On Thu, 28 Oct 2004, David Brownell wrote:
> On Thursday 28 October 2004 01:26, Patrick Mochel wrote:
> >
> > [ Starting to catch up on email.. ]
> >
>
> Me too ... lots of PM-related stuff, it's good to at least
> have it in one queue now!
>
>
> > I assume that the idea is still to have multiple calls to perform the
> > entire transition - the first being to queisce the driver and stop any
> > activity; the second being to perform the actual power transition.
> > (Actually, there should be three - an additional one in the middle to save
> > the device states.)
> >
> > Do we agree on that?
>
> Actually the point I've been meaning to chime in on here is
> that since, as Benjamin noted, if there's a "write to storage"
> step (STD, not STR) it uses the "quiesced"/"frozen" system
> state ... then the real problem is just that the current
> framework **resumes way too many devices** when writing that
> out to swap. (Which is a fourth step...)
Ok, we need to dissect this a little more.
>From a conceptual level (not necessarily with this level of granularity in
the methods drivers will have), for STD, we want to
- Stop All Devices
- Save Device State
- Start swap device back up
- Stop swap device
- Power down devices
- For ACPI S4, we actually want them to put devices in a low-power state
This is important to support this, since a) it's part of the spec, and
b) some wakeup events are available to this and not S5.
- For shutdown, this would be whatever the ->shutdown() method does.
Point being there is a policy decision as to what we do on STD WRT power
state. We must provide for that.
As far as methods go, we make our lives easier (in a way) by having a
totally separate method pair (start() and stop()), since it's the same
action no matter what. Plus, it's an easy hook to add and gives a nice
thing to test along the way (e.g. it would simple to only stop() all
devices and see if all the drivers get it right, without having to play
with power states and worry about crashing your system.)
Does that make sense?
> Most of the PITA that I'm seeing with USB should be easily
> resolved by only resuming the swap device (and ancestors),
> and that would simplify the suspend model for almost all
> drivers. (Except for swap devices, and ancestors, which
> would still need special attentions: appropriate.)
I agree.
Pat
