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:
signature.asc
Description: This is a digitally signed message part
