Re: [RFC]DMA API Update

Liu, Baohong

-----Original Message-----
From: Jon Medhurst (Tixy) [mailto:tixy(a)]
Sent: Monday, January 16, 2017 7:16 AM
To: Liu, Baohong <baohong.liu(a)>; devel(a)
Subject: Re: [devel] [RFC]DMA API Update

On Sat, 2017-01-14 at 00:31 +0000, Liu, Baohong wrote:
Thanks for the feedback. See my reply inline.
From: Jon Medhurst (Tixy) [mailto:tixy(a)]

But finally, the big elephant in the room is: how are DMA APIs
actually expected to used? And how should the system be configured?
The same way as other device drivers. There will be a driver to
implement the APIs for each SoC. App does the config, and initiate the
transfer by calling the APIs.
As far as I can see there is no documentation or examples in Zephyr that give
a clue as to how DMA can be used with device drivers. So it's very difficult to
review a DMA API without some more explanation on it's expected use.

Let me try some more specific questions...

Say I have a system which has:
A) a driver for a DMA Controller (it implement struct dma_driver_api)
B) a driver for some interface, e.g. SPI
C) an app which wants to talk to a device attached to that interface
e.g. and LCD controller
D) other things

Which of the above will call

- dma_channel_config
- dma_transfer_config
- dma_transfer_start
- dma_transfer_stop
I updated the RFC.
The sequence is dma_channel_config, dma_transfer_start, and then callback.
So simple!

dma_transfer_stop is to abort an existing transfer.


The SPI subsystem interface doesn't have anything DMA related in it, so I can
only assume that DMA use will have to be hidden inside the SPI driver, and
for each spi_transceive request made made of it will setup and operate on
an appropriate struct dma_transfer_config? (Or use scatter-gather lists when
API's get that ;-)

If so, every device driver in zephyr that anyone wants to use with DMA will
need to add DMA support to it and make it configurable to
(optionally) use the generic DMA API. Or is it expected that all APIs like SPI
grow new functions for use with DMA specifically?

That still leaves the question as to who calls dma_channel_config and how
the parameters for that get into the system. Is each driver that implements
DMA support going to have a bunch of KConfig entries to dma_slot,
hankshake_polarity etc? Or will the SoC have a bunch of #defines (like we
currently have for IRQ numbers) for setting these DMA attributes (assuming
they are fixed in hardware).

There's also the question as to how channel numbers are allocated. Is this
more per-driver KConfig options or should we have a DMA channel allocator
function so they can just be assigned at runtime?
What you said is the scenario of driver over driver. There are existing examples
In Zephyr.

I'm also thinking about the fact that there are likely to be more devices
capable of DMA than channels available so how about an API to free a
channel? E.g. dma_channel_config claims a channel for use and
dma_channel_free releases for someone else. That way even with static
allocation of channels we have the option of allocating the same channel to
two different devices if we know they can't be active at the same time.
dma_slot is the one to dynamically connect a dma channel to a device. But, the
responsibility to prevent conflict is on user.


Join to automatically receive all group messages.