Re: 12.05 linux-linaro kernel tree

[Tushar Behera]

On 05/18/2012 10:57 PM, Andrey Konovalov wrote:
> Samsung LT's topics:
> topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram
> topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch
> topic/wlan topic/audio topic/hdmi topic/mfc topic/mali
> topic/cma_origen topic/android_config topic/ubuntu_config
> 
Attached patch fixes kernel panic while booting Android on Origen board
using linux-linaro kernel. Since this is touching the core file, I would
like to know if there are any objections to this.

Andrey,
If it is ok, you may either apply the patch or merge [1].

[1] git://git.linaro.org/landing-teams/working/samsung/kernel.git
(llt/umm_fixes)


>>>
 drivers/media/video/videobuf2-dma-contig.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index 266ae7d..57e643b 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -273,6 +273,9 @@ static struct vm_area_struct *vb2_dc_get_user_vma(
 static int vb2_dc_get_user_pages(unsigned long start, struct page **pages,
int n_pages, struct vm_area_struct *vma, int write)
 {
+   if (vma->vm_mm == NULL)
+   vma->vm_mm = current->mm;
+
if (vma_is_io(vma)) {
unsigned int i;



-- 
Tushar Behera
>From c579b4d6b17a6fb1b15cc681268db54e5b73afaf Mon Sep 17 00:00:00 2001
From: Sachin Kamat 
Date: Mon, 21 May 2012 13:51:19 +0530
Subject: [PATCH] VB2-DC: Fix Null pointer related kernel boot crash

vma->vm_mm should point to the proper mm structure. But the pointer is
NULL here. Explicitly setting it to current->mm to avoid kernel crash
during bootup.

Signed-off-by: Ritesh Kumar Solanki 
Signed-off-by: Sachin Kamat 
Signed-off-by: Tushar Behera 
---
 drivers/media/video/videobuf2-dma-contig.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c b/drivers/media/video/videobuf2-dma-contig.c
index 266ae7d..57e643b 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -273,6 +273,9 @@ static struct vm_area_struct *vb2_dc_get_user_vma(
 static int vb2_dc_get_user_pages(unsigned long start, struct page **pages,
 	int n_pages, struct vm_area_struct *vma, int write)
 {
+	if (vma->vm_mm == NULL)
+		vma->vm_mm = current->mm;
+
 	if (vma_is_io(vma)) {
 		unsigned int i;
 
-- 
1.7.4.1

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: android-3.4 or android-3.4-compat

[Dechesne, Nicolas]

hi,

On Fri, May 18, 2012 at 6:00 AM, Andy Green  wrote:

> So I just wanted to check first with folks to make sure there are no
>> objections to merging in the -compat changes, and that the timing of
>> merging in these changes isn't problematic (I can happily hold off till
>> this months release is done, so we don't risk any last minute gotchas).
>>
>
> The only worry I can see is that now even vanilla versions of LT kernels
> are basing off llct that includes Androidizaton, even vanilla will have
> possibly invasive wakelock code.
>
> It might be good to briefly audit the changes to confirm they don't appear
> if CONFIG_ANDROID is off.  Google might not take much care about that case
> but I think it might be important for us.
>

like Andy, I am a bit concerned that we merge the android stuff into the
linaro-core and that we get android candies in 'vanilla' kernel. can't we
(shouldn't we) have -android on top of -core and pull -android only into
'android' kernel? it's true that for most things, -android is not impacting
a 'vanilla' kernel, but clearly from the outside (community *and*
customers) a kernel 'tainted' with Android is not a 'vanilla' kernel
anymore...

I really like the linux-core tree by the way, and the fact that we get
Linaro technologies pre-integrated is helping us clearly. I think if we
only add -android as a branch on top of -core, then that should be enough.

Then Andy (or other LT) would pull -core into their -vanilla, and pull
-android branch into the LT androidized kernel!

cheers,

nico
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC PATCH v1] AudiVal (Audio Validation Suite for Linux)

[Kurt Taylor]

On 17 May 2012 00:12, Harsh Prateek Bora  wrote:

>
>
> On 17 May 2012 01:35, Paul Larson  wrote:
>
>> On Wed, May 16, 2012 at 1:43 AM, Harsh Prateek Bora <
>> harsh.b...@linaro.org> wrote:
>>
>>>
>>>
>>> On 16 May 2012 09:38, Paul Larson  wrote:
>>>
 On Tue, May 15, 2012 at 4:24 PM, Tom Gall  wrote:

> HI Paul,
>
> On Tue, May 15, 2012 at 4:14 PM, Paul Larson 
> wrote:
> > Cool, does this replace the existing e2daudiotest I guess?
>
> Please consider it as complementary.
>
> Ah, I see after looking at it a bit more.  This one isn't completely
 automated and requires someone to listen to the sound :)

>>>
>>> Yes, Its the initial phase and therefore will evolve with time as
>>> required. We may want to plug-in e2eaudiotest and others if already
>>> available.
>>> As of now, it frees the user from finding out the card, device info for
>>> each audio playback/recording device on supported hardware and can help in
>>> identify issues where audio is almost ok, but not truly perfect (like
>>> choppy audio). Un-attended tests may treat imperfect audio as bad as no
>>> audio. I hope I am able to convey what I intend to do so.
>>>
>>> Ah, so if e2eaudiotest is plugged into it, it could act as a sort of
>> front-end for running it and making sure that the right audio device is set
>> up for that particular board?  So in this way, it could allow for automated
>> tests, not just interactive ones?
>>
>
The tests in question are really for different audiences. The e2eaudiotest
tool was designed to be in a fully automated environment as a build sniff
test that does not require a human to see if the entire audio stack on a
particular board/build works "good enough" using a default path.

The test script is to provide an interactive umbrella tool for the
developer to exhaustively test the stack before upstreaming. This can
include the former tool, but doesn't need to.


> Yes, we can add more as well !
>
> regards,
> Harsh
>
>
>>
>> Thanks,
>> Paul Larson
>>
>
>


-- 

Kurt Taylor (irc krtaylor)
Linaro Multimedia
Linaro.org * **│ *Open source software for ARM SoCs
Follow *Linaro: *Facebook  |
Twitter|
Blog 
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: android-3.4 or android-3.4-compat

[Andy Green]

On 21/05/12 18:27, Somebody in the thread at some point said:

hi,

On Fri, May 18, 2012 at 6:00 AM, Andy Green mailto:andy.gr...@linaro.org>> wrote:

So I just wanted to check first with folks to make sure there are no
objections to merging in the -compat changes, and that the timing of
merging in these changes isn't problematic (I can happily hold
off till
this months release is done, so we don't risk any last minute
gotchas).


The only worry I can see is that now even vanilla versions of LT
kernels are basing off llct that includes Androidizaton, even
vanilla will have possibly invasive wakelock code.

It might be good to briefly audit the changes to confirm they don't
appear if CONFIG_ANDROID is off.  Google might not take much care
about that case but I think it might be important for us.


like Andy, I am a bit concerned that we merge the android stuff into the
linaro-core and that we get android candies in 'vanilla' kernel. can't
we (shouldn't we) have -android on top of -core and pull -android only
into 'android' kernel? it's true that for most things, -android is not
impacting a 'vanilla' kernel, but clearly from the outside (community
*and* customers) a kernel 'tainted' with Android is not a 'vanilla'
kernel anymore...

I really like the linux-core tree by the way, and the fact that we get
Linaro technologies pre-integrated is helping us clearly. I think if we
only add -android as a branch on top of -core, then that should be enough.

Then Andy (or other LT) would pull -core into their -vanilla, and pull
-android branch into the LT androidized kernel!


Right that is how it used to be until recently.  But to be fair to 
platform guys, recently mainline did bring a lot of Android stuff back 
into vanilla staging with intention to make it a permanent part of vanilla.


The problem is they were the "easy bits" of Androidization that would 
stay in the staging box.


The Androidization in llct and this new tranche is more invasive to the 
general tree.  Despite I am not on John's whitelist of People Whose 
Opinions Matter for that subject, maybe we should take some care to 
either audit what we're adding to vanilla or as Nicolas is suggesting 
separate it out again.


-Andy

--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 12.05 linux-linaro kernel tree

[Andrey Konovalov]

Greetings,

Changes since last Friday, May 18:
* new ubuntu-sauce topic added
* new umm_fixes topic added (one patch from the Samsung LT to fix
  kernel panic while booting Android on Origen board)
* the tree has been moved from v3.4-rc7 to v3.4 release

Moving to v3.4 release caused one conflict in drivers/dma/pl330.c when 
merging the Samsung LT's topic/core. I've emailed the details to Tushar 
for review.


Starting from today, the linux-linaro branch is frozen until the 12.05 
release is out. Only important bug fixes would be accepted.


Here is the list of the topics included into the 12.05 linux-linaro tree:

Generic topics:
ufs (ufs-for-linux-linaro)
emmc (emmc-for-linux-linaro)
thermal_exynos4_imx6 (thermal_exynos4_imx6_work)
linaro-android-3.4
armlt-gator (tracking-armlt-gator)
umm-wip (umm-3.4rc4-wip)
unsorted (tracking-orphan-unsorted branch from
people/ynk/linux-linaro-tracking.git for the stuff that doesn't fit into
any existing topics)
linaro-configs-3.4
ubuntu-sauce (git://git.linaro.org/ubuntu/linux-linaro-quantal.git
linaro-ubuntu-sauce-packaging-topic)

ARM LT's topics:
tracking-armlt-hdlcd
tracking-armlt-mmc
tracking-armlt-arm-arch-fixes
tracking-armlt-misc-fixes (can be dropped actually, as these fixes are 
in the mainline already - thanks, Tixy)

tracking-armlt-ubuntu-config
tracking-armlt-android-config

Samsung LT's topics:
topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram
topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch
topic/wlan topic/audio topic/hdmi topic/mfc topic/mali
topic/cma_origen topic/android_config topic/ubuntu_config
llt/umm_fixes

last-minute-fixes topic:
- trivial fix to include/linux/dma-buf.h to make it compile in the 
CONFIG_DMA_SHARED_BUFFER=n case


Thanks,
Andrey

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: android-3.4 or android-3.4-compat

[John Stultz]

On 05/21/2012 03:27 AM, Dechesne, Nicolas wrote:

hi,

On Fri, May 18, 2012 at 6:00 AM, Andy Green > wrote:


So I just wanted to check first with folks to make sure there
are no
objections to merging in the -compat changes, and that the
timing of
merging in these changes isn't problematic (I can happily hold
off till
this months release is done, so we don't risk any last minute
gotchas).


The only worry I can see is that now even vanilla versions of LT
kernels are basing off llct that includes Androidizaton, even
vanilla will have possibly invasive wakelock code.

It might be good to briefly audit the changes to confirm they
don't appear if CONFIG_ANDROID is off.  Google might not take much
care about that case but I think it might be important for us.


like Andy, I am a bit concerned that we merge the android stuff into 
the linaro-core and that we get android candies in 'vanilla' kernel. 
can't we (shouldn't we) have -android on top of -core and pull 
-android only into 'android' kernel? it's true that for most things, 
-android is not impacting a 'vanilla' kernel, but clearly from the 
outside (community *and* customers) a kernel 'tainted' with Android is 
not a 'vanilla' kernel anymore...


So this re-opens the discussion we've been having since at least last 
Oct in moving to a consolidated kernel.


Since Android upstreaming is an very active goal of Linaro,  I think 
there's strong technical value in putting the Android patches in along 
with all the other Linaro trees, as it allows us to work out any sort of 
incompatibilities or issues, so we can resolve them prior to being 
pushed upstream.


That said, if folks really want to have a non-android linaro-core tree, 
we can ask Andrey to just merge it in the same phase as he does the 
Landing team trees.


thanks
-john


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: android-3.4 or android-3.4-compat

[John Stultz]

On 05/17/2012 09:00 PM, Andy Green wrote:

On 18/05/12 09:49, Somebody in the thread at some point said:

Hey Andrey, Zach,
So I'm back from my vacation, and have found that the Android team has
released a -compat tree for their 3.4 kernel. Basically this tree
re-adds some items like earlysuspend and classic wakelocks in order to
provide better compatibility with old (and by old, I really mean current
as far as we see - so ICS and earlier) Android userland.

Since we're still shipping ICS, and have no access to whatever the
Android 5.0 userland will be, it seems merging in the -compat tree would
make sense.

However, I know Tixy and others have already tried to address the lack
of earlysuspend in the android-3.3+ kernels, so I wanted to double check
that this wouldn't cause additional pain (since those adjustments might
need to be reverted).

So I just wanted to check first with folks to make sure there are no
objections to merging in the -compat changes, and that the timing of
merging in these changes isn't problematic (I can happily hold off till
this months release is done, so we don't risk any last minute gotchas).


The only worry I can see is that now even vanilla versions of LT 
kernels are basing off llct that includes Androidizaton, even vanilla 
will have possibly invasive wakelock code.


Could you expand a bit more on your concern here? Is the the wakelock 
infrastructure you're concerned about, or the driver changes made by the 
wakelock usage? Or is it just other nebulous changes in the Android tree?


It might be good to briefly audit the changes to confirm they don't 
appear if CONFIG_ANDROID is off.  Google might not take much care 
about that case but I think it might be important for us.


So while wakelocks should turn into a noop if they are disabled, there 
are other changes in the Android tree that aren't necessarily config 
switched.  However, since we are trying to push these patches upstream, 
I think its actually good that we test these changes in non-android 
settings, since its the hope that they will be there eventually, if not 
soon.


Of course, if there are specific issues that pop up, we can either work 
with Google to add needed switches so the code can coexist, or rework 
the changes so the feature is runtime selectable.


thanks
-john


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: android-3.4 or android-3.4-compat

[Christian Robottom Reis]

On Mon, May 21, 2012 at 10:33:47AM -0700, John Stultz wrote:
> >like Andy, I am a bit concerned that we merge the android stuff
> >into the linaro-core and that we get android candies in 'vanilla'
> >kernel. can't we (shouldn't we) have -android on top of -core and
> >pull -android only into 'android' kernel? it's true that for most
> >things, -android is not impacting a 'vanilla' kernel, but clearly
> >from the outside (community *and* customers) a kernel 'tainted'
> >with Android is not a 'vanilla' kernel anymore...
> 
> So this re-opens the discussion we've been having since at least
> last Oct in moving to a consolidated kernel.
> 
> Since Android upstreaming is an very active goal of Linaro,  I think
> there's strong technical value in putting the Android patches in
> along with all the other Linaro trees, as it allows us to work out
> any sort of incompatibilities or issues, so we can resolve them
> prior to being pushed upstream.

I'm quite +1 on what John is saying. There was a time when there was
great uncertainty about the future of the Android patches, but since
Linus' comment last year it's become dead certain that the functionality
/will/ be merged upstream. We can pave the way by getting any
integration issues sorted out early -- similarly to what we do for
practically everything else in linux-linaro.
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 12.05 linux-linaro kernel tree

[Ricardo Salveti]

On Thu, May 10, 2012 at 10:43 PM, Andy Green  wrote:
> On 11/05/12 08:27, Somebody in the thread at some point said:
>
>>  4. in between RCs, we only move mainline on our linux-linaro release
>> baseline forward if we see a working tracking build that wouldn't drop
>> any topics that already made it into this RC cycle.
>
>
> The probability of getting a good unified tree follows the kernel cycle, we
> all have good reasons to have tried to arrive at a good, working, release.
>  Sometimes we only get a reasonably good result a week or two after Linus'
> release.
>
> For that reason maybe you should just be trying to 'release' a release-basis
> unified tree, ie, the 3.4 one targeted now as the deliverable.  It still has
> meaning to make a monthly release of that since it can collect stable
> mainline updates and updates from each LT release tree that happened in the
> meanwhile.
>
> We do need to create these intermediate unified trees so we know what to fix
> on our trees so they can go in smoothly, but it matters less then if one day
> half the LT trees are missing on it since it's of interest only for LTs and
> platform guys to study what else needs solving on the LT trees.
>
> I still think you won't get anywhere useful until we are trying to build the
> unified trees for real.  Then we can start the needed work to make them fit
> together properly, until then we're treading water in "technical debt".
>  Discussing how to run the tree is something to do later after gaining this
> experience.
>
> I had a look at the LT gits
>
> ARM        Merge-managed      integration-linux-vexpress 3.4-rc4
> TI         Rebase-managed     tilt-tracking              3.4-rc4
> Freescale  Merge-managed      lt-3.4                     3.4-rc3
> Samsung    Rebase-managed     tracking                   3.4-rc3
> STE        Merge-managed      integration-linux-ux500    3.4-rc6
>
> (wow STE - on igloocommunity.org - have a LOT of patches!  I thought we were
> leading the way)
>
> Actually locally TILT are on -rc6 but there was almost no conflict coming
> between -rc4 and -rc6.  If you take the approach to merge these trees, I
> found that late in the cycle it's usually pretty forgiving about some
> variation in basis.
>
> So why not give these all a test merge today and see what starts falling
> out?  I am sure we all have something to fix and there may be larger issues
> like two trees with conflicting versions of, I dunno, Mali driver, that
> needs planning to resolve.  Or if people aren't using
> linux-linaro-core-tracking to get their CMA and so on, we need to know and
> start that migration.

So, if I understood correctly, the llct would be the branch used to
actually start producing a valuable path to get the unified tree in
place.

As you said, it seems we should start trying to experiment merging
everything together and deciding what can actually be moved or not to
the core-tracking branch. This way we'd probably move to the direction
of having one real unified tree, instead of just maintaining
linux-linaro over the time.

So these are the useful branches I believe we'd end up having:
- Linux Linaro Core Tracking: main tree used to develop the common
changes across the different LTs/WGs and board flavours
- Linux Linaro: tree with llct that is stabilised between rc releases,
that's part of the LEB releases. This tree would also have additional
topics from the LTs and WGs, in case they want to release it all into
one single tree (releasing together with Linux Linaro is useful in a
way we'll share QA and also helping identifying what other
improvements might be needed in case of conflicts)
- Linux Linaro Tracking/Unified: a tree that could contain llct + all
the sauce maintained by all the LTs, to be used just for testing to
help understanding what should be shared between LTs and be moved to
core-tracking. This would help us getting to a position where we could
identify early what are the conflicts, and work on getting a common
solution with core-tracking before actually starting to send upstream.

Would this fit your needs?

Thanks,
-- 
Ricardo Salveti de Araujo

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v5 2/7] ARM: imx: Add comments to tzic_enable_waker()

