From: Richard Henderson <rth@cygnus.com>
To: Jes Sorensen <Jes.Sorensen@cern.ch>
Cc: Paul.Mackerras@cs.anu.edu.au,
Geert.Uytterhoeven@cs.kuleuven.ac.be,
linuxppc-dev@lists.linuxppc.org, linux-fbdev@vuser.vu.union.edu,
Richard Henderson <rth@cygnus.com>
Subject: Re: [linux-fbdev] Re: readl() and friends and eieio on PPC
Date: Wed, 11 Aug 1999 00:38:05 -0700 [thread overview]
Message-ID: <19990811003805.A11890@cygnus.com> (raw)
In-Reply-To: <d34si6kcge.fsf@lxp03.cern.ch>; from Jes Sorensen on Wed, Aug 11, 1999 at 09:23:29AM +0200
On Wed, Aug 11, 1999 at 09:23:29AM +0200, Jes Sorensen wrote:
> Paul> On ultrasparc at least, there is a "side-effect" bit in each
> Paul> PTE. If that bit is set, it tells the cpu not to reorder
> Paul> accesses to that page. I don't know whether alpha has the same
> Paul> facility, do you?
No, it doesn't.
> I don't know enough about the PPC architecture to comment on this,
> however I can see that wmb() translates into an eieio. wmb() is more
> fine grained and it would make sense to promote it over plain mb() in
> the places where it makes sense.
Definitely. Alpha's wmb and mb are very similar to ppc's sync and eieio.
> Paul> Well, if alpha is actually like that, then IMO it is broken.
IMO it is Most Correct.
Memory barriers on alpha are a fact of life. It's not just I/O that
requires it, though that is where it shows up most often with drivers.
There are a great many cards that do memory mapped i/o that don't care
about the ordering and write combining of the data setup, only that the
data setup all be done before receiving the "go code". In these drivers,
we need only one wmb insn, not one between each and every writel.
This benefit is marked enough that there is zero chance you can convince
me to add wmb() to writel(). The driver writer is the only one that
knows whether this barrier is necessary.
r~
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
next prev parent reply other threads:[~1999-08-11 7:38 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-09 8:17 readl() and friends and eieio on PPC Geert Uytterhoeven
1999-08-09 17:19 ` David A. Gatwood
1999-08-10 1:00 ` Paul Mackerras
1999-08-10 7:18 ` [linux-fbdev] " Jes Sorensen
1999-08-11 0:23 ` Paul Mackerras
1999-08-11 7:23 ` Jes Sorensen
1999-08-11 7:38 ` Richard Henderson [this message]
1999-08-12 0:13 ` Paul Mackerras
1999-08-12 1:39 ` Peter Chang
1999-08-12 4:52 ` Paul Mackerras
1999-08-12 6:17 ` Peter Chang
1999-08-12 0:17 ` Paul Mackerras
1999-08-12 4:40 ` Richard Henderson
1999-08-12 5:00 ` Paul Mackerras
1999-08-12 5:43 ` Richard Henderson
1999-08-12 7:07 ` Paul Mackerras
1999-08-12 7:33 ` Richard Henderson
1999-08-12 9:58 ` Paul Mackerras
1999-08-12 12:31 ` Geert Uytterhoeven
1999-08-13 12:18 ` Paul Mackerras
1999-08-18 11:02 ` Gabriel Paubert
1999-08-13 18:33 ` Richard Henderson
1999-08-12 5:16 ` David Edelsohn
1999-08-12 5:27 ` Paul Mackerras
1999-08-12 5:52 ` Richard Henderson
1999-08-12 7:11 ` Paul Mackerras
1999-08-12 7:32 ` Jes Sorensen
1999-08-11 23:52 ` Paul Mackerras
1999-08-12 7:38 ` Jes Sorensen
1999-08-12 19:00 ` David A. Gatwood
1999-08-13 1:51 ` Paul Mackerras
[not found] <Pine.LNX.3.96.990813143741.27557B-100000@mvista.com>
[not found] ` <d3so5mdyta.fsf@lxp03.cern.ch>
1999-08-14 18:34 ` Geert Uytterhoeven
1999-08-14 18:36 ` David A. Gatwood
1999-08-14 19:48 ` Jes Sorensen
1999-08-15 1:28 ` David A. Gatwood
1999-08-14 21:39 ` Richard Henderson
1999-08-15 23:16 ` Paul Mackerras
1999-08-16 0:29 ` Richard Henderson
1999-08-16 7:11 ` Jes Sorensen
[not found] <m3672hkxri.fsf@soma.andreas.org>
1999-08-15 13:39 ` James Simmons
[not found] <d3pv0p72yr.fsf@lxp03.cern.ch>
1999-08-15 19:43 ` David A. Gatwood
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=19990811003805.A11890@cygnus.com \
--to=rth@cygnus.com \
--cc=Geert.Uytterhoeven@cs.kuleuven.ac.be \
--cc=Jes.Sorensen@cern.ch \
--cc=Paul.Mackerras@cs.anu.edu.au \
--cc=linux-fbdev@vuser.vu.union.edu \
--cc=linuxppc-dev@lists.linuxppc.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;
as well as URLs for NNTP newsgroup(s).