> 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. 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. > 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. > > But the root hub itself would always be able to handle (runtime) > > wakeup events. > > Ah, "would always be able", yes, but _should_ it handle these events when > the wakeup_enabled flag is off? I think it should always handle the events it receives. The option is primarily to help filter the events that can be generated. Example, a device that's known to mis-handle remote wakeup would have wakeup_enabled=N, and never be told to use that mechanism ... early filtering. > > > But I've forgotten exactly what the root hub's wakeup_enabled flag is > > > supposed to mean (and I can't find where it's documented, if anywhere). > > > > It's not especially different from any other device. For USB > > hubs, the wakeup events certainly include "remote wakeup" but > > (in general) also device connect/disconnect. > > The USB spec treats these two classes of events slightly differently. > With external hubs, there's no way to disable the response to a remote > wakeup signal received from downstream. The hub, if it isn't suspended > itself, will _always_ clear the port's suspend feature and set the > suspend-changed bit. If the hub is suspended it will _always_ relay the > remote wakeup signal upstream. And upstream should handle such events; I see no point to not handling them. We don't include code which would allow remote wakeup events to issue unless USB_SUSPEND is set, also including code to handle those events. > But when an external hub is suspended, its response to device > connect/disconnect is dictated by the wakeup-enable feature. If that > feature isn't set, the hub will not generate a remote wakeup signal when > those events occur. Hmm, ok. As a rule we want remote wakeup enabled everywhere, so clearing that feature will be the abnormal case. I can see we might want a software special case to match that hardware special case, but it'd be good to avoid that just like any other special cases. > The spec doesn't say exactly how a root hub is supposed to behave in these > circumstances. Presumably we want to imitate an external hub as closely > as is feasible. Actually I'd say that "presumably we want runtime suspend to kick in as widely as possible, saving power". The reason to emulate external hubs is because removing special cases simplifies things. However, they don't behave identically, in several ways. > That would mean (assuming the root hub is suspended and > the controller isn't, which implies we're talking about runtime PM) that > the root hub always responds to remote wakeup signals, but it responds to > connect/disconnect only when wakeup-enabled is on. That doesn't mesh well with root hubs that have quirks in those areas, which are demonstrably more common than external hubs with such quirks. > 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; and that the root hub can either use (runtime) suspend states and respond to all, or never suspend and not get the events. 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. - Dave ------------------------------------------------------- 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
