On Mon, Jul 25, 2011 at 05:04:55PM +0800, Xu, Andiry wrote: > > -----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?) The USB 3.0 software initiated LPM was really only put in the USB 3.0 bus spec for USB-IF compliance testing. I think we need to use hardware initiated LPM instead. > 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. Well, for USB 3.0 devices, they can always reject the request to go into LPM. So if I were a device manufacturer that didn't want to support USB 3.0 LPM, I would make my device always reject the request to go into U1/U2. But we won't know until we start experimenting with USB 3.0 devices. > > 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. Appendix C is supposed to help with that, but the person in charge of that section wasn't a very good writer. He's an Intel employee, so I'll track him down and try to extract what he actually meant from that section. I think we basically need to add up all the timeouts (for U1 and U2 individually) of all the hubs in the path to the device. I think that also includes the roothub exit latency in the hcparams3 field in the xHCI capabilities register. I'm unclear whether we also need to add in the Hub Packet Header Decode Latency in the bHubHdrDecLat field of the USB 3.0 hub descriptor for each hub in the path to the device. That field describes the time it takes for a hub in U0 to initiate a transition to U0 for a downstream port. > > 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. Sure, that would be fine too. 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
