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.
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.
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.
Nicolas