Re: bus_dmamap_sync() for uhci(4)

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

On Mon, Jun 16, 2008 at 08:54:37AM -0400, Michael Lorenz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> On Jun 16, 2008, at 07:20, Manuel Bouyer wrote:
> >On Sat, Jun 14, 2008 at 10:13:42PM -0400, Michael Lorenz wrote:
> >>[...]
> >>>....................................................umass0: BBB
> >>>reset failed, TIMEOUT
> >>>umass0: BBB bulk-in clear stall failed, TIMEOUT
> >>>umass0: BBB bulk-out clear stall failed, TIMEOUT
> >>>umass0: Invalid CSW: tag 1674 should be 12675
> >>>umass0: BBB reset failed, TIMEOUT
> >>
> >>I saw similar errors on sgimips, Manuel's latest patch fixed them
> >>here, although I get different problems now ( which look a bit like
> >>missing wbflush()es after filling DMA buffers )
> >
> >But all DMA buffers should be mapped uncacheable ...
> 
> Yes, but the CPU still has write buffers that need to be flushed.
> 
> >I see that the sgimips bus_dmamap_sync() uses wmb(), which I assume  
> >is a
> >write memory barrier. Does it also act as a barrier for reads ? Can a
> >read be reordered ahead of another read or write on this CPU ?
> 
> At least this R5k reorders memory accesses all the time, I ran into  
> that a few time when hacking crmfb and when writing the crime driver  
> for XFree86. When we fill a DMA buffer to be sent to some device we  
> will need to wbflush() ( or __asm("sync"); ) before doing anything  
> with it. Same for register writes, if order is important you need to  
> sprinkle barriers all over the place.

OK, there is a wbflush() in _bus_dmamap_sync_mips3() which is always called,
so this should be enough (unless I missed bus_dmamap_sync() calls in some
places).

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