On Thu, 2004-10-28 at 13:30 -0700, Patrick Mochel wrote: > On Thu, 28 Oct 2004, Pavel Machek wrote: > > > Well, for example disk driver certainly needs interrupt controller and > > timer devices to be working... Disk itself does not care about timer > > devices, but driver certainly needs them. > > > > And it is this kind of dependencies that would make it "interesting". > > I'm not disputing those dependencies, but there seems to be something > wrong. If we're writing the image with interrupts enabled, we've either > not suspended the system devices (which means we're not saving their > state), or we've re-enabled interrupts (which may cause some bad things if > some system devices are disabled). If we're writing with interrupts > disabled, then the timers and IRQ seem to be irrelevant. What am I > missing? That's just confusion from Pavel. We resume system devices. That's all there is to do and that works. > Look, I'm not trying to 'overcomplicate' anything. I'm not even trying to > change things. I'm just trying to build a consistent set of terminology > and truisms that we can agree on so when we start talking about actually > changing things, we all have a shared consciousness about what we're > doing. The fact that we disagree on basic stuff like this is indicative of > a strong dissonance between all of us. What's obvious to you is not > obvious to me, vice versa, and ditto for David, Ben, etc. > Well, we have one, it's only a matter of sticking names to those, and they are all 3 "target states", that is they do both the actual stopping/freezing of the driver, the state saving (which means little, most driver don't have to "save" anything, it already there in whatever memory data structure they manipulate) and the optional power state transition. I called them FREEZE, IDLE and SUSPEND, but you are welcome to call them STOP, STANDBY, SUSPEND if you prefer, or whatever. They are basically in increased semantic order. STOP (or FREEZE) is implied by all 3 of them, STANDBY (or IDLE) will additionally put the HW in a low power state that is quick to get back from, and SUSPEND will enter a deep power state. (Typically D3). Now, we figured that it would be nice to differenciate the various steps of suspend to disk in some case, especially the resume ones, which makes me tend to think that a pm_message argument to resume() would be useful and we may want to separate the STOP/FREEZE message sent on STD first pass from the one sent to drivers of the loader kernel on STD resume, though I think those could just be flags (see below) since I expect most drivers to just not care ... There are details on which we didn't fully agree though, like the actual format of the suspend message. I vote for a struct pm_message containing an enum/int for the actual target state (defined above), but unlike David, I'd like some flags or additional informations telling us more details for the few drivers that actually care about such things, like flags indicating if it's an STD or STR, if it's the initial STOP/FREEZE of STD or the one on wakeup, that sort of thing... Finally, my proposal of having pre-suspend and post-resume messages still stands, but it's totally separate. They may be pm_message sent down the tree to suspend() and resume() (if we add an argument to resume()) but I see them more as ordered notifier lists since some subsystems may want to be notified independently. But then, we can work on that separately. Ben.
