On Thursday 28 October 2004 22:50, Patrick Mochel wrote: > > On Fri, 29 Oct 2004, Benjamin Herrenschmidt wrote: > > > The entire point, as I explained in another mail, is that "freeze" means > > to the driver the excact same thing as "suspend" (that is stop > > operations and apply whatever policy is applicable to a suspended driver > > of that class, freeze queues for block like IDE does, drop packets for > > ethernet, etc... stop DMA engine too etc... so a consistent image can be > > saved), but _without_ actually powering anything down. So waking from > > this state is both fast, and without any spike. > > Ok, we're on the same page. Sorry for the confusion. 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".) 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? 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". - Dave
