[Top] [All Lists]

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

To: Atsushi Nemoto <>
Subject: Re: [patch] linux 2.4.17: The second mb() rework (final)
From: "Maciej W. Rozycki" <>
Date: Thu, 21 Feb 2002 15:12:43 +0100 (MET)
In-reply-to: <>
Organization: Technical University of Gdansk
Reply-to: "Maciej W. Rozycki" <>
On Thu, 21 Feb 2002, Atsushi Nemoto wrote:

> TX39 satisfy this on uncached load/store.  "sync" does not flush a
> write buffer, but any uncached load are executed AFTER completion of
> pending uncached store.  On combination of cached and uncached
> operation, TX39 does not satisfy this order.

 With respect to cache refills (what is already cached is irrelevant,
obviously, as read accesse to it don't appear externally), "32-bit RISC
Microprocessor TX39 Family Core Architecture User's Manual" seems to
contradict.  In the description of the "sync" instruction it states: 

"Interlocks the pipeline until the load, store or data cache refill
operation of the previous instruction is completed.  The R3900 Processor
Core can continue processing instructions following a load instruction
even if a cache refill is caused by the load instruction or a load is made
from a noncacheable area.  Executing a SYNC instruction interlocks
subsequent instructions until the SYNC instruction execution is completed.
This ensures that the instructions following a load instruction are
executed in the proper sequence."

It's clear "sync" is strong on the TX39, stronger then required by MIPS

> TX39 has a function called "non-blocking load".  This function is
> described on chapter 4.4 of TX39/H2 manual.  "sync" operation is
> meaningful with this function.

 Chapter 4.3 ("") of the quoted manual.  The statement I quoted assures
indeed (modulo errata, which hopefully don't exist here). 

> Chapter 4.9.4 in TX39/H2 Japanese manual describes write buffer.  But
> I could not find it in the English manual...

 The write buffer is described in the part about "TMPR3901F" (it appears
two manuals are concatenated in a single file), chapter 2.3 ("Bus
Interface Unit (Bus Controller / Write Buffer)").  It looks like a "bc0f" 
loop is needed for mb().  The only difference comparing to R2020/R3220 is
only a single "nop" is needed after a write for the coprocessor status to
become valid, it would seem.  It's not documented explicitly but the
supplied example code suggests so. 

 The document I'm referring to is available at: 

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

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