Hi Alan, On Tuesday 07 June 2011 15:34:48 Alan Stern wrote: > On Tue, 7 Jun 2011, Laurent Pinchart wrote: > > 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. No worries. Do you think I should try to reduce the amount of operations performed by the uvcvideo driver in the URB completion callback by moving them to a workqueue, or is the current driver behaviour (as described above) acceptable ? -- Regards, Laurent Pinchart -- 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
