So, the way l2 caches are handled in the NetBSD mips code is kinda
bogus.  They are, as far as I can tell, pretty much board-specific,
in at least their sizing and detection, and, because of that, their
handling has to be machine-specific, as well.

The fact that their sizing and detection is board-specific is borne
out by the #ifdef's in mips3_vector_init().

Their line size and number of sets is implementation-specific, as well
(and the actual ops to manipulate them may be, too).  (The primary
cache ops are pretty well standardized, but secondary cache ops are
not quite as well standardized.)

I also note the duplication of code between FlushCache, FlushDDache,
FlushICache, etc.  Some of it scares me (like the comment above
mips3_FlushCache, about the assumption... which just doesn't match the
code).

The whole set of diffs around MIPS3_L2CACHE_ABSENT are
... interesting, as well.


Anyway, the way I'd do this is define ops which flush the l1 and l2
caches in the 'standard' ways, for the standard line sizes.
CPU-specific code would fill in the l1 info, and the l2 info if
appropriate (is that ever appropriate on MIPS?), and board-specific
code would fill in the l2 (and further) otherwise.

If efficiency is reaslly considered to be an issue (uh, just about to
issue how many memory ops, are a few jr's really gonna make a diff?),
the entry points could be kept the same and boards could
consruct slightly-more-optimized functions to do all of the flushes.
However, if this is done, std ops which just jump through function
pointers should be provided; I'd bet some $$ that they'll be more
useful as time goes on.

This doesn't cover all the possible cache-related bases which exist,
but it covers all of the ones that the existing code does (poorly 8-).


Anybody wanna do it?  I'd love to, but I don't have much time, and
worse, don't have any real resources with which to test my mods.  I'd
be quite glad to review any concrete proposals, however.



chris