Re: DSS2/PM on 3.2 broken?

[Kevin Hilman <khilman@ti.com>]

Tomi Valkeinen <tomi.valkeinen@ti.com> writes:

> On Thu, 2012-01-12 at 14:40 -0800, Kevin Hilman wrote:
>> Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
>> 
>> > On Mon, 2012-01-09 at 12:46 +0000, Joe Woodward wrote:
>> >> I'm running on a Gumstix Overo (OMAP3530) with an 24-bit LCD panel connected via the DPI interface (using the generic panel driver).
>> >> 
>> >> Entering standby used to work just fine on 3.0, but on 3.2 I get the following:
>> >
>> > I've been debugging this, but I'm at loss. I added some debug prints,
>> > which I show below, and I also pushed them to
>> > "git://gitorious.org/linux-omap-dss2/linux.git pm-test-prints" if
>> > somebody wants to see exactly what they print.
>> >
>> > Kevin, perhaps you have an idea what could be wrong here. Long version
>> > below, short version: doing system suspend breaks omapdss, if omapdss
>> > uses pm_runtime_put, but works with pm_runtime_put_sync.
>> 
>> Is the pm_runtime_put() done after system suspend has started?  
>> 
>> After system suspend has begun, the workqueue used for async callbacks
>> is frozen, so any runtime PM calls that you want to work during
>> suspend/resume must use the _sync versions.
>
> pm_runtime_put() is called inside omapdss driver's .suspend callback. So
> I guess that means the system suspend has started. However, the logs
> show that the runtime_suspend callback _is_ being called before the
> system suspend is finished, so the workqueue can't be frozen...

...or there are other ways that the runtime_suspend callback is called.

In order to ensure that devices are properly idled for system-wide
suspend, The OMAP PM domain layer will call the drivers
->runtime_suspend callback during "late" suspend (using the PM domain's
_noirq callbacks.)

This is there so that even when runtime PM has been disabled (via
userspace, or pm_runtime_forbid() calls) the driver can still be
properly idled before suspend.

In your case, I suspect you're seeing the driver's ->runtime_suspend
callback called during late suspend, not by the PM workqueue.

I don't understand DSS enough to make sense of the logs you sent, so not
sure how to be of more help.

Kevin