From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtMVt-000682-FA for qemu-devel@nongnu.org; Mon, 13 Apr 2009 09:47:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtMVn-00065W-0I for qemu-devel@nongnu.org; Mon, 13 Apr 2009 09:47:52 -0400 Received: from [199.232.76.173] (port=41178 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtMVl-00065I-CF for qemu-devel@nongnu.org; Mon, 13 Apr 2009 09:47:46 -0400 Received: from belushi.uits.indiana.edu ([129.79.1.188]:38597) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LtMVk-00040p-MD for qemu-devel@nongnu.org; Mon, 13 Apr 2009 09:47:44 -0400 Received: from mail-relay.iu.edu (burns.uits.indiana.edu [129.79.1.202]) by belushi.uits.indiana.edu (8.14.2/8.13.8/IU Messaging Team) with ESMTP id n3DDle4w024666 for ; Mon, 13 Apr 2009 09:47:40 -0400 Received: from [129.79.35.119] (nibbler.dlib.indiana.edu [129.79.35.119]) (authenticated bits=0) by mail-relay.iu.edu (8.14.2/8.13.8/IU Messaging Team Submission) with ESMTP id n3DDldW0027009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Apr 2009 09:47:39 -0400 Subject: Re: [Qemu-devel] [patch 2/2] qemu: switch pci device init functions to accept devfn From: Brian Wheeler In-Reply-To: <20090413133021.GA1065@amt.cnet> References: <20090413035311.009617911@amt.cnet> <20090413035340.296329700@amt.cnet> <200904131327.35201.paul@codesourcery.com> <20090413133021.GA1065@amt.cnet> Content-Type: text/plain Date: Mon, 13 Apr 2009 09:47:39 -0400 Message-Id: <1239630459.27750.3.camel@nibbler.dlib.indiana.edu> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Mon, 2009-04-13 at 10:30 -0300, Marcelo Tosatti wrote: > On Mon, Apr 13, 2009 at 01:27:34PM +0100, Paul Brook wrote: > > On Monday 13 April 2009, Marcelo Tosatti wrote: > > > Some pci device initialization functions do not accept a devfn parameter, > > > but instead use "-1", which caused pci_register_device to find the first > > > free slot on the given bus. > > > > > > Have them accept a "devfn" parameter, and use the newly introduced > > > pci_bus_assign_dev_addr function on platform init code to perform > > > the "first free" enumeration. > > > > I don't see how this is better. If anything we want the platform code to get > > smaller, not larger. > > Paul, > > This is a intermediate step. Later you'd get rid of > pci_bus_assign_dev_addr in platform code. > > Ideally you'd have (I think): > > - generic machine initialization code fills in details of pci device > address in pci device structure (or a temporary placeholder) taken from > machine description (optionally auto assigns from a free slot). > - pci driver init functions take generic device pointer as an > argument (either containing the pre allocated pci device or temporary > placeholder), and pass that to pci_register_device, which does > actual registration of pci device on particular bus. > > Does that make sense? > > A benefit of the proposed patch is that it moves assumptions about pci > device address assignment from drivers up to platform code. Later you'd > remove that from platform code to devtree data. > Does this mean that there would be a mechanism for a platform to map the pci memory address to a platform specific linear address? Alpha uses 0x8000000000 + (0x20000000 * bus) + address to determine where the pci memory is mapped in the cpu address space... Brian