On Wed, 27 Apr 2005, David Brownell wrote: > Hmm, but external hubs DO autosuspend: as soon as SOFs stop flowing > from the parent, they suspend themselves (and their children). > That's analagous to what a root hub does when the HC itself gets > suspended.
Right. > The root hub autosuspend is different though; it turns off > the flow of SOF packets, just like setting the suspend bit > on the parent port of an external hub. Right again. And setting that suspend feature won't happen without external intervention; there's nothing "auto" about it. > Thing is, there's no parent hub for the root, so there's no > way the driver for such a hub could set that suspend bit... > the parent is the HCD. Ergo, controlling root hub suspend > is most naturally part of that HCD. ;) Let's carry this line of reasoning a little farther. You're saying that the driver (i.e., the HCD) for the _parent_ of the root hub should be responsible for autosuspending the root hub. By analogy, the driver of the _parent_ of any USB device should be responsible for autosuspending that device. Seems fishy to me. Instead, the driver of the device itself should be responsible. It carries out the autosuspend by sending a request to the parent hub. In the same way, the hub driver should be responsible for autosuspending the root hub. It should carry out the autosuspend by sending a command to the HCD. Which is exactly what it would do, if khubd included an autosuspend routine that called usb_suspend_device for the hub being suspended. > > Yes, although host controllers may be a particularly egregious case. Not > > only do they consume power, they use up plenty of PCI bus cycles. (Maybe > > not too many though, if no devices are plugged in.) > > What resources they use on the parent bus is specific to the > controller and its driver. At this point I think none of the > standard PCI based HCDs need PCI accesses when there's no USB > device attached. Correct. Although I have a 1-second delay in the UHCI driver before autosuspending, to prevent bouncing. > I think it's only UHCI that needs to access > PCI when there are no transactions scheduled. (Since that's > more or less how it knows to send SOFs.) Exactly. That access ought not to be very heavy though. All the controller needs to do is read through a few "skeleton" QHs until it reaches the end of the schedule, and this happens once per ms. The real issue is that the ongoing DMA prevents the CPU from entering certain low-power modes. Alan Stern ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
