The core idea
CPUs often cache recently used memory to reduce latency. A DMA-capable peripheral may read or write RAM without going through the CPU's caches. On a non-coherent system, cached data and RAM can temporarily differ, so software must follow the platform's DMA and cache-maintenance rules.
Two common directions
CPU → device (DMA reads memory)
The CPU prepares a buffer, then the device reads it. If the CPU has dirty cache lines, software may need to synchronize the buffer so the device sees the latest contents before starting DMA.
Device → CPU (DMA writes memory)
The device writes incoming data to RAM. Before the CPU consumes that data, software may need to invalidate or otherwise synchronize cache state so stale cached lines are not used.
Use the operating system's DMA API
In Linux drivers, prefer the documented DMA mapping and synchronization APIs—such as dma_map_single(), dma_unmap_single(), or the appropriate dma_sync_* calls for the buffer type and mapping lifecycle—instead of manually guessing cache operations. Coherent DMA allocations and streaming mappings have different rules.
Practical checklist
- Confirm whether the platform and device path are cache-coherent.
- Use DMA-capable memory and mapping APIs correctly.
- Observe DMA direction and mapping lifetime.
- Do not let the CPU and device access a streaming buffer concurrently unless the API and design explicitly support it.
- Follow the kernel documentation for the target architecture and device.
This is a conceptual overview, not a substitute for the Linux kernel DMA API documentation for your target platform.