On Mon, 26 Aug 2013, Sarah Sharp wrote: > 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.
This sounds a little confused. The end of the TRSMRCY period isn't signalled by an interrupt on any host controller, not even on xHCI. It's just a regular kernel timer. We could increase it from 10 ms to 17 (or 20), but only at the cost of increasing resume latency for every USB device. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
