--Fba/0zbH8Xs+Fj9o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 23, 2007 at 06:18:19PM +0100, Matthias Drochner wrote:
>=20
> cube@cubidou.net 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)
>=20
> 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.)
>=20
> 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
there.

> 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:

http://taryn.cubidou.net/~cube/netbsd/solo.dmesg

--=20
Quentin Garnier - cube@cubidou.net - 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.

--Fba/0zbH8Xs+Fj9o
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (NetBSD)

iQEVAwUBR0cPVdgoQloHrPnoAQLBIAf/dICjMWbsxNPgv4R2O3gR/saVDg2oe1Sk
fXYyiYLK4qEtEw/dx077+fos7DBouu0hcu15brNNPnRWCmdRFTtx9ropXluX2p/G
Y3F3twNWo5ZjgF63xCfA6ILClP0fshqcuAgBeIusbWIvoNsRSg/5sxYncoMfXnHO
5KoIFyn/GPCvWYsOU/KoyGWA5/xTHOMwUtF1xzNWkocetslQXCwp1R7c6Dpt3MZc
Pegm3J82cu7izsw1fI7j8wiFhXmeSkcZ9hdnfjW4PQxqlxnFiM4Bv+ehd1ATzUdR
7FkB6QbtAZUTzSfPK5bGbZ0m3rPhcG8sQU9dKyNfZFMsuukCtcdNbQ==
=+P16
-----END PGP SIGNATURE-----

--Fba/0zbH8Xs+Fj9o--