Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] drm: VTEM infoframe not cleared when switching to non-VRR sink --
commit 5a4e1a050c5d27ea6b13e207c2d853adeb273ef9 Author: Derek Foreman <[email protected]> drm/connector: hdmi: Add VTEM EMP generation This commit adds VTEM EMP generation to enable variable refresh rate signalling over HDMI. The infoframes are generated if the sink supports VRR. > diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c > b/drivers/gpu/drm/display/drm_hdmi_state_helper.c > index d555483996874..33d0c94916430 100644 > --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c > +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c [ ... ] > @@ -1494,6 +1548,12 @@ int > drm_atomic_helper_connector_hdmi_update_infoframes(struct drm_connector *con > goto out; > } > > + if (info->hdmi.vrr_capable) > + ret = write_or_clear_infoframe(connector, > + &funcs->vtem, "VTEM", > + &old_conn_state->hdmi.infoframes.vtem, > + &new_conn_state->hdmi.infoframes.vtem); > + > out: > mutex_unlock(&connector->hdmi.infoframes.lock); > return ret; [Severity: Medium] What happens if a VRR-capable sink is disconnected and replaced by a non-VRR sink? If info->hdmi.vrr_capable becomes false, the guard in drm_atomic_helper_connector_hdmi_update_infoframes() evaluates to false and skips write_or_clear_infoframe() for VTEM. This means the hardware is never commanded to clear the VTEM infoframe via funcs->clear_infoframe(), leading to stale VTEM packets being continuously transmitted to a sink that does not support them. Could this cause a hardware state mismatch and potential compliance issues? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
