From owner-svn-src-all@FreeBSD.ORG Fri May 15 19:31:13 2009 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A9E11065676; Fri, 15 May 2009 19:31:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BC7098FC23; Fri, 15 May 2009 19:31:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n4FJT9xZ069926; Fri, 15 May 2009 13:29:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 15 May 2009 13:29:18 -0600 (MDT) Message-Id: <20090515.132918.833254741.imp@bsdimp.com> To: stas@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090515231922.fb760af4.stas@FreeBSD.org> References: <20090515141642.ebc06b59.stas@FreeBSD.org> <20090515.090531.932035381.imp@bsdimp.com> <20090515231922.fb760af4.stas@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r192027 - head/sys/arm/at91 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 19:31:13 -0000 In message: <20090515231922.fb760af4.stas@FreeBSD.org> Stanislav Sedov writes: : On Fri, 15 May 2009 09:05:31 -0600 (MDT) : "M. Warner Losh" mentioned: : : > In message: <20090515141642.ebc06b59.stas@FreeBSD.org> : > Stanislav Sedov writes: : > : On Thu, 14 May 2009 23:35:36 -0600 (MDT) : > : "M. Warner Losh" mentioned: : > : : > : > In message: <20090515092205.6f6d06fa.stas@FreeBSD.org> : > : > Stanislav Sedov writes: : > : > : On Thu, 14 May 2009 21:37:12 -0600 (MDT) : > : > : "M. Warner Losh" mentioned: : > : > : : > : > : > In message: <200905122114.n4CLEag9033208@svn.freebsd.org> : > : > : > Stanislav Sedov 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. True. : PDC is the entirely another thing, so it need to be checked separately. : EMAC doesn't use PDC but a real DMA implementation. Yes. Understood. Just thinking of other places this might matter. Any idea if this matters on the AVR32? Then again, the built-in devices are mapped into uncached memory, so maybe it just doesn't matter :). Warner