Re: [RFC]DMA API Update

Liu, Baohong

From: Jon Medhurst (Tixy) [mailto:tixy(a)]
Sent: Wednesday, January 18, 2017 3:31 AM
Subject: Re: [devel] [RFC]DMA API Update

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

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.
Just to clarify my previous answer which is meant to say that there are existing
usage cases a driver use API from another driver. (e.g some sensor drivers uses
I2C driver API)

For the channel assignment, I think this should be decided and set by an app level
Prj.conf, not by driver Kconfig.

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.
The DMA API is designed to solve that; ideally app or drivers should all use the DMA
API to implement DMA support


Join to automatically receive all group messages.