On 09/01/2016 05:46 AM, Yangwei (Yang Wei, Device Chipset Key Technologies Platform Development Dept) wrote:
Hi all, When I review ion code in linux-3.18.y, I find a design that may cause a problem in our product. In the design, cma mem is allocated via the interface of dma_alloc_coherent , and this function will create a map to cpu. Sometimes, we just need cma phys addr, do not need cpu address. In our product, We need to map many discontinuous phy mem in kernel space, and those mem will use much vmalloc area. When cma mem is in highmem, it also need to use vmalloc area when Allocated, but we just use cma phys addr, the cpu virtual addr is not need. In linux-3.18.y, cma will reserved in high mem zone firstly. If cma mem is allocated more,and more vmalloc area will be used. This may cause a problem that the vmalloc area will not enough when discontinuous phys mem need to map. So, why dose cma mem need to map to cpu address when allocated ? As mem allocated in system heap, it does not map to cpu address at that time, and we can map it whenever we use it by map_kernel function dynamically. So, why cma heap is not designed like system heap? Best regards, Wei.Yang
The simple answer is that CMA is tied to dma_alloc_coherent and Ion went with the default behavior there which gives a CPU side mapping. The follow up question is "Could Ion support not having a CPU side mapping from dma_alloc_coherent". The answer to that question is yes with some additional patches. Take a look at DMA_ATTR_NO_KERNEL_MAPPING, this option does what you describe: it allocates the physical memory but does not create a CPU side mapping. This could be added to the dma_alloc_coherent call. You would need to be careful that what you implement would support CMA areas in lowmem as well, DMA_ATTR_NO_KERNEL_MAPPING does not clear the mapping from lowmem areas and you could end up with two different map types to the same region. Longer term, I hope to drop Ion's dependency on dma_alloc all together and just use the cma_alloc APIs. You could also take this more difficult approach and help speed up the architecture rework. Thanks, Laura _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
