On Thursday 28 October 2004 11:22, Patrick Mochel wrote: > > On Thu, 28 Oct 2004, David Brownell wrote: > > > > > 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 And right here, write the state to disk -- with records indicating some state that help make resume work "better". An example would be the saved PCI state and the I/O queues for the devices. Filesystems would presumably flush (and maybe invalidate) caches in the "stop all devices" stage; or would that be earlier still? > - 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. Yes. And the "status quo" is that a u32 cookie, variously interpreted, gets passed down for drivers to use during that "Stop All Devices" phase. (I still like the word "Freeze" there, BTW...) > 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.) Aren't suspend(dev,to_sleep_state) --> stop() resume(dev) --> start() except for probe(dev) --> init() and shutdown(dev) --> shutdown() I'm not sure I see a benefit to changing the names for those driver lifecycle events. > Does that make sense? For now, yes. - Dave > > 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 >
