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: 5+ 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox