From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 14 17:39:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 061EE106568F for ; Tue, 14 Jul 2009 17:39:17 +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 CB6398FC18 for ; Tue, 14 Jul 2009 17:39:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6A69D46B2D; Tue, 14 Jul 2009 13:39:16 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 698628A097; Tue, 14 Jul 2009 13:39:15 -0400 (EDT) From: John Baldwin To: Norbert Koch Date: Tue, 14 Jul 2009 11:51:29 -0400 User-Agent: KMail/1.9.7 References: <4A5B3F1B.3040207@demig.de> <200907140849.51702.jhb@freebsd.org> <4A5CA4AA.6050307@demig.de> In-Reply-To: <4A5CA4AA.6050307@demig.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907141151.29971.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 14 Jul 2009 13:39:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: bus device driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 17:39:18 -0000 On Tuesday 14 July 2009 11:30:50 am Norbert Koch wrote: > > > From a hardware perspective, how do your devices know which addresses to > > decode? Do they consume subranges of BARs or are they assigned fixed > > addresses somehow? Do they have programmable decoders of some sort > > themselves? If you wish to have the PCI bus assign you resources then that > > implies that your PCI device has a BAR and that you want to request resources > > for that BAR and then hand out subranges of that to your children. If that > > is the case, then you will need to allocate the resources for the BAR for the > > PCI device from the PCI bus. Then your bus driver for the PCI device will > > need to suballoc from that BAR to your children devices. > > > > > My device decodes one ram address range (16MB) and gives me > one interrupt line. > As my sub-devices operate on partial address areas my idea was to > let them all call bus_alloc_resource() with the same rid parameter (= > BAR selector) > and different offsets. So the bookkeeping should be done by the pci > driver, right? No. First of all, the PCI bus driver will only allocate resources for direct children. It simply passes requests up the tree for grandchildren (this is how ISA devices behind a PCI-ISA bridge request resources). In this case, you will want to allocate resources for your BAR and your interrupt using bus_alloc_resource() during your attach routine. You can then either share the resources directly with your children by returning your resource values in your own bus_alloc_resource() method (see ppc(4) for an example of this) or subdivide your resource to make new resources (the easiest way to do this is probably to create a rman from your resource and then use rman_reserve_resource() to sub-allocate chunks of that to your children). For the interrupt resource you can just return your own resource pointer directly in your bus_alloc_resource() routine. -- John Baldwin