RFC: implementing a way to force external EDID use.

[Arthur Heymans]

Hi

In Linux it is possible to load an EDID externally. Coreboot can
currently not do this. Do you think it is worth implementing this
feature?

An EDID file is a bit to big (128 bytes) to fit in nvram so it would have to go in cbfs.
Where in the code do you think this setting should be implemented:
NB code, read_edid in drivers, decode_edid in lib, somewhere else?
How do you think this feature should be turned on: nvram option or build
option?

Thank you for your comments

[Stefan Reinauer]

Hi Arthur,

* Arthur Heymans  [160622 23:34]:
> Hi
>
> In Linux it is possible to load an EDID externally. Coreboot can
> currently not do this. Do you think it is worth implementing this
> feature?

So far we have not come across devices without an EDID or with a bad
EDID, but if that is the case for you, you should implement this.

What platform are you looking at?
> An EDID file is a bit to big (128 bytes) to fit in nvram so it would have to go in cbfs.

Since the information is not going to change (for a mobile device,
anyways), CBFS is the right place.
> Where in the code do you think this setting should be implemented:
> NB code, read_edid in drivers, decode_edid in lib, somewhere else?

The code should probably live in lib, as it is not chip specific, and be
called from the chip specific code, e.g.

intel_gmbus_read_edid(pmmio + GMBUS0, 3, 0x50, edid_data, 128);
        decode_edid(edid_data, sizeof(edid_data), &edid);

would become something like

if (IS_ENABLED(CONFIG_OVERRIDE_EDID)
                cbfs_read_edid(edid_data, sizeof(edid_data));
        else
                intel_gmbus_read_edid(pmmio + GMBUS0, 3, 0x50, edid_data, 128);
        decode_edid(edid_data, sizeof(edid_data), &edid);
> How do you think this feature should be turned on: nvram option or build
> option?

This depends on your use case. Since this is not something that should
be messed with in the field, I would suggest to make it a Kconfig
option.

Stefan