* dma_alloc_coherent / dma_map_single question
@ 2021-07-26 20:17 Brian Varney
0 siblings, 0 replies; only message in thread
From: Brian Varney @ 2021-07-26 20:17 UTC (permalink / raw)
To: dmaengine
Hello,
I have the following situation:
1. I'm using dma_alloc_coherent to allocate memory for DeviceA
2. I use DeviceA to fill the memory buffer.
Everything is fine so far but at this point I would like to DMA the
memory to DeviceB and I'm not sure the proper way of doing it.
Is it allowed/ok/proper to call dma_map_single for DeviceB using the
address returned from dma_alloc_coherent called on DeviceA? This
seems to work fine in x86_64 but it feels like I'm breaking the rules
because:
1. dma_map_single is supposed to be called with kmalloc addresses.
2. Since the address is from both dma_alloc_coherent and
dma_map_single, I don't know if the dma_sync_* functions are necessary
or not.
I'm worried that I'm just getting lucky having this work and a future
kernel update will break me since I'm not really following the rules.
My code may eventually have to run on ARM too, and I'm not sure it
would work.
I have also considered:
1. Call dma_alloc_coherent for DeviceB and memcpy the data from
DeviceA into it. This would work but I don't want the performance hit
of double buffering.
2. Get rid of the the dma_alloc_coherent for deviceA use
kmalloc/dma_map_single instead. This would work and maybe is the
right thing to do. This requires the extra hassle of dma_sync_*
functions which I was trying to avoid.
Is there a better way of doing this that I'm missing?
Thanks,
Brian V.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-07-26 20:17 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-26 20:17 dma_alloc_coherent / dma_map_single question Brian Varney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).