c-r4k.c cleanup

c-r4k.c cleanup

[Atsushi Nemoto]

This code is wrong (should be "c->dcache.waysize > PAGE_SIZE") and
unnecessary (done correctly in probe_pcache).

diff -u -r1.96 c-r4k.c
--- arch/mips/mm/c-r4k.c	7 Dec 2004 02:33:02 -0000	1.96
+++ arch/mips/mm/c-r4k.c	4 Feb 2005 14:01:35 -0000
@@ -1213,9 +1213,6 @@
 	probe_pcache();
 	setup_scache();
 
-	if (c->dcache.sets * c->dcache.ways > PAGE_SIZE)
-		c->dcache.flags |= MIPS_CACHE_ALIASES;
-
 	r4k_blast_dcache_page_setup();
 	r4k_blast_dcache_page_indexed_setup();
 	r4k_blast_dcache_setup();


Also, some MIPS32/MIPS64 chip have physically indexed data cache so do
no suffer from aliasing.  CPU_20KC is one of them.  Others?

---
Atsushi Nemoto

Re: c-r4k.c cleanup

[Nigel Stephens]

Atsushi Nemoto wrote:

>This code is wrong (should be "c->dcache.waysize > PAGE_SIZE") and
>unnecessary (done correctly in probe_pcache).
>
>diff -u -r1.96 c-r4k.c
>--- arch/mips/mm/c-r4k.c	7 Dec 2004 02:33:02 -0000	1.96
>+++ arch/mips/mm/c-r4k.c	4 Feb 2005 14:01:35 -0000
>@@ -1213,9 +1213,6 @@
> 	probe_pcache();
> 	setup_scache();
> 
>-	if (c->dcache.sets * c->dcache.ways > PAGE_SIZE)
>-		c->dcache.flags |= MIPS_CACHE_ALIASES;
>-
> 	r4k_blast_dcache_page_setup();
> 	r4k_blast_dcache_page_indexed_setup();
> 	r4k_blast_dcache_setup();
>
>
>Also, some MIPS32/MIPS64 chip have physically indexed data cache so do
>no suffer from aliasing.  CPU_20KC is one of them.  Others?
>  
>

The MIPS 24K family's caches are not physically indexed, but they do 
have optional h/w assist to prevent aliases in certain cache 
configurations. This optional feature is indicated by the read-only AR 
(alias removed) flag being set - that's bit 16 in the CP0 Config7 register.

Nigel

Re: c-r4k.c cleanup

[Ralf Baechle]

On Fri, Feb 04, 2005 at 02:39:07PM +0000, Nigel Stephens wrote:

> The MIPS 24K family's caches are not physically indexed, but they do 
> have optional h/w assist to prevent aliases in certain cache 
> configurations. This optional feature is indicated by the read-only AR 
> (alias removed) flag being set - that's bit 16 in the CP0 Config7 register.

That's not a new feature in the MIPS world; the R10000 family introduced
that first and Linux knows how to make use of it.  So now I just need to
teach c-r4k.c to check the AR bit on the 24K.

  Ralf

Re: c-r4k.c cleanup

[Dominic Sweetman]

Only some CPUs suffer from aliases.  A 4Kbyte direct-mapped cache must
be alias free, because all the virtual index bits are the same (being
in-page) as the physical address bits.  That's true but irrelvant,
since there aren't any 4Kbyte caches: but what's slightly less obvious
is that a 16Kbyte 4-way set-associative cache is also alias free.

24K's "AR" bit trick applies *only* to the D-cache, and only to a
32Kbyte cache.  (But then most alias problems are D-cache aliases, and
32Kbyte happens to be the most popular size for a 24K cache - so this
is a trick worth doing).

Note that I-cache aliases are not completely harmless; sometimes you
want to invalidate any I-cache copies of some data, and if it's
aliased you may miss some of them.  Shared libraries are generally
aligned to some large page-size multiple - so multiple text images are
usually the same colour, and don't matter.  You can get problems with
trampolines and stuff.

--
Dominic Sweetman
MIPS Technologies

Re: c-r4k.c cleanup

