summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)Author
3 daysMerge branch 'master' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git # Conflicts: # arch/x86/mm/pat/set_memory.c
3 daysMerge branch 'for-linux-next' of ↵Mark Brown
https://gitlab.freedesktop.org/drm/i915/kernel.git
3 daysMerge branch 'drm-next' of https://gitlab.freedesktop.org/drm/kernel.gitMark Brown
3 daysMerge branch 'mm-unstable' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
3 daysMerge branch into tip/master: 'perf/merge'Ingo Molnar
# New commits in perf/merge: 3eaa50e1e255 ("x86/cpu: Hide and rename static_cpu_has()") edda9051e267 ("perf/x86/amd/uncore: Add group validation") d7ebbae57de3 ("selftests/bpf: Add tests for forked/cloned optimized uprobes") eccf368562bb ("selftests/bpf: Add tests for uprobe nop10 red zone clobbering") 28d57db3e8d4 ("selftests/bpf: Add reattach tests for uprobe syscall") b2cf7c41e4f1 ("selftests/bpf: Change uprobe/usdt trigger bench code to use nop10") ec0596a02083 ("selftests/bpf: Change uprobe syscall tests to use nop10") 6d91200bcbb5 ("selftests/bpf: Emit nop,nop10 instructions combo for x86_64 arch") 8cae54c58608 ("libbpf: Detect uprobe syscall with new error") ee2862439e5c ("libbpf: Change has_nop_combo to work on top of nop10") 554ba38456da ("uprobes/x86: Move optimized uprobe from nop5 to nop10") d9a48e77f6fe ("uprobes/x86: Allow to copy uprobe trampolines on fork") 07c308eb2bcf ("uprobes/x86: Do not leak trampoline vma mapping on optimization failure") 38af0dd6a266 ("uprobes/x86: Remove struct uprobe_trampoline object") a4573a3838ae ("perf/core: Check kernel access when kernel callchains are requested") 166f10836a65 ("perf/core: Fix kernel register info leak via hardware skid") a6b5fbc33172 ("perf/x86/intel: Drop fixed-counter PEBS constraints for baseline PEBS") 01c153956b44 ("perf/x86/intel: Validate the return value of intel_pmu_init_hybrid()") e2b0575900ff ("perf/x86/intel: Fix kernel address leakages in LBR stack") 170cc6b02e3d ("perf/x86/intel: Fallback to sw branch type decoding if no hw decoding") 3c4ec9b2a5db ("perf/x86/intel: Keep cap_user_rdpmc in sync with RDPMC user-disable state") 8767b4d73018 ("perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities") b25813b17944 ("perf/x86/intel/uncore: Implement lazy setup for MSR/MMIO PMUs") 174f0582e38a ("perf/x86/intel/uncore: Fix uncore_box ref/unref ordering") 30c0a1095652 ("perf/x86/intel/uncore: Introduce PMU flags and broken state") ae7ca8796dda ("perf/x86/intel/uncore: Factor out box setup code") 3012af7df343 ("perf/x86/intel/uncore: Keep PCI PMUs working when MMIO/MSR setup fails") cbbc25209ce3 ("perf/x86/intel/uncore: Let init_box() callback report failures") 7d3a9ff98898 ("perf/x86/intel/uncore: Fix refcnt and other cleanups") 003267cb94e2 ("perf/x86/intel/uncore: Fix PCI PMU cleanup on setup failure") Signed-off-by: Ingo Molnar <mingo@kernel.org>
3 daysmm: introduce vma_get_page_prot() and use itLorenzo Stoakes
There's a large number of vm_get_page_prot(vma->vm_flags) invocations. Make life easier by introducing vma_get_page_prot() parameterised by the VMA. This also makes converting vm_get_page_prot() to vma_flags_t easier. Also update the userland VMA tests to reflect the change. No functional change intended. Link: https://lore.kernel.org/20260711-b4-vma-flags-mm-v2-8-0fa2357d5431@kernel.org Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: Zi Yan <ziy@nvidia.com> Acked-by: Jani Nikula <jani.nikula@intel.com> # for i915 Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> [DRM] Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Dave Airlie <airlied@gmail.com> Cc: David Hildenbrand <david@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nico Pache <npache@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
3 daysshmem: provide a shmem_write_folio wrapperChristoph Hellwig
Patch series "better block swap batching and a different take on swap_ops v5". This series makes use of the swap_iocb for block as well so that it doesn't do inefficient single-bio I/O, and then rebases the swap_ops from Baoquan on top of the now very different method structure. When running doing kernels builds, which is a workload that doesn't really do much THP anonymous memory it still gets 2x clustering for writeout and 1.2x for reading back swap in. The overall times do not actually change, though. This patch (of 7): Provide a wrapper for the shmem abuses in drm to prepare for swap I/O refactoring by keeping swap_iocb handling entirely contained in mm/. Link: https://lore.kernel.org/20260713093350.2154226-1-hch@lst.de Link: https://lore.kernel.org/20260713093350.2154226-2-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Baoquan He <baoquan.he@linux.dev> Reviewed-by: Nhat Pham <nphamcs@gmail.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by: Chris Li <chrisl@kernel.org> Reviewed-by: Kairui Song <kasong@tencent.com> Cc: Kemeng Shi <shikemeng@huaweicloud.com> Cc: Barry Song <baohua@kernel.org> Cc: Youngjun Park <youngjun.park@lge.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
4 daysdrm/i915/dp: set VSC_SDP MSA delegation only for capable sinksChaitanya Kumar Borah
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
4 daysdrm/i915/dp: s/intel_dp_needs_vsc_sdp/intel_dp_needs_vsc_colorimetryChaitanya Kumar Borah
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
4 daysdrm/i915/display: Ensure a non-zero safe window from PTL onwardsAnkit Nautiyal
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
4 daysdrm/i915/hdcp: Make hdcp2_encrypted and hdcp_encrypted mutually exclusiveSuraj Kandpal
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
4 daysdrm/i915/bw: Fix spelling mistake "threshod" -> "threshold"Colin Ian King
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>
5 daysdrm/i915/bw: Update bw calculation to account for 16 channelsUma Shankar
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
5 daysdrm/i915/dram: Interpret 0xF populated-channel count as 16Uma Shankar
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
6 daysdrm/i915/dp_tunnel: Add UHBR tunneling supportImre Deak
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
6 daysdrm/i915/dp: Disable UHBR link configs with 1/2 lanesImre Deak
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
6 daysdrm/i915/dp: Remove UHBR dependency from SST fallback kunit testImre Deak
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
6 daysdrm/i915/dp: Enable SST fallback between UHBR and non-UHBR ratesImre Deak
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
6 daysdrm/i915/dp: End link configuration loops properlyImre Deak
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
6 daysdrm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for DPCD ↵Suraj Kandpal
backlight 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 (cherry picked from commit 7d594b24c915afb4b0c5fb8875403253daef5b24) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
6 daysdrm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for DPCD ↵Suraj Kandpal
backlight 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
9 daysdrm/i915/cdclk: Deal with 2 PPC hscale issues when calculating min CDCLKVille Syrjälä
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>
9 daysdrm/i915/cdclk: Introduce crtc_state->pixel_rate_cdclkVille Syrjälä
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>
9 daysdrm/i915/cdclk: Introduce HAS_2PPC()Ville Syrjälä
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>
9 daysdrm/i915/cdclk: Use intel_cdclk_ppc() in intel_modeset_readout_hw_state()Ville Syrjälä
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>
9 daysMerge tag 'drm-intel-gt-next-2026-07-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Driver Changes: Fixes/improvements/new stuff: - Fix phys BO pread/pwrite with offset [gem] (Joonas Lahtinen) - Add missing nospec on parallel submit slot [gem] (Joonas Lahtinen) - Return NULL on error in active_instance (Joonas Lahtinen) - Fix NULL deref in I915_CONTEXT_PARAM_SSEU [gem] (Joonas Lahtinen) - Fix NULL deref on sched_engine alloc failure [gt] (Joonas Lahtinen) - Do not leak siblings[] on proto context error [gem] (Joonas Lahtinen) Miscellaneous: - Return bool values from a boolean helper [gt] (Andi Shyti) - Use correct selftest config symbol [gt] (Pengpeng Hou) - Fix GT PM sort comparators [selftests] (Emre Cecanpunar) - Return NULL for missing multi-lrc parent [guc] (Linmao Li) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tursulin@igalia.com> Link: https://patch.msgid.link/aliZXnfbOV-Mh8gZ@linux
10 daysdrm/i915/selftests: Fix GT PM sort comparatorsEmre Cecanpunar
Compare the sampled clock values instead of their addresses. Comparing addresses leaves the samples unsorted, preventing the code from discarding the minimum and maximum samples. Fixes: 1a5392479207 ("drm/i915/selftests: Measure CS_TIMESTAMP") Signed-off-by: Emre Cecanpunar <emreleno@gmail.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260714220430.238433-1-emreleno@gmail.com (cherry picked from commit 682ea2d28d18bb06f9fc663cb5ab7e80dc0e606a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
10 daysdrm/i915/wm: clear the plane ddb_y entries on plane disableVinod Govindapillai
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 (cherry picked from commit 60f68a6ba298fd1e971a2d91576304bee89a16fc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
11 daysdrm/i915/selftests: Fix GT PM sort comparatorsEmre Cecanpunar
Compare the sampled clock values instead of their addresses. Comparing addresses leaves the samples unsorted, preventing the code from discarding the minimum and maximum samples. Fixes: 1a5392479207 ("drm/i915/selftests: Measure CS_TIMESTAMP") Signed-off-by: Emre Cecanpunar <emreleno@gmail.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260714220430.238433-1-emreleno@gmail.com
11 daysdrm/i915/display: expose blend mode on alpha-capable planesChaitanya Kumar Borah
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
11 daysdrm/i915/bw: introduce the peak bandwidth thresholdVinod Govindapillai
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
11 daysdrm/i915/bw: avoid replicating the update_sagv_status() callsVinod Govindapillai
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
11 daysdrm/i915/bw: extract update_sagv_status()Vinod Govindapillai
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
11 daysdrm/i915/bw: Extract icl_init_qgv_info()Vinod Govindapillai
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
11 daysdrm/i915/display: sagv pre/post plane calls to check pmdemand supportVinod Govindapillai
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
11 daysdrm/i915/pm_demand: introduce HAS_PMDEMAND macroVinod Govindapillai
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
11 daysdrm/i915/wm: clear the plane ddb_y entries on plane disableVinod Govindapillai
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
11 daysdrm/i915/dmc: Enable PIPEDMC_ERROR interrupt on display version 30+Dibin Moolakadan Subrahmanian
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
12 daysdrm/i915/display: Fix too few bits in transcoder mask variablesJohn Harrison
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>
12 daysdrm/i915/display: Fix NV12 ceiling division for bigjoiner caseVidya Srinivas
Commit 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation") computes the UV (chroma) surface start/size as ceiling(half of Y plane start/size) directly from the U16.16 fixed-point source rectangle: x = fp_16_16_to_int_ceil(fp_16_16_div2(src.x1)); For a single pipe the source coordinates are integers, so this is correct. (UV start = ceiling(half of Y plane start)). With bigjoiner + a plane scaler the picture changes. The pipe boundary is a fixed integer destination pixel, but the plane's position and the scaler ratio are arbitrary, so drm_rect_clip_scaled() maps the seam back to a *fractional* per-pipe source. For a 1280->2407 upscaled NV12 plane crossing the seam: master src: width = 1204 * 1280/2407 = 640.265899, x1 = 0 joiner src: width = 1203 * 1280/2407 = 639.734115, x1 = 640.265884 The luma path floors this to an integer (src.x1 >> 16 = 640), but the UV path takes ceiling(640.265884 / 2) = ceil(320.13) = 321. The Y plane then starts at column 640 while the UV plane starts at 321*2 = 642, pushing the chroma read one column past the 640-wide chroma surface on the joiner secondary: [CRTC:382:pipe C] PLANE ATS fault [CRTC:382:pipe C][PLANE:267:plane 1C] fault (CTL=0x81009400, ...) The spec "Y plane start" is the integer pixel the luma surface actually programs (640), not the pre-floor fixed-point value (640.27). Convert the Y plane start/size to integer first - matching skl_check_main_surface() - and then apply the ceiling. This is a no-op for the integer (non-joiner) case and yields the correct, in-bounds chroma offset for the fractional joiner seam: before fix after fix master 1B: x=0 w=321 x=0 w=320 -> [0, 320) slave 1C: x=321 w=320 x=320 w=320 -> [320, 640) The two halves now tile the 640-wide chroma plane exactly and the ATS fault is gone. Assisted-by: GitHub-Copilot:Claude-Opus-4.8 Fixes: 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation") Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260618181837.687302-1-vidya.srinivas@intel.com (cherry picked from commit 0c59cc78241c10e5f02d92b28d811b0435e706a7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
12 daysdrm/i915: Print the phys_base in addition to the dma_addr for the BIOS FBVille Syrjälä
Print the dma_addr, phys_base and memory region name for the BIOS FB. Should make it a bit easier to see whether everything looks correct or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260511214122.8468-15-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
12 daysdrm/i915: Fix BIOS FB memory region name debug printsVille Syrjälä
Apparently we never initialize the name of the struct resource underlying the memory region. Instead we need to look at the name stored directly in the memory region itself. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260511214122.8468-14-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
12 daysdrm/i915: Use drm_dbg_kms() for initial FB debugsVille Syrjälä
The initial FB stuff is ultimately about display stuff, so use the proper display specific debug level for it. 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-6-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
12 daysdrm/i915: Throw away the BIOS fb if has the wrong depth/bppVille Syrjälä
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>
12 daysdrm/i915/fbdev: Extract bios_fb_ok()Ville Syrjälä
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>
12 daysdrm/i915: Disable the plane if initial plane config readout failedVille Syrjälä
Properly turn off the plane if it is enabled but .get_initial_plane_config() failed for whatever reason. The hardware does (or at least did) perform some kind of automagic plane disable when the pipe gets disabled, but we don't rely on that anywhere else either. Also the GGTT/actual memory may get clobbered afterwards, so leaving the plane enabled here could result in visual corruption/GTT faults/etc. 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-2-ville.syrjala@linux.intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
12 daysdrm/i915/display: Fix NV12 ceiling division for bigjoiner caseVidya Srinivas
Commit 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation") computes the UV (chroma) surface start/size as ceiling(half of Y plane start/size) directly from the U16.16 fixed-point source rectangle: x = fp_16_16_to_int_ceil(fp_16_16_div2(src.x1)); For a single pipe the source coordinates are integers, so this is correct. (UV start = ceiling(half of Y plane start)). With bigjoiner + a plane scaler the picture changes. The pipe boundary is a fixed integer destination pixel, but the plane's position and the scaler ratio are arbitrary, so drm_rect_clip_scaled() maps the seam back to a *fractional* per-pipe source. For a 1280->2407 upscaled NV12 plane crossing the seam: master src: width = 1204 * 1280/2407 = 640.265899, x1 = 0 joiner src: width = 1203 * 1280/2407 = 639.734115, x1 = 640.265884 The luma path floors this to an integer (src.x1 >> 16 = 640), but the UV path takes ceiling(640.265884 / 2) = ceil(320.13) = 321. The Y plane then starts at column 640 while the UV plane starts at 321*2 = 642, pushing the chroma read one column past the 640-wide chroma surface on the joiner secondary: [CRTC:382:pipe C] PLANE ATS fault [CRTC:382:pipe C][PLANE:267:plane 1C] fault (CTL=0x81009400, ...) The spec "Y plane start" is the integer pixel the luma surface actually programs (640), not the pre-floor fixed-point value (640.27). Convert the Y plane start/size to integer first - matching skl_check_main_surface() - and then apply the ceiling. This is a no-op for the integer (non-joiner) case and yields the correct, in-bounds chroma offset for the fractional joiner seam: before fix after fix master 1B: x=0 w=321 x=0 w=320 -> [0, 320) slave 1C: x=321 w=320 x=320 w=320 -> [320, 640) The two halves now tile the 640-wide chroma plane exactly and the ATS fault is gone. Assisted-by: GitHub-Copilot:Claude-Opus-4.8 Fixes: 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation") Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260618181837.687302-1-vidya.srinivas@intel.com
12 daysdrm/i915/gt: use correct selftest config symbolPengpeng Hou
intel_engine_user.c checks CONFIG_DRM_I915_SELFTESTS before running the engine UABI isolation check. Kconfig defines DRM_I915_SELFTEST, without the trailing "S", and the rest of i915 uses CONFIG_DRM_I915_SELFTEST. Because CONFIG_DRM_I915_SELFTESTS is not backed by any Kconfig symbol, the IS_ENABLED() test is always false. Use the existing selftest symbol so the debug/selftest guarded path can be reached when selftests are enabled. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the Kconfig definition and the inconsistent guard in intel_engine_user.c. Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260705080225.436-1-pengpeng@iscas.ac.cn (cherry picked from commit 14a2012a490258f3f93857bc4f1b203405964be7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-09drm/i915/kunit: DP link: add fallback testsImre Deak
Add KUnit tests for DP link fallback selection across eDP, SST, and MST. Verify that the fallback logic properly selects the maximum allowed configuration, iterates through allowed configurations, and disables failed configs as expected. These tests include UHBR vs. non-UHBR conditions, MST vs. SST mode, and validate that subsequent fallback selections respect the updated allowed configuration mask. v2: - Rebase on changes using a filter object instead of a mask of configuration indices. - Rebase on changes using an iteration object. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-35-imre.deak@intel.com
2026-07-09drm/i915/kunit: DP link: add update config testsImre Deak
Add KUnit tests for link_caps updates shrinking or expanding the supported rates and lane counts. The tests also cover updates with disabled configurations, including random shrink and expand sequences, to verify that disabled state, allowed configurations, ordering, and max limits stay consistent across updates. v2: Remove test cases for the now unused merge update mode. v3: - Test config iteration in lane count, rate order as well. - Keep space after comma in code comment. (Michał) Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v2 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-4-imre.deak@intel.com