On Fri, 15 May 2009 09:05:31 -0600 (MDT) "M. Warner Losh" <i...@bsdimp.com> mentioned:
> 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... > I don't think there're any reordering possible on at91 platform, though I need to check first. The bus_space_barrier call is currently a no-op on arm platforms, so this modifications were mostly to make the code more correct theoretically then fixing any possible real-world issues. PDC is the entirely another thing, so it need to be checked separately. EMAC doesn't use PDC but a real DMA implementation. -- Stanislav Sedov ST4096-RIPE !DSPAM:4a0dc041994294531918519! _______________________________________________ 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"
