On Tuesday 24 January 2006 1:13 pm, Alan Stern wrote: > This patch reminds me that uhci-hcd needs to implement the wakeup flags.
Ideally, those PPC init sequencing issues would get resolved so you wouldn't have to worry about that except for quirk handling. That is, PCI initialization should be setting the device flags, then usbcore would use those values to initialize the root hub. Last I looked at UHCI docs, there wasn't any other way to tell whether system wakeup was supported ... short of looking at the ACPI tables that are currently in /proc/acpi/wakeup and not yet integrated into the driver model. (Assuming ACPI is in use...) But the root hub itself would always be able to handle (runtime) wakeup events. (Most USB host controllers handle runtime wakeup events. It's the system wakeup that's problematic ... usually because the system suspend states involve disabling most clocks, which in the case of USB prevents the normal "runtime" wakeups from doing their thing. External transceivers can help, with some work; or in some cases, special GPIO-ish treatment of the D+/D- lines.) > 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. > So, does this flag refer specifically to waking up from a system sleep, or > does it also refer to runtime resume signals? So far as the root hub is concerned there is no difference, right? It's the _controller_ device which might be concerned with system wakeup, in response to any root hub resume signal. If it can. > And if it does, how do > we reconcile the fact that runtime resume can be disabled with the > requirement in the USB spec that wakeup signals always clear a port's > suspend feature? I don't see a conflict there. Could you explain? That's just what resume signaling does; usbcore doesn't enable it in all cases... > Finally, when the driver's bus_suspend method runs, it > doesn't know whether it's for a system suspend or a runtime suspend, so > how should it interpret the wakeup_enabled flag? When a hub suspends, it pays attention to its "wakeup enabled" flag. So runtime suspend (e.g. what OHCI has done the past couple years whenever no devices are getting SOF packets, if that silicon doesn't have relevant bugs) will probably end up using resume events to leave the runtime suspend state. When the controller itself suspends, it also pays attention to the "wakeup enabled" flag on the controller. In the PCI case, if the root hub and the controller can both handle wakeup signaling, then the relevant PCI mechanism is enabled. That signaling might be discarded (the current state of PCI runtime suspend), used correctly (some API and ACPI systems), or completely mis-handled (probably half of the ACPI systems I've tried with Linux). - 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 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
