On Fri, 3 Dec 2004, David Brownell wrote: > On Sunday 28 November 2004 12:33 pm, Benjamin Herrenschmidt wrote: > > On Sun, 2004-11-28 at 11:13 -0500, Alan Stern wrote: > > > > > 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? > > I suspect the short answer is that there will be cases where > the sleep transition needs to be aborted, but we can probably > expect the typical case will be that the hardware resume > signaling is effectively "level sensitive", not edge-triggered. As Pavel pointed out, it doesn't matter too much if the request gets lost. After all, if the wakeup/resume event had occurred just _prior_ to the start of the sleep transition, it would effectively have been lost anyway. Just so long as requests arriving after the sleep transition has completed don't get lost, we should be okay. (And as a corollary, requests which do arrive too early and get lost must not leave the hardware in a state which is incapable of responding to later requests.) > For PCI, the PME thing _may_ involve such a uController (as > with ACPI), or not. When PME happens, that means the device > was in some PCI D-state, which I'd expect to mean resume() > gets called -- regardless of whether the device autosuspended > or whether some other system component suspended it. (But > of course, today with ACPI, it only happens in the latter > case, and that's something to eventually try fixing.) The correct approach would be for the PCI core not to call resume() if a sleep transition is in progress. Then when the system is asleep the continuing PME signal will wake it back up immediately. I don't know if this is feasible, however. It might be like an IRQ handler not turning off the source of the interrupt request. Alan Stern
