wbflush() abuse for TOSHIBA_RBTX4927

wbflush() abuse for TOSHIBA_RBTX4927

[Maciej W. Rozycki]

Hello,

 I see wbflush() is abused in an interesting and inefficient way for
TOSHIBA_RBTX4927.  Is there any specific reason for such a setup?

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: wbflush() abuse for TOSHIBA_RBTX4927

[Kevin D. Kissell]

I remember that some of the Toshiba parts of the TX39 series
had some interesting quirks relating to the write buffer.  Perhaps
some of these were carried into the TX49 series as well?

----- Original Message ----- 
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: <linux-mips@linux-mips.org>
Cc: <source@mvista.com>
Sent: Tuesday, April 15, 2003 4:22 PM
Subject: wbflush() abuse for TOSHIBA_RBTX4927


> Hello,
> 
>  I see wbflush() is abused in an interesting and inefficient way for
> TOSHIBA_RBTX4927.  Is there any specific reason for such a setup?
> 
>   Maciej
> 
> -- 
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> 
> 
> 

Re: wbflush() abuse for TOSHIBA_RBTX4927

[Kevin D. Kissell]

I remember that some of the Toshiba parts of the TX39 series
had some interesting quirks relating to the write buffer.  Perhaps
some of these were carried into the TX49 series as well?

----- Original Message ----- 
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: <linux-mips@linux-mips.org>
Cc: <source@mvista.com>
Sent: Tuesday, April 15, 2003 4:22 PM
Subject: wbflush() abuse for TOSHIBA_RBTX4927


> Hello,
> 
>  I see wbflush() is abused in an interesting and inefficient way for
> TOSHIBA_RBTX4927.  Is there any specific reason for such a setup?
> 
>   Maciej
> 
> -- 
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> 
> 
> 

Re: wbflush() abuse for TOSHIBA_RBTX4927

[Maciej W. Rozycki]

On Tue, 15 Apr 2003, Kevin D. Kissell wrote:

> I remember that some of the Toshiba parts of the TX39 series
> had some interesting quirks relating to the write buffer.  Perhaps
> some of these were carried into the TX49 series as well?

 I suppose that's unrelated, since I'm specifically referring to the way
the buffer is handled in the TOSHIBA_RBTX4927 code -- the __wbflush()
backend is not invoked by wbflush() and calls like mb() (used by portable
drivers) unless the kernel is configured in an unobvious way and then
there is duplicate "sync" (but maybe that's needed, thus my question among
others). 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: wbflush() abuse for TOSHIBA_RBTX4927

[Atsushi Nemoto]

>>>>> On Tue, 15 Apr 2003 18:25:38 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:
>> I remember that some of the Toshiba parts of the TX39 series
>> had some interesting quirks relating to the write buffer.  Perhaps
>> some of these were carried into the TX49 series as well?

macro> I suppose that's unrelated, since I'm specifically referring to
macro> the way the buffer is handled in the TOSHIBA_RBTX4927 code --
macro> the __wbflush() backend is not invoked by wbflush() and calls
macro> like mb() (used by portable drivers) unless the kernel is
macro> configured in an unobvious way and then there is duplicate
macro> "sync" (but maybe that's needed, thus my question among
macro> others).

I suppose it's just because the code was written before
CONFIG_CPU_HAS_SYNC was introduced.

AFAIK TX49's SYNC instruction correctly flushes the write buffer.
No bc0f loop is required.

---
Atsushi Nemoto

Re: wbflush() abuse for TOSHIBA_RBTX4927

[Maciej W. Rozycki]

On Wed, 16 Apr 2003, Atsushi Nemoto wrote:

> macro> I suppose that's unrelated, since I'm specifically referring to
> macro> the way the buffer is handled in the TOSHIBA_RBTX4927 code --
> macro> the __wbflush() backend is not invoked by wbflush() and calls
> macro> like mb() (used by portable drivers) unless the kernel is
> macro> configured in an unobvious way and then there is duplicate
> macro> "sync" (but maybe that's needed, thus my question among
> macro> others).
> 
> I suppose it's just because the code was written before
> CONFIG_CPU_HAS_SYNC was introduced.

 It doesn't look so -- it appeared in the tree only a few days ago and
CONFIG_CPU_HAS_SYNC is there for almost a year now.  Even if maintained
privately since before CONFIG_CPU_HAS_SYNC, there was a lot of time to get
it fixed before merging.

> AFAIK TX49's SYNC instruction correctly flushes the write buffer.

 That would be an overkill; we only need to enforce strong ordering here.

> No bc0f loop is required.

 But an external buffer may be attached to a TX49 core, IIRC, so if it is
the case for TOSHIBA_RBTX4927, it's obviously needed.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: wbflush() abuse for TOSHIBA_RBTX4927

[Atsushi Nemoto]

>>>>> On Wed, 16 Apr 2003 15:46:54 +0200 (MET DST), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:
>> 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)

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.

2. Disable CONFIG_CPU_HAS_SYNC and enable CONFIG_CPU_HAS_WB, In this
   case, wmb/rmb macro does nothing and mb/iob/wbflush macro calls
   __wbflush().

3. Enable both CONFIG_CPU_HAS_SYNC and CONFIG_CPU_HAS_WB, In this
   case, wmb/rmb macro issues a SYNC instruction, mb/iob macro calls
   __wbflush() and wbflush macro do both.

In the case 2 and 3, __wbflush() must be implemented with SYNC instruction
and/or bc0f loop.

I think the case 1 is good and enough for TX49.

>> No bc0f loop is required.

macro>  But an external buffer may be attached to a TX49 core, IIRC,
macro> so if it is the case for TOSHIBA_RBTX4927, it's obviously
macro> needed.

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.

---
Atsushi Nemoto

Re: wbflush() abuse for TOSHIBA_RBTX4927

[Maciej W. Rozycki]

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        +