On Sat, 26 Feb 2011, Kyungmin Park wrote: > On Sat, Feb 26, 2011 at 2:22 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > 2011/2/24 Edward Hervey <bilboed@xxxxxxxxx>: > > > >> 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
