From: Mark Salter <msalter@redhat.com>
To: "Michał Mirosław" <mirqus@gmail.com>
Cc: linux-kernel@vger.kernel.org, ming.lei@canonical.com,
stern@rowland.harvard.edu, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] add dma_coherent_write_sync to DMA API
Date: Thu, 01 Sep 2011 08:36:34 -0400 [thread overview]
Message-ID: <1314880595.1439.13.camel@deneb.redhat.com> (raw)
In-Reply-To: <CAHXqBFJ6tEkn+iW3ZBAiWu5Sx9y9MQdnJt5Gfnv5Xc3UB78uLw@mail.gmail.com>
On Thu, 2011-09-01 at 11:57 +0200, Michał Mirosław wrote:
> BTW, if there's no time limit on write buffers flushing, or if write
> buffers can cause reordering of the writes, then the memory accesses
> need to be managed just like non-DMA-coherent memory. So what differs
> then in DMA-coherent vs non-DMA-coherent mappings then?
My understanding is that ordering is preserved, but an ARM guy should
probably verify that.
IIUC, the write buffers could hold data indefinitely. As a practical
matter other writes needing to go out to memory will force buffered
data out eventually. Again, this is my understanding which may be
faulty. My feeling is that this extended write buffering makes it
hard to call the dma memory fully coherent, but other limitations on
ARMv7 make the buffering hard to avoid.
--Mark
WARNING: multiple messages have this Message-ID (diff)
From: msalter@redhat.com (Mark Salter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] add dma_coherent_write_sync to DMA API
Date: Thu, 01 Sep 2011 08:36:34 -0400 [thread overview]
Message-ID: <1314880595.1439.13.camel@deneb.redhat.com> (raw)
In-Reply-To: <CAHXqBFJ6tEkn+iW3ZBAiWu5Sx9y9MQdnJt5Gfnv5Xc3UB78uLw@mail.gmail.com>
On Thu, 2011-09-01 at 11:57 +0200, Micha? Miros?aw wrote:
> BTW, if there's no time limit on write buffers flushing, or if write
> buffers can cause reordering of the writes, then the memory accesses
> need to be managed just like non-DMA-coherent memory. So what differs
> then in DMA-coherent vs non-DMA-coherent mappings then?
My understanding is that ordering is preserved, but an ARM guy should
probably verify that.
IIUC, the write buffers could hold data indefinitely. As a practical
matter other writes needing to go out to memory will force buffered
data out eventually. Again, this is my understanding which may be
faulty. My feeling is that this extended write buffering makes it
hard to call the dma memory fully coherent, but other limitations on
ARMv7 make the buffering hard to avoid.
--Mark
next prev parent reply other threads:[~2011-09-01 12:36 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-31 21:30 [PATCH 0/3] RFC: addition to DMA API Mark Salter
2011-08-31 21:30 ` Mark Salter
2011-08-31 21:30 ` [PATCH 1/3] add dma_coherent_write_sync " Mark Salter
2011-08-31 21:30 ` Mark Salter
2011-09-01 2:59 ` Josh Cartwright
2011-09-01 2:59 ` Josh Cartwright
2011-09-01 9:57 ` Michał Mirosław
2011-09-01 9:57 ` Michał Mirosław
2011-09-01 12:36 ` Mark Salter [this message]
2011-09-01 12:36 ` Mark Salter
2011-09-06 14:30 ` Catalin Marinas
2011-09-06 14:30 ` Catalin Marinas
2011-08-31 21:30 ` [PATCH 2/3] define ARM-specific dma_coherent_write_sync Mark Salter
2011-08-31 21:30 ` Mark Salter
2011-09-06 14:32 ` Catalin Marinas
2011-09-06 14:32 ` Catalin Marinas
2011-09-06 14:37 ` Mark Salter
2011-09-06 14:37 ` Mark Salter
2011-09-06 14:48 ` Catalin Marinas
2011-09-06 14:48 ` Catalin Marinas
2011-09-06 15:02 ` Mark Salter
2011-09-06 15:02 ` Mark Salter
2011-10-03 1:40 ` Jon Masters
2011-10-03 1:40 ` Jon Masters
2011-10-03 8:44 ` Catalin Marinas
2011-10-03 8:44 ` Catalin Marinas
2011-10-03 9:24 ` Jon Masters
2011-10-03 9:24 ` Jon Masters
2011-08-31 21:30 ` [PATCH 3/3] add dma_coherent_write_sync calls to USB EHCI driver Mark Salter
2011-08-31 21:30 ` Mark Salter
2011-09-01 2:33 ` Ming Lei
2011-09-01 2:33 ` Ming Lei
2011-09-01 2:09 ` [PATCH 0/3] RFC: addition to DMA API Ming Lei
2011-09-01 2:09 ` Ming Lei
2011-09-01 3:09 ` Alan Stern
2011-09-01 3:09 ` Alan Stern
2011-09-01 3:41 ` Ming Lei
2011-09-01 3:41 ` Ming Lei
2011-09-01 8:45 ` Will Deacon
2011-09-01 8:45 ` Will Deacon
2011-09-01 9:14 ` Ming Lei
2011-09-01 9:14 ` Ming Lei
2011-09-01 15:42 ` Alan Stern
2011-09-01 15:42 ` Alan Stern
2011-09-01 16:04 ` Russell King - ARM Linux
2011-09-01 16:04 ` Russell King - ARM Linux
2011-09-01 17:31 ` Will Deacon
2011-09-01 17:31 ` Will Deacon
2011-09-01 18:07 ` Russell King - ARM Linux
2011-09-01 18:07 ` Russell King - ARM Linux
2011-09-01 19:14 ` Mark Salter
2011-09-01 19:14 ` Mark Salter
2011-09-01 15:22 ` Alan Stern
2011-09-01 15:22 ` Alan Stern
2011-09-01 15:56 ` Ming Lei
2011-09-01 15:56 ` Ming Lei
2011-09-01 16:48 ` Alan Stern
2011-09-01 16:48 ` Alan Stern
2011-09-02 0:59 ` Ming Lei
2011-09-02 0:59 ` Ming Lei
2011-09-02 13:53 ` Alan Stern
2011-09-02 13:53 ` Alan Stern
2011-09-01 9:11 ` Will Deacon
2011-09-01 9:11 ` Will Deacon
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=1314880595.1439.13.camel@deneb.redhat.com \
--to=msalter@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=mirqus@gmail.com \
--cc=stern@rowland.harvard.edu \
/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.