Re: [RFC]DMA API Update


Huaqi Fang
 

Hi Baohong,

First thanks for proposal about DMA API update.
I want to post some of our use cases and requirements around DMA API, since I am working on Designware ARC Core support in Synopsys, our hardware platform EMSK is already supported in zephyr, and in EMSK 2.2 version, there is a uDMA component in it.
For uDMA component description: https://www.synopsys.com/dw/ipdir.php?ds=arc-system-integration-options
1. As other developers said, for DMA transfers, there are different types of transfer, single list transfer, linked list transfer. But it seems in this API proposal, there is no consideration.
2. In ARC core, it has many aux registers, and the DMA support not just memory to memory, or memory to peripheral, it also support memory to aux interface. Maybe some other DMA component also support different interfaces.
3. For DMA transfer, each burst transfer can be auto-requested or manual requested by peripheral interface signal.

Currently we have uDMA driver for ARC in embARC project: https://www.embarc.org/, if you want to take a look at it, you can register an account and download it.

I post our use cases and requirements here, so hopes that the DMA API can take these into consideration.

Thanks
Huaqi

-----Original Message-----
From: Nallasellan, Singaravelan [mailto:singaravelan.nallasellan(a)intel.com]
Sent: 2017年1月13日 13:40
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC]DMA API Update

It is required to add slave or controller id which is 32 bits. Some DMA controllers require to program mux to connect the hardware handshake signals to the selected peripheral with the channel.

-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Thursday, January 12, 2017 1:20 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC]DMA API Update


Hi everyone,

I would like to propose the update for DMA API.
(https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.zephyrproject.org_browse_ZEP-2D873&d=DgIFAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=KI3IYdedpLSnsCSZ0k3Gcp6fYWESKi3RE-hGv_ZefTg&m=apJcm5GKxXOZ-B-8xed5zGD7lHnTwvAlcy0LrqN83L0&s=4lO6HbTvx4_-SnlOC8xe3edTD8vU2Ych1Arh29j2ATQ&e= ).

Known Problems
--------

Struct dma_channel_config consists of quite a few variables of enum
types, two callback function pointers, and one callback user data pointer.

- The enums can be collapsed into a bit field.
This will reduce the size of the data structure.

- The two callback function pointers (for normal and error cases) can
be combined.
A parameter of error code can be used to differentiate the two
cases. So, the
current callback parameter of user data pointer will be replaced by
two new
parameters. One for error code and the other one for channel id.

- Callback data pointer can be removed.
Currently, this field holds user data. It can be moved to driver
data structure.
The callback function can dig out the information from dev pointer and
channel id passed to it.

Proposed Solution
--------

-- The following are the enums we have now.

handshake_interface /* which peripheral and direction*/
hankshake_polarity /* high or low*/
channel_direction /* memory to memory, memory to peripheral ... */
Source_transfer_width /* source data size */
Destination_transfer_width /* destination data size */
Source_burst_length /* source burst length */
Destination_burst_length /* destination burst length */

All these will be collapsed into a bit field. Some of them will have new names.

Besides the above, three new items will be added.
source_handshake /* HW or SW */
dest_handshake /* HW or SW */
channel_priority /* DMA channel priority */

-- For the callback function, there will be three parameters. They are
device pointer,
channel_id, and error code. As said above, the error callback
will be removed.

-- The callback_data pointer will be removed.

Final API Format
--------

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory
* source_data_size [ 10 : 12 ] --source data size(8,16,32,64,128
and 256 bits)
* dest_data_size [ 13 : 15 ] --destination data
size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 16 : 18 ] --number of source data
unit(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 19 : 21 ] -- number of dest data
unit(1,4,8,16,32,64,128 and 256)
* source_handshake [ 22 ] --HW or SW
* dest_handshake [ 23 ] --HW or SW
* channel_priority [ 24 : 27 ] --DMA channel priority
* RESERVED [ 28 : 31 ]
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
void (*dma_callback)(struct device *dev, uint32_t channel, int
error_code); }

The remaining parts will stay the same.
No change to the structure dma_transfer_config.
No change to the API function prototypes:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

(Note: for xx_data_size and xx_burst_length in the above bit field,
the value will only serve as an index. For example, for
source_data_size, bit field values of 0, 1, 2, 3, 4 and 5 will
correspond to sizes of 8,16,32,64,128 and 256 bits.)

Suggestions and comments are welcome.

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