From owner-freebsd-new-bus@FreeBSD.ORG Mon Oct 2 17:24:03 2006 Return-Path: X-Original-To: freebsd-new-bus@freebsd.org Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00F3D16A4F1 for ; Mon, 2 Oct 2006 17:24:03 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6168043D6A for ; Mon, 2 Oct 2006 17:24:00 +0000 (GMT) (envelope-from john@baldwin.cx) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k92HNpC0017897 for ; Mon, 2 Oct 2006 13:23:55 -0400 (EDT) (envelope-from john@baldwin.cx) From: John Baldwin To: freebsd-new-bus@freebsd.org Date: Mon, 2 Oct 2006 13:23:50 -0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610021323.50997.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 02 Oct 2006 13:23:56 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1973/Mon Oct 2 11:18:33 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Subject: Properly managing sub-allocations X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 17:24:03 -0000 I'm trying to cleanup a few things in apci and I ran into what I think is a new-bus architecture issue. Specifically, acpi likes to allocate system resource resources from its parent, and then turn around and sub-alloc those out to children. This mostly works fine except for the bus space details of the bus tag and bus handle. Currently acpi(4) just copies the tag from the corresponding resource from the parent and sets the handle to the start of the resource. This just happens to work currently because i386 and amd64 use the start of the resource for the handle for SYS_RES_IO and overwrite the handle in nexus_activate_resource() for SYS_RES_MEMORY. This does add some ugliness though in that acpi needs to go find the parent resouce to copy the bus tag. However, it's current algorithm wouldn't work in general (PC98 needs to alloc bus handles, and it does so in nexus_alloc_resource() for example). To solve this, I think we need to stop setting bus tags and handles in bus_alloc_resource(). One solution might be to add a new bus method to set those for a resource, but I think the better solution would be to set the bus tags and handles in bus_activate_resource(). It already sort of does this for some cases (SYS_RES_MEMORY on x86 for example) and will work with the existing ACPI model (it already passes up activate_resource to the parent, so we would just have to remove the explicit setting of the bus tag and handle). I actually wonder if this isn't how things are supposed to be in the first place and that the current aberrations are just bugs? -- John Baldwin From owner-freebsd-new-bus@FreeBSD.ORG Mon Oct 2 17:42:46 2006 Return-Path: X-Original-To: freebsd-new-bus@freebsd.org Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E96B16A40F for ; Mon, 2 Oct 2006 17:42:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BD6343D46 for ; Mon, 2 Oct 2006 17:42:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k92HekYT078501; Mon, 2 Oct 2006 11:40:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 02 Oct 2006 11:39:54 -0600 (MDT) Message-Id: <20061002.113954.756907493.imp@bsdimp.com> To: john@baldwin.cx From: "M. Warner Losh" In-Reply-To: <200610021323.50997.john@baldwin.cx> References: <200610021323.50997.john@baldwin.cx> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 02 Oct 2006 11:40:46 -0600 (MDT) Cc: freebsd-new-bus@freebsd.org Subject: Re: Properly managing sub-allocations X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 17:42:46 -0000 In message: <200610021323.50997.john@baldwin.cx> John Baldwin writes: : I'm trying to cleanup a few things in apci and I ran into what I think is a : new-bus architecture issue. Specifically, acpi likes to allocate system : resource resources from its parent, and then turn around and sub-alloc those : out to children. This mostly works fine except for the bus space details of : the bus tag and bus handle. Currently acpi(4) just copies the tag from the : corresponding resource from the parent and sets the handle to the start of : the resource. This just happens to work currently because i386 and amd64 use : the start of the resource for the handle for SYS_RES_IO and overwrite the : handle in nexus_activate_resource() for SYS_RES_MEMORY. This does add some : ugliness though in that acpi needs to go find the parent resouce to copy the : bus tag. However, it's current algorithm wouldn't work in general (PC98 : needs to alloc bus handles, and it does so in nexus_alloc_resource() for : example). : : To solve this, I think we need to stop setting bus tags and handles in : bus_alloc_resource(). One solution might be to add a new bus method to set : those for a resource, but I think the better solution would be to set the bus : tags and handles in bus_activate_resource(). It already sort of does this : for some cases (SYS_RES_MEMORY on x86 for example) and will work with the : existing ACPI model (it already passes up activate_resource to the parent, so : we would just have to remove the explicit setting of the bus tag and handle). : : I actually wonder if this isn't how things are supposed to be in the first : place and that the current aberrations are just bugs? I think you are right. Thinking about it, you can't access the resources until you've activated them... However, this may break some existing drivers that allocate a BAR, peek at its type and then either activate it or allocate another BAR... The TAG is valid, but the handle isn't. This specific problem will never happen in pc98, since there are no ACPI pc98 machines and can never be. Warner From owner-freebsd-new-bus@FreeBSD.ORG Mon Oct 2 18:19:58 2006 Return-Path: X-Original-To: freebsd-new-bus@freebsd.org Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2537316A47E for ; Mon, 2 Oct 2006 18:19:58 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AD5243D68 for ; Mon, 2 Oct 2006 18:19:53 +0000 (GMT) (envelope-from john@baldwin.cx) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k92IJj78018231; Mon, 2 Oct 2006 14:19:45 -0400 (EDT) (envelope-from john@baldwin.cx) From: John Baldwin To: freebsd-new-bus@freebsd.org Date: Mon, 2 Oct 2006 14:03:50 -0400 User-Agent: KMail/1.9.1 References: <200610021323.50997.john@baldwin.cx> <20061002.113954.756907493.imp@bsdimp.com> In-Reply-To: <20061002.113954.756907493.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610021403.50339.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 02 Oct 2006 14:19:45 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1973/Mon Oct 2 11:18:33 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: Properly managing sub-allocations X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 18:19:58 -0000 On Monday 02 October 2006 13:39, M. Warner Losh wrote: > In message: <200610021323.50997.john@baldwin.cx> > John Baldwin writes: > : I'm trying to cleanup a few things in apci and I ran into what I think is a > : new-bus architecture issue. Specifically, acpi likes to allocate system > : resource resources from its parent, and then turn around and sub-alloc those > : out to children. This mostly works fine except for the bus space details of > : the bus tag and bus handle. Currently acpi(4) just copies the tag from the > : corresponding resource from the parent and sets the handle to the start of > : the resource. This just happens to work currently because i386 and amd64 use > : the start of the resource for the handle for SYS_RES_IO and overwrite the > : handle in nexus_activate_resource() for SYS_RES_MEMORY. This does add some > : ugliness though in that acpi needs to go find the parent resouce to copy the > : bus tag. However, it's current algorithm wouldn't work in general (PC98 > : needs to alloc bus handles, and it does so in nexus_alloc_resource() for > : example). > : > : To solve this, I think we need to stop setting bus tags and handles in > : bus_alloc_resource(). One solution might be to add a new bus method to set > : those for a resource, but I think the better solution would be to set the bus > : tags and handles in bus_activate_resource(). It already sort of does this > : for some cases (SYS_RES_MEMORY on x86 for example) and will work with the > : existing ACPI model (it already passes up activate_resource to the parent, so > : we would just have to remove the explicit setting of the bus tag and handle). > : > : I actually wonder if this isn't how things are supposed to be in the first > : place and that the current aberrations are just bugs? > > I think you are right. Thinking about it, you can't access the > resources until you've activated them... > > However, this may break some existing drivers that allocate a BAR, > peek at its type and then either activate it or allocate another > BAR... The TAG is valid, but the handle isn't. They generally peak at the BAR register itself though, not the value of rman_get_bustag() though, right? > This specific problem will never happen in pc98, since there are no > ACPI pc98 machines and can never be. Yeah, but I can cleanup the stuff in ACPI a good bit if I can get it to stop peeking at the "real" resource to get the bus tag. Also, I think fixing this would be important for a driver that wanted to sub-alloc its resources out to children (like vgapci, which currently cheats on that). -- John Baldwin From owner-freebsd-new-bus@FreeBSD.ORG Mon Oct 2 19:42:14 2006 Return-Path: X-Original-To: freebsd-new-bus@freebsd.org Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 901D916A40F for ; Mon, 2 Oct 2006 19:42:14 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C13A43D55 for ; Mon, 2 Oct 2006 19:42:13 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k92JguQJ079606; Mon, 2 Oct 2006 13:42:57 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 02 Oct 2006 13:42:04 -0600 (MDT) Message-Id: <20061002.134204.-749250271.imp@bsdimp.com> To: john@baldwin.cx From: "M. Warner Losh" In-Reply-To: <200610021403.50339.john@baldwin.cx> References: <200610021323.50997.john@baldwin.cx> <20061002.113954.756907493.imp@bsdimp.com> <200610021403.50339.john@baldwin.cx> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 02 Oct 2006 13:42:57 -0600 (MDT) Cc: freebsd-new-bus@freebsd.org Subject: Re: Properly managing sub-allocations X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 19:42:14 -0000 In message: <200610021403.50339.john@baldwin.cx> John Baldwin writes: : > However, this may break some existing drivers that allocate a BAR, : > peek at its type and then either activate it or allocate another : > BAR... The TAG is valid, but the handle isn't. : : They generally peak at the BAR register itself though, not the value of : rman_get_bustag() though, right? Some do, some get the resource and look at it. There's a lot of variance here. Do you put knowledge of how to decode PCI bars into every driver, or do you let the pci bus take care of it? Since the knowledge is nearly trivial, different people decide differenly. It is still a technique that has been used, and you'll need to be careful to make sure you don't break anything. After all, 0 is a valid I/O tag and it is also the default value... : > This specific problem will never happen in pc98, since there are no : > ACPI pc98 machines and can never be. : : Yeah, but I can cleanup the stuff in ACPI a good bit if I can get it : to stop peeking at the "real" resource to get the bus tag. Also, I : think fixing this would be important for a driver that wanted to : sub-alloc its resources out to children (like vgapci, which : currently cheats on that). Good point. I don't dispute this is a good thing, just that it will solve a problem we're currently having. Given the push for embedded, this is a problem worth solving. Warner From owner-freebsd-new-bus@FreeBSD.ORG Mon Oct 2 20:21:42 2006 Return-Path: X-Original-To: freebsd-new-bus@freebsd.org Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE66F16A403 for ; Mon, 2 Oct 2006 20:21:42 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3575143D82 for ; Mon, 2 Oct 2006 20:20:34 +0000 (GMT) (envelope-from john@baldwin.cx) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k92KKVkZ019221; Mon, 2 Oct 2006 16:20:32 -0400 (EDT) (envelope-from john@baldwin.cx) From: John Baldwin To: freebsd-new-bus@freebsd.org Date: Mon, 2 Oct 2006 16:20:43 -0400 User-Agent: KMail/1.9.1 References: <200610021323.50997.john@baldwin.cx> <200610021403.50339.john@baldwin.cx> <20061002.134204.-749250271.imp@bsdimp.com> In-Reply-To: <20061002.134204.-749250271.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610021620.44185.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 02 Oct 2006 16:20:32 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1973/Mon Oct 2 11:18:33 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: Properly managing sub-allocations X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 20:21:42 -0000 On Monday 02 October 2006 15:42, M. Warner Losh wrote: > In message: <200610021403.50339.john@baldwin.cx> > John Baldwin writes: > : > However, this may break some existing drivers that allocate a BAR, > : > peek at its type and then either activate it or allocate another > : > BAR... The TAG is valid, but the handle isn't. > : > : They generally peak at the BAR register itself though, not the value of > : rman_get_bustag() though, right? > > Some do, some get the resource and look at it. There's a lot of > variance here. Do you put knowledge of how to decode PCI bars into > every driver, or do you let the pci bus take care of it? Since the > knowledge is nearly trivial, different people decide differenly. It > is still a technique that has been used, and you'll need to be careful > to make sure you don't break anything. After all, 0 is a valid I/O > tag and it is also the default value... Err, how can code examine the actual bus tag value of a non-active resource? By definition it's set an opaque MD value. You can't compare it against SYS_RES_MEMORY for example. On i386 systems it happens to be an int, on some other systems (alpha maybe?) I think it can be a pointer to a structure of function pointers for the different bus space operations. I don't think any MI code should ever be examining the bus tag or handle except to pass them as opaque parameters to bus_space_*(). -- John Baldwin From owner-freebsd-new-bus@FreeBSD.ORG Mon Oct 2 21:09:18 2006 Return-Path: X-Original-To: freebsd-new-bus@freebsd.org Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAAF616A403 for ; Mon, 2 Oct 2006 21:09:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47F1A43D46 for ; Mon, 2 Oct 2006 21:09:18 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k92L94sc080475; Mon, 2 Oct 2006 15:09:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 02 Oct 2006 15:08:12 -0600 (MDT) Message-Id: <20061002.150812.151470856.imp@bsdimp.com> To: john@baldwin.cx From: "M. Warner Losh" In-Reply-To: <200610021620.44185.john@baldwin.cx> References: <200610021403.50339.john@baldwin.cx> <20061002.134204.-749250271.imp@bsdimp.com> <200610021620.44185.john@baldwin.cx> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 02 Oct 2006 15:09:05 -0600 (MDT) Cc: freebsd-new-bus@freebsd.org Subject: Re: Properly managing sub-allocations X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 21:09:18 -0000 In message: <200610021620.44185.john@baldwin.cx> John Baldwin writes: : On Monday 02 October 2006 15:42, M. Warner Losh wrote: : > In message: <200610021403.50339.john@baldwin.cx> : > John Baldwin writes: : > : > However, this may break some existing drivers that allocate a BAR, : > : > peek at its type and then either activate it or allocate another : > : > BAR... The TAG is valid, but the handle isn't. : > : : > : They generally peak at the BAR register itself though, not the value of : > : rman_get_bustag() though, right? : > : > Some do, some get the resource and look at it. There's a lot of : > variance here. Do you put knowledge of how to decode PCI bars into : > every driver, or do you let the pci bus take care of it? Since the : > knowledge is nearly trivial, different people decide differenly. It : > is still a technique that has been used, and you'll need to be careful : > to make sure you don't break anything. After all, 0 is a valid I/O : > tag and it is also the default value... : : Err, how can code examine the actual bus tag value of a non-active resource? : By definition it's set an opaque MD value. You can't compare it against : SYS_RES_MEMORY for example. On i386 systems it happens to be an int, on some : other systems (alpha maybe?) I think it can be a pointer to a structure of : function pointers for the different bus space operations. I don't think any : MI code should ever be examining the bus tag or handle except to pass them as : opaque parameters to bus_space_*(). Actually, you are right. I'm confusing success/failure of allocating a I/O and/or Memory bar with this... Warner From owner-freebsd-new-bus@FreeBSD.ORG Fri Oct 6 07:34:38 2006 Return-Path: X-Original-To: freebsd-new-bus@freebsd.org Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51F9316A407 for ; Fri, 6 Oct 2006 07:34:38 +0000 (UTC) (envelope-from namaskar_alok@yahoo.co.in) Received: from web8913.mail.in.yahoo.com (web8913.mail.in.yahoo.com [203.84.221.145]) by mx1.FreeBSD.org (Postfix) with SMTP id 25C0043D49 for ; Fri, 6 Oct 2006 07:34:36 +0000 (GMT) (envelope-from namaskar_alok@yahoo.co.in) Received: (qmail 71732 invoked by uid 60001); 6 Oct 2006 07:34:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C8J8lzhsV6Sb4cXa63LIlZ8iYLxycjQYsEdjcGE1bfRKjAlz/8I/GrJB5kcUY5dWirrKxTMS/XkhurFTovV+ySi//hJgcPG1QcmVBk53F0c9t1S1c87KppJrfbAbTRaJN+SiAdvdNKqIes4/tj54q7iPoEOQoBQY1rAAUwsGLqM= ; Message-ID: <20061006073434.71730.qmail@web8913.mail.in.yahoo.com> Received: from [220.225.33.101] by web8913.mail.in.yahoo.com via HTTP; Fri, 06 Oct 2006 00:34:34 PDT Date: Fri, 6 Oct 2006 00:34:34 -0700 (PDT) From: Alok Barsode To: freebsd-new-bus@freebsd.org In-Reply-To: <20060930.124334.-432842007.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Device enumeration process X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2006 07:34:38 -0000 Hi, Thanks for ur earliers replies. They helped me a lot in understanding the newbus architecture. I am involved in a freeBSD port to a freescale board. I still had a few doubts: I am looking at the autoconf.c file for the i386 architecture. When i/o configuration is in progress during startup, are the drivers for specific busses alreay assosciated with them or the association happens at run time ? for example : when nexus is being attached to root_bus, the method devclass_find_internal("nexus", 0, TRUE) is invoked(in method make_device).Now does a nexus devclass already exist ( it is created through the macro DRIVER_MODULE(nexus, root, nexus_driver, nexus_devclass, 0, 0);) or it is created at runtime ? if it is created at runtime how the nexus_driver get assciated with nexus? Thanks, Alok. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-new-bus@FreeBSD.ORG Fri Oct 6 15:45:21 2006 Return-Path: X-Original-To: freebsd-new-bus@freebsd.org Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0886E16A403 for ; Fri, 6 Oct 2006 15:45:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8615F43D45 for ; Fri, 6 Oct 2006 15:45:20 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k96FhLCi049279; Fri, 6 Oct 2006 09:43:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 06 Oct 2006 09:42:31 -0600 (MDT) Message-Id: <20061006.094231.-1572283957.imp@bsdimp.com> To: namaskar_alok@yahoo.co.in From: "M. Warner Losh" In-Reply-To: <20061006073434.71730.qmail@web8913.mail.in.yahoo.com> References: <20060930.124334.-432842007.imp@bsdimp.com> <20061006073434.71730.qmail@web8913.mail.in.yahoo.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 06 Oct 2006 09:43:22 -0600 (MDT) Cc: freebsd-new-bus@freebsd.org Subject: Re: Device enumeration process X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2006 15:45:21 -0000 In message: <20061006073434.71730.qmail@web8913.mail.in.yahoo.com> Alok Barsode writes: : Thanks for ur earliers replies. They helped me a lot : in understanding the newbus architecture. : I am involved in a freeBSD port to a freescale board. Cool! Remind me: is the freescale an arm design or a Power PC one? : When i/o configuration is in progress during startup, : are the drivers for specific busses alreay assosciated : with them or the association happens at run time ? The drivers are associated with the busses at compile time (as extended via modules that are loaded). The assignment of specific device nodes to drivers is done at run time. : for example : : when nexus is being attached to root_bus, : the method devclass_find_internal("nexus", 0, TRUE) is : invoked(in method make_device).Now does a nexus : devclass already exist ( it is created through the : macro DRIVER_MODULE(nexus, root, nexus_driver, : nexus_devclass, 0, 0);) or it is created at runtime ? : : if it is created at runtime how the nexus_driver get : assciated with nexus? nexus_driver gets associated with nexus here: /* * Determine i/o configuration for a machine. */ static void configure_first(dummy) void *dummy; { /* nexus0 is the top of the i386 device tree */ device_add_child(root_bus, "nexus", 0); } at least tenatively associated. configure_first is run via the SYSINIT at SI_SUB_CONFIGURE as the first thing. In fact, all the autoconf look similar in this respect. The arm one does the same thing. If you look at sys/arm/at91/at91.c, you'll see code: static void at91_identify(driver_t *drv, device_t parent) { BUS_ADD_CHILD(parent, 0, "atmelarm", 0); } which is how the atmelbus gets added to nexus. Again, the atmelbus is about the best example I can easily find in the tree... Warner