From: sashiko-bot@kernel.org
To: "Aman Sharma" <amansharma6122002@gmail.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/hdmi: preserve cached EDID on DDC failure when connector is forced
Date: Sat, 24 Oct 2026 12:19:57 +0000 [thread overview]
Message-ID: <sashiko-outbox-183708@kernel.org> (raw)
In-Reply-To: <179284356403.1659508.10439113185286055496@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] drm/i915/hdmi: cached EDID still wiped by intel_hdmi_detect() on hotplug
- [Medium] drm/i915/hdmi: stale dp_dual_mode state in intel_hdmi_force()
- [Medium] drm/i915/hdmi: stale detect_edid retained after Gen11+ disconnect
--
commit 3cd457134d1b7d17ad43e200eb7f55647f7587b7
Author: Aman Sharma <amansharma6122002@gmail.com>
drm/i915/hdmi: preserve cached EDID on DDC failure when connector is forced
This commit retains the previously cached connector->detect_edid when a DDC
read fails on a forced-on HDMI connector instead of unconditionally clearing
it in intel_hdmi_force(). This avoids wiping the cached EDID and falling back
to the 1024x768 no-EDID mode when an external monitor powers down its DDC/I2C
controller during DPMS standby.
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index b6fa1a1558b82..140d98a61a9c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2568,6 +2568,18 @@ intel_hdmi_set_edid(struct drm_connector *_connector)
> intel_gmbus_force_bit(ddc, false);
> }
>
> + /*
> + * If the connector is forced on (e.g. video=HDMI-A-1:e) and the sink's
> + * DDC/I2C bus is powered down during DPMS standby, keep the previously
> + * cached EDID rather than wiping it and falling back to 1024x768.
> + */
> + if (!drm_edid && connector->base.force && connector->detect_edid) {
> + intel_display_power_put(display, POWER_DOMAIN_GMBUS, wakeref);
> + return true;
> + }
[Severity: Medium]
Will this check ever trigger when intel_hdmi_set_edid() is called from the
hotplug detection path, or will intel_hdmi_detect() still wipe
connector->detect_edid on hotplug?
Even when connector->base.force is set, hotplug and poll handling in
drivers/gpu/drm/i915/display/intel_hotplug.c still runs
intel_hotplug_detect_connector() -> drm_helper_probe_detect() ->
intel_hdmi_detect():
drivers/gpu/drm/i915/display/intel_hotplug.c:intel_hotplug_detect_connector() {
...
status = drm_helper_probe_detect(&connector->base, NULL, false);
if (!connector->base.force)
connector->base.status = status;
...
}
In drivers/gpu/drm/i915/display/intel_hdmi.c, intel_hdmi_detect() is the only
caller that checks the boolean return value of intel_hdmi_set_edid(), and it
still unconditionally calls intel_hdmi_unset_edid() first:
drivers/gpu/drm/i915/display/intel_hdmi.c:intel_hdmi_detect() {
...
if (DISPLAY_VER(display) >= 11 &&
!intel_digital_port_connected(encoder))
goto out;
intel_hdmi_unset_edid(&connector->base);
if (intel_hdmi_set_edid(&connector->base))
status = connector_status_connected;
...
}
On DISPLAY_VER(display) < 11, or on DISPLAY_VER(display) >= 11 when
intel_digital_port_connected(encoder) is true during standby or wake-up while
DDC is still powered down, intel_hdmi_unset_edid() frees
connector->detect_edid and sets it to NULL before intel_hdmi_set_edid() is
called.
When intel_hdmi_set_edid() then sees connector->detect_edid == NULL, it calls
drm_edid_connector_update(&connector->base, NULL) and returns false. Because
drm_helper_probe_detect_ctx() sees the returned status differ from the forced
connector->status, it increments connector->epoch_counter and triggers a
hotplug uevent, causing the subsequent userspace mode probe to find
connector->detect_edid already cleared and fall back to 1024x768 anyway.
Should intel_hdmi_detect() also avoid calling intel_hdmi_unset_edid() up
front so that connector->detect_edid is preserved across hotplug detection on
a forced connector?
[Severity: Medium]
Can this early return also leave connector->detect_edid out of sync with
connector->base.edid_blob_ptr if an unforced connector on DISPLAY_VER >= 11
is unplugged and later forced on?
In drivers/gpu/drm/i915/display/intel_hdmi.c, when a sink is disconnected on
DISPLAY_VER(display) >= 11, intel_hdmi_detect() jumps to out before calling
intel_hdmi_unset_edid():
drivers/gpu/drm/i915/display/intel_hdmi.c:intel_hdmi_detect() {
...
if (DISPLAY_VER(display) >= 11 &&
!intel_digital_port_connected(encoder))
goto out;
intel_hdmi_unset_edid(&connector->base);
...
}
When the connector is not forced, drm_helper_probe_single_connector_modes()
in drivers/gpu/drm/drm_probe_helper.c handles connector_status_disconnected
by clearing the EDID property to NULL while connector->detect_edid remains
non-NULL:
drivers/gpu/drm/drm_probe_helper.c:drm_helper_probe_single_connector_modes() {
...
if (connector->status == connector_status_disconnected) {
drm_dbg_kms(dev, "[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, connector->name);
drm_connector_update_edid_property(connector, NULL);
drm_mode_prune_invalid(dev, &connector->modes, false);
goto exit;
}
...
}
If the user subsequently forces the connector on (for example via sysfs)
while disconnected or while DDC fails, drm_helper_probe_single_connector_modes()
calls intel_hdmi_force() -> intel_hdmi_set_edid(). Because
connector->detect_edid is still non-NULL from the previously unplugged
monitor, intel_hdmi_set_edid() will hit this early return without calling
drm_edid_connector_update(), retaining the unplugged monitor's stale
connector->detect_edid while connector->base.edid_blob_ptr remains NULL.
> +
> + drm_edid_free(connector->detect_edid);
> +
> /* Below we depend on display info having been updated */
> drm_edid_connector_update(&connector->base, drm_edid);
>
> @@ -2638,10 +2650,10 @@ intel_hdmi_force(struct drm_connector *_connector)
> if (!intel_display_driver_check_access(display))
> return;
>
> - intel_hdmi_unset_edid(&connector->base);
> -
> - if (connector->base.status != connector_status_connected)
> + if (connector->base.status != connector_status_connected) {
> + intel_hdmi_unset_edid(&connector->base);
> return;
> + }
>
> intel_hdmi_set_edid(&connector->base);
> }
[Severity: Medium]
Does skipping intel_hdmi_unset_edid() in intel_hdmi_force() when
connector->base.status == connector_status_connected leave stale
intel_hdmi->dp_dual_mode state behind when a new EDID is read?
Previously, intel_hdmi_force() called intel_hdmi_unset_edid(), which resets
intel_hdmi->dp_dual_mode in addition to freeing connector->detect_edid:
drivers/gpu/drm/i915/display/intel_hdmi.c:intel_hdmi_unset_edid() {
...
intel_hdmi->dp_dual_mode.type = DRM_DP_DUAL_MODE_NONE;
intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
drm_edid_free(connector->detect_edid);
connector->detect_edid = NULL;
}
When intel_hdmi_force() instead calls intel_hdmi_set_edid() directly and a
new EDID is read, intel_hdmi_set_edid() frees connector->detect_edid and
calls intel_hdmi_dp_dual_mode_detect(), which returns early without clearing
hdmi->dp_dual_mode when type == DRM_DP_DUAL_MODE_NONE:
drivers/gpu/drm/i915/display/intel_hdmi.c:intel_hdmi_dp_dual_mode_detect() {
...
if (type == DRM_DP_DUAL_MODE_NONE)
return;
hdmi->dp_dual_mode.type = type;
hdmi->dp_dual_mode.max_tmds_clock =
drm_dp_dual_mode_max_tmds_clock(display->drm, type, ddc);
...
}
If a DP++ adaptor was previously connected, or if an unforced connector had
assumed DRM_DP_DUAL_MODE_TYPE1_DVI from VBT before being forced on via sysfs,
won't intel_hdmi->dp_dual_mode.type and intel_hdmi->dp_dual_mode.max_tmds_clock
retain their old values, causing hdmi_port_clock_limit() to clamp the maximum
TMDS clock and intel_dp_dual_mode_set_tmds_output() to send DP++ I2C writes
to a native HDMI sink?
--
Sashiko AI review · https://sashiko.dev/#/patchset/179284356403.1659508.10439113185286055496@gmail.com?part=1
next prev parent reply other threads:[~2026-10-24 12:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-24 12:06 [PATCH] drm/i915/hdmi: preserve cached EDID on DDC failure when connector is forced Aman Sharma
2026-10-24 12:19 ` sashiko-bot [this message]
2026-10-24 12:33 ` [PATCH v2] " Aman Sharma
2026-10-24 12:47 ` sashiko-bot
2026-10-24 12:53 ` [PATCH v3] " Aman Sharma
2026-10-27 9:31 ` Jani Nikula
2026-10-27 15:13 ` ✗ LGCI.VerificationFailed: failure for drm/i915/hdmi: preserve cached EDID on DDC failure when connector is forced (rev2) Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-183708@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=amansharma6122002@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.