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: > 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. > 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. > 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. > - Do we add "additional" data to the pm_message in addition to the > "main" state, like the above, resume would need the same, or do we > just define a larger set of states constants with the risk that drivers > will "miss" some. I like having major/minor bcs most drivers will only care > about major, and we can eventually define a new "minor" to solve a given > problem in the future without breaking all of them > - Do we want to hide the scalar of the message main (major) as Pavel wants, > or do we let drivers switch/case on it ? I want to provide "helpers" but that > doesn't meen completely hiding the message from drivers who do care. Why not have all the details in one message and inline function map_major_state() that tells you something you can switch() on? > 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. It is also usable for suspend-to-RAM because userland is stopped before suspend-to-RAM. 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. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
