Why driver need to map DMA buffers when dma-engine is in device?


DMA buffers are memory mapped by the driver.
For example, in pci-skeleton.c, which uses rtl8319 we have:

  tp->tx_bufs = pci_alloc_consistent(tp->pci_dev, TX_BUF_TOT_LEN,

But DMA engine can reside in soc or in device.

**Is it that dma buffers should be allocated even if DMA engine is in device ? Why ? **

rtl8139cp datasheet (I think the dma is part of the device, but not sure about it):

I believe that “dma engine” and “dma controller” refer to the same thing. Please correct me if wrong.



To be clear, DMA (Direct Memory Access) is a method to transfer data to/from a peripheral from/to main memory. For convenience memory-to-memory DMA and peripheral-to-peripheral bus-mastering are ignored.

DMA is the opposite of programmed I/O (PIO), where the CPU performs the data transfer. For PIO, the CPU would wait for the peripheral to be ready by either polling the device’s status, or having the device generate an interrupt to signal the availability of the peripheral.

Polled PIO is CPU intensive, and PIO using interrupts is a huge improvement. But performing the transfer without any CPU involvement (other than the setup) is the meaning of DMA. The DMA transfer is performed by either the system’s DMA controller (aka third-party DMA) or a bus master associated with the peripheral (aka first-party DMA). The CPU’s involvement in a (simple, not chained) DMA transfer consists of setting up the transfer (e.g., assigning source and destination addresses, transfer count), and then acknowledging the end of the transfer.

DMA buffers are memory mapped by the driver.

Not sure what you mean by this.
Allocating or acquiring a DMA-able buffer does not typically require mapping.

In your question you insinuate that a PCI Ethernet controller that has integrated transmit and receive FIFOs and uses PCI bus mastering does not have to "map DMA buffers". The Ethernet controller is a peripheral of the system, and it has to get data from main memory to transmit, and the data it receives over Ethernet has to be eventually transferred to main memory so that the CPU can process it.
The integrated transmit and receive FIFOs are merely intermediate buffers that exist in between main memory and the rest of the peripheral.

But DMA engine can reside in soc or in device.

You’re sloppy with terminology.
A SoC is a System on (a) Chip. The typical SoC will certainly have a DMA controller, and it is the system’s DMA controller, i.e. for third-party DMA.
A device might have a DMA engine, especially if the bus it connects to supports bus mastering. The Ethernet controller you cite does support PCI bus mastering. This bus mastering is to access main memory (of the PCI host).

The fact that a peripheral might use bus mastering (instead of the system’s DMA controller) cannot negate the need to properly allocate a DMA-able buffer by the device driver. The bus master has the exact same purpose of the system’s DMA controller: to transfer data from/to the peripheral to/from main memory. The CPU can only process data that resides in main memory. The purpose of peripherals is to transfer that data to main memory for processing, and to transfer that data from main memory that has been processed.

Is it that dma buffers should be allocated even if DMA engine is in device ? Why ?

Since bus mastering is for enabling a peripheral to access main memory with minimal CPU intervention, that memory which is accessed has to be DMA-able. That is:

  • the memory has to be addressable by the bus master;
  • the memory has to be addressable by the CPU;
  • the memory has to be locked down, i.e. not swappable;
  • the memory has to be non-cacheable.

When a PCI device driver uses pci_alloc_consistent() to obtain a buffer for a data transfer, it is assured of DMA-able memory. This routine will return a virtual address for the CPU to reference this buffer, and a dma_handle for the bus master to reference this buffer.

Answered By – sawdust

This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply

(*) Required, Your email will not be published