All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: David Daney <ddaney@avtrex.com>, linux-mips@linux-mips.org
Subject: Re: RFH:  What are the semantics of writeb() and friends?
Date: Fri, 01 Jul 2005 12:46:28 +0100	[thread overview]
Message-ID: <1120218385.12446.16.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.61L.0507011002520.30138@blysk.ds.pg.gda.pl>

On Gwe, 2005-07-01 at 10:33, Maciej W. Rozycki wrote:
> > al.?  I would assume that the effects of these must be in the same order 
> > that they were issued, and that any hardware write back queue cannot 
> > combine or merge them in any way.  Is that correct?
> 
>  No it's not.  You need to insert appropriate barriers, one of: wmb(), 
> mb() or rmb().  In rare cases you may need to use iob(), which is 
> currently non-portable (which reminds me I should really push it 
> upstream).

Its even more complicated than that 8)

writeb/writel may be merged in some cases (but not re-ordered) for I/O
devices but a simple mb() will only synchronize them as viewed from
cpu/memory interface. There are two other synchronization points. From
the bridge with the I/O device (typically the PCI root bridge) which is
not enforced automatically across processors on some large numa boxes
but is not usually a problem and on the PCI bus itself.

PCI permits posting (delaying writes) and some forms of merging (but not
re-ordering). Thus if you need an I/O to hit a device on the PCI bus and
know it arrived you must follow it by a read from the same device. So
for example if you want to shut down a DMA transfer and free the buffer
for a PCI device you
need to do

		writel(TURN_DMA_OFF, dev->control);
		readl(dev->something);
		/* Only now is the free safe */

Alan

  reply	other threads:[~2005-07-01 11:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-01  5:22 RFH: What are the semantics of writeb() and friends? David Daney
2005-07-01  5:22 ` David Daney
2005-07-01  9:33 ` Maciej W. Rozycki
2005-07-01 11:46   ` Alan Cox [this message]
2005-07-01 12:54     ` Maciej W. Rozycki
2005-07-01 13:31       ` Alan Cox
2005-07-01 14:43         ` Maciej W. Rozycki
2005-07-01 19:53           ` Alan Cox
2005-07-04 13:08             ` Maciej W. Rozycki

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=1120218385.12446.16.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=ddaney@avtrex.com \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.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.