On Thu, 22 Aug 2013, Sarah Sharp wrote: > > 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. Probably not. After all, USB-2 does not have the elaborate link training and other link management "features" that USB-3 does. What device disconnects do you see under EHCI? I don't recall hearing about them. > 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. What do you mean? EHCI doesn't have any port-status change event at the end of the 10-ms TRSMRCY delay. The only port-status change event in the hardware is right at the beginning, when the resume is initiated. The same is true of UHCI, but OHCI is different. > > > 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. Although that will be adequate, it may not be ideal. You'll still get a 10-ms TRSMRCY delay following the busy wait. Unless you change the hub driver to eliminate that delay for xHCI host controllers. > 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. It can't hurt. Alan Stern -- 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
