On Thu, Jun 18, 2020 at 3:05 AM Hans Verkuil [off-list ref] wrote:

On 18/06/2020 10:59, Jeff Chase wrote:

quoted

Hi Hans,

We are using two of these in an Intel-based Chromebox. I see that the
cros-ec and seco drivers just statically define the PCI BDF of the
Intel graphics device for their boards. I don't see an example of ACPI
passing this information. I can copy cros-ec and seco by adding a
board table and then use the UID of each device to select the correct
port. Adding board-specific configuration to the driver doesn't seem
ideal but I'm not sure what the proper way to pass this using ACPI is.

You are right, it's not ACPI, it's using DMI matching.

I have zero knowledge about ACPI, so I have no idea if there is some standard
method of retrieving this association via ACPI.

I'm not very familiar with ACPI either. I looked for but did not find
an ACPI equivalent of_get_mac_address().

I believe it's possible to reference the PCI node but it would take a
bit of work on both the coreboot and linux side.

This particular chip can actually be used both with DMI matching but also
on an ARM with device tree, but since you can't test this on an ARM board,
there is no point in adding support for that.

However, compared to the cros-ec and seco drivers you can do something a bit
different here: those drivers just return -ENODEV if there is no match, but
since this driver reads the EDID it can just continue as long as it does not
set the CEC_CAP_CONNECTOR_INFO capability.

Is it necessary to add support if we don't set CEC_CAP_CONNECTOR_INFO?

Thanks,
Jeff