"Chris G. Demetriou" wrote:
>
> however, one of the things that it means is, basically, anyplace which
> does a mips3_FlushDCache() on a non-kseg0 address is potentially
> suspect, right?

I don't think this is true.  K2SEG often has to be flushed.  User
address
may also need to be flushed (see below).

> does it not?  The rest of the uses (excluding the Ugh!) are only hit if
> there's no l2 cache, on kseg0 addresses, or in one case (pmap.c:1751)
> a physical address.

What the no L2 mess is all about is to do VCE avoidance in software.
On the R4000 the virtual synonym is kept in the tag, and an interrupt
is generated to let software flush the alias.  The R1x000 does this
all in hardware.

> btw, the code on ll 1738-2178 in pmap.c looks ... iffy to me.  Why is
> that in a defined(MIPS3_L2CACHE_ABSENT) #ifdef, if it doesn't bother
> checking for !mips_L2CachePresent like the similar bits of #ifdef'd
> flushing code do?  (If the test is irrelevant, why is it
> conditionalized?!)

I noticed this today looking at some other code.  The SGI Indy port
will force defining this interface better as it supports a wide
variety of processors (R4000SC, R4000PC, R4600, R4600 with L2 cache
on SysAD, R4000SC, R5000).

The code to do VCE avoidance, should be called that instead of hiding
under an L2 #ifdef.  This is something I need to work on.

> (1) the point above is about doing the kseg conversion in C there for
>     FlushICache, but in assembly for FlushDCache.  Of the mips3
>     FlushICache calls i could find in the MI pmap, 2 were done with a
>     kseg0 address, but one was done with a potentially-user va, AFAIK.
>     (again the requirement of virtual indexing, correct?) In the one
>     done with a 'random' va (pmap.c:1340), the pa is at hand, why not
>     use it, and then you could make the calling interface consistent?

The physical address may have a different virtual index, so if you
know the mapping, you need to use it. 

> (2) one of the things that _really_ confused me about it is that
>     mips3_FlushICache() uses the VA provided, but
>     mips3_FlushICache_2way() takes the address, chops bits off, and
>     offsets it into kseg0.  For that case, you do twice the work,
>     and the C code wouldn't get the mask right anyhow, as-is.

This is what I refered to in my last e-mail.  I'll havn't looked at
-current (we are quite a bit off).  The reason is that if you are
given a user address, you cannot add (dcache_size/2) to it.  It may
not be a valid address.  Yet, by the definition of the interface
you need to index flush, so you must hit both ways.

> (3) there're issues around secondary I-caches (for split secondary
>     caches), but it's not clear that _anybody_ really cares about
>     them.  I don't think i've ever even heard of them in the wild.

I don't recall seeing a platform like this.  Another thing that
R4x00 (except R4600SC Indy) machines should take advantage of is 
that the primary cache is always a subset of the secondary cache.
These machines normally can issue only secondary cache ops.

> if you passed virtual and physical, and did no more than a page at a
> time, you could have a processor's/board's cache ops do whatever was
> appropriate for that processor (i.e., pick virtual or physical
> address, based on indexing type for each cache).  it looks like just
> about every place which uses the cache ops either has both a pa and a
> va (of some type) at hand...  hmm.  this maybe seems like a good idea.

This may be good.  There are cases like the VCE stuff where you may
not have this, but in that case you know you are vitually indexed and
you can pass 0.

> >   I've also alway thought there should be some cache invalidate operations
> > for those cases where you don't need the cache flushed to memory.
> 
> yeah, the pre-DMA ops could use this type of thing, certainly.

That's is a win too.  The code has to be careful to avoid cache line
tearing and invalidating outside the buffer.  IRIX does this.

jeffs