On Thu, Jul 11, 2013 at 3:02 PM, Johannes Stezenbach <js@xxxxxxxxx> wrote: > I'm not familiar with musb but a quick glance at the code > shows it uses software packet scheduling. If you do too > much processing in the URB completion callback (which > is called from irq context), then the next bus transaction > is delayed by that time. See musb_advance_schedule() vs. > musb_giveback() and also the big comment at the start > of musb_core.c. I guess if you want to make em28xx work > with musb you need to move all processing to a tasklet > or similar. I think the issue you are seeing on musb has > nothing to do with the issue on Intel EHCI. Funny - I had the same thought a few hours ago about moving the actual URB processing to a tasklet. However I don't think it will help. Here's why: Expanding on the test where I cut out everything in the URB handler except for the submit, I tweaked the code so that it still does the accounting so that video buffers get delivered but it skips the memcpy() call (which is probably 99% of the work). This results in the URB handler itself having essentially zero cost but empty buffers get delivered to userland so the rest of the system behaves as it normally would. In this case I was still seeing corruption and skipped microframes via the Beagle, suggesting that the reason the corruption went away when I commented out the body of the completion handler wasn't because the cost of executing the completion handler went to zero, but rather because the rest of the system load had gone down as well because no video buffers were being delivered to the rest of the system. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
