Message-ID: <53E56B16.5030402@codeaurora.org>
Date:	Fri, 08 Aug 2014 17:28:06 -0700
From:	Laura Abbott <lauraa@...eaurora.org>
To:	Marek Szyprowski <m.szyprowski@...sung.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
CC:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linaro-mm-sig@...ts.linaro.org, devicetree@...r.kernel.org,
	Arnd Bergmann <arnd@...db.de>,
	Michal Nazarewicz <mina86@...a86.com>,
	Grant Likely <grant.likely@...aro.org>,
	Tomasz Figa <t.figa@...sung.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Nishanth Peethambaran <nishanth.p@...il.com>,
	Marc <marc.ceeeee@...il.com>,
	Josh Cartwright <joshc@...eaurora.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Paul Mackerras <paulus@...ba.org>,
	Jon Medhurst <tixy@...aro.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	"Aneesh Kumar K.V." <aneesh.kumar@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 0/4] CMA & device tree, once again

On 7/14/2014 12:12 AM, Marek Szyprowski wrote:
> Hello,
> 
> This is one more respin of the patches which add support for creating
> reserved memory regions defined in device tree. The last attempt
> (http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html)
> ended in merging only half of the code, so right now we have complete
> documentation merged and only basic code, which implements a half of it
> is written in the documentation. Although the merged patches allow to
> reserve memory, there is no way of using it for devices and drivers.
> 
> This situation makes CMA rather useless, as the main architecture (ARM),
> which used it, has been converted from board-file based system
> initialization to device tree. Thus there is no place to use direct
> calls to dma_declare_contiguous() and some new solution, which bases on
> device tree, is urgently needed.
> 
> This patch series fixes this issue. It provides two, already widely
> discussed and already present in the kernel, drivers for reserved
> memory: first based on DMA-coherent allocator, second using Contiguous
> Memory Allocator. The first one nicely implements typical 'carved out'
> reserved memory way of allocating contiguous buffers in a kernel-style
> way. The memory is used exclusively by devices assigned to the given
> memory region. The second one allows to reuse reserved memory for
> movable kernel pages (like disk buffers, anonymous memory) and migrates
> it out when device to allocates contiguous memory buffer. Both driver
> provides memory buffers via standard dma-mapping API.
> 
> The patches have been rebased on top of latest CMA and mm changes merged
> to akmp kernel tree.
> 
> To define a 64MiB CMA region following node is needed:
> 
> multimedia_reserved: multimedia_mem_region {
> 	compatible = "shared-dma-pool";
> 	reusable;
> 	size = <0x4000000>;
> 	alignment = <0x400000>;
> };
> 
> Similarly, one can define 64MiB region with DMA coherent memory:
> 
> multimedia_reserved: multimedia_mem_region {
> 	compatible = "shared-dma-pool";
> 	no-map;
> 	size = <0x4000000>;
> 	alignment = <0x400000>;
> };
> 

Longer term, I think it would be good if we didn't have to use no-map with
the coherent memory. With no-map and dma-coherent.c right now, not only
do you lose out on the physical memory space, you also have to give up
the same amount of vmalloc space for mapping. On arm32, if you have the default
240MB vmalloc space, 64M is ~25% of the vmalloc space. At least on arm you can
make this up by remapping the memory as coherent.

I haven't seen this picked up anywhere yet so you are welcome to add

Tested-by: Laura Abbott <lauraa@...eaurora.org>

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists