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 ? > > Among the "open" questions here are: > > > > - Do we want resume() to take a message as well ? > > I guess it would be handy. It is incompatible change but right thing > to do. All our changes are incompatible anyway. I'm ready to fix bunch of drivers once we agree on the model. > Why not have all the details in one message and inline function > map_major_state() that tells you something you can switch() on? You mean one scalar ? Eventually... I don't really mind either way, and even the scalar could be something like major << 16 | minor :) > > And I TOTALLY disagree with Pavel about "freeze" turning into D3. There is > > no interrupt nor DMA in D2 and I doubt there is in D1 anyway, and as we > > explained several times, this is _NOT_ a device power state but a driver > > state. Drivers _have_ to properly implement the freeze state in ALL cases > > (since suspend S3 implies freeze semantics in addition to device power) > > I do not understand this one. > > If driver can do D3, I'm able to use it for suspend-to-disk. It will > flicker in an ugly way, but is safe. I probably could use D2 in > exactly the same way. If a driver can do D3, it can also just "suspend" without D3. That is it has the infrastructure (or should have, if not, it's buggy) to keep a consistent state, by either refusing or blocking upstream requests. So FREEZE asks it to do ... just that. Oh, and that include stopping DMA and interrupts, fine. Just _not_ the last step that set the chip to D3... I disagree with the "helper" just translating freeze to D3. That will encourage most driver writers to do just that, and possibly not even think about the acutal "freeze" semantic, thus possibly getting even D3 wrong. > It is also usable for suspend-to-RAM because userland is stopped > before suspend-to-RAM. No it's not stopped on ppc and will never be while I'm maintainer. Besides, I'm intimately convinced that stopping userland is just a band-aid and will not guarantee that your driver doesn't get more upstream requests. > Right solution of course is to teach all drivers about freeze. If I > have to convert FREEZE message into *some* PCI state, D3 is safe > choice in swsusp case and in suspend-to-RAM on i386, too. How many driver actually have _any_ sort of knowledge about suspend anyway ? Ben.