[Robert Lee]

Add additional comments to the tzic_enable_wake() funciton to
clarify its intended usage.

Signed-off-by: Robert Lee 
---
 arch/arm/plat-mxc/tzic.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/plat-mxc/tzic.c b/arch/arm/plat-mxc/tzic.c
index 98308ec..a45dbea 100644
--- a/arch/arm/plat-mxc/tzic.c
+++ b/arch/arm/plat-mxc/tzic.c
@@ -190,6 +190,10 @@ void __init tzic_init_irq(void __iomem *irqbase)
  * tzic_enable_wake() - enable wakeup interrupt
  *
  * @return 0 if successful; non-zero otherwise
+ *
+ * This function provides an interrupt synchronization point that is required
+ * by tzic enabled platforms before entering imx specific low power modes (ie,
+ * those low power modes beyond the WAIT_CLOCKED basic ARM WFI only mode).
  */
 int tzic_enable_wake(void)
 {
-- 
1.7.10


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v5 1/7] ARM: imx: Modify IMX_IO_P2V macro

[Robert Lee]

A change is needed in the IMX_IO_P2V macro to allow all imx5 platforms
to use common definitions when accessing registers of peripherals on
the AIPS2 bus.  With this change, IMX_IO_P2V(MX50_AIPS2_BASE_ADDR) ==
IMX_IO_P2V(MX51_AIPS2_BASE_ADDR) == IMX_IO_P2V(MX53_AIPS2_BASE_ADDR).

