On Thursday 04 April 2013 19:49:26 Felipe Balbi wrote: > 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 ? Per-packet headers that need to be interpreted and then removed. -- Regards, Laurent Pinchart
Attachment:
signature.asc
Description: This is a digitally signed message part.
