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

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

To: Hartvig Ekner <hartvige@mips.com>
Subject: Re: [patch] linux 2.4.17: The second mb() rework (final)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Mon, 18 Feb 2002 15:24:02 +0100 (MET)
Cc: Dominic Sweetman <dom@algor.co.uk>, "Kevin D. Kissell" <kevink@mips.com>, Atsushi Nemoto <nemoto@toshiba-tops.co.jp>, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <200202181252.NAA03169@copsun18.mips.com>
Organization: Technical University of Gdansk
On Mon, 18 Feb 2002, Hartvig Ekner wrote:

> You are no doubt correct regarding the R4K manual - so my comment probably
> only applies for CPU's that claim to be MIPS32/MIPS64 compliant. All MTI's
> CPU offerings (cores only) do in fact flush the WB on a SYNC to comply with
> the current spec.

 Note that the MIPS II spec doesn't forbid a "sync" implementation to be
stronger than required.

> This I do have a problem understanding. If the SYNC does not flush the WB
> on some processor/writebuffer combinations, and a read can be satisfied
> out of the WB, how would you ever be able to guarantee that DMA data written
> by the CPU has reached memory before triggering the IO device?

 If after a "sync" an uncached read could be satisfied from an
uncommittedd write pending since before the "sync" in a CPU's oncore WB,
then the CPU would violate the MIPS II spec of "sync", as the order of
transactions at this CPU's external bus would not be preserved.  You may
exploit this property to do a write-back flush to the host bus -- that's
what I added iob() for.

-- 
+  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>