Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Jul 2004 13:15:23 -0400
From:      Jake Burkholder <jake@locore.ca>
To:        Chuck Tuffli <chuck_tuffli@agilent.com>
Cc:        hackers@freebsd.org
Subject:   Re: bus_alloc_resource question
Message-ID:  <20040727171523.GE18793@locore.ca>
In-Reply-To: <20040727165124.GA64121@cre85086tuf.rose.agilent.com>
References:  <20040727015923.GA63284@cre85086tuf.rose.agilent.com> <20040726.215453.22504137.imp@bsdimp.com> <20040727165124.GA64121@cre85086tuf.rose.agilent.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040727171523.GE18793>