Skip to content

Day 99 - Linux DMA Engine Framework

Today's Goal

Begin learning the Linux DMA Engine Framework.

Unlike previous kernel memory topics, this series focuses on how Linux abstracts different DMA controller implementations into a unified programming interface. The objective of Day99 is to understand the overall architecture before exploring individual APIs and controller implementations.

What I Learned

Today focused on the overall architecture of the Linux DMA Engine Framework instead of implementation details.

DMA Basics

Reviewed the role of Direct Memory Access (DMA) and how it differs from CPU-driven memory transfers.

Key concepts include:

  • DMA Controller
  • DMA Channel
  • Memory-to-Memory transfer
  • Memory-to-Peripheral transfer
  • Peripheral-to-Memory transfer
  • DMA completion interrupt

Also discussed how peripherals cooperate with DMA using hardware DMA requests instead of CPU polling.

Circular DMA

Studied how circular DMA is commonly used for peripherals with unknown or continuous data lengths, such as UART.

Important observations:

  • DMA does not understand communication protocols.
  • The peripheral generates DMA requests whenever data becomes available.
  • DMA continuously fills a ring buffer.
  • The driver determines how and when to process received data.
  • Completion may be detected using polling, idle interrupts, half-transfer interrupts, or transfer-complete interrupts.

This clarified the responsibility boundary between:

  • Peripheral
  • DMA Controller
  • Driver
  • Protocol Parser

Linux DMA Engine Framework

Learned why Linux introduces a framework layer between client drivers and hardware-specific DMA controller drivers.

Overall architecture:

Application
        │
        ▼
Client Driver
        │
        ▼
DMA Engine Framework
        │
        ▼
DMA Controller Driver
        │
        ▼
DMA Hardware

This abstraction allows client drivers to remain portable across different SoCs without directly accessing DMA controller registers.

Major Objects

Introduced the three primary DMA Engine objects:

  • struct dma_device
  • struct dma_chan
  • struct dma_async_tx_descriptor

Current understanding:

Object Responsibility
dma_device Represents a DMA controller
dma_chan Represents a DMA channel used by client drivers
dma_async_tx_descriptor Describes a single DMA transaction

Also clarified that dma_async_tx_descriptor is used for both transmit and receive operations. The historical tx name originates from the Linux Async Transaction framework rather than UART transmit operations.

DMA Workflow

Studied the typical DMA Engine workflow:

Request Channel
        │
        ▼
Prepare Descriptor
        │
        ▼
Submit
        │
        ▼
Issue Pending
        │
        ▼
DMA Running
        │
        ▼
Transfer Complete
        │
        ▼
Callback

One important concept learned today is that:

  • dmaengine_submit() only queues a transaction.
  • dma_async_issue_pending() actually starts DMA execution.

This queue-based design allows multiple DMA transactions to be prepared before hardware execution begins.

Common DMA APIs

Reviewed the purpose of the major DMA Engine APIs without studying their detailed prototypes.

Main APIs include:

  • dma_request_chan()
  • dmaengine_prep_xxx()
  • dmaengine_submit()
  • dma_async_issue_pending()
  • dmaengine_terminate_sync()
  • dma_release_channel()

Detailed API usage will be covered in the following days.

Linux Source Tour

Explored the overall source tree of the DMA subsystem.

Important locations include:

  • include/linux/dmaengine.h
  • drivers/dma/dmaengine.c
  • drivers/dma/

The goal was to understand where the framework, public APIs, and controller drivers are implemented before diving into kernel source analysis.

Summary

Day99 established the overall architecture of the Linux DMA Engine Framework.

Rather than focusing on implementation details, today's study built a complete mental model of how client drivers, the DMA Engine Framework, DMA controller drivers, and hardware cooperate to perform asynchronous data transfers.

This foundation will make it much easier to understand channel allocation, descriptors, transactions, cookies, callbacks, and controller implementations in the following chapters.

Next Plan

Continue with Day100 – DMA Controller & DMA Channel, including:

  • DMA Controller architecture
  • DMA Channel allocation
  • Device Tree (dmas / dma-names)
  • dma_request_chan() internals
  • Relationship between client drivers and DMA controller drivers