[Ralf Baechle]

On Fri, Feb 04, 2005 at 03:19:49PM +0000, Dominic Sweetman wrote:

> Only some CPUs suffer from aliases.  A 4Kbyte direct-mapped cache must
> be alias free, because all the virtual index bits are the same (being
> in-page) as the physical address bits.  That's true but irrelvant,
> since there aren't any 4Kbyte caches: but what's slightly less obvious
> is that a 16Kbyte 4-way set-associative cache is also alias free.

I had dark memory of some el cheapo CPU having 4k caches.

> 24K's "AR" bit trick applies *only* to the D-cache, and only to a
> 32Kbyte cache.  (But then most alias problems are D-cache aliases, and
> 32Kbyte happens to be the most popular size for a 24K cache - so this
> is a trick worth doing).
> 
> Note that I-cache aliases are not completely harmless; sometimes you
> want to invalidate any I-cache copies of some data, and if it's
> aliased you may miss some of them.  Shared libraries are generally
> aligned to some large page-size multiple - so multiple text images are
> usually the same colour, and don't matter.  You can get problems with
> trampolines and stuff.

Linux computes the necessary alignment on the fly.  The method used is
not strictly correct because as you say it should account for possible
I-cache aliases also.

Seems it's cache day again today ;-)

  Ralf

Re: c-r4k.c cleanup

[Ralf Baechle]

On Fri, Feb 04, 2005 at 04:45:32PM +0100, Ralf Baechle wrote:

> > Note that I-cache aliases are not completely harmless; sometimes you
> > want to invalidate any I-cache copies of some data, and if it's
> > aliased you may miss some of them.  Shared libraries are generally
> > aligned to some large page-size multiple - so multiple text images are
> > usually the same colour, and don't matter.  You can get problems with
> > trampolines and stuff.
> 
> Linux computes the necessary alignment on the fly.  The method used is
> not strictly correct because as you say it should account for possible
> I-cache aliases also.
> 
> Seems it's cache day again today ;-)

This is what I've checked in.

  Ralf

Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.97
diff -u -r1.97 c-r4k.c
--- arch/mips/mm/c-r4k.c	4 Feb 2005 15:19:01 -0000	1.97
+++ arch/mips/mm/c-r4k.c	4 Feb 2005 15:48:38 -0000
@@ -1012,9 +1012,17 @@
 	 * normally they'd suffer from aliases but magic in the hardware deals
 	 * with that for us so we don't need to take care ourselves.
 	 */
