Re: bus_dmamap_sync() for uhci(4)

[Michael Lorenz <macallan%NetBSD.org@localhost>]

-----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.

have fun
Michael


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSFZijcpnzkX8Yg2nAQKJ3wf/e0oamO4lQmCg16aPYN3W4RiOV8W+CiMd
TQkqPZ37GA39oTyOboy/GDHfFg3VuMAKw6BU1qfhzzc5RDTzU2DLt0vVMObPKxxB
CtPXY7DEUl5amOReGRd+HQGA85+1KHjTDWyVvZV0poPc+q+bwUIucrm6whgwJF3x
thTBqyJpSX2GA9Z+U/Ltyb4DutbVsT60Y7bB1v5GJlWA4NEWlbq2WlJtzOWoQNlb
H1o/r/VlUwkd0ttliZLm4IFIyYomIXLVErxn3zAkoQ/Ug4Pi56/P13sqqfy5bLBk
LXC+N+PVdDu1C1rNBUa7RMu1Bv4Ywdw+s4/eBk+2JTbUa5magEbLuw==
=/7Jt
-----END PGP SIGNATURE-----