DDI_CLK_VALFREQ is programmed with the port clock, which for DP is the
symbol clock computed assuming 8b/10b encoding (link_rate / 10). For
DP 128b/132b (UHBR) rates and for HDMI FRL the port clock needs to
be modified.
DDI_CLK_VALFREQ does not have any functional impact on H/w, it
only records the frequency S/w intends to set.
Use intel_ddi_link_symbol_clock() to write the correct DDI clock in
kHz
Fixes: 5ec58d7149 ("drm/i915/lt_phy: Add .enable_clock hook on DDI")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260811175844.2613721-4-suraj.kandpal@intel.com
DDI_CLK_VALFREQ is programmed with the port clock, which for DP is the
symbol clock computed assuming 8b/10b encoding (link_rate / 10). For
DP 128b/132b (UHBR) rates and for HDMI FRL the port clock needs to
be modfied.
DDI_CLK_VALFREQ does not have any functional impact on H/w, it
only records the frequency S/w intends to set.
Use intel_ddi_link_symbol_clock() to write the correct DDI clock in
kHz.
Fixes: 51390cc0e0 ("drm/i915/mtl: Add Support for C10 PHY message bus and pll programming")
Fixes: 73fc3abcb7 ("drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260811175844.2613721-3-suraj.kandpal@intel.com
Add intel_ddi_link_symbol_clock() to return the DDI clock frequency for
a given port clock:
DP 8b/10b : rate
DP 128b/132b (UHBR) : (10 / 32) * rate
HDMI FRL : (10 / 18) * rate
HDMI TMDS : rate
The DP case reuses intel_dp_link_symbol_clock().
This will help in upcoming commits to decide value to be written
in DDI_CLK_VALFREQ.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260811175844.2613721-2-suraj.kandpal@intel.com
Reject invalid joiner forcing more thoroughly, taking into account
whether bigjoiner or uncompressed joiner is available, and whether the
requested number of pipes can actually be joined.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/df39b8f30d27a441465b4d9bd42d4db982e5db2b.1786105831.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Skip joining for pipes that can't work as joiner primary pipe for the
number of pipes being joined. This limits the invalid combos early,
instead of ending up with crtc_state->joiner_pipes that would fail
during modeset. Before, crtc_state->joiner pipes could have ended up
including pipes that do not exist on the platform.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/dc1c7fc45d4da7d3fd1bd8b94c30c78d69aa0742.1786105831.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Make intel_dp_can_join(), and subsequently
intel_dp_joiner_candidate_valid() and for_each_joiner_candidate() more
strict about pipes actually available for joining by using
intel_joiner_valid_primary_pipe_mask().
This rejects some invalid combos early for both mode enumeration and
compute config.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/efc330687f8299e5725564c3ed90d5d8e6aa0eb2.1786105831.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Multiplying the max dotclock based on joiner availability on the
platform alone does not take into account the actual pipes (possibly
with some fused) available for joining.
Limit the max joined dotclock based on the actual pipes available for
joining. Add helpers for figuring out the valid primary pipes, based on
having the required joiners and amount of consecutive pipes available.
v2: Check for consecutive pipes available (Ankit)
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/3c615440f018af779a3a522f14637d2993f7af03.1786105831.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
mst_stream_compute_config() called intel_pfit_compute_config() twice
in a row.
commit 5ce9ac1531 ("drm/i915/mst: Call intel_pfit_compute_config()
for sharpness filter")
was erroneously cherry-picked to the fixes tree while
commit ca97f5546f ("drm/i915/mst: Call intel_pfit_compute_config()
for sharpness filter")
was already in there.
Drop the redundant duplicate call.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Nemesa Garg <nemesa.garg@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Fixes: 5ce9ac1531 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter")
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/20260806074819.2631970-1-chaitanya.kumar.borah@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo: adjusted commit message]
Refactor intel_hdmi_dsc_get_num_slices to remove dependency on
intel_crtc_state structure by accepting display mode and output format
as parameters instead.
This makes the function reusable for mode_valid cases where
crtc_state is not present.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260805035027.3473398-3-ankit.k.nautiyal@intel.com
There are workarounds display needs to apply depending on information
only available to the core driver. Add a display parent interface for
the query. For starters, there's only one workaround like this, so keep
it simple instead of over-engineering.
This lets us drop an #ifdef I915 as well as xe dependency on some
display headers.
v2: git add xe_display_wa.h
v3: Add a comments about usage (Suraj)
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260803115417.1760484-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move the core driver TDF call to display parent interface to avoid
direct calls from display to xe driver.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260728170029.608289-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Now that DG2 has a DPLL manager and its users are prepared to obtain
clock state through the framework, switch the platform over to use the
shared DPLL manager.
Remove specific MPLLB state verification and use .compare_hw function
hook to compare HW and SW PLL states.
Assisted-by: Copilot:claude-sonnet-4-6
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260630115336.1059976-5-mika.kahola@intel.com
Prepare DG2 users to obtain clock state and reserve PLLs through the
shared DPLL framework.
Replace the DG2-specific compute hook with the generic framework-backed
helpers.
Assisted-by: Copilot:claude-sonnet-4-6
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260630115336.1059976-4-mika.kahola@intel.com
Add DG2-specific DPLL manager infrastructure for MPLLB-backed port PLLs.
Introduce PLL id mapping, DG2-specific DPLL callbacks for
enable/disable/readout/frequency calculation, and manager callbacks
for compute/get/dump/compare. The platform is not switched over yet.
DG2's PLL-to-encoder lookup prefers the active encoder using the PLL,
but fall back to a matching encoder for the fixed port-to-PLL mapping
when no active user can be identified.
This keeps the active-user fix for operational paths while allowing
readout and verification paths to resolve the PHY even when
pll->active_mask does not identify an active user.
v2: Use intel_encoder_is_dig_port() to filter out
MST virtual encoders (Imre)
Assisted-by: Copilot:claude-sonnet-4-6
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> (v1)
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patch.msgid.link/20260630115336.1059976-3-mika.kahola@intel.com
Refactor the DG2 MPLLB enable path by splitting out a helper that
programs the PHY directly from an intel_mpllb_state.
This is preparatory work for moving DG2 MPLLB handling under the DPLL
framework, where callbacks operate on dpll_hw_state rather than the
full crtc_state.
Assisted-by: Copilot:claude-sonnet-4-6
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260630115336.1059976-2-mika.kahola@intel.com
Set crtc_state->vrr.cmrr.enable at the end of
intel_vrr_cmrr_compute_config() so that CMRR is actually enabled once
the M/N parameters have been computed. This is the final step that
turns on CMRR, with all the parameter computation handled in the
earlier patches.
--v2:
- Everything else except enable compute to handle before this patch
(Chaitanya)
--v3:
- Remove redundant return from compute config
--v4:
- Update CMRR commit message (Chaitanya)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260730105919.3913412-11-mitulkumar.ajitkumar.golani@intel.com
Move the CMRR M/N register writes into a new
intel_vrr_set_cmrr_timings() helper called from
intel_vrr_set_fixed_rr_timings(), so CMRR is programmed together with
the fixed rr timings for both the CMTG and CPU transcoder, instead of
being open-coded in intel_vrr_set_transcoder_timings(). Drop the
now-unused cmrr_enable argument to intel_vrr_tg_enable().
No functional change intended for non-CMRR configurations.
--v2:
- Commit message changes.
- Added Simplified enable/disable sequence. (Chaitanya)
--v3:
- Guard CMRR enable condition (Chaitanya)
- Comment changes updated (Chaitanya)
- Squash register write commits together and
avoid double writing issue. (Chaitanya)
--v4:
- Guard CMRR enable/disable with platform check
--v5:
- Update CMRR in enable/disable path
--v6:
- Simplify enable/disable calls (Chaitanya)
- Make function usable for common cmtg and cpu transcoder
(Chaitanya)
--v7:
- Update commit message (Chaitanya)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Assisted-by: Claude:claude-opus-4-8
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260730105919.3913412-9-mitulkumar.ajitkumar.golani@intel.com
Writing the per-CRTC "intel_vrr_target_refresh_rate" debugfs file only
updates crtc->force_cmrr, a side channel that is not tracked by the
atomic state. The requested ratio therefore does not reach the hardware
until some unrelated commit recomputes the pipe config.
Kick an internal atomic commit for the CRTC from the debugfs write and
mark the CRTC mode as changed so the pipe config is recomputed.
Note that this commit may or may not be downgraded to a fastset,
depending on whether the computed vblank value (with LRR disabled)
changes, so it is not characterised as a fastset.
If the commit fails, restore the previous numerator/denominator so that
force_cmrr does not hold on to bad values, which would otherwise make
all subsequent commits fail.
--v2:
- Commit message and code comment update (Chaitanya)
- Commit header update
- Restore to old known debugfs values when commit fails
(Chaitanya)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260730105919.3913412-8-mitulkumar.ajitkumar.golani@intel.com
Rework the fractional CMRR computation into a generic,
transcoder-agnostic helper driven by an explicit per-CRTC debugfs
target, replacing the previous disabled, eDP-only code path. Compute
CMRR_M and CMRR_N timings based on the video mode requirements. A 1:1
ratio (denominator == 1000) means no video timing is required. Note
that the CMRR enable path is wired up separately; this patch only lays
down the generic computation.
Remove computation of mode_flags, I915_MODE_FLAG_VRR, as CMRR is
being moved to the fixed refresh rate path. Also return early from
the CMRR computation if the existing computation is already sufficient.
--v2:
- Derive video_mode locally instead of caching it in the persistent
struct intel_crtc state (Jani, Chaitanya)
- Fix numerator unit in comment: milli-Hz, not kHz (Chaitanya)
- Fix "requirement" typo and clarify that CMRR is not yet enabled in
the commit message (Chaitanya)
- Fix precision issue while computing the M/N ratio (Chaitanya)
- Rename multiplier_m and multiplier_n to improve readability
(Chaitanya)
- Compute vtotal as it is required for dithering as per the algorithm
implementation (Chaitanya)
- Replace the misleading adjusted_pixel_rate with dividend, which is
more descriptive
--v3:
- Mention the rationale for not computing I915_MODE_FLAG_VRR
(Chaitanya)
- Remove the redundant return statement at the end of the CMRR
computation (Chaitanya)
- Correct cmrr_n calculation (Chaitanya)
- Add an early return if the current computation is already sufficient
to drive the mode without CMRR (Chaitanya)
- Round up requested_refresh_rate (Validation)
- Fix integer overflow
--v4:
- Update cmrr_n calculation to avoid aggressive dithering
- Use div64_u64 to truncate to the floor value instead of
DIV_ROUND_UP_ULL, which rounds up to the ceiling value
- Add a TODO comment to the cmrr_n calculation
- Add a condition for custom refresh rate requests
- Update the CMRR computation comment block in compute_config
--v5:
- Simplify computation
- Correct typo in commit message (Chaitanya)
- Compute early return condition (Chaitanya)
--v6:
- Simplify commit message
- Simplify video timing requirement compute function (Chaitanya)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260730105919.3913412-7-mitulkumar.ajitkumar.golani@intel.com
Add a per-CRTC debugfs file 'intel_vrr_target_refresh_rate' that lets
the user force a CMRR target refresh rate and video-mode requirement.
The file uses a "numerator/denominator" format:
- numerator: requested refresh rate in milli-Hz
(refresh rate in Hz * 1000, e.g. 60000 for 60 Hz)
- denominator: 1000 for a 1:1 ratio (no video timing) or
1001 for the 1000/1001 video timing
Reading the file reports the currently stored values; writing updates
them. The file is created only on platforms with VRR and CMRR support.
--v2:
- Drop the "vrr" debugfs subdirectory and expose a single flat,
intel_-prefixed "intel_vrr_cmrr" file (Jani, Nikula)
- Rename struct intel_crtc.cmrr to force_cmrr to make its purpose
explicit (Chaitanya)
- Fix parse comment: numerator unit is milli-Hz, not KHz (Chaitanya)
- Add debugfs/intel_ prefixes to the debugfs handler functions (Chaitanya)
- Expand commit message with debugfs entry semantics (Chaitanya)
--v3:
- Rename debugfs function and file name (Chaitanya)
- Remove railing new line at EOF (Chaitanya)
- Update CMRR guard conditions (Chaitanya)
- Add 0/0 default case. (Ramanaidu)
--v4:
- Correct CMRR guard check while creating debugfs
--v5:
- Commit message update (Chaitanya)
- Add support for 0/0 writing (Validation)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260730105919.3913412-4-mitulkumar.ajitkumar.golani@intel.com
CMRR is currently advertised on all HAS_CMRR platforms, but it depends
on the VRR timing generator being the default timing generator, which
currently only applies to DISPLAY_VER >= 30.
Gate the CMRR enable condition and readout accordingly so CMRR is only
reported on supported platforms.
No functional change.
--v2:
- Create a separate function to check if CMRR possible
--v3:
- Simplify commit message (Chaitanya)
- Remove redundant outer parenthesis (Chaitanya)
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260730105919.3913412-3-mitulkumar.ajitkumar.golani@intel.com
From xe2_lpd+ platforms, enabling FBC do not depend on the
surface size. So remove the check.
v2: changes to patch description
Bspec: 69560
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260722132448.318112-3-vinod.govindapillai@intel.com
In xe2_lpd+ platforms, there are no restrictions to enable FBC
on planes with respect to the plane width - width can be as per
the platform's maximum supported resolution.
v2: patches squashed and changes in patch descriptions
Bspec: 69560
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260722132448.318112-2-vinod.govindapillai@intel.com
Enabling features like FBC on platforms may depend on a plane's
maximum supported resolutions or some other arbitrary constant
values because of hw restrictions. Currently the helpers that
report a plane's max width and height are private to skl_plane
/ skl_universal_plane. Change the scope to golbal so that
this can be queried from other areas as well.
v2: function parameter alignment fixes
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260722132448.318112-1-vinod.govindapillai@intel.com
intel_dp_hdmi_sink_max_frl() limits the sink's max FRL rate by its
DSC max FRL rate whenever the sink supports DSC 1.2.
However, the DSC max FRL rate (HF-VSDB DSC_Max_FRL_Rate) only applies
to compressed video transport, which requires a DSC 1.2 encoder in
the PCON (configured via intel_dp_pcon_dsc_configure()).
Without such an encoder the HDMI link always carries uncompressed
video, for which the regular Max_FRL_Rate is the correct limit.
Applying the DSC limit unconditionally trains the FRL link at a lower
rate than both the PCON and the sink support.
E.g. an LG OLED G4 (Max_FRL_Rate 48 Gbps, DSC_Max_FRL_Rate 24 Gbps)
behind a Synaptics VMM7100 PCON (PCON max FRL bw 48 Gbps, no DSC
encoder):
Sink max rate from EDID = 24 Gbps
FRL trained with : 24 Gbps
while Windows/macOS train the same hardware at 40/48 Gbps.
The too low FRL rate needlessly constrains the formats available to
the sink.
Only apply the sink's DSC max FRL rate if the PCON has a DSC 1.2
encoder, matching the gate in intel_dp_pcon_dsc_configure().
PCONs with a DSC encoder keep the current conservative behavior,
since the link is trained once and compressed transport may be used
for any subsequent mode.
With this the setup above trains at 48 Gbps.
Tested on PTL (xe) with the above PCON/sink combo.
Fixes: 10fec80b48 ("drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260718105207.5565-3-alexander.kaplan@sms-medipool.de
For modes which fit through the link uncompressed only with a 6 bpc
pipe BPP, the link config currently selects 6 bpc with dithering even
if the sink supports DSC.
For HDMI sinks behind a DP to HDMI protocol converter this is the
wrong preference: HDMI knows no 6 bpc transport format, so the
converter has to expand the dithered 6 bpc stream back to 8 bpc for
the HDMI link anyway, and DSC with an at least 8 bpc input provides
a better output quality than that.
Prefer DSC, following the pattern commit ba49a4643c ("drm/i915/dp:
Set min_bpp limit to 30 in HDR mode") uses for HDR: keep the
uncompressed minimum pipe BPP at 8 bpc if the sink supports DSC,
making the uncompressed link config fail for such modes and the mode
fall back to DSC.
As there, if the DSC computation fails, the mode falls back to YCbCr
4:2:0 where supported, or gets rejected.
Besides the output quality, some converters can't even display a
6 bpc stream at high pixel clocks.
Synaptics VMM PCON based DP to HDMI 2.1 adapters from two device
families (branch device IDs SYNAq and SYNAa) output corrupted FRL
timings for an uncompressed RGB 6 bpc 4k120 (1188 MHz) stream,
resulting in a black screen, while the same mode works with DSC
(12 bpc input) and 6 bpc works at lower pixel clocks.
Windows and macOS drive 4k120 on these devices only via DSC.
A lower bpc limit explicitly requested via the max bpc connector
property is still honored.
This keeps the current uAPI behavior (exercised by IGT kms_dither)
and provides an escape hatch for sinks with a broken DSC
implementation.
DP and eDP sinks, and HDMI sinks without DSC support, are not
affected and keep falling back to 6 bpc.
Tested on PTL (xe) with the above PCONs and an LG OLED G4.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260718105207.5565-2-alexander.kaplan@sms-medipool.de
Per DP 1.4a section 2.2.4.3, the MSA MISC1 VSC_SDP bit signals that
the sink should defer colorimetry to the VSC SDP. It should only be set
when the sink advertises DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED and a
VSC SDP with pixel encoding/colorimetry payload will actually be sent.
Fold the colorimetry_support check into intel_dp_needs_vsc_colorimetry()
so both intel_ddi_set_dp_msa() and intel_dp_compute_vsc_sdp() share a
single consistent gate.
Assisted-by: GitHub_Copilot:claude-sonnet-4.6
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Pranay Samala <pranay.samala@intel.com>
Link: https://patch.msgid.link/20260709113951.3557968-3-chaitanya.kumar.borah@intel.com
The function answers whether a VSC SDP with colorimetry and pixel
encoding payload is required by the content being displayed.
Rename it to reflect that.
No functional change intended.
Assisted-by: GitHub_Copilot:claude-sonnet-4.6
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Pranay Samala <pranay.samala@intel.com>
Link: https://patch.msgid.link/20260709113951.3557968-2-chaitanya.kumar.borah@intel.com
From PTL onwards, the set context latency can be in the vactive region,
letting the safe window start some lines before the vblank start. The DSB
waits on this safe window instead of vblank (bits [15:14] select the safe
window signal from the DPT unit to start the DMA engine).
With modes that have a smaller vblank region, the computed guardband is
clamped to the vblank length, making the undelayed and delayed vblank
coincide. If the SCL is also 0, the 'safe window' becomes effectively 0,
and the DSB configured to wait for it gets stalled, since the hardware
never signals the safe window, leading to:
*ERROR* [CRTC:159:pipe A] flip_done timed out
*ERROR* [CRTC:159:pipe A] DSB 0 timed out waiting for idle
Keep the set context latency at a minimum of 1 to avoid this.
v2: Fix the bit numbers and correct the commit message. (Chaitanya)
Fixes: 4a68c7516c ("drm/i915/dsb: Use safe window path when VRR TG is used")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Assisted-by: GitHub-Copilot:Claude-Opus-4.8
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://patch.msgid.link/20260722062449.1166411-1-ankit.k.nautiyal@intel.com
Wa_16030862157:
Interpret 0xF populated-channel count as 16
The register MEM_SS_INFO_GLOBAL [Number of populated channels] field
definition is updated with an encoding for 16 channels.
For 16-channel configuration, program 1111b. A programmed value of 1111b
must be interpreted as 16 channels for memory bandwidth calculations.
The MEM_SS_INFO_GLOBAL populated-channel field is only 4 bits and cannot
encode 16, so on Xe3p the BIOS programs the saturated field value (0xf)
to indicate the fully-populated 16-channel config (4 memory controllers
x 4 channels). Interpret it as 16 and let the bandwidth math handle the
larger channel count.
v2: Limit the WA only till NVL (Suraj)
Logical separation of WA (Vinod)
WA: 16030862157, 16030875223
Bspec: 69131, 79482
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patch.msgid.link/20260715143243.4141208-2-uma.shankar@intel.com
Disable 1 and 2 lane link configurations on UHBR tunneled links,
according to DP Standard v2.1b "3.5.2.16.3 128b/132b DPRX Lane Count
Conversion Failure Indication and Corrective Action". A tunnel can
indicate if it's not affected by this limitation, check for that and
skip disabling the unsupported lanes for a well-behaving tunnel.
The Standard in the same section also describes a workaround for 2 lanes
which requires assisstance from the sink, where the sink indicates at
the end of the link training sequence if the link training must be
retried. This mechanism also requires quirking out some sinks - based on
the sink's DPCD OUI and EDID identifications - which doesn't implement
this link training feedback indication properly. This patch leaves the
implementation of this workaround for a follow-up, but prepares for it
already by detecting the supported number of lane counts at a place
where both DPCD OUI and EDID is available for the quirk detection.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260714152700.555527-6-imre.deak@intel.com
After fallback between UHBR and non-UHBR link rates got enabled in a
previous change, there is no need to test fallback sequences for UHBR
and non-UHBR rates separately. Make the test simply start from the
maximum (UHBR) rate.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260714152700.555527-5-imre.deak@intel.com
Enable link training fallback between UHBR and non-UHBR link rates on DP
SST links. This was disabled so far to preserve the fallback behavior.
There isn't a known issue related to such a fallback and DP MST has been
using this for a while already. Also, enabling UHBR rates over
Thunderbolt tunnels in a follow-up change, which at least on some links
supports only 4 lanes and not 1 or 2 lanes on UHBR, makes a
UHBR->non-UHBR fallback scenario more likely.
At the same time align the corresponding link training fallback kunit
test, allowing a UHBR <-> non-UHBR fallback there as well.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.comd>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260714152700.555527-4-imre.deak@intel.com
