[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is
-1- Force clkdm to SW_WKUP
-2- Configure desired module mode to "enable" or "auto"
-3- Wait for the desired module idle status to be FUNC
-4- Program clkdm in HW_AUTO(if supported)

This sequence applies to all older OMAPs' as well,
however since they use autodeps, it makes sure that
no clkdm is in IDLE, and hence not requiring a force
SW_WKUP when a module is being enabled.

OMAP4 does not need to support autodeps, because
of the dyanamic dependency feature, wherein
the HW takes care of waking up a clockdomain from
idle and hence the module, whenever an interconnect
access happens to the given module.
Autodeps were mainly needed on older OMAPs' as
this was not the case back then, and a module
access with the module/clkdm in idle would cause
an abort.

Fix the clkdm_clk_enable api to handle
this sequence on OMAP4.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
The patch is based on 'integration-2.6.39' branch
of git://git.pwsan.com/linux-integration because
of dependencies with other patches in the branch.

 arch/arm/mach-omap2/clock.c           |    4 ++++
 arch/arm/mach-omap2/clockdomain.c     |    7 ++++++-
 arch/arm/mach-omap2/clockdomain44xx.c |    9 ++-------
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 46d03cc..1cf6786 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -322,6 +322,10 @@ int omap2_clk_enable(struct clk *clk)
 		}
 	}
 
+	/* If clockdomain supports hardware control, enable it */
+	if (clk->clkdm)
+		clkdm_allow_idle(clk->clkdm);
+
 	return 0;
 
 oce_err3:
diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
index a0341de..9e1164f 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -825,7 +825,12 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
 	if (!arch_clkdm || !arch_clkdm->clkdm_clk_enable)
 		return -EINVAL;
 
-	if (atomic_inc_return(&clkdm->usecount) > 1)
+	/*
+	 * For arch's with no autodeps, clkcm_clk_enable
+	 * should be called for every clock instance that is
+	 * enabled, so the clkdm can be force woken up.
+	 */
+	if ((atomic_inc_return(&clkdm->usecount) > 1) && autodeps)
 		return 0;
 
 	/* Clockdomain now has one enabled downstream clock */
diff --git a/arch/arm/mach-omap2/clockdomain44xx.c b/arch/arm/mach-omap2/clockdomain44xx.c
index a1a4ecd..6f38d47 100644
--- a/arch/arm/mach-omap2/clockdomain44xx.c
+++ b/arch/arm/mach-omap2/clockdomain44xx.c
@@ -95,13 +95,8 @@ static void omap4_clkdm_deny_idle(struct clockdomain *clkdm)
 
 static int omap4_clkdm_clk_enable(struct clockdomain *clkdm)
 {
-	bool hwsup = false;
-
-	hwsup = omap4_cminst_is_clkdm_in_hwsup(clkdm->prcm_partition,
-					clkdm->cm_inst, clkdm->clkdm_offs);
-
-	if (!hwsup)
-		clkdm_wakeup(clkdm);
+	/* For every clock enable, force wakeup the clkdm */
+	clkdm_wakeup(clkdm);
 
 	return 0;
 }
-- 
1.7.0.4

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

Hi Rajendra,

A few questions...

On Fri, 4 Mar 2011, Rajendra Nayak wrote:

> On OMAP4, the PRCM recommended sequence for enabling
> a module after power-on-reset is
> -1- Force clkdm to SW_WKUP
> -2- Configure desired module mode to "enable" or "auto"
> -3- Wait for the desired module idle status to be FUNC
> -4- Program clkdm in HW_AUTO(if supported)
> 
> This sequence applies to all older OMAPs' as well,
> however since they use autodeps, it makes sure that
> no clkdm is in IDLE, and hence not requiring a force
> SW_WKUP when a module is being enabled.
> 
> OMAP4 does not need to support autodeps, because
> of the dyanamic dependency feature, wherein
> the HW takes care of waking up a clockdomain from
> idle and hence the module, whenever an interconnect
> access happens to the given module.
> Autodeps were mainly needed on older OMAPs' as
> this was not the case back then, and a module
> access with the module/clkdm in idle would cause
> an abort.

Hmmm.  For OMAP3, I was under the impression that the PRCM would request 
that a target module exit idle via SIdleReq when the module's main 
functional clock was enabled.  (Assuming that the interface clock was 
enabled and in auto-idle.)  We would see this happen in the clock code by 
waiting for the CM_IDLEST* bits to change -- apparently these represented 
SIdleReq signals.

The PRCM would wake up the module's functional and interface clockdomains 
if they were in hardware-supervised mode and INACTIVE.  Then the module 
would exit idle and signal the PRCM via SIdleAck.

Then the processor could read and write module registers, etc.

Later, when the processor was finished, it would disable the module's main 
functional clock.  The PRCM would request the module to go idle via 
SIdleReq.  If the module's internal state allowed it to go idle, it would 
do so and use its SIdleAck signal to notify the PRCM.  The PRCM could then 
allow the clockdomains to go INACTIVE if the clocks were not needed.

Is this theory of operation correct?  If so, then it would seem that as 
long as a module's interface clock and main functional clock are enabled, 
module accesses should succeed, with no abort.

On the other hand, reading the 34xx TRM Rev. ZH section 4.12.2.4.6 
"CM_CLKSTCTRL_ <domain name> (Clock State Control Register)", it appears 
that some clockdomains don't take target module idle states into account.  
For example, DSS and USBHOST both contain target modules, but the 
paragraphs on DSS and USBHOST don't mention target module idle states at 
all.  (This section also does not mention SGX or CAM for some reason.)  
Do these clockdomains disregard target idle states when determining 
whether to go INACTIVE?  If so, that would certainly create a need 
to add a sleep dependency whenever a processor wished to access a module.

Or is some other phenomenon happening?

> Fix the clkdm_clk_enable api to handle
> this sequence on OMAP4.

In terms of triage, does this patch fix something that currently doesn't 
work (meaning that we should try to merge it for 2.6.39)?  Or can we plan 
to merge this during the 2.6.40 time frame?  It would be ideal, of course, 
if we could wait until 2.6.40, given how close we are to the merge window 
opening.

> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> The patch is based on 'integration-2.6.39' branch
> of git://git.pwsan.com/linux-integration because
> of dependencies with other patches in the branch.
> 
>  arch/arm/mach-omap2/clock.c           |    4 ++++
>  arch/arm/mach-omap2/clockdomain.c     |    7 ++++++-
>  arch/arm/mach-omap2/clockdomain44xx.c |    9 ++-------
>  3 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index 46d03cc..1cf6786 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -322,6 +322,10 @@ int omap2_clk_enable(struct clk *clk)
>  		}
>  	}
>  
> +	/* If clockdomain supports hardware control, enable it */
> +	if (clk->clkdm)
> +		clkdm_allow_idle(clk->clkdm);
> +
>  	return 0;
>  
>  oce_err3:
> diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
> index a0341de..9e1164f 100644
> --- a/arch/arm/mach-omap2/clockdomain.c
> +++ b/arch/arm/mach-omap2/clockdomain.c
> @@ -825,7 +825,12 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
>  	if (!arch_clkdm || !arch_clkdm->clkdm_clk_enable)
>  		return -EINVAL;
>  
> -	if (atomic_inc_return(&clkdm->usecount) > 1)
> +	/*
> +	 * For arch's with no autodeps, clkcm_clk_enable
> +	 * should be called for every clock instance that is
> +	 * enabled, so the clkdm can be force woken up.
> +	 */
> +	if ((atomic_inc_return(&clkdm->usecount) > 1) && autodeps)
>  		return 0;
>  
>  	/* Clockdomain now has one enabled downstream clock */
> diff --git a/arch/arm/mach-omap2/clockdomain44xx.c b/arch/arm/mach-omap2/clockdomain44xx.c
> index a1a4ecd..6f38d47 100644
> --- a/arch/arm/mach-omap2/clockdomain44xx.c
> +++ b/arch/arm/mach-omap2/clockdomain44xx.c
> @@ -95,13 +95,8 @@ static void omap4_clkdm_deny_idle(struct clockdomain *clkdm)
>  
>  static int omap4_clkdm_clk_enable(struct clockdomain *clkdm)
>  {
> -	bool hwsup = false;
> -
> -	hwsup = omap4_cminst_is_clkdm_in_hwsup(clkdm->prcm_partition,
> -					clkdm->cm_inst, clkdm->clkdm_offs);
> -
> -	if (!hwsup)
> -		clkdm_wakeup(clkdm);
> +	/* For every clock enable, force wakeup the clkdm */
> +	clkdm_wakeup(clkdm);
>  
>  	return 0;
>  }
> -- 
> 1.7.0.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


- Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

Hi Paul,

On Wednesday 09 March 2011 09:20 AM, Paul Walmsley wrote:
> Hi Rajendra,
>
> A few questions...
>
> On Fri, 4 Mar 2011, Rajendra Nayak wrote:
>
>> On OMAP4, the PRCM recommended sequence for enabling
>> a module after power-on-reset is
>> -1- Force clkdm to SW_WKUP
>> -2- Configure desired module mode to "enable" or "auto"
>> -3- Wait for the desired module idle status to be FUNC
>> -4- Program clkdm in HW_AUTO(if supported)
>>
>> This sequence applies to all older OMAPs' as well,
>> however since they use autodeps, it makes sure that
>> no clkdm is in IDLE, and hence not requiring a force
>> SW_WKUP when a module is being enabled.
>>
>> OMAP4 does not need to support autodeps, because
>> of the dyanamic dependency feature, wherein
>> the HW takes care of waking up a clockdomain from
>> idle and hence the module, whenever an interconnect
>> access happens to the given module.
>> Autodeps were mainly needed on older OMAPs' as
>> this was not the case back then, and a module
>> access with the module/clkdm in idle would cause
>> an abort.
>
> Hmmm.  For OMAP3, I was under the impression that the PRCM would request
> that a target module exit idle via SIdleReq when the module's main
> functional clock was enabled.  (Assuming that the interface clock was
> enabled and in auto-idle.)  We would see this happen in the clock code by
> waiting for the CM_IDLEST* bits to change -- apparently these represented
> SIdleReq signals.
>
> The PRCM would wake up the module's functional and interface clockdomains
> if they were in hardware-supervised mode and INACTIVE.  Then the module
> would exit idle and signal the PRCM via SIdleAck.

PRCM waking up the module's clockdomains when in hardware-supervised
and INACTIVE, atleast does not seem to be true for OMAP4 and does seem
to be documented atleast in the func specs (need to see if its
in TRM, else I will raise a request to include it) Chapter 11 to 23,
Section Chapter#.5.2.1: Enabling one <clockdomain name> module after
power-on-reset.
This seems to suggest that the clockdomains have to be force woken-up
using SW_WKUP, and can then be programmed in HW_AUTO once the module
is accessible.
 From what I know this was true on OMAP3 as well and maybe on OMAP2,
