public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox