Ankit Nautiyal [Wed, 5 Nov 2025 14:06:59 +0000 (11:06 -0300)]
drm/i915/xe3p_lpd: Drop support for interlace mode
Interlace mode is officially removed from HW from Xe3p_LPD. The
register TRANS_VSYNCSHIFT and the bits in TRANS_CONF are now removed, so
make sure we do not set/get these anymore.
drm/i915/xe3p_lpd: Remove gamma,csc bottom color checks
With Xe3p_LPD, the SKL_BOTTOM_COLOR_GAMMA_ENABLE and
SKL_BOTTOM_COLOR_CSC_ENABLE bits are being removed. Thus, we need not
set gamma_enable nor csc_enable in crtc_state.
Note that GAMMA_MODE.POST_CSC_GAMMA_ENABLE and CSC_MODE.ICL_CSC_ENABLE
are the documented alternatives for the bottom color bits being removed.
But as these suggested bits are being checked in state checker as part
of gamma_mode, csc_mode fields and as gamma_enable/csc_enable are not
being used anywhere else functionally post ICL, we need not set these
fields in crtc_state.
On Xe3p_LPD, the dbuf blocks fields of different registers are now
documented as 13-bit fields. The dbuf isn't really large enough to need
the 13th bit, but let's go ahead and update the definition now just in
case some new display IP in future ends up needing the larger size. The
extra bit is an unused bit in previous display versions, so we can
safely just extend the existing definition.
Matt Atwood [Wed, 5 Nov 2025 14:06:53 +0000 (11:06 -0300)]
drm/i915/xe3p_lpd: Update bandwidth parameters
Bandwidth parameters for Xe3p_LPD are the same as for Xe3_LPD. Re-use
them.
Since handling for Xe3_LPD version 30.02 is more like a special case,
let's use a "== 3002" check for it inside the ">= 30" branch instead of
adding a new branch for version 35. That allows us to re-use the ">=
30" branch for Xe3p_LPD.
v2:
- Do not have a special case for ecc_impacting_de_bw, since there are
no specific instructions in Bspec for this scenario. (Matt Roper)
v3:
- Re-use the ">= 30" branch in the if-ladder. (Matt Roper)
Gustavo Sousa [Wed, 5 Nov 2025 14:06:52 +0000 (11:06 -0300)]
drm/i915/display: Use braces for if-ladder in intel_bw_init_hw()
Looking at the current if-ladder in intel_bw_init_hw(), we see that
Xe2_HPD contains two entries, differing only for ECC memories. Let's
improve readability by using braces and allowing adding extra conditions
for each case.
v2:
- Tweaked commit message, since we are not going to add the ECC case
for Xe3p_LPD anymore.
drm/i915/xe3p_lpd: Add Xe3p_LPD display IP features
Xe3p_LPD (display version 35) is similar to Xe2_LPD with respect to the
features described by struct intel_display_device_info, so reuse its
device descriptor.
Alok Tiwari [Mon, 3 Nov 2025 13:23:31 +0000 (05:23 -0800)]
drm/i915/dmc: Fix extra bracket and wrong variable in PIPEDMC error logs
Fixes two issues in intel_pipedmc_irq_handler():
- Removed an extra ']' in the PIPEDMC error and interrupt vector log.
- Corrected the interrupt vector log to print int_vector instead of tmp,
as tmp will be zero in this case.
drm/i915/display: Extend i915_display_info with Type-C port details
Expose key Type-C port data in i915_display_info to make it easier to
understand the port configuration and active mode, especially whether
the link is in DP-Alt or TBT-Alt, without having to scan kernel logs.
v2: Use drm_printer (Ville)
Lock/Unlock around the printf (Imre)
v3: Forward Declaration drm_printer struct (Jani)
v4: Handle MST connector with no active encoder (Imre)
Add a delimiter between fields and ":" after the port name (Imre)
v5: Init dig_port and use it in intel_encorder_is_tc and tc_info (Imre)
Move tc->port_name to a newline (Imre)
v6: Use intel_tc_port_lock/Unlock (Imre)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251028190753.3089937-1-khaled.almahallawy@intel.com
Jouni Högander [Thu, 30 Oct 2025 20:28:34 +0000 (22:28 +0200)]
drm/xe/display: Runtime pm wrappers for display parent interface
Implement runtime pm wrappers for xe driver and add them into display
parent interface.
v3:
- drop useless include
- drop xe_display_rpm_{get, put}_raw
v2:
- move xe_display_rpm_interface code into xe_display_rpm.c
- rename xe_rpm as xe_display_rpm
We have differing implementations for display runtime pm in i915 and xe
drivers. Add struct of function pointers into display_parent_interface
which will contain used implementation of runtime pm.
v2:
- add _interface suffix to rpm function pointer struct
- add struct ref_tracker forward declaration
- use kernel-doc comments
This is a baby step towards not building display as part of both i915
and xe drivers, but rather making it an independent driver interfacing
with the two.
v3: useless include additions dropped
v2: unrelated include removal dropped
Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20251030202836.1815680-2-jouni.hogander@intel.com
Suraj Kandpal [Sat, 1 Nov 2025 03:25:05 +0000 (08:55 +0530)]
drm/i915/ltphy: Hook up LT Phy Enable & Disable sequences
Hook up the LT Phy enable and disable sequences using encoder->
enable/disable_clock and reusing the TBT enable disable sequence from
cx0 PHY since it remains the same.
Suraj Kandpal [Sat, 1 Nov 2025 03:25:04 +0000 (08:55 +0530)]
drm/i915/ltphy: Program LT Phy Non-TBT PLL disable sequence
Program in the steps for Non TBT PLL disable sequence.
The whole function can be defined in one shot since most of
prequiste functions are already coded in.
Suraj Kandpal [Sat, 1 Nov 2025 03:25:03 +0000 (08:55 +0530)]
drm/i915/ltphy: Program the rest of the LT Phy Enable sequence
Program the rest of the LT Phy Non TBT PLL Enable sequence. This
can be done in a single patch since the rest of the prequistie
functions are already coded in.
Suraj Kandpal [Sat, 1 Nov 2025 03:25:01 +0000 (08:55 +0530)]
drm/i915/ltphy: Program the P2P Transaction flow for LT Phy
Program the LT PHY P2P transaction which uses P2M cycle to get
get data fro Phy when it is ready and then go read the MAC register
from the MAC address space.
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)
projects / thirdparty / kernel / linux.git / log