This change was tested for mapping conflicts using the iop2v script
found at git://git.pengutronix.de/git/ukl/imx-iop2v.git and by
performing a bootup of a default build using imx_v6_v7_defconfig
on a imx51 babbage board and imx53 loco board.  The comments were
modified to reflect the output given by the script which shows the
virtual address mappings.

Signed-off-by: Robert Lee 
---
 arch/arm/plat-mxc/include/mach/hardware.h |   25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/arch/arm/plat-mxc/include/mach/hardware.h 
b/arch/arm/plat-mxc/include/mach/hardware.h
index 0630513..071afd0 100644
--- a/arch/arm/plat-mxc/include/mach/hardware.h
+++ b/arch/arm/plat-mxc/include/mach/hardware.h
@@ -50,7 +50,7 @@
  * IO  0x0020+0x10 ->  0xf400+0x10
  * mx21:
  * AIPI0x1000+0x10 ->  0xf440+0x10
- * SAHB1   0x8000+0x10 ->  0xf400+0x10
+ * SAHB1   0x8000+0x10 ->  0xf500+0x10
  * X_MEMC  0xdf00+0x004000 ->  0xf5f0+0x004000
  * mx25:
  * AIPS1   0x43f0+0x10 ->  0xf530+0x10
@@ -58,47 +58,50 @@
  * AVIC0x6800+0x10 ->  0xf580+0x10
  * mx27:
  * AIPI0x1000+0x10 ->  0xf440+0x10
- * SAHB1   0x8000+0x10 ->  0xf400+0x10
+ * SAHB1   0x8000+0x10 ->  0xf500+0x10
  * X_MEMC  0xd800+0x10 ->  0xf5c0+0x10
  * mx31:
  * AIPS1   0x43f0+0x10 ->  0xf530+0x10
  * AIPS2   0x53f0+0x10 ->  0xf570+0x10
  * AVIC0x6800+0x10 ->  0xf580+0x10
- * X_MEMC  0xb800+0x01 ->  0xf4c0+0x01
+ * X_MEMC  0xb800+0x01 ->  0xf5c0+0x01
  * SPBA0   0x5000+0x10 ->  0xf540+0x10
  * mx35:
  * AIPS1   0x43f0+0x10 ->  0xf530+0x10
  * AIPS2   0x53f0+0x10 ->  0xf570+0x10
  * AVIC0x6800+0x10 ->  0xf580+0x10
- * X_MEMC  0xb800+0x01 ->  0xf4c0+0x01
+ * X_MEMC  0xb800+0x01 ->  0xf5c0+0x01
  * SPBA0   0x5000+0x10 ->  0xf540+0x10
  * mx50:
  * TZIC0x0fffc000+0x004000 ->  0xf4bfc000+0x004000
- * SPBA0   0x5000+0x10 ->  0xf540+0x10
  * AIPS1   0x53f0+0x10 ->  0xf570+0x10
+ * SPBA0   0x5000+0x10 ->  0xf540+0x10
  * AIPS2   0x63f0+0x10 ->  0xf530+0x10
  * mx51:
