Re: [PATCH] implement pm_ops.valid for everybody

[David Brownell <david-b@pacbell.net>]

On Thursday 22 March 2007 2:56 pm, Guennadi Liakhovetski wrote:
> On Thu, 22 Mar 2007, David Brownell wrote:
> 
> > STR shuts down a lot more.  Not necessarily powering down the CPU
> > (which is what would cause the need for boot/BIOS code to have the
> > "this is really a resume" cases, and isn't always possible), but at
> > least being more agressive about powering down clocks and such.
> 
> Dave, sorry, maybe I am being dense the whole time, but - "more" than 
> what??? If you implement several modes, ok, you can compare them. But if 
> you only implement one suspend mode for whatever reason - what are you 
> comparing it to? 

How about ... that canonical trivial "standby" mode I described,
where the CPU doesn't do much more than what a power-naive idle loop
might be doing?  Almost any system can do that much.

On ARM that'd be a wait-for-interrupt instruction; some other CPUs
may have analagous instructions that explicitly try to save some power,
which might not be good for an idle loop.  And some systems may have
power saving to wrap around that WFI; the idle loop might even use them.

Take it from first principles, and assume today's typical case where
drivers don't (can't!! sigh) do anything different in standby vs STR.
Then the *only* difference will be what pm_enter/pm_exit can do ...
and that's going to be primarly "what does the CPU do".

So if pm_enter is doing fancy stuff to the CPU, like re-clocking it
or powering it off ... that's more of an STR than a "standby".  As
Rafael put it, the resume then requires a "boot-like procedure".

Of course this is all points on a spectrum, and different systems
can work very differently.  Which is why I don't like the idea of
trying to place hard requirements on what STR or standby must be;
a platform could very easily support two useful power states, where
neither fits such "hard" labels.

- Dave