From: Scott Wood <scottwood@freescale.com>
To: Bruce_Leonard@selinc.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Async DMA question regarding dma_async_memcpy_buf_to_buf
Date: Mon, 24 Nov 2008 15:00:50 -0600 [thread overview]
Message-ID: <492B1602.7010102@freescale.com> (raw)
In-Reply-To: <OFD9E09DDF.B1C0E27A-ON8825750B.00700150-8825750B.00726C59@selinc.com>
Bruce_Leonard@selinc.com wrote:
> Hummm, let me try again, I may be tripping up on my ignorance of the
> kernel. According to Linux Device Drivers 3, the DMA_TO/FROM_DEVICE
> macros impact when the dma_map/unmap_single functions copy data and do
> cache flushes to ensure cache coherency. DMA_TO_DEVICE tells
> dma_map_single() to ensure that all data is copied out to memory and cache
> is flushed before doing the transfer and DMA_FROM_DEVICE tell
> dma_unmap_single() to ensure all data is in main memory after the
> transfer.
Right.
> (My understanding is that this is really only important on
> archs that use bounce buffers which I'm not).
It's also important on architectures where DMA is non-coherent (mpc83xx
DMA is coherent).
> So, no as far as "the device" (and I do mean the DMA engine) is concerned,
> the "mapping" of the src and dest pointers make zero difference, the
> hardware doesn't care since it's just acting on raw addresses. However,
> it does (or at least I think it does) matter to the kernel and making sure
> that the cache doesn't get screwed up.
Right.
> But it sounds like
> you're saying those macros are unimportant.
No, they're very important on certain hardware.
> Can dma_async_memcpy_buf_to_buf() _safely_ be used to DMA either direction
> (CPU <=> peripheral) _without_ cache coherency problems?
Any given memcpy operation involves *both* directions. Data is copied
out of host memory into the DMA engine's internal buffer (this is the
src mapping), and then it its copied back into host memory at a
different address (this is the dest mapping).
-Scott
next prev parent reply other threads:[~2008-11-24 21:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-24 18:55 Async DMA question regarding dma_async_memcpy_buf_to_buf Bruce_Leonard
2008-11-24 19:47 ` Scott Wood
2008-11-24 20:10 ` Bruce_Leonard
2008-11-24 20:16 ` Scott Wood
2008-11-24 20:49 ` Bruce_Leonard
2008-11-24 21:00 ` Scott Wood [this message]
2008-11-24 21:23 ` Bruce_Leonard
2008-11-24 21:28 ` Scott Wood
2008-11-24 21:35 ` Bruce_Leonard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=492B1602.7010102@freescale.com \
--to=scottwood@freescale.com \
--cc=Bruce_Leonard@selinc.com \
--cc=linuxppc-embedded@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox