On Wed, 2013-01-30 at 17:15 +0000, Paul Walmsley wrote:

Hi Tero et al.,

On Tue, 22 Jan 2013, Paul Walmsley wrote:

quoted

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

...

quoted

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