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. > > 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. For USB there is no separate "power management uController" involved, except _possibly_ in the case when a root hub receives the USB resume signaling and passes that on. 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.) For non-PCI systems like various SOC systems, the wakeup event usually seems to be morphed into a normal IRQ, possibly after interacting with something to re-enable clocks and wake the system from SRAM. I'm not sure I see resume() calls ever happening there, especially when that IRQ gets delivered to the USB controller directly using the controller's normal resume IRQ. (Several OHCI systems I've looked at do that.) Non-ACPI systems with PCI can still detect and process PME, but I'd expect they would just resume() the devices that were issuing the PME signal. > > 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, You know that's not true today. At least sysfs can suspend devices. I'm curious how you think composite hardware modules should handle suspend. I hope there's a better name for those; the case is several pieces of hardware (say, four different controllers) that collaborate, and rely on invariants like "if this controller is active, so is this other one"(*). The point being, sometimes drivers need to suspend and resume each other ... and for PM, the goal is to keep everything suspended except when it's in active use. I've not seen any reason to redefine suspend() and resume() to apply only to system sleep state transitions. - Dave (*) One particular example: a USB OTG device consists of at least three controllers + drivers, counting just the lowest level "real hardware". (There are also upper level drivers, as for mass-storage or modem links.) - Host (OHCI, EHCI, or custom); - Peripheral (all custom); - OTG controller (in charge of protocols like HNP that can switch between host and peripheral roles). Today, that OTG controller is probably two separate devices that are linked -- not unlike an MII transciever and an Ethernet controller. The idle state shouuld be all four controllers suspended. Then the transceiver can resume its driver, which then resumes the relevant controllers (OTG plus either host or peripheral roles; or in some cases both) and associated upper level drivers.
