Re: [RFC]DMA API Update


Jon Medhurst (Tixy) <tixy@...>
 

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

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).
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.

--
Tixy

Join devel@lists.zephyrproject.org to automatically receive all group messages.