DMA memory data race?

[Stefan Thöni]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x99A5F4B3D4E372A6.asc
Type: application/pgp-keys
Size: 1867 bytes
Desc: OpenPGP public key
URL: <http://lists.genode.org/pipermail/users/attachments/20210924/e1ef7f9d/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 313 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20210924/e1ef7f9d/attachment.sig>