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. > > I can easily do > > this without the USB core being involved, by changing the xHCI driver to > > either: > > > > 1. Busy wait with xhci_handshake() in the xHCI get port status until > > the port is in U0. > > > > 2. Add a completion per xHCI port. In xHCI get port status, initiate > > U0 entry, and wait on the port's completion for up to 20 ms. In the > > port status change event code, complete that port's completion when > > the port is in U0 and the bus_state->resuming_ports bit is set. > > I would expect either of those to be adequate. I right, I think I'll do the busy wait, since 71% of the time it should return immediately. Completions are overkill here. 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. 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
