On Thu, 10 Nov 2011, Alan Stern wrote: > 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. (Sorry to be so short earlier -- I was in a hurry.) My feeling is that pm-qos isn't currently a good choice for this sort of thing. But that impression could easily be wrong, because I know so little about it and because pm-qos is going through changes aimed at making it more suitable for managing various kinds of runtime-PM-like things. Even if you decide to handle all of this within the USB subsystem, it will be a big job. I'll be happy to discuss plans for various approaches if you want. 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
