Folks...

I think the bugs have been shaken out of the thorpej-mips-cache
branch, and that it's in good enough shape to bring down onto
the trunk.  Here is the current state of the branch:

	The following processors have had cache ops
	written:

		* R2000/R3000 (cache_r3k) -- briggs@netbsd.org
		  has tested this on a DECstation 5000/25.

		* R4000/R4400 (cache_r4k) -- mhitch@netbsd.org
		  tracked down a bug, which has been fixed.

		  Confirmed working on R4000-with-L2.

		  Confirmed working on R4400-no-L2 and
		  R4400-with-L2.

		* R4600/R5000 (cache_r5k) -- shin@netbsd.org
		  has committed fixes to this code.

		  Confirmed working on R4600 v2 (SGI IP-22 with
		  no SysAD L2 cache).

		  Confirmed working on RM5260 (Algorithmics P-5064).

		* TX39 (cache_tx39) -- uch@netbsd.org has
		  committed fixes to this code.  Awaiting
		  confirmation that it is working properly.

		* R5900 (cache_r5900) -- uch@netbsd.org has
		  written this code and tested it on a
		  PlayStation 2.

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

		* algor		[WORKING]

		* arc		[WORKING]

		* pmax		[WORKING]

		* playstation2	[WORKING]
				Needs optimized bus_dmamap_sync().

		* hpcmips	[need verification that this is working]
				Needs optimized bus_dmamap_sync().
				Been waiting for confirmation for a few
				days, but since hpcmips developers committed
				changes to the hpcmips port on the branch,
				I am going to assume that it's working fine.
				If that is not the case, the port can be
				fixed on the trunk.

		* sgimips	[WORKING]
				Needs optimized bus_dmamap_sync().

		* cobalt	[need testing]
				Don't expect problems, here.  Same
				processor as P-5064.

		* mipsco	[need testing]
				Don't expect problems, here.  Same
				processor as DECstation 5000/25.

		* newsmips	[need testing]
				Don't expect problems, here.  Same
				processor as DECstation 5000/25 and
				DECstation 5000/260.

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