[Top] [All Lists]

Re: [PATCH] MIPS: Remove execution hazard barriers for Octeon.

To: Paul Gortmaker <>
Subject: Re: [PATCH] MIPS: Remove execution hazard barriers for Octeon.
From: David Daney <>
Date: Mon, 11 May 2009 15:24:17 -0700
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Thunderbird (X11/20090320)
Paul Gortmaker wrote:
On Mon, May 11, 2009 at 3:11 PM, David Daney <> wrote:
The Octeon has no execution hazards, so we can remove them and save an
instruction per TLB handler invocation.

Signed-off-by: David Daney <>
 arch/mips/mm/tlbex.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index 3548acf..4b2ea1f 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -257,7 +257,7 @@ static void __cpuinit build_tlb_write_entry(u32 **p, struct 
uasm_label **l,
       case tlb_indexed: tlbw = uasm_i_tlbwi; break;

-       if (cpu_has_mips_r2) {
+       if (cpu_has_mips_r2 && current_cpu_type() != CPU_CAVIUM_OCTEON) {

Assuming that it is feasible that some other future cores might also be
free of execution hazards, wouldn't it be better to do:

  if (cpu_has_mips_r2 && cpu_has_exec_hazard) {

That would be a bit cleaner.  I will test a new patch.

David Daney

and then hide the CPU type listing (currently just one) in some header file?


<Prev in Thread] Current Thread [Next in Thread>