dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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