On Wed, 10 Oct 2007, Ralf Baechle wrote:
> > As long as the user is indeed capable of knowing what the exact CPU type
> > is. I have been told replacing R4X00 with a choice like R4000, R4400,
> > R4600, R4700 may already be too much of a hassle.
> Four choices is too much; after all these four marketing names are really
> just 4 variants of two fairly similar processors. Doable? Yes. A useful
> improvment? I doubt, otoh users of those old machines count every cycle
> by hand still ;-)
Except from the note on cycle counting ;-) I do agree these days and
about the only place that cares about the subtleties of the R4k models are
the TLB handlers which we have now solved with the current approach.
> One of the things I'm trying to achieve is to get rid of all the use of
> CONFIG_CPU_MIPS32_R1 and similar processor symbols in code coming to a
> point where selection of one of those symbols in Kconfig only means to
> optimize a kernel for the selected core without sacrificing compatibility.
Well, these options should really be used to select the "-march=" option
only. We have some places, such as <asm/stackframe.h>, where the
dependency is tough to eliminate, but that is definitely the right
> (But of course the few machines that support processors with multiple ISAs
> spoil that plan a little ..)
Well, they have cp0.prid and cp0.config* registers at their disposal.
> > I do not think we happen to handle this scenario -- the more interesting
> > configurations that could benefit do not support the cp0.ebase register
> > making per-CPU handlers quite a challenge (i.e. the cost would exceed the
> > benefit).
> It's doable but there is little point. Ebase is an R2 feature and who
> on earth would mix pre-R2 and R2 cores in a SOC now that R2 is established
> for a few years?
I have actually thought of one of your pet SGI machine setups -- where
the CPUs are mixed and are either MIPS III or MIPS IV each. I do not
recall you mentioning the exception vector range of RAM being local to the
CPU cards, so I am assuming the handlers are always shared.