Dear Laurent, ====================================================================================== Let me explain my problem again. We use MJPG-streamser to test IP Cam function. the network interface is WiFi. WebCam is using UVC driver. We have the issue is the stream will disconnect in a few minutes on our embedded system. the reason is : the call back function of uvc urb complete can not re-submit urb successfully. The error code is "-EFBIG". EHCI driver think the urb submit is too late. the ip cam test condition is 1280x720 30 fps via WiFi(802.11n). the call back function seems take more cpu cycles when itd_complete, because it decode data and re-submit urb . the call back function is included in ehci irq path. it may increase irq latency. Do you have idea about : is it "must" decode data in uvcvideo complete call back function? is it "must" re-submit urb in uvcvideo complete call back function? Thanks! Best Regards, Soho ======================================================================================== 2011/5/31 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > 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
