svn commit: r192027 - head/sys/arm/at91
Stanislav Sedov
stas at FreeBSD.org
Fri May 15 19:19:36 UTC 2009
On Fri, 15 May 2009 09:05:31 -0600 (MDT)
"M. Warner Losh" <imp at bsdimp.com> mentioned:
> 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...
>
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:4a0dc042994291521116252!
More information about the svn-src-head
mailing list