mostly for the r3900 crowd, but there are some more generic questions
at the end.  8-)


So, i'm looking through the various cache ops, to see about the notion
of a common set of interfaces, and I came across a the chunk of
r3900.h:

/* 
 *      R3900 CACHE instruction (not MIPS3 cache op)
 */
#define R3900_MIN_CACHE_SIZE            1024
#define R3900_MAX_DCACHE_SIZE           (8 * 1024) 
#ifndef OP_CACHE
#define OP_CACHE        057
#endif
#define R3900_CACHE(op, offset, base) \
        .word (OP_CACHE << 26 | ((base) << 21) | ((op) << 16) | \
        ((offset) & 0xffff))
#define R3900_CACHE_I_INDEXINVALIDATE   0
#define R3900_CACHE_D_HITINVALIDATE     0x11

#define CPUREG_A0       4
#define CPUREG_T0       8


Perusing the tx39 core arch. manual, certainly, very few cache ops are
actually supported (just IINV_I, HINV_D, and ops to clear the lock and
LRU bits in the dcache).

However, I don't see anything which backs up the comment "not MIPS3
cache op", or which would force use of the .word to encode the op.
the encoding seems to be the same as the standard cache op.  (In fact,
it looks like the R3900_CACHE op treats the value of 'offset' as
unsigned, which reading the manual seems incorrect, but probably safe,
esp. for our use.  8-)

Additionally, binutils seems to mark the use of the 'cache' op as OK
if MIPS3 (or better) _or_ r3900.


So, any reason why R3900_CACHE exists at all?


it looks like you could easily check the proper behaviour by changing
things to be as follows:

#define R3900_cache(op, offset, base)				\
	.set push						\
	.set mips3						\
	cache op, offset(base)					\
	.set pop

#define	CPUREG_A0	a0
#define	CPUREG_A0	t0


The (more) generic questions:

	* why does pmap_procwr() flush both I and D for mips3, but
	  only flush I for mips1?

	* most FlushDCache routines seem to use writeback-invalidate.
	  the r3900 one seems to use invalidate (i.e., no
	  write-back!).  (The FlushCache routine seems to accomplish
	  the writeback-invalidate by loading data.)

	  Given the use of FlushDCache for mips1 in pmap_remove_pv,
	  this would seem to be incorrect...



chris