On Fri, 2004-10-29 at 08:55 -0700, David Brownell wrote: > Good ... but that'll mean we need to revisit the model of what > state drivers have during resume(), right? > > Minimally to say that any records of current device state will > be invalidated on "some" resumes ... basically, all is fine > except when it came from a restored snapshot. (Since that > snapshot will contain device records reflecting "freeze" state, > not "low power".) Yes. > Now those records include pci_dev->current_state, which isn't > much used, and device->power.power_state, which I think needs > to be removed. Anything else? Can anyone identify problems > that come about if we remove those fields, and similar stuff, > from the "all devices" framework? I agree about removing power_state. It this that's all we have to care about, pci_dev->current_state should just be re-read from the HW imho when resuming from STD. That's one example where I think using a few flags in addition to the message itself would be useful, or using different RESUME messages In that case, that would be a RESUME message, with a flag indicating we are resuming from STD, or it would be a RESUME_FROM_STD message, allowing the PCI bus code to update it's current_state variable from the actual state of the PM register before calling the driver resume. That raises the question of the format of the PM message, I think once we finally agree to that, we'll be able to start coding something. I have no preference at this point, I see either a struct made of an enum plus some flags (FREEZE/IDLE/SUSPEND/RESUME enum, plus some flags indicating what phase of STD we are, or that we are doing STR, or some other stuff we may want to define). Or a single enum with more varied messages (like RESUME_FROM_STR, RESUME_FROM_STD, RESUME_FROM_STD_SNAPSHOT_FREEZE, ... :) The later could be done by splitting the message in 2, the "major" part (RESUME) and the "minor" part giving the details. There may be other ways. But keep in mind that most drivers will not care, that is they will do just the same thing on all resume cases, so if we define too many enums, we'll end up with 3 or 4 cases in drivers and drivers missing one, etc... that sort of horror. I like the main + flags idea because drivers will usually just have a single case _and_ we can add more flags in the future for other sutble distinction we want to make without breaking all drivers. (Like eventually using FREEZE for things like kexec & shutdown) > Any drivers that need to track this state are going to need > to squirrel it away before they return from any "freeze" that > precedes a snapshot. Which means _those_ drivers would need > different kinds of "freeze". Or just be told what's been going on via a detailed enough message Ben.