- * TZIC0xe000+0x004000 ->  0xf500+0x004000
+ * TZIC0x0fffc000+0x004000 ->  0xf4bfc000+0x004000
  * IRAM0x1ffe+0x02 ->  0xf4fe+0x02
+ * DEBUG   0x6000+0x10 ->  0xf500+0x10
  * SPBA0   0x7000+0x10 ->  0xf540+0x10
  * AIPS1   0x73f0+0x10 ->  0xf570+0x10
- * AIPS2   0x83f0+0x10 ->  0xf430+0x10
+ * AIPS2   0x83f0+0x10 ->  0xf530+0x10
  * mx53:
  * TZIC0x0fffc000+0x004000 ->  0xf4bfc000+0x004000
+ * DEBUG   0x4000+0x10 ->  0xf500+0x10
  * SPBA0   0x5000+0x10 ->  0xf540+0x10
  * AIPS1   0x53f0+0x10 ->  0xf570+0x10
  * AIPS2   0x63f0+0x10 ->  0xf530+0x10
  * mx6q:
- * SCU 0x00a0+0x001000 ->  0xf400+0x001000
+ * SCU 0x00a0+0x004000 ->  0xf400+0x004000
  * CCM 0x020c4000+0x004000 ->  0xf42c4000+0x004000
- * ANATOP  0x020c8000+0x001000 ->  0xf42c8000+0x001000
+ * ANATOP  0x020c8000+0x004000 ->  0xf42c8000+0x004000
  * UART4   0x021f+0x004000 ->  0xf42f+0x004000
  */
 #define IMX_IO_P2V(x)  (   \
-   0xf400 +\
+   (((x) & 0x8000) >> 7) | \
+   (0xf400 +   \
(((x) & 0x5000) >> 6) + \
(((x) & 0x0b00) >> 4) + \
-   (((x) & 0x000f)))
+   (((x) & 0x000f
 
 #define IMX_IO_ADDRESS(x)  IOMEM(IMX_IO_P2V(x))
 
-- 
1.7.10


_

[PATCH v5 0/7] cleanup imx5 idle, add imx5/6 cpuidle

[Robert Lee]

Cleanup up imx5 idle code and enable imx5 low powe idle for imx53.

Add common imx cpuidle initialization functionality and add a i.MX5 and i.MX6Q
platform cpuidle implementation.

Based on v3.4 plus recently submitted/accepted MACHINE_INIT late_initcall 
 patch series: http://www.spinics.net/lists/arm-kernel/msg171620.html and common
 clock patch series:
 http://comments.gmane.org/gmane.linux.ports.arm.kernel/161043

v5 changes:
 * rebase to v3.4 plus common clock patch series
 * various trivial changes/fixes from v4 submssion
 * Add separate pm_init patch for imx51 and imx53

v4 changes:
 * Added several imx5 idle cleanups to series.
 * Modified imx_io_p2v function to allow common imx5 AIPS2 bus virutal address
 * Added comment to tzic_wakeup_enable().
 * Movied imx5 idle code from mm-imx5.c to pm-imx5.c.
 * Removed unnecessary time consuming code execution that ran on each idle
   instance.
 * modified imx5_pm_init to be a late_initcall
 * added late_initcall to all imx53 MACHINE_START entries.
 * enabled imx5 low power idle for imx53
 * rebased cpuidle driver on top of imx5 cleanup changes.
 * modified cpuidle driver exit time to reflect removal of unnecessary code

http://comments.gmane.org/gmane.linux.linaro.devel/11858
   

v3 changes:
 * removed file introduced in v1 no longer needed after v2 [per Shawn Guo]
 * re-ordered added #includes in alphabetical order [per Shawn Guo]
 * Remove if(!drv) check to allow handling by stack trace [per Sascha Hauer]
 * Added missing return value in error meesage [per Shawn Guo]
 * fixed (void *) casting problem pointed out Sasha Hauer.  Used a different
   type of casting to properly give warning on improper casting:
arm_pm_idle = (void (*)(void))imx5_idle;
   Used this casting instead of adding a dummy caller function because
   adding the dummy function appears to unnecessarily introduce the following
   additional operations:
static void imx5_pm_idle(void)
{
  a0:   e1a0c00dmov ip, sp
  a4:   e92dd800push{fp, ip, lr, pc}
  a8:   e24cb004sub fp, ip, #4
imx5_idle();
  ac:   ebd3bl  0 
}
  b0:   e89da800ldm sp, {fp, sp, pc}

http://permalink.gmane.org/gmane.linux.linaro.devel/11653

v2 changes:
 * Removed some unnecessary  spaces [per Jess Juhl]
 * Added return value for an error message [per Sascha Hauer]
 * Reworked init scheme to use device tree late_initcall [per Sascha and Shawn]
 * Moved imx6q and imx5 cpuidle functionality to existing files.

https://lkml.org/lkml/2012/5/1/363

v1 initial submission:

https://lkml.org/lkml/2012/4/16/644

Robert Lee (7):
  ARM: imx: Modify IMX_IO_P2V macro
  ARM: imx: Add comments to tzic_enable_waker()
  ARM: imx: clean and consolidate imx5 suspend and idle code
  ARM: imx: Enable imx53 low power idle
  ARM: imx: Add common imx cpuidle init functionality.
  ARM: imx: Add imx5 cpuidle
  ARM: imx: Add imx6q cpuidle driver

 arch/arm/mach-imx/clk-imx51-imx53.c   |2 +-
 arch/arm/mach-imx/clock-mx51-mx53.c   |1 +
 arch/arm/mach-imx/imx53-dt.c  |1 +
 arch/arm/mach-imx/mach-imx6q.c|   19 +
 arch/arm/mach-imx/mach-mx53_ard.c |1 +
 arch/arm/mach-imx/mach-mx53_evk.c |1 +
 arch/arm/mach-imx/mach-mx53_loco.c|1 +
 arch/arm/mach-imx/mach-mx53_smd.c |1 +
 arch/arm/mach-imx/mm-imx5.c   |   26 ++-
 arch/arm/mach-imx/pm-imx5.c   |  111 ++---
 arch/arm/plat-mxc/Makefile|1 +
 arch/arm/plat-mxc/cpuidle.c   |   80 +
 arch/arm/plat-mxc/include/mach/common.h   |6 +-
 arch/arm/plat-mxc/include/mach/cpuidle.h  |   22 ++
 arch/arm/plat-mxc/include/mach/hardware.h |   25 ---
 arch/arm/plat-mxc/tzic.c  |4 ++
 16 files changed, 243 insertions(+), 59 deletions(-)
 create mode 100644 arch/arm/plat-mxc/cpuidle.c
 create mode 100644 arch/arm/plat-mxc/include/mach/cpuidle.h

-- 
1.7.10


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v5 7/7] ARM: imx: Add imx6q cpuidle driver

[Robert Lee]

Add basic imx6q cpuidle driver.  For now, only basic WFI state is
supported.  Deeper idle states will be added in the future.

Signed-off-by: Robert Lee 
---
 arch/arm/mach-imx/mach-imx6q.c |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index da6c1d9..4fc1fe7 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -10,7 +10,9 @@
  * http://www.gnu.org/copyleft/gpl.html
  */
 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -21,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,8 +31,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
+
 void imx6q_restart(char mode, const char *cmd)
 {
struct device_node *np;
@@ -86,6 +91,19 @@ static void __init imx6q_init_machine(void)
imx6q_pm_init();
 }
 
+static struct cpuidle_driver imx6q_cpuidle_driver = {
+   .name   = "imx6q_cpuidle",
+   .owner  = THIS_MODULE,
+   .en_core_tk_irqen   = 1,
+   .states[0]  = ARM_CPUIDLE_WFI_STATE,
+   .state_count= 1,
+};
+
+static void __init imx6q_init_late(void)
+{
+   imx_cpuidle_init(&imx6q_cpuidle_driver);
+}
+
 static void __init imx6q_map_io(void)
 {
imx_lluart_map_io();
@@ -142,6 +160,7 @@ DT_MACHINE_START(IMX6Q, "Freescale i.MX6 Quad (Device 
Tree)")
.handle_irq = imx6q_handle_irq,
.timer  = &imx6q_timer,
.init_machine   = imx6q_init_machine,
+   .init_late  = imx6q_init_late,
.dt_compat  = imx6q_dt_compat,
.restart= imx6q_restart,
 MACHINE_END
-- 
1.7.10


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v5 6/7] ARM: imx: Add imx5 cpuidle

[Robert Lee]

Add cpuidle driver for imx5 platform.

Signed-off-by: Robert Lee 
---
 arch/arm/mach-imx/pm-imx5.c |   43 +--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index b3dcd8e..19621ed1 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -12,10 +12,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "crm-regs-imx5.h"
 
@@ -134,12 +136,48 @@ static const struct platform_suspend_ops mx5_suspend_ops 
= {
.enter = mx5_suspend_enter,
 };
 
-static void imx5_pm_idle(void)
+static inline int imx5_cpu_do_idle(void)
 {
-   if (likely(!tzic_enable_wake()))
+   int ret = tzic_enable_wake();
+
+   if (likely(!ret))
cpu_do_idle();
+
+   return ret;
+}
+
+static void imx5_pm_idle(void)
+{
+   imx5_cpu_do_idle();
+}
+
+static int imx5_cpuidle_enter(struct cpuidle_device *dev,
+   struct cpuidle_driver *drv, int idx)
+{
+   int ret;
+
+   ret = imx5_cpu_do_idle();
+   if (ret < 0)
+   return ret;
+
+   return idx;
 }
 
+static struct cpuidle_driver imx5_cpuidle_driver = {
+   .name   = "imx5_cpuidle",
+   .owner  = THIS_MODULE,
+   .en_core_tk_irqen   = 1,
+   .states[0]  = {
+   .enter  = imx5_cpuidle_enter,
+   .exit_latency   = 2,
+   .target_residency   = 1,
+   .flags  = CPUIDLE_FLAG_TIME_VALID,
+   .name   = "IMX5 SRPG",
+   .desc   = "CPU state retained,powered off",
+   },
+   .state_count= 1,
+};
+
 static int __init imx5_pm_common_init(void)
 {
int ret;
@@ -157,6 +195,7 @@ static int __init imx5_pm_common_init(void)
/* Set the registers to the default cpu idle state. */
mx5_cpu_lp_set(IMX5_DEFAULT_CPU_IDLE_STATE);
 
+   imx_cpuidle_init(&imx5_cpuidle_driver);
return 0;
 }
 
-- 
1.7.10


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v5 3/7] ARM: imx: clean and consolidate imx5 suspend and idle code

