--Li7ckgedzMh1NgdW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 12, 2005 at 12:54:28AM +0100, Martin Husemann wrote:
> On Fri, Nov 11, 2005 at 08:19:14PM +0100, Quentin Garnier wrote:
> > We currently have code (under PCI_INTR_FIXUP) that looks up the _PRT
> > tables for each PCI bus and tries to apply it.  However, this is done
> > completely wrong.
>=20
> You are using a lot of ACPI specific terms that probably do not make much
> sense to lots of people on this list (for sure *I* do not know what _PRT
> is, for example). My first reaction on reading this is that you probably
> could solve the problems by using device properties (as uwe hinted) and
> getting some things into the correct order in i386/amd64 machdep PCI code.
>=20
> Could you explain why you need to move ACPI information into environment
> variables only to extract them later? Can't you just use the ACPI informa=
tion
> when you need it?

Our autoconf process and the ACPI namespace walk have to happen together
if we don't want to face issue.  The reason for that is that the ACPI
table itself doesn't carry enough information to allow us to match a
device in the ACPI table to a device found by autoconf, and in return,
given a device, it's almost impossible to extract its ACPI counterpart.

So if we want to properly use the information carried by the ACPI table
(the example here being the _PRT tables which describe interrupt routing
on a PCI bus), we have the choice of either seperating completely the
ACPI namespace walk from the normal device enumeration, or mixing them
somehow.  The former is very hard because for example the add-on PCI
cards won't appear in the ACPI namespace although other devices on the
same bus will.

The latter seems more logical, anyway, but it is not as easy as having
devices matching what appears in the ACPI table.  For example, ACPI
only has the notion of a "PCI root bus" device.  PCI-to-PCI bridges
and the child PCI bus device appear as only one device.

That means that we have an additional ppb(4) device in the way.  The
father PCI bus has to transmit the ACPI handle of the ppb+pci device
to its grandson the secondary PCI bus.  (Arguably, we could follow ACPI
here and get rid of ppb or the secondary pci.  However, I think the
separation has its merit, and the problem will be the same with atabus
vs. pciide vs. atapibus vs. wd/cd.)

Passing information from a grandfather to a grandson is not currently
possible with our autoconf(9) framework.  That's why I came up with this
idea of an environment variable.  The ppb(4) device ignores it, thus it
stays in the environment when the child PCI bus gets probed.

Note that there are two different part in my patches (and that's why
there are two patches, which BTW were reformatted by hand, so might not
apply properly;  and some other things need to be patched because of the
cfattach API change).  The first one deals with the environment stuff
itself, which might possibly be done using properties(9) (I didn't know
about it, but I'll definitely try using it).

The second one deals with using the environment variables.  We have two
choices here:  either the device itself checks for the environment
variables and deals appropriately.  In the pci(4) case, that means we
end up with #if NACPI stuff in pci.c, and possibly with a struct
pci_softc that depends on such defines.  This is ugly IMO.

The other option is what I chose, having an autoconf(9) mechanism that
allows attachments to be done in a different way if some environment
variables are defined.  At first I was disappointed that I had to change
struct cfdata for that, but in the end I don't think it is too bad, as
it will allow the user to prevent autoconf(9) from overriding the
attachment for a specific device (though my config(1) patch doesn't
include that).

I hope it is clearer that way.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--Li7ckgedzMh1NgdW
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEVAwUBQ3U4R9goQloHrPnoAQJBGQf/dk7Q1fgngtXcESw2HocnOIHAmn/1DUKi
PtLUylQzUFJQALn7UAjidN4GiN01Lt8MXHx0RM8E24I/x53DVTWhfR6A8TW3tLO5
VU0AdhkKK21aEMS0eyoepLXSNfy7Dx825H7DTyDyY4gdHJXuN7pFEOZz2OrU8Xky
+KhQ+DxRbztollw6m9KZ1e/1FbsNn1hh91XiQcbwWO3gjuuTh06sheFSXv8mtON7
DLt9yuY4l1fkH9grcsi6fn7ZbmbMCgPc46PFC8F3SBl+8fMHHxqxeTmiCvfh6mFq
HrWaHB1fXUHviaDBEA3r90xmMxpCFGW9fcdXr+kd3C7l0upCgolr7g==
=105X
-----END PGP SIGNATURE-----

--Li7ckgedzMh1NgdW--