Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Jun Sun <jsun@mvista.com>]

Maciej W. Rozycki wrote:
> On Tue, 23 Jul 2002, Ralf Baechle wrote:
> 
> 
>>I intentionally have that 32-bit stuff in the 64-bit kernel so we can simply
>>have share identical CPU probing code between the 32-bit and 64-bit kernels.
>>This in anticipation of a further unification of the two ports which still
>>duplicate plenty of code with just minor changes.
> 
> 
>  I suspected a maintability reason.  Thus as a temporary fix I'm checking
> in a version that provides the missing cpu_has_fpu() function (a copy
> from the trunk).
> 
> 
>>To make sharing easier I suggest to move all the CPU probing code into it's
>>own file, probe.c or so?
> 
> 
>  That might be a good idea in principle, but it won't solve the problem
> anyway.  I'd like to see the code for 32-bit processors get annihilated by
> the compiler if built for mips64.  I'll look at it soon.  The MIPS32/64
> crap needs to be fixed here as well.
> 

FWIW, I like to see CPU probing and setup done in a distributed, configurable 
fashion.  Here are some of my ideas which have been floating around for a while.

. There is a global table, where each entry in the table have (at least) four 
fields:
	uint company_id
	uint processor_id
	uint revision_id
	void (*setup_cpu)(void);

. cpu_probe() simply reads prid register and search through the table.  If it 
finds matching one, then issue the (setup_cpu) call.

. matching allows wildcard matching.  Apparently more specific entry should be 
checked before more generic entries.

. cpu cache routines and tlb routines are organized accordingly, so that 
static configurations can be done sensibly.

This structure allows maximum code sharing for conforming CPUs and also give 
an easy for unique ones or buggy, early-production ones.  It should also make 
it easy to add or remove support for particular CPU or CPU family.  Of course, 
more details need to be fleshed out.


Jun