On Wed, 25 Jan 2006, David Brownell wrote:
> > Some Intel motherboards have documentation indicating that system wakeup
> > can be enabled by setting some bits in the UHCI controller's PCI config
> > space. Presumably that information is also present in the ACPI tables.
>
> Well, the info that the controller can issue system wakeups, though
> not about those PCI bits.
Really? How does one go about finding out (without wading through
hundreds of pages of turgid ACPI prose) what sort of information the ACPI
tables actually contain?
> That would suggest that on those Intel
> boards (using southbridge detection?) you'd need to init the pci_dev
> wakeup bits in the UHCI driver.
The controller's PCI vendor and product IDs should be sufficient to
determine if it's the right sort of board.
> > Beyond that, I haven't seen any indication either. The only USB card I've
> > got with PCI PM support provides that support just for the EHCI
> > controller, not for the companion UHCI controllers.
>
> ISTR some VIA parts have PCI PM attributes for UHCI.
Maybe some do. Not this one (it's a 6202):
]# lspci -vv -s 1:0.0
01:00.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32, Cache Line Size 08
Interrupt: pin A routed to IRQ 11
Region 4: I/O ports at d880 [size=32]
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-
> > Unfortunately, for UHCI at least, there doesn't seem to be any simple way
> > to treat the two types of events differently. Either the root hub always
> > responds to all events, or else it doesn't respond to any events when
> > wakeup-enabled is off. Which way do you think it should behave?
>
> I think what you're saying is that UHCI either responds to all three
> types of wakeup events (resume/disconnect/connect) or none of them;
Yes. More precisely, there's only one hardware bit to control
wakeup-event interrupt generation while the root hub is suspended, so you
can enable interrupts for all three types of event or for none of them.
It's possible to rely on polling instead of interrupts, but that's a
different story...
> and that the root hub can either use (runtime) suspend states and
> respond to all, or never suspend and not get the events.
Or suspend and not get the events. That's about what you might expect to
happen after setting wakeup_enable to 0. Of course in such situations the
driver wouldn't do an autosuspend; this would only be for a runtime
suspend explicitly requested by the user via sysfs.
> Keying that all off the wakeup enabled policy flag seems fine to me;
> that's how OHCI and EHCI are working now, in part to match what UHCI
> seemd capable of.
All right, I'll do it this way. Any differences in the three HCD
implementations ought to end up sufficiently small and obscure not to
bother anyone.
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
