From: Robert Hancock <hancockrwd@gmail.com>
To: Leon Woestenberg <leon.woestenberg@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Memory-mapped I/O barriers, state of affairs?
Date: Mon, 22 Mar 2010 18:14:15 -0600 [thread overview]
Message-ID: <4BA807D7.7080007@gmail.com> (raw)
In-Reply-To: <c384c5ea1003221512s229d1d94ta7690d109b75843a@mail.gmail.com>
On 03/22/2010 04:12 PM, Leon Woestenberg wrote:
> Hello Andreas, all,
>
> On Mon, Mar 22, 2010 at 9:16 PM, Andreas Bombe<aeb@debian.org> wrote:
>> On Mon, Mar 22, 2010 at 08:18:49PM +0100, Leon Woestenberg wrote:
>>> What is the current solution for that particular problem, i.e. how
>>> should I make sure host memory writes are committed before I have an
>>> external DMA device act on it?
>>
>> The dma_sync_* functions, if you reuse DMA buffers without unmapping,
>> take care of that. Otherwise the process of mapping them handles it.
>>
> The mapping makes the memory cache-coherent. I already use that.
>
> But does that mean that this coherency is guaranteed to occur before I
> start MMIO access to a device, i.e. is there a guaranteed ordering
> between the writes?
Well, for a streaming mapping, the device may not see the write to the
memory at all until it's synced or unmapped (for one thing, if the
kernel is using swiotlb to map the memory, it's an entirely different
piece of memory and it needs to copy the data to where the device can
actually see it).
For a coherent mapping, however, though I can't say for certain what the
behavior is "supposed" to be, many drivers seem to depend on writes to
these regions being ordered with respect to regular memory and would
break if a particular platform didn't obey that.
prev parent reply other threads:[~2010-03-23 0:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-22 19:18 Memory-mapped I/O barriers, state of affairs? Leon Woestenberg
2010-03-22 20:16 ` Andreas Bombe
2010-03-22 22:12 ` Leon Woestenberg
2010-03-23 0:14 ` Robert Hancock [this message]
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=4BA807D7.7080007@gmail.com \
--to=hancockrwd@gmail.com \
--cc=leon.woestenberg@gmail.com \
--cc=linux-kernel@vger.kernel.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