Hi Ravi, On Friday 29 March 2013 14:14:35 B, Ravi wrote: > Laurent/Ming Lei > > >>>>> 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, > >> > >> typo mistake, read as "bottle-neck" > >> > >> 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. In general it is, but the amount of data to be copied is pretty small, so I'm not sure if it's worth it for the uvcvideo driver. If reading from coherent memory is that slow you won't be able to sustain the required bandwidth, regardless of whether the memcpy is performed in interrupt context or not. The driver will be unusable in both case. > > You are correct, I have profiled, the timing I have posted in previous > > mail are due to the memcpy() in uvc_video_decode_data(). Which is the > > bottle-neck and consumes most of the time. > > There is an improvement in timing after defining CONFIG_DMA_NONCOHERENT, the > coherent memory access is very slow leads to this issue. > > #ifndef CONFIG_DMA_NONCOHERENT > stream->urb_buffer[i] = usb_alloc_coherent( > stream->dev->udev, stream->urb_size, > gfp_flags | __GFP_NOWARN, > &stream->urb_dma[i]); #else > stream->urb_buffer[i] = > kmalloc(stream->urb_size, gfp_flags | > __GFP_NOWARN); #endif Can your platform really DMA from non-coherent memory ? If so, why isn't CONFIG_DMA_NONCOHERENT unset ? > The mentor host controller (driver/usb/musb) puts all overhead on SW to > schedule the next urb, unlike like ehci/xhci where the multiple urbs (TDs) > can be queued and HW executes the transfers on the bus without SW > intervention. In case of musb host controller, the SW has to program the > urb one by one, hence it is critical that urb completion callback called in > interrupt context must be very thin. -- 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
