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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html