Re: calling runtime PM from system PM methods

"Rafael J. Wysocki" [off-list ref] writes:

On Wednesday, June 15, 2011, Kevin Hilman wrote:

[...]

quoted

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?

[...]

quoted

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