On Monday 22 November 2004 08:05, Alan Stern wrote: > 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... Could be. On the other hand, I've yet to see a system wake up from PME with ACPI either, so I don't have any reason to believe the other PME infrastructure behaves yet either. (In fact, wakeup from a PS2 keyboard or mouse hasn't even seemed to work. So I'm not in the least worried that it's not yet behaving for more complex scenarios, like using a USB keyboard or mouse to wake the system.) > As for timer polling, I thought you were dead against it because it > prevents CPUs from entering lower power-usage states. What I said there was that I know that behavior "could" be demonstrated with timer polling, not that I thought it "should" be. The way it "should" work is that ACPI, or whatever other mechanism handles wakeup events, should behave correctly. (Until it does, other options may be necessary just to get interfaces unit tested. If ACPI is preventing the system from entering low power states, so be it!) > > 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. My point is that that part of a hub suspending is a guarantee that it'll issue (a) resume events. And in the case of a root hub, Linux doesn't care which mechanism it uses. For now, Linux wrongly expects that it's only software polling. That's an issue we should fix at some point. > 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? The latter: it's a root hub that must use software polling, except in system-wide sleep states. That's fully compatible with how the system shuts down the timers almost as the very last thing before entering an ACPI sleep state. - Dave
