-----Original Message-----
From: Johann Fischer [mailto:johann_fischer@...]
Sent: Friday, June 9, 2017 5:13 AM
To: Liu, Baohong <baohong.liu@...>; zephyr-
devel@...
Subject: Re: [Zephyr-devel] DMA driver API, source_burst_length,
dest_burst_length

Hi Baohong,

What are the data units? octets?

This is HW related. It can't specified here in the generic API.

Burst length should be used together with transfer width. Let me give an

example.

For a single DMA data transfer, the source can only send data out at 2
bytes each transfer and the destination can only accept data at one
byte each transfer (this is HW related.). The DMA engine will get 2
bytes from the source and sends the data to the destination one byte
each time (do this twice). For this case, the DMA burst length will be
2 bytes long, since this is the minimum data unit the source side can
deal with. So, source_burst_length = 1 source_transfer_width = 2
dest_burst_length = 2 dest_transfer_width = 1

thanks for the clarification. I suppose:
source_transfer_width should be source_data_size ?
dest_transfer_width should be dest_data_size ?

It is a little redundant, what is the reason for two burst length variables? You can
also pass the number of bytes per request and then calculate the burst length in
the driver, if necessary.

Make sense.

Note: 1 or 2 in the above is absolute value. Since in the API, the enum starts

from 0, 1 or 2 should be changed to 0 or 1.

Do you mean "enum dma_burst_length"? No driver seems to use it.

If a dma driver implementation follows the generic dma API, it should use this enum.

I would be glad if you would find time to review PR[1] and the fix for
test_chan_blen_transfer (15757e1).

I do not work on Zephyr any more. If time allows, I will be happy to review it.

[1] https://github.com/zephyrproject-rtos/zephyr/pull/393

--
Best Regards,
Johann Fischer