Tomi Valkeinen <tomi.valkeinen@xxxxxx> writes: > On Thu, 2012-01-12 at 14:40 -0800, Kevin Hilman wrote: >> Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
