Laurent > > > On Thu, Mar 28, 2013 at 08:53:03PM +0800, Ming Lei wrote: > > > > On Thu, Mar 28, 2013 at 8:30 PM, B, Ravi <ravib...@ti.com> wrote: > > > > > 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. > > > > > > > > uvc_video_decode_data() is basically a memcpy() from coherent buffer > to > > > > normal buffer. > > > > > > if that's the case, this should show, right ? > > > > > > Maybe not, it might be worse(per my previous test on Pandaboard A1) to > > > change to DMA streaming buffer, since DMA unmapping has become > > > expensive too for reading from device after invalidating buffer is > added > > > to handle speculative prefetching, and before that, DMA unmapping was > > > basically a nop on ARM. > > > > > > But you guys can do the test again, or do some analysis about such > slow > > > memcpy() on coherent buffer. > > > > Since the uvc_video_complete() callback handler called from interrupt > > context, video post processing or memcpy can be deferred to tasklet or > > bottom half, rather than doing it in interrupt context. > > If that's the only way to fix the issue, yes. However, given your really > poor > memcpy() performances, I don't think you will be able to sustain the > incoming > video bandwidth. The driver would soon run out of URBs.
I agree with you, let me check whether memcpy is the bottle here, I will try to get profile info on this. But in general it would be good to move post processing to bottom half which helps to reduce interrupt latency. Thanks -- Ravi B -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
