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

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

To: macro@ds2.pg.gda.pl
Subject: Re: [patch] linux 2.4.17: The second mb() rework (final)
From: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Date: Thu, 21 Feb 2002 21:00:52 +0900 (JST)
Cc: jgg@debian.org, kevink@mips.com, linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <Pine.GSO.3.96.1020215203113.29773Q-100000@delta.ds2.pg.gda.pl>
Organization: TOSHIBA Personal Computer System Corporation
References: <Pine.LNX.3.96.1020215104857.10921A-100000@wakko.debian.net> <Pine.GSO.3.96.1020215203113.29773Q-100000@delta.ds2.pg.gda.pl>
>>>>> On Fri, 15 Feb 2002 20:39:09 +0100 (MET), "Maciej W. Rozycki" 
>>>>> <macro@ds2.pg.gda.pl> said:
macro>  Well, the "classic" MIPS R2020 and R3220 ones would break PCI
macro> (or actually any I/O) ordering semantics as they return data
macro> from a posted write upon a hit.  The affected read never
macro> appears at the I/O bus in that case.  They never reorder writes
macro> though, as they work as FIFOs (the former is four stage deep
macro> and the latter is six stage deep), so wmb() may be null for
macro> them.

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

As I wrote in another mail, TX39's uncached load does NOT return data
from a write buffer.  Uncached load/store always appears on I/O bus in
same order.

The problem of TX39's write buffer is that cached load/store operation
can overtake preceding uncached store operation (even if "SYNC" was
exist between these operations).

---
Atsushi Nemoto

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