Hi,
A Panther Lake eDP panel is streaked with vertical bands from the first modeset
at boot on 7.2.x, and clean on 7.1.13. The only measurable difference I can find
is that the AS SDP is now programmed on a link that is not running VRR, and I
have confirmed that this is exactly the field the new predicate reads:
drivers/gpu/drm/i915/display/intel_dp.c:3226 (v7.2.6; :3119 on mainline)
return intel_vrr_possible(crtc_state); /* was: crtc_state->vrr.enable
*/
with
bool intel_vrr_possible(const struct intel_crtc_state *crtc_state)
{
return crtc_state->vrr.flipline;
}
On this panel flipline is programmed for a fixed refresh rate as well, so the
predicate is non-zero with VRR off. All 34 of the fixed-refresh state dumps I
have, across 7.1.13, 7.2.4 and 7.2.6, read
vrr: no, fixed rr: yes, vmin: 2016, vmax: 2016, flipline: 2016,
pipeline full: 0, ...
including the runs where the VRR state itself was not stable.
I rebuilt only xe.ko from the 7.2.6 tree with that one line restored, signed it,
and loaded it in place of the distribution module. The streak is gone at the
first modeset. Same kernel, same firmware, same compositor, same panel - the
module is the only variable - and the loaded module is identified by build-id
rather than assumed, because vermagic matches for any build of the same kernel.
The full report, with the state dumps, log excerpts, the commit list and
everything that is still open, is the work item:
https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/9252
The raw drm.debug=0xe logs and the source snapshots are attachments there, so I
am not attaching them here.
Two things I would rather state than leave to be found:
- This removes the fixed-refresh trigger only. While VRR is actually active,
crtc_state->vrr.enable is already true, so the change is a no-op on that
path, and I have not isolated the VRR-active path in testing.
- The non-determinism on suspend/resume is not explained by this. There is a
#FIXME inside intel_dp_compute_as_sdp() saying that SDP/infoframe updates
"aren't truly atomic, and with the new cdclk->tc clock crossing we may
transiently send a corrupted packet if the update lands mid-transmission".
That is my candidate, but it is a guess and I have not instrumented the
window.
The patch follows as a separate mail, since it stands on its own.
Thanks,
Xizhe Tang
