On Wed, 15 Jun 2011, Kevin Hilman wrote: > "Rafael J. Wysocki" <rjw@xxxxxxx> 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. Another difference is that the user can forbid runtime power management of any device through the power/control attribute, independently of system sleeps. Yet another difference arises because during system PM, the PM workqueue is frozen. If a driver relies on asynchronous runtime PM then nothing will happen. This may not apply to you, but it applies to plenty of other drivers. > 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? What you're missing is that runtime PM has two separate aspects: a hardware/power aspect and an administrative aspect. In terms of hardware/power it is very similar to system PM, but in administrative terms it is quite different. Another thing you need to realize: Rafael is open to the idea that subsystems may be designed specifically to allow drivers to use runtime PM during their ->suspend and ->resume callbacks. However in the period between ->suspend returning and ->resume being called, runtime PM should _not_ be used. In particular, this includes the times when ->suspend_noirq and ->resume_noirq are called -- and these are the routines which are often expected to do the real work of setting the device's power state. Alan Stern -- 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
