> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Saturday, July 23, 2011 1:09 AM > To: Xu, Andiry > Cc: greg@xxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; > stern@xxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH] usbcore: get BOS descriptor set > > 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? > Hmm. I suppose there are four kinds of LPM for xHCI: 1. USB2 software initiated LPM: usbcore issues a SetPortFeature (PORT_LINK_STATE) to U2 request. This can be done via autosuspend in usbcore, or providing interfaces to userspace, see lpm codes in ehci-dbg.c. 2. USB2 hardware initiated LPM: xHCI 1.0 feature. Let the host decides when to put a link into U2. In this case, USB2 software LPM is disallowed. 3. USB3 software initiated LPM: usbcore issues a SetPortFeature (PORT_LINK_STATE) to U1/U2 request. Basically same as USB2, but needs to take care of the max exit latency. (I have a question about this. From USB3 spec 10.14.2.10, I assume software can set port link state to U1 for USB3 devices. However, in table 35 of xHCI spec, writing a '1'(U1) to PLS field is ignored by xHC?) 4. USB3 hardware initiated LPM: usbcore issues a SetPortFeature (PORT_U1/U2_TIMEOUT) request. In this case, I wonder how to decide the appropriate values for U1 and U2 timeout? > > 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). > Before enable USB 3.0 LPM by default, is a LPM test necessary? I have seen some USB2 devices which claim to be LPM-capable but fail the LPM test. Not sure what behavior USB3 devices will have. > 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. > Yes, but how to calculate U1 and U2 timeouts? I found no clue in the spec. > > 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. > Since it's a check before actually enable U1/U2, I think the function name should be something like xhci_evaluate_max_exit_latency(). xhci_enable_usb3_lpm() should include codes to set U1/U2 timeout, only after the max exit latency is accepted by xHC successfully. Thanks, Andiry -- 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
