aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/gpu/drm/i915/display
AgeCommit message (Collapse)AuthorFilesLines
2026-09-22drm/i915/dp: use EXPORT_SYMBOL_IF_KUNIT() for kunit helpersJani Nikula2-4/+6
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: 2eb9982ff179 ("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)
2026-09-22drm/i915/dp_mst: Fix configuring TUs for a disconnected streamImre Deak3-1/+25
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>
2026-09-22drm/i915/dp_mst: Fix configuring FEC for a disconnected streamImre Deak1-1/+2
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>
2026-09-22drm/i915/quirks: Limit eDP rate to HBR2 on HP Pavilion Plus 14-ew1Ankit Nautiyal1-0/+3
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 8c9006283e4b ("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: 8c9006283e4b ("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>
2026-09-22drm/i915/psr: Clear stale sel fetch enable bits on sel fetch disableNemesa Garg4-7/+26
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: b1f5279b5981 ("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>
2026-09-16Revert "drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable"Nemesa Garg2-20/+10
This reverts commit 7f1172a2ac0d7e50850785e2e65789c8aac8411a. 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: 7f1172a2ac0d ("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>
2026-09-15drm/i915/display: check configuration index before shiftingLuca Coelho1-1/+8
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: 39e30bdf2f92 ("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>
2026-09-10drm/i915/dp: Gate UHBR SST SDP splitting on sink capabilityMitul Golani2-6/+40
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: 8853750dbad8 ("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>
2026-08-31drm/i915/cdclk: Fix dg2_power_well_count() return typeVille Syrjälä1-2/+2
dg2_power_well_count() is supposed to return an integer, not a boolean. Make it so. Fixes: 9112ce99c1d7 ("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>
2026-08-31drm/i915/cdclk: Avoid spurious cdclk sanitization on PTL+Ville Syrjälä1-2/+4
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: 2ee8dbd880b1 ("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>
2026-08-31drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disableNemesa Garg2-10/+20
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: b1f5279b5981 ("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>
2026-08-31drm/i915/lt_phy: program DDI_CLK_VALFREQ with DDI clock frequencySuraj Kandpal1-2/+4
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: 5ec58d714935 ("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>
2026-08-31drm/i915/cx0: program DDI_CLK_VALFREQ with DDI clock frequencySuraj Kandpal1-2/+3
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: 51390cc0e00a ("drm/i915/mtl: Add Support for C10 PHY message bus and pll programming") Fixes: 73fc3abcb797 ("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>
2026-08-31drm/i915/ddi: add helper to compute DDI clock frequencySuraj Kandpal2-0/+12
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>
2026-08-31drm/i915/dp_mst: Remove duplicate intel_pfit_compute_config() callChaitanya Kumar Borah1-4/+0
mst_stream_compute_config() called intel_pfit_compute_config() twice in a row. commit 5ce9ac1531b8 ("drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter") was erroneously cherry-picked to the fixes tree while commit ca97f5546f19 ("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: 5ce9ac1531b8 ("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>
2026-08-01Merge tag 'drm-intel-next-2026-07-28' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-nextDave Airlie49-566/+3401
drm/i915 feature pull #2 for v7.3: Features and functionality: - Enable UHBR link rates on Thunderbolt tunneled links (Imre) - Reduce Xe3+ PM demand peak bandwidth for power savings (Vinod) - Add the blend mode property to all planes that support alpha blending (Chaitanya) - Enable pipe DMC error interrupts for display 30+ (Dibin) - Add KUnit tests for DP link config selection and fallback (Imre) Refactoring and cleanups: - Refactor DP link config selection and unify across use cases (Imre) - Unify i915 and xe display runtime PM calls (Jani) - Refactor BIOS framebuffer takeover (Ville) Fixes: - Fix HD audio on DP UHBR SST (Kai Vehmanen) - Fixes to xe driver BIOS framebuffer takeover (Ville) - Fix 2 pixels-per-clock CDCLK calculation to avoid underruns (Ville) - Fix incorrectly set VSC SDP Main Stream Attribute (Chaitanya) - Fix BPC and DSC selection for HDMI sinks (Alexander Kaplan) - Fix PCON max FRL rate selection (Alexander Kaplan) - Workaround Xe3P PSR2 screen corruption (Dibin) - Fix NVL A & B stepping vtotal setting (Suraj) - Fix xe DPT allocation paths (Maarten) - Prefer system memory instead of stolen for new framebuffers in xe (Maarten) - Fix transcoder mask sizes (John Harrison) - Clear stale UV/Y plane DDB entries on plane disable (Vinod) - Fix some DP AUX backlight control issues, again (Suraj) - Fix switching between HDCP 1.4 and 2.2 authentication (Suraj) - Remove unnecessary Xe2_LPD+ FBC plane width and surface size limits (Vinod) - Ensure non-zero DSB safe window for PTL+ (Ankit) - Fix bandwidth calculation to account for 16 DRAM channels (Uma) - Fix NV12 ceiling division for bigjoiner case (Vidya) DRM core changes: - Add Thunderbolt UHBR tunneling support (Imre) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/cb1b5a644d75589cbcdcc8ec8160968140426439@intel.com
2026-07-24drm/i915/fbc: No surface size restrictions from LNL onwardsVinod Govindapillai1-0/+3
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
2026-07-24drm/i915/fbc: No need of any hardcoded plane width limit from LNL+Vinod Govindapillai1-4/+12
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
2026-07-24drm/xe/display: Expose plane max width/height helpers to global scopeVinod Govindapillai2-8/+17
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
2026-07-24drm/i915/dp: Ignore the sink's DSC max FRL rate without a PCON DSC encoderAlexander Kaplan1-1/+8
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: 10fec80b48c5 ("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
2026-07-24drm/i915/dp: Prefer DSC over 6 bpc uncompressed output for HDMI sinksAlexander Kaplan1-0/+14
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 ba49a4643cf5 ("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
2026-07-22drm/i915/dp: set VSC_SDP MSA delegation only for capable sinksChaitanya Kumar Borah2-4/+12
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
2026-07-22drm/i915/dp: s/intel_dp_needs_vsc_sdp/intel_dp_needs_vsc_colorimetryChaitanya Kumar Borah3-7/+7
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
2026-07-22drm/i915/display: Ensure a non-zero safe window from PTL onwardsAnkit Nautiyal1-0/+13
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: 4a68c7516c57 ("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
2026-07-22drm/i915/hdcp: Make hdcp2_encrypted and hdcp_encrypted mutually exclusiveSuraj Kandpal1-0/+2
With introduction of force_hdcp14 we can now for HDCP 1.4 by passing HDCP 2.2 authentication but In MST, _intel_hdcp_disable() and _intel_hdcp2_disable() can return early when there are still other streams active on the port (num_streams > 0), leaving the per-connector hdcp_encrypted / hdcp2_encrypted flag stale. If the same connector is later re-enabled with the other HDCP version (e.g. HDCP 1.4 via force_hdcp14 after a prior HDCP 2.2 session on that connector) the stale flag from the previous protocol survives. intel_hdcp_disable() then picks the wrong branch on the next disable causing the following splat. xe 0000:00:02.0: [drm] drm_WARN_ON(!(intel_de_read(display, ((((&(display)->info.__runtime_info)->ip.ver) >= 12) ? ((const i915_reg_t){ .reg = (((0x664B4) + (cpu_transcoder) * ((0x665B4) - (0x664B4)))) }) : ((const i915_reg_t){ .reg = ((((const u32 []){ 0x66800, 0x66500, 0x66600, 0x66700, 0x66A00, 0x66900 })[(port)]) + (0xB4)) }))) & ((u32)(((int)sizeof(struct {_Static_assert(!(__builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)((20) >= (sizeof(u32) * 8)) * 0l)) : (int *)8))), (20) >= (sizeof(u32) * 8), false)), "const_true((20) >= BITS_PER_TYPE(u32))" " is true");})) + ((((1ULL))) << (20)))))) WARNING: drivers/gpu/drm/i915/display/intel_hdcp.c:1969 at _intel_hdcp2_disable+0x4bf/0x520 [xe], CPU#2: kms_content_pro/101318 Modules linked in: xe vfio_pci_core vfio_iommu_type1 vfio iommufd xt_multiport snd_hda_codec_intelhdmi snd_hda_codec_hdmi drm_gpuvm drm_gpusvm_helper drm_buddy gpu_sched drm_ttm_helper ttm drm_suballoc_helper drm_exec drm_display_helper cec rc_core drm_kunit_helpers kunit i2c_algo_bit xt_conntrack xt_MASQUERADE bridge stp llc nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype nft_compat x_tables nf_tables xfrm_user xfrm_algo overlay cpuid cmdlinepart spi_nor mei_gsc_proxy mtd intel_rapl_msr wmi_bmof intel_uncore_frequency intel_uncore_frequency_common x86_pkg_temp_thermal intel_powerclamp coretemp snd_intel_dspcfg aesni_intel snd_hda_codec gf128mul snd_hda_core snd_hwdep r8169 snd_pcm intel_cstate snd_timer i2c_i801 i2c_mux snd spi_intel_pci processor_thermal_device_pci realtek video e1000e spi_intel i2c_smbus soundcore phy_package processor_thermal_device processor_thermal_wt_hint mei_me platform_temperature_control processor_thermal_soc_slider idma64 mei processor_thermal_rfim processor_thermal_rapl intel_ish_ipc intel_rapl_common intel_ishtp thunderbolt processor_thermal_wt_req processor_thermal_power_floor intel_vpu processor_thermal_mbox igen6_edac wmi sunrpc kvm_intel binfmt_misc kvm irqbypass int3403_thermal int340x_thermal_zone intel_skl_int3472_tps68470 tps68470_regulator intel_pmc_core clk_tps68470 acpi_tad int3400_thermal intel_hid pmt_telemetry acpi_thermal_rel sparse_keymap pmt_discovery pinctrl_intel_platform pmt_class intel_pmc_ssram_telemetry intel_pmc_pwrm_telemetry intel_skl_int3472_discrete intel_skl_int3472_common acpi_pad intel_vsec nls_iso8859_1 dm_multipath msr fuse efi_pstore autofs4 [last unloaded: xe_live_test] CPU: 2 UID: 0 PID: 101318 Comm: kms_content_pro Kdump: loaded Tainted: G U L N 7.2.0-rc2-lgci-xe-xe-5389-67aa8ad5c4c59cd1a-debug+ #1 PREEMPT(lazy) Tainted: [U]=USER, [L]=SOFTLOCKUP, [N]=TEST Hardware name: Intel Corporation Panther Lake Client Platform/PTL-UH LP5 T3 RVP1, BIOS PTLPFWI1.R00.3514.D01.2512291130 12/29/2025 RIP: 0010:_intel_hdcp2_disable+0x4c9/0x520 [xe] Code: 85 ff 74 04 48 8b 7f 08 4c 8b 7f 50 4d 85 ff 74 23 e8 5b 80 df e0 48 89 c6 48 8d 3d b1 f7 ba ff 48 c7 c1 a0 27 6a a1 4c 89 fa <67> 48 0f b9 3a e9 c9 fc ff ff 4c 8b 3f eb d8 e8 33 45 4e e1 4c 89 RSP: 0018:ffffc900027bf738 EFLAGS: 00010246 RAX: ffffffffa16bd4f1 RBX: ffff8881a1e69000 RCX: ffffffffa16a27a0 RDX: ffff8881c7b1b190 RSI: ffffffffa16bd4f1 RDI: ffffffffa100de30 RBP: ffffc900027bf7b0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88844397a000 R13: ffff88844397a000 R14: ffff88817f7d2000 R15: ffff8881c7b1b190 FS: 0000774e9299dbc0(0000) GS:ffff8884eb36c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000774e94bc7220 CR3: 00000002166c1002 CR4: 0000000108f72ef0 PKRU: 55555554 Call Trace: <TASK> ? intel_hdcp_update_value+0x7d/0x260 [xe] intel_hdcp_disable+0x118/0x130 [xe] intel_hdcp_update_pipe+0x175/0x1b0 [xe] ? intel_initial_watermarks+0x20/0x60 [xe] intel_ddi_update_pipe+0x44/0xb0 [xe] intel_pre_update_crtc+0x3bc/0x410 [xe] skl_commit_modeset_enables+0x1a7/0x890 [xe] ? icl_sagv_pre_plane_update+0x6c/0xf0 [xe] intel_atomic_commit_tail+0x114b/0x20a0 [xe] ? lock_release+0xd0/0x2a0 intel_atomic_commit+0x2ff/0x350 [xe] ? intel_atomic_commit+0x2ff/0x350 [xe] drm_atomic_commit+0xaf/0xf0 ? __pfx___drm_printfn_info+0x10/0x10 drm_mode_atomic_ioctl+0xcb5/0xf60 ? drm_mode_atomic_ioctl+0x8a8/0xf60 ? drm_mode_atomic_ioctl+0x604/0xf60 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xb3/0x120 drm_ioctl+0x2db/0x5a0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x51/0x80 ? __pm_runtime_resume+0x5b/0x90 ? xe_pm_runtime_get_ioctl+0x61/0x150 [xe] xe_drm_ioctl+0x64/0xb0 [xe] __x64_sys_ioctl+0xa5/0x100 x64_sys_call+0x1250/0x26e0 do_syscall_64+0x103/0x6d0 ? __task_pid_nr_ns+0xc0/0x290 ? trace_hardirqs_on_prepare+0xcb/0xf0 ? do_syscall_64+0x34/0x6d0 ? fred_entry_from_user+0x92/0x140 ? trace_hardirqs_on+0x22/0xe0 ? do_syscall_64+0xb8/0x6d0 fred_entry_from_user+0x92/0x140 asm_fred_entrypoint_user+0x41/ Ensure the two flags are mutually exclusive at every successful enable: after intel_hdcp_auth() succeeds. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Tested-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com> Reviewed-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com> Link: https://patch.msgid.link/20260717034734.477591-1-suraj.kandpal@intel.com
2026-07-21drm/i915/bw: Fix spelling mistake "threshod" -> "threshold"Colin Ian King1-1/+1
There is a spelling mistake in a drm_dbg_kms message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20260720161630.326016-1-colin.i.king@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-21drm/i915/bw: Update bw calculation to account for 16 channelsUma Shankar1-3/+17
Wa_16030862157: Update Bandwidth Calculation to account for 16channel memory config. v2: Logical separation of changes (Suraj, Vinod) WA: 16030862157, 16030875223 Bspec: 69131, 68859 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-3-uma.shankar@intel.com
2026-07-21drm/i915/dram: Interpret 0xF populated-channel count as 16Uma Shankar3-1/+16
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
2026-07-20drm/i915/dp_tunnel: Add UHBR tunneling supportImre Deak1-5/+32
Add support for UHBR link rates on Thunderbolt tunneled links. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-7-imre.deak@intel.com
2026-07-20drm/i915/dp: Disable UHBR link configs with 1/2 lanesImre Deak5-0/+75
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
2026-07-20drm/i915/dp: Remove UHBR dependency from SST fallback kunit testImre Deak1-35/+12
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
2026-07-20drm/i915/dp: Enable SST fallback between UHBR and non-UHBR ratesImre Deak2-17/+3
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
2026-07-20drm/i915/dp: End link configuration loops properlyImre Deak1-4/+15
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: 7266df62ed0a7 ("drm/i915/dp: Iterate configurations via link_caps for SST non-DSC") Fixes: 4f104fc10a461 ("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
2026-07-20drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for DPCD backlightSuraj Kandpal1-6/+1
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: ed8be780bdbc ("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
2026-07-17drm/i915/cdclk: Deal with 2 PPC hscale issues when calculating min CDCLKVille Syrjälä4-4/+88
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>
2026-07-17drm/i915/cdclk: Introduce crtc_state->pixel_rate_cdclkVille Syrjälä8-17/+28
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>
2026-07-17drm/i915/cdclk: Introduce HAS_2PPC()Ville Syrjälä2-1/+2
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>
2026-07-17drm/i915/cdclk: Use intel_cdclk_ppc() in intel_modeset_readout_hw_state()Ville Syrjälä3-9/+6
Replace the hand roller intel_cdclk_ppc() with the real thing in intel_modeset_readout_hw_state(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260715120926.10786-2-ville.syrjala@linux.intel.com Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
2026-07-15drm/i915/display: expose blend mode on alpha-capable planesChaitanya Kumar Borah3-0/+11
Since commit 860e748bddcc ("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
2026-07-15drm/i915/bw: introduce the peak bandwidth thresholdVinod Govindapillai2-0/+32
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
2026-07-15drm/i915/bw: avoid replicating the update_sagv_status() callsVinod Govindapillai1-7/+2
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
2026-07-15drm/i915/bw: extract update_sagv_status()Vinod Govindapillai1-20/+18
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
2026-07-15drm/i915/bw: Extract icl_init_qgv_info()Vinod Govindapillai1-5/+15
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
2026-07-15drm/i915/display: sagv pre/post plane calls to check pmdemand supportVinod Govindapillai1-0/+6
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
2026-07-15drm/i915/pm_demand: introduce HAS_PMDEMAND macroVinod Govindapillai5-11/+12
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
2026-07-15drm/i915/wm: clear the plane ddb_y entries on plane disableVinod Govindapillai1-1/+1
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: d34b59d5ba41 ("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
2026-07-15drm/i915/dmc: Enable PIPEDMC_ERROR interrupt on display version 30+Dibin Moolakadan Subrahmanian1-4/+6
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
2026-07-14drm/i915/display: Fix too few bits in transcoder mask variablesJohn Harrison6-27/+27
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: 789dda6429e0 ("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>
2026-07-14drm/i915: Throw away the BIOS fb if has the wrong depth/bppVille Syrjälä1-0/+9
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>
2026-07-14drm/i915/fbdev: Extract bios_fb_ok()Ville Syrjälä1-8/+18
Pull the "is the BIOS FB OK?" checks to a helper function. We'll add other relevant checks there later. 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-3-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.