On Mon, 2004-10-18 at 09:00, Pavel Machek wrote: > 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: 1 - Initial freeze for snapshot 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. (David, you are on the list yet ?) 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 ? 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 However I don't see cases needing minor for idle & suspend messages. So before we go further and Pavel start coding yet another bunch of stuff that I won't agree with, can we at least try to agree (Pavel, please) on the exact semantics of the messages we want passed down ? Among the "open" questions here are: - Do we want resume() to take a message as well ? - 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. 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) Ben.
