On Thu, Nov 10, 2011 at 08:42:52PM -0500, Alan Stern wrote: > On Thu, 10 Nov 2011, Alan Stern wrote: > > > On Thu, 10 Nov 2011, Sarah Sharp wrote: > > > 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.) No worries. :) > 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. Yeah, someone else suggested pm-qos might be a good fit, but I don't know too much about it. My feeling is that it doesn't buy me much, since the hardware is going to be doing most of the actual power management, but I wanted to see if you felt strongly one way or another before just doing it in the USB subsystem. > 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. At this point I have a list of requirements (that seems to grow the more I think about it), and a couple thoughts on what sort of new fields might need to be added to the usb_device structure. I'll see if I can put them together in any sort of coherent email. :) One thing I've been trying to figure out is how device suspend (U3) and link PM (U1/U2) will interact. One complication is that you can't directly go from U1 or U2 into U3; instead you have to bring the device back into U0 and then put it in U3. That means when we suspend a device, we'll have to disable the device from entering U1 and U2, and disable the parent hub's port U1/U2 timeouts. Then when we resume a device we'll have to re-enable the device and hub U1/U2 timeouts. The bit I'm struggling with that there are places where the USB core disables autosuspend (like when we're installing to a new configuration) by calling usb_autoresume_device. Should U1 and U2 be disabled in that case? Any transfer that's sent will wake up any links in a lower power state, so I can't really see a need to disable it. Do you? 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
