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@linaro.org wrote:
2011/2/24 Edward Hervey bilboed@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.
- 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
- 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