UVC with continuous video buffers.
Hi, we have a system with a UVC camera connected to USB to acquire video images and a hardware processor which needs continuous memory buffers to process them. I've been looking at the current version of UVC drivers and it seems it allocates buffers using vmalloc_32() call: http://lxr.linux.no/#linux+v3.1/drivers/media/video/uvc/uvc_queue.c#L135 I am interested to extend the driver to support contiguous memory buffers and send it to mainline. What is the right way to achieve this? Can anyone please point me to a video driver example where continuous memory allocation is used? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVC with continuous video buffers.
On Wed, Nov 2, 2011 at 11:49 AM, javier Martin wrote: > Hi, > we have a system with a UVC camera connected to USB to acquire video > images and a hardware processor which needs continuous memory buffers > to process them. > > I've been looking at the current version of UVC drivers and it seems > it allocates buffers using vmalloc_32() call: > http://lxr.linux.no/#linux+v3.1/drivers/media/video/uvc/uvc_queue.c#L135 > > I am interested to extend the driver to support contiguous memory > buffers and send it to mainline. What is the right way to achieve > this? Can anyone please point me to a video driver example where > continuous memory allocation is used? I've actually got a very similar issue and have been looking into it (an em28xx device on OMAP requiring contiguous physical memory for the hardware H.264 encoder). One thing you may definitely want to check out is the patch sent earlier today with subject: [PATCH] media: vb2: vmalloc-based allocator user pointer handling While that patch is intended for videobuf2, you might be able to copy the core logic into videobuf-vmalloc. There are other drivers which use USERPTR provided buffers (which are allocated as contiguous memory from userland [i.e. vfpe_capture accepting buffers from cmemk on the OMAP platform]), but they typically do DMA so it's not really useful as an example where you have a USB based device. If you get it working, by all means send the code to the ML so others can benefit. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVC with continuous video buffers.
Hi Devin, thank you for your answer. On 2 November 2011 17:12, Devin Heitmueller wrote: > I've actually got a very similar issue and have been looking into it > (an em28xx device on OMAP requiring contiguous physical memory for the > hardware H.264 encoder). One thing you may definitely want to check > out is the patch sent earlier today with subject: My case is a i.MX27 SoC with its internal H.264 encoder. > [PATCH] media: vb2: vmalloc-based allocator user pointer handling > > While that patch is intended for videobuf2, you might be able to copy > the core logic into videobuf-vmalloc. I've seen a recent patch by Laurent Pinchart which provides vb2 support for UVC driver. It might also help: [PATCH 2/2] uvcvideo: Use videobuf2-vmalloc > There are other drivers which use USERPTR provided buffers (which are > allocated as contiguous memory from userland [i.e. vfpe_capture > accepting buffers from cmemk on the OMAP platform]), but they > typically do DMA so it's not really useful as an example where you > have a USB based device. > > If you get it working, by all means send the code to the ML so others > can benefit. Sure, though I will need some help because it seems some related frameworks are not ready for what we want to achieve. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVC with continuous video buffers.
Hi Javier, On Wednesday 02 November 2011 17:33:16 javier Martin wrote: > On 2 November 2011 17:12, Devin Heitmueller wrote: > > I've actually got a very similar issue and have been looking into it > > (an em28xx device on OMAP requiring contiguous physical memory for the > > hardware H.264 encoder). One thing you may definitely want to check > > out is the patch sent earlier today with subject: > > My case is a i.MX27 SoC with its internal H.264 encoder. > > > [PATCH] media: vb2: vmalloc-based allocator user pointer handling > > > > While that patch is intended for videobuf2, you might be able to copy > > the core logic into videobuf-vmalloc. > > I've seen a recent patch by Laurent Pinchart which provides vb2 support for > UVC driver. It might also help: > > [PATCH 2/2] uvcvideo: Use videobuf2-vmalloc I've finally had time to work on that recently, so you should be able to get all the videobuf2 goodies for free :-) However, the above patch that adds user pointer support in the videobuf2 vmalloc-based allocator only supports memory backed by pages. If you contiguous buffer is in a memory area reserved by the system at boot time, the assumption will not be true. Supporting user pointers with no struct page backing is possible, but will require a new patch for vb2. > > There are other drivers which use USERPTR provided buffers (which are > > allocated as contiguous memory from userland [i.e. vfpe_capture > > accepting buffers from cmemk on the OMAP platform]), but they > > typically do DMA so it's not really useful as an example where you > > have a USB based device. > > > > If you get it working, by all means send the code to the ML so others > > can benefit. > > Sure, though I will need some help because it seems some related frameworks > are not ready for what we want to achieve. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVC with continuous video buffers.
On Friday 04 November 2011 11:41:28 Laurent Pinchart wrote: > Hi Javier, > > On Wednesday 02 November 2011 17:33:16 javier Martin wrote: > > On 2 November 2011 17:12, Devin Heitmueller wrote: > > > I've actually got a very similar issue and have been looking into it > > > (an em28xx device on OMAP requiring contiguous physical memory for the > > > hardware H.264 encoder). One thing you may definitely want to check > > > > > out is the patch sent earlier today with subject: > > My case is a i.MX27 SoC with its internal H.264 encoder. > > > > > [PATCH] media: vb2: vmalloc-based allocator user pointer handling > > > > > > While that patch is intended for videobuf2, you might be able to copy > > > the core logic into videobuf-vmalloc. > > > > I've seen a recent patch by Laurent Pinchart which provides vb2 support > > for UVC driver. It might also help: > > > > [PATCH 2/2] uvcvideo: Use videobuf2-vmalloc > > I've finally had time to work on that recently, so you should be able to > get all the videobuf2 goodies for free :-) > > However, the above patch that adds user pointer support in the videobuf2 > vmalloc-based allocator only supports memory backed by pages. If you > contiguous buffer is in a memory area reserved by the system at boot time, > the assumption will not be true. Supporting user pointers with no struct > page backing is possible, but will require a new patch for vb2. I'm a bit hesitant about this. If I understand correctly this is really something that should be solved through the buffer sharing work that Sumit Semwal is working on. What several drivers do today is to allow user pointers that point to contiguous physical memory (using videobuf2-dma-contig.c). I've always found that pretty ugly, though. The buffer sharing API should make this much easier to handle, however, it is still in alpha stage. Regards, Hans > > > There are other drivers which use USERPTR provided buffers (which are > > > allocated as contiguous memory from userland [i.e. vfpe_capture > > > accepting buffers from cmemk on the OMAP platform]), but they > > > typically do DMA so it's not really useful as an example where you > > > have a USB based device. > > > > > > If you get it working, by all means send the code to the ML so others > > > can benefit. > > > > Sure, though I will need some help because it seems some related > > frameworks are not ready for what we want to achieve. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVC with continuous video buffers.
Hi Hans, On Friday 04 November 2011 11:58:26 Hans Verkuil wrote: > On Friday 04 November 2011 11:41:28 Laurent Pinchart wrote: > > On Wednesday 02 November 2011 17:33:16 javier Martin wrote: > > > On 2 November 2011 17:12, Devin Heitmueller wrote: > > > > I've actually got a very similar issue and have been looking into it > > > > (an em28xx device on OMAP requiring contiguous physical memory for > > > > the hardware H.264 encoder). One thing you may definitely want to > > > > check > > > > > > > out is the patch sent earlier today with subject: > > > My case is a i.MX27 SoC with its internal H.264 encoder. > > > > > > > [PATCH] media: vb2: vmalloc-based allocator user pointer handling > > > > > > > > While that patch is intended for videobuf2, you might be able to copy > > > > the core logic into videobuf-vmalloc. > > > > > > I've seen a recent patch by Laurent Pinchart which provides vb2 support > > > for UVC driver. It might also help: > > > > > > [PATCH 2/2] uvcvideo: Use videobuf2-vmalloc > > > > I've finally had time to work on that recently, so you should be able to > > get all the videobuf2 goodies for free :-) > > > > However, the above patch that adds user pointer support in the videobuf2 > > vmalloc-based allocator only supports memory backed by pages. If you > > contiguous buffer is in a memory area reserved by the system at boot > > time, the assumption will not be true. Supporting user pointers with no > > struct page backing is possible, but will require a new patch for vb2. > > I'm a bit hesitant about this. If I understand correctly this is really > something that should be solved through the buffer sharing work that > Sumit Semwal is working on. That's correct. This will also require composition support in the V4L2 capture drivers to be able to write in a frame buffer window for instance. > What several drivers do today is to allow user pointers that point to > contiguous physical memory (using videobuf2-dma-contig.c). I've always > found that pretty ugly, though. The buffer sharing API should make this > much easier to handle, however, it is still in alpha stage. That's the problem, we have no solution at the moment. User pointer support for memory not backed by struct page is an interim solution. If we decide not to support this but use the buffer sharing API instead, user pointer support in V4L2 will not be that useful anymore (not that it would necessarily be a bad thing). > > > > There are other drivers which use USERPTR provided buffers (which are > > > > allocated as contiguous memory from userland [i.e. vfpe_capture > > > > accepting buffers from cmemk on the OMAP platform]), but they > > > > typically do DMA so it's not really useful as an example where you > > > > have a USB based device. > > > > > > > > If you get it working, by all means send the code to the ML so others > > > > can benefit. > > > > > > Sure, though I will need some help because it seems some related > > > frameworks are not ready for what we want to achieve. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVC with continuous video buffers.
On 4 November 2011 11:41, Laurent Pinchart wrote: > Hi Javier, > > On Wednesday 02 November 2011 17:33:16 javier Martin wrote: >> On 2 November 2011 17:12, Devin Heitmueller wrote: >> > I've actually got a very similar issue and have been looking into it >> > (an em28xx device on OMAP requiring contiguous physical memory for the >> > hardware H.264 encoder). One thing you may definitely want to check >> > out is the patch sent earlier today with subject: >> >> My case is a i.MX27 SoC with its internal H.264 encoder. >> >> > [PATCH] media: vb2: vmalloc-based allocator user pointer handling >> > > However, the above patch that adds user pointer support in the videobuf2 > vmalloc-based allocator only supports memory backed by pages. If you > contiguous buffer is in a memory area reserved by the system at boot time, the > assumption will not be true. Supporting user pointers with no struct page > backing is possible, but will require a new patch for vb2. > Hi Laurent, thanks for your help. I am using dma_declare_coherent_memory() at startup to reserve memory. Then I use dma_alloc_coherent() in my driver through 'videobuf2-dma-contig.h' (emma-PrP I've recently submitted). I understand these functions provide memory backed by pages and you are referring to the case where you use the 'mem' argument of the kernel to leave memory unused. Am I right? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UVC with continuous video buffers.
Hi Javier, On Thursday 17 November 2011 11:55:28 javier Martin wrote: > On 4 November 2011 11:41, Laurent Pinchart wrote: > > On Wednesday 02 November 2011 17:33:16 javier Martin wrote: > >> On 2 November 2011 17:12, Devin Heitmueller wrote: > >> > I've actually got a very similar issue and have been looking into it > >> > (an em28xx device on OMAP requiring contiguous physical memory for the > >> > hardware H.264 encoder). One thing you may definitely want to check > >> > >> > out is the patch sent earlier today with subject: > >> My case is a i.MX27 SoC with its internal H.264 encoder. > >> > >> > [PATCH] media: vb2: vmalloc-based allocator user pointer handling > > > > However, the above patch that adds user pointer support in the videobuf2 > > vmalloc-based allocator only supports memory backed by pages. If you > > contiguous buffer is in a memory area reserved by the system at boot > > time, the assumption will not be true. Supporting user pointers with no > > struct page backing is possible, but will require a new patch for vb2. > > Hi Laurent, > thanks for your help. > > I am using dma_declare_coherent_memory() at startup to reserve memory. > Then I use dma_alloc_coherent() in my driver through > 'videobuf2-dma-contig.h' (emma-PrP I've recently submitted). I > understand these functions provide memory backed by pages and you are > referring to the case where you use the 'mem' argument of the kernel > to leave memory unused. Am I right? I think you're right, yes. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
