On Tue, 21 Feb 2012, Sarah Sharp wrote: > Hi Alan, > > I'm working on some patches to add USB 3.0 link power management to the > USB core and xHCI. I think you already know that U1 and U2 are new link > power states for USB 3.0 (although USB 2.1 has U1, sort of, with the L1 > state). > > There are two ways to get into U1 or U2. The device can initiate the > link state change, or the hub/roothub can initiate a link state change > after an idle timeout. Either link partner can reject the request to go > to a lower power state. A USB 3.0 modem might, for example, want to > reject a request to go into U2 because it's in the middle of receiving a > text message. > > For those classes of devices that can send data to the host through an > interrupt endpoint, like modems or bluetooth, I think it makes sense to > only allow device-initiated link state changes. The idea is the device > knows when it needs to transmit data to the host, and it can quickly > transition to a lower power link state after it's done sending data. Would this apply to all classes with interrupt endpoints, or would it be more specific? > If the host needs to send data through the device, the links will > automatically get put into U0 by the hubs in the path to the device, and > the hubs will force the links to stay in U0 until the packet is > received. Then after the device gets the data, and transmits it through > the radio, the device can quickly put the link back down into U2. > > If we have hub-initiated link state changes in this model, I think we > will have a lot of churn for the device rejecting link power state > transition requests, and I'm not sure if that will actually save power. > I'm also concerned about "dumb" modems that always accept the link state > change, and shutdown their radios, even though they are receiving data. > > The Intel Windows folks have come up with a list of device classes and > what they think the device-initiated vs. hub-initiated link state policy > should be. I'd like to duplicate that in Linux, so that we don't run > into "broken" devices that work under the Windows policy but break under > Linux. > > To that end, I'd like to add a new usb_device_driver field, > disable_hub_initiated_lpm. If any interface driver for a device sets > that flag, we won't set the U1/U2 link idle timeout values for its > parent hub. We will allow the device to initiate a link state change, > regardless of the flag state (later if we find truly broken devices, we > might need a second flag). You know, this whole thing has a slightly bizarre air to it. Yes, the device does have some idea of when it's going to need to send or receive data, so it makes sense to allow the device to initiate a link-state change. But the hub has no idea at all -- it knows less about what's going on than the host does. Why should the hub ever initiate anything? Or to put it another way, why aren't the link-change idle timeout values used by the device instead of used by the hub? > Does this policy sound reasonable? If so, I have a couple of questions > about driver binding and disabling USB devices that are related. What would you set the idle-timeout values to? Should those numbers be stored in the usb_device_driver as well? In which case, would you need an explicit disable_hub_initiated_lpm field? Does this affect scheduling of periodic transfers, or is that all handled by the xHCI hardware? Yes, overall this seems like a reasonable way to do things, given the framework imposed by the spec. What are your further questions? 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
