Subject: c-r4k.c cleanup

From: Atsushi Nemoto <[email-masked]>
Date: Fri, 04 Feb 2005 23:12:54 +0900 (JST)

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

---

From: Nigel Stephens <[email-masked]>
Date: Fri, 04 Feb 2005 14:39:07 +0000

>+++ arch/mips/mm/c-r4k.c	4 Feb 2005 14:01:35 -0000

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

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 4 Feb 2005 15:58:03 +0100

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

---

From: Dominic Sweetman <[email-masked]>
Date: Fri, 4 Feb 2005 15:19:49 +0000

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

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 4 Feb 2005 16:45:32 +0100

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

> usually the same colour, and don't matter.  You can get problems with

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

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 4 Feb 2005 16:53:40 +0100

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

---

From: Jun Sun <[email-masked]>
Date: Fri, 4 Feb 2005 09:49:27 -0800

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

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

Jun

---

From: David Daney <[email-masked]>
Date: Fri, 04 Feb 2005 09:51:50 -0800

> Index: arch/mips/mm/c-r4k.c

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.

---

From: Atsushi Nemoto <[email-masked]>
Date: Mon, 07 Feb 2005 19:24:50 +0900 (JST)

>>>>> On Fri, 4 Feb 2005 15:58:03 +0100, Ralf Baechle <[email-masked]> 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

---

From: Yoichi Yuasa <[email-masked]>
Date: Mon, 7 Feb 2005 21:32:27 +0900

On Mon, 07 Feb 2005 19:24:50 +0900 (JST)

> +++ linux-mips/arch/mips/mm/c-r4k.c	2005-02-07 19:10:38.779771207 +0900

25Kf also has virtually indexed cache.

Yoichi

---

From: Dominic Sweetman <[email-masked]>
Date: Mon, 7 Feb 2005 12:36:50 +0000

> 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

---

From: Dominic Sweetman <[email-masked]>
Date: Mon, 7 Feb 2005 13:52:57 +0000

Interesting,

> 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

---

From: Yoichi Yuasa <[email-masked]>
Date: Mon, 7 Feb 2005 23:04:11 +0900

On Mon, 7 Feb 2005 21:32:27 +0900

> 25Kf also has virtually indexed cache.

Sorry, D-cahce is physically indexed cache.

Yoichi

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 7 Feb 2005 21:36:48 +0000

> 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

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 7 Feb 2005 21:49:49 +0000

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

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

  Ralf