Subject: Re: ISA direct config of ACPI devices
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: Quentin Garnier <firstname.lastname@example.org>
Date: 11/23/2007 18:35:17
Content-Type: text/plain; charset=us-ascii
On Fri, Nov 23, 2007 at 06:18:19PM +0100, Matthias Drochner wrote:
> email@example.com said:
> > It maps the ACPI tree on our device tree with the result of attaching
> > those devices to the "acpipcib" device (because that's where they
> > appear in the ACPI tree)
> Interesting -- this looks like the way Windows does it. Only
> that they call it LPC-bus which matches the hardware better.
> (I didn't check yet what the diffences between ISA and LPC are.
> I'd guess LPC is logically reduced and physically accelerated.)
> But how do you know if you find eg a UAR1=3DPNP0501 entry in
> the ACPI _SB namespace that it should be put below your acpipcib
> node in the tree? I haven't found any ISA bus object in the
Because that's where it is in the ACPI tree. I only follow what is
> ACPI spec, nor anything in the device nodes which could tell
> "this is an ISA device". And you can't tell from address ranges
> because we have subtractive decoding on those bridges.
> So there is some heuristics or guessing, or am I missing something?
No heuristics. While descending both the ACPI tree and our device tree,
starting with the PCI Root device (i.e. pci0 at acpi0, PNPwhatever),
I put ACPI information as a property while attaching a device (at this
point I have a separate API to allocate a device_t and attaching a
driver, which means I can set the property before autoconf looks for
drivers), and it goes do through acpippb devices and eventually an
acpipcib, which defines the acpinodebus ifattr and thus is able to
attach what are currently com@acpi and so on.
So yes, it assumes the ACPI tree the vendor provides makes some kind of
sense (granted, that might be a big assumption, but I have yet to see a
table where it is untrue), but if it's not the case, it's not fatal:
acpi0 will try to attach unclaimed nodes at the end of the process.
You can see an example of the resulting dmesg here:
Quentin Garnier - firstname.lastname@example.org - cube@NetBSD.org
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)
-----END PGP SIGNATURE-----