Disable VRR DC balance by default due to timing issues observed on some
panel/TCON combinations.
Keep the module parameter to enable DC balance during debugging and to
isolate DC balance effects from underlying VRR/display timing issues.
--v2:
- Make enable_dc_balance a bool and keep it disabled by default; fix the
parameter type/value mismatch and correct the description (Chaitanya
Kumar Borah, Jani Nikula)
- Explain in the commit message why the feature is gated and why a
module parameter is used (Jani Nikula)
--v3:
- Commit message update (Jani Nikula)
Fixes: 5558192707 ("drm/i915/vrr: Enable DC Balance")
Cc: <stable@vger.kernel.org> # v7.0+
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260917074322.2606738-1-mitulkumar.ajitkumar.golani@intel.com
(cherry picked from commit d1ef78f0581e856c4238c751e9ae2884ce58c275)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Use EXPORT_SYMBOL_IF_KUNIT() instead of the regular EXPORT_SYMBOL() to
export the symbols to the kunit namespace. Otherwise, the symbols get
exported for all the kernel to see, and the corresponding
MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING") in the tests is
meaningless.
Fixes: 2eb9982ff1 ("drm/i915/kunit: Export link training and caps funcs for testing")
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260915160620.779372-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 4ffdb772716e4279d63dfaaadf965da73e799aeb)
During an atomic commit after all the MST stream CRTC state is computed
the driver ensures that the sum of TUs of all the streams on a given MST
topology link is within limits (63 for 8b10 and 64 for 128b132b). For a
disconnected stream the DRM MST core's BW verification doesn't ensure
this, because the topology state it uses for this is destroyed as soon
as the stream (i.e. MST connector/port) is disconnected. The driver
should keep the link state valid even for such disconnected streams, as
userspace may disable them one-by-one only in a deferred way. Ensure the
link's sum of TUs stays within limits in this case by simply reusing the
maximum link BPP limit from the stream's (i.e. CRTC's) old state.
The disconnection can happen either via the whole topology getting
disconnected or via only the given stream's port getting disconnected.
Check for both of these conditions separately, as a connector gets
unregistered after a link disconnect event only in a deferred way.
Cc: stable@vger.kernel.org # v6.10+
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16073
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16384
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260907174413.741851-2-imre.deak@intel.com
(cherry picked from commit ee00f8fbb2b202002ab90834e02e9ba372773a36)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
During an atomic commit after all the MST stream CRTC state is computed
the driver ensures that the FEC is configured the same way (enabled or
disabled) for all the streams on a given MST topology's link.
drm_dp_mst_port_downstream_of_parent() used to determine if a stream is
downstream of an MST port will return false if the whole topology is
disconnected, since in that case it can't verify that the port/
parent_port passed to it is in the given MST topology. This is a problem
during the above FEC configuration check, since
intel_dp_mst_check_dsc_change()->get_pipes_downstream_of_mst_ports()
will not return all the stream CRTCs/pipes for the topology as expected.
Since passing parent_port==NULL to get_pipes_downstream_of_mst_port()
is meant to return all the streams for the given topology (i.e. mst_mgr)
skip checking if an MST port is downstream of a parent port in this
case.
This fixes a problem where the FEC configuration check explained above
failed to ensure that all streams' FEC is configured the same way if the
topology was disconnected, leading to a FEC state mismatch error.
Cc: stable@vger.kernel.org # v6.10+
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16073
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16384
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260907174413.741851-1-imre.deak@intel.com
(cherry picked from commit 270681fbffbba2b6ccf5b7e3c34b8b563b36167f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The eDP panel on the HP Pavilion Plus Laptop 14-ew1xxx advertises HBR3
while leaving the TPS4 support bit clear. The output however flickers, once
link is trained with HBR3.
Until commit 8c9006283e ("Revert "drm/i915/dp: Reject HBR3 when sink
doesn't support TPS4"") such sinks were capped at HBR2 by the TPS4 check
which incidentally kept this panel stable. That check was reverted because
other panels legitimately need HBR3 without advertising TPS4, and the
per-machine QUIRK_EDP_LIMIT_RATE_HBR2 was introduced to handle the affected
machines instead.
Add the machine to the list of devices that need the
QUIRK_EDP_LIMIT_RATE_HBR2.
Fixes: 8c9006283e ("Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"")
Reported-by: Annoy Cc <annoycc@gmail.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16743
Cc: <stable@vger.kernel.org> # v6.18+
Tested-by: Annoy Cc <annoycc@gmail.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/20260907034555.2753846-1-ankit.k.nautiyal@intel.com
(cherry picked from commit 550b703fdbb2a2022faa75b4b11ab135241afbd9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Selective fetch is dropped while pipe CRC is active, and the planes keep
their SEL_FETCH_PLANE_CTL / SEL_FETCH_CUR_CTL enable bit set in hardware
over that. A plane disabled while selective fetch is off never gets the
bit cleared, as the disable path is guarded by enable_psr2_sel_fetch.
Once selective fetch comes back the hardware resumes fetching for a
plane that is no longer enabled and keeps its DDB range reserved.
Clear the bits as selective fetch is turned off instead. Atomic check
has both the old and the new crtc state, so record the transition there
and let the plane and cursor arm paths write the registers to 0 for that
commit.
v2: Drop the old_crtc_state->hw.active check. [Jouni]
Fixes: b1f5279b59 ("drm/i915/psr: Move plane sel fetch configuration into plane source files")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8739
Assisted-by: Copilot:Claude-Opus-5
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260909110332.3528029-3-nemesa.garg@intel.com
(cherry picked from commit a4c0e7f80429eda6990960971aebd4e4b9533cc6)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This reverts commit 7f1172a2ac.
This commit replaced the crtc_state->enable_psr2_sel_fetch guard in
icl_plane_disable_sel_fetch_arm() and i9xx_cursor_disable_sel_fetch_arm()
with HAS_PSR2_SEL_FETCH(). This is a display version check and
says nothing about the pipe, so every plane and cursor disable on a
display 12+ platform started writing SEL_FETCH_PLANE_CTL() /
SEL_FETCH_CUR_CTL(), including on pipes that do not implement them.
It shows up as an unclaimed register access on pipes driving HDMI where
selective fetch was never enabled.
The stale selective fetch enable bit that commit addressed is handled
in the next patch.
Fixes: 7f1172a2ac ("drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16876
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260909110332.3528029-2-nemesa.garg@intel.com
(cherry picked from commit d393529394167e0f5f706657eebe84d8529ce4fc)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The calc_allowed_config_filter() function passes the return value of
iter_pos_to_idx() directly to BIT(), but the helper can return -1 for
an invalid iterator.
The iterator already rejects negative indices before doing a
configuration, so this should not matter in normal flows. In any
case, for robustness, check the index explicitly and warn if it is
negative, avoiding an undefined shift.
Fixes: 39e30bdf2f ("drm/i915/dp_link_caps: Add link configuration iterator")
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260908100659.113555-1-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
(cherry picked from commit fe05cb9b9fb0ecc10409c4c6133257214b6cd8c8)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
SDP splitting for 128b/132b (UHBR) SST audio must only be enabled when
the sink advertises support for it. Previously sdp_split_enable
was set for every UHBR SST stream carrying audio, regardless of sink
capability.
In MST mode SDP splitting is inherently supported, so the sink
capability check (DP_SST_SPLIT_SDP_CAP) is applied only to the SST path.
Fixes: 8853750dba ("drm/i915: Enable SDP split for DP2.0")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260825073204.872441-1-mitulkumar.ajitkumar.golani@intel.com
(cherry picked from commit b37921c9f533ca936c5b5a484c1299680c570a7e)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
dg2_power_well_count() is supposed to return an integer,
not a boolean. Make it so.
Fixes: 9112ce99c1 ("drm/i915/cdclk: Extract dg2_power_well_count()")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260826143100.19401-1-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
(cherry picked from commit dcf423710d0253d7d729c3992bbae0c6197c9c22)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Apparently PTL+ no longer has the cd2x pipe select field in
CDCLK_CTL. Take that into account during CDCLK sanitization.
This currently triggers a spurious CDCLK sanitization during
driver load on PTL+ which will causes a visible glitch on all
active displays.
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8550
Fixes: 2ee8dbd880 ("drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260717155107.17801-1-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
(cherry picked from commit 1786d26887817a779641d3a093c66ac91382113b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
icl_plane_disable_sel_fetch_arm() wrote SEL_FETCH_PLANE_CTL = 0 only when
crtc_state->enable_psr2_sel_fetch was set. If a plane was disabled after
selective fetch had been turned off, the guard fired early and left the
register's enable bit set in hardware.
The bit is harmless until selective fetch is re-enabled. When it is, the
hardware resumes fetching for the now-disabled plane and keeps its old DDB
range reserved.
i9xx_cursor_disable_sel_fetch_arm() has the same guard on SEL_FETCH_CUR_CTL
and is fixed the same way.
v2: Add same check for cursor also. [sashiko]
Cc: stable@vger.kernel.org
Fixes: b1f5279b59 ("drm/i915/psr: Move plane sel fetch configuration into plane source files")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8739
Assisted-by: GitHub-Copilot:claude-opus-4.6
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260818095149.2172935-1-nemesa.garg@intel.com
(cherry picked from commit 600a7c9d40e5e0c5544f42d1c9592c8d15224dc0)
Signed-off-by: Jani Nikula <jani.nikula@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 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
(cherry picked from commit eaed815ca3483c227e4ec80b86d1b3ce5c2508be)
Signed-off-by: Jani Nikula <jani.nikula@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
(cherry picked from commit 9ac3ee6c0f92cd09893bd442964fb6b0d6813b5e)
Signed-off-by: Jani Nikula <jani.nikula@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
(cherry picked from commit 5abc20e39dd074e8696387ca6871d6e432baf0cd)
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]
(cherry picked from commit ea9f3470d33602fb776ea55443467baacf66f23a)
Signed-off-by: Jani Nikula <jani.nikula@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
Call intel_dp_link_caps_iter_end() after the link configuration loops.
At the moment this call only clears the iteration object, so the lack of
call didn't cause an actual issue.
Cc: Luca Coelho <luciano.coelho@intel.com>
Fixes: 7266df62ed ("drm/i915/dp: Iterate configurations via link_caps for SST non-DSC")
Fixes: 4f104fc10a ("drm/i915/dp: Iterate configurations via link_caps for SST DSC")
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260714152700.555527-3-imre.deak@intel.com
Turns out some panels allow only AUX based backlight
by just setting the DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
not setting the DP_EDP_BACKLIGHT_AUX_ENABLE_CAP.
If we make DP_EDP_BACKLIGHT_AUX_ENABLE_CAP a necessity for AUX
based DPCD backlight these panels loose the ability to manipulate
backlight via AUX, especially ones with no PWM controller.
Remove this check from function so that panels who do not advertise
DP_EDP_BACKLIGHT_AUX_ENABLE_CAP but advertise
DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP are able to manipulate
backlight again.
Fixes: ed8be780bd ("drm/i915/backlight: Fix VESA backlight possible check condition")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16507
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/20260716030959.436430-1-suraj.kandpal@intel.com
Double the fractional part of the horizontal scale factor
for the purposes of min_cdck calculation. This bumps the min
CDCLK sufficiently to overcome some kind of 2 PPC granularity
issue. Without this CDCLK may end up being too low and we get
underruns with certain horizontal downscale factors.
The current Bspec formula calls for doubling only the
fractional part below 0.5, and rounding it down to a
unit fraction. But that formula does not result in a
sufficient CDCLK bump in a lot of cases. Empirical evidence
supports doubling the entire fractional part, so let's just
do that while we wait for further analysis from the hardware
team.
Also note that the position of the scaler output window also
seems to matter. If the output is near the left edge of the
screen then lower CDCLK is sufficient, but moving the output
window further to the right causes underruns unless CDCLK is
also bumped. Some prefill happening during hblank already?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260715120926.10786-5-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
We'll need to do additional adjustments to the pipe pixel rate
for the purposes of min CDCLK calculations. Add a new
crtc_state->pixel_rate_cdclk for that purpose. We'll leave the
original crtc_state->pixel_rate for data rate related calculations
since we presumably don't need those extra adjustments there.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260715120926.10786-4-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
We'll need to check for the "does the platform do 2 pixels per clock?"
thing in a few places. Add a feature macro for it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260715120926.10786-3-ville.syrjala@linux.intel.com
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Since commit 860e748bdd ("drm: ensure blend mode supported if pixel
format with alpha exposed"), drm_mode_config_validate() warns when a
plane exposes an alpha pixel format but not the "pixel blend mode"
property. The cursor (ARGB8888, all platforms) and the VLV/CHV primary
and sprite planes trip this.
Userspace has historically assumed premultiplied blending when the
property is not attached, so it is safe to assume that planes that
did not expose the property already blended with fixed pre-multiplied
alpha in hardware. Therefore, expose a "pixel blend mode" property
advertising only DRM_MODE_BLEND_PREMULTI to match that assumption and
silence the warning. The cursor call is unconditional; the primary and
sprite calls are gated to VLV/CHV, the only platforms whose format lists
include alpha formats.
Assisted-by: Claude:claude-opus-4-8
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16623
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260715054221.451421-1-chaitanya.kumar.borah@intel.com
On Xe3+, the SoC can lower the fabric frequency when the display
needs less bandwidth than the minimum GV point. This threshold is
defined as 20 GB/s. The driver can choose to request this threshold
when the required data rate falls below it.
Add an extra QGV entry, with both peak bw and derated bw set to
20 GB/s, to the bandwidth info when all of the following hold:
1. The platform is Xe3+.
2. There is at least one existing QGV point.
3. The number of QGV points is below 8 (the maximum).
Once a plane group is found, the driver iterates over all QGV points
in that group to find the best match for the required data rate. If
the required data rate is below 20 GB/s, it selects the peak bw from
this new QGV point (20 GB/s).
v2: add the peak bandwidth threshold as an additional QGV entry
v3: drm_warn switched to drm_dbg_kms (Suraj)
Removed log in case of no sagv and some tweak in the log message
if the system has already the maximum number of QGV points
Bspec: 68880
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260615203355.218578-8-vinod.govindapillai@intel.com
Now that SAGV status update is consolidated, need to update the
SAGV status based on the number of QGV points only once after
bw info initialization is done.
v2: patch description updated.
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260615203355.218578-7-vinod.govindapillai@intel.com
Extract the code to update the SAGV status based on the number of
QGV points into a separate function and use it.
v2: rebase
v3: patch description updated
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260615203355.218578-6-vinod.govindapillai@intel.com
Simplify the initialization of QGV points info by extracting
the code to initialize the QGV points info from dram info based
on the memory type. This will reduce the complexity of the init
QGV info routine as we will be supporting new memory types in
future platforms.
v2: rebase after Ville's refactoring
v3: patch description updated
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260615203355.218578-5-vinod.govindapillai@intel.com
For pmdemand cases, no need to even calculate the masks based
on the qgv points index. Though the current logic avoids setting
the registers based on the pmdemand support, some qgv point masks
are compared in vain and do nothing. So leave early if pmdemand
is supported.
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260615203355.218578-4-vinod.govindapillai@intel.com
PM demand feature introduces a new way to set bw, power and
performance requirements to pcode from display version 14 onwards.
Use an identifiable name as a macro to distinguish the pm demand
specific changes in the code.
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260615203355.218578-3-vinod.govindapillai@intel.com
The UV/Y plane DDB entriess are never cleared on
sk_wm_plane_disable_noatomic() and can leave stale DDB state
for NV12 planes on pre-Gen11 devices
Fixes: d34b59d5ba ("drm/i915: Add skl_wm_plane_disable_noatomic()")
Assisted-by: Copilot:claude-sonnet-4.6
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260615203355.218578-2-vinod.govindapillai@intel.com
Enable PIPEDMC_ERROR alongside the existing PIPEDMC_GTT_FAULT and
PIPEDMC_ATS_FAULT interrupt bits for display version 30+.
On PTL, DC state transitions do not trigger the spurious PIPEDMC_ERROR
interrupts that were previously a concern. Enable the interrupt so pipe
DMC errors are reported by intel_pipedmc_irq_handler().
v2:
- Remove IGT reference from commit message (Suraj).
Bspec: 70296
Suggested-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260708090712.3800170-1-dibin.moolakadan.subrahmanian@intel.com
New transcoder enum values (for CMTG) were recently added which pushed
the maximum transcoder mask beyond 8bits. The patch in question
updated the info structure's u8 to u16 but not any of the functions
that process transcoder masks. So fix those as well.
v2: Fix more instances (found by Sashiko)
Signed-off-by: John Harrison <John.Harrison@Igalia.com>
Fixes: 789dda6429 ("drm/i915/cmtg: Add CMTG transcoder offset in struct _device_info")
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20260713234138.3861243-1-John.Harrison@Igalia.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Respect the user's choice of depth/bpp for the fbdev framebuffer
and throw out the fb we inherited from the BIOS if it doesn't
match.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-4-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
