On Mon, 29 Nov 2004, Benjamin Herrenschmidt wrote: > 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. This _is_ a USB concept, although it certainly might apply elsewhere too (keyboards and mice, for instance, or input devices in general). The idea is that while the device is suspended, if some important event happens (like a key is pressed or the mouse is moved) the device sends a request to tell the system that the device needs to be resumed. In USB the hardware doesn't permit devices to resume all by themselves; they have to ask the host to do it for them. PCI is the same way. The difference between a resume request and a wakeup request lies mostly in the host, not so much in the device. A resume request is what happens when the system is awake and the device is in a low-power mode, asking to be returned to full power. A wakeup request is what happens when the system is suspended and the device wants to wake it up. A device might not even be aware of the difference between the two types of request. Either request could take the form of PME#. (In fact Linux currently doesn't support using PME# for resume requests; that needs to be changed.) A resume request could also be a regular IRQ. There are other possibilities as well (like setting a flag in a device register that the driver polls regularly), but these are the major ones. > > 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. Not so. If the driver's suspend method was called, it might be for a selective suspend, not a system suspend. A driver can't afford to ignore IRQs while the device is suspended; otherwise there would be no way to do a selective resume on demand. Furthermore, it could be that a device can't issue wakeup requests unless it has IRQs enabled. So what happens, for instance, if Wake-on-LAN is turned on and an Ethernet interface has been suspended in preparation for STR, but before the STR completes (and while interrupts are still enabled) a packet arrives? It doesn't make sense for the driver to resume the Ethernet interface when the whole system is about to go to sleep. On the other hand, since the request has already been delivered, if the driver ignores it then it will be lost forever. Alan Stern
