[PATCH] MIPS: Add support for the MIPS32 4Kc family I/D caches.

[PATCH] MIPS: Add support for the MIPS32 4Kc family I/D caches.

[Steven J. Hill]

From: "Steven J. Hill" <sjhill@mips.com>

Signed-off-by: Douglas Leung <douglas@mips.com>
Signed-off-by: Steven J. Hill <sjhill@mips.com>
---
 arch/mips/mm/c-r4k.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 18546fa..bca1447 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1000,7 +1000,7 @@ static void __cpuinit probe_pcache(void)
 			c->icache.linesz = 2 << lsize;
 		else
 			c->icache.linesz = lsize;
-		c->icache.sets = 64 << ((config1 >> 22) & 7);
+		c->icache.sets = 32 << (((config1 >> 22) + 1) & 7);
 		c->icache.ways = 1 + ((config1 >> 16) & 7);
 
 		icache_size = c->icache.sets *
@@ -1020,7 +1020,7 @@ static void __cpuinit probe_pcache(void)
 			c->dcache.linesz = 2 << lsize;
 		else
 			c->dcache.linesz= lsize;
-		c->dcache.sets = 64 << ((config1 >> 13) & 7);
+		c->dcache.sets = 32 << (((config1 >> 13) + 1) & 7);
 		c->dcache.ways = 1 + ((config1 >> 7) & 7);
 
 		dcache_size = c->dcache.sets *
-- 
1.7.10

Re: [PATCH] MIPS: Add support for the MIPS32 4Kc family I/D caches.

[Ralf Baechle]

On Mon, May 21, 2012 at 10:33:32AM -0500, Steven J. Hill wrote:

> Signed-off-by: Steven J. Hill <sjhill@mips.com>
> ---
>  arch/mips/mm/c-r4k.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
> index 18546fa..bca1447 100644
> --- a/arch/mips/mm/c-r4k.c
> +++ b/arch/mips/mm/c-r4k.c
> @@ -1000,7 +1000,7 @@ static void __cpuinit probe_pcache(void)
>  			c->icache.linesz = 2 << lsize;
>  		else
>  			c->icache.linesz = lsize;
> -		c->icache.sets = 64 << ((config1 >> 22) & 7);
> +		c->icache.sets = 32 << (((config1 >> 22) + 1) & 7);
>  		c->icache.ways = 1 + ((config1 >> 16) & 7);
>  
>  		icache_size = c->icache.sets *
> @@ -1020,7 +1020,7 @@ static void __cpuinit probe_pcache(void)
>  			c->dcache.linesz = 2 << lsize;
>  		else
>  			c->dcache.linesz= lsize;
> -		c->dcache.sets = 64 << ((config1 >> 13) & 7);
> +		c->dcache.sets = 32 << (((config1 >> 13) + 1) & 7);
>  		c->dcache.ways = 1 + ((config1 >> 7) & 7);
>  
>  		dcache_size = c->dcache.sets *

Good catch.  I'm amazed how long we were able to get away with this bug.
I guess it only covers a rather esotheric cache configuration.

I wonder what variant of the 4Kc is affected by this?  So far none has
an I-cache with only 32 lines per way.

  Ralf

Re: [PATCH] MIPS: Add support for the MIPS32 4Kc family I/D caches.

[Maciej W. Rozycki]

On Tue, 22 May 2012, Ralf Baechle wrote:

> > diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
> > index 18546fa..bca1447 100644
> > --- a/arch/mips/mm/c-r4k.c
> > +++ b/arch/mips/mm/c-r4k.c
> > @@ -1000,7 +1000,7 @@ static void __cpuinit probe_pcache(void)
> >  			c->icache.linesz = 2 << lsize;
> >  		else
> >  			c->icache.linesz = lsize;
> > -		c->icache.sets = 64 << ((config1 >> 22) & 7);
> > +		c->icache.sets = 32 << (((config1 >> 22) + 1) & 7);
> >  		c->icache.ways = 1 + ((config1 >> 16) & 7);
> >  
> >  		icache_size = c->icache.sets *
> > @@ -1020,7 +1020,7 @@ static void __cpuinit probe_pcache(void)
> >  			c->dcache.linesz = 2 << lsize;
> >  		else
> >  			c->dcache.linesz= lsize;
> > -		c->dcache.sets = 64 << ((config1 >> 13) & 7);
> > +		c->dcache.sets = 32 << (((config1 >> 13) + 1) & 7);
> >  		c->dcache.ways = 1 + ((config1 >> 7) & 7);
> >  
> >  		dcache_size = c->dcache.sets *
> 
> Good catch.  I'm amazed how long we were able to get away with this bug.

 It was not a bug, or at least not an active one.  The new encoding was 
only added with revision 3 of the architecture or thereabouts, so not so 
long ago.  It used to be reserved previously, so we just handled it 
arbitrarily (though perhaps we should have panicked instead on 
encountering it indeed).

> I guess it only covers a rather esotheric cache configuration.
> 
> I wonder what variant of the 4Kc is affected by this?  So far none has
> an I-cache with only 32 lines per way.

 It must be a recent addition; is the 4Kc maintained anymore actually?  
I've thought it was replaced with the 4KEc entirely, hmm...

  Maciej

Re: [PATCH] MIPS: Add support for the MIPS32 4Kc family I/D caches.

[Ralf Baechle]

On Sun, May 27, 2012 at 03:19:47AM +0100, Maciej W. Rozycki wrote:

>  It was not a bug, or at least not an active one.  The new encoding was 
> only added with revision 3 of the architecture or thereabouts, so not so 
> long ago.  It used to be reserved previously, so we just handled it 
> arbitrarily (though perhaps we should have panicked instead on 
> encountering it indeed).

The patch at least was applicable to all 2.4 and 2.6 branches ...

  Ralf

Re: [PATCH] MIPS: Add support for the MIPS32 4Kc family I/D caches.

[Maciej W. Rozycki]

On Tue, 29 May 2012, Ralf Baechle wrote:

> >  It was not a bug, or at least not an active one.  The new encoding was 
> > only added with revision 3 of the architecture or thereabouts, so not so 
> > long ago.  It used to be reserved previously, so we just handled it 
> > arbitrarily (though perhaps we should have panicked instead on 
> > encountering it indeed).
> 
> The patch at least was applicable to all 2.4 and 2.6 branches ...

 That you could have backported the change to old code doesn't mean the 
code was buggy at the time it was written.  It only became buggy as the 
environment changed.

 I have now double-checked my resources and according to the revision 
history of the architecture spec, the new encoding was only added with 
revision 3.00 of the spec: "Added encoding (0x7) for 32 sets for one cache 
way." that was dated March 2010 (my copy of revision 2.80 certainly does 
not list it and 3.05 does; I don't have the exact 3.00 revision 
unfortunately).  Up until then 64 was the smallest number of ways 
supported (and 7 was listed as a reserved encoding, just as when the code 
you've just patched was written).

 Linux 2.6.33 was released in February 2010 and 2.6.34 in May.  So 
anything before 2.6.34 was never buggy, and certainly none of 2.4 kernels.  

 You now have the answer to your concern as to how long we survived with 
this bug too: 2 years and 2 months.  Not too bad. ;)

 I still wonder why the 4Kc is mentioned in this context, this is a MIPS32 
revision 1 architecture chip, so revision 3 cannot apply to it anyway, 
hmm...

  Maciej