On Sunday 21 November 2004 08:58, Alan Stern wrote:
> David:
>
> The next time you send in that proposed patch to add can_wakeup and
> wakeup_enabled flags to devices' PM info, can you also add a can_resume
> flag? This is needed because for many devices, sending a resume request
> (during a selective suspend) is different from sending a wakeup request
> (during a system suspend) -- and some devices can do one but not the
> other.
I'm not sure I see this....
> 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.
> Another example might be the root hub for the UHCI controller in that new
> Genesys HC. Until they fix their design it won't send resume request
> IRQs,
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.)
> but it may very well still send PME#. Actually I don't know whether
> it does or not -- and I don't know how to test it. How do I tell when a
> PCI device is sending PME#?
I just use "lspci -vv". For one EHCI, I see:
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin C routed to IRQ 10
Region 0: Memory at e8004000 (32-bit, non-prefetchable)
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
That PM "Status:" line reports the controller is in D0 (which at
this momement involves no periodic DMA), PME is not enabled,
and it's not getting signaled either. If it said "PME+" that
would mean it's signaling PME# right now. The flags say it
can issue PME from any state; not all EHCIs will do that.
To test if a root hub can issue PME# you can enable USB_SUSPEND
and suspend a tree with a wakeup-capable device (keyboard, or
maybe net2280 plus custom firmware). Then use that device to
issue a wakeup. Last time I tested, I saw "PME+" as expected
from both EHCI and OHCI. (But no messages from ACPI ... so
it's just unit-tested...) I didn't try to issue PME from D0...
> 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.
- Dave
> Alan Stern
>
>
