linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Sven Luther <sven.luther@wanadoo.fr>,
	Alan Cox <alan@www.pagan.org.uk>, Nicolas DET <nd@bplan-gmbh.de>,
	Linux-USB <linux-usb-devel@lists.sourceforge.net>,
	linuxppc-dev list <linuxppc-dev@lists.linuxppc.org>
Subject: Re: [linux-usb-devel] [Patch] for UHCI driver (from kernel 2.6.6).
Date: Fri, 18 Jun 2004 16:43:49 -0500	[thread overview]
Message-ID: <1087595028.2061.295.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0406181737520.1334-100000@ida.rowland.org>


On Fri, 2004-06-18 at 16:41, Alan Stern wrote:
> On Fri, 18 Jun 2004, Benjamin Herrenschmidt wrote:
>
> > I think it's more likely we are dealing with an ordering issue of
> > accesses to memory vs. mmio, those aren't order unless you use memory
> > barriers. Actually, it's worse, you need a full mb() to order them,
> > which is why lately, we made ppc64 writeX() do full sync's ... that sucks
> > but it's near to impossible to get an abstract IO API that would cover
> > our needs here and still make other archs happy it seems...
>
> I recently changed a few mb() calls to wmb(), because they only protected
> data the CPU was writing to be read by the device.  Do you think changing
> all the wmb()'s back to mb()'s would make a difference?
>
> (Actually it seems likely that this is _not_ directly related to the
> original problem, but it might be important anyway.)

Well, the problem on ppc is that the eieio done by wmb() (or implicitely
done by all writeX IO accessors) will only order stores in the same
domain. That is cacheable aren't ordered vs. non cacheables.

For example, write to a descriptor in memory, then writel() to your
device, that isn't guaranteed to happen in order.

In this case, you indeed need an mb(), but that's a ppc thing and the
race on ppc32 CPUs is quite small (though ppc64, typically POWER4 and
POWER5, will eat you for lunch with their multiple deep store queues).

Ben


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2004-06-18 21:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <40CDC05B.9020708@bplan-gmbh.de>
     [not found] ` <1087241757.5996.3.camel@localhost.localdomain>
     [not found]   ` <20040617173454.GA5971@pegasos>
2004-06-18 10:20     ` [linux-usb-devel] [Patch] for UHCI driver (from kernel 2.6.6) Sven Luther
2004-06-18 21:31       ` Benjamin Herrenschmidt
2004-06-18 21:41         ` Alan Stern
2004-06-18 21:43           ` Benjamin Herrenschmidt [this message]
2004-06-19 13:59             ` Alan Stern
2004-06-19 14:16               ` Sven Luther
2004-06-21  8:18                 ` Segher Boessenkool
2004-06-21  8:57                   ` Sven Luther
2004-06-19  6:53           ` Oliver Neukum

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=1087595028.2061.295.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=alan@www.pagan.org.uk \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=nd@bplan-gmbh.de \
    --cc=stern@rowland.harvard.edu \
    --cc=sven.luther@wanadoo.fr \
    /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).