aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2026-01-10drm/amd/pm: Replace without wait with async callsLijo Lazar7-59/+64
Use the new async locked message function instead of without_waiting messaging function. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-10drm/amd/pm: Add async message call supportLijo Lazar3-5/+37
Add asynchronous messaging (message which doesn't wait for response) using message control block. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-10drm/amd/pm: Use message control in messagingLijo Lazar1-202/+15
Use message control block operations in common message functions. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-10drm/amd/pm: Add message control for SMUv15Lijo Lazar1-0/+17
Initialize smu message control in SMUv15 SOCs. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-10drm/amd/pm: Add message control for SMUv14Lijo Lazar2-0/+34
Initialize smu message control in SMUv14 SOCs. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-10drm/amd/pm: Add message control for SMUv13Lijo Lazar9-2/+62
Initialize smu message control in SMUv13 SOCs. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-10drm/amd/pm: Add message control for SMUv12Lijo Lazar3-0/+21
Initialize smu message control in SMUv12 SOCs. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-10drm/amd/pm: Add message control for SMUv11Lijo Lazar7-0/+24
Initialize smu message control in SMUv11 SOCs. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-10drm/amd/pm: Add smu message control blockLijo Lazar3-0/+433
Add message control block to abstract PMFW message protocol. Message control block primarily carries message config which is set of register addresses and message ops which abstracts the protocol of sending messages. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-10drm/amdgpu: Use correct address to setup gart page table for vram accessXiaogang Chen1-2/+2
Use dst input parameter to setup gart page table entries instead of using fixed location. Fixes: 237d623ae659 ("drm/amdgpu/gart: Add helper to bind VRAM pages (v2)") Signed-off-by: Xiaogang Chen <xiaogang.chen@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-10drm/amdgpu: Skip loading SDMA_RS64 in VFYuBiao Wang1-0/+1
VFs use the PF SDMA ucode and are unable to load SDMA_RS64. Signed-off-by: YuBiao Wang <YuBiao.Wang@amd.com> Signed-off-by: Victor Skvortsov <Victor.Skvortsov@amd.com> Reviewed-by: Gavin Wan <gavin.wan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-09drm/xe: Allow compressible surfaces to be 1-way coherentXin Wang7-14/+109
Previously, compressible surfaces were required to be non-coherent (allocated as WC) because compression and coherency were mutually exclusive. Starting with Xe3, hardware supports combining compression with 1-way coherency, allowing compressible surfaces to be allocated as WB memory. This provides applications with more efficient memory allocation by avoiding WC allocation overhead that can cause system stuttering and memory management challenges. The implementation adds support for compressed+coherent PAT entry for the xe3_lpg devices and updates the driver logic to handle the new compression capabilities. v2: (Matthew Auld) - Improved error handling with XE_IOCTL_DBG() - Enhanced documentation and comments - Fixed xe_bo_needs_ccs_pages() outdated compression assumptions v3: - Improve WB compression support detection by checking PAT table instead of version check v4: - Add XE_CACHE_WB_COMPRESSION, which simplifies the logic. v5: - Use U16_MAX for the invalid PAT index. (Matthew Auld) Bspec: 71582, 59361, 59399 Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Xin Wang <x.wang@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260109093007.546784-1-x.wang@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-01-09drm/bridge: dw-hdmi-qp: Add support for missing HPDChris Morgan1-4/+30
Add support for the dw-hdmi-qp driver to handle devices with missing HPD pins. Since in this situation we are now polling for the EDID data via i2c change the error message to a rate limited debug message when we are unable to complete an i2c read, as a disconnected device would otherwise fill dmesg with i2c read errors. Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251119225526.70588-3-macroalpha82@gmail.com
2026-01-09drm/rockchip: replace use of system_wq with system_percpu_wqMarco Crivellari1-2/+2
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. system_wq should be the per-cpu workqueue, yet in this name nothing makes that clear, so replace system_wq with system_percpu_wq. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251031104846.119503-3-marco.crivellari@suse.com
2026-01-09drm/rockchip: replace use of system_unbound_wq with system_dfl_wqMarco Crivellari1-1/+1
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. system_unbound_wq should be the default workqueue so as not to enforce locality constraints for random work whenever it's not required. Adding system_dfl_wq to encourage its use when unbound work should be used. The old system_unbound_wq will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251031104846.119503-2-marco.crivellari@suse.com
2026-01-09drm/panfrost: Fix a page leak in panfrost_mmu_map_fault_addr() when THP is onBoris Brezillon1-15/+25
drm_gem_put_pages(), which we rely on for returning BO pages to shmem, assume per-folio refcounting and not per-page. If we call shmem_read_mapping_page() per-page, we break this assumption and leak pages every time we get a huge page allocated. v2: - Rework the logic for() loop to better match the folio-granular allocation scheme Cc: Loïc Molinari <loic.molinari@collabora.com> Fixes: c12e9fcb5a5a ("drm/panfrost: Introduce huge tmpfs mountpoint option") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260108123325.1088195-1-boris.brezillon@collabora.com Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
2026-01-09drm/gpuvm: fix name in kernel doc of drm_gpuvm_bo_obtain_locked()Alice Ryhl1-2/+2
When renaming this function, the name in the docs was not updated. This causes a KernelDoc warning. Thus, fix it. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601091113.0b0WuRML-lkp@intel.com/ Fixes: 9bf4ca1e699c ("drm/gpuvm: drm_gpuvm_bo_obtain() requires lock and staged mode") Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260109082019.3999814-1-aliceryhl@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-09drm/i915/guc: make 'guc_hw_reg_state' static as it isn't exportedBen Dooks1-1/+1
The guc_hw_reg_state array is not exported, so make it static. Fixes the following sparse warning: drivers/gpu/drm/i915/i915_gpu_error.c:692:3: warning: symbol 'guc_hw_reg_state' was not declared. Should it be static? Fixes: ba391a102ec11 ("drm/i915/guc: Include the GuC registers in the error state") Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260108201202.59250-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-09drm/xe: improve header checkJani Nikula1-1/+2
Improve header check: Remove unused -DHDRTEST. Include the header twice to check for include guards. Run kernel-doc on the header. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260107155401.2379127-5-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-09drm/xe/vm: fix xe_vm_validation_exec() kernel-docJani Nikula1-1/+1
Fix kernel-doc warnings on xe_vm_validation_exec(): Warning: ../drivers/gpu/drm/xe/xe_vm.h:392 expecting prototype for xe_vm_set_validation_exec(). Prototype was for xe_vm_validation_exec() instead Fixes: 0131514f9789 ("drm/xe: Pass down drm_exec context to validation") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260107155401.2379127-4-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-09drm/xe/xe_late_bind_fw: fix enum xe_late_bind_fw_id kernel-docJani Nikula1-1/+3
Fix kernel-doc warnings on enum xe_late_bind_fw_id: Warning: ../drivers/gpu/drm/xe/xe_late_bind_fw_types.h:19 cannot understand function prototype: 'enum xe_late_bind_fw_id' Fixes: 45832bf9c10f ("drm/xe/xe_late_bind_fw: Initialize late binding firmware") Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://patch.msgid.link/20260107155401.2379127-3-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-09drm/xe/vf: fix struct xe_gt_sriov_vf_migration kernel-docJani Nikula1-2/+2
Fix kernel-doc warnings on struct xe_gt_sriov_vf_migration: Warning: ../drivers/gpu/drm/xe/xe_gt_sriov_vf_types.h:47 cannot understand function prototype: 'struct xe_gt_sriov_vf_migration' Fixes: e1d2e2d878bf ("drm/xe/vf: Add xe_gt_recovery_pending helper") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260107155401.2379127-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-09drm/xe/guc: fix struct guc_lfd_file_header kernel-docJani Nikula1-3/+2
Fix kernel-doc warnings on struct guc_lfd_file_header: Warning: ../drivers/gpu/drm/xe/abi/guc_lfd_abi.h:168 expecting prototype for struct guc_logfile_header. Prototype was for struct guc_lfd_file_header instead Fixes: 7eeb0e5408bd ("drm/xe/guc: Add LFD related abi definitions") Cc: Zhanjun Dong <zhanjun.dong@intel.com> Cc: Julia Filipchuk <julia.filipchuk@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260107155401.2379127-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-09drm/i915/cdclk: Incorporate Xe3_LPD changes for CD2X dividerGustavo Sousa1-6/+23
On Xe3_LPD, there is no instruction to program the CD2X divider anymore and the hardware is expected to always use the default value of 0b00, meaning "divide by 1". With that, the CDCLK_CTL register was changed so that: (1) The field "CD2X Divider Select" became a debug-only field. Because we are programming CDCLK_CTL with a direct write instead of read-modify-write operation, we still need to program "CD2X Divider Select" in order to keep the field from deviating from its default value. Let's, however, throw a warning if we encounter a CDCLK value that would result in an unexpected value for that field. (2) The field "CD2X Pipe Select" has been removed. In fact, some debugging in a PTL machine showed that such field comes back as zero after writing a non-zero value to it. As such, do not program it starting with Xe3_LPD. v2: - Add missing "val |= " when calling bxt_cdclk_cd2x_pipe(). (Dnyaneshwar) Bspec: 68864, 69090 Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20260106-xe3_lpd-no-cd2x-divider-v2-1-06e5cbc9dabb@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-01-09drm/gem: Fix a GEM leak in drm_gem_get_unmapped_area()Boris Brezillon1-4/+6
drm_gem_object_lookup_at_offset() can return a valid object with filp or filp->f_op->get_unmapped_area set to NULL. Make sure we still release the ref we acquired on such objects. Cc: Loïc Molinari <loic.molinari@collabora.com> Fixes: 99bda20d6d4c ("drm/gem: Introduce drm_gem_get_unmapped_area() fop") Reviewed-by: Loïc Molinari <loic.molinari@collabora.com> Link: https://patch.msgid.link/20260106164935.409765-1-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2026-01-09drm/rockchip: Drop ROCKCHIP_IOMMU depend for DRM_ROCKCHIPChaoyi Chen1-1/+2
On the RK3506 platform, there is no iommu hardware. And even on platform that have iommu hardware, it should be possible to use VOP without enabling iommu. In this case, a contiguous memory space like CMA should be used. So this patch removes the dependency on ROCKCHIP_IOMMU with an 'optional-dependency'. Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> [added reference to optional-dependies description] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251106020632.92-9-kernel@airkyi.com
2026-01-09drm/panic: Fix expected string for QR_CODE in drm_panic_type_mapNathan Chancellor1-2/+2
The help text of CONFIG_DRM_PANIC_SCREEN_QR_CODE documents the expected value to CONFIG_DRM_PANIC_SCREEN as "qr_code" but drm_panic_type_map checks for "qr". Adjust drm_panic_type_map and the module description to match so that existing configurations do not stop working. Fixes: e85e9ccf3f84 ("drm/panic: Report invalid or unsupported panic modes") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260105-drm_panic-handle-invalid-drm_panic_screen-v1-2-55228bd4b0f8@kernel.org
2026-01-09drm/panic: Ensure drm_panic_type is initialized to a valid valueNathan Chancellor1-2/+5
If a user has set an invalid CONFIG_DRM_PANIC_SCREEN value (such as "qr_code" without CONFIG_DRM_PANIC_SCREEN_QR_CODE=y due to missing or incorrect Rust dependencies), there is a panic when accessing /sys/module/drm/parameters/panic_screen: [ 12.218375] BUG: unable to handle page fault for address: 0000000796dd8818 [ 12.219737] #PF: supervisor read access in kernel mode ... [ 12.227167] RIP: 0010:drm_panic_type_get+0x1b/0x30 If drm_panic_type_set() does not find a valid drm_panic_type enumeration in drm_panic_type_map based on the provided value, it does not change drm_panic_type from the default -1 value, which is not a valid index for accessing drm_panic_type_map in drm_panic_type_get(), resulting in the crash. Validate the value of CONFIG_DRM_PANIC_SCREEN at boot time via the return value of drm_panic_type_set() in drm_panic_init() and explicitly fall back to the default of "user" with a message to the user so that they can adjust their configuration or fix missing dependencies. [ 0.800697] Unsupported value for CONFIG_DRM_PANIC_SCREEN ('qr_code'), falling back to 'user'... Fixes: e85e9ccf3f84 ("drm/panic: Report invalid or unsupported panic modes") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260105-drm_panic-handle-invalid-drm_panic_screen-v1-1-55228bd4b0f8@kernel.org
2026-01-09Merge tag 'drm-misc-next-2026-01-08' of ↵Dave Airlie53-645/+1492
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.20: UAPI Changes: Cross-subsystem Changes: Core Changes: - draw: Add API to check if a format conversion can be done - panic: Rename draw_panic_static_* to draw_panic_screen_*, Add kunit tests - shmem: Improve tests Driver Changes: - ast: Big endian fixes - etnaviv: Add PPU flop reset support - panfrost: Add GPU_PM_RT support for RZ/G3E SoC - panthor: multiple fixes around VM termination, huge page support - pl111: Fix build regression - v3d: Fix DMA segment size - bridge: - Add connector argument to .hpd_notify - Plenty of patches to convert existing drivers to refcounting - Convert Rockchip's inno hdmi support to a proper bridge - lontium-lt9611uxc: Switch to HDMI audio helpers - panel: - New panel: BOE NV140WUM-T08 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260108-literate-nyala-of-courtesy-de501a@houat
2026-01-08drm/xe: Add page reclamation related statsBrian Nguyen6-0/+20
Add page reclaim list (PRL) related stats to GT stats to assist in debugging and tuning of page reclaim related actions. Include counters of page sizes added to PRL and if PRL action is issued. v2: - Add PRL_ABORTED_COUNT stats and corresponding changes. (Matthew B) Signed-off-by: Brian Nguyen <brian3.nguyen@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260107010447.4125005-10-brian3.nguyen@intel.com
2026-01-08drm/xe: Fix page reclaim entry handling for large pagesBrian Nguyen1-17/+47
For 64KB pages, XE_PTE_PS64 is defined for all consecutive 4KB pages and are all considered leaf nodes, so existing check was falsely adding multiple 64KB pages to PRL. For larger entries such as 2MB PDE, the check for pte->base.children is insufficient since this array is always defined for page directory, level 1 and above, so perform a check on the entry itself pointing to the correct page. For unmaps, if the range is properly covered by the page full directory, page walker may finish without walking to the leaf nodes. For example, a 1G range can be fully covered by 512 2MB pages if alignment allows. In this case, the page walker will walk until it reaches this corresponding directory which can correlate to the 1GB range. Page walker will simply complete its walk and the individual 2MB PDE leaves won't get accessed. In this case, PRL invalidation is also required, so add a check to see if pt entry cover the entire range since the walker will complete the walk. There are possible race conditions that will cause driver to read a pte that hasn't been written to yet. The 2 scenarios are: - Another issued TLB invalidation such as from userptr or MMU notifier. - Dependencies on original bind that has yet to be executed with an unbind on that job. The expectation is these race conditions are likely rare cases so simply perform a fallback to full PPC flush invalidation instead. v2: - Reword commit and updated zero-pte handling. (Matthew B) v3: - Rework if statement for abort case with additional comments. (Matthew B) Fixes: b912138df299 ("drm/xe: Create page reclaim list on unbind") Signed-off-by: Brian Nguyen <brian3.nguyen@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260107010447.4125005-9-brian3.nguyen@intel.com
2026-01-08drm/xe: Add explicit abort page reclaim listBrian Nguyen2-12/+28
PRLs could be invalidated to indicate its getting dropped from current scope but are still valid. So standardize calls and add abort to clearly define when an invalidation is a real abort and PRL should fallback. v3: - Update abort function to macro. (Matthew B) Signed-off-by: Brian Nguyen <brian3.nguyen@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260107010447.4125005-8-brian3.nguyen@intel.com
2026-01-08drm/xe: Remove debug comment in page reclaimBrian Nguyen1-1/+0
Drop debug comment erronenously added in patch commit. Signed-off-by: Brian Nguyen <brian3.nguyen@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260107010447.4125005-7-brian3.nguyen@intel.com
2026-01-08drm/xe: fix WQ_MEM_RECLAIM passed as max_active to alloc_workqueue()Marco Crivellari1-1/+1
Workqueue xe-ggtt-wq has been allocated using WQ_MEM_RECLAIM, but the flag has been passed as 3rd parameter (max_active) instead of 2nd (flags) creating the workqueue as per-cpu with max_active = 8 (the WQ_MEM_RECLAIM value). So change this by set WQ_MEM_RECLAIM as the 2nd parameter with a default max_active. Fixes: 60df57e496e4 ("drm/xe: Mark GGTT work queue with WQ_MEM_RECLAIM") Cc: stable@vger.kernel.org Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260108180148.423062-1-marco.crivellari@suse.com
2026-01-08drm/xe: Add missing newlines to drm_warn messagesOsama Abdelkader1-7/+7
The drm_warn() calls in the default cases of various switch statements in xe_vm.c were missing trailing newlines, which can cause log messages to be concatenated with subsequent output. Add '\n' to all affected messages. Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Link: https://patch.msgid.link/20251224212116.59021-1-osama.abdelkader@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-08drm/xe/pf: Allow upon-any-hang wedged mode only in debug configLukasz Laguna1-1/+2
The GuC reset policy is global, so disabling it on PF can affect all running VFs. To avoid unintended side effects, restrict setting upon-any-hang (2) wedged mode on the PF to debug builds only. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260107174741.29163-5-lukasz.laguna@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-08drm/xe/vf: Disallow setting wedged mode to upon-any-hangLukasz Laguna1-0/+5
In upon-any-hang (2) wedged mode, engine resets need to be disabled, which requires changing the GuC reset policy. VFs are not permitted to do that. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260107174741.29163-4-lukasz.laguna@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-08drm/xe: Update wedged.mode only after successful reset policy changeLukasz Laguna4-20/+71
Previously, the driver's internal wedged.mode state was updated without verifying whether the corresponding engine reset policy update in GuC succeeded. This could leave the driver reporting a wedged.mode state that doesn't match the actual reset behavior programmed in GuC. With this change, the reset policy is updated first, and the driver's wedged.mode state is modified only if the policy update succeeds on all available GTs. This patch also introduces two functional improvements: - The policy is sent to GuC only when a change is required. An update is needed only when entering or leaving XE_WEDGED_MODE_UPON_ANY_HANG, because only in that case the reset policy changes. For example, switching between XE_WEDGED_MODE_UPON_CRITICAL_ERROR and XE_WEDGED_MODE_NEVER doesn't affect the reset policy, so there is no need to send the same value to GuC. - An inconsistent_reset flag is added to track cases where reset policy update succeeds only on a subset of GTs. If such inconsistency is detected, future wedged mode configuration will force a retry of the reset policy update to restore a consistent state across all GTs. Fixes: 6b8ef44cc0a9 ("drm/xe: Introduce the wedged_mode debugfs") Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Link: https://patch.msgid.link/20260107174741.29163-3-lukasz.laguna@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-08drm/xe: Validate wedged_mode parameter and define enum for modesLukasz Laguna9-20/+94
Check correctness of the wedged_mode parameter input to ensure only supported values are accepted. Additionally, replace magic numbers with a clearly defined enum. Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260107174741.29163-2-lukasz.laguna@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-08drm/xe/pm: Handle GT resume failureRaag Jadav1-4/+22
We've been historically ignoring GT resume failure. Since the function can return error, handle it properly. v2: Bring up display before bailing (Matt Roper, Rodrigo) Signed-off-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251220073657.166810-1-raag.jadav@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-08Revert duplicate "drm/amdgpu: disable peer-to-peer access for DCC-enabled ↵Peter Colberg1-12/+0
GC12 VRAM surfaces" This reverts commit 22a36e660d014925114feb09a2680bb3c2d1e279 once, which was merged twice due to an incorrect backmerge resolution. Fixes: ce0478b02ed2 ("Merge tag 'v6.18-rc6' into drm-next") Signed-off-by: Peter Colberg <pcolberg@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-01-08drm/xe/nvls: Define GuC firmware for NVL-SMatt Roper1-0/+1
Although NVL-S has a similar Xe3 to PTL/WCL, it requires a unique GuC firmware. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-12-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Julia Filipchuk <julia.filipchuk@intel.com> Link: https://patch.msgid.link/20260108181956.1254908-9-julia.filipchuk@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-08drm/rockchip: vop: Add support for rk3506Chaoyi Chen2-0/+71
The VOP on rk3506: - Support 2 lane MIPI DSI interface, 1.5Gbps/lane. - Support RGB interface. - Max output resolution is 1280x1280@60fps. - WIN1 layer support RGB888/ARGB8888/RGB565. - Support Gamma LUT. Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251106020632.92-10-kernel@airkyi.com
2026-01-08drm/rockchip: dsi: Add support for rk3506Chaoyi Chen1-0/+20
The dsi controller found on RK3506 supports up to 2 lanes. Signed-off-by: Hongming Zou <hongming.zou@rock-chips.com> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251106020632.92-8-kernel@airkyi.com
2026-01-08drm/rockchip: vop2: Simplify format_mod_supportedDaniel Stone1-34/+22
Make it a little less convoluted, and just directly check if the combination of plane + format + modifier is supported. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-8-83463c075a8d@collabora.com
2026-01-08drm/rockchip: vop2: Use drm_is_afbc helper functionDaniel Stone1-1/+1
We don't need to do a long open-coded walk here; we can simply check the modifier value. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-7-83463c075a8d@collabora.com
2026-01-08drm/rockchip: vop2: Enforce AFBC transform stride align in plane_checkDaniel Stone1-3/+9
Make sure we can't break the hardware by requesting an unsupported configuration. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-6-83463c075a8d@collabora.com
2026-01-08drm/rockchip: vop2: Enforce AFBC source alignment in plane_checkDaniel Stone1-5/+10
Planes can only source AFBC framebuffers at multiples of 4px wide on RK3566/RK3568. Instead of clipping on all SoCs when the user asks for an unaligned source rectangle, reject the configuration in the plane's atomic check on RK3566/RK3568 only. Signed-off-by: Daniel Stone <daniels@collabora.com> [Make RK3566/RK3568 specific, reword message, s/byte/pixel/] Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-5-83463c075a8d@collabora.com
2026-01-08drm/rockchip: vop2: Enforce scaling workaround in plane_checkDaniel Stone1-10/+11
It seems only cluster windows are capable of applying downscaling when the source region has an odd width. Instead of applying a workaround inside atomic_update, fail the plane check if this is requested. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-4-83463c075a8d@collabora.com
2026-01-08drm/rockchip: vop2: Fix Esmart test conditionDaniel Stone1-6/+4
If we want to find out if a window is Esmart or not, test for not being a cluster window, rather than AFBDC presence. No functional effect as only cluster windows support AFBC decode. Signed-off-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251215-vop2-atomic-fixups-v5-3-83463c075a8d@collabora.com
generated by cgit