Date: Mon, 26 Jan 2004 22:34:43 -0800 From: Mike Smith <msmith@freebsd.org> To: Nate Lawson <nate@root.org> Cc: arch@freebsd.org Subject: Re: newbus ioport usage Message-ID: <E4469364-5092-11D8-8DD8-000393C72BD6@freebsd.org> In-Reply-To: <20040126191657.B31071@root.org> References: <20040126140100.T29680@root.org> <20040126.151728.133912536.imp@bsdimp.com> <20040126165523.W30461@root.org> <20040126.181720.15264443.imp@bsdimp.com> <20040126191657.B31071@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, I've found what's going on. Apparently my acpi_sysresource0 > pseudo-device is claiming all resources in its _CRS method. If I don't > boot with 0x101c and 0x101d attached, it attaches to 0x1010-0x109d. > But > if I boot attaching them, it reserves less of the range. It just comes along later, I think. > I'm not sure of a way around this. All ASL I've seen keeps these > registers contiguous so I could whack out a block of 8 of them, > although > that doesn't seem correct. Perhaps acpi_cpu should be able to override > the acpi_sysresource0 allocations, maybe by asking it for the resource > if > bus_resource_alloc returns NULL. Thoughts? You probably need the concept of a "may be considered system device" device, which can steal resource ranges from the sysresource placeholder. 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. = Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E4469364-5092-11D8-8DD8-000393C72BD6>