Tomi Valkeinen <tomi.valkei...@ti.com> writes: > On Thu, 2012-01-19 at 11:24 -0800, Kevin Hilman wrote: >> Tomi Valkeinen <tomi.valkei...@ti.com> writes: > >> > Now, you already said using pm_runtime_put_sync version is the correct >> > way when suspending. But to use that I need to either always use >> > pm_runtime_put_sync, or add an extra boolean which marks that we're >> > suspending, and pass that around, or make it a DSS global variable. >> >> I'm not sure why can't you use the sync version just in the suspend >> callback? > > To do that the suspend callback should be the one that disables the > device and calls pm_runtime_suspend. With DSS that's not the case, it's > the panel drivers that are in charge of enabling/disabling DSS (by > calling appropriate functions in omapdss).
Ah, OK. makes sense. > The only thing that the omapdss suspend callback does is to call the > normal disable functions on the display drivers. This leads to calls to > disable-functions on the dss hwmod drivers, and then pm_runtime_put > calls. But at the point the pm_runtime funcs are called, the code has no > idea that we're actually doing system suspend. Thus I'd need to pass > that information somehow, probably with a global variable. > > And while that's not difficult to do, it sure feels a bit ugly. > > I think I'll just change the pm_runtime_put calls to sync versions for > now. I imagine the perf impact with the change should be negligible. > I'll return to this issue after the devtree adaptation has been made, as > it changes the child-parent relations of the dss related devices, and > perhaps managing the PM states will also get a bit easier. Sounds reasonable. Kevin -- 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
