Hi folks...

As some of you have noticed, there's a branch on the source tree called
"thorpej-mips-cache".  The purpose of this branch is to overhaul the
way caches are handled in NetBSD/mips.  The current method on the trunk
is not really optimal for modern systems, and not flexible enough to
handle the fairly large number of cache configurations one is likely to
encounter.

As you may have remembered, I posted a description of my work on the
new cache primitives a while ago on this list.  The way it works is
the cache configuration code sets up a function vector based on the
cache configuration of the system, and provides the following API
to code that needs to manipulate the cache:

	mips_icache_sync_all	Synchronize I-cache

	mips_icache_sync_range	Synchronize I-cache range

	mips_icache_sync_range_index (index ops)

	mips_dcache_wbinv_all	Write-back Invalidate D-cache

	mips_dcache_wbinv_range	Write-back Invalidate D-cache range

	mips_dcache_wbinv_range_index (index ops)

	mips_dcache_inv_range	Invalidate D-cache range

	mips_dcache_wb_range	Write-back D-cache range

This API handles both primary and secondary caches.

See mips/include/cache.h on the branch for complete details.

Now, as for the status of the branch.

	The following processors have had cache ops written:

		* R2000/R3000 (cache_r3k) -- light testing,
		  needs to be beat on a lot more to make
		  sure it's working.

		* R4000/R4400 (cache_r4k) -- seems to work for
		  systems with no L2 cache.  Needs testing on
		  systems with L2 cache, and needs a lot more
		  beating to make sure it's really okay.

		* R4600/R5000 (cache_r5k) -- currently broken
		  on RM52xx processors ... dealing with 2-way
		  index ops is probably broken.  Not yet tested
		  at all on R4600.

		  UPDATE: Takao Shinohara <shin@netbsd.org> looks
		  to have fixed the 2-way cache ops for RM52xx.
		  I haven't yet had a chance to verify this on
		  my P-5064, but will do so as soon as possible.
		  I am going to update the BRANCHES file to reflect
		  this.  (Thank you very much for working on the code!)

		* TX39 (cache_tx39) -- probably broken.  Have to
		  make sure all the code is there.  Not yet tested
		  at all.

		  UPDATE: UCHIYAMA Yasushi <uch@netbsd.org> has made
		  some changes to this code.  I don't know if the
		  code has been heavily tested, however.  If you could
		  verify that the TX39 code is working for you, I would
		  greatly appreciate it.

		* R5900 (cache_r5900) -- UCHIYAMA Yasushi has written
		  the R5900 cache ops and committed them to the branch.
		  I will be updating the document to reflect their
		  presence.  (Thank you very much for working on
		  the code!)

	The following ports have been updated to compile (and
	use optimized-for-processor bus_dma routines).  Those
	that hvae been tested and work are marked with [WORKING].

		* algor		[will use to test RM52xx fixes]

		* arc		[will use to rest R4400 no-L2]
				Seems to be working okay.  Will
				test more heavily soon.

		* pmax		[will use to test R3000/R4400 with-L2]
				Seems to be working okay.  Will
				test more heavily soon.

		* playstation2	[WORKING]
				It seems as if the bus_dmamap_sync
				routine could use some optimization,
				here.  I haven't read the R5900 manual,
				but I'm assuming that it has a
				virtually-indexed write-back cache?  Look
				at the algor bus_dma.c on the branch for an
				example.

		* hpcmips	[need verification that this is working]
				It seems as if the bus_dmamap_sync
				routine could use some optimization,
				here.  There are R4000 and TX39 style
				caches supported on this port, and there
				should be a bus_dmamap_sync routine for
				each supported cache configuration
				(including TX39 in write-back vs
				write-through).  Look at the pmax
				bus_dma.c on the branch for an example.

	Ports that are not yet fixed up to compile:

		* cobalt

		* mipsco

		* newsmips

		* sgimips	[will use to test R4600]

In order to make it easier for people to continue working on the
branch, I will be syncing the branch with -current again this coming
week.  Watch source-changes.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>