summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display
AgeCommit message (Collapse)Author
5 daysdrm/i915/psr: Compute PSR entry_setup_frames into intel_crtc_stateJouni Högander
PSR entry_setup_frames is currently computed directly into struct intel_dp:intel_psr:entry_setup_frames. This causes a problem if mode change gets rejected after PSR compute config: Psr_entry_setup_frames computed for this rejected state is in intel_dp:intel_psr:entry_setup_frame. Fix this by computing it into intel_crtc_state and copy the value into intel_dp:intel_psr:entry_setup_frames on PSR enable. Fixes: 2b981d57e480 ("drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier") Cc: Mika Kahola <mika.kahola@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312083710.1593781-3-jouni.hogander@intel.com (cherry picked from commit 8c229b4aa00262c13787982e998c61c0783285e0) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
5 daysdrm/i915/psr: Disable PSR on update_m_n and update_lrrJouni Högander
PSR/PR parameters might change based on update_m_n or update_lrr. Disable on update_m_n and update_lrr to ensure proper parameters are taken into use on next PSR enable in intel_psr_post_plane_update. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15771 Fixes: 2bc98c6f97af ("drm/i915/alpm: Compute ALPM parameters into crtc_state->alpm_state") Cc: <stable@vger.kernel.org> # v6.19+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312083710.1593781-2-jouni.hogander@intel.com (cherry picked from commit 65852b56bfa929f99e28c96fd98b02058959da7f) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
6 daysdrm/i915/dmc: Fix an unlikely NULL pointer deference at probeImre Deak
intel_dmc_update_dc6_allowed_count() oopses when DMC hasn't been initialized, and dmc is thus NULL. That would be the case when the call path is intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() -> gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), as intel_power_domains_init_hw() is called *before* intel_dmc_init(). However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count() conditionally, depending on the current and target DC states. At probe, the target is disabled, but if DC6 is enabled, the function is called, and an oops follows. Apparently it's quite unlikely that DC6 is enabled at probe, as we haven't seen this failure mode before. It is also strange to have DC6 enabled at boot, since that would require the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and the driver stopping / reprogramming the firmware is a poorly specified sequence and as such unlikely an intentional BIOS behaviour. It's more likely that BIOS is leaving an unintentionally enabled DC6 HW state behind (without actually loading the required DMC firmware for this). The tracking of the DC6 allowed counter only works if starting / stopping the counter depends on the _SW_ DC6 state vs. the current _HW_ DC6 state (since stopping the counter requires the DC5 counter captured when the counter was started). Thus, using the HW DC6 state is incorrect and it also leads to the above oops. Fix both issues by using the SW DC6 state for the tracking. This is v2 of the fix originally sent by Jani, updated based on the first Link: discussion below. Link: https://lore.kernel.org/all/3626411dc9e556452c432d0919821b76d9991217@intel.com Link: https://lore.kernel.org/all/20260228130946.50919-2-ltao@redhat.com Fixes: 88c1f9a4d36d ("drm/i915/dmc: Create debugfs entry for dc6 counter") Cc: Mohammed Thasleem <mohammed.thasleem@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Tao Liu <ltao@redhat.com> Cc: <stable@vger.kernel.org> # v6.16+ Tested-by: Tao Liu <ltao@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260309164803.1918158-1-imre.deak@intel.com (cherry picked from commit 2344b93af8eb5da5d496b4e0529d35f0f559eaf0) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
12 daysdrm/i915/dp: Read ALPM caps after DPCD initArun R Murthy
For eDP read the ALPM DPCD caps after DPCD initalization and just before the PSR init. v2: Move intel_alpm_init to intel_edp_init_dpcd (Jouni) v3: Add Fixes with commit-id (Jouni) v4: Separated the alpm dpcd read caps from alpm_init and moved to intel_edp_init_dpcd. v5: Read alpm_caps always for eDP irrespective of the eDP version (Jouni) v6: replace drm_dp_dpcd_readb with drm_dp_dpcd_read_byte (Jouni) Fixes: 15438b325987 ("drm/i915/alpm: Add compute config for lobf") Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Animesh Manna <animesh.manna@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/20260304072157.1123283-1-arun.r.murthy@intel.com (cherry picked from commit 88442ba208dd5d3405de3f5000cf5b2c86876ae3) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
12 daysdrm/i915/psr: Write DSC parameters on Selective Update in ET modeJouni Högander
There are slice row per frame and pic height parameters in DSC that needs to be configured on every Selective Update in Early Transport mode. Use helper provided by DSC code to configure these on Selective Update when in Early Transport mode. Also fill crtc_state->psr2_su_area with full frame area on full frame update for DSC calculation. v2: move psr2_su_area under skip_sel_fetch_set_loop label Bspec: 68927, 71709 Fixes: 467e4e061c44 ("drm/i915/psr: Enable psr2 early transport as possible") Cc: <stable@vger.kernel.org> # v6.9+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260304113011.626542-5-jouni.hogander@intel.com (cherry picked from commit 3140af2fab505a4cd47d516284529bf1585628be) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
12 daysdrm/i915/dsc: Add helper for writing DSC Selective Update ET parametersJouni Högander
There are slice row per frame and pic height configuration in DSC Selective Update Parameter Set 1 register. Add helper for configuring these. v2: - Add WARN_ON_ONCE if vdsc instances per pipe > 2 - instead of checking vdsc instances per pipe being > 1 check == 2 Bspec: 71709 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260304113011.626542-4-jouni.hogander@intel.com (cherry picked from commit c8698d61aeb3f70fe33761ee9d3d0e131b5bc2eb) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> [tursulin: fixup forward declaration conflict]
12 daysdrm/i915/dsc: Add Selective Update register definitionsJouni Högander
Add definitions for DSC_SU_PARAMETER_SET_0_DSC0 and DSC_SU_PARAMETER_SET_0_DSC1 registers. These are for Selective Update Early Transport configuration. Bspec: 71709 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260304113011.626542-3-jouni.hogander@intel.com (cherry picked from commit 24f96d903daf3dcf8fafe84d3d22b80ef47ba493) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
12 daysdrm/i915/psr: Repeat Selective Update area alignmentJouni Högander
Currently we are aligning Selective Update area to cover cursor fully if needed only once. It may happen that cursor is in Selective Update area after pipe alignment and after that covering cursor plane only partially. Fix this by looping alignment as long as alignment isn't needed anymore. v2: - do not unecessarily loop if cursor was already fully covered - rename aligned as su_area_changed Fixes: 1bff93b8bc27 ("drm/i915/psr: Extend SU area to cover cursor fully if needed") Cc: <stable@vger.kernel.org> # v6.9+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260304113011.626542-2-jouni.hogander@intel.com (cherry picked from commit 681e12440d8b110350a5709101169f319e10ccbb) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
12 daysdrm/i915/vrr: Configure VRR timings after enabling TRANS_DDI_FUNC_CTLVille Syrjälä
Apparently ICL may hang with an MCE if we write TRANS_VRR_VMAX/FLIPLINE before enabling TRANS_DDI_FUNC_CTL. Personally I was only able to reproduce a hang (on an Dell XPS 7390 2-in-1) with an external display connected via a dock using a dodgy type-C cable that made the link training fail. After the failed link training the machine would hang. TGL seemed immune to the problem for whatever reason. BSpec does tell us to configure VRR after enabling TRANS_DDI_FUNC_CTL as well. The DMC firmware also does the VRR restore in two stages: - first stage seems to be unconditional and includes TRANS_VRR_CTL and a few other VRR registers, among other things - second stage is conditional on the DDI being enabled, and includes TRANS_DDI_FUNC_CTL and TRANS_VRR_VMAX/VMIN/FLIPLINE, among other things So let's reorder the steps to match to avoid the hang, and toss in an extra WARN to make sure we don't screw this up later. BSpec: 22243 Cc: stable@vger.kernel.org Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reported-by: Benjamin Tissoires <bentiss@kernel.org> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15777 Tested-by: Benjamin Tissoires <bentiss@kernel.org> Fixes: dda7dcd9da73 ("drm/i915/vrr: Use fixed timings for platforms that support VRR") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260303095414.4331-1-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> (cherry picked from commit 93f3a267c3dd4d811b224bb9e179a10d81456a74) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-03-04drm/i915/psr: Fix for Panel Replay X granularity DPCD register handlingJouni Högander
DP specification is saying value 0xff 0xff in PANEL REPLAY SELECTIVE UPDATE X GRANULARITY CAPABILITY registers (0xb2 and 0xb3) means full-line granularity. Take this into account when handling Panel Replay X granularity informed by the panel. Fixes: 1cc854647450 ("drm/i915/psr: Use SU granularity information available in intel_connector") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7284 Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260225074221.1744330-2-jouni.hogander@intel.com (cherry picked from commit f5c8f824a495e849492f09a43bd965a8f4d86cb2) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-02-23drm/i915/alpm: ALPM disable fixesJouni Högander
PORT_ALPM_CTL is supposed to be written only before link training. Remove writing it from ALPM disable. Also clearing ALPM_CTL_ALPM_AUX_LESS_ENABLE and is not about disabling ALPM but switching to AUX-Wake ALPM. Stop touching this bit on ALPM disable. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7153 Fixes: 1ccbf135862b ("drm/i915/psr: Enable ALPM on source side for eDP Panel replay") Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.10+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260212062731.397801-1-jouni.hogander@intel.com (cherry picked from commit 008304c9ae75c772d3460040de56e12112cdf5e6) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-02-22Convert remaining multi-line kmalloc_obj/flex GFP_KERNEL usesKees Cook
Conversion performed via this Coccinelle script: // SPDX-License-Identifier: GPL-2.0-only // Options: --include-headers-for-types --all-includes --include-headers --keep-comments virtual patch @gfp depends on patch && !(file in "tools") && !(file in "samples")@ identifier ALLOC = {kmalloc_obj,kmalloc_objs,kmalloc_flex, kzalloc_obj,kzalloc_objs,kzalloc_flex, kvmalloc_obj,kvmalloc_objs,kvmalloc_flex, kvzalloc_obj,kvzalloc_objs,kvzalloc_flex}; @@ ALLOC(... - , GFP_KERNEL ) $ make coccicheck MODE=patch COCCI=gfp.cocci Build and boot tested x86_64 with Fedora 42's GCC and Clang: Linux version 6.19.0+ (user@host) (gcc (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7), GNU ld version 2.44-12.fc42) #1 SMP PREEMPT_DYNAMIC 1970-01-01 Linux version 6.19.0+ (user@host) (clang version 20.1.8 (Fedora 20.1.8-4.fc42), LLD 20.1.8) #1 SMP PREEMPT_DYNAMIC 1970-01-01 Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21Convert more 'alloc_obj' cases to default GFP_KERNEL argumentsLinus Torvalds
This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21Convert 'alloc_flex' family to use the new default GFP_KERNEL argumentLinus Torvalds
This is the exact same thing as the 'alloc_obj()' version, only much smaller because there are a lot fewer users of the *alloc_flex() interface. As with alloc_obj() version, this was done entirely with mindless brute force, using the same script, except using 'flex' in the pattern rather than 'objs*'. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-21Merge tag 'drm-intel-next-fixes-2026-02-20' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Add missing slice count check during DP mode validation Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/aZgb43cDcTPBYssk@jlahtine-mobl
2026-02-18Merge tag 'drm-intel-next-fixes-2026-02-13' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Regresion fix for HDR 4k displays (#15503) - Fixup for Dell XPS 13 7390 eDP rate limit - Memory leak fix on ACPI _DSM handling Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/aY8CtbhijtetQ6P3@jlahtine-mobl
2026-02-17drm/i915/dp: Add missing slice count check during mode validationImre Deak
Add the missing check for a valid slice count during mode validation when DSC is enabled. Cc: Vinod Govindapillai <vinod.govindapillai@intel.com> Fixes: 745395b51c26 ("drm/i915/dp: Add intel_dp_mode_valid_with_dsc()") Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260216070421.714884-2-imre.deak@intel.com (cherry picked from commit ec4db429fd38e5c5cbea3521049739fd2718845c) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-02-12drm/i915/acpi: free _DSM package when no connectorsKaushlendra Kumar
acpi_evaluate_dsm_typed() returns an ACPI package in pkg. When pkg->package.count == 0, we returned without freeing pkg, leaking memory. Free pkg before returning on the empty case. Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> Fixes: 337d7a1621c7 ("drm/i915: Fix invalid access to ACPI _DSM objects") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260109032549.1826303-1-kaushlendra.kumar@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit c0a27a0ca8a34e96d08bb05a2c5d5ccf63fb8dc0) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-02-12drm/i915/dp: Fix pipe BPP clamping due to HDRImre Deak
The pipe BPP value shouldn't be set outside of the source's / sink's valid pipe BPP range, ensure this when increasing the minimum pipe BPP value to 30 due to HDR. While at it debug print if the HDR mode was requested for a connector by setting the corresponding HDR connector property. This indicates if the requested HDR mode could not be enabled, since the selected pipe BPP is below 30, due to a sink capability or link BW limit. v2: - Also handle the case where the sink could support the target 30 BPP only in DSC mode due to a BW limit, but the sink doesn't support DSC or 30 BPP as a DSC input BPP. (Chaitanya) - Debug print the connector's HDR mode in the link config dump, to indicate if a BPP >= 30 required by HDR couldn't be reached. (Ankit) - Add Closes: trailer. (Ankit) - Don't print the 30 BPP-outside of valid BPP range debug message if the min BPP is already > 30 (and so a target BPP >= 30 required for HDR is ensured). Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7052 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15503 Fixes: ba49a4643cf53 ("drm/i915/dp: Set min_bpp limit to 30 in HDR mode") Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> # v1 Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260209133817.395823-1-imre.deak@intel.com (cherry picked from commit 08b7ef16b6a03e8c966e286ee1ac608a6ffb3d4a) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-02-09drm/i915/quirks: Fix device id for QUIRK_EDP_LIMIT_RATE_HBR2 entryAnkit Nautiyal
Update the device ID for Dell XPS 13 7390 2-in-1 in the quirk `QUIRK_EDP_LIMIT_RATE_HBR2` entry. The previous ID (0x8a12) was incorrect; the correct ID is 0x8a52. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Fixes: 21c586d9233a ("drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20251226043359.2553-1-ankit.k.nautiyal@intel.com (cherry picked from commit c7c30c4093cc11ff66672471f12599a555708343) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-02-06Merge tag 'drm-intel-next-fixes-2026-02-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Fix the pixel normalization handling for xe3p_lpd display Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/aYROngKfyUIyoQW0@jlahtine-mobl
2026-02-02drm/i915/display: fix the pixel normalization handling for xe3p_lpdVinod Govindapillai
Pixel normalizer is enabled with normalization factor as 1.0 for FP16 formats in order to support FBC for those formats in xe3p_lpd. Previously pixel normalizer gets disabled during the plane disable routine. But there could be plane format settings without explicitly calling the plane disable in-between and we could endup keeping the pixel normalizer enabled for formats which we don't require that. This is causing crc mismatches in yuv formats and FIFO underruns in planar formats like NV12. Fix this by updating the pixel normalizer configuration based on the pixel formats explicitly during the plane settings arm calls itself - enable it for FP16 and disable it for other formats in HDR capable planes. v2: avoid redundant pixel normalization setting updates v3: moved the normalization factor definition to intel_fbc.c and some updates to comments v4: simplified the pixel normalizer setting handling Fixes: 5298eea7ed20 ("drm/i915/xe3p_lpd: use pixel normalizer for fp16 formats for FBC") Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260130095919.107805-1-vinod.govindapillai@intel.com (cherry picked from commit c0dc68f4e2aa7eddb9ec6d95931f9576d8fe7334) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-01-30Merge tag 'drm-intel-next-fixes-2026-01-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Prevent u64 underflow in intel_fbc_stolen_end Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/aXsWGWjacEJ03rTs@jlahtine-mobl
2026-01-28BackMerge tag 'v6.19-rc7' into drm-nextDave Airlie
Linux 6.19-rc7 This is needed for msm and rust trees. Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-01-26drm/i915/display: Prevent u64 underflow in intel_fbc_stolen_endJonathan Cavitt
Static analysis reveals a potential integer underflow in intel_fbc_stolen_end. This can apparently occur if intel_parent_stolen_area_size returns zero (or, theoretically, any value less than 2^23), as 2^23 is subtracted from the return value and stored in a u64. While this doesn't appear to cause any issues due to the use of the min() function to clamp the return values from the intel_fbc_stolen_end function, it would be best practice to avoid undeflowing values like this on principle. So, rework the function to prevent the underflow from occurring. Note that the underflow at present would result in the value of intel_fbc_cfb_base_max being returned at the end of intel_fbc_stolen_end, so just return that if the value of intel_parent_stolen_area_size is too small. While we're here, fix the other comments here and modify the execution path for readability. v2: (Jani) - Fix the comments in intel_fbc_stolen_end - Use check_sub_overflow - Remove macro that mirrors SZ_8M, as it is now only referenced once - Misc. formatting fixes Fixes: a9da512b3ed7 ("drm/i915: avoid the last 8mb of stolen on BDW/SKL") Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260107162935.8123-2-jonathan.cavitt@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 6695dc279820a50cb20ecd8b5250e05234dac780) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-01-22drm/i915/display: Fix color pipeline enum name leakChaitanya Kumar Borah
intel_color_pipeline_plane_init() allocates enum names for color pipelines, which are copied by drm_property_create_enum(). The temporary strings were not freed, resulting in a memory leak. Allocate enum names only after successful pipeline construction and free them on all exit paths. Fixes: ef105316819d ("drm/i915/color: Create a transfer function color pipeline") Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260113102303.724205-5-chaitanya.kumar.borah@intel.com
2026-01-22drm/i915/color: Place 3D LUT after CSC in plane color pipelineChaitanya Kumar Borah
Move the 3D LUT block to its correct position in the plane color pipeline: [Pre-CSC] -> [CSC] -> [3DLUT] -> [Post-CSC] Fixes: 65db7a1f9cf7 ("drm/i915/color: Add 3D LUT to color pipeline") Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260113102303.724205-2-chaitanya.kumar.borah@intel.com
2026-01-19drm/i915/psr: Don't enable Panel Replay on sink if globally disabledJouni Högander
With some panels informing support for Panel Replay we are observing problems if having Panel Replay enable bit set on sink when forced to use PSR instead of Panel Replay. Avoid these problems by not setting Panel Replay enable bit in sink when Panel Replay is globally disabled during link training. I.e. disabled by module parameter. The enable bit is still set when disabling Panel Replay via debugfs interface. Added note comment about this. Fixes: 68f3a505b367 ("drm/i915/psr: Enable Panel Replay on sink always when it's supported") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v6.15+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260115070039.368965-1-jouni.hogander@intel.com (cherry picked from commit c5a52cd04e24f0ae53fda26f74ab027b8c548e0e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-01-16Merge tag 'drm-intel-next-2026-01-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Beyond Display: - Make 'guc_hw_reg_state' static as it isn't exported (Ben) - Fix doc build on mei related interface header (Jani) Display related: - Fix ggtt fb alignment on Xe display (Tvrtko) - More display clean-up towards deduplication and full separation (Jani) - Use the consolidated HDMI tables (Suraj) - Account for DSC slice overhead (Ankit) - Prepare GVT for display modularization (Ankit, Jani) - Enable/Disable DC balance along with VRR DSB (Mitul, Ville) - Protection against unsupported modes in LT PHY (Suraj) - Display W/a addition and fixes (Gustavo) - Fix many SPDX identifier comments (Ankit) - Incorporate Xe3_LPD changes for CD2X divider (Gustavo) - Clean up link BW/DSC slice config computation (Imre) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/aWkNThVRSkGAfUVv@intel.com
2026-01-13drm/i915/dp: Simplify computing the DSC compressed BPP for DP-MSTImre Deak
The minimum/maximum DSC input (i.e. pipe) and compressed (i.e. link) BPP limits are computed already in intel_dp_compute_config_limits(), so there is no need to do this again in mst_stream_dsc_compute_link_config() called later. Remove the corresponding alignments from the latter function and use the precomputed (aligned and within bounds) maximum pipe BPP and the min/max compressed BPP values instead as-is. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-21-imre.deak@intel.com
2026-01-13drm/i915/dp: Simplify eDP vs. DP compressed BPP computationImre Deak
intel_edp_dsc_compute_pipe_bpp() matches now intel_dp_dsc_compute_pipe_bpp(), remove the former function. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-20-imre.deak@intel.com
2026-01-13drm/i915/dp: Unify computing compressed BPP for DP-SST and eDPImre Deak
Move computing the eDP compressed BPP value to the function computing this for DP, allowing further simplifications later. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-19-imre.deak@intel.com
2026-01-13drm/i915/dp: Simplify computing forced DSC BPP for DP-SSTImre Deak
If dsc_compute_compressed_bpp() failed with a forced pipe BPP value (where the forced pipe BPP value itself is valid within the min/max pipe BPP limits), the function will also fail when called with the maximum pipe BPP value: dsc_compute_compressed_bpp() will try all compressed BPPs below the passed in pipe BPP value and if the function failed with a given (low) compressed BPP value it will also fail with a compressed BPP value higher than the one which failed already. Based on the above remove the logic to retry computing a compressed BPP value with the maximum pipe BPP value if computing the compressed BPP failed already with the (lower) forced pipe BPP value. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-18-imre.deak@intel.com
2026-01-13drm/i915/dp: Simplify computing DSC BPPs for DP-SSTImre Deak
The maximum pipe BPP value (used as the DSC input BPP) has been aligned already to the corresponding source/sink input BPP capabilities in intel_dp_compute_config_limits(). So it isn't needed to perform the same alignment again in intel_dp_dsc_compute_pipe_bpp() called later, this function can simply use the already aligned maximum pipe BPP value, do that. Also, there is no point in trying pipe BPP values lower than the maximum: this would only make dsc_compute_compressed_bpp() start with a lower _compressed_ BPP value, but this lower compressed BPP value has been tried already when dsc_compute_compressed_bpp() was called with the higher pipe BPP value (i.e. the first dsc_compute_compressed_bpp() call tries already all the possible compressed BPP values which are all below the pipe BPP value passed to it). Simplify the function accordingly trying only the maximum pipe BPP value. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-17-imre.deak@intel.com
2026-01-13drm/i915/dp: Simplify computing DSC BPPs for eDPImre Deak
The maximum pipe BPP value (used as the DSC input BPP) has been aligned already to the corresponding source/sink input BPP capabilities in intel_dp_compute_config_limits(). So it isn't needed to perform the same alignment again in intel_edp_dsc_compute_pipe_bpp() called later, this function can simply use the already aligned maximum pipe BPP value, do that. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-16-imre.deak@intel.com
2026-01-13drm/i915/dp: Use helpers to align min/max compressed BPPsImre Deak
The minimum/maximum compressed BPP values are aligned/bounded in intel_dp_compute_link_bpp_limits() to the corresponding source limits. The minimum compressed BPP value doesn't change afterwards, so no need to align it again, remove that. The maximum compressed BPP, which depends on the pipe BPP value still needs to be aligned, since the pipe BPP value could change after the above limits were computed, via intel_dp_force_dsc_pipe_bpp(). Use the corresponding helper for this alignment instead of open-coding the same. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-15-imre.deak@intel.com
2026-01-13drm/i915/dp: Unify detect and compute time DSC mode BW validationImre Deak
Atm, a DP DSC video mode's required BW vs. the available BW is determined by calculating the maximum compressed BPP value allowed by the available BW. Doing that using a closed-form formula as it's done atm (vs. an iterative way) is problematic, since the overhead of the required BW itself depends on the BPP value being calculated. Instead of that calculate the required BW for the minimum compressed BPP value supported both by the source and the sink and check this BW against the available BW. This change also aligns the BW calculation during mode validation with how this is done during state computation, calculating the required effective data rate with the corresponding BW overhead. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-14-imre.deak@intel.com
2026-01-13drm/i915/dp: Add intel_dp_mode_valid_with_dsc()Imre Deak
Add intel_dp_mode_valid_with_dsc() and call this for an SST/MST mode validation to prepare for a follow-up change using a way to verify the mode's required BW the same way this is done elsewhere during state computation (which in turn depends on the mode's effective data rate with the corresponding BW overhead). Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-13-imre.deak@intel.com
2026-01-13drm/i915/dp: Factor out compute_max_compressed_bpp_x16()Imre Deak
Factor out compute_max_compressed_bpp_x16() also used during mode validation in a follow-up change. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-12-imre.deak@intel.com
2026-01-13drm/i915/dp: Factor out compute_min_compressed_bpp_x16()Imre Deak
Factor out compute_min_compressed_bpp_x16() also used during mode validation in a follow-up change. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-11-imre.deak@intel.com
2026-01-13drm/i915/dp: Pass mode clock to dsc_throughput_quirk_max_bpp_x16()Imre Deak
Prepare for follow-up changes using dsc_throughput_quirk_max_bpp_x16() without an intel_crtc_state pointer. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-10-imre.deak@intel.com
2026-01-13drm/i915/dp: Pass intel_output_format to ↵Imre Deak
intel_dp_dsc_sink_{min_max}_compressed_bpp() Prepare for follow-up changes also calling intel_dp_dsc_min_sink_compressed_bpp() / intel_dp_dsc_max_sink_compressed_bpp_x16() without an intel_crtc_state. While at it remove the stale function declarations from the header file. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-9-imre.deak@intel.com
2026-01-13drm/i915/dp: Drop intel_dp parameter from ↵Imre Deak
intel_dp_compute_config_link_bpp_limits() The intel_dp pointer can be deducted from the connector pointer, so it's enough to pass only connector to intel_dp_compute_config_link_bpp_limits(), do so. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-8-imre.deak@intel.com
2026-01-13drm/i915/dp: Align min/max compressed BPPs when calculating BPP limitsImre Deak
Align the minimum/maximum DSC compressed BPPs to the corresponding source compressed BPP limits already when computing the BPP limits. This alignment is also performed later during state computation, however there is no reason to initialize the limits to an unaligned/incorrect value. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-7-imre.deak@intel.com
2026-01-13drm/i915/dp: Align min/max DSC input BPPs to sink capsImre Deak
Align the minimum/maximum DSC input BPPs to the corresponding sink DSC input BPP capability limits already when computing the BPP limits. This alignment is also performed later during state computation, however there is no reason to initialize the limits to an unaligned/incorrect value. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-6-imre.deak@intel.com
2026-01-13drm/i915/dp: Factor out align_max_vesa_compressed_bpp_x16()Imre Deak
Factor out align_max_vesa_compressed_bpp_x16(), also used later for computing the maximum DSC compressed BPP limit. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-5-imre.deak@intel.com
2026-01-13drm/i915/dp: Factor out align_max_sink_dsc_input_bpp()Imre Deak
Factor out align_max_sink_dsc_input_bpp(), also used later for computing the maximum DSC input BPP limit. Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-4-imre.deak@intel.com
2026-01-13drm/i915/dp: Drop unused timeslots param from dsc_compute_link_config()Imre Deak
Drop the unused timeslots parameter from dsc_compute_link_config() and other functions calling it. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251222153547.713360-2-imre.deak@intel.com
generated by cgit v1.2.3 (git 2.0.4) at 2026-03-22 11:22:49 +0000