On Sun, 21 Nov 2004, David Brownell wrote: > > A common example is many PCI devices. If a device supports PME# then it > > can generate wakeup requests. But there's no way for it to generate a > > resume request, because (unless my understanding is completely wrong) PME# > > isn't an IRQ and doesn't affect a running CPU; it merely wakes up a > > sleeping system. > > That's certainly how Linux ACPI implements it just now. > It's my understanding that it's just an implementation > restriction ... there's an event that's being ignored, > one I think ACPI could already pass to Linux, and one > that I know could be synthesized with timer polling. Okay. Looking through the kernel source I couldn't find any place where PME# is turned off! That would cause problems for repeated suspends... As for timer polling, I thought you were dead against it because it prevents CPUs from entering lower power-usage states. > There will indeed be bugs and hardware restrictions, > both in chips and in boards using them. (Even in > reference boards!) But remember that a USB HCD > exposes two distinct devices: > > (a) Root hub, for downstream interfacing, which in > this case only supports software signaling for > wakeup/resume; and > > (b) Bus interface, for upstream signaling, which in > this case might support hardware signaling. > Both chip and board must support that, else the > system won't support wakeup from USB devices. > > Linux doesn't care if (a) uses hardware IRQs or software > polling to detect USB resume signaling ... the root hub > timer polls by default, so essentially any root hub has > no problem issuing "resume" events. (Maybe the timings > would be wrong without faster polling.) You're wrong there. When any hub (not just the root hub) suspends, the hub driver's suspend method cancels the status URB, so there is no polling. If the HCD wanted to poll for resume events, it would have to do so itself by adding special-purpose code. > > There shouldn't be any need to have separate wakeup_enabled and > > resume_enabled flags. It's hard to imagine why anybody would want to > > enable one but not the other. Also it's likely to be true for most > > devices that the two features are turned on in the same way. > > I consider "can_wakeup" to be the generic name for what a USB > config descriptor has in bmAttributes.USB_DEVICE_REMOTE_WAKEUP. > Host controllers have two "can_wakeup" bits: one for the root > hub (usb device) and one for its upstream bus interface (pci > or whatever). > > The implementations of those bits can differ a lot. OHCI gives > me clear examples: the root hub has one mechanism (enter an > OHCI state after enabling some interrupts), the bus interface > has another (PCI PM, PCI legacy/bios, various platform-specific > busses and wiring options, and so on). > > I think that'll be clearer with the next version of that patch. > After I clear out some other patches, I'll send that update. How would you describe a host controller which was capable of sending PME# when the PCI bus interface is suspended, but is not capable of interrupting the host when the bus interface is in D0 and the root hub is suspended? Would you say that the root hub's can_wakeup should not be set? Or would you say that can_wakeup should be set and the HCD should rely on timer polling to detect events? Alan Stern
