DMA memory data race?

[Stefan Kalkowski]

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 at gapfruit.com>
> sub  ECDH 512/04378363 2021-03-03
> 




> _______________________________________________
> Genode users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users


-- 
Stefan Kalkowski
Genode labs

https://github.com/skalk | https://genode.org