svn commit: r192027 - head/sys/arm/at91

[M. Warner Losh]

In message: <20090515141642.ebc06b59.stas at FreeBSD.org>
            Stanislav Sedov <stas at FreeBSD.org> writes:
: On Thu, 14 May 2009 23:35:36 -0600 (MDT)
: "M. Warner Losh" <imp at bsdimp.com> mentioned:
: 
: > In message: <20090515092205.6f6d06fa.stas at FreeBSD.org>
: >             Stanislav Sedov <stas at FreeBSD.org> writes:
: > : On Thu, 14 May 2009 21:37:12 -0600 (MDT)
: > : "M. Warner Losh" <imp at bsdimp.com> mentioned:
: > : 
: > : > In message: <200905122114.n4CLEag9033208 at svn.freebsd.org>
: > : >             Stanislav Sedov <stas at FreeBSD.org> writes:
: > : > : @@ -926,6 +937,7 @@ atestart_locked(struct ifnet *ifp)
: > : > :  		 * tell the hardware to xmit the packet.
: > : > :  		 */
: > : > :  		WR4(sc, ETH_TAR, segs[0].ds_addr);
: > : > : +		BARRIER(sc, ETH_TAR, 8, BUS_SPACE_BARRIER_WRITE);
: > : > :  		WR4(sc, ETH_TCR, segs[0].ds_len);
: > : > 
: > : > Why is a barrier needed here?
: > : > 
: > : Writing the TCR register triggers the transmit, so it had to be written
: > : strongly after the TAR register. That's why I added the barrier here.
: > 
: > Then shouldn't the barrier be after TCR write?  Or does this ensure
: > that the write is before TCR?
: > 
: 
: Yeah, this barrier is to ensure that the TCR register gets written after the
: TAR register has been written, not before. I don't think an additional barrier
: is needed after the TCR write.

Did this fix an observed bug, or is it theoretical?  None of Atmel's
code does this, but maybe we turn on some flag that reorders writes.
On the other hand, I've seen some minor flakiness from time to time
that could be explained by reordering....

There's likely a bunch of other places where something like this may
be needed.  The PDC has size/address information, followed by an
enable bit.  The MCI device has some similar weirdness as well...

Warner