[PATCH] Handle I-TLB Error and Miss separately on 8xx

[Tom Rini]

On Fri, Jan 14, 2005 at 08:51:44PM +0100, Joakim Tjernlund wrote:

> BTW, there is a simpler fix to the TLB Miss problem.
> In the TLB Miss handlers, just move the 2: label a few instr. upwards to
> the same line as the "li	r21, 0x00f0". That way you will force a 
> TLB error. You can do this for both Data and Instr. Miss handlers.
> The code after where the 2: label used to be can be deleted. 

Like this?  Only lightly tested on my rpxlite on 2.6:


---

 linux-2.6-current-trini/arch/ppc/kernel/head_8xx.S |   22 +--------------------
 1 files changed, 2 insertions(+), 20 deletions(-)

diff -puN arch/ppc/kernel/head_8xx.S~ppc32-mpc8xx-itlbmiss-fix arch/ppc/kernel/head_8xx.S
--- linux-2.6-current/arch/ppc/kernel/head_8xx.S~ppc32-mpc8xx-itlbmiss-fix	2005-01-18 11:55:34.000000000 -0700
+++ linux-2.6-current-trini/arch/ppc/kernel/head_8xx.S	2005-01-18 11:57:11.000000000 -0700
@@ -343,7 +343,7 @@ InstructionTLBMiss:
 	 * set.  All other Linux PTE bits control the behavior
 	 * of the MMU.
 	 */
-	li	r11, 0x00f0
+2:	li	r11, 0x00f0
 	rlwimi	r10, r11, 0, 24, 28	/* Set 24-27, clear 28 */
 	DO_8xx_CPU6(0x2d80, r3)
 	mtspr	MI_RPN, r10	/* Update TLB entry */
@@ -357,15 +357,6 @@ InstructionTLBMiss:
 #endif
 	rfi
 
-2:	mfspr	r10, M_TW	/* Restore registers */
-	lwz	r11, 0(r0)
-	mtcr	r11
-	lwz	r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
-	lwz	r3, 8(r0)
-#endif
-	b	InstructionAccess
-
 	. = 0x1200
 DataStoreTLBMiss:
 #ifdef CONFIG_8xx_CPU6
@@ -419,7 +410,7 @@ DataStoreTLBMiss:
 	 * set.  All other Linux PTE bits control the behavior
 	 * of the MMU.
 	 */
-	li	r11, 0x00f0
+2:	li	r11, 0x00f0
 	rlwimi	r10, r11, 0, 24, 28	/* Set 24-27, clear 28 */
 	DO_8xx_CPU6(0x3d80, r3)
 	mtspr	MD_RPN, r10	/* Update TLB entry */
@@ -433,15 +424,6 @@ DataStoreTLBMiss:
 #endif
 	rfi
 
-2:	mfspr	r10, M_TW	/* Restore registers */
-	lwz	r11, 0(r0)
-	mtcr	r11
-	lwz	r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
-	lwz	r3, 8(r0)
-#endif
-	b	DataAccess
-
 /* This is an instruction TLB error on the MPC8xx.  This could be due
  * to many reasons, such as executing guarded memory or illegal instruction
  * addresses.  There is nothing to do but handle a big time error fault.
_

-- 
Tom Rini
http://gate.crashing.org/~trini/