PROPOSAL : multi-way cache support in Linux/MIPS

[Jun Sun <jsun@mvista.com>]

Ralf,

I have got NEC DDB5476 running stable enough that I am comfortable to
check in
my code.  Will you take it?

Assuming the answer is yes, there are several issues regarding checking
in.
I will bring them up one by one.

The first issue is multi-way cache support.  DDB5476 uses R5432 CPU
which
has two-way set-associative cache.  The problematic part is the
index-based cache operations in r4xxcache.h does not cover all ways in a
set.

I think this is a problem in general.  So far I have seen MIPS
processors with
2-way, 4-way and 8-way sets.  And I have seen them using ether least-
significant-addressing-bits or most-significant-addressing-bits
within a cache line to select ways.

Here is my proposal :

. introduce two variables,
        cache_num_ways - number of ways in a set
        cache_way_selection_offset - the offset added to the address to
select
                next cache line in the same set.  For LSBs addressing,
it is
                equal to 1.  For MSBs addressing, it is equal to
                cache_line_size / cache_num_ways.  (It can potentially
take
                care of some future weired way-selection scheme as long
as
                the offset is uniform)

. These variables are initialized in cpu_probe().

  (Alternatively, I think we should have cpu_info table, that contains
all
   these cpu information.  Then a general routine can fill in the based
on
   the cpu id.  This can get rid of a bunch of ugly switch/case
statements.)

. in the include/asm/r4kcache.h file, all Index-based cache operation
needs
  to changed like the following (for illustration only; need
optimization) :

-----
        while(start < end) {
                cache16_unroll32(start,Index_Writeback_Inv_D);
                start += 0x200;
        }
+++++
        while(start < end) {
                for (i=0; i< cache_num_ways; i++) {
                        cache16_unroll32(start +
i*cache_way_selection_offset,
                                         Index_Writeback_Inv_D);
                }
                start += 0x200;
        }
=====

What do you think?  If it is OK, I can do the patch.  The cpu_info table
is a nice wish, but I don't think I know enough to do that job yet.

Jun