From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 27 17:15:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D81916A4CE for ; Tue, 27 Jul 2004 17:15:25 +0000 (GMT) Received: from k6.locore.ca (k6.locore.ca [205.233.216.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C64E543D2D for ; Tue, 27 Jul 2004 17:15:24 +0000 (GMT) (envelope-from jake@locore.ca) Received: by k6.locore.ca (Postfix, from userid 1000) id D9E26A923; Tue, 27 Jul 2004 13:15:23 -0400 (EDT) Date: Tue, 27 Jul 2004 13:15:23 -0400 From: Jake Burkholder To: Chuck Tuffli Message-ID: <20040727171523.GE18793@locore.ca> References: <20040727015923.GA63284@cre85086tuf.rose.agilent.com> <20040726.215453.22504137.imp@bsdimp.com> <20040727165124.GA64121@cre85086tuf.rose.agilent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040727165124.GA64121@cre85086tuf.rose.agilent.com> User-Agent: Mutt/1.4.2.1i cc: hackers@freebsd.org Subject: Re: bus_alloc_resource question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2004 17:15:25 -0000 Apparently, On Tue, Jul 27, 2004 at 09:51:25AM -0700, Chuck Tuffli said words to the effect of; > On Mon, Jul 26, 2004 at 09:54:53PM -0600, M. Warner Losh wrote: > ... > > Generally, one doesn't need to set the resource value. Doing so > > usually indicates the presence of some bug in the system. Also, just > > I realize now that the original email wasn't clear. This is a bus > driver for a new bus. Think of the physical addresses from 0xe0000000 > - 0xefffffff as being a memory mapped config space for devices. Each > 4KB segment of this region maps the configuration space for every > possible bus, device, function number combination. I was thinking that > each of these segments was a bus resource, but maybe that isn't the > right approach. Any thoughts as to a better approach? > > Jake Burkholder suggested using pmap_mapdev() for small sections of > memory, but cautioned that this uses up virtual address space. The bus > driver could map each segment to test if a device was there and unmap > the segments that didn't contain devices. Ok, I think what you want to do is make an rman (resource manager) that manages the device memory, and that child devices will allocate from. In your attach routine you would then probe the bus by mapping in portions of whatever size you need and adding the child device's resources to a resource list, for each child found. An example of this (oddly enough) is the sparc64 nexus (in -current), sparc64/sparc64/nexus.c, and the sparc64 sbus driver, sparc64/sbus/sbus.c. The MI pci bus drivers as well, but this is a bit closer to what you're doing, I think. You won't be able to allocate the region from pci unless its described by pci, but that doesn't really matter as long as no one else tries to use it. HTH, Jake