On Thursday 28 October 2004 16:26, Benjamin Herrenschmidt wrote: > On Thu, 2004-10-28 at 16:15 -0700, David Brownell wrote: > > On Thursday 28 October 2004 15:49, Pavel Machek wrote: > > > > > > > You enter a state, you always go back to state 0 (resumed) before > > > > entering another one. Period. That's the basis of why I got > > > > save_state() removed in the first place, remember ? > > > > Hmm, I was thinking that we had already discussed this > > as letting _drivers_ choose whether or not to fully > > resume. When suspending, it gets told the target sleep > > state, and the DRIVER is responsible for sorting out > > what that means for the hardware state and capabilities. > > We have to broadcast a wakeup message between freeze and last suspend. > If we don't, your "parent" driver won't be able to process your > requests. I still don't see "broadcast" as a completely intuitive phrase here; it'd need to respect tree structure ... thaw/resume must go top-down, and freeze/suspend must go bottom-up. Of course Linux currently has several non-connected device trees, and you've pointed out that there are recipients of those messages that aren't device trees... message delivery order shouldn't matter between device trees, and for some of the others it might not matter either. > That is, STD looks like: > > - broadcast freeze > - pmdisk core does snapshot of memory etc... > - broadcast wake > - write to disk > - broadcast suspend or shutdown > > The wake before write to disk has to be global if you want devices to be > able to do anything useful in the last step (suspend or shutdown) when > they rely on a parent driver (like USB devices rely on OHCI) or else the > drivers won't be able to talk to their devices. There's no need for "broadcast" or "global"; the only stuff that needs to be resumed -- USB is no exception! -- is the path from dev through dev->parent up to the root of that particular subtree. > > This gets to the subtree-suspend issues too; I think > > there does need to be a designated "active" state (0) > > that the interior nodes (hubs, bridges, etc) must be > > in before Linux changes child state. > > If we do subtree, we could indeed put everybody _but_ the swap device > into suspend/shutdown right away, and the subtree to swap only in > freeze. In this case, only that subtree need to be woken up, and then > fully suspended again. We could, but That Sounds Needlessly Complicated. - Dave
