Date: Tue, 27 Jan 2004 15:09:36 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: nate@root.org Cc: msmith@freebsd.org Subject: Re: newbus ioport usage Message-ID: <20040127.150936.73380598.imp@bsdimp.com> In-Reply-To: <20040127133251.W75080@root.org> References: <20040127125547.G74774@root.org> <20040127.141937.45155991.imp@bsdimp.com> <20040127133251.W75080@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040127133251.W75080@root.org>
Nate Lawson <nate@root.org> writes:
: 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).
Right, that's why it would delegate the resource. This implies that
when the delegation is released, it would go back to being owned by
acpi0.
: > 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.
This gets ugly. The reason that I suggested not doing the discovery
this way is because you want to allocate *ALL* resources up front
before giving any to any children. pci has issues with this right now
that I'm working to fix.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040127.150936.73380598.imp>