Laurent > > > > > > Some more debugging, Most of the time spend in stream->decode() > function > > > > That points to uvc_video_decode_isoc(). > > You are correct, that points to uvc_video_decode_isoc() > > > > > > in uvc_video_complete() callback handler. > > > > It's not very surprising, but doesn't tell where the problem comes from. > > As > > Ming Lei pointed out, slow access to coherent memory might be an > > explanation. > > Could you find out how the time is spent between > uvc_video_decode_start(), > > uvc_video_decode_data() and uvc_video_decode_data() ? It might also be > > worth > > it timing the uvc_queue_next_buffer() calls, in case the function is > > delayed > > by spinlock contention (if you're running on an SMP system). > > I did not dig further, I try to get this timing info. > > Quickly I tried another experiment, instead of calling stream->decode() in > callback, initiated work thread, which perform stream->decode() & re- > submit urb. This reduces the uvc_video_callback() time to 12usec, But > after 900 urb completion, submit_urb() failed with -EBUSY error. Further I > stopped debugging, something I may not be doing right at uvc level. > > Thanks Laurent. I profiled the uvc_video_decode_isoc(), the maximum time was taken by uvc_video_decode_data() function. For example, in one iteration I have observed, the time taken by uvc_video_decode_isoc() was 2175 usec. In this maximum amount of time was consumed by uvc_video_decode_data() around 1792 usec. The function uvc_video_decode_data() was called in loop, below the time taken in each iteration. The total was around 1792 usec. SUM(108, 59, 72, 57, 108, 58, 108, 58, 72, 87, 72, 58, 108, 59, 82, 58, 108,59, 72, 87, 74, 59, 109) = 1792 usec let me know if you need any further info. -- Ravi B -- 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
