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."
|