summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-07-24drm/i915/dp: Ignore the sink's DSC max FRL rate without a PCON DSC encoderAlexander Kaplan
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 Kaplan
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-24gpu: nova-core: reserve vGPU WPR2 heapZhi Wang
GSP-RM needs a larger WPR2 heap when booting in vGPU mode. The heap size is firmware-dependent, so it should come from the generated firmware bindings instead of being open-coded in nova-core. Pass the detected vGPU state into the framebuffer layout calculation. Keep baremetal boots on the existing heap sizing path, and use the 570.144 vGPU default heap binding only when vGPU is enabled. The same state match also sets the VF partition count, so disabled and invalid 0/1-VF states do not enter the vGPU heap path. Cc: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260722073913.1807677-7-zhiw@nvidia.com [ Use checked arithmetic to calculate wpr2_heap_addr. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-24gpu: nova-core: set RMSetSriovMode for vGPUZhi Wang
The GSP registry setup needs to advertise SR-IOV mode when nova-core boots GSP for an enabled vGPU configuration. Without the registry entry, GSP-RM is not told to initialize in the mode required by NVIDIA vGPU. Append RMSetSriovMode to the SetRegistry command when the vGPU state detected before GSP boot is enabled. Keep the existing registry entries unchanged for non-vGPU boots. Cc: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260722073913.1807677-6-zhiw@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-24gpu: nova-core: detect and store vGPU stateZhi Wang
GSP boot needs a stable view of vGPU state before it starts building the boot-time data structures that depend on SR-IOV and firmware policy. That state must be derived once from the PCI VF count and the FSP PRC vGPU mode knob before booting GSP. Add VgpuManager to detect and retain the vGPU state during GPU construction. Keep the manager separate from the detected state because later vGPU milestones will add vGPU resources and lifecycle state to it. Keep the vGPU capability gate local to the vGPU module with per-chip HAL modules. Treat failures to detect the optional vGPU state as disabled so they do not prevent a bare-metal probe, and log both the failure and the detected state where the manager is constructed. Cc: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260722073913.1807677-5-zhiw@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-24gpu: nova-core: read vGPU mode from FSP via PRC protocolZhi Wang
vGPU boot needs to know whether firmware reports vGPU mode as active. FSP's Management Partition exposes PRC (Product Reconfiguration Control) as an API for reading device configuration knobs without firmware updates. The vGPU mode knob is one such configuration value. Add typed PRC request and response payloads for the vGPU mode object, add the PRC NVDM type, and parse the returned knob value into VgpuMode. Signed-off-by: Zhi Wang <zhiw@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260722073913.1807677-4-zhiw@nvidia.com [ FspPrcMessage is small and short-lived; stack-allocate it instead of using KBox. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-23drm/vc4: Shut down BO cache timer before teardownLinmao Li
The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync(). Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Link: https://patch.msgid.link/20260720084426.1632508-1-lilinmao@kylinos.cn Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-23drm/mediatek: mtk_hdmi_common: take i2c adapter module referenceJohan Hovold
The i2c subsystem currently blocks during adapter deregistration whenever there are consumers holding a reference. Switch to using of_get_i2c_adapter_by_node() which also takes a reference to the adapter module so that an attempt to unload the module while in use fails gracefully instead of blocking uninterruptibly. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260716132103.1564995-1-johan@kernel.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-07-24Merge tag 'drm-xe-fixes-2026-07-23' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Skip invalidation for purgeable state updates (Arvind) - Add drm_dev guards when detaching CCS read / write buffers (Satyanarayana) - Alloc per domain unique i2c id (Raag) - Fix SVM leak on resv obj alloc failure in xe_vm_create (Shuicheng) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/amJ5-WUA_OS_RBAp@fedora
2026-07-23drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmemJosé Expósito
drm_gem_shmem_test_purge [1] and drm_gem_shmem_test_get_pages_sgt [2] intermittently fail on ppc64le and s390x CI systems with a DMA address overflow: DMA addr 0x0000000100307000+4096 overflow (mask ffffffff, bus limit 0) WARNING: kernel/dma/direct.h:114 dma_direct_map_sg+0x778/0x920 drm_gem_shmem_test_purge: ASSERTION FAILED at drivers/gpu/drm/tests/drm_gem_shmem_test.c:330 Expected sgt is not error, but is: -5 The call chain leading to the failure is: drm_gem_shmem_test_purge() / drm_gem_shmem_test_get_pages_sgt() drm_gem_shmem_get_pages_sgt() drm_gem_shmem_get_pages_sgt_locked() [drm_gem_shmem_helper.c] dma_map_sgtable() [mapping.c] __dma_map_sg_attrs() dma_direct_map_sg() [direct.c] dma_direct_map_phys() [kernel/dma/direct.h] dma_capable() Checks addr against DMA mask -> FAILS: addr > 0xFFFFFFFF The root cause is that KUnit devices are initialized with a 32-bit DMA mask (DMA_BIT_MASK(32)) in lib/kunit/device.c. On ppc64le and s390x systems with physical memory above 4GB, page allocations can land at addresses that exceed this mask. When drm_gem_shmem_get_pages_sgt() attempts to DMA-map these pages via dma_map_sgtable(), the DMA layer rejects the mapping because the physical address overflows the 32-bit mask. The failure is intermittent because pages may or may not be allocated above 4GB on any given run depend on memory pressure. Fix by setting a 64-bit DMA mask on the device before calling drm_gem_shmem_get_pages_sgt() for all tests, following the same pattern already used in drm_gem_shmem_test_obj_create_private(). [1] https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/2643976103/test_s390x/15128551935/artifacts/jobwatch/logs/recipes/21561049/tasks/220716793/results/1014626315/logs/dmesg.log [2] https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/2643976103/test_ppc64le/15128551933/artifacts/jobwatch/logs/recipes/21561041/tasks/220716705/results/1014628163/logs/dmesg.log Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem") Closes: https://datawarehouse.cki-project.org/issue/5345 Closes: https://datawarehouse.cki-project.org/issue/3184 Assisted-by: Claude:claude-4.6-opus Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: José Expósito <jose.exposito@redhat.com> Link: https://patch.msgid.link/20260703150808.3832-1-jose.exposito89@gmail.com
2026-07-23drm/etnaviv: force flush on power register opsRandolph Sapp
Add gpu_write_power_sync to verify that power register modifications have reached the endpoint device in sequence specific sections that do not validate device state. These sequence specific areas have been detected experimentally with an am57xx-evm through numerous boot and module load+unload cycles. Signed-off-by: Randolph Sapp <rs@ti.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Link: https://patch.msgid.link/20251013170122.1145387-2-rs@ti.com
2026-07-23drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()Shuicheng Lin
Commit 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a "simple" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Cc: Matthew Auld <matthew.auld@intel.com> Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721205516.4058959-2-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-23drm/xe/i2c: Allow per domain unique idRaag Jadav
PCI bus, device and function can be same for devices existing across different domains. Allow per domain unique identifier while registering platform device to prevent name conflict. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260721113438.651100-1-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit a79f6abc8b516b5bd906e2eca8121e3549ee163f) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-23gpu: nova-core: wait for RISC-V HALTED on FSP unloadEliot Courtney
Currently the code waits for "not active" but this is not the same as halted as there are more than two states. Match openrm here and wait for halted instead. Fixes: c7fea1f70944 ("gpu: nova-core: add non-sec2 unload path") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-10-8e3d8bc32bb9@nvidia.com [acourbot: s/imply/guarantee.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-23gpu: nova-core: correct RISC-V HALTED fieldEliot Courtney
This uses the incorrect value, so update it. Fixes: bb58d1aee608 ("gpu: nova-core: falcon: Add support to check if RISC-V is active") Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-9-8e3d8bc32bb9@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-23gpu: nova-core: gsp: ensure LibOS DMA allocation lives long enoughEliot Courtney
Currently, `GspSequencer` stores a raw DMA handle. Instead, store a reference to `Coherent` to statically ensure that the allocation lives long enough. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-4-8e3d8bc32bb9@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-23gpu: nova-core: gsp: ensure lifetime for FMC boot DMA allocationsEliot Courtney
Currently, `FmcBootArgs` takes DMA handles directly, rather than references to the `Coherent` for them. This is error prone, so instead store lifetime'd references to the `Coherent` allocation. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-3-8e3d8bc32bb9@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-23gpu: nova-core: fsp: catch bogus queue pointer issuesEliot Courtney
Currently, `poll_msgq` will report a message of size 4 if the queue pointers are broken. It's easy to catch this if it occurs, so have `poll_msgq` return an error in this case. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-2-8e3d8bc32bb9@nvidia.com [acourbot: explicitly mention the error, add paragraph separator.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-22drm/xe/nvls: Drop force_probe requirementGustavo Sousa
NVL-S is stable enough for us to drop force_probe requirement. Let's do that. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260722-nvl_s-drop-force_probe-v1-1-db944d940cff@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-07-22drm/mediatek: mtk_hdmi: Fix DDC adapter double put in v2Guangshuo Li
mtk_hdmi_common_probe() gets the DDC adapter with of_find_i2c_adapter_by_node() and registers a devm action to release the adapter device reference with put_device(). The HDMI v2 remove callback also calls i2c_put_adapter() on the same DDC adapter. This is not paired with of_find_i2c_adapter_by_node(): it drops the adapter device reference before the devm action drops it again, and it also puts a module reference that was never taken. Remove the extra i2c_put_adapter() call and drop the now-empty HDMI v2 remove callback. The common devm action releases the adapter device reference. Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188") Cc: stable@vger.kernel.org Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260713112957.884640-1-lgs201920130244@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-07-22drm/mediatek: Check CRTC state before freeingRuoyu Wang
mtk_crtc_reset() destroys the current CRTC state only when crtc->state is non-NULL, but it always converts crtc->state to struct mtk_crtc_state and passes the result to kfree(). When reset is called without an existing state, container_of(NULL, ...) does not produce NULL. Keep the mtk state free in the same crtc->state guard as the helper state destruction. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 2d267b81898e ("drm/mtk: Use __drm_atomic_helper_crtc_reset") Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260707150528.2270739-1-ruoyuw560@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-07-22drm/xe/vm: Use regular comment for GSC VM lockdep note in xe_vm_create()Shuicheng Lin
The block comment describing the GSC VM lockdep annotation uses the kernel-doc opening marker (/**), but it is an in-function implementation note rather than API documentation. Per Documentation/doc-guide/kernel-doc.rst, /** is reserved for kernel-doc comments describing functions, structs, and other API elements, and using it for other comments can confuse kernel-doc tooling. Switch it to a regular block comment (/*). No functional change. Cc: Matthew Brost <matthew.brost@intel.com> Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721205516.4058959-4-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-07-22drm/xe/vm: Remove redundant INIT_WORK() for rebind_work in xe_vm_create()Shuicheng Lin
xe_vm_create() initializes vm->preempt.rebind_work twice for LR-mode VMs: once in the LR-mode setup block before xe_svm_init(), and again inside the xe_validation_guard() block. The second call is a no-op on top of the first since the work is never queued between them, but re-initializing a work item is unnecessary and makes lifetime and ordering harder to reason about (e.g., any future change that queues the work earlier would be silently corrupted by the second INIT_WORK). Drop the duplicate INIT_WORK() and keep only the batch_invalidate_tlb flag handling in the later LR-mode block. The single INIT_WORK() call in the earlier LR-mode setup block remains the sole initialization. No functional change. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721205516.4058959-3-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-07-22drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create()Shuicheng Lin
Commit 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a "simple" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Cc: Matthew Auld <matthew.auld@intel.com> Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721205516.4058959-2-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-07-22drm/gma500: return errors from Oaktrail HDMI I2C readsPengpeng Hou
xfer_read() waits for the HDMI I2C transaction to reach I2C_TRANSACTION_DONE, but it ignores both timeout and signal returns from wait_for_completion_interruptible_timeout(). If the interrupt never advances the transaction state, the loop can wait forever. Return -ETIMEDOUT when the completion wait expires, propagate interrupted waits, and make the I2C master_xfer callback return the first transfer error instead of reporting a successful message count. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patch.msgid.link/20260625003240.6923-1-pengpeng@iscas.ac.cn
2026-07-22drm/xe/i2c: Allow per domain unique idRaag Jadav
PCI bus, device and function can be same for devices existing across different domains. Allow per domain unique identifier while registering platform device to prevent name conflict. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260721113438.651100-1-raag.jadav@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-07-22drm/vc4: hvs/v3d: Fix null dereference in unbindGregor Herburger
The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory. Fixes: d3f5168a0810 ("drm/vc4: Bind and initialize the V3D engine.") Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de> Link: https://patch.msgid.link/20260721-rpi-vc4-fix-v2-1-b813dcd01dc7@linutronix.de Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-22drm/panel: fix unmet dependency bug for DRM_PANEL_HIMAX_HX83121AJulian Braha
Currently, DRM_PANEL_HIMAX_HX83121A selects DRM_DISPLAY_DSC_HELPER without also ensuring DRM_DISPLAY_HELPER is enabled, causing an unmet dependency: WARNING: unmet direct dependencies detected for DRM_DISPLAY_DSC_HELPER Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && DRM_DISPLAY_HELPER [=n] Selected by [m]: - DRM_PANEL_HIMAX_HX83121A [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_PANEL [=y] && OF [=y] && DRM_MIPI_DSI [=y] && BACKLIGHT_CLASS_DEVICE [=m] - DRM_PANEL_ILITEK_ILI9882T [=m] && HAS_IOMEM [=y] && DRM [=m] && DRM_PANEL [=y] && OF [=y] && DRM_MIPI_DSI [=y] && BACKLIGHT_CLASS_DEVICE [=m] Many other DRM_PANEL_* options select DRM_DISPLAY_HELPER when selecting DRM_DISPLAY_DSC_HELPER, let's do the same here. This unmet dependency bug was found by kconfirm, a static analysis tool for Kconfig. Fixes: defab7b01e08 ("drm/panel: hx83121a: select DRM_DISPLAY_DSC_HELPER") Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260711234230.2236041-1-julianbraha@gmail.com
2026-07-22drm/panel: s6e3ha8: fix unmet dependency on DRM_DISPLAY_HELPERJulian Braha
Currently, DRM_PANEL_SAMSUNG_S6E3HA8 selects DRM_DISPLAY_DSC_HELPER without ensuring its dependency, DRM_DISPLAY_HELPER, is enabled, causing an unmet dependency. Let's select DRM_DISPLAY_HELPER as other similar options do. This unmet dependency bug was found by kconfirm, a static analysis tool for Kconfig. Fixes: fd3b2c5f40a1 ("drm/panel: s6e3ha8: select CONFIG_DRM_DISPLAY_DSC_HELPER") Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260712001514.2318597-1-julianbraha@gmail.com
2026-07-22drm/panel: ilitek-ili9882t: fix unmet dependency for DRM_PANEL_ILITEK_ILI9882TJulian Braha
Currently, DRM_PANEL_ILITEK_ILI9882T selects DRM_DISPLAY_DSC_HELPER without ensuring DRM_DISPLAY_HELPER is also enabled, causing an unmet dependency and build failure. Other similar options select DRM_DISPLAY_HELPER, let's do the same here. This unmet dependency bug was found by kconfirm, a static analysis tool for Kconfig. Fixes: 68e28facbc8a ("drm/panel: ilitek-ili9882t: Select DRM_DISPLAY_DSC_HELPER") Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260712002632.2323484-1-julianbraha@gmail.com
2026-07-22drm/panel: ilitek-ili9881c: do not fail probe if iovcc is absentDavid Oberhollenzer
Commit 4c95b2b7d49e ("drm/panel: ilitek-ili9881c: support Waveshare 7.0" DSI panel") adds an additional iovcc regulator that other Ilitek ili9881c based panels apparently do not have or need. The commit goes out of its way to make usage of this new regulator optional, dutifully testing if the field in `struct ili9881c` is NULL before touching the new regulator. However, in the probe function, it unconditionally fails if devm_regulator_get_optional returns an error. devm_regulator_get_optional() returns -ENODEV if the regulator is missing, causing probe to fail for other panels that do not have an iovcc-supply set in the device tree. Fixes: 4c95b2b7d49e ("drm/panel: ilitek-ili9881c: support Waveshare 7.0" DSI panel") Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260713082213.75759-1-david.oberhollenzer@sigma-star.at
2026-07-22drm/v3d: Idle AXI transactions before disabling the clock on suspendMaíra Canal
Currently, v3d_power_suspend() removes the GPU clock without first quiescing the GPU's memory interface (AXI). If the clock is cut while the core still has outstanding AXI transactions in flight, the hardware is frozen mid-transaction. That corrupted state survives the power cycle, and the first job submitted after the next resume will cause a GPU hang accompanied by an L2T "pte invalid" MMU fault. The hardware already provides a safe-powerdown sequence for this: request the GMP to stop and wait for outstanding reads/writes to drain (v3d_idle_axi()), plus the GCA safe shutdown on pre-4.1 HW (v3d_idle_gca()). The driver implements both, but the runtime PM support added later never invoked them when powering the GPU down. Perform the safe-powerdown sequence in v3d_power_suspend() before disabling the clock, while the core is still powered. Link: https://github.com/raspberrypi/linux/issues/7443 Link: https://github.com/raspberrypi/linux/issues/7488 Fixes: 458f2a712ab4 ("drm/v3d: Introduce Runtime Power Management") Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260718-v3d-pm-axi-transactions-v1-2-4ecd7729ed70@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-22drm/v3d: Reach the GMP through the hub registers on V3D 7.xMaíra Canal
v3d_idle_axi() drains the GPU's memory interface for a safe powerdown by using the V3D_GMP_CFG register. It reached both registers with the macros V3D_CORE_READ and V3D_CORE_WRITE. On V3D 7.x the GMP is no longer a per-core block; it lives in the hub register region. Reaching it through the per-core register block addresses the wrong region. Select the hub accessors (V3D_{READ,WRITE}) for the GMP on V3D 7.x and keep the per-core path for earlier generations. Cc: stable@vger.kernel.org Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x") Link: https://patch.msgid.link/20260718-v3d-pm-axi-transactions-v1-1-4ecd7729ed70@igalia.com Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-22drm: fix missing header include for drm_panel_put()Neil Armstrong
Some DRM drivers lacked the drm_panel.h include to use drm_panel_put() after the commit b71a623598d3 ("drm/panel: of_drm_find_panel() return a counted reference"). Fixes: b71a623598d3 ("drm/panel: of_drm_find_panel() return a counted reference") Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260722-panel-fix-kms-panel-put-v1-1-ebde56446ee5@linaro.org
2026-07-22drm/panel: simple: Add Kyocera tcg070wvlq panelHeiko Schocher
Commit 922fb2db0287 ("dt-bindings: display: simple: Add Kyocera tcg070wvlq panel") added the compatible string for the Kyocera tcg070wvlq panel to the devicetree bindings documentation (panel-simple.yaml), but the corresponding entry was not added to the panel-simple driver. Add the missing compatible entry to the driver. Signed-off-by: Heiko Schocher <hs@nabladev.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260721041935.757240-1-hs@nabladev.com
2026-07-22drm/panel: osd101t2587: migrate to newer mipi_dsi* functionsRobert-Andrei Mercea
Migrate osd101t2587-53ts panel driver from deprecated mipi_dsi* functions to their *_multi variants for improved error handling, as specified in the GPU subsystem TODO list. Link: https://docs.kernel.org/gpu/todo.html#transition-away-from-using-deprecated-mipi-dsi-functions Signed-off-by: Robert-Andrei Mercea <robertandreimercea@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260720115126.666363-1-robertandreimercea@gmail.com
2026-07-22drm/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
2026-07-22drm/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
2026-07-22drm/pagemap: Guard HPAGE_PMD_ORDER use with CONFIG_ARCH_ENABLE_THP_MIGRATIONMatthew Brost
HPAGE_PMD_SHIFT expands to BUILD_BUG() when CONFIG_PGTABLE_HAS_HUGE_LEAVES is not set, causing a compile error when both CONFIG_TRANSPARENT_HUGEPAGE and CONFIG_HUGETLB_PAGE are disabled: drivers/gpu/drm/drm_pagemap.c:480:12: error: call to '__compiletime_assert_458' declared with 'error' attribute: BUILD_BUG failed 480 | order = HPAGE_PMD_ORDER; | ^ include/linux/huge_mm.h:117:26: note: expanded from macro 'HPAGE_PMD_ORDER' 117 | #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT) | ^ include/linux/huge_mm.h:113:28: note: expanded from macro 'HPAGE_PMD_SHIFT' 113 | #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; }) Define DRM_PAGEMAP_PMD_ORDER, which maps to HPAGE_PMD_ORDER when CONFIG_ARCH_ENABLE_THP_MIGRATION is enabled and to -1 otherwise. This is safe because all code paths that use DRM_PAGEMAP_PMD_ORDER are reachable only when CONFIG_ARCH_ENABLE_THP_MIGRATION is enabled. Fixes: 139ab31aea8a ("drm/pagemap: Correct cpages calculation for migrate_vma_setup") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202607201914.LpAGsbXs-lkp@intel.com/ Cc: Jan Stancek <jstancek@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Tested-by: Jan Stancek <jstancek@redhat.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260721223244.1102276-1-matthew.brost@intel.com
2026-07-22drm/pagemap: Clear driver-provided PFNs from migration PFN arrayMatthew Brost
DRM pagemap overloads the migration PFN array to store driver-provided PFNs before calling migrate_vma_*() to finalize the migration. If an error occurs during the incremental copy phase, the migration PFN entries are reverted to their original state. After reverting the device-folio mutations, clear any remaining driver-provided PFNs to avoid confusing the migrate_vma_*() helpers. Also clear any driver-provided PFNs if populate_devmem_pfn() fails, as a precaution against stale entries being interpreted as migration PFNs. Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: 3902846af36b ("drm/pagemap Fix error paths in drm_pagemap_migrate_to_devmem") Fixes: ec265e1f1cfc ("drm/pagemap: Support source migration over interconnect") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260721204353.1082632-1-matthew.brost@intel.com
2026-07-22drm/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
2026-07-22drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffersSatyanarayana K V P
CCS read/write buffers are freed during BO destruction. In some cases, BOs may be destroyed after the device is unbound but while the DRM structure remains valid, leading to NULL pointer dereferences when accessing device resources. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 9376 Comm: xe_pat Not tainted 7.2.0-rc2+ #1 PREEMPT(lazy) RIP: 0010:xe_sriov_vf_ccs_rw_update_bb_addr+0x4d/0xa0 [xe] RSP: 0018:ffffcf304110b9c8 EFLAGS: 00010246 RAX: ffff8a85c38a0a00 RBX: 00000000810ef000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8a85c39c1888 RBP: ffffcf304110b9e8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a85c39c1888 R13: 0000000000000000 R14: ffff8a85c39b4f28 R15: ffff8a85c3885000 FS: 0000000000000000(0000) GS:ffff8a878b809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010314a002 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <TASK> xe_migrate_ccs_rw_copy_clear+0x98/0x120 [xe] xe_sriov_vf_ccs_detach_bo+0x2c/0x60 [xe] xe_ttm_bo_delete_mem_notify+0xc8/0xe0 [xe] ttm_bo_cleanup_memtype_use+0x26/0x80 [ttm] ttm_bo_release+0x29e/0x2d0 [ttm] ttm_bo_fini+0x39/0x70 [ttm] xe_gem_object_free+0x1f/0x30 [xe] drm_gem_object_free+0x1d/0x40 ttm_bo_vm_close+0x5f/0x90 [ttm] remove_vma+0x2c/0x70 tear_down_vmas+0x63/0xf0 exit_mmap+0x20d/0x3f0 __mmput+0x45/0x170 mmput+0x31/0x40 do_exit+0x2ba/0xac0 do_group_exit+0x2d/0xb0 __x64_sys_exit_group+0x18/0x20 x64_sys_call+0x14a0/0x2390 do_syscall_64+0xdd/0x640 ? count_memcg_events+0xea/0x240 ? handle_mm_fault+0x1ec/0x2f0 Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721052215.2267228-2-satyanarayana.k.v.p@intel.com (cherry picked from commit 1ae415a6eefe5004954a1d352b1718faca8844ef) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-22drm/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
2026-07-21drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffersSatyanarayana K V P
CCS read/write buffers are freed during BO destruction. In some cases, BOs may be destroyed after the device is unbound but while the DRM structure remains valid, leading to NULL pointer dereferences when accessing device resources. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 9376 Comm: xe_pat Not tainted 7.2.0-rc2+ #1 PREEMPT(lazy) RIP: 0010:xe_sriov_vf_ccs_rw_update_bb_addr+0x4d/0xa0 [xe] RSP: 0018:ffffcf304110b9c8 EFLAGS: 00010246 RAX: ffff8a85c38a0a00 RBX: 00000000810ef000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8a85c39c1888 RBP: ffffcf304110b9e8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a85c39c1888 R13: 0000000000000000 R14: ffff8a85c39b4f28 R15: ffff8a85c3885000 FS: 0000000000000000(0000) GS:ffff8a878b809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010314a002 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <TASK> xe_migrate_ccs_rw_copy_clear+0x98/0x120 [xe] xe_sriov_vf_ccs_detach_bo+0x2c/0x60 [xe] xe_ttm_bo_delete_mem_notify+0xc8/0xe0 [xe] ttm_bo_cleanup_memtype_use+0x26/0x80 [ttm] ttm_bo_release+0x29e/0x2d0 [ttm] ttm_bo_fini+0x39/0x70 [ttm] xe_gem_object_free+0x1f/0x30 [xe] drm_gem_object_free+0x1d/0x40 ttm_bo_vm_close+0x5f/0x90 [ttm] remove_vma+0x2c/0x70 tear_down_vmas+0x63/0xf0 exit_mmap+0x20d/0x3f0 __mmput+0x45/0x170 mmput+0x31/0x40 do_exit+0x2ba/0xac0 do_group_exit+0x2d/0xb0 __x64_sys_exit_group+0x18/0x20 x64_sys_call+0x14a0/0x2390 do_syscall_64+0xdd/0x640 ? count_memcg_events+0xea/0x240 ? handle_mm_fault+0x1ec/0x2f0 Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721052215.2267228-2-satyanarayana.k.v.p@intel.com
2026-07-21gpu: nova-core: fsp: limit FSP receive message allocation sizeEliot Courtney
Currently, the FSP receive message code will try to allocate whatever was sent without checking it at all. But the actual size allowed is limited to 1024 anyway, so reject any messages over that size as bogus. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-1-8e3d8bc32bb9@nvidia.com [acourbot: use `SZ_1K` constant for size.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-21drm/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>
2026-07-21drm: Send per-connector hotplug eventsNicolas Frattaroli
Try to send per-connector hotplug events as often as possible, rather than connector-less global hotplug events. This does result in more hotplug events if multiple connectors changed at the same time, but give userspace more actionable information. Since the hotplug event needs to be sent outside of the mode_config mutex to avoid a deadlock, the drm_client_dev_hotplug() call is split off from the drm_sysfs_(connector_)?hotplug_event calls. Co-developed-by: Marius Vlad <marius.vlad@collabora.com> Signed-off-by: Marius Vlad <marius.vlad@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260526-hot-plug-passup-v10-2-f62351a9ea3e@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-07-21drm/vmwgfx: Validate vmw_surface_metadata::array_sizeIan Forbes
This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available. Fixes: 504901dbb0b5 ("drm/vmwgfx: Refactor surface_define to use vmw_surface_metadata") Reported-by: Zero Day Initiative <zdi-disclosures@trendmicro.com> Cc: stable@vger.kernel.org Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patch.msgid.link/20260623193314.506257-1-ian.forbes@broadcom.com
2026-07-21drm/vc4: Prevent shader BO mappings from becoming writableLinmao Li
vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects. Fixes: 463873d57014 ("drm/vc4: Add an API for creating GPU shaders in GEM BOs.") Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/dri-devel/20260720085554.B0AF01F000E9@smtp.kernel.org/ Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Link: https://patch.msgid.link/20260721011558.1672477-1-lilinmao@kylinos.cn Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-21drm/tests/gpu_buddy: add a new test case for buffer clearance during resumeArunpravin Paneer Selvam
Add a new unit test case for buffer clearance issue during resume. Using a non-power-of-two mm size, allocate alternating blocks of 4KiB in an even sequence and free them as cleared. All alternate blocks should be marked as dirty and the split blocks should be merged back to their original size when the blocks clear reset function is called. Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260721114236.507578-1-Arunpravin.PaneerSelvam@amd.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-07 15:05:23 +0000