[Robert Lee]

The imx5 idle code that existed in mm-imx5.c is moved to pm-imx5.c.
The imx5_pm_init call is now exported and called during the
MACHINE_START late_init in supported imx5 platforms.

Remove various enabling/disabling of the gpc_dvfs clock and
enable it once during initialization.  This is a very low
power clock that must be enabled during low power operations.

There are only two "suspend_state_t" imx5 low power modes ever
used.  STOP_POWER_OFF for suspend to mem and
WAIT_UNCLOCKED_POWER_OFF for idle and suspend to standby.  The
latter mode only requires 500 nanoseconds of extra hardware
exit time beyond a basic WFI operation (WAIT_CLOCKED mode) so
no other idle mode is necessary.  Given this information, it
is more efficient to keep the registers in the often used
WAIT_UNCLOCKED_POWER_OFF state and only to and from the
STOP_POWER_OFF register state as needed when suspend to
mem is required.

Signed-off-by: Robert Lee 
---
 arch/arm/mach-imx/mm-imx5.c |   21 +-
 arch/arm/mach-imx/pm-imx5.c |   67 +++
 arch/arm/plat-mxc/include/mach/common.h |3 +-
 3 files changed, 44 insertions(+), 47 deletions(-)

diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c
index 3fb4d56..ff7fa61 100644
--- a/arch/arm/mach-imx/mm-imx5.c
+++ b/arch/arm/mach-imx/mm-imx5.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 #include 
@@ -23,24 +22,6 @@
 #include 
 #include 
 
-static struct clk *gpc_dvfs_clk;
-
-static void imx5_idle(void)
-{
-   /* gpc clock is needed for SRPG */
-   if (gpc_dvfs_clk == NULL) {
-   gpc_dvfs_clk = clk_get(NULL, "gpc_dvfs");
-   if (IS_ERR(gpc_dvfs_clk))
-   return;
-   clk_prepare(gpc_dvfs_clk);
-   }
-   clk_enable(gpc_dvfs_clk);
-   mx5_cpu_lp_set(WAIT_UNCLOCKED_POWER_OFF);
-   if (!tzic_enable_wake())
-   cpu_do_idle();
-   clk_disable(gpc_dvfs_clk);
-}
-
 /*
  * Define the MX50 memory map.
  */
@@ -104,7 +85,6 @@ void __init imx51_init_early(void)
mxc_set_cpu_type(MXC_CPU_MX51);
mxc_iomux_v3_init(MX51_IO_ADDRESS(MX51_IOMUXC_BASE_ADDR));
mxc_arch_reset_init(MX51_IO_ADDRESS(MX51_WDOG1_BASE_ADDR));
-   arm_pm_idle = imx5_idle;
 }
 
 void __init imx53_init_early(void)
@@ -239,4 +219,5 @@ void __init imx53_soc_init(void)
 void __init imx51_init_late(void)
 {
mx51_neon_fixup();
+   imx51_pm_init();
 }
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index e26a9cb..baf9321 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -13,18 +13,27 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include "crm-regs-imx5.h"
 
-static struct clk *gpc_dvfs_clk;
+/*
+ * The WAIT_UNCLOCKED_POWER_OFF state only requires <= 500ns to exit.
+ * This is also the lowest power state possible without affecting
+ * non-cpu parts of the system.  For these reasons, imx5 should default
+ * to always using this state for cpu idling.  The PM_SUSPEND_STANDBY also
+ * uses this state and needs to take no action when registers remain confgiured
+ * for this state.
+ */
+#define IMX5_DEFAULT_CPU_IDLE_STATE WAIT_UNCLOCKED_POWER_OFF
 
 /*
  * set cpu low power mode before WFI instruction. This function is called
  * mx5 because it can be used for mx50, mx51, and mx53.
  */
-void mx5_cpu_lp_set(enum mxc_cpu_pwr_mode mode)
+static void mx5_cpu_lp_set(enum mxc_cpu_pwr_mode mode)
 {
u32 plat_lpc, arm_srpgcr, ccm_clpcr;
u32 empgc0, empgc1;
@@ -87,11 +96,6 @@ void mx5_cpu_lp_set(enum mxc_cpu_pwr_mode mode)
}
 }
 
-static int mx5_suspend_prepare(void)
-{
-   return clk_prepare_enable(gpc_dvfs_clk);
-}
-
 static int mx5_suspend_enter(suspend_state_t state)
 {
switch (state) {
@@ -99,7 +103,7 @@ static int mx5_suspend_enter(suspend_state_t state)
mx5_cpu_lp_set(STOP_POWER_OFF);
break;
case PM_SUSPEND_STANDBY:
-   mx5_cpu_lp_set(WAIT_UNCLOCKED_POWER_OFF);
+   /* DEFAULT_IDLE_STATE already configured */
break;
default:
return -EINVAL;
@@ -114,12 +118,10 @@ static int mx5_suspend_enter(suspend_state_t state)
__raw_writel(0, MXC_SRPG_EMPGC1_SRPGCR);
}
cpu_do_idle();
-   return 0;
-}
 
