linux-toradex.git/kernel/dma/Kconfig, branch master

dma-contiguous: simplify numa cma area handling

2026-05-28T08:11:45+00:00

Currently, there are 2 kernel cmdline ways to setup numa cma area:
"cma_pernuma=" and "numa_cma=", and there are 2 cma arrays as well,
while they have no difference technically. Robin suggested to cleanup
the code and only use one array [1], as "the apparent intent that
users only want one _or_ the other".

Simplify the code by only using one array to save the numa cma area.
And in rare case that a user really setup the 2 cmdline parameters
at the same time,  let the per-node specific size setting 'numa_cma='
take priority over the global numa cma setting.

Link[1]: https://lore.kernel.org/lkml/43c5301c-fe6a-41e4-9482-ccfc7b62f2a7@arm.com/

Suggested-by: Robin Murphy 
Signed-off-by: Feng Tang 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20260525015111.6267-1-feng.tang@linux.alibaba.com

dma-contiguous: add kconfig option to setup numa cma area if not configured explicitly

2026-05-22T05:57:40+00:00

There was a report on a multi-numa-nodes arm64 server that when IOMMU
is disabled, the dma_alloc_coherent() function always returns memory
from node 0 even for devices attaching to other nodes, while they can
get local dma memory when IOMMU is on with the same API.

The reason is, when IOMMU is disabled, the dma_alloc_coherent() will
go the direct way and call dma_alloc_contiguous(). The system doesn't
have any explicit cma setting (like per-numa cma), and only has a
default 64MB cma reserved area (on node 0), where kernel will try
first to allocate memory from.

Robin Murphy suggested to setup pernuma cma or disable cma, which did
solve the issue. While there is still concern that for customers
which don't have much kernel knowledge, they could still suffer from
this silently as some architectures enable cma area by default (not
an issue for X86 though, which set CONFIG_CMA_SIZE_MBYTES to 0 by
default) for most Linux distributions.

One thought is to follow the current cma reserving policy for platform
with 'CONFIG_DMA_NUMA_CMA=y', that if the numa cma (either the 'numa cma'
or 'cma pernuma' method) is not explicitly configured, and the platform
really has multiple NUMA nodes, set it up according to size of default
'dma_contiguous_default_area'. This way, the default behavior of
platform with one NUMA node is kept unchanged (say embedded/small
devices don't need to allocate extra memory), while the general dma
locality is improved.

Add a new bool kernel config CONFIG_CMA_SIZE_PERNUMA to control whether
to enable it. Even when the config is enabled, user can still disable
it by kernel-cmdline setting like "numa_cma=0:0" or "cma_pernuma=0".

Reported-by: Changrong Chen 
Suggested-by: Ying Huang 
Suggested-by: Robin Murphy 
Signed-off-by: Feng Tang 
Link: https://lore.kernel.org/r/20260512085509.83002-1-feng.tang@linux.alibaba.com
Link: https://lore.kernel.org/all/20260520222742.GA1607511@ax162/
[mszyprow: squashed changes from both links, added __initdata attribute
           to the numa_cma_configured variable]
Signed-off-by: Marek Szyprowski

dma-mapping: Separate DMA sync issuing and completion waiting

2026-03-13T22:47:31+00:00

Currently, arch_sync_dma_for_cpu and arch_sync_dma_for_device
always wait for the completion of each DMA buffer. That is,
issuing the DMA sync and waiting for completion is done in a
single API call.

For scatter-gather lists with multiple entries, this means
issuing and waiting is repeated for each entry, which can hurt
performance. Architectures like ARM64 may be able to issue all
DMA sync operations for all entries first and then wait for
completion together.

To address this, arch_sync_dma_for_* now batches DMA operations
and performs a flush afterward. On ARM64, the flush is implemented
with a dsb instruction in arch_sync_dma_flush(). On other
architectures, arch_sync_dma_flush() is currently a nop.

Cc: Leon Romanovsky 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Marek Szyprowski 
Cc: Robin Murphy 
Cc: Ada Couprie Diaz 
Cc: Ard Biesheuvel 
Cc: Marc Zyngier 
Cc: Anshuman Khandual 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Joerg Roedel 
Cc: Stefano Stabellini 
Cc: Oleksandr Tyshchenko 
Cc: Tangquan Zheng 
Reviewed-by: Juergen Gross  # drivers/xen/swiotlb-xen.c
Tested-by: Xueyuan Chen 
Signed-off-by: Barry Song 
Reviewed-by: Leon Romanovsky 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/20260228221316.59934-1-21cnbao@gmail.com

dma-mapping: Remove dma_mark_clean (again)

2026-01-07T23:19:08+00:00

With IA-64 now gone, there are no users of the dma_mark_clean hook,
so we can retire it for good.

Signed-off-by: Robin Murphy 
Signed-off-by: Marek Szyprowski 
Link: https://lore.kernel.org/r/c004927f01962726ff1dcf94d1b4efff84db805a.1767727673.git.robin.murphy@arm.com

dma-debug: remove DMA_API_DEBUG_SG

2024-10-29T07:53:37+00:00

The scatterlist validity checks are pretty simple and cheap, perform them
unconditionally.

Signed-off-by: Christoph Hellwig

dma-mapping: clearly mark DMA ops as an architecture feature

2024-09-04T04:08:51+00:00

DMA ops are a helper for architectures and not for drivers to override
the DMA implementation.

Unfortunately driver authors keep ignoring this.  Make the fact more
clear by renaming the symbol to ARCH_HAS_DMA_OPS and having the two drivers
overriding their dma_ops depend on that.  These drivers should probably be
marked broken, but we can give them a bit of a grace period for that.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Thomas Gleixner 
Acked-by: Sakari Ailus  # for IPU6
Acked-by: Robin Murphy

dma-mapping: direct calls for dma-iommu

2024-08-22T04:18:11+00:00

Directly call into dma-iommu just like we have been doing for dma-direct
for a while.  This avoids the indirect call overhead for IOMMU ops and
removes the need to have DMA ops entirely for many common configurations.

Signed-off-by: Leon Romanovsky 
Signed-off-by: Leon Romanovsky 
Acked-by: Greg Kroah-Hartman 
Acked-by: Robin Murphy 
Signed-off-by: Christoph Hellwig

dma: compile-out DMA sync op calls when not used

2024-05-07T11:29:53+00:00

Some platforms do have DMA, but DMA there is always direct and coherent.
Currently, even on such platforms DMA sync operations are compiled and
called.
Add a new hidden Kconfig symbol, DMA_NEED_SYNC, and set it only when
either sync operations are needed or there is DMA ops or swiotlb
or DMA debug is enabled. Compile global dma_sync_*() and dma_need_sync()
only when it's set, otherwise provide empty inline stubs.
The change allows for future optimizations of DMA sync calls depending
on runtime conditions.

Signed-off-by: Alexander Lobakin 
Signed-off-by: Christoph Hellwig

dma-direct: add a CONFIG_ARCH_HAS_DMA_ALLOC symbol

2023-10-22T14:38:54+00:00

Instead of using arch_dma_alloc if none of the generic coherent
allocators are used, require the architectures to explicitly opt into
providing it.  This will used to deal with the case of m68knommu and
coldfire where we can't do any coherent allocations whatsoever, and
also makes it clear that arch_dma_alloc is a last resort.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Robin Murphy 
Reviewed-by: Greg Ungerer 
Tested-by: Greg Ungerer

dma-direct: add dependencies to CONFIG_DMA_GLOBAL_POOL

2023-10-22T14:38:02+00:00

CONFIG_DMA_GLOBAL_POOL can't be combined with other DMA coherent
allocators.  Add dependencies to Kconfig to document this, and make
kconfig complain about unmet dependencies if someone tries.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Robin Murphy 
Reviewed-by: Lad Prabhakar 
Reviewed-by: Greg Ungerer 
Tested-by: Greg Ungerer