[ Starting to catch up on email.. ] On Mon, 18 Oct 2004, Benjamin Herrenschmidt wrote: > On Mon, 2004-10-18 at 09:36, Pavel Machek wrote: > > Hi! > > > > > > That is not what I mean. In non-modular resume case, this happens: > > > > > > Well... STD has actually a total of 4 transitions, for which we may > > > want to provide a way for drivers to know where they are going on > > > then: > > > > Actually there's 5 of them: > > Oops, right, see, I'm not properly woken up yet :) > > > > 1 - Initial freeze for snapshot > > 1a - Unfreeze so image can be written > > > 2 - Suspend or PowerDown > > > 3 - Freeze before resume > > > 4 - Unfreeze after resume > > > > > > And no state variable can be kept since 2 is done after the state > > > snapshot, and 3 is done on a freshly booting kernel. > > ... > > > So what do we do here. Do we still have a single PM_FREEZE (or whatever > > > we call it) message and a single resume() and stuff the details somewhere > > > else or do we pass a richer message ? > > > > Actually stuffing the details somewhere else (system_state) was tried > > before, it got past Andrew but Patrick did not like it. > > Me neither. And we are talking about doing something sane for now. > > > > We could break up the message in two. state_major & state_minor... that > > > would give us something like > > > > > > PM_FREEZE_STD_SNAPSHOT > > > PM_FREEZE_STD_RESUME > > > PM_FREEZE_STD_KEXEC > > > > Or we could always pass full state and have helpers that tell "easy" > > version (i.e. PM_FREEZE) to simple drivers. Hopefully no drivers will > > ever use full information but we want it there. > > I'm open to both solutions here. David, what do you prefer ? Patrick ? We need better vocabulary. In previous messages, you mixed 'freeze' and 'suspend'; and 'unfreeze' and 'resume'. Each one of those has differently defined semantics in other contexts. 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? if so (and I'll try not to stray too far here), then we should agree on what to call those. I propose the following names, with another parameter that is passed to the method called containing the system state we're about to enter(the encoding of which is momentarily irrelevant): - Stop - Save - Power With the converse actions being - Power (yes, the naming is intentional, since it should just be flipping power state bits) - Restore - Start Thoughts? Pat
