An Overview of The Dmaengine Subsystem: Free Electrons

Embedded Linux Conference 2015
An Overview of
the DMAEngine Free Electrons
Subsystem Embedded Linux

Developers
Maxime Ripard
Free Electrons
[email protected]
c Copyright 2004-2015, Free Electrons.

Creative Commons BY-SA 3.0 license.
Corrections, suggestions, contributions and translations are welcome!
Free Electrons. Kernel, drivers, embedded Linux and Android - Development, consulting, training and support. http://free-electrons.com 1/29
Maxime Ripard
I Embedded Linux engineer and trainer at Free Electrons

I Embedded Linux development: kernel and driver
development, system integration, boot time and power
consumption optimization, consulting, etc.
I Embedded Linux training, Linux driver development training
and Android system development training, with materials
freely available under a Creative Commons license.
I http://free-electrons.com
I Contributions
I Kernel support for the sunXi SoCs from Allwinner
I Contributor to few open-source projects, Buildroot, an
open-source, simple and fast embedded Linux build system,
Barebox, a modern bootloader.
I Living in Toulouse, south west of France
An Overview of the DMAEngine Subsystem
Introduction
Peripheral DMA vs...
... DMA Controllers
Transfer Width
Burst Size
Scatter Gather
Scatter Gather Descriptors
Cyclic Transfers
Realistic DMA Controller
Linux Support
APIs
I DMAEngine
I Merged in 2006, in 2.6.18
I Subsystem to handle memory-to-device transfers
I Async TX
I Merged in 2007, in 2.6.23
I Initially part of the raid5 code to support the XScale offload
engines
I Subsystem to handle memory to memory operations (memcpy,
XOR, etc.)
I Implemented on top of dmaengine, but takes many shortcuts,
instead of being a real client.
Slave consumer API
1. Request a channel: dma_request_channel, or one of its

variants
2. Configure the channel for our use: dmaengine_slave_config
3. Get a transaction descriptor for our transfer:
dmaengine_prep_*
4. Put the transaction in the driver pending queue:
dmaengine_submit
5. Issue pending requests (blocks and calls back your driver to
give an update on the transfer status):
dmaengine_issue_pending
Slave Controller Drivers
struct dma_device and its Fields
I DMAEngine, like any framework, relies on a structure you

have to fill with various pieces of information in order to do its
job properly
I Mostly:
channels Initialized list of the supported channels. The
size of the list is the number of channels
supported by your driver
* align Alignment in bytes for the Async TX buffers
DMA Transfer Types 1/2
I The next step is to set which transfer types your driver

supports
I This is done through the function dma_cap_set, which takes
various flags as an argument:
I DMA_MEMCPY
I Memory to memory copy
I DMA_SG
I Memory to memory scatter gather
I DMA_INTERLEAVE
I Memory to memory interleaved transfer
I DMA_XOR
I Memory to memory XOR
I DMA_XOR_VAL
I Memory buffer parity check using XOR
DMA Transfer Types 2/2
I DMA_PQ
I Memory to memory P+Q computation
I DMA_PQ_VAL
I Memory buffer parity check using P+Q
I DMA_INTERRUPT
I The device is able to generate a dummy transfer that will
generate interrupts
I DMA_SLAVE
I Memory to device transfers
I DMA_CYCLIC
I The device is able to handle cyclic transfers
Weird Transfer Types
I DMA_PRIVATE
I Async TX doesn’t go through dma_request_channel but
circumvents it, and just starts using any random channel it can
I It does so unless you set this flag
I DMA_ASYNC_TX
I Set by the core when you support all Async TX transfer types
I Used only if ASYNC_TX_ENABLE_CHANNEL_SWITCH is enabled
I Used by dma_find_channel, which is a non-exclusive
equivalent of dma_request_channel, used only by Async TX
Channels Resources Allocation
I device_alloc_chan_resources and
device_free_chan_resources
I Called by the framework when your channel is first requested
I Allows to allocate custom resources for your channel, and free
them when you’re done
I Optional (since 3.20)
Transaction Descriptor Retrieval Functions
I device_prep_dma_*
I Optional, but have to match the transfer types you declared
I Should create both the software descriptor, for Linux and
clients to identify the transfer, and the hardware descriptor
matching it for the dma controller
I Should also ensure that the parameters of this transfer match
what the driver supports
Submitting Pending Jobs
I device_issue_pending
I Should take the first descriptor of the transaction and start it
I Should go through all the descriptors in the list, notifying the
client using an optional callback that the transfer is done
Transfer Status Reporting
I device_tx_status
I Reports the current state of a given transaction descriptor
I Does so using the dma_set_residue function, and returns
only a flag saying whether it’s done or in progress
I This is where the granularity we used earlier comes into action.
Channel configuration
I device_control
I Takes an additional flag, that represents the action to perform
on the channel
I DMA_PAUSE
I Pauses a given channel
I DMA_RESUME
I Resumes a given channel
I DMA_TERMINATE_ALL
I Aborts all transfers on a given channel
I DMA_SLAVE_CONFIG
I Configures a given channel with new parameters
Capabilities
I device_slave_caps
I Returns various pieces of information about the controller
I Can the transfer be paused? terminated?
I Which transfer widths are supported?
I Which slave directions are supported?
I Used by generic layers to get an idea of what the device
they’re going to use is capable of (only ASoC so far)
Recent Developments
Generic Capabilities (4.0)
I Removed device_slave_caps, and moved the logic in the

framework itself
I Introduction of new variables in struct dma_device
* width Bitmask of supported transfer width, both as
source and destination
directions Bitmask of the supported slave directions
(memory to device, device to memory, device to
device)
granularity Granularity of the transfer residue your controller
can provide: bursts, chunks or descriptors
I Split of the device_control function in four independent
functions: device_config, device_pause, device_resume,
device_terminate_all
Scheduled DMA
I Many DMA controllers have more requests than channels

I These drivers usually have all the scheduling code
I Plus, every driver has a lot of administrative code, that is not
trivial to get right (callback deferral, allocation of the
descriptors, etc.), yet similar from one driver to another
I The Scheduled DMA framework abstracts away most of it,
and only a few things remain in the drivers:
I Interrupt management
I LLI related functions (iterators, configuration, etc.)
I Scheduling hints
I Channel management (pause, resume, residues, etc.)
Questions?
Maxime Ripard
[email protected]
Slides under CC-BY-SA 3.0

http://free-electrons.com/pub/conferences/2015/elc/ripard-dmaengine

An Overview of The Dmaengine Subsystem: Free Electrons

Uploaded by

Copyright:

Available Formats

An Overview of The Dmaengine Subsystem: Free Electrons

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Overview of The Dmaengine Subsystem: Free Electrons

Uploaded by

Copyright:

Available Formats

Embedded Linux Conference 2015

Subsystem Embedded Linux

c Copyright 2004-2015, Free Electrons.

I Embedded Linux engineer and trainer at Free Electrons

1. Request a channel: dma_request_channel, or one of its

Slave Controller Drivers

I DMAEngine, like any framework, relies on a structure you

I The next step is to set which transfer types your driver

I Removed device_slave_caps, and moved the logic in the

I Many DMA controllers have more requests than channels

Slides under CC-BY-SA 3.0

You might also like