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.
> > >
>
> 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
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.
--
Ravi B
--
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
