tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bus_dmamap_sync() for uhci(4)

On Mon, Jun 16, 2008 at 08:54:37AM -0400, Michael Lorenz wrote:
> 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

Manuel Bouyer, LIP6, Universite Paris VI.  
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index