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. > --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). 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
