Re: bus_dmamap_sync() for uhci(4)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Jun 09, 2008 at 05:44:18PM -0400, Michael Lorenz wrote:
> >>>BTW, I suspect the lack of memory read/write barrier are the  
> >>>cause of
> >>>the issues I'm seeing on x86 too (this is why I started this work).
> >>
> >>Hmm, I need to read sgimips' bus_dma stuff again but since other
> >>drivers work it can't be all that borked.
> >
> >Sure it was not my point. It's most probably an issue with the
> >_sync() calls I added. But as the memory referred to by these calls  
> >should be
> >mapped uncached anyway, I don't understand how they could make a  
> >difference.
> 
> Something's weird here - I added the KASSERT you asked for, didn't  
> add ehci back but the kernel found the USB disk this time. It did  
> hang while probing a low speed device though ( sat there for a minute  
> or so ), when I unplugged it the machine booted normally and so far  
> bonnie's been working for about 10 minutes without any trouble. For  
> some reason it took a lot longer than on my other machines to find  
> the USB disk ( ~15 seconds vs. less than one )

So the KASSERT didn't fire, which means that the memory here is mapped
uncached. In this case, the bus_dmamap_sync() should just add a wmb() in
the path, which should make things really worse (it's _bus_dmamap_sync_mips3()
which is used on the O2, right ?).

when using BUS_DMAMAP_COHERENT, is the memory region completely uncached
on sgimips, or do we still need to invalidate the cache line before a
read ?

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--