diff options
| author | Ville Syrjälä <ville.syrjala@linux.intel.com> | 2025-09-17 23:34:44 +0300 |
|---|---|---|
| committer | Ville Syrjälä <ville.syrjala@linux.intel.com> | 2025-09-18 23:42:15 +0300 |
| commit | 291ddb993ac967a519cdb5394fd06871b9fa74bf (patch) | |
| tree | f2fb5af6a81529248c6f5a7584b93cd17de50d91 /tools/perf/scripts/python/stackcollapse.py | |
| parent | 6559ca4a42d7976497fcf49e4c4fad9639fc1f76 (diff) | |
| download | linux-291ddb993ac967a519cdb5394fd06871b9fa74bf.tar.gz linux-291ddb993ac967a519cdb5394fd06871b9fa74bf.zip | |
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>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions
