Hello Genodians
While implementing our driver for the i.MX8 CAAM device, I experience some problems with DMA using the following steps:
a) Allocate DMA memory using alloc_dma_buffer from the platform session. b) Fill the DMA memory with some data. c) Tell the hardware to work with the data by register write. d) Look at the result code provided by the hardware.
I observe an error result code from the hardware indicating the DMA read failed or returned the wrong data, unless I insert some time-consuming code (like a call to Genode::log or just a burning cycles) between b) and c).
I think the problem could be a data race between the CPU filling the RAM and the device reading it by DMA. On the other hand, I provide the UNCACHED argument to alloc_dma_buffer which should, if my understanding is correct, be reflected in the page table disabling the cache thus avoiding this problem.
What am I missing?
Kind regards Stefan
Gesendet: Freitag, 24. September 2021 um 11:06 Uhr Von: "Stefan Thöni" stefan.thoeni@gapfruit.com An: "users" users@lists.genode.org Betreff: DMA memory data race?
Hello Genodians
While implementing our driver for the i.MX8 CAAM device, I experience some problems with DMA using the following steps:
a) Allocate DMA memory using alloc_dma_buffer from the platform session. b) Fill the DMA memory with some data. c) Tell the hardware to work with the data by register write. d) Look at the result code provided by the hardware.
I observe an error result code from the hardware indicating the DMA read failed or returned the wrong data, unless I insert some time-consuming code (like a call to Genode::log or just a burning cycles) between b) and c).
I think the problem could be a data race between the CPU filling the RAM and the device reading it by DMA. On the other hand, I provide the UNCACHED argument to alloc_dma_buffer which should, if my understanding is correct, be reflected in the page table disabling the cache thus avoiding this problem.
What am I missing?
Youre missing this proverb: Never debug DMA problems on a linux kernel!
Kind regards Stefan _______________________________________________ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Stefan,
On Fri, Sep 24, 2021 at 11:06:27AM +0200, Stefan Thöni wrote:
Hello Genodians
While implementing our driver for the i.MX8 CAAM device, I experience some problems with DMA using the following steps:
a) Allocate DMA memory using alloc_dma_buffer from the platform session. b) Fill the DMA memory with some data. c) Tell the hardware to work with the data by register write. d) Look at the result code provided by the hardware.
I observe an error result code from the hardware indicating the DMA read failed or returned the wrong data, unless I insert some time-consuming code (like a call to Genode::log or just a burning cycles) between b) and c).
Did you inserted a data-memory barrier in between b and c? This is mandatory if you want all data-writes to succeed before signaling the hardware that the DMA buffer is ready.
I think the problem could be a data race between the CPU filling the RAM and the device reading it by DMA. On the other hand, I provide the UNCACHED argument to alloc_dma_buffer which should, if my understanding is correct, be reflected in the page table disabling the cache thus avoiding this problem.
You are right, as long as the DMA memory is allocated as uncached memory, you shouldn't observe caching issues. Otherwise, this would have been my first guess.
Regards Stefan
What am I missing?
Kind regards Stefan
pub ECDSA 512/D4E372A6 2021-03-03 Stefan Thöni stefan.thoeni@gapfruit.com
sub ECDH 512/04378363 2021-03-03
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-
Stefan Kalkowski -
Stefan Thöni -
Uwe