On Wed, 9 Apr 2014, Clemens Ladisch wrote: > Alan Stern wrote: > > The IN transfer was 1 frame long and scheduled for frame 1123, so its > > completion indicates that the current frame number is >= 1123. The OUT > > transfer was 6 frames long and scheduled for frame 1111, so it should > > have completed in frame 1117. But the timestamps show that the two > > URBs completed at the same time (only 13 us between them). > > Looks like interrupt moderation. I don't think so; to me it looks more like a bug. We're already getting one interrupt per ms for the IN endpoint anyway; there's no reason to moderate the one-every-6-ms interrupts for the OUT endpoint. Also, with moderation you'd see several URBs apparently completing at once, but that's not what happened here. In fact, I get the impression that with isochronous URBs A, B, C,... in the queue, xhci-hcd doesn't report the completion of A to the driver until B has terminated, and it reports the completion of B when C has terminated, etc. That's got to be a programming error somewhere. > What minimum queue length should a driver use to work with all HCs? What snd-usb-audio is doing right now should be fine. While I'm not acquainted with the detailed operation of xhci-hcd, its requirements should not be any more strict than those of ehci-hcd. And this was a full-speed USB device -- not even high speed, let alone SuperSpeed! Furthermore, I clearly recall Sarah Sharp (the original maintainer for xhci-hcd) saying that the support for isochronous transfers needed attention. This may well be an example. 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
