On Thu, 15 Feb 2024, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote:
> On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
>> +static int
>> +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
>> +{
>> + struct drm_connector *connector = data;
>> + struct drm_device *ddev = connector->dev;
>> + struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
>> + unsigned char start = block * EDID_LENGTH;
>> + void *edid;
>> + int r;
>> +
>> + if (!acpidev)
>> + return -ENODEV;
>> +
>> + switch (connector->connector_type) {
>> + case DRM_MODE_CONNECTOR_LVDS:
>> + case DRM_MODE_CONNECTOR_eDP:
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>
> We could have other types of connectors that want this too.
> I don't see any real benefit in having this check tbh. Drivers
> should simply notset the flag on connectors where it won't work,
> and only the driver can really know that.
Agreed.
>> const struct drm_edid *drm_edid_read(struct drm_connector *connector)
>> {
>> + const struct drm_edid *drm_edid = NULL;
>> +
>> if (drm_WARN_ON(connector->dev, !connector->ddc))
>> return NULL;
>>
>> - return drm_edid_read_ddc(connector, connector->ddc);
>> + if (connector->acpi_edid_allowed)
>
> That should probably be called 'prefer_acpi_edid' or something
> since it's the first choice when the flag is set.
>
> But I'm not so sure there's any real benefit in having this
> flag at all. You anyway have to modify the driver to use this,
> so why not just have the driver do the call directly instead of
> adding this extra detour via the flag?
Heh, round and round we go [1].
BR,
Jani.
[1] https://lore.kernel.org/r/87sf23auxv.fsf@xxxxxxxxx
--
Jani Nikula, Intel
