]> Gentwo Git Trees - linux/.git/commit
drm/i915/vrr: Store guardband in crtc state even for icl/tgl
authorVille Syrjälä <ville.syrjala@linux.intel.com>
Wed, 17 Sep 2025 20:34:44 +0000 (23:34 +0300)
committerVille Syrjälä <ville.syrjala@linux.intel.com>
Thu, 18 Sep 2025 20:42:15 +0000 (23:42 +0300)
commit291ddb993ac967a519cdb5394fd06871b9fa74bf
treef2fb5af6a81529248c6f5a7584b93cd17de50d91
parent6559ca4a42d7976497fcf49e4c4fad9639fc1f76
drm/i915/vrr: Store guardband in crtc state even for icl/tgl

While ICL/TGL VRR hardware doesn't have a register for the guardband
value, our lives will be simpler if we pretend that it does. Start
by computing the guardband the same as on ADL+ and storing it in
the state, and only then we convert it into the corresponding
pipeline_full value that the hardware can consume. During readout we
do the opposite.

I was debating whether to completely remove pipeline_full from the
crtc state, but decided to keep it for now. Mainly because we check
it in vrr_params_changed() and simply checking the guardband instead
isn't 100% equivalent; Theoretically, framestart_delay may have
changed in the opposite direction to pipeline_full, keeping the
derived guardband value unchaged. One solution would be to also check
framestart_delay, but that feels a bit leaky abstraction wise.

Also note that we don't currently handle the maximum limit of 255
scanlines for the pipeline_full in a very nice way. The actual
position of the delayed vblank will move because of that clamping,
and so some of our code may get confused. But fixing this shall
wait a for now.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250917203446.14374-4-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
drivers/gpu/drm/i915/display/intel_display.c
drivers/gpu/drm/i915/display/intel_vrr.c