Date: Tue, 27 Jan 2004 14:19:37 -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.141937.45155991.imp@bsdimp.com> In-Reply-To: <20040127125547.G74774@root.org> References: <E4469364-5092-11D8-8DD8-000393C72BD6@freebsd.org> <20040127.032119.28084825.imp@bsdimp.com> <20040127125547.G74774@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040127125547.G74774@root.org>
Nate Lawson <nate@root.org> writes:
: On Tue, 27 Jan 2004, M. Warner Losh wrote:
: > In message: <E4469364-5092-11D8-8DD8-000393C72BD6@freebsd.org>
: > Mike Smith <msmith@freebsd.org> writes:
: > : The whole reason for the sysresource device was to have something
: > : sitting on resources that the AML said had "something" behind them
: > : so that they didn't get handed out to devices on eg. PCI. If you're
: > : in the same sort of scope as the sysresource device, it's fair to
: > : say that you know more than eg. the PCI bus resource code does about
: > : whether you can use the resource in question.
: >
: > Yes. It is a form of resource enumeration that belongs to ACPI.
: > Therefore, ACPI should manage it and dole it out to its children which
: > are based on the AML. That's what it is there for. It is akin to the
: > PCI code assigning resources based on the BARs that a child has.
: > However, only akin, because the entire resource space is enumerated in
: > the bus, not the children, for ACPI. The sysresource stuff was a
: > means to an end, not the only way to that end. I'm starting to think
: > that the right way to go is to reserve EVERYTHING up front, and then
: > have all the acpi_foo devices allocate out of that reserveation.
: >
: > In this way it is similar to a BAR that has been assigned by the BIOS,
: > but isn't allocated by a child device on pci. In the code I'm working
: > on, those resources are reserved at the bus level and given to the
: > child if it asks for it later. Well, it is a little more complex than
: > that because the child device actually owns the resource, but the bus
: > is who assigns ownership. In ACPI, since the resource maps aren't
: > child specific, the ownership should resided in the bus layer. So
: > instead of belonging to acpi_sysresource0, it would belong to acpi0.
: > This may also help some downstream resource allocations, since they
: > would now be happening a little earlier in the game.
:
: 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.
There's nothing magical about the acpi_sysresource device, and it can
be relegated to the scrap-heap of history if needed.
This is similar to how pci bridges should be working, but aren't,
right now. They have a range they decode, and they should own those
resources, but given them out to their children as they request them.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040127.141937.45155991.imp>