Re: DSS2/PM on 3.2 broken?

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

Hi,

On Wed, 2012-01-11 at 15:15 +0000, Joe Woodward wrote:

> > The pm_runtime_get_sync() call in dss_runtime_get() is returning  a 
> > negative value, could you print out that value too?
> > 
> > If the call to pm_runtime_get_sync() fails, we bail out immediately. So
> > the LCD interface shouldn't have been enabled at all. I don't know why 
> > we get sync lost errors.
> > 
> > There is a possibility that the LCD interface wasn't switched off when 
> > for some reason when we suspended, and switching on the clocks again 
> > tries to start the transfer without DSS being configured correctly?

I can reproduce this on my Overo. The problem goes away if I change
dss's and dispc'c pm_runtime_put() calls to pm_runtime_put_sync(). But
I'm not quite sure why.

I would imagine that the pm framework would flush the async
pm_runtime_put calls before the system goes into suspend. Comparing the
logs of successful and non-successful suspends it seems that the order
of suspend and resume events changes. Perhaps the suspend goes fine, but
for whatever reason the resume calls happen in a different order,
causing the problems. I need to study this more to understand the
problem.

Kevin, can you confirm that just using pm_runtime_put() is enough even
in system suspend case, and the framework handles doing the runtime_put
before suspending?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]