linux-mips
[Top] [All Lists]

Re: wbflush() abuse for TOSHIBA_RBTX4927

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: wbflush() abuse for TOSHIBA_RBTX4927
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Thu, 17 Apr 2003 13:12:43 +0200 (MET DST)
Cc: kevink@mips.com, linux-mips@linux-mips.org, source@mvista.com
In-reply-to: <20030417.112704.74755522.nemoto@toshiba-tops.co.jp>
Organization: Technical University of Gdansk
Original-recipient: rfc822;linux-mips@linux-mips.org
Reply-to: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
On Thu, 17 Apr 2003, Atsushi Nemoto wrote:

> >> AFAIK TX49's SYNC instruction correctly flushes the write buffer.
> 
> macro>  That would be an overkill; we only need to enforce strong
> macro> ordering here.
> 
> Hmm... But SYNC is a only TX49 instruction that enforce completions of
> preceding read operations.  (TX49 have "non-blocking load" feature
> which allows non-cached read/write to overtake preceding cached read)

 Yes it is the correct instruction and it works, but if it really flushes
the write buffer, then it does too much and hits performance -- all that
it needs to do is to act as an ordering barrier and assure the write
buffer gets drained before any *subsequent* load or store, which might not
necessarily happen soon. 

> I can imagine three configurations:
> 
> 1. Enable CONFIG_CPU_HAS_SYNC and disable CONFIG_CPU_HAS_WB.  In this
>    case, wmb/rmb/mb/iob/wbflush macro all issues a SYNC instruction.
[...]
> Although I'm not sure whether TX49 core can be integrated with such an
> external write buffer, all TX49XX (not TX39) I have ever seen does not
> have it.

 Then case #1 should be just fine, but the code gets it differently.

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