Re: calling runtime PM from system PM methods

On Friday, June 10, 2011, Mark Brown wrote:

On Thu, Jun 09, 2011 at 09:56:48AM -0400, Alan Stern wrote:

quoted

On Wed, 8 Jun 2011, Kevin Hilman wrote:

quoted

quoted

Runtime suspend
2. activity finishes

quoted

quoted

system suspend [echo mem > /sys/power/state]
2. prevent future activity, halt/wait for current activity

quoted

quoted

The only difference is step 2.

quoted

That _is_ the main difference, and it's a big one.  (As Magnus pointed 
out, wakeup-enabling is another difference).

...

quoted

They don't have to be decoupled, and indeed they can share code.  The 
point Rafael and I are making is that they have to use different 
callback pointers, which gives you a chance to handle the differences 
as well as the similarities.

It seems like everyone's agreeing with each other here - from the user
side the request seems to be largely for core infastructure like
UNIVERSAL_DEV_PM_OPS() (which I'm not sure is a good idea any more given
that it doesn't do anything to handle the runtime/system interaction?).

I'm not sure what you mean here.  First, UNIVERSAL_DEV_PM_OPS() actually
does what it says, defines a set of operations to use for system suspend,
hibernation and runtime PM all the same.

Right now this all feels like more work than it should be in simpler
drivers.

My impression is that you and Kevin are talking of different things.

The Kevin's point originally was that it might be desirable to do things
like calling pm_runtime_suspend() from a driver's (system) .suspend()
callback, if I understood it correctly, and the answer was that it wasn't
the right thing to do (for reasons given elsewhere in the thread).

Your point seems to be that simple drivers should not be required to
define separate callback routines, for example, for system suspend and
runtime PM.  However, they aren't required to do so, they can point
all of their "suspend" callback pointers to the same routine, which is
what the UNIVERSAL_DEV_PM_OPS() macro does.

Thanks,
Rafael