LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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