and thinking of why we might not have seen any issues with them, I
realized, because of the autodeps of all clockdomains with MPU, they
would never be in INACTIVE while a module is being enabled, even if
the clockdomain was in HW_AUTO.


>
> Then the processor could read and write module registers, etc.
>
> Later, when the processor was finished, it would disable the module's main
> functional clock.  The PRCM would request the module to go idle via
> SIdleReq.  If the module's internal state allowed it to go idle, it would
> do so and use its SIdleAck signal to notify the PRCM.  The PRCM could then
> allow the clockdomains to go INACTIVE if the clocks were not needed.
>
> Is this theory of operation correct?  If so, then it would seem that as
> long as a module's interface clock and main functional clock are enabled,
> module accesses should succeed, with no abort.
>
> On the other hand, reading the 34xx TRM Rev. ZH section 4.12.2.4.6
> "CM_CLKSTCTRL_<domain name>  (Clock State Control Register)", it appears
> that some clockdomains don't take target module idle states into account.
> For example, DSS and USBHOST both contain target modules, but the
> paragraphs on DSS and USBHOST don't mention target module idle states at
> all.  (This section also does not mention SGX or CAM for some reason.)
> Do these clockdomains disregard target idle states when determining
> whether to go INACTIVE?  If so, that would certainly create a need
> to add a sleep dependency whenever a processor wished to access a module.

hmm.. I am not sure if this is a TRM bug, but FWIK, no clockdomains
should go to INACTIVE without taking into account the target idle
state. All targets should be sent a idlereq and only on a idleack from
all of them, should the clockdomain transition to INACTIVE. If the
clockdomain hits INACTIVE just based on its initiators asserting
standby, it does not seem right.

Btw, the patch does not change the behaviour/sequence followed on OMAP3,
it just affects OMAP4.

>
> Or is some other phenomenon happening?
>
>> Fix the clkdm_clk_enable api to handle
>> this sequence on OMAP4.
>
> In terms of triage, does this patch fix something that currently doesn't
> work (meaning that we should try to merge it for 2.6.39)?  Or can we plan
> to merge this during the 2.6.40 time frame?  It would be ideal, of course,
> if we could wait until 2.6.40, given how close we are to the merge window
> opening.

Since no clockdomains on OMAP4 were programmed in HW_AUTO untill now,
we did not have any issues, but with the recent series from Santosh
(which adds mpu ret/off support in idle/suspend) programming the
clockdomains to HW_AUTO did show issues/aborts, and this patch
fixes them.

regards,
Rajendra

>
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>> The patch is based on 'integration-2.6.39' branch
>> of git://git.pwsan.com/linux-integration because
>> of dependencies with other patches in the branch.
>>
>>   arch/arm/mach-omap2/clock.c           |    4 ++++
>>   arch/arm/mach-omap2/clockdomain.c     |    7 ++++++-
>>   arch/arm/mach-omap2/clockdomain44xx.c |    9 ++-------
>>   3 files changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
>> index 46d03cc..1cf6786 100644
>> --- a/arch/arm/mach-omap2/clock.c
>> +++ b/arch/arm/mach-omap2/clock.c
>> @@ -322,6 +322,10 @@ int omap2_clk_enable(struct clk *clk)
>>   		}
>>   	}
>>
>> +	/* If clockdomain supports hardware control, enable it */
>> +	if (clk->clkdm)
>> +		clkdm_allow_idle(clk->clkdm);
>> +
>>   	return 0;
>>
>>   oce_err3:
>> diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
>> index a0341de..9e1164f 100644
>> --- a/arch/arm/mach-omap2/clockdomain.c
>> +++ b/arch/arm/mach-omap2/clockdomain.c
>> @@ -825,7 +825,12 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
>>   	if (!arch_clkdm || !arch_clkdm->clkdm_clk_enable)
>>   		return -EINVAL;
>>
>> -	if (atomic_inc_return(&clkdm->usecount)>  1)
>> +	/*
>> +	 * For arch's with no autodeps, clkcm_clk_enable
>> +	 * should be called for every clock instance that is
>> +	 * enabled, so the clkdm can be force woken up.
>> +	 */
>> +	if ((atomic_inc_return(&clkdm->usecount)>  1)&&  autodeps)
>>   		return 0;
>>
>>   	/* Clockdomain now has one enabled downstream clock */
>> diff --git a/arch/arm/mach-omap2/clockdomain44xx.c b/arch/arm/mach-omap2/clockdomain44xx.c
>> index a1a4ecd..6f38d47 100644
>> --- a/arch/arm/mach-omap2/clockdomain44xx.c
>> +++ b/arch/arm/mach-omap2/clockdomain44xx.c
>> @@ -95,13 +95,8 @@ static void omap4_clkdm_deny_idle(struct clockdomain *clkdm)
>>
>>   static int omap4_clkdm_clk_enable(struct clockdomain *clkdm)
>>   {
>> -	bool hwsup = false;
>> -
>> -	hwsup = omap4_cminst_is_clkdm_in_hwsup(clkdm->prcm_partition,
>> -					clkdm->cm_inst, clkdm->clkdm_offs);
>> -
>> -	if (!hwsup)
>> -		clkdm_wakeup(clkdm);
>> +	/* For every clock enable, force wakeup the clkdm */
>> +	clkdm_wakeup(clkdm);
>>
>>   	return 0;
>>   }
>> --
>> 1.7.0.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>
> - Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Kevin Hilman]

Rajendra Nayak <rnayak@ti.com> writes:

>> In terms of triage, does this patch fix something that currently doesn't
>> work (meaning that we should try to merge it for 2.6.39)?  Or can we plan
>> to merge this during the 2.6.40 time frame?  It would be ideal, of course,
>> if we could wait until 2.6.40, given how close we are to the merge window
>> opening.
>
> Since no clockdomains on OMAP4 were programmed in HW_AUTO untill now,
> we did not have any issues, but with the recent series from Santosh
> (which adds mpu ret/off support in idle/suspend) programming the
> clockdomains to HW_AUTO did show issues/aborts, and this patch
> fixes them.

FWIW, I was planning to merge the OMAP4 MPU ret/off series from Santosh
for 2.6.39, so this patch would be required for that to series to work.

Kevin

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

(cc'ing Tero also)

Hi Rajendra

On Wed, 9 Mar 2011, Rajendra Nayak wrote:

> On Wednesday 09 March 2011 09:20 AM, Paul Walmsley wrote:
> > On Fri, 4 Mar 2011, Rajendra Nayak wrote:
> 
> PRCM waking up the module's clockdomains when in hardware-supervised
> and INACTIVE, atleast does not seem to be true for OMAP4 and does seem
> to be documented atleast in the func specs (need to see if its
> in TRM, else I will raise a request to include it) Chapter 11 to 23,
> Section Chapter#.5.2.1: Enabling one <clockdomain name> module after
> power-on-reset.
> This seems to suggest that the clockdomains have to be force woken-up
> using SW_WKUP, and can then be programmed in HW_AUTO once the module
> is accessible.
> From what I know this was true on OMAP3 as well and maybe on OMAP2,
> and thinking of why we might not have seen any issues with them, I
> realized, because of the autodeps of all clockdomains with MPU, they
> would never be in INACTIVE while a module is being enabled, even if
> the clockdomain was in HW_AUTO.

OK, maybe this is why the autodeps were needed, because otherwise we would 
need to wake the clockdomain up before enabling the clocks.  Something to 
experiment with for 2.6.40.

> hmm.. I am not sure if this is a TRM bug, but FWIK, no clockdomains
> should go to INACTIVE without taking into account the target idle
> state. All targets should be sent a idlereq and only on a idleack from
> all of them, should the clockdomain transition to INACTIVE. If the
> clockdomain hits INACTIVE just based on its initiators asserting
> standby, it does not seem right.

Ok, probably just a TRM bug then.  Guess we'll find out when we start 
removing the autodeps...

> Btw, the patch does not change the behaviour/sequence followed on OMAP3,
> it just affects OMAP4.

Until the autodeps get removed :-)

> Since no clockdomains on OMAP4 were programmed in HW_AUTO untill now,
> we did not have any issues, but with the recent series from Santosh
> (which adds mpu ret/off support in idle/suspend) programming the
> clockdomains to HW_AUTO did show issues/aborts, and this patch
> fixes them.

Okay, I'll queue this for 2.6.39.

Thanks for thinking through the module enable sequence with me,


- Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

Hi Rajendra,

On Wed, 9 Mar 2011, Rajendra Nayak wrote:

> On Wednesday 09 March 2011 09:20 AM, Paul Walmsley wrote:
> > On Fri, 4 Mar 2011, Rajendra Nayak wrote:
> > 
> > > On OMAP4, the PRCM recommended sequence for enabling
> > > a module after power-on-reset is
> > > -1- Force clkdm to SW_WKUP
> > > -2- Configure desired module mode to "enable" or "auto"
> > > -3- Wait for the desired module idle status to be FUNC
> > > -4- Program clkdm in HW_AUTO(if supported)
> > > 
> > > This sequence applies to all older OMAPs' as well,
> > > however since they use autodeps, it makes sure that
> > > no clkdm is in IDLE, and hence not requiring a force
> > > SW_WKUP when a module is being enabled.

This patch is currently breaking boot on OMAP4430 ES2.0 Pandaboard,
so I've dropped it from the integration branch until it can be
debugged.  Could you check it, please?

The tag "integration-2.6.39-20110310-008" of
git://git.pwsan.com/linux-integration boots fine; it's got everything
but this patch.  Then when this patch is applied, I2C problems show
up, and root (on MMC) doesn't mount.


- Paul


