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