[Top] [All Lists]

Re: RFH: What are the semantics of writeb() and friends?

To: "Maciej W. Rozycki" <>
Subject: Re: RFH: What are the semantics of writeb() and friends?
From: Alan Cox <>
Date: Fri, 01 Jul 2005 14:31:49 +0100
Cc: David Daney <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <1120218385.12446.16.camel@localhost.localdomain> <>
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
        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.
        this with care.

Note order - not synchronicity. On that it says

       While the basic functions are defined to be synchronous with
        to each other and ordered with respect to each other the busses
        devices sit on may themselves have asynchronicity. In particular
        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
        author cares. This kind of property cannot be hidden from driver
        writers in the API.  In some cases, the read used to flush the
        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.

        "In flight refueling scares me. It's like two elephants
                        mating at mach one"
                                -- Arjan van de Ven

<Prev in Thread] Current Thread [Next in Thread>