Re: RFC: Cleanup/detection patch

[Keith M Wesolowski <wesolows@foobazco.org>]

On Tue, Apr 03, 2001 at 07:43:07PM -0700, Jun Sun wrote:

> 1. Right now, our tree (at least 32-bit) does not even support multiple CPUs
> (with the same machine/board).  Take a look of
> arch/mips/mm/loadmmu.c:loadmmu(), and you will see what I mean.  The CPU
> specific ld_mmu_xxx is #ifdef'ed.  So if you enable multiple CPU, the last
> ld_mmu_xxx will win!
> 
> So a modest step forward would be fixing that first.

In the patch, the mips_cpu structure has a load_cache and load_tlb
function associated with it which are assigned during cpu_probe.  It
is now possible - I believe - to compile both andes.c and r4k* into
the kernel and have the right routines run at boot time.  No reason
this can't work for other CPUs also.

> 2. Currently all CPU specific ld_mmu_xxx stuff lump cache and TLB together. 
> That is not very good.  I have seen CPUs that can share cache but not TLB. 
> Vice versa.  Personally I like to see their separation first before a more
> dramatic scheme is in place.

The patch addresses this; look at the removal of r4xx0.c and its
replacements.  It's been split into four pieces - this may become
three later.  One for cache, one for tlb, one for copy/clear page and
miscellaneous outlined assembly (yes, in real assembly), and one for
initialization functions.  There's no reason it couldn't be further
split; for example, to do r4600/r5k style caches in a separate module.

> 3. Unfortunally not all CPUs can be fully probed at the run-time,
> specifically the external cache size and geometry.  I was thinking
> perhaps a board detection routine should be placed at the beginning
> which will supply external

The CPU-specific load_cache is responsible for this.  I'm open to the
idea of having separate cache detection for cache problems that are
*not* cpu-specific.  For example, if r10k indy with boardcache existed
that might be applicable.  But I think the load_cache should be able
to handle this.

> cache info.  In addition it will probably set prom_init() pointer -
> yes, we do have conflicting prom_init() from every board-specific
> implementation - and board_setup() pointer.  What do you think?

Namespace collisions like that must die.  For now the mips_init->init
is called at about the same place that prom_init used to be; in many
cases the equivalent will be needed to successfully probe a machine
and thus will be done by the probe function.  In either case, there's
no need for each machine to have a separate function with that name.

> Sorry for not giving you patch specific comments, but I figure if I
> don't spit it out now it will be probably never. :-)

Yep.

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
"I should have crushed his marketing-addled skull with a fucking bat."