On Fri, 26 Nov 2004, David Brownell wrote: > I'd agree that if HCDs do things like autosuspending, that shouldn't > be something to affect khubd ... though I'm not sure I'd expect the > "hub" and HCD "root hub" driver autosuspend results to differ much.
It's the difference between a "usbcore suspend" of the root hub and a "root-hub suspend", in the terminology you suggest below. The functional differences should be very small. Probably the largest difference is that the manufacturer, product, and serial # strings won't show up in /proc/bus/usb/devices during a usbcore suspend but they will during a root-hub suspend. > I think it's really worth thinking of HCDs as combining two distinct > device drivers. One of the drivers is for the upstream bus (PCI, an > SOC bus, or wire-it-yourself); the other is the root hub. Certainly > that helps with OHCI, and EHCI too, though I suspect not many other > standardized register APIs will appear for USB. (Plus there's the > vowel shortage. [AEOU]HCI are taken, leaving only IHCI and YHCI. :) Of course, there's no need to limit the selection to vowels. This realization opens up vast new worlds of possibilities... :-) > > (a) USB device is physically suspended (upstream ports receives no > > packets, power usage is very low). This notion does not apply > > to root hubs because they don't receive packets on a regular basis > > from upstream. > > That's what I'd call the "USB Suspend" state. Root hubs > actually do have analagous states, with downstream ports > suspended just like other hubs ... just say that all USB > links to/from the device are disconnected or suspended, > and it should be safe to ignore that root hubs don't hav > USB links "to" the device, just "from" it. I prefer keeping the root hub analogs as separate concepts, because "USB suspend" really is a very well-defined state whereas "root-hub suspend" is rather fuzzy with several possible substates. (Also, it's a little misleading, even for real hubs, to say that in "USB suspend" all the USB links are disconnected or suspended. The USB spec doesn't recognize the concept of a "link" being suspended, only of a "port" being suspended. And in "USB suspend" of a real hub, the downstream ports aren't necessarily suspended.) > > (b) Usbcore thinks a device is supended (udev->state == > > USB_STATE_SUSPENDED and udev->driver->suspend() has been called). > > Applies to root hubs as well as real devices, and for real > > devices this implies (a) -- unless usbcore is broken! > > Right. This is "usbcore suspend", maybe. Sounds good. I should also have mentioned that for root hubs (b) => (c), in analogy with (b) => (a) for real hubs. > > > > (c) Root hub is not transmitting packets. It may or may not allow > > polling of registers and it may or may not have reduced power use; > > these could be considered sub-divisions of (c). > > Actually, it's the root hub analogue of (a) in most cases... > especially in the "can't access registers" case. (Though that > part shouldn't matter to usbcore; it's not a USB notion.) And > if it's not transmitting packets, it's clearly saving power > already ... HCDs can combine a few more power saving modes. Yes, (c) is analogous to (a). This is the state that HCD root-hub autosuspend code will use, since as you mention, (b) is impractical because it requires a process context. > > (d) Host controller is in a PCI low-power mode. Only config-space > > registers are accessible. Analogous notions apply to non-PCI > > controllers. This implies some form of (c). > > This would apply exclusively to the upstream link to the > root hub, yes? Does usbcore even need to know about this? > (Other than re-usable PCI glue code, which isn't exactly > a "core" function.) This does apply mainly to the upstream link to the root hub. But since it implies (c) it also affects the downstream link. And no, usbcore does not need to know about this state (other than hcd-pci.c); only the HCDs do. This does lead to problems in the non-CONFIG_USB_SUSPEND case, where URBs sent to the root hub might cause the HCD to try accessing the hardware registers. I'm not going to worry about it. > > If you can come up with good names for the (a) - (c) we can refer to (d) > > as "HC is suspended". Maybe (a) could be a "physical suspend". > > I was thinking "USB suspend" for (a), with "root hub suspend" > for its (c) variant, and "usbcore suspend" for (b). I can go along with that. It should make communication easier. On a slightly different tack, should we start thinking now about making usb_suspend/resume_device non-recursive? It should be sufficient to have the routines suspend/resume all the interfaces along with the device, without the recursion to children devices. After all, when these routines are called by the PM core for a system sleep transition, the recursion has already been handled for us. For selective suspend of non-hubs, obviously it doesn't matter. And so far selective suspend of hubs has come up only in the autosuspend code, which kicks in only when all the children are already suspended. It ought to be good enough to have usb_suspend_device simply fail when there is a non-suspended child. If we want to keep a recursive version of selective suspend, it might be better to put the recursion somewhere above usb_suspend_device (like building it into the sysfs interface somehow). Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
