linux-mips
[Top] [All Lists]

Re: [PATCH] Synthesize TLB refill handler at runtime

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] Synthesize TLB refill handler at runtime
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Wed, 24 Nov 2004 15:04:10 +0000 (GMT)
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>, Manish Lachwani <mlachwani@mvista.com>, Geert Uytterhoeven <geert@linux-m68k.org>, Linux/MIPS Development <linux-mips@linux-mips.org>
In-reply-to: <20041124094423.GB21039@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20041121170242.GR20986@rembrandt.csv.ica.uni-stuttgart.de> <Pine.GSO.4.61.0411212048520.26374@waterleaf.sonytel.be> <20041121203757.GS20986@rembrandt.csv.ica.uni-stuttgart.de> <20041122070117.GB25433@linux-mips.org> <41A283BD.3080300@mvista.com> <Pine.LNX.4.58L.0411230036310.31113@blysk.ds.pg.gda.pl> <41A29DCF.8030308@mvista.com> <Pine.LNX.4.58L.0411232018390.19941@blysk.ds.pg.gda.pl> <20041124014057.GE902@rembrandt.csv.ica.uni-stuttgart.de> <20041124094423.GB21039@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 24 Nov 2004, Ralf Baechle wrote:

> > >   default:
> > >           /*
> > >            * Others are assumed to have one cycle mtc0 hazard,
> > > -          * and one cycle tlbwr hazard.
> > > +          * and one cycle tlbwr hazard or to understand ehb.
> > >            * XXX: This might be overly general.
> > >            */
> > > -         i_nop(p);
> > > +         i_ehb(p);
> > >           i_tlbwr(p);
> > > -         i_nop(p);
> > > +         i_ehb(p);
> > >           break;
> > 
> > Does r24k really need both delays? If not, it should get its own case.

 Good point -- "eret" is a hazard barrier, too, so the second "ehb" is not
needed.  For any release 2 implementation, actually.

> > Probably it should be separated even if it is identical, the code above
> > is nothing but a guess based on preexisting code.
> 
> I would suggest to default to EHB only for architecture revision 2.  For
> any pre-V2 processor the outcome of a default case is basically luck and
> so I would suggest to just panic and force people to read their CPU
> manual.

 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.

  Maciej

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