On Sun, 2004-11-28 at 11:13 -0500, Alan Stern wrote: > An important question needs to be answered before the new PM messages can > be handled properly in device drivers. > > What should happen when a device sends a resume or wakeup > request while the system is going through a transition into > a sleep state? It pretty much depends what you call a "device" resume/wakeup. > For example, suppose we're doing STR and a driver's suspend() method has > already run, but before everything else is suspended and interrupts are > disabled the driver receives a resume request. What should it do? Can > the sleep transition be aborted somehow? Or should the request be saved > and acted on when the system wakes up later? I'm not sure what you call by "the driver receives a resume request", is this a USB thing ? on the ppc, so far, driver never get anything like that. The resume is a HW thing occuring between devices on the bus and the power management uController. That is either some PCI PME thing, or other HW mean triggers a resume in HW, the drivers don't see it. > Part of the problem is that the driver doesn't know a transition is > occurring. It only knows that its device is suspended and wants to > resume; it's impossible to tell whether this is a selective suspend (in > which case the resume should be allowed) or a global suspend (in which > case something else should happen -- but what?). Again, can you be more precise ? If the driver got it's suspend() callback called, it's a system suspend, and thus the driver is in "frozen" state and should have stopped activity on the device and probably also ignore irqs. So in fact, the driver would probably not even "see" the device is doing anything special. > With STD the question is even more acute. What happens if the resume > request arrives after the memory snapshot has been taken? Then there's > no way to save the request for later. But if the request isn't acted on > immediately, it will be lost forever. Again, what do you call a "resume request". Ben.
