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

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Monday 24 July 2006 05:22, David Brownell wrote:
> On Sunday 23 July 2006 3:45 pm, Rafael J. Wysocki wrote:
> > On Sunday 23 July 2006 15:03, Alan Stern wrote:
> > > On Sun, 23 Jul 2006, Rafael J. Wysocki wrote:
> > > ... In other words, devices get restored to the state 
> > > they were in before suspend.
> > 
> > Yes.
> >
> > > I don't see anything wrong with that.  It does raise some more questions.
> > > 
> > > 	Who should be responsible for remembering the device's state
> > > 	from before the system suspend: the PM core or the driver?
> > > 	(Note that the driver has a better idea of what that state
> > > 	actually was.)
> > 
> > It seems to be easier to leave it to the driver.
> 
> Just the way any true runtime pm operation would be, yes?

I think so.

> > However, I think the core 
> > needs to have at least some control over it.   Otherwise, for example,
> > the detection of misbehaving drivers would be quite difficult, IMHO.
> 
> Remember that the definition of runtime PM under discussion is:
> 
> > > >    2   While the system is running, independently of other power management
> > > >        activity.  Upstream drivers will normally not know (or care) if the
> > > >        device is in some low power state when issuing requests; the driver
> > > >        will auto-resume anything that's needed when it gets a request.
> 
> That excludes the core having any such "control", or the ability to "detect"
> such misbehavior.  (And why would it be misbehavior, when the difference is
> irrelevant to upstream drivers issuing requests to that device?)  No matter
> what state the device resumes into, the only architectural requirement is
> that it respond as if it were fully "on".  Because runtime low power states
> are exactly equivalent to "fully operational" except they use less power.
>
> > > 	Upon resuming from a system suspend, is it better to tell the
> > > 	driver to "go directly to the saved state" or to turn the
> > > 	device back fully ON and then change to the saved state (if it 
> > > 	wasn't fully ON before the system suspend)?
> > 
> > I think the rule should be "go directly to the saved state", if possible.
> 
> Agreed, though as I described above it's not something that can be
> detected outside of that driver without actually measuring the power
> drain that driver imposes on the system.

And that would be difficult if not impossible.

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.

Greetings,
Rafael