Re: [RFC]DMA API Update

Liu, Baohong

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

On Wed, 2017-01-18 at 23:15 +0000, Liu, Baohong wrote:
From: Jon Medhurst (Tixy) [mailto:tixy(a)]

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
Just to clarify.

The driver that implements DMA support (e.g. SPI driver) will need to determine
where it needs to get the parameters values for calling the DMA API. This is
beyond the scope of this RFC.

#defines (like we currently have for IRQ numbers) for setting these
DMA attributes (assuming they are fixed in hardware).
The DMA driver should have configuration entries for setting these
parameters and the values of these configurations should be determined
and set by an app level prj.conf, not by the SPI or DMA driver
So, when I add DMA support to my uart, everyone project that uses a UART,
or device attached through a UART, needs know the magic device specific
configuration required and add it their prj.conf?

E.g, to run the Zephyr UART tests I edit tests/drivers/uart/prj.conf to add the
DMA slot, handshaking polarity, etc., that are used for the UART + DMA
driver combination on the device I'm interested in?

Does prj.conf support #includes? That way we could at least provide an
include files per SoC for people to include to get all this config. Then again, if
we did that, why not just add the config direct to the SoC defconfig? Or even
better, just add it to SoC headers files like IRQ assignments and device
addresses? At least that way this SoC specific knowledge is more together in
one place. Currently it's spread between SoC and board files, and leaking into
device drivers, and now starting to push some of it into project files as well
seems like completely the wrong direction to take.


Join to automatically receive all group messages.