Re: Properly managing sub-allocations

On Monday 02 October 2006 13:39, M. Warner Losh wrote:
> In message: <[email protected]>
>             John Baldwin <[email protected]> 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "[email protected]"