In message: <20090515141642.ebc06b59.s...@freebsd.org>
Stanislav Sedov <s...@freebsd.org> writes:
: On Thu, 14 May 2009 23:35:36 -0600 (MDT)
: "M. Warner Losh" <i...@bsdimp.com> mentioned:
:
: > In message: <20090515092205.6f6d06fa.s...@freebsd.org>
: > Stanislav Sedov <s...@freebsd.org> writes:
: > : On Thu, 14 May 2009 21:37:12 -0600 (MDT)
: > : "M. Warner Losh" <i...@bsdimp.com> mentioned:
: > :
: > : > In message: <200905122114.n4cleag9033...@svn.freebsd.org>
: > : > Stanislav Sedov <s...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
