[Top] [All Lists]

Re: [patch 1/5] SiByte fixes for 2.6.12

To: "Maciej W. Rozycki" <>
Subject: Re: [patch 1/5] SiByte fixes for 2.6.12
From: Andy Isaacson <>
Date: Thu, 23 Jun 2005 16:26:33 -0700
Cc: Andrew Isaacson <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Mutt/1.4.2i
On Thu, Jun 23, 2005 at 12:01:57PM +0100, Maciej W. Rozycki wrote:
> On Wed, 22 Jun 2005, Andrew Isaacson wrote:
> > SB1 does not use the R4K TLB code.
>  Well, the flag is not really to specify whether the common code is to be 
> used or not.  It's about whether the TLB is like that of the R4k.  
> Actually it's always been a mystery for me why the common code cannot be 
> used for the SB1, but perhaps there is something specific that I could 
> only discover in that "SB-1 Core User Manual" that I yet have to see, 
> sigh...
>  Of course if your TLB is indeed different from that of the R4k, then you 
> shouldn't be setting to 1 in the first place...

So I don't know everything that went on during the SB1 MIPS port, but
what I see at this point makes at least some sense to me.  The SB1 has
some fancy features that are used in c-sb1.c and thereabouts (the DMA
pageops, and avoiding work by using the coherency guarantees, among

While it is worthwhile to abstract that code out some more (and I
consider it a long-term goal to share as much code as possible with the
generic r4k/mips32/mips64 code), it works as is and it's not obvious
what small simplifications should be taken at this point.  (Or at least,
I'm not smart enough to see what obvious small simplifications should be
done.)  So for the time being I'm in favor of doing what's needed to
keep the support from bit-rotting.  I'll keep an eye on whatever
cleanups you end up doing and keep them up to date with our internal

That said, I'm open to suggestions as to what I should do in the short
term to get the right results.


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