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 14:31:49 +0100 [thread overview]
Message-ID: <1120224708.12446.26.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.61L.0507011303190.30138@blysk.ds.pg.gda.pl>
On Gwe, 2005-07-01 at 13:54, Maciej W. Rozycki wrote:
> > writeb/writel may be merged in some cases (but not re-ordered) for I/O
>
> Is that non-reordering specified anywhere for the API or does it just
> happen to be satisfied by most implementations? Ours (for MIPS, that is)
> for example does nothing to ensure that.
It is defined by the device I/O document as follows:
The read and write functions are defined to be ordered. That is
the
compiler is not permitted to reorder the I/O sequence. When the
ordering can be compiler optimised, you can use <function>
__readb</function> and friends to indicate the relaxed ordering.
Use
this with care.
Note order - not synchronicity. On that it says
While the basic functions are defined to be synchronous with
respect
to each other and ordered with respect to each other the busses
the
devices sit on may themselves have asynchronicity. In particular
many
authors are burned by the fact that PCI bus writes are posted
asynchronously. A driver author must issue a read from the same
device to ensure that writes have occurred in the specific cases
the
author cares. This kind of property cannot be hidden from driver
writers in the API. In some cases, the read used to flush the
device
may be expected to fail (if the card is resetting, for
example). In
that case, the read should be done from config space, which is
guaranteed to soft-fail if the card doesn't respond.
> What if the host I/O bus is not PCI? For this kind of stuff I tend to
> think in the terms of TURBOchannel systems, just to be sure not to get
> influenced by the most common hardware. ;-)
The bus behaviour is bus defined.
> Again, the I/O bus your host is attached to need not be PCI and you may
> need a bridge specific operation to make your write be completed, possibly
> combined with your quoted sequence (if there is actually PCI somewhere in
> the system; think AlphaServer 8400).
We don't currently have cross bridge "io_write_and_be_synchronous()"
type functions. So far drivers have always known what to do. Your
example might break that of course.
Alan
--
"In flight refueling scares me. It's like two elephants
mating at mach one"
-- Arjan van de Ven
next prev parent reply other threads:[~2005-07-01 13:34 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
2005-07-01 12:54 ` Maciej W. Rozycki
2005-07-01 13:31 ` Alan Cox [this message]
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=1120224708.12446.26.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox