Date: Tue, 27 Jan 2004 13:05:08 -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: <20040127125547.G74774@root.org> In-Reply-To: <20040127.032119.28084825.imp@bsdimp.com> References: <20040126.181720.15264443.imp@bsdimp.com> <20040126191657.B31071@root.org> <20040127.032119.28084825.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: <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. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040127125547.G74774>