On Thu, Jul 11, 2013 at 02:12:08PM -0400, Alan Stern wrote: > On Thu, 11 Jul 2013, Devin Heitmueller wrote: > > > Another strange thing: If I change the completion handler on the 8147 > > to comment out the actual processing of the URB (such that all the > > completion handler does is resubmit the URB), the problem disappears. > > The isoc stream as captured by the Beagle shows no video corruption, > > and no 250us gaps. If I were to speculate, I think this might be > > either because I've reduced the overall load on the system (not only > > is the URB handler not actually doing anything, but the userland code > > which process the video is no longer receiving frames), or > > alternatively the URB completion handler takes such a long time to > > execute that it actually prevents the hardware from sending out > > microframes (due to raw CPU load, the fact it's happening in interrupt > > context, or because of some shared lock). > > The musb driver makes much greater demands on the CPU than the EHCI > driver, relative to the different CPU speeds. Reducing the total load > on the ti8147 thus could significantly improve the performance. 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. Johannes -- 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
