On Thu, Jul 09, 2026 at 07:56:45AM +0200, Marek Szyprowski wrote: > On 08.07.2026 10:35, David Hildenbrand (Arm) wrote: > > On 7/7/26 12:02, Marek Szyprowski wrote: > >> On 01.07.2026 18:08, Thierry Reding wrote: > >>> From: Thierry Reding <[email protected]> > >>> > >>> There is no technical reason why there should be a limited number of CMA > >>> regions, so extract some code into helpers and use them to create extra > >>> functions (cma_create() and cma_free()) that allow creating and freeing, > >>> respectively, CMA regions dynamically at runtime. > >> > >> Well, the technical reason for not creating cma regions dynamically at > >> runtime is that on some architectures (like 32bit ARM) the early fixup > >> for the region is needed to make it functional for DMA. > > Can you point me at the code that does that? Thanks! > Check dma_contiguous_early_fixup() and dma_contiguous_remap() in > arch/arm/mm/dma-mapping.c. Those functions ensures that the CPU mappings for > the CMA reserved region in linear map are remapped with 4k pages instead > of the 1M sections, so later, it will be possible to alter the mappings and > change them to coherent when needed (altering 1M sections is not possible, > because each process has it's own level-1 array even for the kernel linear > mapping). > > > > However, in the use case in this patchset the reserved region is only shared > with buddy allocator by using the CMA infrastructure, not registered to the > regular DMA-mapping API, so it would work fine. I'm not convinced that this > is the right API to use for this though.
Are you saying you're not convinced that CMA is the right API to use for this? Or something else? I certainly don't think we want to get the DMA-mapping API involved for this because that always implies that we perform cache operations, which we specifically don't want for this memory. Thierry
signature.asc
Description: PGP signature
