Re: RFC -- updated Documentation/power/devices.txt

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

On Monday 24 July 2006 7:51 am, Alan Stern wrote:
> On Mon, 24 Jul 2006, Rafael J. Wysocki wrote:

> > So, it looks like the core will only need to tell the driver to "resume"
> > with the implicit "go directly to the saved state" meaning and the
> > driver will actually decide what to do.
> 
> And this implies that the meanings of the suspend() and resume() method
> calls are different from what people might normally think.

No ...

> suspend()   
> doesn't really mean "Put your device into a low-power state"; it means
> "The system is going into a suspend, so remember the device's current
> power state and take whatever actions are appropriate".

Which is exactly what it means today.


> For example, if 
> the device is already in a low-power state then it might be appropriate to
> do nothing at all.

Ditto.


> Likewise, resume() doesn't mean "Change your device to fully ON"; it means
> "The system is waking up from a suspend, so put your device back into
> whatever power state it was in before the suspend occurred".

It means "put it back in a fully operational state".

And whether that state is "full on", or one of the "runtime suspend" states,
or whether it goes into "full on" and then automagically into a "runtime suspend",
doesn't matter externally.  And can't even be noticed without test setups
measuring differential power usage between different configurations...


> These meanings may not be entirely consistent with the way the PM core
> works now,

I don't believe any semantic change is being discussed here.


> but to me they make more sense.  To make the core consistent 
> with this approach wouldn't require much of a change.  Basically we just
> have to rip out all the stuff referring to dev->power.power_state, which
> needs to be done anyway.

Considering how few drivers use dev->power.power_state, it's easier to
say the problem is in the ones that use it  ... rather than the ones that
ignore it and act as I've described above! :)

- Dave



> Alan Stern
>