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. 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. > 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. > > > > Just read the paper David did summarizing our discussions, I think it's > > > pretty clear the kind of callbacks we need. > > > > We really should put it somewhere in Documentation/ so this kind of > > discussion does not repeat... > > I'll send along an updated version as soon as some of the more > recent points get settled. That was just a first whack, and > pretty much everyone here has disagreed today with at least > some of what's in that draft ... ;) > > - Dave -- Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