-static void mx5_suspend_finish(void)
-{
-   clk_disable_unprepare(gpc_dvfs_clk);
+   /* return registers to default idle state */
+   mx5_cpu_lp_set(IMX5_DEFAULT_CPU_IDLE_STATE);
+   return 0;
 }
 
 static int mx5_pm_valid(suspend_state_t state)
@@ -129,25 +131,38 @@ static int mx5_pm_valid(suspend_state_t state)
 
 static const struct platform_suspend_ops mx5_suspend_ops = {
.valid = mx5_pm_valid,
-   .prepare = mx5_suspend_prepare,
.enter = mx5_suspend_enter,
-   .finish = mx5_suspend_finish,
 };
 
-static int __init mx5_pm_init(void)
+static void i

[PATCH v5 4/7] ARM: imx: Enable imx53 low power idle

[Robert Lee]

Add various functionality needed to enable a imx53 low power idle
state.  This includes adding the imx53 gpc_dvfs clock and making a
common imx5_late_init function and initializing all imx53
 MACHINE_STATE late_init calls to imx5_late_init.

Signed-off-by: Robert Lee 
---
 arch/arm/mach-imx/clk-imx51-imx53.c |2 +-
 arch/arm/mach-imx/clock-mx51-mx53.c |1 +
 arch/arm/mach-imx/imx53-dt.c|1 +
 arch/arm/mach-imx/mach-mx53_ard.c   |1 +
 arch/arm/mach-imx/mach-mx53_evk.c   |1 +
 arch/arm/mach-imx/mach-mx53_loco.c  |1 +
 arch/arm/mach-imx/mach-mx53_smd.c   |1 +
 arch/arm/mach-imx/mm-imx5.c |5 +
 arch/arm/mach-imx/pm-imx5.c |5 +
 arch/arm/plat-mxc/include/mach/common.h |3 +++
 10 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c 
b/arch/arm/mach-imx/clk-imx51-imx53.c
index 66633d5..834a87d 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -245,6 +245,7 @@ static void __init mx5_clocks_common_init(unsigned long 
rate_ckil,
clk_register_clkdev(clk[dummy], NULL, "imx-keypad");
clk_register_clkdev(clk[tve_gate], NULL, "imx-tve.0");
clk_register_clkdev(clk[ipu_di1_gate], "di1", "imx-tve.0");
+   clk_register_clkdev(clk[gpc_dvfs], "gpc_dvfs", NULL);
 
/* Set SDHC parents to be PLL2 */
clk_set_parent(clk[esdhc_a_sel], clk[pll2_sw]);
@@ -302,7 +303,6 @@ int __init mx51_clocks_init(unsigned long rate_ckil, 
unsigned long rate_osc,
clk_register_clkdev(clk[mx51_mipi], "mipi_hsp", NULL);
clk_register_clkdev(clk[vpu_gate], NULL, "imx51-vpu.0");
clk_register_clkdev(clk[fec_gate], NULL, "imx27-fec.0");
-   clk_register_clkdev(clk[gpc_dvfs], "gpc_dvfs", NULL);
clk_register_clkdev(clk[ipu_gate], "bus", "imx51-ipu");
clk_register_clkdev(clk[ipu_di0_gate], "di0", "imx51-ipu");
clk_register_clkdev(clk[ipu_di1_gate], "di1", "imx51-ipu");
diff --git a/arch/arm/mach-imx/clock-mx51-mx53.c 
b/arch/arm/mach-imx/clock-mx51-mx53.c
index 0847050..decedc6 100644
--- a/arch/arm/mach-imx/clock-mx51-mx53.c
+++ b/arch/arm/mach-imx/clock-mx51-mx53.c
@@ -1529,6 +1529,7 @@ static struct clk_lookup mx53_lookups[] = {
_REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk)
_REGISTER_CLOCK("imx-ssi.2", NULL, ssi3_clk)
_REGISTER_CLOCK("imx-keypad", NULL, dummy_clk)
+   _REGISTER_CLOCK(NULL, "gpc_dvfs", gpc_dvfs_clk)
_REGISTER_CLOCK("pata_imx", NULL, pata_clk)
_REGISTER_CLOCK("imx53-ahci.0", "ahci", sata_clk)
_REGISTER_CLOCK("imx53-ahci.0", "ahci_phy", ahci_phy_clk)
diff --git a/arch/arm/mach-imx/imx53-dt.c b/arch/arm/mach-imx/imx53-dt.c
index 4172279..c502619 100644
--- a/arch/arm/mach-imx/imx53-dt.c
+++ b/arch/arm/mach-imx/imx53-dt.c
@@ -125,6 +125,7 @@ DT_MACHINE_START(IMX53_DT, "Freescale i.MX53 (Device Tree 
Support)")
.handle_irq = imx53_handle_irq,
.timer  = &imx53_timer,
.init_machine   = imx53_dt_init,
+   .init_late  = imx53_init_late,
.dt_compat  = imx53_dt_board_compat,
.restart= mxc_restart,
 MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx53_ard.c 
b/arch/arm/mach-imx/mach-mx53_ard.c
index 0564198..f1e83d6 100644
--- a/arch/arm/mach-imx/mach-mx53_ard.c
+++ b/arch/arm/mach-imx/mach-mx53_ard.c
@@ -266,5 +266,6 @@ MACHINE_START(MX53_ARD, "Freescale MX53 ARD Board")
.handle_irq = imx53_handle_irq,
.timer = &mx53_ard_timer,
.init_machine = mx53_ard_board_init,
+   .init_late  = imx53_init_late,
.restart= mxc_restart,
 MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx53_evk.c 
b/arch/arm/mach-imx/mach-mx53_evk.c
index 5a72188..8387496 100644
--- a/arch/arm/mach-imx/mach-mx53_evk.c
+++ b/arch/arm/mach-imx/mach-mx53_evk.c
@@ -174,5 +174,6 @@ MACHINE_START(MX53_EVK, "Freescale MX53 EVK Board")
.handle_irq = imx53_handle_irq,
.timer = &mx53_evk_timer,
.init_machine = mx53_evk_board_init,
+   .init_late  = imx53_init_late,
.restart= mxc_restart,
 MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx53_loco.c 
b/arch/arm/mach-imx/mach-mx53_loco.c
index 37f67ca..e266f3f 100644
--- a/arch/arm/mach-imx/mach-mx53_loco.c
+++ b/arch/arm/mach-imx/mach-mx53_loco.c
@@ -316,5 +316,6 @@ MACHINE_START(MX53_LOCO, "Freescale MX53 LOCO Board")
.handle_irq = imx53_handle_irq,
.timer = &mx53_loco_timer,
.init_machine = mx53_loco_board_init,
+   .init_late  = imx53_init_late,
.restart= mxc_restart,
 MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx53_smd.c 
b/arch/arm/mach-imx/mach-mx53_smd.c
index 8e972c5..4f4c1b9 100644
--- a/arch/arm/mach-imx/mach-mx53_smd.c
+++ b/arch/arm/mach-imx/mach-mx53_smd.c
@@ -163,5 +163,6 @@ MACHINE_START(MX53_SMD, "Freescale MX53 SMD Board")
.handle_irq = imx53_handle_irq,
.timer = &m

[PATCH v5 5/7] ARM: imx: Add common imx cpuidle init functionality.

[Robert Lee]

Add common cpuidle init functionality that can be used by various
imx platforms.

Signed-off-by: Robert Lee 
---
 arch/arm/plat-mxc/Makefile   |1 +
 arch/arm/plat-mxc/cpuidle.c  |   80 ++
 arch/arm/plat-mxc/include/mach/cpuidle.h |   22 
 3 files changed, 103 insertions(+)
 create mode 100644 arch/arm/plat-mxc/cpuidle.c
 create mode 100644 arch/arm/plat-mxc/include/mach/cpuidle.h

diff --git a/arch/arm/plat-mxc/Makefile b/arch/arm/plat-mxc/Makefile
index e81290c..63b064b 100644
--- a/arch/arm/plat-mxc/Makefile
+++ b/arch/arm/plat-mxc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_MXC_ULPI) += ulpi.o
 obj-$(CONFIG_MXC_USE_EPIT) += epit.o
 obj-$(CONFIG_MXC_DEBUG_BOARD) += 3ds_debugboard.o
 obj-$(CONFIG_CPU_FREQ_IMX)+= cpufreq.o
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o
 ifdef CONFIG_SND_IMX_SOC
 obj-y += ssi-fiq.o
 obj-y += ssi-fiq-ksym.o
diff --git a/arch/arm/plat-mxc/cpuidle.c b/arch/arm/plat-mxc/cpuidle.c
new file mode 100644
index 000..d4cb511
--- /dev/null
+++ b/arch/arm/plat-mxc/cpuidle.c
@@ -0,0 +1,80 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2012 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct cpuidle_device __percpu * imx_cpuidle_devices;
+
+static void __init imx_cpuidle_devices_uninit(void)
+{
+   int cpu_id;
+   struct cpuidle_device *dev;
+
+   for_each_possible_cpu(cpu_id) {
+   dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
+   cpuidle_unregister_device(dev);
+   }
+
+   free_percpu(imx_cpuidle_devices);
+}
+
+int __init imx_cpuidle_init(struct cpuidle_driver *drv)
+{
+   struct cpuidle_device *dev;
+   int cpu_id, ret;
+
+   if (drv->state_count > CPUIDLE_STATE_MAX) {
+   pr_err("%s: state_count exceeds maximum\n", __func__);
+   return -EINVAL;
+   }
+
+   ret = cpuidle_register_driver(drv);
+   if (ret) {
+   pr_err("%s: Failed to register cpuidle driver with error: %d\n",
+__func__, ret);
+   return ret;
+   }
+
+   imx_cpuidle_devices = alloc_percpu(struct cpuidle_device);
+   if (imx_cpuidle_devices == NULL) {
+   ret = -ENOMEM;
+   goto unregister_drv;
+   }
+
+   /* initialize state data for each cpuidle_device */
+   for_each_possible_cpu(cpu_id) {
+   dev = per_cpu_ptr(imx_cpuidle_devices, cpu_id);
+   dev->cpu = cpu_id;
+   dev->state_count = drv->state_count;
+
+   ret = cpuidle_register_device(dev);
+   if (ret) {
+   pr_err("%s: Failed to register cpu %u, error: %d\n",
+   __func__, cpu_id, ret);
+   goto uninit;
+   }
+   }
+
+   return 0;
+
+uninit:
+   imx_cpuidle_devices_uninit();
+
+unregister_drv:
+   cpuidle_unregister_driver(drv);
+   return ret;
+}
diff --git a/arch/arm/plat-mxc/include/mach/cpuidle.h 
b/arch/arm/plat-mxc/include/mach/cpuidle.h
new file mode 100644
index 000..bc932d1
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/cpuidle.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2012 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+
+#ifdef CONFIG_CPU_IDLE
+extern int imx_cpuidle_init(struct cpuidle_driver *drv);
+#else
+static inline int imx_cpuidle_init(struct cpuidle_driver *drv)
+{
+   return -ENODEV;
+}
+#endif
-- 
1.7.10


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: android-3.4 or android-3.4-compat

[Andy Green]

On 22/05/12 01:58, Somebody in the thread at some point said:

On Mon, May 21, 2012 at 10:33:47AM -0700, John Stultz wrote:

like Andy, I am a bit concerned that we merge the android stuff
into the linaro-core and that we get android candies in 'vanilla'
kernel. can't we (shouldn't we) have -android on top of -core and
pull -android only into 'android' kernel? it's true that for most
things, -android is not impacting a 'vanilla' kernel, but clearly

