On Fri, Jul 22, 2011 at 09:58:42AM +0800, Xu, Andiry wrote: > > -----Original Message----- > > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > > Sent: Friday, July 22, 2011 12:16 AM > > To: Xu, Andiry > > Cc: greg@xxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; > > stern@xxxxxxxxxxxxxxxxxxx > > Subject: Re: [PATCH] usbcore: get BOS descriptor set > > > > Hi Andiry, > > > > Are you getting the BOS descriptor in order to implement link power > > management? That was next on my todo list, and I want to make sure > I'm > > not duplicating your efforts. :) > > > > Yes, the BOS descriptor patch is for LPM. However it's independent so I > submitted it separately. > > Yes, I'm working on LPM now, but only implemented partly, includes > testing USB2.0 device software LPM and enable hardware LPM(xHCI 1.0) if > the test passed. I've fixed the issue we discussed in the last LPM email > and more tests are running now, will submit them next week if everything > is OK. Great! > For USB3 and USB2 runtime LPM, it's more complicated because driver must > decide when to put the link into lower power state. Maybe usbcore needs > to give the command, or we can provide interfaces to userspace, such as > EHCI does. Maybe you have decided the mechanism? Are you talking about the fact that USB 2.0 LPM is software initiated, not hardware initiated like USB 3.0 LPM? I'm a bit confused about this paragraph. Does EHCI expose files to allow USB2 LPM to be turned on and off for specific port? Or what mechanism are you talking about? For USB 3.0 LPM, I think we need to add some code to the USB core to keep track of the exit latencies in the usb_device structure. I'm not sure yet whether we need a separate sysfs file for whether to enable U1 or U2. I think we should test, see if we find any broken devices, and then add that if necessary. I think until we find broken devices, we should enable USB 3.0 LPM by default, even if the device suspend sysfs files (power/control) disallow auto-suspend (U3). I think the policy decision for USB 3.0 LPM needs to happen in the USB core, since the device autosuspend policy mechanisms also resides there. The USB core can look at the exit latencies of all devices in the path of a particular device, the periodic polling interval, and decide whether to enable U1 or U2. Then the xHCI roothub only has to be modified to understand the USB 3.0 hub commands to set the U1 and U2 timeouts for the devices attached to the roothubs. That way the code for enabling USB 3.0 LPM for both the roothub and external hubs will be the same. The other bit that will need to be added is a way to update the xHCI device structures to set the max exit latency for a device, before enabling U1/U2 timeouts in the parent. We have to give the host controller a chance to reject the U1/U2 enabling, in case it can't find room to schedule Ping requests to wake up links in U1/U2 before sending isochronous transfers. That would require an Evaluate Context command, I think. So there probably needs to be a new host controller to USB core API to ask whether U1/U2 can be enabled, and pass in the new possible max exit latencies. Maybe something like: xhci_enable_usb3_lpm(struct usb_hcd *hcd, struct usb_device *udev, unsigned int u1_max_exit_latency, unsigned int u2_max_exit_latency) Or possibly two functions, one for U1 and one for U2. It's likely that enabling U1 will work while U2 might not due to the increased exit latency. Alan, any opinions on this plan? 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
