In my infinite spare time, I've been hacking on the SGIMIPS code to get it
to work on my Indigo2.  I've now got chunks of a Seeq driver working, but 
in getting it working I stumbled accross a potential bus_dma issue.

Since I'm not a MIPS expert, I thought I'd ask the crowd here before I go
snooping in the code...

The problem I had was with mbufs being passed to the Seeq for transmit: the
mbuf data wasn't being flushed from cache (if I read the mbuf via KSEG1, I
got garbage, whereas a read of the mbuf via KSEG0 got the right data).

Cribbing from one of the other MIPS-based bus_dma implementations, I changed
the cache ops in bus_dma_sync() in the following manner to get things going:

--- bus.c       2000/06/29 07:44:10     1.4
+++ bus.c       2001/03/12 17:42:08
@@ -673,10 +673,10 @@
                    "(0x%lx..0x%lx) ...", i, addr + offset,
                    addr + offset + minlen - 1);
 #endif
-#if 1
+#if 0
                MachFlushDCache(addr + offset, minlen);
 #endif
-#if 0
+#if 1
                mips3_HitFlushDCache(map->dm_segs[i]._ds_vaddr + offset, len);
 #endif
 #if 0

Can someone enlighten me why the MachFlushDCache() was used rather than 
mips3_HitFlushDCache?  Was this just an attempt to avoid creating MIPS1
vs. MIPS3 versions?

Also, I'm curious why the MachFlushDCache() call didn't seem to DTRT.

I'll go dig in the code later, but thanks for any clues,
--rafal

----
Rafal Boni                                               rafal.boni@eDial.com
 PGP key C7D3024C, print EA49 160D F5E4 C46A 9E91  524E 11E0 7133 C7D3 024C
    Need to get a hold of me?  http://800.eDial.com/rafal.boni@eDial.com