Re: [RFC]DMA API Update


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

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)linaro.org]
[...]

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

?

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?

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.

--
Tixy

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