On Thu, Aug 22, 2013 at 02:55:07PM -0700, Greg KH wrote: > On Thu, Aug 22, 2013 at 02:49:07PM -0700, Sarah Sharp wrote: > > On Thu, Aug 22, 2013 at 10:42:49AM -0400, Alan Stern wrote: > > > On Wed, 21 Aug 2013, Sarah Sharp wrote: > > > > > > > Possible fixes > > > > -------------- > > > > > > > > The USB core obviously needs to be changed to check the port status > > > > after the TRSMRCY timeout, and continue to wait if the port is still in > > > > the resuming state. I will have to study the EHCI port status diagrams > > > > in detail to figure out how the USB core can do this. > > > > > > As far as EHCI is concerned, this is a non-problem. The closest > > > analogy to the RExit->U0 transition is in the description of the Force > > > Port Resume bit (bit 6) in Table 2-16 of the EHCI spec, where it says > > > that the host controller must complete the transition to the high-speed > > > idle state within 2 milliseconds of software setting the bit to a zero > > > (which happens when the hub driver does its Get-Port-Status call). > > > > > > Thus, as soon as the TRSMRCY delay is finished, the device and the port > > > are supposed to be ready. In fact, the hardware doesn't provide any > > > means of telling whether they are ready or not. > > > > Well, shoot, I thought I had solved world hunger, or at least USB power > > management issues. :) > > > > So basically it sounds like this is an xHCI specific issue, and probably > > not the root cause of the USB device disconnects we see under EHCI > > hosts. I guess the xHCI hardware engineers just assumed software would > > always wait for the interrupt from the port status change event, rather > > than using a simple 10 ms timer. I bet they didn't even realize that > > that the transition took longer than 10ms, because Windows waited for > > the port status change event. One last thought on this note: We know Windows doesn't have high-res timers, and Arjan says asking for a 10 ms delay will produce a delay around 17 ms. Since Linux is busy waiting, we may be communicating with the device sooner than Windows does. > Why can't Linux do the same thing, and not worry about any "timeout" at > all? We can for xHCI hosts, but not EHCI hosts. EHCI hosts only send an interrupt when the suspend change bit is set, which is when software needs to start the 10ms timer. It doesn't send an interrupt when that 10ms expires, unlike xHCI. We could add a new xHCI driver call, to resume the port, which would only return to the USB core when the port status change event occurs after the 10 ms (or longer) delay has finished. > > Should I print a debugging message if the xHCI host exceeds 10ms? I > > would be nice to let hardware engineers know they're out of spec. > > Sure, but the odds of anyone of them enabling debugging, and then > noticing this are slim to none. But if it makes us feel better pointing > out hardware bugs (I know it makes me feel good), please do so. It will make it easier to convince xHCI host designers that they need to improve their link training timing, so I'll leave it in. Besides, it's much more likely that people will have debugging enabled now that Xenia has made the driver use dynamic debug rather than a config option. :) 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
