Re: Using UVC webcam gadget with a real v4l2 device

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Bhupesh,

On Monday 30 April 2012 18:47:24 Bhupesh SHARMA wrote:
> On Monday, April 30, 2012 3:51 PM Laurent Pinchart wrote:
> > On Thursday 26 April 2012 13:23:59 Bhupesh SHARMA wrote:
> > > Hi Laurent,
> > > 
> > > Sorry to jump-in before your reply on my previous mail, but as I was
> > > studying the USERPTR stuff in more detail, I have a few more queries
> > > which I believe you can include in your reply as well..
> > 
> > [snip]
> > 
> > > I am now a bit confused on how the entire system will work now:
> > > - Does USERPTR method needs to be supported both in UVC gadget and
> > > soc-camera side, or one can still support the MMAP method and the other
> > > can now be changed to support USERPTR method and we can achieve a ZERO
> > > buffer copy operation using this method?
> > 
> > You need USERPTR support on one side only. In practice many (all?) soc-
> > camera drivers require physically contiguous memory, so you will need to
> > use MMAP on the soc-camera side and USERPTR on the UVC gadget side.
> > DMABUF, when merged in the kernel, will be a better solution (but will
> > require all drivers to use vb2).
> 
> Perfect. So, I plan now to add vb2 support for uvc-gadget and leave soc-
> camera side to use the mmap stuff.
> 
> Now, waiting for your pointers for managing the race-conditions in the UVC
> gadget and also avoiding the memcpy that is happening in the QBUF call on
> the UVC gadget, before I start the actual work.

The memcpy doesn't happen at QBUF time, but when filling the URBs. Avoiding it 
will be pretty difficult, as the driver needs to add packet headers. I would 
leave that out for now.

Regarding videobuf2 support, the main issue comes from race conditions between 
stream start, buffer queueing and URB completion. Unlike the UVC host driver 
where URBs can be resubmitted immediately, the gadget driver can only resubmit 
URBs (in uvc_video_complete()) when there is data to be sent. Otherwise the 
URB is put on a free URBs list (video->req_free) and enqueued in 
uvc_video_pump() the next time a buffer is queued. This requires taking 
various locks and must thus be considered with care. I'm pretty unhappy with 
calling video->encode with the queue irqlock held, I would like to change 
that, but I don't expect to to be an easy task.

-- 
Regards,

Laurent Pinchart