On Thu, Sep 01, 2011 at 04:14:35PM -0400, Alan Stern wrote: > On Thu, 1 Sep 2011, Sarah Sharp wrote: > > > On Thu, Sep 01, 2011 at 11:32:54AM +0300, Felipe Balbi wrote: > > > On Wed, Aug 31, 2011 at 10:53:01PM -0400, Alan Stern wrote: > > > > Consider xHCI as an example. To what extent does it make sense to > > > > suspend/resume the low/full/high-speed bus independently of the > > > > SuperSpeed bus? I don't know enough about xHCI to say. > > > > The xHCI PCI host can only be put in D3 when all ports (USB 3.0 and USB > > 2.0) are suspended. So it really makes no sense to suspend the two > > buses separately. > > Even when the PCI controller is at full power, can you save a little > extra energy by doing something special at a time when all the enabled > LS/FS/HS ports are suspended but some of the SS ports aren't (or vice > versa)? No, there's not anything that the xHCI spec mentions in that regard. It's really up to the hardware manufacturer what it wants to do with the information that software provides. The most important thing software tells the xHCI host is which endpoints are being stopped because the USB device is being suspended. Each vendor could, for example, turn off clocks for specific ports if all the devices attached to that port were suspended. Or if it has an internal periodic and asynchronous schedule, it could chose to turn off the periodic schedule if all periodic endpoints were stopped. But that's a hardware implementation detail, and not something the xHCI driver enables for all xHCI host controllers. For example, Andiry introduced a power savings feature for the AMD Hudson xHCI host controller that allowed the xHCI driver to tell it when an isochronous endpoint was active, with the intention that the host controller power down some circuitry when there were no active isoc endpoints. The host controller could have easily done that internally, by keeping track of which isochronous endpoints weren't stopped with the suspend bit set. However, Andiry's patch might have produced slightly better power management because it could allow the host controller to shut down the circuitry between active isochronous URBs, rather than waiting 2 seconds for the USB core to put the idle device into suspend (or never suspending it because there was an asynchronous endpoint active). > With other PCI controllers this sort of power saving is possible. > While keeping the controller in D0, you can still turn off the frame > counter and the synchronous and async schedules. Does xHCI do this > sort of thing automatically? The xHCI host has full control over the schedule, so it should be doing that sort of thing internally. From a software perspective, there is no schedule, only endpoint rings and (usually only one) event ring. We get events when the transfer completes, not per frame or when the frame list rolls over. >From a power management perspective, the only thing the xHCI driver can do is put the xHCI host in D3, enable automatic USB 2.0 link power management, and enable the U1/U2 timeouts for USB 3.0 devices so that link power management is turned on for them. Those are the only generic knobs the xHCI spec provides. Everything else is hidden in the hardware or enabled through a vendor-specific register. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
