"Rafael J. Wysocki" <[email protected]> writes: > On Wednesday, June 15, 2011, Kevin Hilman wrote:
[...] >> >> From a device driver perspective, system PM is just runtime >> PM where the "idleness" was forced and only a subset of possible wakeup >> sources are enabled. > > Oh well, I wonder how much of a difference would make you think those things > are really different. ;-) Seeing a description of the differences would help. So far the list is rather short: wakeups and forcibly quieting the hardware. I guess I still don't see why system PM cannot be viewed as a special case of runtime PM, so how about a specific question: From a device driver perspective, how is system PM anything other than manually/forcibly creating the right conditions for a runtime PM transition to happen? [...] >> The development effort is primarily >> focused on implementing efficient runtime PM for an _active_ system. >> When this is working, implementing system PM is easy: all that is needed >> is to enable/disable relevant wakeups and force the device to idle. >> This allows runtime PM to trigger, and the device is suspended. > > No, it doesn't. What you're trying to do is to "maunally" trigger runtime PM No. What I'm trying to do in .suspend() is create the conditions necessary such that a runtime PM transition will occur *by itself*. If the right conditions exist (namely, idle HW, no pending activity, etc.) a runtime PM transition will happen *on its own*, and will not need to be manually triggered. IOW, a runtime PM transition is a side effect of creating the right idle conditions. > when _you_ think is suitable. No, only when a system suspend is requested by the user. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
