Re: New MIPS cache code vs. R5k secondary caches...

In message <[email protected]>, you write: 

-> On Fri, Sep 20, 2002 at 04:24:00PM -0400, Rafal Boni wrote:
-> 
->  > 		* First of all, Jason noted that he'd verified RM5260 worked
->  > 		  on his P5064; was this with L2 or without?
-> 
-> As far as I know, none of the QED (now PMC-Sierra) RM52xx CPUs have an
-> L2 cache interface.  Obviously, mine was tested without :-)

Ah!  I did register for doc access at PMC-Sierra after I sent the previous
mail, and grabbed the manual and errata, but haven't read any of it yet.

->  > 		* Given the R5k has separate SC-present and SC-enabled bits,
->  > 		  should the generic cache code only try and use the cache
->  > 		  if both are true?  Currently, it assumes if the SC-present
->  > 		  bit is on, it must set up (and hence use) SC cache ops.
-> 
-> It should probably check SC-present and SC-enabled.

That's what I was thinking; this would also make it very easy to work around
the SC badness by clearing the enable bit in mips_machdep_cache_config() and
this causing the cache code to ignore the L2 cache.

->  > 		* The only defined operation for secondary cache is "page
->  > 		  invalidate" which requires "page" (where "page" == 128 
->  > 		  cache lines of 32-bytes each) aligned addresses.
->  > 
->  > 			* This means no indexed operations for secondary
->  > 			  cache; what are the repercussions on the cache
->  > 			  code here?
-> 
-> The code obviously tried to use HIT ops when it can.  Since the L2
-> is write-through, you're okay ... you can make wbinv_range_index the
-> same as wbinv_all (sure, that sucks, but it will provide correct operation).

Hmm, OK.  That would work.

-> So, it sounds like you need the following ops for the R5000 L2:
-> 
-> 	wbinv_all	"page invalidate" the entire L2 in a loop.
-> 			Not sure how you'll go about doing this if
-> 			there is no index op!

Yah, I'm not either.  The Linux code I've seem people toss around does as
if the page invalidate cacheop where actually indexed -- by just walking
from KSEG0 to KSEG0 + sdcache_size and invalidating each page inbetween.

Another way to do this may be to simply use the SDcache INDEX STORE TAG
to mark all the cache blocks invalid; this could also be used if we wanted
to invalidate very small regions (ie, << page size).

-> 	wbinv_range	"page invalidate" the range.  First round to
-> 			find the end address, then truncate to find
-> 			the start address.

Yup, this is the easy one.

-> 	wbinv_range_index   Same as wbinv_all ??
-> 
-> 	inv_range	Same as wbinv_range.
-> 
-> 	wb_range	Noop.

Right.

--rafal

----
Rafal Boni                                                     [email protected]
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill