linux-mips-fnet
[Top] [All Lists]

Re: [patch] linux 2.4.17: The second mb() rework (final)

To: Jason Gunthorpe <jgg@debian.org>
Subject: Re: [patch] linux 2.4.17: The second mb() rework (final)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Fri, 15 Feb 2002 20:39:09 +0100 (MET)
Cc: "Kevin D. Kissell" <kevink@mips.com>, linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <Pine.LNX.3.96.1020215104857.10921A-100000@wakko.debian.net>
Organization: Technical University of Gdansk
On Fri, 15 Feb 2002, Jason Gunthorpe wrote:

> Sorry, why? If the TX39 is the only processor in the system then write
> buffers can be left alone. You can't consider PCI IO devices to be

 That depends on the implementation of the buffers.

> processors because the bus protocols would never allow you to satisfy the
> requirements for 'sync'.

 Fully agreed -- I've already expressed that in another mail.

> IMHO the only time *mb should care about a write buffer is if the buffer
> breaks PCI ordering semantics, by, say returning reads from posted write
> data, re-ordering, etc.

 Well, the "classic" MIPS R2020 and R3220 ones would break PCI (or
actually any I/O) ordering semantics as they return data from a posted
write upon a hit.  The affected read never appears at the I/O bus in that
case.  They never reorder writes though, as they work as FIFOs (the former
is four stage deep and the latter is six stage deep), so wmb() may be null
for them.

 I've read a suggestion a "bc0f" might be needed for the TX39's write
buffer as a barrier.  That means the buffer behaves as the "classic" ones. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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