I've had more time to look at this now. Let's take one of the most
pathological cases, the Dell d610. It's available with either Intel or
ATI graphics. The DSDT declares three video devices. Two are called VID,
the third is called VID2. I'll call the first two VID(a) and VID(b) to
reduce confusion.
The layout is as follows:
host bridge (_ADR 0x00)
|
|
/ \
/ \
AGP (_ADR 0x00010000) |
| / \
| / \
VID(a) (_ADR 0x00) / \
VID(b) (_ADR 0x00020000) VID2 (_ADR 0x00020001)
If we call acpi_get_physical_device on VID(a), we'll get nothing - there
isn't a corresponding physical device. Therefore we have to call it on
the parent, and so will get the AGP bridge if the machine is configured
that way. If not, we can be sure that VID(a) doesn't exist.
If we call acpi_get_physical_device on VID(b), then either the device
exists and we get something, or the device doesn't exist and we don't.
In the second case, how do we distinguish between that being because the
device doesn't exist and that being because the physical device is the
parent? If we call acpi_get_physical_device on the parent of VID(b),
then we'll hit the host bridge and we'll get a PCI device back. This
then looks almost identical to the AGP bridge case.
There are two things we can do here. The first is to examine the _ADR
field and use that to determine whether we should look at the parent or
not (if it's parsable as a PCI address, look at the current device. If
not, look at the parent device). The second is to always look at the
parent device and ignore it if the host bridge is returned.
I think the first approach is probably better, since it doesn't result
in us depending on the vagueries of bus topology. However, I'm concerned
about the inherent assumption it makes about video devices being
PCI-like. That's true now, but I'm aware of at least one forthcoming
platform where that may not be the case. The spec certainly doesn't
require it. I'll try to come up with a patch in any case.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
