Date: Tue, 27 Jan 2004 13:40:18 -0800 (PST) From: Nate Lawson <nate@root.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: msmith@freebsd.org Subject: Re: newbus ioport usage Message-ID: <20040127133251.W75080@root.org> In-Reply-To: <20040127.141937.45155991.imp@bsdimp.com> References: <E4469364-5092-11D8-8DD8-000393C72BD6@freebsd.org> <20040127.032119.28084825.imp@bsdimp.com> <20040127125547.G74774@root.org> <20040127.141937.45155991.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Jan 2004, M. Warner Losh wrote: > In message: <20040127125547.G74774@root.org> > Nate Lawson <nate@root.org> writes: > : Ok, let me propose a design and I'd appreciate your comments. The probe > : routine for acpi_sysresource will stay the same. The attach will allocate > : the resources to its parent device (acpi0). > : > : acpi0 will make this set of resources available to its children via a > : flag included with bus_alloc_resource, say ACPIDEV_REQUEST. If > : acpi_resource_alloc finds a range already has that flag set, it will > : refuse the request. Otherwise, it will release that range and then > : immediately allocate it to the child. > > That seems overly convoluted. Why not just allocate it in acpi0? If > a driver requests something that acpi0 has allocated, it assigns it to > the child and takes it out of its resource manager. If not, then it > passes things up a level in the tree. No special flags needed, > although acpi does get a little more complicated. This will ensure > that the resources are owned by someone, and can easily be delegated. > These resource ranges are there to be used by acpi, and only acpi. So acpi0 would do a resource_list_delete for the given resource if it's in the list and then perform the alloc request. This would then succeed since no one owns the resource at that point. Once it succeeds, the child owns the range and it can't be stolen. And I guess when the child releases the range, acpi0 can reclaim all such resources. I wouldn't want a pccard device plugged in later to grab the IO ports after a child temporarily releases them (say while the ACPI Performance cpufreq driver is unloaded and then reloaded). > There's nothing magical about the acpi_sysresource device, and it can > be relegated to the scrap-heap of history if needed. Well, the way we find out about the resources is through a pseudo-device with a PNPID. So it makes sense to use the normal device discovery method to find these resources. This leads me to do the allocation for the parent by the acpi_sysresource0 attach method. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040127133251.W75080>