> For USB there is no separate "power management uController" Well, the PM uController is whatever motherboard logic triggers a wakeup of the machine, since typically, the CPU is off. It is typically on USB triggered by some root hub signaling, possibly via PME# on PCE > involved, except _possibly_ in the case when a root hub > receives the USB resume signaling and passes that on. Ok. > 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. I don't know how the system reacts to PME. On mac, we have no way that I know for software to detect that it happened. It's purely some logic that works independently of the CPU that triggers the wakeup when the machine is sleepnig. Maybe on x86, you have a way to be informed of PME things ? > (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.) Ok. > 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. But that's off band from the normal PM calls. That is, I would expect the controller to simply forward the resume event to some higher levels in the system, that will trigger the system resume which will then trigger the resum() callbacks dance. But I see your point about having potentially havign a local resume. That is, you put your bus into suspend mode (local/dynamic PM), and in the middle of a subsequence suspend process, get a resume from a device... I'd rather ignore it at this point. > You know that's not true today. At least sysfs can suspend > devices. Yes, but that's broken in many ways, we both know it. > 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"(*). They either can be organized in some hierarchy, or if they can't then the drivers will have to find local ways of collaborating (hooks, whatever). For those cases, it would make sense to add virtual nodes to the PM tree that don't directly match a struct device tho, I agree. > 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. I agree, but we need to properly pass to the driver the semantic information of either doing a functional freezing (rejecting or blockingany subsequent request from upstream) or letting it do some kind of auto-resume. Annything more complicated will require explicit collaboration between the drivers (hooks etc...). But anyway, this is why I think we need to go on now with the suspend calls we defined (plus adding a parameter to resume), with the explicit precision that drivers must be ready to deal gracefully with additional calls we may define. For example, one sent when the sysfs thing is written to would make sense. My idea was to define that a driver suspend callback returns 0 for a successfull call, -ENOSUPP for an unrecongnized suspend message (up to whatever calls it to decide wether this is fatal or not, equivalent ot having to suspend function at that point, like PCI, may provide a default implementation), and an error would abort the transition. > - 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. I'm not sure I understand what OTG is, but from what you describe, there should be no problem putting them in some kind of hierarchy... Ben.
