DMA driver API, source_burst_length, dest_burst_length


Johann Fischer
 

Hi,

The DMA API describes the source_burst_length and dest_burst_length of the struct dma_config as:

...
* source_burst_length [ 0 : 15 ] - number of source data units
* dest_burst_length [ 16 : 31 ] - number of destination data units
...

What are the data units? octets?

From the test code, it is also not clear:

tests/drivers/dma/test_loop_transfer/src/dma.c:

initializes dma_cfg.dest_burst_length = 1;


tests/drivers/dma/test_chan_blen_transfer/src/test_dma.c

initializes dma_cfg.dest_burst_length = blen; /* blen = (8 | 16) */

--
Best Regards,
Johann Fischer


Liu, Baohong
 

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-
bounces@...] On Behalf Of Johann Fischer
Sent: Thursday, June 8, 2017 6:40 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] DMA driver API, source_burst_length, dest_burst_length

Hi,

The DMA API describes the source_burst_length and dest_burst_length of the
struct dma_config as:

...
* source_burst_length [ 0 : 15 ] - number of source data units
* dest_burst_length [ 16 : 31 ] - number of destination data units
...

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

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.


From the test code, it is also not clear:

tests/drivers/dma/test_loop_transfer/src/dma.c:

initializes dma_cfg.dest_burst_length = 1;


tests/drivers/dma/test_chan_blen_transfer/src/test_dma.c

initializes dma_cfg.dest_burst_length = blen; /* blen = (8 | 16) */

--
Best Regards,
Johann Fischer
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Johann Fischer
 

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.


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.

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

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

--
Best Regards,
Johann Fischer


Liu, Baohong
 

-----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