tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Missing ACPI PCI devices in acpi_pcidev_scan
Hi,
I'm trying to refactor an old ACPI display patch that I sent [1] in dec.
2008, and that I've been using since (on netbsd-5). The patch
introduced helper functions to look for a given pci device in the ACPI
tree. But, as noted in [2], and I gladly admit it, the implementation
was not efficient (it used too many ACPI walks without even caching
results). A new implementation now exists in functions acpi_pcidev_scan
and acpi_pcidev_find of acpi_pci.c [3], and I would like to use them.
However, acpi_pcidev_scan does not detect all my PCI devices, in fact it
only detects one: PCI0. This is due to the fact that the function
acpi_pcidev_scan discards devices that do not have the "_BBN" child
integer value (PCI bus number). IMHO, PCI devices are not required to
have this "_BBN" child, except for PCI host bridges. This is how I
interpret the spec, and also what I observe on two PCs (with iasl).
It was previously argued in the list that there should be a unique ACPI
namespace walk to build an in-kernel representation of the ACPI tree
from which drivers can get all the information they need. I like this
idea, but I don't see how acpi_pcidev_scan can find the PCI bus number
of PCI devices without the parent-child information of the ACPI tree,
and AFAICS this information is currently missing in the in-kernel
representation (struct acpi_devnode). As AcpiWalkNamespace performs a
DFS (with both pre and post order visitor callbacks), the parent-child
information could be stored during the ACPI walk done by acpi_build_tree
(in acpi.c), provided that struct acpi_devnode is modified to contain
that information. What do you think?
Thanks for your help,
Grégoire
[1] http://mail-index.netbsd.org/tech-kern/2008/12/11/msg003849.html
[2] http://mail-index.netbsd.org/tech-kern/2009/11/18/msg006507.html
[3] http://mail-index.netbsd.org/tech-kern/2009/11/28/msg006552.html
Home |
Main Index |
Thread Index |
Old Index