Hi Sarah, Thanks a lot for replying back. On Sat, Mar 22, 2014 at 12:17:49AM +0800, Sarah Sharp wrote: > Cc-ing Mathias Nyman, who is taking over as xHCI driver maintainer. > > On Fri, Mar 21, 2014 at 02:37:22PM +0530, Pratyush Anand wrote: > > Hi Sarah, > > > > I have to implement dynamic U1/U2 initiation on a dwc3 based xhci > > platform. I can see that my host starts sending LGO_U1 (when idle) by > > enabling XHCI_LPM_SUPPORT & XHCI_INTEL_HOST quirk in xhci_plat_quirks > > and using xhci_enable/disable_usb3_lpm_timeout in > > xhci_plat_xhci_driver. But offcourse that is not going to be the final > > solution. > > > > Before I float a RFC patch for it, I wanted to understand few things: > > Ok, I wrote the code two years ago and haven't really looked at it > since, so I'll have to refresh my memory on the mouthful of acronyms. :) > > > -- I see there there are three functions > > xhci_calculate_intel_u1/u2_timeout & xhci_check_intel_tier_policy > > specific to XHCI_INTEL_HOST in the whole path. > > Since I do not see similar specification (which have been used > > in above function) in dwc3 specs, so I wanted to understand that how did > > you decide in function xhci_calculate_intel_u1_timeout that SEL should > > be multiplied (on top of what has been defined by USB3 specs C.1.5.1) by > > 3 if control ep is present or by 5 if bulk and so on.... or even how > > many number of hub should be allowed to enable LPM for any device. > > This was based on information given to me by the Intel chipset folks. > Without knowledge of the constraints of the host and its internal > scheduler, you can't really know how to calculate the timeouts. I do > suspect the rule about the number of hubs that are allowed to enable LPM > is an Intel-specific thing. > > Basically, you're going to have to work with Synopsys and TI to figure > out if there's any hardware constraints for dw3. That's why we didn't > enable LPM across the board for all xHCI 1.0 hosts. I wish the USB 3.0 > spec and xHCI spec had exposed information that software could use to > calculate U1/U2 timeouts, but like all power management features, it was > shoved in late and not well-documented. OK.. I ll get in touch with synopsis and our host developers to look if any such limitations exists. > > > --Slot Context Max Exit Latency(MEL) has been programmed using MAX(U1_mel, > > u2_mel). Just for my understanding, can there be any situation when > > u1_mel is greater that u2_mel. If not then code can be simplified a bit. > > There's nothing in the spec that requires U1 MEL <= U2 MEL. In > practice, I've never seen it happen, but you never know what USB device > vendors will do. :) > > > --Do you see any scenario where params.pel could be greater than > > params.sel? If not then do we really need to remember pel and do > > calculation based on it in xhci_get_timeout_no_hub_lpm? > > So, looking at the log for commit 51e0a012066, it seems that SEL = PEL + > some delay. I guess SEL will always be equal to or greater than PEL. > I believe that I stored those variables mostly in case we ran into > issues with USB 3.0 devices, so that we could (potentially) expose those > values through sysfs, which might help with debugging. We haven't > needed that, so you can probably safely not track PEL. > > ...and you do know that most USB 3.0 devices simply refuse to go into U1 > and U2, right? I put in a lot of effort into enabling this feature, and > found that most devices simply NAK the request to go into U1 or U2. You > have to use a bus analyzer and be sure you're actually going into low > power states when you're testing the dw3 code. There are a few devices > out there that support USB 3.0 LPM (Western Digital My Passport, for > example). Yes, most of the devices does responds with LXU to a LGO_Ux. I have a programmable dwc3 device controller which I can ask to respond with LAU. I will discuss to hardware folks for any limitations as you suggested above. But before I close, I have a very specific query. As per my understanding, maximum exit latency programmed in slot_ctx is not as per xhci specification. -- SW programmes slot_ctx with max_exit_latency in function xhci_change_max_exit_latency. -- The above max_exit_latency has been calculated in calculate_max_exit_latency , which is max(u1_mel, u2_mel). -- Reading the xhci specification again, section 4.23.5.2 says that Max Exit Latency programmed in Slot Context is max[ Ping Wake Delay, bInterval (if isoc ep exists), max time to transfer isoc data]. -- Ping Wake Delay has been defined in USB specs C.1.3.2 and more clearly is C.1.5.2. As per C.1.5.2, PWD should be something which we have stored in params->sel (and not params->mel). -- So you do not think that in calculate_max_exit_latency, slot_ctx should be programmed with max(u1_sel, u2_sel)? May be , we can add other two conditions as defined in xhci specs 4.23.5.2. What do you say? Pratyush -- 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
