[st-ericsson] v4l2 vs omx for camera

[Marek Szyprowski]

Hello,

On Saturday, February 26, 2011 8:20 PM Nicolas Pitre wrote:

> On Sat, 26 Feb 2011, Kyungmin Park wrote:
> 
> > On Sat, Feb 26, 2011 at 2:22 AM, Linus Walleij <linus.walleij at linaro.org> wrote:
> > > 2011/2/24 Edward Hervey <bilboed at gmail.com>:
> > >
> > >>  What *needs* to be solved is an API for data allocation/passing at the
> > >> kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that
> > >> userspace (like GStreamer) can pass around, monitor and know about.
> > >
> > > I think the patches sent out from ST-Ericsson's Johan Mossberg to
> > > linux-mm for "HWMEM" (hardware memory) deals exactly with buffer
> > > passing, pinning of buffers and so on. The CMA (Contigous Memory
> > > Allocator) has been slightly modified to fit hand-in-glove with HWMEM,
> > > so CMA provides buffers, HWMEM pass them around.
> > >
> > > Johan, when you re-spin the HWMEM patchset, can you include
> > > linaro-dev and linux-media in the CC? I think there is *much* interest
> > > in this mechanism, people just don't know from the name what it
> > > really does. Maybe it should be called mediamem or something
> > > instead...
> >
> > To Marek,
> >
> > Can you also update the CMA status and plan?
> >
> > The important thing is still Russell don't agree the CMA since it's
> > not solve the ARM different memory attribute mapping issue. Of course
> > there's no way to solve the ARM issue.
> 
> There are at least two ways to solve that issue, and I have suggested
> both on the lak mailing list already.
> 
> 1) Make the direct mapped kernel memory usable by CMA mapped through a
>    page-sized two-level page table mapping which would allow for solving
>    the attributes conflict on a per page basis.

That's the solution I work on now. I've also suggested this in the last
CMA discussion, however there was no response if this is the right way

> 2) Use highmem more aggressively and allow only highmem pages for CMA.
>    This is quite easy to make sure the target page(s) for CMA would have
>    no kernel mappings and therefore no attribute conflict.  Furthermore,
>    highmem pages are always relocatable for making physically contiguous
>    segments available.

I'm not sure that highmem is the right solution. First, this will force
systems with rather small amount of memory (like 256M) to use highmem just
to support DMA allocable memory. It also doesn't solve the issue with
specific memory requirement for our DMA hardware (multimedia codec needs
video memory buffers from 2 physical banks).

The relocation issue has been already addressed in the last CMA patch series.
Michal managed to create a framework that allowed to relocate on demand any
pages from the CMA area.

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center