Hi, On Thu, Apr 04, 2013 at 04:52:15PM +0200, Laurent Pinchart 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. why do we even have that memcpy() there ? Why don't we use the same buffer for uvc_buffer->buf and urb->buffer ? That would cut all issues to a halt. Anything which prevents a zero-copy implementation ? -- balbi
Attachment:
signature.asc
Description: Digital signature
