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