On Wed, 24 Nov 2004, Maciej W. Rozycki wrote:
> Agreed. We should probably verify these few "traditional" CPUs to be
> handled explicitly ourselves, though, as there is no one else to look
> after them.
Here's my proposal. It doesn't handle MIPS*R2 processors implicitly yet
as that asks for a clean implementation of MIPS architecture
determination. I'll do that in a separate step and adjust this code
afterwards. For now it should be OK. Agreed?
Note, these panic()s really beg for early printk() support -- but doesn't
everyone have it already? ;-)
Maciej
patch-mips-2.6.10-rc1-20041112-mips-tlbwr-0
diff -up --recursive --new-file linux-mips-2.6.10-rc1-20041112.macro/arch/mips/mm/tlbex.c linux-mips-2.6.10-rc1-20041112/arch/mips/mm/tlbex.c
--- linux-mips-2.6.10-rc1-20041112.macro/arch/mips/mm/tlbex.c Tue Nov 23 20:55:14 2004
+++ linux-mips-2.6.10-rc1-20041112/arch/mips/mm/tlbex.c Wed Nov 24 20:15:35 2004
@@ -761,10 +761,22 @@ static __init void build_tlb_write_rando
case CPU_R4600:
case CPU_R4700:
+ case CPU_R5000:
+ case CPU_5KC:
i_nop(p);
i_tlbwr(p);
break;
+ case CPU_R10000:
+ case CPU_R12000:
+ case CPU_4KC:
+ case CPU_SB1:
+ case CPU_4KSC:
+ case CPU_20KC:
+ case CPU_25KF:
+ i_tlbwr(p);
+ break;
+
case CPU_NEVADA:
i_nop(p); /* QED specifies 2 nops hazard */
/*
@@ -776,6 +788,12 @@ static __init void build_tlb_write_rando
l_tlbwr_hazard(l, *p);
break;
+ case CPU_4KEC:
+ case CPU_24K:
+ i_ehb(p);
+ i_tlbwr(p);
+ break;
+
case CPU_RM9000:
/*
* When the JTLB is updated by tlbwi or tlbwr, a subsequent
@@ -794,21 +812,9 @@ static __init void build_tlb_write_rando
i_ssnop(p);
break;
- case CPU_R10000:
- case CPU_R12000:
- case CPU_SB1:
- i_tlbwr(p);
- break;
-
default:
- /*
- * Others are assumed to have one cycle mtc0 hazard,
- * and one cycle tlbwr hazard or to understand ehb.
- * XXX: This might be overly general.
- */
- i_ehb(p);
- i_tlbwr(p);
- i_ehb(p);
+ panic("No TLB refill handler yet (CPU type: %d)",
+ current_cpu_data.cputype);
break;
}
}
