On Thu, 10 Nov 2011, Sarah Sharp wrote: > Hi Alan, > > I'm looking at implementing USB 3.0 link power management, and I > wondered if you could help me with some high-level design before I get > into the actual coding. :) I'd like to avoid re-writing the entire > patchset because I should have been using some core kernel > infrastructure. > > The mechanism behind link power management (LPM) is pretty simple. Each > USB device advertises the exit latency it will encur to come out of each > of the two link states (U1 and U2) to the active link state (U0). Exit > latencies get worse the deeper you go into the USB tree because they add > up. Either the USB device can ask to go into a deeper link state, or > the parent hub can have a timeout value and ask the device to go into a > deeper link state after the timeout. > > Since link states are automatically entered and exited by the bus > hardware, the OS only needs to enable the device to enter U1 and/or U2 > (with a SetFeature request) and (optionally) enable the parent hub > timeout. The parent hub can be set up with a timeout of 0xff, which > means the hub doesn't try to put the link into a lower power state, but > it accepts device requests to go into lower power states. > > Figuring out what the timeout should be is tricky, and is turning out to > be host controller specific. For Intel hosts, I can't let the link > enter U1 or U2 between service intervals when a periodic endpoint is > active for hardware scheduling reasons (even if the exit latency for U1 > or U2 is less than the time between service intervals). So every time a > new configuration or alternate interface setting is installed, the OS > needs to recalculate the timeout values. > > A further complication is that some types of devices need device > initiated lower power link states, but won't benefit from their parent > hub having a timeout. Communication devices like modems and bluetooth > adapters will know when they can't go into a lower power link state > (because they're, say, receiving a text message), so it makes no sense > to program the parent hub timeout. That means there has to be a way for > USB drivers to specify that the timeout should be 0xff (let the device > decide). > > With the three different players in this game (USB core for periodic > endpoint management, xHCI for additional constraints, and USB drivers > for behavioral constraints), and the need to track both exit latencies > and timeouts, it starts to sound like I really should be using pm_qos > for this. > > Do you think pm_qos would be a good fit for this? Or should I just try > to handle it all in the USB core? It's a complicated problem, no question. I don't know enough about pm_qos to give you an answer, unfortunately. 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