-	if (c->cputype != CPU_R10000 && c->cputype != CPU_R12000)
+	switch (c->cputype) {
 		if (c->dcache.waysize > PAGE_SIZE)
-		        c->dcache.flags |= MIPS_CACHE_ALIASES;
+			
+	case CPU_R10000:
+	case CPU_R12000:
+		break;
+	case CPU_24K:
+		if (!(read_c0_config7() & (1 << 16)))
+	default:
+			c->dcache.flags |= MIPS_CACHE_ALIASES;
+	}
 
 	switch (c->cputype) {
 	case CPU_20KC:

Re: c-r4k.c cleanup

[David Daney]

Ralf Baechle wrote:
> This is what I've checked in.
> 
>   Ralf
> 
> Index: arch/mips/mm/c-r4k.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
> retrieving revision 1.97
> diff -u -r1.97 c-r4k.c
> --- arch/mips/mm/c-r4k.c	4 Feb 2005 15:19:01 -0000	1.97
> +++ arch/mips/mm/c-r4k.c	4 Feb 2005 15:48:38 -0000
> @@ -1012,9 +1012,17 @@
>  	 * normally they'd suffer from aliases but magic in the hardware deals
>  	 * with that for us so we don't need to take care ourselves.
>  	 */
> -	if (c->cputype != CPU_R10000 && c->cputype != CPU_R12000)
> +	switch (c->cputype) {
>  		if (c->dcache.waysize > PAGE_SIZE)
> -		        c->dcache.flags |= MIPS_CACHE_ALIASES;
> +			
> +	case CPU_R10000:
> +	case CPU_R12000:
> +		break;
> +	case CPU_24K:
> +		if (!(read_c0_config7() & (1 << 16)))
> +	default:
> +			c->dcache.flags |= MIPS_CACHE_ALIASES;
> +	}
>  
>  	switch (c->cputype) {
>  	case CPU_20KC:

That may be legal C, but I have a difficult time figuring out exactly 
what it is supposed to do as case labels in the middle of statements 
confuses me.

Does the first if in the switch do anything?  My reading of the spec 
indicates that it is unreachable code.

Just my $0.02

David Daney.

Re: c-r4k.c cleanup

[Jun Sun]

On Fri, Feb 04, 2005 at 04:45:32PM +0100, Ralf Baechle wrote:
> On Fri, Feb 04, 2005 at 03:19:49PM +0000, Dominic Sweetman wrote:
> 
> > Only some CPUs suffer from aliases.  A 4Kbyte direct-mapped cache must
> > be alias free, because all the virtual index bits are the same (being
> > in-page) as the physical address bits.  That's true but irrelvant,
> > since there aren't any 4Kbyte caches: but what's slightly less obvious
> > is that a 16Kbyte 4-way set-associative cache is also alias free.
> 
> I had dark memory of some el cheapo CPU having 4k caches.
> 

IDT (rc32332) has a 2K d-cache. :)

Jun

Re: c-r4k.c cleanup

[Atsushi Nemoto]

>>>>> On Fri, 4 Feb 2005 15:58:03 +0100, Ralf Baechle <ralf@linux-mips.org> said:
ralf> That's not a new feature in the MIPS world; the R10000 family
ralf> introduced that first and Linux knows how to make use of it.  So
ralf> now I just need to teach c-r4k.c to check the AR bit on the 24K.

20KC Users Manual says it has physically indexed data cache.

--- linux-mips.org/arch/mips/mm/c-r4k.c	2005-02-07 19:06:54.598390493 +0900
+++ linux-mips/arch/mips/mm/c-r4k.c	2005-02-07 19:10:38.779771207 +0900
@@ -1016,6 +1016,8 @@
 	case CPU_R10000:
 	case CPU_R12000:
 		break;
+	case CPU_20KC:	/* physically indexed */
+		break;
 	case CPU_24K:
 		if (!(read_c0_config7() & (1 << 16)))
 	default:

For other MIPS64 core, 5Kc has virtually indexed cache.  How about 25KF?

---
Atsushi Nemoto

Re: c-r4k.c cleanup

[Yoichi Yuasa]

On Mon, 07 Feb 2005 19:24:50 +0900 (JST)
Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:

> >>>>> On Fri, 4 Feb 2005 15:58:03 +0100, Ralf Baechle <ralf@linux-mips.org> said:
> ralf> That's not a new feature in the MIPS world; the R10000 family
> ralf> introduced that first and Linux knows how to make use of it.  So
> ralf> now I just need to teach c-r4k.c to check the AR bit on the 24K.
> 
> 20KC Users Manual says it has physically indexed data cache.
> 
> --- linux-mips.org/arch/mips/mm/c-r4k.c	2005-02-07 19:06:54.598390493 +0900
> +++ linux-mips/arch/mips/mm/c-r4k.c	2005-02-07 19:10:38.779771207 +0900
> @@ -1016,6 +1016,8 @@
>  	case CPU_R10000:
>  	case CPU_R12000:
>  		break;
> +	case CPU_20KC:	/* physically indexed */
> +		break;
>  	case CPU_24K:
>  		if (!(read_c0_config7() & (1 << 16)))
>  	default:
> 
> For other MIPS64 core, 5Kc has virtually indexed cache.  How about 25KF?

25Kf also has virtually indexed cache.

Yoichi

Re: c-r4k.c cleanup

[Yoichi Yuasa]

On Mon, 7 Feb 2005 21:32:27 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> On Mon, 07 Feb 2005 19:24:50 +0900 (JST)
> Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> 
> > >>>>> On Fri, 4 Feb 2005 15:58:03 +0100, Ralf Baechle <ralf@linux-mips.org> said:
> > ralf> That's not a new feature in the MIPS world; the R10000 family
> > ralf> introduced that first and Linux knows how to make use of it.  So
> > ralf> now I just need to teach c-r4k.c to check the AR bit on the 24K.
> > 
> > 20KC Users Manual says it has physically indexed data cache.
> > 
> > --- linux-mips.org/arch/mips/mm/c-r4k.c	2005-02-07 19:06:54.598390493 +0900
> > +++ linux-mips/arch/mips/mm/c-r4k.c	2005-02-07 19:10:38.779771207 +0900
> > @@ -1016,6 +1016,8 @@
> >  	case CPU_R10000:
> >  	case CPU_R12000:
> >  		break;
> > +	case CPU_20KC:	/* physically indexed */
> > +		break;
> >  	case CPU_24K:
> >  		if (!(read_c0_config7() & (1 << 16)))
> >  	default:
> > 
> > For other MIPS64 core, 5Kc has virtually indexed cache.  How about 25KF?
> 
> 25Kf also has virtually indexed cache.

Sorry, D-cahce is physically indexed cache.

Yoichi

Re: c-r4k.c cleanup

[Dominic Sweetman]

Atsushi Nemoto (anemo@mba.ocn.ne.jp) writes:

> 20KC Users Manual says it has physically indexed data cache.

That's correct.

> For other MIPS64 core, 5Kc has virtually indexed cache.

Yes.

> How about 25KF?

Physically indexed, it's a descendent of the 20Kc core.

--
Dominic

Re: c-r4k.c cleanup

[Dominic Sweetman]

Interesting,

> Atsushi Nemoto (anemo@mba.ocn.ne.jp) writes:
> 
> > 20KC Users Manual says it has physically indexed data cache.
> 
> That's correct.
> 
> > For other MIPS64 core, 5Kc has virtually indexed cache.
> 
> Yes.
> 
> > How about 25KF?
> 
> Physically indexed, it's a descendent of the 20Kc core.

When Yoichi said 

> 25Kf also has virtually indexed cache

I assume s/he meant the I-cache.

Here is the official MIPS Technologies line (and we kind of ought to know):

o The 25KF D-cache is physically indexed (and of course
  physically tagged). 

o The 25KF I-cache is virtually indexed and virtually tagged - the tag
  includes the ASID to reduce the number of occasions on which you
  have to invalidate all the lines from a particular process.

o A 25KF secondary cache, if provided, is physically indexed and
  tagged. 

-- 
Dominic Sweetman, 
MIPS Technologies (UK)
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706205 / fax: +44 1223 706250 / swbrd: +44 1223 706200
http://www.mips.com

Re: c-r4k.c cleanup

[Ralf Baechle]

On Mon, Feb 07, 2005 at 01:52:57PM +0000, Dominic Sweetman wrote:

> o The 25KF D-cache is physically indexed (and of course
>   physically tagged). 
> 
> o The 25KF I-cache is virtually indexed and virtually tagged - the tag
>   includes the ASID to reduce the number of occasions on which you
>   have to invalidate all the lines from a particular process.
> 
> o A 25KF secondary cache, if provided, is physically indexed and
>   tagged. 

Ok, so I've added it also, thanks.

  Ralf

Re: c-r4k.c cleanup

[Ralf Baechle]

On Mon, Feb 07, 2005 at 07:24:50PM +0900, Atsushi Nemoto wrote:

> >>>>> On Fri, 4 Feb 2005 15:58:03 +0100, Ralf Baechle <ralf@linux-mips.org> said:
> ralf> That's not a new feature in the MIPS world; the R10000 family
> ralf> introduced that first and Linux knows how to make use of it.  So
> ralf> now I just need to teach c-r4k.c to check the AR bit on the 24K.
> 
> 20KC Users Manual says it has physically indexed data cache.

Correct - and just to make this CPU one of a rare breed in the MIPS world
it also has virtually indexed, virtually tagged caches, similar to the
Sibyte SB1.  Sibyte still uses it's own cache code but eventually that
should go away, so I've listed it also.

  Ralf