>from the outside (community *and* customers) a kernel 'tainted'

with Android is not a 'vanilla' kernel anymore...


So this re-opens the discussion we've been having since at least
last Oct in moving to a consolidated kernel.

Since Android upstreaming is an very active goal of Linaro,  I think
there's strong technical value in putting the Android patches in
along with all the other Linaro trees, as it allows us to work out
any sort of incompatibilities or issues, so we can resolve them
prior to being pushed upstream.


I'm quite +1 on what John is saying. There was a time when there was
great uncertainty about the future of the Android patches, but since
Linus' comment last year it's become dead certain that the functionality
/will/ be merged upstream. We can pave the way by getting any
integration issues sorted out early -- similarly to what we do for
practically everything else in linux-linaro.


Hm I just said we should audit it for being dependent on CONFIG_ANDROID.

If we KNOW that deconfiguration of CONFIG_ANDROID is equivalent to not 
having Androidization patched in, people will stop wanting to get rid of 
the patches.  But since Google's interest is in the case it is 
configured, I doubt they took care about having it disabled well.


For other configurable features in the mainline kernel, part of the deal 
of getting in there is that they can be turned off nicely.  There's even 
a wholesale CONFIG_PM.  But the remaining (200 or so last time I looked) 
Androidization patches haven't been through that kind of scrutiny by 
anyone.  Again last time I looked they fiddled with a fair amount of 
kernel guts, sometimes with additional config coverage but not always.


Initially we added without discrimination that 7 year old patch that 
turns dmesg into junk to llct because it came in with Google's 
Androidization series.  It suggests we're just shovelling them on 
without any plan at the moment.


If we're claiming we are converging these patches to upstream, "working 
out integration issues" then we should be auditing them for being 
properly dependent on CONFIG_ANDROID before adding them to the same 
basis used for vanilla consumers.


-Andy

--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 12.05 linux-linaro kernel tree

[Andy Green]

On 22/05/12 04:02, Somebody in the thread at some point said:

On Thu, May 10, 2012 at 10:43 PM, Andy Green  wrote:

On 11/05/12 08:27, Somebody in the thread at some point said:


  4. in between RCs, we only move mainline on our linux-linaro release
baseline forward if we see a working tracking build that wouldn't drop
any topics that already made it into this RC cycle.



The probability of getting a good unified tree follows the kernel cycle, we
all have good reasons to have tried to arrive at a good, working, release.
  Sometimes we only get a reasonably good result a week or two after Linus'
release.

For that reason maybe you should just be trying to 'release' a release-basis
unified tree, ie, the 3.4 one targeted now as the deliverable.  It still has
meaning to make a monthly release of that since it can collect stable
mainline updates and updates from each LT release tree that happened in the
meanwhile.

We do need to create these intermediate unified trees so we know what to fix
on our trees so they can go in smoothly, but it matters less then if one day
half the LT trees are missing on it since it's of interest only for LTs and
platform guys to study what else needs solving on the LT trees.

I still think you won't get anywhere useful until we are trying to build the
unified trees for real.  Then we can start the needed work to make them fit
together properly, until then we're treading water in "technical debt".
  Discussing how to run the tree is something to do later after gaining this
experience.

I had a look at the LT gits

ARMMerge-managed  integration-linux-vexpress 3.4-rc4
TI Rebase-managed tilt-tracking  3.4-rc4
Freescale  Merge-managed  lt-3.4 3.4-rc3
SamsungRebase-managed tracking   3.4-rc3
STEMerge-managed  integration-linux-ux5003.4-rc6

(wow STE - on igloocommunity.org - have a LOT of patches!  I thought we were
leading the way)

Actually locally TILT are on -rc6 but there was almost no conflict coming
between -rc4 and -rc6.  If you take the approach to merge these trees, I
found that late in the cycle it's usually pretty forgiving about some
variation in basis.

