On Fri, 19 Jul 2013 sgtcapslock@xxxxxxxxxxx wrote: > > Can you provide usbmon traces showing what happens when the mouse is > > plugged in to an OHCI controller and when it is plugged in to an EHCI > > controller? Instructions are in Documentation/usb/usbmon.txt. > > > > Alan Stern > > > > > > Absolutely. Ahh, I'm not really sure if I should send them as attachments > to this message or not, so I've decided to put them up on a paste site. > Please let me know if you want them here instead. > > Here's that same mouse (Zowie EC1 eVo) plugged into a [native ehci] port > on the board which hands it off to ohci: > > http://pastebin.com/auM1MavY > > And here it is when plugged into an external USB hub on one of the same > ports, which causes it to use the ehci driver instead: > > http://pastebin.com/1r7BQSBw I think I see what's going on. The usbhid driver uses a single interrupt URB to receive data from the device. When the URB completes, it gets resubmitted to receive the next packet of data. The OHCI controller issues interrupts at frame boundaries, and it probably gets the information for upcoming interrupt transfers at the beginning of a frame. Thus, suppose some data is received during frame N. An interrupt occurs and the URB completes at the end of frame N. The usbhid driver processes the data and then resubmits the URB. By that time, however, it is already too late for the controller to handle it during frame N+1. It doesn't get handled until frame N+2. Since each frame is one millisecond, the maximum polling rate ends up being 500 Hz. With EHCI controllers, interrupts occur at the boundaries of microframes rather than frames. Thus, the usbhid driver gets the data and processes it after only 1/8 ms has elapsed, which leaves enough time to resubmit the URB before frame N+1 begins. This could be considered a bug in the usbhid driver. As far as I can see, the only way to fix it is to use two interrupts URBs rather than one. 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
