On Tue, 31 May 2011, Soho Soho123 wrote: > Dear Alan, > > After tracing the flow, and we do the measurement about cpu cycles for > function in ehci irq path. We find the function scan_periodic(), in > for loop, case Q_TYPE_ITD will occupy much cpu cycles. It will > increase irq latency for ehci. Good, you found the source of your problem. > below is the issue that increase irq latency: > 1. when in case Q_TYPE_ITD , it will run itd_complete() for URB complete. Yes. The rest of the code in the Q_TYPE_ITD case (that is, everything except the itd_complete() call) should run very fast. > 2. if modified is true, then it will goto restart, then case > Q_TYPE_ITD will run again, it is repeatly. Actually it should run only twice. The second time through, itd_complete() will not be called and so modified will not be true. > 3. Sometime, we can see uvc driver uvc_video_decode_isoc() will take > much cpu cycle,too. Since uvc driver decode data in complete call back > function. That sounds like the real cause of the latency. > Our question: > is it possible to modify flow of uvc driver? Since in complete call > back function, it will do decode and re-submit new urb. it will take > more time, right? I don't know anything about the uvcvideo driver. You should ask driver's maintainer (CC'ed). > is it possible to reduce the time for case Q_TYPE_ITD? If you look carefully, you'll probably find that most of the time is used by uvcvideo. I don't think the code in ehci-hcd can be improved very much. > Note: > the test condition: > ip camera configuration: 1280x720, 30fps > > Could you kindly help to give us the hints for the enhancement iso schedule? If the real problem is in uvcvideo, changing ehci-hcd won't help. 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
