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
