On Friday 03 December 2004 2:28 pm, Alan Stern wrote: > On Fri, 3 Dec 2004, David Brownell wrote: > > > 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. I don't think I noticed that message, or entirely agree. > 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. How so? If it were _prior_ then there'd have been no reason not to respond immediately; nothing lost. > 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.) That is, harware designers must not make the wakeup events edge-triggered. > 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. Ideally, it's like starting to go to sleep blocks the wakeup IRQs, and the final step of sleeping would actually re-enable the IRQs. That's a difference between drivers suspending as part of a system sleep state transitions (ACPI S-states other than S0) and as part of normal operations (during S0). - Dave
