The sharpness property requires the use of one of the scaler
so need to set the sharpness scaler coefficient values.
These values are based on experiments and vary for different
tap value/win size. These values are normalized by taking the
sum of all values and then dividing each value with a sum.
Add helper to compute and set the scaler coefficients.
v2: Fix ifndef header naming issue reported by kernel test robot
v3: Rename file name[Arun]
Replace array size number with macro[Arun]
v4: Correct the register format[Jani]
Add brief comment and expalin about file[Jani]
Remove coefficient value from crtc_state[Jani]
v5: Fix build issue
v6: Add new function for writing coefficients[Ankit]
v7: Add cooments and add a scaler id check [Ankit]
v8: Remove casf_enable from here[Ankit]
v9: Removed REG and use shift operator[Jani]
v10: Remove filter macros
v11: Add casf_write_coeff function to casf_enable
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251028120747.3027332-6-ankit.k.nautiyal@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add the register bits related to filter lut values
and helper to load the casf filter lut.
These values are golden values and these value has
to be loaded one time while enabling the casf.
v2: update commit message[Ankit]
v3: Add intel_casf prefix to filter_load fn[Jani]
v4: Define the filter macros here
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251028120747.3027332-5-ankit.k.nautiyal@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add register definitions for sharpness strength and
filter window size used by CASF. Provide functions to
read and write these fields.
The sharpness strength value is determined by user input,
while the winsize is based on the resolution. The casf_enable
flag should be set if the platform supports sharpness adjustments
and the user API strength is not zero. Once sharpness is
enabled, update the strength bit of the register whenever
the user changes the strength value, as the enable bit and
winsize bit remain constant.
Introduce helper to enable, disable and update strength.
Add relavant strength and winsize in both enable and disable.
v2: Introduce get_config for casf[Ankit]
v3: Replace 0 with FILTER_STRENGTH_MASK[Ankit]
v4: After updating strength add win_sz register
v5: Replace u16 with u32 for total_pixel
v6: Add casf logging
v7: Add helper for enable and disable casf
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251028120747.3027332-4-ankit.k.nautiyal@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Introduce a new crtc property "SHARPNESS_STRENGTH" that allows
the user to set the intensity so as to get the sharpness effect.
The value of this property can be set from 0-255.
It is useful in scenario when the output is blurry and user
want to sharpen the pixels. User can increase/decrease the
sharpness level depending on the content displayed.
v2: Rename crtc property variable [Arun]
Add modeset detail in uapi doc[Uma]
v3: Fix build issue
v4: Modify the subject line[Ankit]
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Tested-by: Adarsh G M <Adarsh.g.m@intel.com>
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://invent.kde.org/plasma/kwin/-/merge_requests/7689
Link: https://patch.msgid.link/20251028120747.3027332-2-ankit.k.nautiyal@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We started seeing "[drm] *ERROR* Timed out waiting PSR idle state" after
taking optimized guardband into use. These are seen because VSC SDPs are
sent on same line as AS SDPs when AS SDP is enabled. AS SDP is sent on line
configured in EMP_AS_SDP_TL register. We are configuring
crtc_state->vrr.vsync_start into that register.
Fix this by ensuring AS SDP is sent on line which is within
guardband. From the bspec:
EMP_AS_SDP_TL < SCL + Guardband
v2: check HAS_AS_SDP
Bspec: 71197
Fixes: 52ecd48b8d ("drm/i915/dp: Add helper to get min sdp guardband")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20251023043140.961104-1-jouni.hogander@intel.com
The reason for enabling FEC for an uncompressed stream on an MST link is
that the DSC compression is enabled for another stream on the same link.
For such an uncompressed stream FEC doesn't need to be supported on the
whole path until the (DP-SST) sink DPRX. For instance if a branch device
- like a monitor with an MST branch device within it - is plugged to a
DFP connector of an MST docking station and the monitor's branch
device does not support FEC, the docking station's branch device will
still enable the link to the monitor correctly, disabling the FEC on
that link as expected. Since it's been verified already that FEC is
supported for the compressed stream above, the corresponding check for
the uncompressed stream can be dropped: the check for the compressed
stream implies already that FEC is supported on the link between the
source DPTX and immediate downstream branch device. If FEC is not
supported on the whole path until the sink DPRX, FEC will be disabled by
a downstream branch device on the path as described above for the MST
dock + MST monitor configuration example.
This fixes a problem in the above MST dock + MST monitor example, where
the dock supports FEC, but the monitor doesn't support it and FEC gets
enabled on the link due to DSC getting enabled for another monitor's
stream on the same link.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14254
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251028113536.602352-1-imre.deak@intel.com
In cases where the requested minimum CDCLK exceeds all available
values for the current reference clock, the CDCLK selection logic
previously returned 0. This could result coverity division or
modulo by zero issue.
Introduce a fallback mechanism that returns platform's max_cdclk_freq
instead of 0.
v2: Update safe fallback value to max cdclk. (Ville)
v3: Update commit messgae (Mika)
Signed-off-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20251017150526.781715-1-ramanaidu.naladala@intel.com
Use the similar logic in skl_plane_has_planar(),
glk_plane_has_planar() and skl_plane_has_rc_ccs() to avoid
having to think too much when comparing the three.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251009211313.30234-9-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Extract glk_plane_has_planar() out from skl_plane_has_planar()
to make the logic a bit less convoluted.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251009211313.30234-8-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
We don't need to check for crtc hw.enable because that would also
imply that the plane is disabled and we would have bailed out already
earlier.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251009211313.30234-7-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Make the skl+ plane size checks a bit more regular by
adding intel_plane_min_height() instead of using a hardcoded
1 everwhere.
v2: s/1/min_height/ one more time
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251009211313.30234-6-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Currently we check the plane min size only for the Y plane.
Extend the check to the CbCr plane as well.
This will also allow us to remove the planar format check from
icl_plane_min_width() since the +2 on the CbCr plane is equivalent
to +4 on the Y plane. I suspect this approach actually models the
hardware issue more accurately.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251009211313.30234-5-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
ADL+ no longer need the plane min width w/a (Wa_14011264657 or
Wa_14011050563). Don't apply it there. DG2 still needs it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251009211313.30234-3-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
There's no point in doing all the other checks in
intel_vrr_is_capable() if the platform doesn't support VRR at all
Check HAS_VRR() before wasting time on the other checks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-23-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
The coment in intel_vrr_extra_vblank_delay() is a bit outdated now
that we generally got rid of the "vblank delay" stuff. Update the
comment to better describe the current state of things.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-22-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
We generally use the 'old_crtc_state' in the disable functions to
make it clear these generally get called when the hardware is
still using the old crtc state rather than the new crtc state.
Rename the intel_vrr_transcoder_disable() 'crtc_state' parameter
to 'old_crtc_state' for consistency.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-19-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Currently, depending on vrr.enable, we may write TRANS_VRR_CTL from
both intel_vrr_set_transcoder_timings() and intel_vrr_transcoder_enable()
on !always_use_vrr_tg() platforms. Streamline this so that we just
always write it from intel_vrr_set_transcoder_timings(), and
never from intel_vrr_transcoder_enable().
The main benefit is that intel_vrr_transcoder_enable() becomes symmetric
to intel_vrr_transcoder_disable().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-16-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Currently we always disable the VRR timing generator in
intel_vrr_transcoder_disable(). But doing so on !always_use_vrr_tg()
platforms is redundant since we've alreayd disabled the VRR timing
generator earlier in intel_vrr_disable(). Do the disable in
intel_vrr_transcoder_disable() only on always_on_vrr_tg() platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-15-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Extract the VRR timing generator enable into intel_vrr_tg_enable(),
as a counterpart to intel_vrr_tg_disable().
Note that the CMRR part is probably broken, but so are other
things in the CMRR implementation, and thus it is currently
disabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-14-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Currently intel_vrr_disable() writes TRANS_VRR_CTL() with
trans_vrr_ctl(), whereas intel_vrr_transcoder_disable() always
writes just a plain 0. Write trans_vrr_ctl() in both places to
unify the code, allowing for more shared code in the future.
Since the VRR timing generator will be disabled by the
TRANS_VRR_CTL write it doesn't really matter what we write to
the register (other than VRR_CTL_VRR_ENABLE that is).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-12-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
EMP_AS_SDL_TL replaces the TRANS_VRR_VSYNC for the purposes of
setting the AS SDP transmission line. Move the EMP_AS_SDL_TL into
intel_vrr_set_transcoder_timings() since that's where we write
TRANS_VRR_VSYNC as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-11-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
The way intel_vrr_compute_*_timings() works is rather confusing.
First intel_vrr_compute_config() assigns the computed vmin/vmax
into crtc_state->vrr.{vmin,vmax}, and then either
intel_vrr_compute_vrr_timings() leaves them untouched or
intel_vrr_compute_{cmrr,fixed_rr}_timings() overwrite them with
something else.
Clean this up by moving all crtc_state->vrr.{vmin,vmax} assignments
into intel_vrr_compute_*_timings().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-7-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
The "vblank delay" we are including in the crtc state dump is
meaningful only when running with fixed refresh rate timings.
With VRR timings one has to look at the VRR state to figure out
the same thing.
Since we already dump the position of the delayed vblank for
both fixed refresh rate and VRR timings, this "vblank delay"
thing seems pretty much pointless now. Get rid of it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-4-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
If SCL is changing we need to take the LRR codepath to update
it during a fastset. Account for that in lrr_params_changed().
The current code will only notice the SCL change if the position
of the delayed vblank also changes. But that might not happen
when using the VRR timing generator because the delayed vblank
is then defined by the guardband instead of the SCL.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-3-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
On TGL the hardware always needs TRANS_VBLANK.VBLANK_START
to be programemd with VACTIVE+SCL. Make it so.
The current way of programming it with crtc_vblank_start only
works for the legacy timing generator, as there the delayed
vblank does happen exactly at VACTIVE+SCL.
But if one tries to change intel_vrr_always_use_vrr_tg() to
always use the VRR timing generator on TGL, crtc_vblank_start
will point to the VRR timing generator's delayed vblank,
which may not match VACTIVE+SCL.
Fortunately the state checker caught the issue right away
when I tried intel_vrr_always_use_vrr_tg()==true on TGL.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-2-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
xe_device.h and xe_device_has_flat_ccs() are no longer needed since
commit 3a5c5c472c ("drm/i915/display: add HAS_AUX_CCS() feature
check").
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251022121450.452649-2-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We've stopped using struct drm_i915_private in intel_fb.c and
skl_universal_plane.c, so we can drop the i915_drv.h includes.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251022121450.452649-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
DMC_EVT_CTL_ENABLE cannot be cleared once set. So currently
any event we never enable will have DMC_EVT_CTL_ENABLE cleared,
whereas any event which has been enabled even once will have
DMC_EVT_CTL_ENABLE set. For that reason assert_dmc_loaded() has
a special case to ignore any mismatches in DMC_EVT_CTL_ENABLE.
Eliminate the special case by always configuring DMC_EVT_CTL_ENABLE
based on the original firmware event definition. Now all
event handlers will have DMC_EVT_CTL_ENABLE set, whether or
not the event has been enabled in the past.
All disabled event handlers will still have the event type set
to DMC_EVENT_FALSE so they will not actually trigger despite
DMC_EVT_CTL_ENABLE being set.
Tested-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251022100718.24803-4-ville.syrjala@linux.intel.com
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Imre Deak <imre.deak@intel.com>
TGL/ADL-S DMC firmware incorrectly uses the undelayed vblank
trigger for the HRR event, when it should be using the delayed
vblank trigger.
Fixed DMC firmware was never relaesed and isntead the Windows
driver just fixes this up by hand. Follow suit.
Not that we actually enable the HRR event currently. But let's
fix up the event ID, just in case someone ever needs to enable
this.
Tested-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251022100718.24803-3-ville.syrjala@linux.intel.com
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Imre Deak <imre.deak@intel.com>
On ADL-S the main DMC HRR event DMC_EVT_CTL/HTP are never
restored to their previous values during DC6 exit. This
angers assert_dmc_loaded(), and basically makes the HRR
handler unusable because we don't rewrite EVT_HTP when
enabling DMC events.
Let's just clear the HRR EVT_CTL/HTP to zero from the
beginnning so that the expected value matches the post-DC6
reality.
I suppose if we ever had actual use for HRR we'd have to both,
reject HRR+PSR, and reprogram EVT_HTP when enabling the event.
But for now we don't care about HRR so keeping both registers
zeroed is fine.
Cc: stable@vger.kernel.org
Tested-by: Petr Vorel <pvorel@suse.cz>
Fixes: 43175c92d4 ("drm/i915/dmc: Assert DMC is loaded harder")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15153
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251022100718.24803-2-ville.syrjala@linux.intel.com
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Imre Deak <imre.deak@intel.com>
The intel_crtc_state::fec_enable check in intel_dp_needs_8b10b_fec() is
redundant drop it: originally it ensured that the FEC enabled state for
a CRTC other than the CRTC intel_dp_needs_8b10b_fec() called for is
preserved, even if DSC is not enabled for the latter CRTC. The way FEC
gets enabled for all the CRTCs on an 8b10b MST link is changed by
commit 7c027070e9 ("drm/i915/dp_mst: Track DSC enabled status on the
MST link") and
commit 470b84af45 ("drm/i915/dp_mst: Recompute all MST link CRTCs if
DSC gets enabled on the link")
depending on intel_dsc_enabled_on_link() in intel_dp_needs_8b10b_fec()
instead of the above fec_enable check. Drop the check.
Suggested-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20251020154438.416761-1-imre.deak@intel.com
There is no reason in debugfs why PSR has been disabled. Currently,
without this information, IGT tests cannot decide whether PSR has
been disabled on purpose or was it abnormal behavior. Because of it,
the status of the test cannot be decided correctly.
Add no_psr_reason field into struct intel_psr. Add no_psr_reason
into struct intel_crtc_state to prevent staying out of sync when
_psr_compute_config is not using computed state. Write the reason,
e.g. PSR setup timing not met, into proper PSR debugfs file. Update
the reason from new_crtc_state in intel_psr_pre_plane_update. Extend
format of debugfs file to have reason when it is non-NULL. Clean the
reason when PSR is activated.
Refactor intel_psr_post_plane_update to use no_psr_reason along
keep_disabled.
Changelog:
v10->v11
- update the reason from new_crtc_state instead of old_crtc_state [Jouni]
v9->v10
- log reason into intel_crtc_state instead of intel_dp->psr [Jouni]
- remove clearing no_psr_reason in intel_psr_compute_config [Jouni]
- change update of no_psr_reason into more readable form [Jouni]
v8->v9
- add no_psr_reason into struct intel_crtc_state [Jouni]
- update the reason in intel_psr_pre_plane_update [Jouni]
- elaborate on motivation of the feature in commit message [Sebastian]
- copy changelog to commit message [Sebastian]
v7->v8
- reset no_psr_reason at the begin of intel_psr_compute_config [Jouni]
- restore keep_disabled [Jouni]
- drop setting "Sink not reliable" [Jouni]
- add WA number [Jouni]
- if non-NULL, write no_psr_reason after PSR mode [Jouni]
v6->v7
- rebase onto new drm-tip
v5->v6
- move setting no_psr_reason to intel_psr_post_plane_update [Jouni]
- remove setting no_psr_reason when disabling PSR is temporary [Jouni]
v4->v5
- fix indentation errors from checkpatch
v3->v4
- change format of logging workaround #1136
v2->v3
- change reason description to be more specific [Mika]
- remove BSpecs number & WA number from being written into no_psr_reason
- replace spaces with tabs
v1->v2
- set other reasons than "PSR setup timing not met"
- clear no_psr_reason when activating PSR.
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20251002095640.1347990-2-michal.grzelak@intel.com
Currently the guardband is optimized only for platforms where the
VRR timing generator is always ON.
Extend the usage of optimized guardband to all VRR supporting platforms.
v2: Drop check for `crtc_state->vrr.enable` and just return true
unconditionally from intel_vrr_use_optimized_guardband(). (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20251017123504.2247954-6-ankit.k.nautiyal@intel.com
In the current VRR implementation, vrr.vmin and vrr.guardband are set such
that they do not need to change when switching from fixed refresh rate to
variable refresh rate. Specifically, vrr.guardband is always set to match
the vblank length. This approach works for most cases, but not for LRR,
where the guardband would need to change while the VRR timing generator is
still active.
With the VRR TG always active, live updates to guardband are unsafe and not
recommended. To ensure hardware safety, guardband was moved out of the
!fastset block, meaning any change now requires a full modeset.
This breaks seamless LRR switching, which was previously supported.
Since the problem arises from guardband being matched to the vblank length,
solution is to use a minimal, sufficient static value, instead. So we use a
static guardband defined during mode-set that fits within the smallest
expected vblank and remains unchanged in case of features like LRR where
vtotal changes. To compute this minimum guardband we take into account
latencies/delays due to different features as mentioned in the Bspec.
Introduce a helper to compute the minimal sufficient guardband.
On platforms where the VRR timing generator is always ON, we optimize the
guardband regardless of whether the display is operating in fixed or
variable refresh rate mode.
v2:
- Use max of sagv latency and skl_wm_latency(1) for PM delay
computation. (Ville)
- Avoid guardband optimization for HDMI for now. (Ville)
- Allow guardband optimization only for platforms with
intel_vrr_always_use_vrr_tg = true. (Ville)
- Add comments for PM delay and a #TODO note for HDMI.
v3: Drop the variable prefill_min_guardband. (Ville)
Bspec: 70151
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20251017123504.2247954-5-ankit.k.nautiyal@intel.com
