From: Jesse Barnes <jbarnes@sgi.com>
To: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Cc: "José Fonseca" <j_r_fonseca@yahoo.co.uk>, linux-kernel@vger.kernel.org
Subject: Re: How to write portable MMIO code?
Date: Tue, 30 Apr 2002 13:01:36 -0700 [thread overview]
Message-ID: <20020430200136.GA1204879@sgi.com> (raw)
In-Reply-To: <20020430190110.GA20294@localhost> <Pine.LNX.4.44.0204301428480.32217-100000@chaos.physics.uiowa.edu>
On Tue, Apr 30, 2002 at 02:41:56PM -0500, Kai Germaschewski wrote:
> Well, my understanding is the following: (if I get something wrong,
> hopefully somebody who's reading this will correct me)
>
> the barrier(), {,r,w}mb() stuff is for actually for normal memory
> accesses.
>
> About barrier():
>
> If you have
>
> *p1 = 1; *p2 = 2;
>
> the compiler may decide to reorder this to (if it knows that p1 != p2)
>
> *p2 = 2; *p1 = 1;
>
> A barrier() in between will inhibit this reordering.
>
> For some archs, even the barrier() is not sufficient to serialize the
> accesses to RAM. The compiler may generate something like
>
> mov [p1], 1
> mov [p2], 2
>
> but on e.g. alpha (where the asm would look differently ;-), the processor
> may decide to put the second instruction on the memory bus before the
> first one. Only an mb in between will guarantee the ordering on the
> memory bus.
That's a good summary of the memory ordering issues one normally runs
into.
> Now, for IO, basically the same holds, though I wouldn't want to guarantee
> that the macros designed for the memory bus would work on the PCI bus as
> expected.
Right. In fact, waiting on I/O busses can take a bit longer than
making sure the processor executes memory transactions in the order
you'd like.
> However, I do *believe*, that the readl/writel functions implicitly do the
> right thing and introduce barriers where needed. On x86 e.g., the macros
> do a cast to (volatile *), which will ensure that these functions are
> compiled without reordering. As x86 is strongly ordered, no additional
> mb() or whatever is necessary (nor does it exist) to make sure that this
> ordering will propagate to the PCI bus.
Right, readl/writel will order things wrt the compiler and
processor, but not necessarily the I/O bus. On IA64, we've introduced
mmiob() to address this. It acts just like mb(), but wrt I/O address
space. The ia64 patch for 2.5 includes some documentation about it,
I'd love to see other arches implement something similar (even as a
simple nop) so that machines with weakly ordered I/O busses will work
as expected.
Jesse
next prev parent reply other threads:[~2002-04-30 20:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-30 14:22 How to write portable MMIO code? José Fonseca
2002-04-30 16:19 ` Kai Germaschewski
2002-04-30 19:01 ` José Fonseca
2002-04-30 19:41 ` Kai Germaschewski
2002-04-30 20:01 ` Jesse Barnes [this message]
2002-04-30 19:56 ` arjan
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=20020430200136.GA1204879@sgi.com \
--to=jbarnes@sgi.com \
--cc=j_r_fonseca@yahoo.co.uk \
--cc=kai@tp1.ruhr-uni-bochum.de \
--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 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.