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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux