On Friday 29 March 2013 05:24:27 B, Ravi wrote: > On Thu, Mar 28, 2013 at 9:27 PM, Felipe Balbi wrote: > On Thu, Mar 28, 2013 at 03:23:46PM +0200, Felipe Balbi wrote: > > On Thu, Mar 28, 2013 at 08:53:03PM +0800, Ming Lei wrote: > > > On Thu, Mar 28, 2013 at 8:30 PM, B, Ravi <ravibabu@xxxxxx> 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. > > It is not odd to see I/O performance isn't very good on ARM... -- 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
