[moved to port-mips]

In article <20040412150800.GH294@rezrov.net> on source-changes
wileyc@rezrov.net wrote:

> On Mon, Apr 12, 2004 at 11:49:20PM +0900, Izumi Tsutsui wrote:
> 
> > Umm, the latter is not streamline but just backout...
> 
> Er, isn't arch/mips/mips/* supposed to be canonical for all mips targets?
> Looking at the code involved, I can't see any good reason to prefer the
> contortions in the previous sgimips-specific routine ... hence the term
> "streamline".

Maybe it was supposed, but I guess it is not finished (or is suspended?)
for now.

Actually, wbinv op for BUS_DMASYNC_PREREAD is too conservative
but only inv op for PREREAD is not enough (so they are #if'ed out).
I think the previous sgimips code which I committed does the right
thing, and I just committed the change only port I tested.
arc also has the same code, but I have no machines which use
MI mips bus_dma.c.

> > (though I wouldn't object if the previous code causes any problem)
> 
> Well, I'm trying to track down weird problems when one uses a CD-ROM on IP32.
> My working hypothesis was that the bus_space DMA code was a bit chigau, so
> I was doing a line-by-line diff between the MD and MI code.  The changes as
> committed unfortunately have not fixed the core problem, but one must fix
> bugs as they are encountered ...

chigau? :-)
Yes, they are different, but I'd like to know what is actually wrong
in the previous code, or what problem actually is fixed on your case.
(i.e. I think MI code should be changed in that case)

> (btw, there are several instances in the MD code where we're declaring
> variables as vaddr where in the MI equivalent they are paddr, which indicates
> a bit of confusion as to what that code was doing on a given platform although
> the typedefs involved result in the same type)

Would you please show an example?
At least, some mips ports have 64bit paadr_t even though their vaddr_t
is (still) 32bit. That's the reason we have both vaddr_t and
paddr_t, but some old code might have some bugs in the usage of them.
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp