Re: [RFC]DMA API Update


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

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

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.
Where? I can only assume you have in mind the things in
ext/hal/qmsi/drivers which is only occurrence of DMA in the Zephyr tree
I can find. Those drivers look hard coded for use on a single SoC and
have driver specific APIs for DMA, and nothing in-tree uses those APIs.

Also, there is no app in-tree that actually uses DMA apart from
test_loop_transfer which just does a simple memory-to-memory DMA test.

If the idea is that people should follow the Quark example, then it
looks to me that your saying DMA support in drivers is something
everyone has to design for themselves on a per-driver basis? If so,
there'll be no API consistency between drivers and every app will be
hard coded to a particular set of drivers.

But I can't believe that is what is intended, so I must have mis-
understood something fundamental.

--
Tixy

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