From owner-svn-src-head@FreeBSD.ORG Mon Mar 5 19:25:51 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3FAE106566B; Mon, 5 Mar 2012 19:25:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 834A88FC15; Mon, 5 Mar 2012 19:25:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 1A25F46B52; Mon, 5 Mar 2012 14:25:51 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 756DAB955; Mon, 5 Mar 2012 14:25:50 -0500 (EST) From: John Baldwin To: Marius Strobl Date: Mon, 5 Mar 2012 14:17:38 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201203022038.q22Kc5vd046376@svn.freebsd.org> <201203021718.38092.jhb@freebsd.org> <20120302223807.GI55090@alchemy.franken.de> In-Reply-To: <20120302223807.GI55090@alchemy.franken.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203051417.38470.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 05 Mar 2012 14:25:50 -0500 (EST) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r232403 - in head/sys: dev/acpica dev/cardbus dev/pci powerpc/ofw sparc64/pci X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:25:52 -0000 On Friday, March 02, 2012 5:38:07 pm Marius Strobl wrote: > On Fri, Mar 02, 2012 at 05:18:37PM -0500, John Baldwin wrote: > > On Friday, March 02, 2012 4:45:52 pm Marius Strobl wrote: > > > On Fri, Mar 02, 2012 at 08:38:05PM +0000, John Baldwin wrote: > > > > Author: jhb > > > > Date: Fri Mar 2 20:38:04 2012 > > > > New Revision: 232403 > > > > URL: http://svn.freebsd.org/changeset/base/232403 > > > > > > > > Log: > > > > - Add a bus_dma tag to each PCI bus that is a child of a Host-PCI bridge. > > > > The tag enforces a single restriction that all DMA transactions must not > > > > cross a 4GB boundary. Note that while this restriction technically only > > > > applies to PCI-express, this change applies it to all PCI devices as it > > > > is simpler to implement that way and errs on the side of caution. > > > > > > Hrm, wouldn't it have been more appropriate to implement this in the > > > Host-PCI bridges instead? Probably for anything but x86 this would > > > allow to easily distinguish at least between PCI and PCI-Express capable > > > bus hierarchies and would move the PAE workaround to the MD bits to > > > where it belongs. > > > > The PAE workaround is dying as I've already fixed HEAD to make boundary arguments > > use a bus_addr_t. However, I committed it in this fashion so it can be MFC'd > > since I can't merge the boundary KBI change. > > > > The reason I did not do this in the Host-PCI bridge drivers is that we would have > > to do this in umpteen different drivers, and all for a change that is mandated by > > the PCI spec and not specific to the various specs the Host-PCI bridge drivers > > all cater to (OFW, ACPI, MPTable, various and sundry embedded platforms, etc.). > > > > Well, on !x86 we don't have generic Host-PCI bridge drivers based on > what you call specs here, but rather specific drivers for individual > Host-PCI, Host-PCI-X and Host-PCI-Express chips. Whether the PCI* > buses beneath these are enumerated using FDT, OFW etc. doesn't really > matter in this context. Yes, but the 4GB limit is also not specific to the things that make psycho(4) differ from schizo(4). We could at least have a common helper routine to create the tag, but we'd still have a lot of duplicated code to implement N bus_get_dma_tag methods, etc. That type of setup is just begging to have some random Host-PCI bridge driver forget to include the right logic. It seems simpler and safer to do it in one central place, so it is always correct. Also, while PCI-express is the only type of PCI whose specification enforces a 4GB boundary, we have seen non-PCI-e PCI devices also need a 4GB boundary (e.g. bge(4) devices behind an AMD HyperTransport PCI-X bridge). Given all that, I think having older, non-PCI-e devices possibly use an extra S/G element in the rare case that a transaction crosses a 4GB boundary (which won't even happen with the 32-bit DVMA on sparc64 IIUC), is an ok tradeoff to ensure this constraint is correctly defined for all platforms, including future chipsets. -- John Baldwin