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: 10+ 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
-- strict thread matches above, loose matches on Subject: below --
2008-11-22 1:00 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.