On Fri, 22 Jul 2011, Sarah Sharp wrote: > For USB 3.0 LPM, I think we need to add some code to the USB core to > keep track of the exit latencies in the usb_device structure. I'm not > sure yet whether we need a separate sysfs file for whether to enable U1 > or U2. I think we should test, see if we find any broken devices, and > then add that if necessary. I think until we find broken devices, we > should enable USB 3.0 LPM by default, even if the device suspend sysfs > files (power/control) disallow auto-suspend (U3). LPM for hubs is more complicated than it is for devices, because with hubs you have to worry about the latency requirements of all the downstream devices. > I think the policy decision for USB 3.0 LPM needs to happen in the USB > core, since the device autosuspend policy mechanisms also resides there. They aren't necessarily all that closely related, apart from the obvious fact that autosuspend implies U3. > The USB core can look at the exit latencies of all devices in the path > of a particular device, the periodic polling interval, and decide > whether to enable U1 or U2. There can be more than one periodic endpoint, with various polling intervals and different phases. In fact, usbcore doesn't have access to all that information. Besides, you probably want to start with powering-down just the last hop to the device, not the entire path. > Then the xHCI roothub only has to be > modified to understand the USB 3.0 hub commands to set the U1 and U2 > timeouts for the devices attached to the roothubs. That way the code > for enabling USB 3.0 LPM for both the roothub and external hubs will be > the same. Right. > The other bit that will need to be added is a way to update the xHCI > device structures to set the max exit latency for a device, before > enabling U1/U2 timeouts in the parent. We have to give the host > controller a chance to reject the U1/U2 enabling, in case it can't find > room to schedule Ping requests to wake up links in U1/U2 before sending > isochronous transfers. That would require an Evaluate Context command, > I think. So there probably needs to be a new host controller to USB > core API to ask whether U1/U2 can be enabled, and pass in the new > possible max exit latencies. Maybe something like: > > xhci_enable_usb3_lpm(struct usb_hcd *hcd, struct usb_device *udev, > unsigned int u1_max_exit_latency, unsigned int > u2_max_exit_latency) > > Or possibly two functions, one for U1 and one for U2. It's likely that > enabling U1 will work while U2 might not due to the increased exit > latency. > > Alan, any opinions on this plan? I don't know. When do you decide to put a link into a low-power state? Once you do, does it automatically return to that state after carrying out a transfer, or do you have to tell it explicitly to go back? At some point, constantly telling a link to change state uses up more power than leaving the link in U0 permanently. Alan Stern -- 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
