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? One additional constraint is that I need to notify the xHC of changes to the maximum exit latency for the device. If the exit latency is getting worse (say because a new periodic endpoint was added for a new alt setting), I have to change the max exit latency in the xHC structure before changing the exit latency in the parent hub (and before any URBs are scheduled for that new endpoint). If the exit latency is getting better, I have to set the timeout values in the parent hub before changing the values in the xHC structure. I'm not sure if the callback I get from the pm_pos layer when the constraints change will help me enforce these rules. I really want to make sure the ordering is correct before a new endpoint on a recently installed alt setting is used, and I'm not sure what the guarantees WRT to timing the pm_qos core gives me. Basically I'm trying to figure out if pm_qos is the right infrastructure to use, or if it won't help me much in this case. 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
