On Tue, 7 Jun 2011, Laurent Pinchart wrote: > Hi Soho and Alan, > > Sorry for the late reply. > > On Tuesday 31 May 2011 17:53:03 Soho Soho123 wrote: > > 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? > > The URB completion callback performs the following operations. > > - Header decoding. Every UVC packet starts with a header that contains a > couple of bit flags. Those flags are processed to detect image boundaries and > errors. > > - Data copy. If the packet contains payload data (as opposed to packets with a > header only), the payload is copied to another buffer. Whether the device will > send many small isochronous packets or few big ones is entirely up to the > device, but in the end the same amount of data will be copied. At most 3070 > bytes will be copied per URB. > > - Video buffer completion. If the driver detects that a frame is complete, it > will wake tasks waiting on the buffer. > > This can't really be optimized without removing URB processing from interrupt > context completely. I could just queue the URB buffers to a list and process > them in a workqueue. URBs could then be resubmitted faster, with another > buffer. However, if the platform isn't fast enough, the URB completion > callback will run out of buffers and will thus loose data. > > How much time are drivers allowed to spend in the URB completion callback ? > Why does the EHCI driver require very low latency there ? If the URB is > resubmitted too late, why can't it just be queued for the next (micro-)frame ? Never mind... This turned out to be a false alarm. Soho's problem wasn't caused by excessive time in the uvcvideo callback; it was caused by some completely different driver blocking interrupt delivery for more than 40 ms at a time. Sorry for the trouble. 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
