Suraj Kandpal [Sat, 1 Nov 2025 03:24:58 +0000 (08:54 +0530)]
drm/i915/ltphy: Update the ltpll config table value for eDP
When we get the eDP tables we reuse dp tables for some data rates.
We need to modify the 3rd config value of this table to 1 instead
of 0 since that is the only difference in the dp and edp table for
that particular data rate.
Suraj Kandpal [Sat, 1 Nov 2025 03:24:55 +0000 (08:54 +0530)]
drm/i915/ltphy: Read PHY_VDR_0_CONFIG register
Read PHY_VDR_0_CONFIG to check if there is any change in the register and
decide based on that if P2P sequence to change the data rate of LT PHY
are required or not. This scenario only happens if the requested mode
uses 1.62Gbps with DP mode since LT PHY defaults to this mode if
any other mode is requested we need to follow the whole sequence.
Suraj Kandpal [Sat, 1 Nov 2025 03:24:51 +0000 (08:54 +0530)]
drm/i915/ltphy: Phy lane reset for LT Phy
Define function to bring phy lane out of reset for LT Phy and the
corresponding pre-requisite steps before we follow the steps for
Phy lane reset. Also create a skeleton of LT PHY PLL enable sequence
function in which we can place this function
drm/i915/xe3p_lpd: use pixel normalizer for fp16 formats for FBC
There is a hw restriction that we could enable the FBC for FP16
formats only if the pixel normalization block is enabled. Hence
enable the pixel normalizer block with normalzation factor as
1.0 for the supported FP16 formats to get the FBC enabled. Two
existing helper function definitions are moved up to avoid the
forward declarations as part of this patch as well.
v2: sw/hw state differentiation on handling pixel normalizer (Jani)
drm/i915/xe3p_lpd: extract pixel format valid routine for FP16 formats
As the pixel normalizer block is needed only for the FP16 formats,
separating out the FP16 formats handling will benefit in selectively
enabling the pixel normalizer block in the following patch.
drm/i915/xe3p_lpd: Add FBC support for FP16 formats
Add supported FP16 formats for FBC. FBC can be enabled with
FP16 formats only when plane pixel normalizer block is enabled.
The follow up patches will handle the pixel normalizer block
configuration.
v2: changes related to comments to use better tracking of pixel
normalizer
drm/i915/xe3p_lpd: Extend FBC support to UINT16 formats
Starting Xe3p_LPD, FBC is supported on UINT16 formats as well. Also
UINT16 being a 64bpp format, will use cpp of 8 for cfb stride and thus
size calculations.
v2: simplify getting the cpp per format (Ville)
simplify the pixel format is valid for xe3p_lp (Vinod)
Jani Nikula [Wed, 22 Oct 2025 15:17:14 +0000 (18:17 +0300)]
drm/xe/compat: reduce i915_utils.[ch]
Reduce the compat i915_utils.h to only cover the requirements of
MISSING_CASE() in soc/ and the few i915_inject_probe_failure()
instances, instead of including the entire i915_utils.h from i915. This
prevents new users for the utilities from cropping up.
With this, we can remove the xe/display/ext/i915_utils.c altogether.
Jani Nikula [Wed, 22 Oct 2025 15:17:13 +0000 (18:17 +0300)]
drm/i915/display: switch to intel_display_utils.h
The remaining utils display needs from i915_utils.h are primarily
MISSING_CASE() and fetch_and_zero(), with a couple of
i915_inject_probe_failure() uses.
To avoid excessive churn, add duplicates of MISSING_CASE() and
fetch_and_zero() to intel_display_utils.h, and switch display to use the
display utils.
As long as there are display files that include i915_drv.h, which
includes i915_utils.h, we'll need #ifndef guards for MISSING_CASE() and
fetch_and_zero() in both utils headers. We can remove them once display
no longer depends on i915_drv.h.
A couple of files in display still need i915_utils.h for
i915_inject_probe_failure(). Annotate this. They will be handled
separately.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patch.msgid.link/79f9e31ca64c8c045834d48e20ceb0c515d1e9e1.1761146196.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Wed, 22 Oct 2025 15:17:12 +0000 (18:17 +0300)]
drm/i915/display: add intel_display_vtd_active()
Add intel_display_vtd_active() to utils. It's intentional duplication
with i915_utils.h i915_vtd_active(), but reduces duplication with
xe. Win some, lose some.
Add intel_display_utils.c for display utilities that need more than a
header.
Start off with intel_display_run_as_guest(). The implementation is
intentional duplication of the i915_utils.h i915_run_as_guest(), with
the idea that it's small enough to not matter.
Jani Nikula [Wed, 22 Oct 2025 15:17:09 +0000 (18:17 +0300)]
drm/i915: split out separate files for jiffies timeout and wait helpers
Add i915_jiffies.h and intel_display_jiffies.h for jiffies timeout and
wait helpers, and use them separately from i915 and display. This helps
reduce the display dependency on i915_utils.h.
Long term, both msecs_to_jiffies_timeout() and
wait_remaining_ms_from_jiffies() really belong in core kernel headers,
but for now unblock display refactoring.
Expose the drm crtc sharpness strength property which will enable
or disable the sharpness/casf based on user input. With this user
can set/update the strength of the sharpness or casf filter.
Nemesa Garg [Tue, 28 Oct 2025 12:07:45 +0000 (17:37 +0530)]
drm/i915/display: Enable/disable casf
Call intel_casf_enable and intel_casf_disable
in atomic commit path to enable and disable casf.
Call intel_casf_update_strength to only update
the desired strength value.
v2: Introduce casf_enable here.[Ankit]
v3: Use is_disabling in casf_disabling.[Ankit]
v4: Swap old_state and new_state param.[Ankit]
v5: In disable fn move win_sz after sharpness_ctl.
v6: Rebase and update commit message.
Nemesa Garg [Tue, 28 Oct 2025 12:07:44 +0000 (17:37 +0530)]
drm/i915/display: Set and get the casf config
Set the configuration for CASF and capture it
in crtc_state and get the configuration by
reading back. Add the support to compare the
software and hardware state of CASF.
v2: Update subject[Ankit]
v3: Add the state compare[Ankit]
Nemesa Garg [Tue, 28 Oct 2025 12:07:43 +0000 (17:37 +0530)]
drm/i915/display: Configure the second scaler
Both sharpness and panel fitter use pipe scaler,
but only one can be enabled at a time. Furthermore
sharpness uses second scaler. So for CASF, check if
second scaler is available and make sure that only
either of panel fitter or sharpness is enabled at
a time.
v2: Add the panel fitting check before enabling sharpness
v3: Reframe commit message[Arun]
v4: Replace string based comparison with plane_state[Jani]
v5: Rebase
v6: Fix build issue
v7: Remove scaler id from verify_crtc_state[Ankit]
v8: Change the patch title. Add code comment.
Move the config part in patch#6. [Ankit]
v9: Refactor the patch[Ankit]
v10: Modify the header of patch[Ankit]
Nemesa Garg [Tue, 28 Oct 2025 12:07:41 +0000 (17:37 +0530)]
drm/i915/display: Compute the scaler coefficients
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
Nemesa Garg [Tue, 28 Oct 2025 12:07:39 +0000 (17:37 +0530)]
drm/i915/display: Add CASF strength and winsize
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
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.
Jouni Högander [Thu, 23 Oct 2025 04:31:40 +0000 (07:31 +0300)]
drm/i915/display: Take into account AS SDP in intel_dp_sdp_min_guardband
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: 52ecd48b8d3f ("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
Imre Deak [Tue, 28 Oct 2025 11:35:36 +0000 (13:35 +0200)]
drm/i915/dp_mst: Fix check for FEC support for an uncompressed stream
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.
drm/i915: Add fallback for CDCLK selection when min_cdclk is too high
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)
Ville Syrjälä [Thu, 9 Oct 2025 21:13:12 +0000 (00:13 +0300)]
drm/i915: Unify the logic in {skl,glk}_plane_has_*()
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.
Ville Syrjälä [Thu, 9 Oct 2025 21:13:08 +0000 (00:13 +0300)]
drm/i915: Start checking plane min size for the chroma plane
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.
Ville Syrjälä [Mon, 20 Oct 2025 18:50:38 +0000 (21:50 +0300)]
drm/i915/vrr: Check HAS_VRR() first in intel_vrr_is_capable()
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.
Ville Syrjälä [Mon, 20 Oct 2025 18:50:37 +0000 (21:50 +0300)]
drm/i915/vrr: Update the intel_vrr_extra_vblank_delay() comment
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.
Ville Syrjälä [Mon, 20 Oct 2025 18:50:36 +0000 (21:50 +0300)]
drm/i915/vrr: Nuke intel_vrr_vmin_flipline()
Now that intel_vrr_flipline_offset() is completely hidden from the
higher level VRR code, intel_vrr_vmin_flipline() has become rather
pointless. Remove it.
Ville Syrjälä [Mon, 20 Oct 2025 18:50:34 +0000 (21:50 +0300)]
drm/i915/vrr: s/crtc_state/old_crtc_state/ in intel_vrr_transcoder_disable()
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.
Ville Syrjälä [Mon, 20 Oct 2025 18:50:31 +0000 (21:50 +0300)]
drm/i915/vrr: Always write TRANS_VRR_CTL in intel_vrr_set_transcoder_timings() on !always_use_vrr_tg()
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().
Ville Syrjälä [Mon, 20 Oct 2025 18:50:30 +0000 (21:50 +0300)]
drm/i915/vrr: Disable VRR TG in intel_vrr_transcoder_disable() only on always use_vrr_tg() platforms
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.
Ville Syrjälä [Mon, 20 Oct 2025 18:50:27 +0000 (21:50 +0300)]
drm/i915/vrr: Use trans_vrr_ctl() in intel_vrr_transcoder_disable()
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).
Ville Syrjälä [Mon, 20 Oct 2025 18:50:26 +0000 (21:50 +0300)]
drm/i915/vrr: Move EMP_AS_SDP_TL write into intel_vrr_set_transcoder_timings()
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.
Ville Syrjälä [Mon, 20 Oct 2025 18:50:22 +0000 (21:50 +0300)]
drm/i195/vrr: Move crtc_state->vrr.{vmin,vmax} update into intel_vrr_compute_vrr_timings()
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().
Ville Syrjälä [Mon, 20 Oct 2025 18:50:20 +0000 (21:50 +0300)]
drm/i915/vrr: Compute fixed refresh rate timings the same way as CMRR timings
Unify the VRR timing computation stuff a bit having both the
fixed refresh rate and CMRR cases assign the crtc_state->vrr
stuff in exactly the same way.
Ville Syrjälä [Mon, 20 Oct 2025 18:50:19 +0000 (21:50 +0300)]
drm/i915: Remove the "vblank delay" state dump
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.
Ville Syrjälä [Mon, 20 Oct 2025 18:50:18 +0000 (21:50 +0300)]
drm/i915/lrr: Include SCL in lrr_params_changed()
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.
Ville Syrjälä [Mon, 20 Oct 2025 18:50:17 +0000 (21:50 +0300)]
drm/i915/vrr: Fix intel_vrr_always_use_vrr_tg()==true on TGL
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.
For reasons still unknown, xe appears to require a stride alignment of
XE_PAGE_SIZE, and using 64 leads to sporadic failures. Go back to having
separate stride alignment for i915 and xe, until the issue is root
caused.
v2: Add FIXME comment, reference issue with Link (Ville)
Ville Syrjälä [Wed, 22 Oct 2025 10:07:18 +0000 (13:07 +0300)]
drm/i915/dmc: Set DMC_EVT_CTL_ENABLE for disabled event handlers as well
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.
Ville Syrjälä [Wed, 22 Oct 2025 10:07:16 +0000 (13:07 +0300)]
drm/i915/dmc: Clear HRR EVT_CTL/HTP to zero on ADL-S
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: 43175c92d403 ("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>
Imre Deak [Mon, 20 Oct 2025 15:44:38 +0000 (18:44 +0300)]
drm/i915/dp: Simplify intel_dp_needs_8b10b_fec()
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 7c027070e98d ("drm/i915/dp_mst: Track DSC enabled status on the
MST link") and
commit 470b84af457e ("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.
Michał Grzelak [Thu, 2 Oct 2025 09:56:40 +0000 (11:56 +0200)]
drm/i915/display: Add no_psr_reason to PSR debugfs
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
Ankit Nautiyal [Fri, 17 Oct 2025 12:35:03 +0000 (18:05 +0530)]
drm/i915/vrr: Use the min static optimized guardband
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)
Ankit Nautiyal [Fri, 17 Oct 2025 12:35:01 +0000 (18:05 +0530)]
drm/i915/dp: Add helper to get min sdp guardband
Add a helper to compute vblank time needed for transmitting specific
DisplayPort SDPs like PPS, GAMUT_METADATA, and VSC_EXT. Latency is
based on line count per packet type.
This will be used to ensure adequate guardband when features like DSC/HDR
are enabled.
v2: Correct the lines required for PPS SDP. (Jouni)
Ankit Nautiyal [Fri, 17 Oct 2025 12:35:00 +0000 (18:05 +0530)]
drm/i915/psr: Add helper to get min psr guardband
Introduce a helper to compute the max link wake latency when using
Auxless/Aux wake mechanism for PSR/Panel Replay/LOBF features.
This will be used to compute the minimum guardband so that the link wake
latencies are accounted and these features work smoothly for higher
refresh rate panels.
v2:
- Account for flag `req_psr2_sdp_prior_scanline` and scl lines while
computing min guardband. (Jouni)
- Use wake lines only for eDP with panel_replay and sel_update flags
set. (Jouni)
Imre Deak [Wed, 15 Oct 2025 16:19:34 +0000 (19:19 +0300)]
drm/i915/dp: Fix panel replay when DSC is enabled
Prevent enabling panel replay if the sink doesn't support this due to
DSC being enabled.
Panel replay has two modes, updating full frames or only selected
regions of the frame. If the sink doesn't support Panel Replay in full
frame update mode with DSC prevent Panel Replay completely if DSC is
enabled. If the sink doesn't support Panel Replay only in the selective
update mode while DSC is enabled, it will still support Panel Replay in
the full frame update mode, so only prevent selective updates in this
case.
v2:
- Use Panel Replay instead of PR in debug prints. (Jouni)
- Rebase on change tracking the link DSC state in the crtc state.
Imre Deak [Wed, 15 Oct 2025 16:19:33 +0000 (19:19 +0300)]
drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the link
The state of all the CRTCs on an MST link must be recomputed, if DSC
gets enabled on any of the CRTCs on the link. For instance an MST
docking station's Panel Replay capability may depend on whether DSC is
enabled on any of the dock's streams (aka CRTCs). To assist the Panel
Replay state computation for a CRTC based on the above, track in the
CRTC state if DSC is enabled on any CRTC on an MST link.
The intel_link_bw_limits::force_fec_pipes mask is used for a reason
similar to the above: enable FEC on all CRTCs of a non-UHBR (8b10b) MST
link if DSC is enabled on any of the link's CRTCs. The FEC enabled state
for a CRTC doesn't indicate if DSC is enabled on a UHBR MST link (FEC is
always enabled by the HW for UHBR, hence it's not tracked by the
intel_crtc_state::fec_enable flag for such links, where this flag is
always false).
Based on the above, to be able to determine the DSC state on both
non-UHBR and UHBR MST links, track the more generic DSC-enabled-on-link
state (instead of the FEC-enabled-on-link state) for each CRTC in
intel_link_bw_limits.
Imre Deak [Wed, 15 Oct 2025 16:19:32 +0000 (19:19 +0300)]
drm/i915/dp_mst: Track DSC enabled status on the MST link
Track whether DSC is enabled on any CRTC on a link. On DP-SST (and DSI)
this will always match the CRTC's DSC state, those links having only a
single stream (aka CRTC). For instance, on DP-MST if DSC is enabled for
CRTC#0, but disabled for CRTC#1, the DSC/FEC state for these CRTCs will
be as follows:
CRTC#0:
- compression_enable = true
- compression_enabled_on_link = true
- fec_enable = true for 8b10b, false for 128b132b
CRTC#1:
- compression_enable = false
- compression_enabled_on_link = true
- fec_enable = true for 8b10b, false for 128b132b
This patch only sets compression_enabled_on_link for CRTC#0 above and
enables FEC on CRTC#0 if DSC was enabled on any other CRTC on the 8b10b
MST link. A follow-up change will make sure that the state of all the
CRTCs (CRTC#1 above) on an MST link is recomputed if DSC gets enabled on
any CRTC, setting compression_enabled_on_link and fec_enable for these.
Imre Deak [Wed, 15 Oct 2025 16:19:30 +0000 (19:19 +0300)]
drm/i915/dp: Export helper to determine if FEC on non-UHBR links is required
Export the helper function to determine if FEC is required on a non-UHBR
(8b10b) SST or MST link. A follow up change will take this into use for
MST as well.
While at it determine the output type from the CRTC state, which allows
dropping the intel_dp argument. Also make the function return the
required FEC state, instead of setting this in the CRTC state, which
allows only querying this requirement, without changing the state.
Also rename the function to intel_dp_needs_8b10b_fec(), to clarify that
the function determines if FEC is required on an 8b10b link (on 128b132b
links FEC is always enabled by the HW implicitly, so the function will
return false for that case).
Imre Deak [Wed, 15 Oct 2025 16:19:29 +0000 (19:19 +0300)]
drm/i915/dp: Ensure the FEC state stays disabled for UHBR links
Atm, in the DP SST case the FEC state is computed before
intel_crtc_state::port_clock is initialized, hence intel_dp_is_uhbr()
will always return false and the FEC state will be always computed
assuming a non-UHBR link.
This happens to work, since the FEC state is recomputed later in
intel_dp_mtp_tu_compute_config(), where port_clock will be set already,
so intel_crtc_state::fec_enable will be reset as expected for UHBR. This
also depends on link rates being tried in an increasing order (i.e. from
non-UHBR -> UHBR link rates) in dsc_compute_link_config(), thus
intel_crtc_state::fec_enable being set for the non-UHBR rates and
getting reset for the first UHBR rate as expected.
A follow-up change will reuse intel_dp_fec_compute_config() for the DP
MST state computation, prepare for that here, making sure that the
function determines the correct intel_crtc_state::fec_enable=false state
for UHBR link rates based on the above.
The DP SST and MST state computation should be further unified to avoid
computing/setting the intel_crtc_state::fec_enable state multiple times,
but that's left for a follow-up change. For now add only code comments
about this.
Imre Deak [Wed, 15 Oct 2025 16:19:28 +0000 (19:19 +0300)]
drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC
Add a helper to enable the DSC compression configuration for a CRTC.
Follow-up changes will introduce tracking for the same DSC state on the
whole link, which will need to be set whenever DSC is enabled for the
CRTC. Also, according to the above, when querying the DSC state on the
link, both the CRTC's and the link's DSC state must be considered.
Setting the DSC configuration for a CRTC and querying the DSC
configuration for the link (added by follow-up changes) is better done
via helper functions based on the above, prepare for that here.
Ville Syrjälä [Mon, 13 Oct 2025 20:12:34 +0000 (23:12 +0300)]
drm/i915: Compute per-crtc min_cdclk earlier
Currently we compute the min_cdclk for each pipe during
intel_cdclk_atomic_check(). But that is too late for the
pipe prefill vs. vblank length checks (done during
intel_compute_global_watermarks).
We can't just reorder these things due to other dependencies,
so instead pull only the per-crtc minimum cdclk calculation
ahead. We should have enough information for that as soon
as we've computed the min cdclk for the planes.
Ville Syrjälä [Mon, 13 Oct 2025 20:12:32 +0000 (23:12 +0300)]
drm/i915/fbc: Decouple FBC from intel_cdclk_atomic_check()
Always account for FBC requirements in intel_crtc_compute_min_cdclk()
so that we don't have to worry about the actual CDCLK frequency in
intel_fbc_check_plane() any longer.
Ville Syrjälä [Mon, 13 Oct 2025 20:12:31 +0000 (23:12 +0300)]
drm/i915/ips: Eliminate the cdclk_state stuff from hsw_ips_compute_config()
Reorganize the IPS CDCLK handling such that the computed CDCLK
frequency will always satisfy the IPS requirements. The only
exceptional case is if IPS would push the CDCLK above the platform
max, but in that case we can simply disable IPS.
To make this 100% race free we must move the enable_ips modparam
check out from the min CDCLK computation path so that there is no
chance of hsw_min_cdclk() and hsw_ips_compute_config() observing
a different enable_ips value during the same commit.
This allows us to completely remove the cdclk_state stuff
from the IPS code. We only ever have to compare the IPS min
CDCLK against the platform max CDCLK. Thus we eliminate any ordering
requirements between intel_cdclk_atomic_check() and
hsw_ips_compute_config().
Additionally we reduce the three copies of the code doing the
95% calculation into just one.
Ville Syrjälä [Mon, 13 Oct 2025 20:12:30 +0000 (23:12 +0300)]
drm/i915/bw: Relocate intel_bw_crtc_min_cdclk()
intel_bw_crtc_min_cdclk() (aka. the thing that deals with what bspec
calls "Maximum Pipe Read Bandwidth") doesn't really have anything to
do with the rest of intel_bw.c (which is all about SAGV/QGV and
memory bandwidth). Move it into intel_crtc.c (for the lack of a better
place).
And I don't really want to call intel_bw.c functions from intel_crtc.c,
so move out intel_bw_crtc_data_rate() as well. And when we move that we
pretty much have to move intel_bw_crtc_num_active_planes() as well since
the two are meant to be used as a pair (they both implement the same
"ignore the cursor" logic).
And in an effort to keep the namespaces at least semi-sensible we
flip the intel_bw_crtc_ prefix into intel_crtc_bw_.
Ville Syrjälä [Tue, 14 Oct 2025 19:18:07 +0000 (22:18 +0300)]
drm/i915/prefill: Introduce skl_prefill.c
Add a new helper thingy to deal with the pipe prefill latency.
We get three potentially useful thigns out of this:
- skl_prefill_vblank_too_short() used for checking the
actual vblank/guardband length
- skl_prefill_min_guardband() to calculate a suitable guardband
size based on some worst case scaling/etc. estimates
- skl_prefill_min_cdclk() used to calculate a minimum cdclk
frequency required for very small vblank lengths (in case the
otherwise computed minimum cdclk doesn't result in fast enough
prefill).
The internal arithmetic is done terms of scanlines using .16
binary fixed point representation.
v2: Add the missing <<16 for framestart_delay
Drop the cdclk_state stuff in favor of crtc_state->min_cdclk
Rename to skl_prefill since this is skl+ only
Use intel_crtc_vblank_length() instead of hand rolling it
memset(0) in prefill_init()
Ville Syrjälä [Tue, 14 Oct 2025 19:18:06 +0000 (22:18 +0300)]
drm/i915/wm: Add WM0 prefill helpers
Add skl_wm0_prefill_lines() (based on the actual state) and
skl_wm0_prefill_lines_worst() (worst case estimate) which
tell us how many extra lines are needed in prefill for WM0.
The returned numbers are in .16 binary fixed point.
TODO: skl_wm0_prefill_lines_worst() is a bit rough still
v2: Drop all pre-icl FIXMEs since this only gets used for VRR guardband
projects / thirdparty / kernel / linux.git / log
