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 <[email protected]> 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/[email protected]?part=1
