Date: Mon, 2 Oct 2006 14:03:50 -0400 From: John Baldwin <john@baldwin.cx> To: freebsd-new-bus@freebsd.org Subject: Re: Properly managing sub-allocations Message-ID: <200610021403.50339.john@baldwin.cx> In-Reply-To: <20061002.113954.756907493.imp@bsdimp.com> References: <200610021323.50997.john@baldwin.cx> <20061002.113954.756907493.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 02 October 2006 13:39, M. Warner Losh wrote: > In message: <200610021323.50997.john@baldwin.cx> > John Baldwin <john@baldwin.cx> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610021403.50339.john>