OMAP4 PM bootloader dependency problems

OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi Tero, Rajendra, Santosh,

As we've discussed, there are known bootloader dependencies with the OMAP4 
PM retention idle code, introduced in v3.8.  Boards booted with u-boot 
versions even as recent as 2011 won't enter retention idle correctly; for 
example:

    http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt

The right thing for you all to do is what was done for OMAP3: to add code 
to correctly reset and initialize these on-chip devices.  However, since 
it's already late in the v3.8-rc cycle, this seems unlikely to happen in 
time for the v3.8 release -- and that's assuming that you guys are working 
on this, which I'm unsure of.

Barring that, what I'd like to see is a patch for v3.8-rc fixes that adds 
a warning, printed to the kernel console, during boot.  The warning should 
state that the OMAP4 PM code only works with certain bootloaders, and 
should identify the minimum u-boot release needed for OMAP4 full-chip 
retention idle to work.

Could you guys please put that together ASAP so we can get it merged 
during the v3.8-rc cycle?  Otherwise we're going to frustrate users when 
people expect PM to work correctly with their existing bootloaders.  The 
least we can do for them is warn them that problems exist.

This should take priority over any new features.


- Paul

---------- Forwarded message ----------
Date: Mon, 7 Jan 2013 18:40:02 +0000 (UTC)
From: Paul Walmsley <paul@pwsan.com>
To: Madhusudhan.Gowda@elektrobit.com
Cc: linux-omap@vger.kernel.org, t-kristo@ti.com, rnayak@ti.com
Subject: RE: Querry on UART wakeup on Linux 3.8-rc1

Hi,

On Sun, 6 Jan 2013, Madhusudhan.Gowda@elektrobit.com wrote:

> Could  someone point me if it has been working in any of the releases ?

Serial wakeup from retention suspend seems to work on the OMAP4460 
Panda-ES here as of v3.8-rc1, with a really recent U-boot[*]:

http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/pm/4460pandaes/4460pandaes_log.txt

http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/README.txt