So why not give these all a test merge today and see what starts falling
out?  I am sure we all have something to fix and there may be larger issues
like two trees with conflicting versions of, I dunno, Mali driver, that
needs planning to resolve.  Or if people aren't using
linux-linaro-core-tracking to get their CMA and so on, we need to know and
start that migration.


So, if I understood correctly, the llct would be the branch used to
actually start producing a valuable path to get the unified tree in
place.


Exactly.


As you said, it seems we should start trying to experiment merging
everything together and deciding what can actually be moved or not to
the core-tracking branch. This way we'd probably move to the direction
of having one real unified tree, instead of just maintaining
linux-linaro over the time.


Right.


So these are the useful branches I believe we'd end up having:
- Linux Linaro Core Tracking: main tree used to develop the common
changes across the different LTs/WGs and board flavours


Yes.  This is already doing good stuff for us, we can carefully add more 
things here to give everyone an easy ride and eliminate desynchronized 
duplication between the trees.



- Linux Linaro: tree with llct that is stabilised between rc releases,
that's part of the LEB releases. This tree would also have additional
topics from the LTs and WGs, in case they want to release it all into
one single tree (releasing together with Linux Linaro is useful in a
way we'll share QA and also helping identifying what other
improvements might be needed in case of conflicts)
- Linux Linaro Tracking/Unified: a tree that could contain llct + all
the sauce maintained by all the LTs, to be used just for testing to
help understanding what should be shared between LTs and be moved to
core-tracking. This would help us getting to a position where we could
identify early what are the conflicts, and work on getting a common
solution with core-tracking before actually starting to send upstream.

Would this fit your needs?


I think you can forget the last two and just take care about llct.  For 
a while I imagined there was just something I wasn't getting about this 
new llt scheme but now I believe it's simply unworkable and not thought 
through.



If you imagine just a little bit ahead of where we are today, with all 
LT on same or similar llct basis on any particular day, actually Andrey 
can imagine to wake up one morning and casually try to merge two or more 
LT trees and see what happens.  They're on same basis, we moved most or 
eventually all duplicated content to a canonical version coming from 
llct... most of the thorns are removed from the path.


He will find:

 1) merge conflicts... two or more trees both changed same code. 

Re: android-3.4 or android-3.4-compat

[Ricardo Salveti]

On Tue, May 22, 2012 at 1:21 AM, Andy Green  wrote:
> On 22/05/12 01:58, Somebody in the thread at some point said:
>> On Mon, May 21, 2012 at 10:33:47AM -0700, John Stultz wrote:
 like Andy, I am a bit concerned that we merge the android stuff
 into the linaro-core and that we get android candies in 'vanilla'
 kernel. can't we (shouldn't we) have -android on top of -core and
 pull -android only into 'android' kernel? it's true that for most
 things, -android is not impacting a 'vanilla' kernel, but clearly
>>>
>>> >from the outside (community *and* customers) a kernel 'tainted'

 with Android is not a 'vanilla' kernel anymore...
>>>
>>> So this re-opens the discussion we've been having since at least
>>> last Oct in moving to a consolidated kernel.
>>>
>>> Since Android upstreaming is an very active goal of Linaro,  I think
>>> there's strong technical value in putting the Android patches in
>>> along with all the other Linaro trees, as it allows us to work out
>>> any sort of incompatibilities or issues, so we can resolve them
>>> prior to being pushed upstream.
>>
>>
>> I'm quite +1 on what John is saying. There was a time when there was
>> great uncertainty about the future of the Android patches, but since
>> Linus' comment last year it's become dead certain that the functionality
>> /will/ be merged upstream. We can pave the way by getting any
>> integration issues sorted out early -- similarly to what we do for
>> practically everything else in linux-linaro.
>
> Hm I just said we should audit it for being dependent on CONFIG_ANDROID.
>
> If we KNOW that deconfiguration of CONFIG_ANDROID is equivalent to not
> having Androidization patched in, people will stop wanting to get rid of the
> patches.  But since Google's interest is in the case it is configured, I
> doubt they took care about having it disabled well.
>
> For other configurable features in the mainline kernel, part of the deal of
> getting in there is that they can be turned off nicely.  There's even a
> wholesale CONFIG_PM.  But the remaining (200 or so last time I looked)
> Androidization patches haven't been through that kind of scrutiny by anyone.
>  Again last time I looked they fiddled with a fair amount of kernel guts,
> sometimes with additional config coverage but not always.
>
> Initially we added without discrimination that 7 year old patch that turns
> dmesg into junk to llct because it came in with Google's Androidization
> series.  It suggests we're just shovelling them on without any plan at the
> moment.
>
> If we're claiming we are converging these patches to upstream, "working out
> integration issues" then we should be auditing them for being properly
> dependent on CONFIG_ANDROID before adding them to the same basis used for
> vanilla consumers.

It makes sense, and I also agree that we should only have
Androidization related patches at core if they can be properly
switched off by a config. This is probably a requirement for upstream
anyway, so I don't see as an issue on our side.

The rest of the patches could be part of linux-linaro, like we have
for the other LTs. That would help already identifying what are the
remaining issues for an unified tree and also getting the enablement
for all the LTs that are part of linux-linaro.

Here the core-tracking branch should be used just for common and stuff
that has a good change of hitting upstream. If you still need more
clean-up work, then merging it at linux-linaro would be the way to go.

Cheers,
-- 
Ricardo Salveti de Araujo

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Optimized kernel memcpy/memset

[jackiele]

Hi there,

I would like to do the same things with you guys in my devkit8000 board and see 
the performance. But since the kernel does not support NEON by default, how can 
we enable that SIMD? Could someone give me a point to figure out?




___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 12.05 linux-linaro kernel tree

[Deepti Kalakeri]

On Thu, May 17, 2012 at 8:29 PM, Andrey Konovalov <
andrey.konova...@linaro.org> wrote:

> On 05/17/2012 06:40 PM, Andy Green wrote:
>
>> On 17/05/12 17:41, Somebody in the thread at some point said:
>>
>>> On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote:
>>>
 Greetings,

 So far I wasn't updating the linux-linaro tree since the 12.04 release.
 (The generic topic updates were being done to the
 linux-linaro-core-tracking tree)

 Now it is time to move the focus to the linux-linaro tree. For one week
 it will use the mainline tip as the base.

>>>
>>> What happened to this?
>>>
>>
> I had some minor conflicts and build failures, so kept the updated tree
> locally for a while.
>
>
>  linux-linaro hasn't changed for 4 weeks now, so our vexpress 'tracking'
>>> builds of Android and Ubuntu are in fact the same kernels as the 12.04
>>> release.
>>>
>>
>> It doesn't matter as long as llct is moving - and it has been, Andrey is
>> doing a really nice job. If we can get all the LTs to base on llct, and
>> get all the important things standardized in llct, then everything will
>> come right.
>>
>
> Actually, it (not moving linux-linaro forward for too long) was my fault..
> Have pushed to the linux-linaro some time ago (no Samsung LT topics added
> yet).
> BTW, for llct I've added the linux-linaro-core-tracking-v3.**4-rc7 tag
> just in case the v3.4-rc7 tree is needed. As llct tip has moved beyond
> v3.4-rc7.
>
>
>  Nobody cares that we glued a couple dozen patches from ARM LT on one
>> other LT tree as a one-off.
>>
>
> linux-linaro tree is used by some CI jobs. To have the 12.05 stuff being
> tested in LAVA and such, I should have updated the linux-linaro tree as
> early as possible.
>

Should we stop to build linux-linaro and switch to llct or continue to
build linux-linaro and include llct builds as well?

>
> Thanks,
> Andrey
>
>
> __**_
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/**mailman/listinfo/linaro-dev
>



-- 
Thanks and Regards,
Deepti
Infrastructure Team Member, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev