since switching to dma-direct, memory using DMA_ATTR_NO_KERNEL_MAPPING
is no longer allocated using the arch specific handlers and instead
will use dma_direct_alloc_no_mapping. While the arm specific allocation
handlers implicitly clear the allocated dma buffers and will flush any caches
dma-direct relies on ARCH_HAS_DMA_PREP_COHERENT to flush the caches.

Without this flush video frame corruption can occur in drivers
like the coda v4l2 driver which explicitly sets the DMA_ATTR_NO_KERNEL_MAPPING flag.

Fixes: ae626eb97376 ("ARM/dma-mapping: use dma-direct unconditionally")
Signed-off-by: Christian Meissl <meissl.christian@gmail.com>
---
 arch/arm/Kconfig          | 1 +
 arch/arm/mm/dma-mapping.c | 8 ++++++++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3072731fe09c..7a3aaf3a490b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM
        select ARCH_HAS_DEBUG_VIRTUAL if MMU
        select ARCH_HAS_DMA_ALLOC if MMU
        select ARCH_HAS_DMA_OPS
+       select ARCH_HAS_DMA_PREP_COHERENT
        select ARCH_HAS_DMA_WRITE_COMBINE if !ARM_DMA_MEM_BUFFERABLE
        select ARCH_HAS_ELF_RANDOMIZE
        select ARCH_HAS_FORTIFY_SOURCE
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 88c2d68a69c9..bde7ae4ba31a 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1821,3 +1821,11 @@ void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
 {
        __arm_dma_free(dev, size, cpu_addr, dma_handle, attrs, false);
 }
+
+void arch_dma_prep_coherent(struct page *page, size_t size)
+{
+       void *ptr = page_address(page);
+
+       dmac_flush_range(ptr, ptr + size);
+       outer_flush_range(__pa(ptr), __pa(ptr) + size);
+}
-- 
2.49.0

On Tue, Jun 17, 2025 at 09:54:46AM +0200, Christian Meissl wrote:
> since switching to dma-direct, memory using DMA_ATTR_NO_KERNEL_MAPPING
> is no longer allocated using the arch specific handlers and instead
> will use dma_direct_alloc_no_mapping. While the arm specific allocation
> handlers implicitly clear the allocated dma buffers and will flush any caches
> dma-direct relies on ARCH_HAS_DMA_PREP_COHERENT to flush the caches.
> 
> Without this flush video frame corruption can occur in drivers
> like the coda v4l2 driver which explicitly sets the DMA_ATTR_NO_KERNEL_MAPPING flag.
> 
> Fixes: ae626eb97376 ("ARM/dma-mapping: use dma-direct unconditionally")
> Signed-off-by: Christian Meissl <meissl.christian@gmail.com>
[...]
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 88c2d68a69c9..bde7ae4ba31a 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1821,3 +1821,11 @@ void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
>  {
>         __arm_dma_free(dev, size, cpu_addr, dma_handle, attrs, false);
>  }
> +
> +void arch_dma_prep_coherent(struct page *page, size_t size)
> +{
> +       void *ptr = page_address(page);
> +
> +       dmac_flush_range(ptr, ptr + size);
> +       outer_flush_range(__pa(ptr), __pa(ptr) + size);
> +}

It probably doesn't make any difference in practice, FWIW arm64 only
does a clean rather than flush (clean+invalidate) here.

What I noticed is that arch_dma_prep_coherent() is only called for
lowmem pages, so doing page_address() is safe. However, I don't think we
have anything to flush the caches for highmem pages.

-- 
Catalin