(There are some warnings present from the power state debugging 
code, so there's probably something that could use a closer look.)

The problem is, you need a really recent bootloader for this to work.  
This is because the mainline kernel is missing code to idle several 
on-chip devices (IVAHD, DSP, etc.).  This can be seen with the OMAP4430 
boot logs:

http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/pm/4430es2panda/4430es2panda_log.txt

That board is running an "older" bootloader - from July 2012!

The hope is that some of the folks still working for TI can post the 
appropriate reset and idle code for these devices.  Or at least, we'd 
better add a console warning to the OMAP44xx PM init code that warns about 
the bootloader dependencies.  Any comments from the TI folks here?


- Paul

> 
> Thanks,
> Gowda
> 
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org
> [mailto:linux-omap-owner@vger.kernel.org] 
> Sent: 01. tammikuuta 2013 22:08
> To: linux-omap@vger.kernel.org
> Subject: Querry on UART wakeup on Linux 3.8-rc1
> 
> Hi,
> 
> I tried to wakeup OMAP430 ES2.1 Panda from static suspend retention
> using console uart2, it doesn't wakeup.
> But could configure GPIO_121 button to wake up from retention fine.
> 
> On the serial uart side I have manually enabled wakeup by echo enabled >
> /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup
> 
> I could see the wakeup enable bit (1<<14)  of  uart irrx pad register is
> being set properly before it does static suspend fine.
> 
> Should I need to do any more thing to get it work?
> 
> Thanks,
> Gowda
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org More majordomo info
> at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi Tero, Rajendra, Santosh,

As we've discussed, there are known bootloader dependencies with the OMAP4 
PM retention idle code, introduced in v3.8.  Boards booted with u-boot 
versions even as recent as 2011 won't enter retention idle correctly; for 
example:

    http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt

The right thing for you all to do is what was done for OMAP3: to add code 
to correctly reset and initialize these on-chip devices.  However, since 
it's already late in the v3.8-rc cycle, this seems unlikely to happen in 
time for the v3.8 release -- and that's assuming that you guys are working 
on this, which I'm unsure of.

Barring that, what I'd like to see is a patch for v3.8-rc fixes that adds 
a warning, printed to the kernel console, during boot.  The warning should 
state that the OMAP4 PM code only works with certain bootloaders, and 
should identify the minimum u-boot release needed for OMAP4 full-chip 
retention idle to work.

Could you guys please put that together ASAP so we can get it merged 
during the v3.8-rc cycle?  Otherwise we're going to frustrate users when 
people expect PM to work correctly with their existing bootloaders.  The 
least we can do for them is warn them that problems exist.

This should take priority over any new features.


- Paul

---------- Forwarded message ----------
Date: Mon, 7 Jan 2013 18:40:02 +0000 (UTC)
From: Paul Walmsley <paul@pwsan.com>
To: Madhusudhan.Gowda at elektrobit.com
Cc: linux-omap at vger.kernel.org, t-kristo at ti.com, rnayak at ti.com
Subject: RE: Querry on UART wakeup on Linux 3.8-rc1

Hi,

On Sun, 6 Jan 2013, Madhusudhan.Gowda at elektrobit.com wrote:

> Could  someone point me if it has been working in any of the releases ?

Serial wakeup from retention suspend seems to work on the OMAP4460 
Panda-ES here as of v3.8-rc1, with a really recent U-boot[*]:

http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/pm/4460pandaes/4460pandaes_log.txt

http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/README.txt

(There are some warnings present from the power state debugging 
code, so there's probably something that could use a closer look.)

The problem is, you need a really recent bootloader for this to work.  
This is because the mainline kernel is missing code to idle several 
on-chip devices (IVAHD, DSP, etc.).  This can be seen with the OMAP4430 
boot logs:

http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/pm/4430es2panda/4430es2panda_log.txt

That board is running an "older" bootloader - from July 2012!

The hope is that some of the folks still working for TI can post the 
appropriate reset and idle code for these devices.  Or at least, we'd 
better add a console warning to the OMAP44xx PM init code that warns about 
the bootloader dependencies.  Any comments from the TI folks here?


- Paul

> 
> Thanks,
> Gowda
> 
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org
> [mailto:linux-omap-owner at vger.kernel.org] 
> Sent: 01. tammikuuta 2013 22:08
> To: linux-omap at vger.kernel.org
> Subject: Querry on UART wakeup on Linux 3.8-rc1
> 
> Hi,
> 
> I tried to wakeup OMAP430 ES2.1 Panda from static suspend retention
> using console uart2, it doesn't wakeup.
> But could configure GPIO_121 button to wake up from retention fine.
> 
> On the serial uart side I have manually enabled wakeup by echo enabled >
> /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup
> 
> I could see the wakeup enable bit (1<<14)  of  uart irrx pad register is
> being set properly before it does static suspend fine.
> 
> Should I need to do any more thing to get it work?
> 
> Thanks,
> Gowda
> --
> 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
> --
> 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
> 

--
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

Re: OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi Tero et al.,

On Tue, 22 Jan 2013, Paul Walmsley wrote:

> As we've discussed, there are known bootloader dependencies with the OMAP4 
> PM retention idle code, introduced in v3.8.  Boards booted with u-boot 
> versions even as recent as 2011 won't enter retention idle correctly; for 
> example:
> 
>     http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt

...

> Barring that, what I'd like to see is a patch for v3.8-rc fixes that adds 
> a warning, printed to the kernel console, during boot.  The warning should 
> state that the OMAP4 PM code only works with certain bootloaders, and 
> should identify the minimum u-boot release needed for OMAP4 full-chip 
> retention idle to work.

Any progress on this one?  Time is getting very short to get this into 
v3.8-rc fixes, and it's important to get this into v3.8 so we don't 
have users expecting chip power management to work correctly with most 
u-boot versions that are out in the field.

All we should need for v3.8-rc are a few pr_warn()s that execute during 
OMAP4 PM init, noting that the OMAP4 chip power management doesn't work 
correctly with many bootloaders, due to missing code in the kernel to 
properly reset and initialize some devices, and noting the first u-boot 
version that is known to work correctly.

Otherwise there's a very real risk that folks out there will waste lots of 
time trying to figure out why power management doesn't work as they 
expect.   To respect our users, we shouldn't put them in that situation.


- Paul

OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi Tero et al.,

On Tue, 22 Jan 2013, Paul Walmsley wrote:

> As we've discussed, there are known bootloader dependencies with the OMAP4 
> PM retention idle code, introduced in v3.8.  Boards booted with u-boot 
> versions even as recent as 2011 won't enter retention idle correctly; for 
> example:
> 
>     http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt

...

> Barring that, what I'd like to see is a patch for v3.8-rc fixes that adds 
> a warning, printed to the kernel console, during boot.  The warning should 
> state that the OMAP4 PM code only works with certain bootloaders, and 
> should identify the minimum u-boot release needed for OMAP4 full-chip 
> retention idle to work.

Any progress on this one?  Time is getting very short to get this into 
v3.8-rc fixes, and it's important to get this into v3.8 so we don't 
have users expecting chip power management to work correctly with most 
u-boot versions that are out in the field.

All we should need for v3.8-rc are a few pr_warn()s that execute during 
OMAP4 PM init, noting that the OMAP4 chip power management doesn't work 
correctly with many bootloaders, due to missing code in the kernel to 
properly reset and initialize some devices, and noting the first u-boot 
version that is known to work correctly.

Otherwise there's a very real risk that folks out there will waste lots of 
time trying to figure out why power management doesn't work as they 
expect.   To respect our users, we shouldn't put them in that situation.


- Paul

Re: OMAP4 PM bootloader dependency problems

[Tero Kristo]

On Wed, 2013-01-30 at 17:15 +0000, Paul Walmsley wrote:
> Hi Tero et al.,
> 
> On Tue, 22 Jan 2013, Paul Walmsley wrote:
> 
> > As we've discussed, there are known bootloader dependencies with the OMAP4 
> > PM retention idle code, introduced in v3.8.  Boards booted with u-boot 
> > versions even as recent as 2011 won't enter retention idle correctly; for 
> > example:
> > 
> >     http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt
> 
> ...
> 
> > Barring that, what I'd like to see is a patch for v3.8-rc fixes that adds 
> > a warning, printed to the kernel console, during boot.  The warning should 
> > state that the OMAP4 PM code only works with certain bootloaders, and 
> > should identify the minimum u-boot release needed for OMAP4 full-chip 
> > retention idle to work.
> 
> Any progress on this one?  Time is getting very short to get this into 
> v3.8-rc fixes, and it's important to get this into v3.8 so we don't 
> have users expecting chip power management to work correctly with most 
> u-boot versions that are out in the field.
> 
> All we should need for v3.8-rc are a few pr_warn()s that execute during 
> OMAP4 PM init, noting that the OMAP4 chip power management doesn't work 
> correctly with many bootloaders, due to missing code in the kernel to 
> properly reset and initialize some devices, and noting the first u-boot 
> version that is known to work correctly.

Personally I don't like too much to have just extra spam during boot,
which in many cases is even unnecessary (e.g. people who actually have
good u-boot in use.) Personally I would like to have some sort of test
during boot which detects broken PM and maybe prevents core idle
completely if this is the case. Alternatively we can add extra info to
the failed suspend dump and mention a good u-boot to try out (v2012-07
or newer.)

If we could detect boot loader version from kernel side, that would work
also.

-Tero

> 
> Otherwise there's a very real risk that folks out there will waste lots of 
> time trying to figure out why power management doesn't work as they 
> expect.   To respect our users, we shouldn't put them in that situation.
> 
> 
> - Paul

OMAP4 PM bootloader dependency problems

[Tero Kristo]

On Wed, 2013-01-30 at 17:15 +0000, Paul Walmsley wrote:
> Hi Tero et al.,
> 
> On Tue, 22 Jan 2013, Paul Walmsley wrote:
> 
> > As we've discussed, there are known bootloader dependencies with the OMAP4 
> > PM retention idle code, introduced in v3.8.  Boards booted with u-boot 
> > versions even as recent as 2011 won't enter retention idle correctly; for 
> > example:
> > 
> >     http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt
> 
> ...
> 
> > Barring that, what I'd like to see is a patch for v3.8-rc fixes that adds 
> > a warning, printed to the kernel console, during boot.  The warning should 
> > state that the OMAP4 PM code only works with certain bootloaders, and 
> > should identify the minimum u-boot release needed for OMAP4 full-chip 
> > retention idle to work.
> 
> Any progress on this one?  Time is getting very short to get this into 
> v3.8-rc fixes, and it's important to get this into v3.8 so we don't 
> have users expecting chip power management to work correctly with most 
> u-boot versions that are out in the field.
> 
> All we should need for v3.8-rc are a few pr_warn()s that execute during 
> OMAP4 PM init, noting that the OMAP4 chip power management doesn't work 
> correctly with many bootloaders, due to missing code in the kernel to 
> properly reset and initialize some devices, and noting the first u-boot 
> version that is known to work correctly.

Personally I don't like too much to have just extra spam during boot,
which in many cases is even unnecessary (e.g. people who actually have
good u-boot in use.) Personally I would like to have some sort of test
during boot which detects broken PM and maybe prevents core idle
completely if this is the case. Alternatively we can add extra info to
the failed suspend dump and mention a good u-boot to try out (v2012-07
or newer.)

If we could detect boot loader version from kernel side, that would work
also.

-Tero

> 
> Otherwise there's a very real risk that folks out there will waste lots of 
> time trying to figure out why power management doesn't work as they 
> expect.   To respect our users, we shouldn't put them in that situation.
> 
> 
> - Paul

Re: OMAP4 PM bootloader dependency problems

[Rajendra Nayak]

Tero,

On Thursday 31 January 2013 02:30 PM, Tero Kristo wrote:
> Personally I don't like too much to have just extra spam during boot,
> which in many cases is even unnecessary (e.g. people who actually have
> good u-boot in use.) Personally I would like to have some sort of test
> during boot which detects broken PM and maybe prevents core idle
> completely if this is the case. Alternatively we can add extra info to
> the failed suspend dump and mention a good u-boot to try out (v2012-07
> or newer.)
>
> If we could detect boot loader version from kernel side, that would work
> also.

Given that there is no easy way to say for sure the bootloader is the
cause for broken PM in the kernel, neither is it possible to know the
bootloader version, why don't we do this.
Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note
that it isn't enabled by default in omap2plus_defconfig. Also
throw one when a suspend fails, saying bootloader *could be* a possible
cause specifying the right version to be used. That should give enough
hints to folks still using old bootloaders and testing PM.
Does that sound good?

regards,
Rajendra

OMAP4 PM bootloader dependency problems

[Rajendra Nayak]

Tero,

On Thursday 31 January 2013 02:30 PM, Tero Kristo wrote:
> Personally I don't like too much to have just extra spam during boot,
> which in many cases is even unnecessary (e.g. people who actually have
> good u-boot in use.) Personally I would like to have some sort of test
> during boot which detects broken PM and maybe prevents core idle
> completely if this is the case. Alternatively we can add extra info to
> the failed suspend dump and mention a good u-boot to try out (v2012-07
> or newer.)
>
> If we could detect boot loader version from kernel side, that would work
> also.

Given that there is no easy way to say for sure the bootloader is the
cause for broken PM in the kernel, neither is it possible to know the
bootloader version, why don't we do this.
Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note
that it isn't enabled by default in omap2plus_defconfig. Also
throw one when a suspend fails, saying bootloader *could be* a possible
cause specifying the right version to be used. That should give enough
hints to folks still using old bootloaders and testing PM.
Does that sound good?

regards,
Rajendra

Re: OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi,

On Thu, 31 Jan 2013, Tero Kristo wrote:

> Personally I don't like too much to have just extra spam during boot,
> which in many cases is even unnecessary (e.g. people who actually have
> good u-boot in use.)

The impact of two or three informative lines sent to the kernel console on 
boot is lower than the cost of people spending hours trying to figure out 
why chip retention idle doesn't work.

Linux distributions that control the bootloader version can easily 
comment out the warning.

I'm hoping the console messages will inspire someone out there to fix the 
root cause of the problem -- that the kernel is missing device 
reset and initialization code for several OMAP4 devices.

> Personally I would like to have some sort of test during boot which 
> detects broken PM and maybe prevents core idle completely if this is the 
> case.

As far as I know, a simple, clean test for this that can be merged 
right now doesn't exist, and has never been posted to the lists.

Personally, it's unclear how such a test can be implemented reliably.  
You've proposed checking IP block idle/standby states during PM init in 
previous E-mails.  But the problem with this is that those IP blocks might 
already be in use by their drivers by the time the OMAP4 PM code 
initializes.

It's also important to keep in mind that adding any significant amount of 
new code this late in the 3.8-rc cycle is not acceptable for my upstreams.

That said, if you have a clean, reliable, and short solution for this, 
please post it by the end of the week.

> Alternatively we can add extra info to the failed suspend dump and 
> mention a good u-boot to try out (v2012-07 or newer.)

Folks might be using dynamic idle, so just adding a message on resume from 
suspend isn't enough.

> If we could detect boot loader version from kernel side, that would work
> also.

I haven't seen any proposals for how to do this.  Even if one were 
available, it would require maintaining kernel blacklists.  Considering 
that the fault is in the kernel OMAP4 integration code and data, adding 
such a blacklist seems like the wrong approach.

...

In any case, all of the options that you've mentioned are workarounds, not 
real solutions.  Fixing the root cause would involve adding reset and 
initialization code for the remaining devices.  No one is working on this 
as far as I'm aware.  And even if they were, it would be too much code to 
add during the v3.8-rc fixes cycle.

I understand that you don't want to add an unconditional message on boot.  
But right now, it's the best approach.  Please post a patch for this by 
the end of this week that I or Kevin can send upstream ASAP.


regards,

- Paul

OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi,

On Thu, 31 Jan 2013, Tero Kristo wrote:

> Personally I don't like too much to have just extra spam during boot,
> which in many cases is even unnecessary (e.g. people who actually have
> good u-boot in use.)

The impact of two or three informative lines sent to the kernel console on 
boot is lower than the cost of people spending hours trying to figure out 
why chip retention idle doesn't work.

Linux distributions that control the bootloader version can easily 
comment out the warning.

I'm hoping the console messages will inspire someone out there to fix the 
root cause of the problem -- that the kernel is missing device 
reset and initialization code for several OMAP4 devices.

> Personally I would like to have some sort of test during boot which 
> detects broken PM and maybe prevents core idle completely if this is the 
> case.

As far as I know, a simple, clean test for this that can be merged 
right now doesn't exist, and has never been posted to the lists.

Personally, it's unclear how such a test can be implemented reliably.  
You've proposed checking IP block idle/standby states during PM init in 
previous E-mails.  But the problem with this is that those IP blocks might 
already be in use by their drivers by the time the OMAP4 PM code 
initializes.

It's also important to keep in mind that adding any significant amount of 
new code this late in the 3.8-rc cycle is not acceptable for my upstreams.

That said, if you have a clean, reliable, and short solution for this, 
please post it by the end of the week.

> Alternatively we can add extra info to the failed suspend dump and 
> mention a good u-boot to try out (v2012-07 or newer.)

Folks might be using dynamic idle, so just adding a message on resume from 
suspend isn't enough.

> If we could detect boot loader version from kernel side, that would work
> also.

I haven't seen any proposals for how to do this.  Even if one were 
available, it would require maintaining kernel blacklists.  Considering 
that the fault is in the kernel OMAP4 integration code and data, adding 
such a blacklist seems like the wrong approach.

...

In any case, all of the options that you've mentioned are workarounds, not 
real solutions.  Fixing the root cause would involve adding reset and 
initialization code for the remaining devices.  No one is working on this 
as far as I'm aware.  And even if they were, it would be too much code to 
add during the v3.8-rc fixes cycle.

I understand that you don't want to add an unconditional message on boot.  
But right now, it's the best approach.  Please post a patch for this by 
the end of this week that I or Kevin can send upstream ASAP.


regards,

- Paul

Re: OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi,

On Thu, 31 Jan 2013, Rajendra Nayak wrote:

> Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note
> that it isn't enabled by default in omap2plus_defconfig. Also
> throw one when a suspend fails, saying bootloader *could be* a possible
> cause specifying the right version to be used.

In my view, these steps aren't sufficient, for the reasons described in 

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

Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter 
full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it 
doesn't seem right to restrict a solution to that case.

regards,


- Paul

OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi,

On Thu, 31 Jan 2013, Rajendra Nayak wrote:

> Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note
> that it isn't enabled by default in omap2plus_defconfig. Also
> throw one when a suspend fails, saying bootloader *could be* a possible
> cause specifying the right version to be used.

In my view, these steps aren't sufficient, for the reasons described in 

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

Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter 
full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it 
doesn't seem right to restrict a solution to that case.

regards,


- Paul

Re: OMAP4 PM bootloader dependency problems

[Santosh Shilimkar]

On Thursday 31 January 2013 09:10 PM, Paul Walmsley wrote:
> Hi,
>
> On Thu, 31 Jan 2013, Rajendra Nayak wrote:
>
>> Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note
>> that it isn't enabled by default in omap2plus_defconfig. Also
>> throw one when a suspend fails, saying bootloader *could be* a possible
>> cause specifying the right version to be used.
>
> In my view, these steps aren't sufficient, for the reasons described in
>
> http://marc.info/?l=linux-omap&m=135964568904053&w=2
>
> Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter
> full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it
> doesn't seem right to restrict a solution to that case.
>

I think rajendra also mentioned adding one in suspend path too
when it fails.
" Also throw one when a suspend fails, saying bootloader
*could be* a possible cause specifying the right version to be used."

I find Rajendra's suggestion reasonable because some one might
just miss the boot message but getting the message on failure
case cant' be missed.

Regards
Santosh

OMAP4 PM bootloader dependency problems

[Santosh Shilimkar]

On Thursday 31 January 2013 09:10 PM, Paul Walmsley wrote:
> Hi,
>
> On Thu, 31 Jan 2013, Rajendra Nayak wrote:
>
>> Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note
>> that it isn't enabled by default in omap2plus_defconfig. Also
>> throw one when a suspend fails, saying bootloader *could be* a possible
>> cause specifying the right version to be used.
>
> In my view, these steps aren't sufficient, for the reasons described in
>
> http://marc.info/?l=linux-omap&m=135964568904053&w=2
>
> Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter
> full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it
> doesn't seem right to restrict a solution to that case.
>

I think rajendra also mentioned adding one in suspend path too
when it fails.
" Also throw one when a suspend fails, saying bootloader
*could be* a possible cause specifying the right version to be used."

I find Rajendra's suggestion reasonable because some one might
just miss the boot message but getting the message on failure
case cant' be missed.

Regards
Santosh

Re: OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi,

On Thu, 31 Jan 2013, Santosh Shilimkar wrote:

> On Thursday 31 January 2013 09:10 PM, Paul Walmsley wrote:
> > On Thu, 31 Jan 2013, Rajendra Nayak wrote:
> > 
> > > Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note
> > > that it isn't enabled by default in omap2plus_defconfig. Also
> > > throw one when a suspend fails, saying bootloader *could be* a possible
> > > cause specifying the right version to be used.
> > 
> > In my view, these steps aren't sufficient, for the reasons described in
> > 
> > http://marc.info/?l=linux-omap&m=135964568904053&w=2
> > 
> > Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter
> > full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it
> > doesn't seem right to restrict a solution to that case.
> > 
> 
> I think rajendra also mentioned adding one in suspend path too
> when it fails.
> " Also throw one when a suspend fails, saying bootloader
> *could be* a possible cause specifying the right version to be used."
> 
> I find Rajendra's suggestion reasonable because some one might
> just miss the boot message but getting the message on failure
> case cant' be missed.

Right.  I don't have any problem with adding a message to the suspend path 
also.  But I'd like to see a boot-time message added even if 
CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention 
idle with dynamic idle.  In other words, not everyone might use 'echo mem 
> /sys/power/state'.


- Paul

OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi,

On Thu, 31 Jan 2013, Santosh Shilimkar wrote:

> On Thursday 31 January 2013 09:10 PM, Paul Walmsley wrote:
> > On Thu, 31 Jan 2013, Rajendra Nayak wrote:
> > 
> > > Throw a pr_warn() at boot only when CONFIG_CPU_IDLE is enabled. Note
> > > that it isn't enabled by default in omap2plus_defconfig. Also
> > > throw one when a suspend fails, saying bootloader *could be* a possible
> > > cause specifying the right version to be used.
> > 
> > In my view, these steps aren't sufficient, for the reasons described in
> > 
> > http://marc.info/?l=linux-omap&m=135964568904053&w=2
> > 
> > Even with CONFIG_CPU_IDLE=n, it's still possible to attempt to enter
> > full-chip retention idle on OMAP4 via 'echo mem > /sys/power/state', so it
> > doesn't seem right to restrict a solution to that case.
> > 
> 
> I think rajendra also mentioned adding one in suspend path too
> when it fails.
> " Also throw one when a suspend fails, saying bootloader
> *could be* a possible cause specifying the right version to be used."
> 
> I find Rajendra's suggestion reasonable because some one might
> just miss the boot message but getting the message on failure
> case cant' be missed.

Right.  I don't have any problem with adding a message to the suspend path 
also.  But I'd like to see a boot-time message added even if 
CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention 
idle with dynamic idle.  In other words, not everyone might use 'echo mem 
> /sys/power/state'.


- Paul

Re: OMAP4 PM bootloader dependency problems

[Paul Walmsley]

On Thu, 31 Jan 2013, Paul Walmsley wrote:

> Right.  I don't have any problem with adding a message to the suspend path 
> also.  But I'd like to see a boot-time message added even if 
> CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention 
> idle with dynamic idle.  In other words, not everyone might use 'echo mem 
> > /sys/power/state'.

(and re-reading my original E-mail to Rajendra, I can see that it was 
nuclear, so I'm sorry about that.)


- Paul

OMAP4 PM bootloader dependency problems

[Paul Walmsley]

On Thu, 31 Jan 2013, Paul Walmsley wrote:

> Right.  I don't have any problem with adding a message to the suspend path 
> also.  But I'd like to see a boot-time message added even if 
> CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention 
> idle with dynamic idle.  In other words, not everyone might use 'echo mem 
> > /sys/power/state'.

(and re-reading my original E-mail to Rajendra, I can see that it was 
nuclear, so I'm sorry about that.)


- Paul

Re: OMAP4 PM bootloader dependency problems

[Paul Walmsley]

On Thu, 31 Jan 2013, Paul Walmsley wrote:

> On Thu, 31 Jan 2013, Paul Walmsley wrote:
> 
> > Right.  I don't have any problem with adding a message to the suspend path 
> > also.  But I'd like to see a boot-time message added even if 
> > CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention 
> > idle with dynamic idle.  In other words, not everyone might use 'echo mem 
> > > /sys/power/state'.
> 
> (and re-reading my original E-mail to Rajendra, I can see that it was 
> nuclear, so I'm sorry about that.)

Hehe, _unclear_.  Time to go back to bed...


- Paul

OMAP4 PM bootloader dependency problems

[Paul Walmsley]

On Thu, 31 Jan 2013, Paul Walmsley wrote:

> On Thu, 31 Jan 2013, Paul Walmsley wrote:
> 
> > Right.  I don't have any problem with adding a message to the suspend path 
> > also.  But I'd like to see a boot-time message added even if 
> > CONFIG_CPU_IDLE=n, since it's still possible to enter full-chip retention 
> > idle with dynamic idle.  In other words, not everyone might use 'echo mem 
> > > /sys/power/state'.
> 
> (and re-reading my original E-mail to Rajendra, I can see that it was 
> nuclear, so I'm sorry about that.)

Hehe, _unclear_.  Time to go back to bed...


- Paul

Re: OMAP4 PM bootloader dependency problems

[Jon Hunter]

Hi Paul,

On 01/21/2013 08:42 PM, Paul Walmsley wrote:
> 
> Hi Tero, Rajendra, Santosh,
> 
> As we've discussed, there are known bootloader dependencies with the OMAP4 
> PM retention idle code, introduced in v3.8.  Boards booted with u-boot 
> versions even as recent as 2011 won't enter retention idle correctly; for 
> example:
> 
>     http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt
> 
> The right thing for you all to do is what was done for OMAP3: to add code 
> to correctly reset and initialize these on-chip devices.  However, since 
> it's already late in the v3.8-rc cycle, this seems unlikely to happen in 
> time for the v3.8 release -- and that's assuming that you guys are working 
> on this, which I'm unsure of.

I noticed on my OMAP4430 SDP that in suspend L3INIT was failing to enter 
retention state. I am not sure if this is the same problem that you are 
seeing or not. However, I found that the reason the L3INIT was not entering
retention on this board was because the USB DPLL was not locked by the
bootloader on this board. On my panda the USB DPLL is locked the L3INIT 
is entering suspend. 

I crafted the following which is working on my omap4430 panda, sdp and 
omap4460 panda. Let me know what you think ...

Cheers
Jon

>From 3bfe708af8e91564bc78c79111f9080a35fb5b88 Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Tue, 5 Feb 2013 13:27:57 -0600
Subject: [PATCH] ARM: OMAP4: Fix low power in kernel suspend

Some versions of the u-boot bootloader do not lock the USB DPLL and
when the USB DPLL is not locked, then it is observed that the L3INIT
power domain does not transition to retention state during kernel
suspend on OMAP4 devices. Fix this by locking the USB DPLL at 960 MHz
on kernel boot.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/cclock44xx_data.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index e71a19c..2c811d9 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -48,6 +48,13 @@
  */
 #define OMAP4_DPLL_ABE_DEFFREQ				98304000
 
+/*
+ * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
+ * "3.6.3.9.5 DPLL_USB Preferred Settings" shows that the preferred
+ * locked frequency for the USB DPLL is 960MHz.
+ */
+#define OMAP4_DPLL_USB_DEFFREQ				960000000
+
 /* Root clocks */
 
 DEFINE_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 59000000, 0x0);
@@ -2045,5 +2052,13 @@ int __init omap4xxx_clk_init(void)
 	if (rc)
 		pr_err("%s: failed to configure ABE DPLL!\n", __func__);
 
+	/*
+	 * Lock USB DPLL on OMAP4 devices so that the L3INIT power
+	 * domain can transition to retention state when not in use.
+	 */
+	rc = clk_set_rate(&dpll_usb_ck, OMAP4_DPLL_USB_DEFFREQ);
+	if (rc)
+		pr_err("%s: failed to configure USB DPLL!\n", __func__);
+
 	return 0;
 }
-- 
1.7.10.4

OMAP4 PM bootloader dependency problems

[Jon Hunter]

Hi Paul,

On 01/21/2013 08:42 PM, Paul Walmsley wrote:
> 
> Hi Tero, Rajendra, Santosh,
> 
> As we've discussed, there are known bootloader dependencies with the OMAP4 
> PM retention idle code, introduced in v3.8.  Boards booted with u-boot 
> versions even as recent as 2011 won't enter retention idle correctly; for 
> example:
> 
>     http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt
> 
> The right thing for you all to do is what was done for OMAP3: to add code 
> to correctly reset and initialize these on-chip devices.  However, since 
> it's already late in the v3.8-rc cycle, this seems unlikely to happen in 
> time for the v3.8 release -- and that's assuming that you guys are working 
> on this, which I'm unsure of.

I noticed on my OMAP4430 SDP that in suspend L3INIT was failing to enter 
retention state. I am not sure if this is the same problem that you are 
seeing or not. However, I found that the reason the L3INIT was not entering
retention on this board was because the USB DPLL was not locked by the
bootloader on this board. On my panda the USB DPLL is locked the L3INIT 
is entering suspend. 

I crafted the following which is working on my omap4430 panda, sdp and 
omap4460 panda. Let me know what you think ...

Cheers
Jon

>From 3bfe708af8e91564bc78c79111f9080a35fb5b88 Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Tue, 5 Feb 2013 13:27:57 -0600
Subject: [PATCH] ARM: OMAP4: Fix low power in kernel suspend

Some versions of the u-boot bootloader do not lock the USB DPLL and
when the USB DPLL is not locked, then it is observed that the L3INIT
power domain does not transition to retention state during kernel
suspend on OMAP4 devices. Fix this by locking the USB DPLL at 960 MHz
on kernel boot.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 arch/arm/mach-omap2/cclock44xx_data.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index e71a19c..2c811d9 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -48,6 +48,13 @@
  */
 #define OMAP4_DPLL_ABE_DEFFREQ				98304000
 
+/*
+ * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
+ * "3.6.3.9.5 DPLL_USB Preferred Settings" shows that the preferred
+ * locked frequency for the USB DPLL is 960MHz.
+ */
+#define OMAP4_DPLL_USB_DEFFREQ				960000000
+
 /* Root clocks */
 
 DEFINE_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 59000000, 0x0);
@@ -2045,5 +2052,13 @@ int __init omap4xxx_clk_init(void)
 	if (rc)
 		pr_err("%s: failed to configure ABE DPLL!\n", __func__);
 
+	/*
+	 * Lock USB DPLL on OMAP4 devices so that the L3INIT power
+	 * domain can transition to retention state when not in use.
+	 */
+	rc = clk_set_rate(&dpll_usb_ck, OMAP4_DPLL_USB_DEFFREQ);
+	if (rc)
+		pr_err("%s: failed to configure USB DPLL!\n", __func__);
+
 	return 0;
 }
-- 
1.7.10.4

Re: OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi Jon,

sorry for the delay,

On Tue, 5 Feb 2013, Jon Hunter wrote:

> I noticed on my OMAP4430 SDP that in suspend L3INIT was failing to enter 
> retention state. I am not sure if this is the same problem that you are 
> seeing or not. However, I found that the reason the L3INIT was not entering
> retention on this board was because the USB DPLL was not locked by the
> bootloader on this board. On my panda the USB DPLL is locked the L3INIT 
> is entering suspend. 
> 
> I crafted the following which is working on my omap4430 panda, sdp and 
> omap4460 panda. Let me know what you think ...

Looks fine to me.  It doesn't fix the problem I'm seeing with OMAP4 
L3INIT, unfortunately.  But it sounds like it fixes a problem for you -- 
which means it probably fixes something for other people too.  Queued
for v3.9-rc.


- Paul

OMAP4 PM bootloader dependency problems

[Paul Walmsley]

Hi Jon,

sorry for the delay,

On Tue, 5 Feb 2013, Jon Hunter wrote:

> I noticed on my OMAP4430 SDP that in suspend L3INIT was failing to enter 
> retention state. I am not sure if this is the same problem that you are 
> seeing or not. However, I found that the reason the L3INIT was not entering
> retention on this board was because the USB DPLL was not locked by the
> bootloader on this board. On my panda the USB DPLL is locked the L3INIT 
> is entering suspend. 
> 
> I crafted the following which is working on my omap4430 panda, sdp and 
> omap4460 panda. Let me know what you think ...

Looks fine to me.  It doesn't fix the problem I'm seeing with OMAP4 
L3INIT, unfortunately.  But it sounds like it fixes a problem for you -- 
which means it probably fixes something for other people too.  Queued
for v3.9-rc.


- Paul