Uncompressing Linux... done, booting the kernel.
[    0.000000] Linux version 2.6.38-rc7-00238-g3dfe14f (paul at twilight) (gcc version 4.5.1 (Sourcery G1
[    0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: OMAP4 Panda board
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] OMAP4430 ES2.0
[    0.000000] SRAM: Mapped pa 0x40300000 to va 0xfe400000 size: 0xe000
[    0.000000] PERCPU: Embedded 7 pages/cpu @c0efa000 s8032 r8192 d12448 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 117602
[    0.000000] Kernel command line: root=/dev/mmcblk0p2 ro rootwait mem=463M console=ttyO2,115200n8 ik
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 463MB = 463MB total
[    0.000000] Memory: 458320k/458320k available, 15792k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
[    0.000000]     vmalloc : 0xdd000000 - 0xf8000000   ( 432 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xdcf00000   ( 463 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .init : 0xc0008000 - 0xc0050000   ( 288 kB)
[    0.000000]       .text : 0xc0050000 - 0xc05812c4   (5317 kB)
[    0.000000]       .data : 0xc0582000 - 0xc05fa2e0   ( 481 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU-based detection of stalled CPUs is disabled.
[    0.000000] NR_IRQS:409
[    0.000000] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
[    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.001098] Calibrating delay loop... 2009.29 BogoMIPS (lpj=7847936)
[    0.171905] pid_max: default: 32768 minimum: 301
[    0.172760] Security Framework initialized
[    0.172760] Mount-cache hash table entries: 512
[    0.172760] CPU: Testing write buffer coherency: ok
[    0.179107] L310 cache controller enabled
[    0.179107] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, Cache size: 1048576 B
[    0.181701] CPU1: Booted secondary processor
[    0.182434] CPU1: Unknown IPI message 0x1
[    0.374694] Brought up 2 CPUs
[    0.374755] SMP: Total of 2 processors activated (4022.78 BogoMIPS).
[    0.382324] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for emif_fw
[    0.382324] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l3_instr
[    0.382324] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l3_main_1
[    0.384887] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l3_main_2
[    0.384887] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_abe
[    0.384887] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_cfg
[    0.384948] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per
[    0.384948] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup
[    0.384979] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for mpu_private
[   10.694824] omap_i2c omap_i2c.1: controller timed out
[   10.710449] twl: i2c_write failed to transfer all messages
[   10.711578] print_constraints: VCXIO: 1800 mV normal standby
[   11.710449] omap_i2c omap_i2c.1: controller timed out
[   11.726074] twl: i2c_write failed to transfer all messages
[   11.727416] print_constraints: VDAC: 1800 mV normal standby
[   12.726074] omap_i2c omap_i2c.1: controller timed out
[   12.741699] twl: i2c_write failed to transfer all messages
[   13.741699] omap_i2c omap_i2c.1: controller timed out
[   13.757324] twl: i2c_read failed to transfer all messages
[   13.757324] print_constraints: VAUX1_6030: 1000 <--> 3000 mV normal standby
[   14.757324] omap_i2c omap_i2c.1: controller timed out
[   14.772949] twl: i2c_write failed to transfer all messages
[   15.772949] omap_i2c omap_i2c.1: controller timed out
[   15.788574] twl: i2c_read failed to transfer all messages
[   15.788635] print_constraints: VAUX2_6030: 1200 <--> 2800 mV normal standby
[   16.788574] omap_i2c omap_i2c.1: controller timed out
[   16.804199] twl: i2c_write failed to transfer all messages
[   17.804199] omap_i2c omap_i2c.1: contrre: registered new interface driver cdc_subset
[   20.744201] usbcore: registered new interface driver zaurus
[   20.750091] cdc_ncm: 7-Feb-2011
[   20.753692] usbcore: registered new interface driver cdc_ncm
[   20.760955] usbcore: registered new interface driver cdc_wdm
[   20.766937] Initializing USB Mass Storage driver...
[   20.772399] usbcore: registered new interface driver usb-storage
[   20.778747] USB Mass Storage support registered.
[   20.784332] usbcore: registered new interface driver libusual
[   20.790740] usbcore: registered new interface driver usbtest
[   20.796722] udc: OMAP UDC driver, version: 4 October 2004 (iso) (dma)
[   20.805206] mousedev: PS/2 mouse device common for all mice
[   20.814331] input: twl4030_pwrbutton as /devices/platform/omap/omap_i2c.1/i2c-1/1-0049/twl4030_pwr0
[   20.827728] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
[   20.834472] omap_device: omap_i2c.1: new worst case activate latency 0: 6744384
[   21.835449] omap_i2c omap_i2c.1: controller timed out
[   21.851074] twl: i2c_read failed to transfer all messages
[   21.856872] twl_rtc: Could not read TWLregister E - error -110
[   21.866058] twl_rtc: probe of twl_rtc failed with error -110
[   21.872314] i2cs, leaving on
[   28.336883] regulator_init_complete: VANA: incomplete constraints, leaving on
[   28.359039] regulator_init_complete: VUSIM: incomplete constraints, leaving on
[   29.366699] omap_i2c omap_i2c.1: controller timed out
[   29.382415] twl: i2c_read failed to transfer all messages
[   29.382415] regulator_init_complete: VPP: incomplete constraints, leaving on
[   30.390136] omap_i2c omap_i2c.1: controller timed out
[   30.405822] twl: i2c_read failed to transfer all messages
[   30.405822] regulator_init_complete: VMMC: incomplete constraints, leaving on
[   30.419006] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[   30.425689] Waiting for root device /dev/mmcblk0p2...

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

Hi Paul,

On Thursday 10 March 2011 05:48 PM, Paul Walmsley wrote:
> This patch is currently breaking boot on OMAP4430 ES2.0 Pandaboard,
> so I've dropped it from the integration branch until it can be
> debugged.  Could you check it, please?
>
> The tag "integration-2.6.39-20110310-008" of
> git://git.pwsan.com/linux-integration boots fine; it's got everything
> but this patch.  Then when this patch is applied, I2C problems show
> up, and root (on MMC) doesn't mount.

Looks like you are missing this patch which should fix the i2c
timeouts..
http://marc.info/?l=linux-omap&m=129924561819873&w=2

regards,
Rajendra

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

On Thu, 10 Mar 2011, Rajendra Nayak wrote:

> On Thursday 10 March 2011 05:48 PM, Paul Walmsley wrote:
> > This patch is currently breaking boot on OMAP4430 ES2.0 Pandaboard,
> > so I've dropped it from the integration branch until it can be
> > debugged.  Could you check it, please?
> > 
> > The tag "integration-2.6.39-20110310-008" of
> > git://git.pwsan.com/linux-integration boots fine; it's got everything
> > but this patch.  Then when this patch is applied, I2C problems show
> > up, and root (on MMC) doesn't mount.
> 
> Looks like you are missing this patch which should fix the i2c
> timeouts..
> http://marc.info/?l=linux-omap&m=129924561819873&w=2

Thanks, let's see if Ben is planning to merge it for 2.6.39.


- Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

Hi Ben,

On Thu, 10 Mar 2011, Rajendra Nayak wrote:

> On Thursday 10 March 2011 05:48 PM, Paul Walmsley wrote:
> > This patch is currently breaking boot on OMAP4430 ES2.0 Pandaboard,
> > so I've dropped it from the integration branch until it can be
> > debugged.  Could you check it, please?
> > 
> > The tag "integration-2.6.39-20110310-008" of
> > git://git.pwsan.com/linux-integration boots fine; it's got everything
> > but this patch.  Then when this patch is applied, I2C problems show
> > up, and root (on MMC) doesn't mount.
> 
> Looks like you are missing this patch which should fix the i2c
> timeouts..

Do you think you'll merge this patch:

   http://marc.info/?l=linux-omap&m=129924561819873&w=2

during the 2.6.39 window?  If so, then I'll add Rajendra's clockdomain 
patch back in to my 2.6.39 queue here; it seems to depend on the I2C 
driver patch.


- Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Ben Dooks]

On Thu, Mar 10, 2011 at 06:17:02AM -0700, Paul Walmsley wrote:
> Hi Ben,
> 
> On Thu, 10 Mar 2011, Rajendra Nayak wrote:
> 
> > On Thursday 10 March 2011 05:48 PM, Paul Walmsley wrote:
> > > This patch is currently breaking boot on OMAP4430 ES2.0 Pandaboard,
> > > so I've dropped it from the integration branch until it can be
> > > debugged.  Could you check it, please?
> > > 
> > > The tag "integration-2.6.39-20110310-008" of
> > > git://git.pwsan.com/linux-integration boots fine; it's got everything
> > > but this patch.  Then when this patch is applied, I2C problems show
> > > up, and root (on MMC) doesn't mount.
> > 
> > Looks like you are missing this patch which should fix the i2c
> > timeouts..
> 
> Do you think you'll merge this patch:
> 
>    http://marc.info/?l=linux-omap&m=129924561819873&w=2
> 
> during the 2.6.39 window?  If so, then I'll add Rajendra's clockdomain 
> patch back in to my 2.6.39 queue here; it seems to depend on the I2C 
> driver patch.

see
http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=shortlog;h=refs/heads/for-2639-rc7/i2c-fixes

awaiting linus.

> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

On Thu, 10 Mar 2011, Ben Dooks wrote:

> see
> http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=shortlog;h=refs/heads/for-2639-rc7/i2c-fixes
> 
> awaiting linus.

Thanks Ben.


- Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

On Thu, 10 Mar 2011, Paul Walmsley wrote:

> On Wed, 9 Mar 2011, Rajendra Nayak wrote:
> 
> > On Wednesday 09 March 2011 09:20 AM, Paul Walmsley wrote:
> > > On Fri, 4 Mar 2011, Rajendra Nayak wrote:
> > > 
> > > > On OMAP4, the PRCM recommended sequence for enabling
> > > > a module after power-on-reset is
> > > > -1- Force clkdm to SW_WKUP
> > > > -2- Configure desired module mode to "enable" or "auto"
> > > > -3- Wait for the desired module idle status to be FUNC
> > > > -4- Program clkdm in HW_AUTO(if supported)
> > > > 
> > > > This sequence applies to all older OMAPs' as well,
> > > > however since they use autodeps, it makes sure that
> > > > no clkdm is in IDLE, and hence not requiring a force
> > > > SW_WKUP when a module is being enabled.
> 
> This patch is currently breaking boot on OMAP4430 ES2.0 Pandaboard,
> so I've dropped it from the integration branch until it can be
> debugged.  Could you check it, please?

It's also breaking boot on OMAP35xx BeagleBoard rev C2.  The kernel 
boot messages are below - omap2plus_defconfig + DEBUG_LL.  Reverting
the patch fixes it.  Could you please take a look?


- Paul

Uncompressing Linux... done, booting the kernel.
[    0.000000] Linux version 2.6.38-rc7-00245-gccc0402 (paul at twilight) (gcc version 4.5.1 (Sourcery G1
[    0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: OMAP3 Beagle Board
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp )
[    0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000
[    0.000000] On node 0 totalpages: 65536
[    0.000000] free_area_init_node: node 0, pgdat c05faf20, node_mem_map c0b54000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65024 pages, LIFO batch:15
[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
[    0.000000] Reprogramming SDRC clock to 332000000 Hz
[    0.000000] PERCPU: Embedded 7 pages/cpu @c0d59000 s8032 r8192 d12448 u32768
[    0.000000] pcpu-alloc: s8032 r8192 d12448 u32768 alloc=8*4096
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
[    0.000000] Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 memk
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 256MB = 256MB total
[    0.000000] Memory: 248248k/248248k available, 13896k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
[    0.000000]     vmalloc : 0xd0800000 - 0xf8000000   ( 632 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .init : 0xc0008000 - 0xc0051000   ( 292 kB)
[    0.000000]       .text : 0xc0051000 - 0xc05832fc   (5321 kB)
[    0.000000]       .data : 0xc0584000 - 0xc05fc300   ( 481 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU-based detection of stalled CPUs is disabled.
[    0.000000] NR_IRQS:409
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
[    0.000000] Total of 96 interrupts on 1 active controller
[    0.000000] omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.
[    0.000000] OMAP clockevent source: GPTIMER12 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.057403] Calibrating delay loop... 476.81 BogoMIPS (lpj=1859584)
[    0.226165] pid_max: default: 32768 minimum: 301
[    0.231872] Security Framework initialized
[    0.236602] Mount-cache hash table entries: 512
[    0.246917] CPU: Testing write buffer coherency: ok
[    0.255737] Brought up 1 CPUs
[    0.258880] SMP: Total of 1 processors activated (476.81 BogoMIPS).
[    0.282135] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_core
[    0.289703] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per
[    0.297088] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup
[    0.321289] omap_hwmod: i2c1: softreset failed (waited 10000 usec)
[    0.341857] omap_hwmod: i2c2: softreset failed (waited 10000 usec)
[    0.362457] omap_hwmod: i2c3: softreset failed (waited 10000 usec)
[    0.376159] print_constraints: dummy: 
[    0.381896] NET: Registered protocol family 16
[    0.388214] GPMC revision 5.0
[    0.391510] Trying to install interrupt handler for IRQ402
[    0.397369] Trying to install interrupt handler for IRQ403
[    0.403167] Trying to install interrupt handler for IRQ404
[    0.408905] Trying to install interrupt handler for IRQ405
[    0.414703] Trying to install interrupt handler for IRQ406
[    0.420501] Trying to install interrupt handler for IRQ407
[    0.426330] Trying to install interrupt handler for IRQ408
[    0.432067] Trying to install type control for IRQ409
[    0.437408] Trying to set irq flags for IRQ409
[    0.451568] omap_device: omap_gpio.0: new worst case activate latency 0: 91552
[    0.460113] OMAP GPIO hardware version 2.5
[    0.465179] OMAP GPIO hardware version 2.5
[    0.470092] OMAP GPIO hardware version 2.5
[    0.474945] OMAP GPIO hardware version 2.5
[    0.479858] OMAP GPIO hardware version 2.5
[    0.484771] OMAP GPIO hardware version 2.5

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

Hi Paul,

On 3/10/2011 8:09 PM, Paul Walmsley wrote:
> On Thu, 10 Mar 2011, Paul Walmsley wrote:
>
>> On Wed, 9 Mar 2011, Rajendra Nayak wrote:
>>
>>> On Wednesday 09 March 2011 09:20 AM, Paul Walmsley wrote:
>>>> On Fri, 4 Mar 2011, Rajendra Nayak wrote:
>>>>
>>>>> On OMAP4, the PRCM recommended sequence for enabling
>>>>> a module after power-on-reset is
>>>>> -1- Force clkdm to SW_WKUP
>>>>> -2- Configure desired module mode to "enable" or "auto"
>>>>> -3- Wait for the desired module idle status to be FUNC
>>>>> -4- Program clkdm in HW_AUTO(if supported)
>>>>>
>>>>> This sequence applies to all older OMAPs' as well,
>>>>> however since they use autodeps, it makes sure that
>>>>> no clkdm is in IDLE, and hence not requiring a force
>>>>> SW_WKUP when a module is being enabled.
>>
>> This patch is currently breaking boot on OMAP4430 ES2.0 Pandaboard,
>> so I've dropped it from the integration branch until it can be
>> debugged.  Could you check it, please?
>
> It's also breaking boot on OMAP35xx BeagleBoard rev C2.  The kernel
> boot messages are below - omap2plus_defconfig + DEBUG_LL.  Reverting
> the patch fixes it.  Could you please take a look?

I got hold of a Beagle, a sticker on which says rev C1D.
Not sure if there is a better way to identify the rev, but
this one seems to boot fine for me even with this patch.
I just applied this one patch on top of the the tag
'integration-2.6.39-20110310-008' of git://git.pwsan.com/linux-
integration.

Would a board rev make a difference?

-------
Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Linux version 2.6.38-rc7-dirty (rnayak at a0131687pc) (gcc 
version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #10 SMP Fri Mar 11 
17:55:24 IST 2011
[    0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), 
cr=10c53c7f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache
[    0.000000] Machine: OMAP3 Beagle Board
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp )
[    0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000
[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
[    0.000000] Reprogramming SDRC clock to 332000000 Hz
[    0.000000] PERCPU: Embedded 7 pages/cpu @c0d59000 s8032 r8192 d12448 
u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on. 
Total pages: 65024
[    0.000000] Kernel command line: console=ttyO2,115200n8 
root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait rootflags=barrier=1 
earlyprintk init=/bin/sh
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 
bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 256MB = 256MB total
[    0.000000] Memory: 248248k/248248k available, 13896k reserved, 0K 
highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
[    0.000000]     vmalloc : 0xd0800000 - 0xf8000000   ( 632 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .init : 0xc0008000 - 0xc0051000   ( 292 kB)
[    0.000000]       .text : 0xc0051000 - 0xc05830dc   (5321 kB)
[    0.000000]       .data : 0xc0584000 - 0xc05fc420   ( 482 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU-based detection of stalled CPUs is disabled.
[    0.000000] NR_IRQS:409
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 
interrupts
[    0.000000] Total of 96 interrupts on 1 active controller
[    0.000000] omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.
[    0.000000] OMAP clockevent source: GPTIMER12 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps 
every 131071999ms
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, 
Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.057373] Calibrating delay loop... 488.41 BogoMIPS (lpj=1908736)
[    0.232391] pid_max: default: 32768 minimum: 301
[    0.238067] Security Framework initialized
[    0.242767] Mount-cache hash table entries: 512
[    0.253082] CPU: Testing write buffer coherency: ok
[    0.261932] Brought up 1 CPUs
[    0.265075] SMP: Total of 1 processors activated (488.41 BogoMIPS).
[    0.288421] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for 
l4_core
[    0.295989] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for 
l4_per
[    0.303375] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for 
l4_wkup
[    0.327484] omap_hwmod: i2c1: softreset failed (waited 10000 usec)
[    0.348358] omap_hwmod: i2c2: softreset failed (waited 10000 usec)
[    0.369201] omap_hwmod: i2c3: softreset failed (waited 10000 usec)
[    0.382751] print_constraints: dummy:
[    0.388580] NET: Registered protocol family 16
[    0.394805] GPMC revision 5.0
[    0.398101] Trying to install interrupt handler for IRQ402
[    0.404052] Trying to install interrupt handler for IRQ403
[    0.409851] Trying to install interrupt handler for IRQ404
[    0.415649] Trying to install interrupt handler for IRQ405
[    0.421447] Trying to install interrupt handler for IRQ406
[    0.427215] Trying to install interrupt handler for IRQ407
[    0.433044] Trying to install interrupt handler for IRQ408
[    0.438812] Trying to install type control for IRQ409
[    0.444122] Trying to set irq flags for IRQ409
[    0.458343] omap_device: omap_gpio.0: new worst case activate latency 
0: 122070
[    0.466979] OMAP GPIO hardware version 2.5
[    0.472015] OMAP GPIO hardware version 2.5
[    0.476959] OMAP GPIO hardware version 2.5
[    0.481811] OMAP GPIO hardware version 2.5
[    0.486755] OMAP GPIO hardware version 2.5
[    0.491668] OMAP GPIO hardware version 2.5
[    0.515655] omap_mux_init: Add partition: #1: core, flags: 0
[    0.525390] OMAP3 Beagle Rev: C1/C2/C3
[    0.534912] omap_device: omap_uart.0: new worst case activate latency 
0: 30517
[    0.546813] omap_device: omap_uart.2: new worst case deactivate 
latency 0: 30517
[    0.554901] Found NAND on CS0
[    0.558044] Registering NAND on CS0
[    0.563262] Unable to get DVI reset GPIO
[    0.567657] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.596466] OMAP DMA hardware revision 4.0
[    0.677093] bio: create slab <bio-0> at 0
[    0.693084] SCSI subsystem initialized
[    0.698181] omap_device: omap2_mcspi.1: new worst case activate 
latency 0: 30517
[    0.716827] usbcore: registered new interface driver usbfs
[    0.724304] usbcore: registered new interface driver hub
[    0.731079] usbcore: registered new device driver usb
[    0.739105] omap_device: omap_i2c.1: new worst case activate latency 
0: 61035
[    0.746948] omap_i2c omap_i2c.1: bus 1 rev3.12 at 2600 kHz
[    0.765686] twl4030: PIH (irq 7) chaining IRQs 368..375
[    0.771545] twl4030: power (irq 373) chaining IRQs 376..383
[    0.779876] twl4030: gpio (irq 368) chaining IRQs 384..401
[    0.801025] print_constraints: VMMC1: 1850 <--> 3150 mV at 3000 mV 
normal standby
[    0.812499] print_constraints: VDAC: 1800 mV normal standby
[    0.821655] print_constraints: VDVI: 1800 mV normal standby
[    0.831024] print_constraints: VSIM: 1800 <--> 3000 mV at 1800 mV 
normal standby
[    0.839874] omap_device: omap_i2c.1: new worst case deactivate 
latency 0: 30517
[    0.848022] omap_i2c omap_i2c.3: bus 3 rev3.12 at 100 kHz
[    0.867095] Switching to clocksource 32k_counter
[    0.873657] Switched to NOHz mode on CPU #0
[    1.019775] NET: Registered protocol family 2
[    1.025787] IP route cache hash table entries: 2048 (order: 1, 8192 
bytes)
[    1.035400] TCP established hash table entries: 8192 (order: 4, 65536 
bytes)
[    1.043457] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
[    1.056030] TCP: Hash tables configured (established 8192 bind 8192)
[    1.062835] TCP reno registered
[    1.066192] UDP hash table entries: 128 (order: 1, 10240 bytes)
[    1.072845] UDP-Lite hash table entries: 128 (order: 1, 10240 bytes)
[    1.080871] NET: Registered protocol family 1
[    1.087158] RPC: Registered udp transport module.
[    1.092468] RPC: Registered tcp transport module.
[    1.097412] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.105438] NetWinder Floating Point Emulator V0.97 (double precision)
[    1.320373] VFS: Disk quotas dquot_6.5.2
[    1.324951] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.334991] JFFS2 version 2.2. (NAND) (SUMMARY)  ? 2001-2006 Red Hat, 
Inc.
[    1.343444] msgmni has been set to 484
[    1.353393] io scheduler noop registered
[    1.357666] io scheduler deadline registered
[    1.362365] io scheduler cfq registered (default)
[    1.373229] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.389556] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a 
OMAP UART0
[    1.399383] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a 
OMAP UART1
[    1.408508] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a 
OMAP UART2
[    1.416625] console [ttyO2] enabled, bootconsole disabled
[    1.416625] console [ttyO2] enabled, bootconsole disabled
[    1.478668] brd: module loaded
[    1.506439] loop: module loaded
[    1.511108] omap_device: omap_i2c.1: new worst case activate latency 
0: 152587
[    1.529266] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.536132] omap2-nand driver initializing
[    1.541107] ONFI flash detected
[    1.544769] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron 
NAND 256MiB 1,8V 16-bit)
[    1.553955] Creating 5 MTD partitions on "omap2-nand.0":
[    1.559539] 0x000000000000-0x000000080000 : "X-Loader"
[    1.576385] 0x000000080000-0x000000260000 : "U-Boot"
[    1.589569] 0x000000260000-0x000000280000 : "U-Boot Env"
[    1.602081] 0x000000280000-0x000000680000 : "Kernel"
[    1.616058] 0x000000680000-0x000010000000 : "File System"
[    1.746307] OneNAND driver initializing
[    1.762634] usbcore: registered new interface driver asix
[    1.769317] usbcore: registered new interface driver cdc_ether
[    1.776580] usbcore: registered new interface driver net1080
[    1.783386] usbcore: registered new interface driver cdc_subset
[    1.790496] usbcore: registered new interface driver zaurus
[    1.796508] cdc_ncm: 7-Feb-2011
[    1.800537] usbcore: registered new interface driver cdc_ncm
[    1.809814] usbcore: registered new interface driver cdc_wdm
[    1.815887] Initializing USB Mass Storage driver...
[    1.821929] usbcore: registered new interface driver usb-storage
[    1.828399] USB Mass Storage support registered.
[    1.834960] usbcore: registered new interface driver libusual
[    1.841979] usbcore: registered new interface driver usbtest
[    1.847930] udc: OMAP UDC driver, version: 4 October 2004 (iso) (dma)
[    1.859130] mousedev: PS/2 mouse device common for all mice
[    1.869018] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[    1.887878] input: twl4030_pwrbutton as 
/devices/platform/omap/omap_i2c.1/i2c-1/1-0049/twl4030_pwrbutton/input/input1
[    1.904266] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
[    1.914123] i2c /dev entries driver
[    1.923553] Driver for 1-wire Dallas network protocol.
[    1.931701] omap_device: omap_wdt.-1: new worst case activate latency 
0: 30517
[    1.941497] OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
[    1.949462] twl4030_wdt twl4030_wdt: Failed to register misc device
[    1.956481] twl4030_wdt: probe of twl4030_wdt failed with error -16
[    1.981750] usbcore: registered new interface driver usbhid
[    1.987792] usbhid: USB HID core driver
[    1.991882] oprofile: hardware counters not available
[    1.997161] oprofile: using timer interrupt.
[    2.002471] TCP cubic registered
[    2.005950] Initializing XFRM netlink socket
[    2.010620] NET: Registered protocol family 17
[    2.015502] NET: Registered protocol family 15
[    2.020874] Registering the dns_resolver key type
[    2.026580] VFP support v0.3: implementor 41 architecture 3 part 30 
variant c rev 1
[    2.036193] ThumbEE CPU extension supported.
[    2.054840] Power Management for TI OMAP3.
[    2.106384] clock: disabling unused clocks to save power
[    2.119476] regulator_init_complete: VDVI: incomplete constraints, 
leaving on
[    2.127502] regulator_init_complete: VDAC: incomplete constraints, 
leaving on
[    2.137084] twl_rtc twl_rtc: setting system clock to 2000-01-01 
00:44:33 UTC (946687473)
[    2.150207] Waiting for root device /dev/mmcblk0p2...
[    2.466430] mmc0: new SDHC card at address aaaa
[    2.475067] mmcblk0: mmc0:aaaa SD04G 3.69 GiB
[    2.488464]  mmcblk0: p1 p2

[    3.158355] kjournald starting.  Commit interval 5 seconds
[    3.165069] EXT3-fs (mmcblk0p2): warning: mounting fs with errors, 
running e2fsck is recommended
[    3.178955] EXT3-fs (mmcblk0p2): using internal journal
[    3.184448] EXT3-fs (mmcblk0p2): recovery complete
[    3.193359] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data 
mode
[    3.201263] VFS: Mounted root (ext3 filesystem) on device 179:2.
[    3.207885] Freeing init memory: 292K

/bin/sh: can't access tty; job control turned off
#
#

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Kevin Hilman]

Rajendra Nayak <rnayak@ti.com> writes:

[...]

>>
>> It's also breaking boot on OMAP35xx BeagleBoard rev C2.  The kernel
>> boot messages are below - omap2plus_defconfig + DEBUG_LL.  Reverting
>> the patch fixes it.  Could you please take a look?
>
> I got hold of a Beagle, a sticker on which says rev C1D.
> Not sure if there is a better way to identify the rev, but
> this one seems to boot fine for me even with this patch.
> I just applied this one patch on top of the the tag
> 'integration-2.6.39-20110310-008' of git://git.pwsan.com/linux-
> integration.

In the process of testing Santosh's OMAP4 PM series (which includes
$SUBJECT patch) on OMAP3, I also noticed some problems on beagle (mine
is a C3.)

Specifially, with $SUBJECT patch applied, none of the powerdomains ever
reach inactive or RET during idle (suspend seems to work fine.)

Just reverting $SUBJECT patch makes things go back to working normally.

I pushed the test branch I used which is a merge of Santosh's v3 branch
with my pm branch (branch: tmp/santosh-omap4-pm)

I tested by first doing a suspend test and confirming all the
powerdomains hit retention.  That worked fine.  Then I did an idle test:

  echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout               
  echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout               
  echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout               
  echo 1 > /debug/pm_debug/sleep_while_idle

and waited for the UARTs to timeout.

Well after the UART timeouts expired, I do not see any powerdomains
transitioning from ON.

What's even more strange is that the same thing is working fine on all
the other OMAP3 platforms I tested: 3430/n900, 3630/zoom3 and even a
different 3530-based platform, the OMAP3EVM.

Kevin

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

Hi Kevin,

On 3/11/2011 10:17 PM, Kevin Hilman wrote:
> Rajendra Nayak<rnayak@ti.com>  writes:
>
> [...]
>
>>>
>>> It's also breaking boot on OMAP35xx BeagleBoard rev C2.  The kernel
>>> boot messages are below - omap2plus_defconfig + DEBUG_LL.  Reverting
>>> the patch fixes it.  Could you please take a look?
>>
>> I got hold of a Beagle, a sticker on which says rev C1D.
>> Not sure if there is a better way to identify the rev, but
>> this one seems to boot fine for me even with this patch.
>> I just applied this one patch on top of the the tag
>> 'integration-2.6.39-20110310-008' of git://git.pwsan.com/linux-
>> integration.
>
> In the process of testing Santosh's OMAP4 PM series (which includes
> $SUBJECT patch) on OMAP3, I also noticed some problems on beagle (mine
> is a C3.)
>
> Specifially, with $SUBJECT patch applied, none of the powerdomains ever
> reach inactive or RET during idle (suspend seems to work fine.)
>
> Just reverting $SUBJECT patch makes things go back to working normally.
>
> I pushed the test branch I used which is a merge of Santosh's v3 branch
> with my pm branch (branch: tmp/santosh-omap4-pm)
>
> I tested by first doing a suspend test and confirming all the
> powerdomains hit retention.  That worked fine.  Then I did an idle test:
>
>    echo 5>  /sys/devices/platform/omap/omap_uart.0/sleep_timeout
>    echo 5>  /sys/devices/platform/omap/omap_uart.1/sleep_timeout
>    echo 5>  /sys/devices/platform/omap/omap_uart.2/sleep_timeout
>    echo 1>  /debug/pm_debug/sleep_while_idle
>
> and waited for the UARTs to timeout.
>
> Well after the UART timeouts expired, I do not see any powerdomains
> transitioning from ON.
>
> What's even more strange is that the same thing is working fine on all
> the other OMAP3 platforms I tested: 3430/n900, 3630/zoom3 and even a
> different 3530-based platform, the OMAP3EVM.

I probably know whats going wrong with this patch, even though I
haven't really been able to reproduce any of these issues myself.

The below change which should be the only one affecting non-OMAP4
platforms actually is calling clkdm_allow_idle() for all clkdms
without really checking for a CLKDM_CAN_ENABLE_AUTO flag, which
seems wrong. I was somehow under the impression that the
clkdm_allow_idle() function would internally do this check but
that does not seem to be the case.

+	/* If clockdomain supports hardware control, enable it */
+	if (clk->clkdm)
+		clkdm_allow_idle(clk->clkdm);

I could see that emu_clkdm on OMAP3 is one clockdomain for
which CLKDM_CAN_ENABLE_AUTO is been disabled.

 From clockdomains2xxx_3xxx_data.c file..
--------
/*
  * Disable hw supervised mode for emu_clkdm, because emu_pwrdm is
  * switched of even if sdti is in use
  */
static struct clockdomain emu_clkdm = {
         .name           = "emu_clkdm",
         .pwrdm          = { .name = "emu_pwrdm" },
         .flags          = /* CLKDM_CAN_ENABLE_AUTO |  */CLKDM_CAN_SWSUP,
         .clktrctrl_mask = OMAP3430_CLKTRCTRL_EMU_MASK,
         .omap_chip      = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
--------

Maybe programming emu_clkdm in HW_AUTO is the one that shows
up these strange behavior on select BeagleBoard's.
Not sure if this would fix the issue but this does seem
like a necessary fix needed for this patch.

Paul,

To handle this I was thinking of adding another clockdomain
framework api, something like a clkdm_post_clk_enable, to do
the post clock/module enable sequencing of clockdomain
programming. Or is it ok to check for a clockdomain specific
flag in clock framework? Any thoughts?

Now that its too late for this to make it to .39, I can
experiment with this sequence on OMAP2/3 as well and see
if all the autodeps can then be removed.

regards,
Rajendra


>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

On 3/12/2011 1:23 PM, Rajendra Nayak wrote:
> Hi Kevin,
>
> On 3/11/2011 10:17 PM, Kevin Hilman wrote:
>> Rajendra Nayak<rnayak@ti.com>  writes:
>>
>> [...]
>>
>>>>
>>>> It's also breaking boot on OMAP35xx BeagleBoard rev C2.  The kernel
>>>> boot messages are below - omap2plus_defconfig + DEBUG_LL.  Reverting
>>>> the patch fixes it.  Could you please take a look?
>>>
>>> I got hold of a Beagle, a sticker on which says rev C1D.
>>> Not sure if there is a better way to identify the rev, but
>>> this one seems to boot fine for me even with this patch.
>>> I just applied this one patch on top of the the tag
>>> 'integration-2.6.39-20110310-008' of git://git.pwsan.com/linux-
>>> integration.
>>
>> In the process of testing Santosh's OMAP4 PM series (which includes
>> $SUBJECT patch) on OMAP3, I also noticed some problems on beagle (mine
>> is a C3.)
>>
>> Specifially, with $SUBJECT patch applied, none of the powerdomains ever
>> reach inactive or RET during idle (suspend seems to work fine.)
>>
>> Just reverting $SUBJECT patch makes things go back to working normally.
>>
>> I pushed the test branch I used which is a merge of Santosh's v3 branch
>> with my pm branch (branch: tmp/santosh-omap4-pm)
>>
>> I tested by first doing a suspend test and confirming all the
>> powerdomains hit retention.  That worked fine.  Then I did an idle test:
>>
>>    echo 5>  /sys/devices/platform/omap/omap_uart.0/sleep_timeout
>>    echo 5>  /sys/devices/platform/omap/omap_uart.1/sleep_timeout
>>    echo 5>  /sys/devices/platform/omap/omap_uart.2/sleep_timeout
>>    echo 1>  /debug/pm_debug/sleep_while_idle
>>
>> and waited for the UARTs to timeout.
>>
>> Well after the UART timeouts expired, I do not see any powerdomains
>> transitioning from ON.
>>
>> What's even more strange is that the same thing is working fine on all
>> the other OMAP3 platforms I tested: 3430/n900, 3630/zoom3 and even a
>> different 3530-based platform, the OMAP3EVM.
>
> I probably know whats going wrong with this patch, even though I
> haven't really been able to reproduce any of these issues myself.
>
> The below change which should be the only one affecting non-OMAP4
> platforms actually is calling clkdm_allow_idle() for all clkdms
> without really checking for a CLKDM_CAN_ENABLE_AUTO flag, which
> seems wrong. I was somehow under the impression that the
> clkdm_allow_idle() function would internally do this check but
> that does not seem to be the case.

Actually I was wrong, clkdm_allow_idle() does seem to have a
check for the CLKDM_CAN_ENABLE_AUTO flag.

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

Hi Kevin/Paul,

On 3/11/2011 10:17 PM, Kevin Hilman wrote:
> Rajendra Nayak<rnayak@ti.com>  writes:
>
> [...]
>
>>>
>>> It's also breaking boot on OMAP35xx BeagleBoard rev C2.  The kernel
>>> boot messages are below - omap2plus_defconfig + DEBUG_LL.  Reverting
>>> the patch fixes it.  Could you please take a look?
>>
>> I got hold of a Beagle, a sticker on which says rev C1D.
>> Not sure if there is a better way to identify the rev, but
>> this one seems to boot fine for me even with this patch.
>> I just applied this one patch on top of the the tag
>> 'integration-2.6.39-20110310-008' of git://git.pwsan.com/linux-
>> integration.
>
> In the process of testing Santosh's OMAP4 PM series (which includes
> $SUBJECT patch) on OMAP3, I also noticed some problems on beagle (mine
> is a C3.)
>
> Specifially, with $SUBJECT patch applied, none of the powerdomains ever
> reach inactive or RET during idle (suspend seems to work fine.)
>
> Just reverting $SUBJECT patch makes things go back to working normally.
>
> I pushed the test branch I used which is a merge of Santosh's v3 branch
> with my pm branch (branch: tmp/santosh-omap4-pm)
>
> I tested by first doing a suspend test and confirming all the
> powerdomains hit retention.  That worked fine.  Then I did an idle test:
>
>    echo 5>  /sys/devices/platform/omap/omap_uart.0/sleep_timeout
>    echo 5>  /sys/devices/platform/omap/omap_uart.1/sleep_timeout
>    echo 5>  /sys/devices/platform/omap/omap_uart.2/sleep_timeout
>    echo 1>  /debug/pm_debug/sleep_while_idle
>
> and waited for the UARTs to timeout.
>
> Well after the UART timeouts expired, I do not see any powerdomains
> transitioning from ON.
>
> What's even more strange is that the same thing is working fine on all
> the other OMAP3 platforms I tested: 3430/n900, 3630/zoom3 and even a
> different 3530-based platform, the OMAP3EVM.

I tried to reproduce this on a Beagle rev C3, but I don't seem
to be seeing this issue. I was able to hit OFF mode in both
suspend and idle.

I also tried removing autodeps completely on OMAP3 and ran
into some issues/aborts with GPIO restore path with
OFF mode enabled.

Besides these, debugging some McBSP related crashes showed
up another issue with this patch.
Since the clockdomain is programmed back to HW_AUTO (if supported)
in the clock framework, this happens *before* waiting for the
module to become accessible. (On OMAP4, the check to make sure
the module is accessible happens in the hwmod framework, unlike
in older OMAP's, where it was part of the clock framework)

So instead of implementing the recommended sequence of
-1- Force clkdm to SW_WKUP
-2- Configure desired module mode to "enable" or "auto"
-3- Wait for the desired module idle status to be FUNC
-4- Program clkdm in HW_AUTO(if supported)

..it was actually implementing the wrong sequence as below
-1- Force clkdm to SW_WKUP
-2- Configure desired module mode to "enable" or "auto"
-3- Program clkdm in HW_AUTO(if supported)
-4- Wait for the desired module idle status to be FUNC

This however was only a problem on OMAP4.

Fixing this would require moving the clockdomain programming
back to HW_AUTO as part of the hwmod framework.
However this sequence is recommended even for optional
clock enabling, and hence might have to be handled at
the clock framework as well. (Since optional clocks
are still controlled by drivers using clock framework
directly).
Any suggestions on how to handle this without duplicating
much of this across clock and hwmod framework?

regards,
Rajendra

>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

Hi Rajendra,

I regret the delay,

On Fri, 11 Mar 2011, Rajendra Nayak wrote:

> Would a board rev make a difference?

I doubt it...

- Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

Hi Rajendra,

On Mon, 21 Mar 2011, Rajendra Nayak wrote:

> On 3/11/2011 10:17 PM, Kevin Hilman wrote:
> > Rajendra Nayak<rnayak@ti.com>  writes:
> > 
> > [...]
> > 
> > > > 
> > > > It's also breaking boot on OMAP35xx BeagleBoard rev C2.  The kernel
> > > > boot messages are below - omap2plus_defconfig + DEBUG_LL.  Reverting
> > > > the patch fixes it.  Could you please take a look?
> > > 
> > > I got hold of a Beagle, a sticker on which says rev C1D.
> > > Not sure if there is a better way to identify the rev, but
> > > this one seems to boot fine for me even with this patch.
> > > I just applied this one patch on top of the the tag
> > > 'integration-2.6.39-20110310-008' of git://git.pwsan.com/linux-
> > > integration.
> > 
> > In the process of testing Santosh's OMAP4 PM series (which includes
> > $SUBJECT patch) on OMAP3, I also noticed some problems on beagle (mine
> > is a C3.)
> > 
> > Specifially, with $SUBJECT patch applied, none of the powerdomains ever
> > reach inactive or RET during idle (suspend seems to work fine.)
> > 
> > Just reverting $SUBJECT patch makes things go back to working normally.
> > 
> > I pushed the test branch I used which is a merge of Santosh's v3 branch
> > with my pm branch (branch: tmp/santosh-omap4-pm)
> > 
> > I tested by first doing a suspend test and confirming all the
> > powerdomains hit retention.  That worked fine.  Then I did an idle test:
> > 
> >    echo 5>  /sys/devices/platform/omap/omap_uart.0/sleep_timeout
> >    echo 5>  /sys/devices/platform/omap/omap_uart.1/sleep_timeout
> >    echo 5>  /sys/devices/platform/omap/omap_uart.2/sleep_timeout
> >    echo 1>  /debug/pm_debug/sleep_while_idle
> > 
> > and waited for the UARTs to timeout.
> > 
> > Well after the UART timeouts expired, I do not see any powerdomains
> > transitioning from ON.
> > 
> > What's even more strange is that the same thing is working fine on all
> > the other OMAP3 platforms I tested: 3430/n900, 3630/zoom3 and even a
> > different 3530-based platform, the OMAP3EVM.
> 
> I tried to reproduce this on a Beagle rev C3, but I don't seem
> to be seeing this issue. I was able to hit OFF mode in both
> suspend and idle.
> 
> I also tried removing autodeps completely on OMAP3 and ran
> into some issues/aborts with GPIO restore path with
> OFF mode enabled.
> 
> Besides these, debugging some McBSP related crashes showed
> up another issue with this patch.
> Since the clockdomain is programmed back to HW_AUTO (if supported)
> in the clock framework, this happens *before* waiting for the
> module to become accessible. (On OMAP4, the check to make sure
> the module is accessible happens in the hwmod framework, unlike
> in older OMAP's, where it was part of the clock framework)
> 
> So instead of implementing the recommended sequence of
> -1- Force clkdm to SW_WKUP
> -2- Configure desired module mode to "enable" or "auto"
> -3- Wait for the desired module idle status to be FUNC
> -4- Program clkdm in HW_AUTO(if supported)
> 
> ..it was actually implementing the wrong sequence as below
> -1- Force clkdm to SW_WKUP
> -2- Configure desired module mode to "enable" or "auto"
> -3- Program clkdm in HW_AUTO(if supported)
> -4- Wait for the desired module idle status to be FUNC

Hmmm, right now OMAP4 only appears to be forcing the clkdm to SW_WKUP if 
the clockdomain is in software-supervised mode 
(clockdomain44xx.c:omap4_clkdm_clk_enable()).  Doesn't seem like that 
follows either sequence?

> This however was only a problem on OMAP4.
> 
> Fixing this would require moving the clockdomain programming
> back to HW_AUTO as part of the hwmod framework.

In omap_hwmod.c:_enable(), what do you think about:

1. saving the current idle mode of the clockdomain,

2. forcing the clockdomain to software-supervised wakeup.

3. enabling clocks and waiting for the module as we currently do, then

4. switching the clockdomain's idle mode back to its original state?

Seems like that would be a reasonable approach for the short term, at 
least for drivers that have been converted to PM runtime.

> However this sequence is recommended even for optional clock enabling, 
> and hence might have to be handled at the clock framework as well. 

Might be worth finding out the reasoning behind this recommendation.  Is 
this only for optional clocks that are used for functional purposes, e.g., 
for modules that use HWMOD_CONTROL_OPT_CLKS_IN_RESET ?

> (Since optional clocks are still controlled by drivers using clock 
> framework directly).

Yeah, if this really turns out to be needed, sounds like we'll have to 
tightly couple the hwmod code with the OMAP clock code :-( I'd suggest 
that we find out why this is recommended first.

> Any suggestions on how to handle this without duplicating
> much of this across clock and hwmod framework?


- Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

Hi Paul,

<snip>...
>>> Well after the UART timeouts expired, I do not see any powerdomains
>>> transitioning from ON.
>>>
>>> What's even more strange is that the same thing is working fine on all
>>> the other OMAP3 platforms I tested: 3430/n900, 3630/zoom3 and even a
>>> different 3530-based platform, the OMAP3EVM.
>>
>> I tried to reproduce this on a Beagle rev C3, but I don't seem
>> to be seeing this issue. I was able to hit OFF mode in both
>> suspend and idle.
>>
>> I also tried removing autodeps completely on OMAP3 and ran
>> into some issues/aborts with GPIO restore path with
>> OFF mode enabled.
>>
>> Besides these, debugging some McBSP related crashes showed
>> up another issue with this patch.
>> Since the clockdomain is programmed back to HW_AUTO (if supported)
>> in the clock framework, this happens *before* waiting for the
>> module to become accessible. (On OMAP4, the check to make sure
>> the module is accessible happens in the hwmod framework, unlike
>> in older OMAP's, where it was part of the clock framework)
>>
>> So instead of implementing the recommended sequence of
>> -1- Force clkdm to SW_WKUP
>> -2- Configure desired module mode to "enable" or "auto"
>> -3- Wait for the desired module idle status to be FUNC
>> -4- Program clkdm in HW_AUTO(if supported)
>>
>> ..it was actually implementing the wrong sequence as below
>> -1- Force clkdm to SW_WKUP
>> -2- Configure desired module mode to "enable" or "auto"
>> -3- Program clkdm in HW_AUTO(if supported)
>> -4- Wait for the desired module idle status to be FUNC
>
> Hmmm, right now OMAP4 only appears to be forcing the clkdm to SW_WKUP if
> the clockdomain is in software-supervised mode
> (clockdomain44xx.c:omap4_clkdm_clk_enable()).  Doesn't seem like that
> follows either sequence?

Yes, the current implementation only forces it to SW_WKUP
if the clockdomain is in software supervised mode which is
not correct.
Thats what this patch intended to fix, but like I said
the sequence followed in this patch was still not right.

>
>> This however was only a problem on OMAP4.
>>
>> Fixing this would require moving the clockdomain programming
>> back to HW_AUTO as part of the hwmod framework.
>
> In omap_hwmod.c:_enable(), what do you think about:
>
> 1. saving the current idle mode of the clockdomain,
>
> 2. forcing the clockdomain to software-supervised wakeup.
>
> 3. enabling clocks and waiting for the module as we currently do, then
>
> 4. switching the clockdomain's idle mode back to its original state?
>
> Seems like that would be a reasonable approach for the short term, at
> least for drivers that have been converted to PM runtime.

Ok, I'll try and get some RFC patches in these lines soon.

>
>> However this sequence is recommended even for optional clock enabling,
>> and hence might have to be handled at the clock framework as well.
>
> Might be worth finding out the reasoning behind this recommendation.  Is
> this only for optional clocks that are used for functional purposes, e.g.,
> for modules that use HWMOD_CONTROL_OPT_CLKS_IN_RESET ?

Ok, I'll try and dig some more details on this.

regards,
Rajendra
>
>> (Since optional clocks are still controlled by drivers using clock
>> framework directly).
>
> Yeah, if this really turns out to be needed, sounds like we'll have to
> tightly couple the hwmod code with the OMAP clock code :-( I'd suggest
> that we find out why this is recommended first.
>
>> Any suggestions on how to handle this without duplicating
>> much of this across clock and hwmod framework?
>
>
> - Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

Hi Paul,

<snip>..
>>
>> In omap_hwmod.c:_enable(), what do you think about:
>>
>> 1. saving the current idle mode of the clockdomain,
>>
>> 2. forcing the clockdomain to software-supervised wakeup.
>>
>> 3. enabling clocks and waiting for the module as we currently do, then
>>
>> 4. switching the clockdomain's idle mode back to its original state?
>>
>> Seems like that would be a reasonable approach for the short term, at
>> least for drivers that have been converted to PM runtime.
>
> Ok, I'll try and get some RFC patches in these lines soon.

I tried some of what you were suggesting here and it seems to
work well, like you said, for the drivers which are converted
to PM runtime.

Now the issue seems to be, how do we handle the ones which
are *still* using clock framework to enable main clocks and
are yet to be converted to PM runtime.

One such, MMC, is showing me issues on OMAP4 even at boot
and causes a crash.

Its a different thing that some of these drivers which use
direct clock calls are working by fluke on OMAP4 since the
clock framework does not even wait for the modules to become
accessible after the clock enable.

I know the right way seems to be to get all these drivers
converted to PM runtime, but that might take sometime.

regards,
Rajendra

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

On 4/1/2011 8:21 PM, Rajendra Nayak wrote:
> Hi Paul,
>
> <snip>..
>>>
>>> In omap_hwmod.c:_enable(), what do you think about:
>>>
>>> 1. saving the current idle mode of the clockdomain,
>>>
>>> 2. forcing the clockdomain to software-supervised wakeup.
>>>
>>> 3. enabling clocks and waiting for the module as we currently do, then
>>>
>>> 4. switching the clockdomain's idle mode back to its original state?
>>>
>>> Seems like that would be a reasonable approach for the short term, at
>>> least for drivers that have been converted to PM runtime.
>>
>> Ok, I'll try and get some RFC patches in these lines soon.
>
> I tried some of what you were suggesting here and it seems to
> work well, like you said, for the drivers which are converted
> to PM runtime.
>
> Now the issue seems to be, how do we handle the ones which
> are *still* using clock framework to enable main clocks and
> are yet to be converted to PM runtime.
>
> One such, MMC, is showing me issues on OMAP4 even at boot
> and causes a crash.
>
> Its a different thing that some of these drivers which use
> direct clock calls are working by fluke on OMAP4 since the
> clock framework does not even wait for the modules to become
> accessible after the clock enable.
>
> I know the right way seems to be to get all these drivers
> converted to PM runtime, but that might take sometime.

One way I am able to get this working (atleast MMC)
is by preventing the clock domain belonging to MMC module
from being programmed into HW_SUP mode.
Acceptable hack in the interim while we wait for the MMC
driver to be using PM runtime?

>
> regards,
> Rajendra

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

On Fri, 1 Apr 2011, Rajendra Nayak wrote:

> On 4/1/2011 8:21 PM, Rajendra Nayak wrote:
> > > > In omap_hwmod.c:_enable(), what do you think about:
> > > > 
> > > > 1. saving the current idle mode of the clockdomain,
> > > > 
> > > > 2. forcing the clockdomain to software-supervised wakeup.
> > > > 
> > > > 3. enabling clocks and waiting for the module as we currently do, then
> > > > 
> > > > 4. switching the clockdomain's idle mode back to its original state?
> > > > 
> > > > Seems like that would be a reasonable approach for the short term, at
> > > > least for drivers that have been converted to PM runtime.
> > > 
> > > Ok, I'll try and get some RFC patches in these lines soon.
> > 
> > I tried some of what you were suggesting here and it seems to
> > work well, like you said, for the drivers which are converted
> > to PM runtime.
> > 
> > Now the issue seems to be, how do we handle the ones which
> > are *still* using clock framework to enable main clocks and
> > are yet to be converted to PM runtime.
> > 
> > One such, MMC, is showing me issues on OMAP4 even at boot
> > and causes a crash.
> > 
> > Its a different thing that some of these drivers which use
> > direct clock calls are working by fluke on OMAP4 since the
> > clock framework does not even wait for the modules to become
> > accessible after the clock enable.
> >
> > I know the right way seems to be to get all these drivers
> > converted to PM runtime, but that might take sometime.
> 
> One way I am able to get this working (atleast MMC)
> is by preventing the clock domain belonging to MMC module
> from being programmed into HW_SUP mode.

What programs the OMAP4 clockdomains into hwsup mode in the first place?  
There's no clkdms_setup() as there is in mach-omap2/pm34xx.c.  I guess 
maybe this code in mach-omap2/pm.c might do it as a side effect:

	switch (sleep_switch) {
	case FORCEWAKEUP_SWITCH:
		if (pwrdm->pwrdm_clkdms[0]->flags & CLKDM_CAN_ENABLE_AUTO)
			clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
		else
			clkdm_sleep(pwrdm->pwrdm_clkdms[0]);
		break;

If I'm reading this code correctly, it will always force clockdomains that 
support hwsup mode into hwsup mode, even if they've been previously 
programmed to swsup mode.  That's not right.  This function should leave 
the clockdomain's autoidle setting where it was when the function was 
entered.  So this needs to be fixed also.

> Acceptable hack in the interim while we wait for the MMC driver to be 
> using PM runtime?

Ideally this should be overridden in the code, not the data, since this 
hack is needed due to a software problem, not a hardware problem.  The 
clockdomains data should just be a statement of what the hardware 
supports.

But given the above bug and the lack of some clkdms_setup() function for 
OMAP4, I guess the clockdomains data is the least bad choice for right 
now, provided that the patch also:

1. puts a big comment in that data warning about the problem and 
explaining why

2. puts a pr_warn() in mach-omap2/pm44xx.c:omap4_pm_init() saying: 
"WARNING: OMAP4 power savings limited since MMC driver not converted to 
PM runtime"


- Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Santosh Shilimkar]

Paul,
On 4/4/2011 12:17 PM, Paul Walmsley wrote:
> On Fri, 1 Apr 2011, Rajendra Nayak wrote:
>
>> On 4/1/2011 8:21 PM, Rajendra Nayak wrote:
>>>>> In omap_hwmod.c:_enable(), what do you think about:
>>>>>
>>>>> 1. saving the current idle mode of the clockdomain,
>>>>>
>>>>> 2. forcing the clockdomain to software-supervised wakeup.
>>>>>
>>>>> 3. enabling clocks and waiting for the module as we currently do, then
>>>>>
>>>>> 4. switching the clockdomain's idle mode back to its original state?
>>>>>
>>>>> Seems like that would be a reasonable approach for the short term, at
>>>>> least for drivers that have been converted to PM runtime.
>>>>
>>>> Ok, I'll try and get some RFC patches in these lines soon.
>>>
>>> I tried some of what you were suggesting here and it seems to
>>> work well, like you said, for the drivers which are converted
>>> to PM runtime.
>>>
>>> Now the issue seems to be, how do we handle the ones which
>>> are *still* using clock framework to enable main clocks and
>>> are yet to be converted to PM runtime.
>>>
>>> One such, MMC, is showing me issues on OMAP4 even at boot
>>> and causes a crash.
>>>
>>> Its a different thing that some of these drivers which use
>>> direct clock calls are working by fluke on OMAP4 since the
>>> clock framework does not even wait for the modules to become
>>> accessible after the clock enable.
>>>
>>> I know the right way seems to be to get all these drivers
>>> converted to PM runtime, but that might take sometime.
>>
>> One way I am able to get this working (atleast MMC)
>> is by preventing the clock domain belonging to MMC module
>> from being programmed into HW_SUP mode.
>
> What programs the OMAP4 clockdomains into hwsup mode in the first place?

This is done as part of the OMAP4 PM series.

Regards
Santosh

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Rajendra Nayak]

Hi Paul,

On 4/4/2011 12:17 PM, Paul Walmsley wrote:
> On Fri, 1 Apr 2011, Rajendra Nayak wrote:
>
>> On 4/1/2011 8:21 PM, Rajendra Nayak wrote:
>>>>> In omap_hwmod.c:_enable(), what do you think about:
>>>>>
>>>>> 1. saving the current idle mode of the clockdomain,
>>>>>
>>>>> 2. forcing the clockdomain to software-supervised wakeup.
>>>>>
>>>>> 3. enabling clocks and waiting for the module as we currently do, then
>>>>>
>>>>> 4. switching the clockdomain's idle mode back to its original state?
>>>>>
>>>>> Seems like that would be a reasonable approach for the short term, at
>>>>> least for drivers that have been converted to PM runtime.
>>>>
>>>> Ok, I'll try and get some RFC patches in these lines soon.
>>>
>>> I tried some of what you were suggesting here and it seems to
>>> work well, like you said, for the drivers which are converted
>>> to PM runtime.
>>>
>>> Now the issue seems to be, how do we handle the ones which
>>> are *still* using clock framework to enable main clocks and
>>> are yet to be converted to PM runtime.
>>>
>>> One such, MMC, is showing me issues on OMAP4 even at boot
>>> and causes a crash.
>>>
>>> Its a different thing that some of these drivers which use
>>> direct clock calls are working by fluke on OMAP4 since the
>>> clock framework does not even wait for the modules to become
>>> accessible after the clock enable.
>>>
>>> I know the right way seems to be to get all these drivers
>>> converted to PM runtime, but that might take sometime.
>>
>> One way I am able to get this working (atleast MMC)
>> is by preventing the clock domain belonging to MMC module
>> from being programmed into HW_SUP mode.
>
> What programs the OMAP4 clockdomains into hwsup mode in the first place?

This is not yet in mainline, but being done by Santosh's series which
adds OMAP4 low power support in idle and suspend.
http://marc.info/?l=linux-omap&m=130130417927632&w=2

> There's no clkdms_setup() as there is in mach-omap2/pm34xx.c.  I guess
> maybe this code in mach-omap2/pm.c might do it as a side effect:
>
> 	switch (sleep_switch) {
> 	case FORCEWAKEUP_SWITCH:
> 		if (pwrdm->pwrdm_clkdms[0]->flags&  CLKDM_CAN_ENABLE_AUTO)
> 			clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
> 		else
> 			clkdm_sleep(pwrdm->pwrdm_clkdms[0]);
> 		break;
>
> If I'm reading this code correctly, it will always force clockdomains that
> support hwsup mode into hwsup mode, even if they've been previously
> programmed to swsup mode.  That's not right.  This function should leave
> the clockdomain's autoidle setting where it was when the function was
> entered.  So this needs to be fixed also.

You are right, the code is buggy, I just posted a short series which
should fix this.
http://marc.info/?l=linux-omap&m=130200752115352&w=2

>
>> Acceptable hack in the interim while we wait for the MMC driver to be
>> using PM runtime?
>
> Ideally this should be overridden in the code, not the data, since this
> hack is needed due to a software problem, not a hardware problem.  The
> clockdomains data should just be a statement of what the hardware
> supports.
>
> But given the above bug and the lack of some clkdms_setup() function for
> OMAP4, I guess the clockdomains data is the least bad choice for right
> now, provided that the patch also:

With Santosh's series which adds the clkdms_setup and my series
to fix the above bug, I should be able to handle this in the code,
rather than hack the clockdomains data.
I will post some patches for that as well.

regards
Rajendra

>
> 1. puts a big comment in that data warning about the problem and
> explaining why
>
> 2. puts a pr_warn() in mach-omap2/pm44xx.c:omap4_pm_init() saying:
> "WARNING: OMAP4 power savings limited since MMC driver not converted to
> PM runtime"
>
>
> - Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Paul Walmsley]

Hi Rajendra, Santosh,

just FYI I just observed this happening without the clockdomain patch, and  
tracked this down.  It seems that there is an intermittent 
problem with the OMAP L3 bus code.  On the 35xx BeagleBoard here, it 
occasionally hangs after powerup:

[    0.810119] OMAP GPIO hardware version 2.5
[    0.815368] OMAP GPIO hardware version 2.5
[    0.820465] OMAP GPIO hardware version 2.5
[    0.825531] OMAP GPIO hardware version 2.5
[    0.830657] OMAP GPIO hardware version 2.5
[    0.835784] OMAP GPIO hardware version 2.5
[    0.840881] initcall omap_gpio_drv_reg+0x0/0xc returned 0 after 38146 
usecs
[    0.848358] calling  bdi_class_init+0x0/0x50 @ 1
[    0.854003] initcall bdi_class_init+0x0/0x50 returned 0 after 0 usecs
[    0.860870] calling  kobject_uevent_init+0x0/0x20 @ 1
[    0.866363] initcall kobject_uevent_init+0x0/0x20 returned 0 after 0 
usecs
[    0.873626] calling  gpiolib_sysfs_init+0x0/0x98 @ 1
[    0.885894] initcall gpiolib_sysfs_init+0x0/0x98 returned 0 after 0 
usecs
[    0.893157] calling  lcd_class_init+0x0/0x58 @ 1
[    0.898742] initcall lcd_class_init+0x0/0x58 returned 0 after 0 usecs
[    0.905731] calling  backlight_class_init+0x0/0x70 @ 1
[    0.911834] initcall backlight_class_init+0x0/0x70 returned 0 after 0 
usecs
[    0.919219] calling  tty_class_init+0x0/0x3c @ 1
[    0.924743] initcall tty_class_init+0x0/0x3c returned 0 after 0 usecs
[    0.931610] calling  vtconsole_class_init+0x0/0xe4 @ 1
[    0.938812] initcall vtconsole_class_init+0x0/0xe4 returned 0 after 
7629 usecs
[    0.946472] calling  wakeup_sources_debugfs_init+0x0/0x3c @ 1
[    0.952606] initcall wakeup_sources_debugfs_init+0x0/0x3c returned 0 
after 0 usecs
[    0.960571] calling  spi_init+0x0/0x88 @ 1
[    0.966247] initcall spi_init+0x0/0x88 returned 0 after 0 usecs
[    0.972564] calling  i2c_init+0x0/0x70 @ 1
[    0.978485] initcall i2c_init+0x0/0x70 returned 0 after 0 usecs
[    0.984832] calling  omap3_l3_init+0x0/0x14 @ 1

(hang)

- Paul

[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Santosh Shilimkar]

On 4/21/2011 1:12 AM, Paul Walmsley wrote:
>
> Hi Rajendra, Santosh,
>
> just FYI I just observed this happening without the clockdomain patch, and
> tracked this down.  It seems that there is an intermittent
> problem with the OMAP L3 bus code.  On the 35xx BeagleBoard here, it
> occasionally hangs after powerup:
>
> [    0.810119] OMAP GPIO hardware version 2.5
> [    0.815368] OMAP GPIO hardware version 2.5
> [    0.820465] OMAP GPIO hardware version 2.5
> [    0.825531] OMAP GPIO hardware version 2.5
> [    0.830657] OMAP GPIO hardware version 2.5
> [    0.835784] OMAP GPIO hardware version 2.5
> [    0.840881] initcall omap_gpio_drv_reg+0x0/0xc returned 0 after 38146
> usecs
> [    0.848358] calling  bdi_class_init+0x0/0x50 @ 1
> [    0.854003] initcall bdi_class_init+0x0/0x50 returned 0 after 0 usecs
> [    0.860870] calling  kobject_uevent_init+0x0/0x20 @ 1
> [    0.866363] initcall kobject_uevent_init+0x0/0x20 returned 0 after 0
> usecs
> [    0.873626] calling  gpiolib_sysfs_init+0x0/0x98 @ 1
> [    0.885894] initcall gpiolib_sysfs_init+0x0/0x98 returned 0 after 0
> usecs
> [    0.893157] calling  lcd_class_init+0x0/0x58 @ 1
> [    0.898742] initcall lcd_class_init+0x0/0x58 returned 0 after 0 usecs
> [    0.905731] calling  backlight_class_init+0x0/0x70 @ 1
> [    0.911834] initcall backlight_class_init+0x0/0x70 returned 0 after 0
> usecs
> [    0.919219] calling  tty_class_init+0x0/0x3c @ 1
> [    0.924743] initcall tty_class_init+0x0/0x3c returned 0 after 0 usecs
> [    0.931610] calling  vtconsole_class_init+0x0/0xe4 @ 1
> [    0.938812] initcall vtconsole_class_init+0x0/0xe4 returned 0 after
> 7629 usecs
> [    0.946472] calling  wakeup_sources_debugfs_init+0x0/0x3c @ 1
> [    0.952606] initcall wakeup_sources_debugfs_init+0x0/0x3c returned 0
> after 0 usecs
> [    0.960571] calling  spi_init+0x0/0x88 @ 1
> [    0.966247] initcall spi_init+0x0/0x88 returned 0 after 0 usecs
> [    0.972564] calling  i2c_init+0x0/0x70 @ 1
> [    0.978485] initcall i2c_init+0x0/0x70 returned 0 after 0 usecs
> [    0.984832] calling  omap3_l3_init+0x0/0x14 @ 1
>
Will have a look at it