Hi! > > 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). Nice summary! > 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... struct pm_message, passed also during would work for me... but it is quite a lot of work to get there. My plan is: * device_suspend() gets pm_message_t argument, that is originally typedef int __bitwise pm_message_t, and passes one of FREEZE, IDLE, SUSPEND. notice that drivers still compile at this point, and with "right" selection of FREEZE, IDLE, SUSPEND constants, nothing breaks. * drivers are converted so that they never ever look at pm_message_t directly * pm_message_t gets additional fields, like if it is suspend-to-disk or to ram or whatever. * device_resume() may get pm_message_t argument... > 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. Yes, these can wait. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
