summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-03-11drm/amd/display: Fix compile warnings in dml2_0Gaghik Khachatrian
Fix static analysis warnings by ensuring swath size temporaries are initialized before use. No functional change intended. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Check for S0i3 to be done before DCCG init on DCN21Ivan Lipski
[WHY] On DCN21, dccg2_init() is called in dcn10_init_hw() before bios_golden_init(). During S0i3 resume, BIOS sets MICROSECOND_TIME_BASE_DIV to 0x00120464 as a marker. dccg2_init() overwrites this to 0x00120264, causing dcn21_s0i3_golden_init_wa() to misdetect the state and skip golden init. Eventually during the resume sequence, a flip timeout occurs. [HOW] Skip DCCG on dccg2_is_s0i3_golden_init_wa_done() on DCN21. Fixes: 4c595e75110e ("drm/amd/display: Migrate DCCG registers access from hwseq to dccg component.") Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11gpu: nova-core: gsp: fix UB in DmaGspMem pointer accessorsDanilo Krummrich
The DmaGspMem pointer accessor methods (gsp_write_ptr, gsp_read_ptr, cpu_read_ptr, cpu_write_ptr, advance_cpu_read_ptr, advance_cpu_write_ptr) dereference a raw pointer to DMA memory, creating an intermediate reference before calling volatile read/write methods. This is undefined behavior since DMA memory can be concurrently modified by the device. Fix this by moving the implementations into a gsp_mem module in fw.rs that uses the dma_read!() / dma_write!() macros, making the original methods on DmaGspMem thin forwarding wrappers. An alternative approach would have been to wrap the shared memory in Opaque, but that would have required even more unsafe code. Since the gsp_mem module lives in fw.rs (to access firmware-specific binding field names), GspMem, Msgq and their relevant fields are temporarily widened to pub(super). This will be reverted once IoView projections are available. Cc: Gary Guo <gary@garyguo.net> Closes: https://lore.kernel.org/nouveau/DGUT14ILG35P.1UMNRKU93JUM1@kernel.org/ Fixes: 75f6b1de8133 ("gpu: nova-core: gsp: Add GSP command queue bindings and handling") Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260309225408.27714-1-dakr@kernel.org [ Use pub(super) where possible; replace bitwise-and with modulo operator analogous to [1]. - Danilo ] Link: https://lore.kernel.org/all/20260129-nova-core-cmdq1-v3-1-2ede85493a27@nvidia.com/ [1] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-11drm/amd/display: Add documentation and cleanup DMUB HW lock managerNicholas Kazlauskas
To document how the helpers should be used before a subsequent change adds new locations that these helpers will be used. Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Add new types to replay configChunTao Tso
[WHAT] Add FRAME_SKIPPING_ERROR_STATUS to dpcd_replay_configuration. Add received_frame_skipping_error_hpd to replay_config. Add REPLAY_GENERAL_CMD_SET_COASTING_VTOTAL_WITHOUT_FRAME_UPDATE to dmub_cmd_replay_general_subtype. Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: ChunTao Tso <chuntao.tso@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Fix HWSS v3 fast path determinationNicholas Kazlauskas
[WHY] We're checking surface and stream updates after they've been applied to their respective states within `update_planes_and_stream_state`. Medium updates under the HWSS V3 fast path that are not supported or tested are getting implicitly if they don't trigger a DML validation and getting updated in place on the dc->current_state context. [HOW] Fix this issue by moving up the fast path determination check prior to `update_planes_and_stream_state`. This is how the V2 path works and how the V3 path used to work prior to the refactors in this area. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Add missing DCCG register entries for DCN20-DCN316Ivan Lipski
Commit 4c595e75110e ("drm/amd/display: Migrate DCCG registers access from hwseq to dccg component.") moved register writes from hwseq to dccg2_*() functions but did not add the registers to the DCCG register list macros. The struct fields default to 0, so REG_WRITE() targets MMIO offset 0, causing a GPU hang on resume (seen on DCN21/DCN30 during IGT kms_cursor_crc@cursor-suspend). Add - MICROSECOND_TIME_BASE_DIV - MILLISECOND_TIME_BASE_DIV - DCCG_GATE_DISABLE_CNTL - DCCG_GATE_DISABLE_CNTL2 - DC_MEM_GLOBAL_PWR_REQ_CNTL to macros in dcn20_dccg.h, dcn301_dccg.h, dcn31_dccg.h, and dcn314_dccg.h. Fixes: 4c595e75110e ("drm/amd/display: Migrate DCCG registers access from hwseq to dccg component.") Reported-by: Rafael Passos <rafael@rcpassos.me> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Add ESD detection for replay recoveryWeiguang Li
[HOW] Add Replay recovery flow so that when HPD occurs and ESD is detected, Replay can restore the system back to normal. Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Reviewed-by: Robin Chen <robin.chen@amd.com> Reviewed-by: Aric Cyr <aric.cyr@amd.com> Signed-off-by: Weiguang Li <wei-guang.li@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Update underflow detectionCharlene Liu
[WHY] Add underflow detection for later ASICs. Reviewed-by: Leo Chen <leo.chen@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Add COLOR_ENCODING/COLOR_RANGE to overlay planesHarry Wentland
Extend COLOR_ENCODING and COLOR_RANGE property creation to overlay planes in addition to primary planes. This allows overlay planes to use YUV formats with proper color space configuration when the hardware supports NV12/P010 formats. These properties control the YUV-to-RGB conversion matrix selection (BT.601/BT.709/BT.2020) and range handling (limited/full range). Assisted-by: Claude: claude-sonnet-4.5 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Add NV12/P010 formats to primary planeHarry Wentland
Add NV12, NV21, and P010 YUV formats to the primary plane's supported format list, enabling YUV content to be scanned out directly from the primary plane. Assisted-by: Claude: claude-sonnet-4.5 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Set chroma taps to 1 if luma taps are 1Harry Wentland
When luma is unscaled we also want chroma to be pixel-perfect. When luma taps are > 1 the result will be a blurred luma plane, even when the image isn't scaled. This makes IGT tests for CSC colorop pass. Assisted-by: Claude: claude-sonnet-4.5 Reviewed-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Add min clock init for DML21 mode programmingOvidiu Bunea
[WHY & HOW] 0 stream cases do not go through any DML validation which leaves DCN clocks in unoptimized states. If requesting DML validation or programming with 0 streams, program DCN clocks to lowest DPM state. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Ovidiu Bunea <ovidiu.bunea@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Return early from vesa replay enable functionPeichen Huang
[WHY & HOW] If the enable state is already as expect then just return. Reviewed-by: Robin Chen <robin.chen@amd.com> Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Peichen Huang <PeiChen.Huang@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/amd/display: Clean up NULL pointer warnings in dml2Gaghik Khachatrian
This commit addresses multiple warnings by adding defensive checks for NULL pointers before dereferencing them. The changes ensure that pointers such as are validated, preventing potential undefined behavior. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Signed-off-by: Gaghik Khachatrian <gaghik.khachatrian@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-11drm/i915/dmc: Fix an unlikely NULL pointer deference at probeImre Deak
intel_dmc_update_dc6_allowed_count() oopses when DMC hasn't been initialized, and dmc is thus NULL. That would be the case when the call path is intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() -> gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), as intel_power_domains_init_hw() is called *before* intel_dmc_init(). However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count() conditionally, depending on the current and target DC states. At probe, the target is disabled, but if DC6 is enabled, the function is called, and an oops follows. Apparently it's quite unlikely that DC6 is enabled at probe, as we haven't seen this failure mode before. It is also strange to have DC6 enabled at boot, since that would require the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and the driver stopping / reprogramming the firmware is a poorly specified sequence and as such unlikely an intentional BIOS behaviour. It's more likely that BIOS is leaving an unintentionally enabled DC6 HW state behind (without actually loading the required DMC firmware for this). The tracking of the DC6 allowed counter only works if starting / stopping the counter depends on the _SW_ DC6 state vs. the current _HW_ DC6 state (since stopping the counter requires the DC5 counter captured when the counter was started). Thus, using the HW DC6 state is incorrect and it also leads to the above oops. Fix both issues by using the SW DC6 state for the tracking. This is v2 of the fix originally sent by Jani, updated based on the first Link: discussion below. Link: https://lore.kernel.org/all/3626411dc9e556452c432d0919821b76d9991217@intel.com Link: https://lore.kernel.org/all/20260228130946.50919-2-ltao@redhat.com Fixes: 88c1f9a4d36d ("drm/i915/dmc: Create debugfs entry for dc6 counter") Cc: Mohammed Thasleem <mohammed.thasleem@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Tao Liu <ltao@redhat.com> Cc: <stable@vger.kernel.org> # v6.16+ Tested-by: Tao Liu <ltao@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260309164803.1918158-1-imre.deak@intel.com
2026-03-11Merge v7.0-rc3 into drm-nextSimona Vetter
Requested by Maxime Ripard for drm-misc-next because renesas people need fb797a70108f ("drm: renesas: rz-du: mipi_dsi: Set DSI divider"). Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
2026-03-11drm/i915/frontbuffer: reduce fb for frontbuffer abbreviation usageJani Nikula
Using fb for frontbuffer is a bit misleading, as framebuffer is the more common fb. Reduce fb usage in frontbuffer function naming. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/f7f04d63771891d1c3b1aa280485437bc4a70f20.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/i915/frontbuffer: call parent interface directlyJani Nikula
Do away with the redundant intel_frontbuffer_get(), intel_frontbuffer_put(), and intel_frontbuffer_ref() functions, and call the parent interface functions directly. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/7451574d6840fe9a4af16d2d6b81ffb7739b5b76.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/{i915, xe}/frontbuffer: move frontbuffer handling to parent interfaceJani Nikula
Move the get/put/ref/flush_for_display calls to the display parent interface. For i915, move the hooks next to the other i915 core frontbuffer code in i915_gem_object_frontbuffer.c. For xe, add new file xe_frontbuffer.c for the same. Note: The intel_frontbuffer_flush() calls from i915_gem_object_frontbuffer.c will partially route back to i915 core via the parent interface. This is less than stellar. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/f69b967ed82bbcfd60ffa77ba197b26a1399f09f.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/i915/overlay: convert from struct intel_frontbuffer to i915_frontbufferJani Nikula
The intel_frontbuffer_get() and intel_frontbuffer_put() calls are routed through intel_frontbuffer.c to i915_gem_object_frontbuffer.c. We might as well call the functions directly, instead of going through display code. This would only get worse with get/put being moved to the parent interface. To make this easier, convert overlay code from struct intel_frontbuffer to struct i915_frontbuffer, and add a i915_gem_object_frontbuffer_track() wrapper for clarity. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/829b304a6451e80fbce554bdc7788077245e803a.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/i915/gem: unify i915 gem object frontbuffer function namesJani Nikula
Many of the i915 gem object frontbuffer function names follow the file name as prefix. Follow suit with the remaining functions, renaming them i915_gem_object_frontbuffer_*(). Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/3415b59497f2c3a79586600d259eeaf58be73498.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/i915/gem: relocate __i915_gem_object_{flush, invalidate}_frontbuffer()Jani Nikula
Move __i915_gem_object_{flush,invalidate}_frontbuffer() to i915_gem_object_frontbuffer.c. All the other i915 gem object frontbuffer functions are there already, and the relevant declarations are in i915_gem_object_frontbuffer.h too. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/d779ef44b4b43feda9df63f1225a947a9cd23ba8.1772475391.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-03-11drm/panthor: Fix the "done_fence is initialized" detection logicBoris Brezillon
After commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"), dma_fence::ops == NULL can't be used to check if the fence is initialized. Use dma_fence_was_initialized() instead. v2: - Use dma_fence_was_initialized() instead of open-coding it Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Christian König <christian.koenig@amd.com> Reported-by: Steven Price <steven.price@arm.com> Reported-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Christian König <christian.koenig@amd.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260309124318.222902-1-boris.brezillon@collabora.com
2026-03-11drm/loongson: use drm_gem_ttm_dumb_map_offset()Amin GATTOUT
Replace the open-coded lsdc_dumb_map_offset() with the generic drm_gem_ttm_dumb_map_offset() helper, which is functionally identical. This removes unnecessary boilerplate and aligns with the DRM convention for TTM-based drivers. Signed-off-by: Amin GATTOUT <amin.gattout@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260308-master-v1-1-af32d71c8a1d@gmail.com
2026-03-11drm/gem-shmem: Track folio accessed/dirty status in vmapThomas Zimmermann
On successful vmap, set the page_mark_accessed_on_put and _dirty_on_put flags in the gem-shmem object. Signals that the contained pages require LRU and dirty tracking when they are being released back to SHMEM. Clear these flags on put, so that the buffer remains quiet until the next call to vmap. There's no means of handling dirty status in vmap as there's no write-only mapping available. Both flags, _accessed_on_put and _dirty_on_put, have always been part of the gem-shmem object, but never used much. So most drivers did not track the page status correctly. Only the v3d and imagination drivers make limited use of _dirty_on_put. In the case of imagination, move the flag setting from init to cleanup. This ensures writeback of modified pages but does not interfere with the internal vmap/vunmap calls. V3d already implements this behaviour. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> # gem-shmem Acked-by: Frank Binns <frank.binns@imgtec.com> # imagination Tested-by: Frank Binns <frank.binns@imgtec.com> # imagination Link: https://patch.msgid.link/20260227114509.165572-7-tzimmermann@suse.de
2026-03-11drm/gem-shmem: Track folio accessed/dirty status in mmapThomas Zimmermann
Invoke folio_mark_accessed() in mmap page faults to add the folio to the memory manager's LRU list. Userspace invokes mmap to get the memory for software rendering. Compositors do the same when creating the final on-screen image, so keeping the pages in LRU makes sense. Avoids paging out graphics buffers when under memory pressure. In pfn_mkwrite, further invoke the folio_mark_dirty() to add the folio for writeback should the underlying file be paged out from system memory. This rarely happens in practice, yet it would corrupt the buffer content. This has little effect on a system's hardware-accelerated rendering, which only mmaps for an initial setup of textures, meshes, shaders, etc. v4: - test for VM_FAULT_NOPAGE before marking folio as accessed (Boris) - test page-array bounds in mkwrite handler (Boris) v3: - rewrite for VM_PFNMAP v2: - adapt to changes in drm_gem_shmem_try_mmap_pmd() Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260227114509.165572-6-tzimmermann@suse.de
2026-03-11drm/gem-shmem: Refactor drm_gem_shmem_try_map_pmd()Thomas Zimmermann
The current mmap page-fault handler requires some changes before it can track folio access. Call to folio_test_pmd_mappable() into the mmap page-fault handler before calling drm_gem_shmem_try_map_pmd(). The folio will become useful for tracking the access status. Also rename drm_gem_shmem_try_map_pmd() to _try_insert_pfn_pmd() and only pass the page fault and page-frame number. The new name and parameters make it similar to vmf_insert_pfn_pmd(). No functional changes. If PMD mapping fails or is not supported, insert a regular PFN as before. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260227114509.165572-5-tzimmermann@suse.de
2026-03-11drm/gem-shmem: Return vm_fault_t from drm_gem_shmem_try_map_pmd()Thomas Zimmermann
Return the exact VM_FAULT_ mask from drm_gem_shmem_try_map_pmd(). Gives the caller better insight into the result. Return 0 if nothing was done. If the caller sees VM_FAULT_NOPAGE, drm_gem_shmem_try_map_pmd() added a PMD entry to the page table. As before, return early from the page-fault handler in that case. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Suggested-by: Matthew Wilcox <willy@infradead.org> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260227114509.165572-4-tzimmermann@suse.de
2026-03-11drm/gem-shmem: Test for existence of page in mmap fault handlerThomas Zimmermann
Not having a page pointer in the mmap fault handler is an error. Test for this situation and return VM_FAULT_SIGBUS if so. Also replace several lookups of the page with a local variable. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260227114509.165572-3-tzimmermann@suse.de
2026-03-11drm/gem-shmem: Use obj directly where appropriate in fault handlerThomas Zimmermann
Replace shmem->base with obj in several places. It is the same value, but the latter is easier to read. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260227114509.165572-2-tzimmermann@suse.de
2026-03-11drm/xe/userptr: Defer Waiting for TLB invalidation to the second pass if ↵Thomas Hellström
possible Now that the two-pass notifier flow uses xe_vma_userptr_do_inval() for the fence-wait + TLB-invalidate work, extend it to support a further deferred TLB wait: - xe_vma_userptr_do_inval(): when the embedded finish handle is free, submit the TLB invalidation asynchronously (xe_vm_invalidate_vma_submit) and return &userptr->finish so the mmu_notifier core schedules a third pass. When the handle is occupied by a concurrent invalidation, fall back to the synchronous xe_vm_invalidate_vma() path. - xe_vma_userptr_complete_tlb_inval(): new helper called from invalidate_finish when tlb_inval_submitted is set. Waits for the previously submitted batch and unmaps the gpusvm pages. xe_vma_userptr_invalidate_finish() dispatches between the two helpers via tlb_inval_submitted, making the three possible flows explicit: pass1 (fences pending) -> invalidate_finish -> do_inval (sync TLB) pass1 (fences done) -> do_inval -> invalidate_finish -> complete_tlb_inval (deferred TLB) pass1 (finish occupied) -> do_inval (sync TLB, inline) In multi-GPU scenarios this allows TLB flushes to be submitted on all GPUs in one pass before any of them are waited on. Also adds xe_vm_invalidate_vma_submit() which submits the TLB range invalidation without blocking, populating a xe_tlb_inval_batch that the caller waits on separately. v3: - Add locking asserts and notifier state asserts (Matt Brost) - Update the locking documentation of the notifier state members (Matt Brost) - Remove unrelated code formatting changes (Matt Brost) Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260305093909.43623-5-thomas.hellstrom@linux.intel.com
2026-03-11drm/xe: Split TLB invalidation into submit and wait stepsThomas Hellström
xe_vm_range_tilemask_tlb_inval() submits TLB invalidation requests to all GTs in a tile mask and then immediately waits for them to complete before returning. This is fine for the existing callers, but a subsequent patch will need to defer the wait in order to overlap TLB invalidations across multiple VMAs. Introduce xe_tlb_inval_range_tilemask_submit() and xe_tlb_inval_batch_wait() in xe_tlb_inval.c as the submit and wait halves respectively. The batch of fences is carried in the new xe_tlb_inval_batch structure. Remove xe_vm_range_tilemask_tlb_inval() and convert all three call sites to the new API. v3: - Don't wait on TLB invalidation batches if the corresponding batch submit returns an error. (Matt Brost) - s/_batch/batch/ (Matt Brost) Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260305093909.43623-4-thomas.hellstrom@linux.intel.com
2026-03-11drm/xe/userptr: Convert invalidation to two-pass MMU notifierThomas Hellström
In multi-GPU scenarios, asynchronous GPU job latency is a bottleneck if each notifier waits for its own GPU before returning. The two-pass mmu_interval_notifier infrastructure allows deferring the wait to a second pass, so all GPUs can be signalled in the first pass before any of them are waited on. Convert the userptr invalidation to use the two-pass model: Use invalidate_start as the first pass to mark the VMA for repin and enable software signalling on the VM reservation fences to start any gpu work needed for signaling. Fall back to completing the work synchronously if all fences are already signalled, or if a concurrent invalidation is already using the embedded finish structure. Use invalidate_finish as the second pass to wait for the reservation fences to complete, invalidate the GPU TLB in fault mode, and unmap the gpusvm pages. Embed a struct mmu_interval_notifier_finish in struct xe_userptr to avoid dynamic allocation in the notifier callback. Use a finish_inuse flag to prevent two concurrent invalidations from using it simultaneously; fall back to the synchronous path for the second caller. v3: - Add locking asserts in notifier components (Matt Brost) - Clean up newlines (Matt Brost) - Update the userptr notifier state member locking documentation (Matt Brost) Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260305093909.43623-3-thomas.hellstrom@linux.intel.com
2026-03-11drm: bridge: anx7625: correctly detect if PD can be disabledDmitry Baryshkov
During initial checks the ANX7625 bridge can be powered on before setting up the Type-C port. At this point, when anx7625_ocm_loading_check() checks if it can disable PD or not, it will notice that typec_port is not set and disable PD, breaking orientation and HPD handling. Unify the check between anx7625_ocm_loading_check() anx7625_i2c_probe() and anx7625_typec_register() and check for the presence of the "connector" node. Fixes: 8ad0f7d2e6fd ("drm: bridge: anx7625: implement message sending") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Xin Ji <xji@analogixsemi.com> Tested-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260211-anx7625-fix-pd-v1-1-1dd31451b06f@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-11drm: bridge: anx7625: don't crash if Type-C port is not usedLoic Poulain
The typec_set_*() functions do not tolerate being passed the NULL typec_port instance. However, if CONFIG_TYPEC is enabled, but anx7625 DT node doesn't have the usb-c connector fwnode, then typec_port remains NULL, crashing the kernel. Prevent calling typec_set_foo() functions by checking that ctx->typec_port is not NULL in anx7625_typec_set_status(). Call trace: typec_set_orientation+0x18/0x68 (P) anx7625_typec_set_status+0x108/0x13c anx7625_work_func+0x124/0x438 process_one_work+0x214/0x648 worker_thread+0x1b4/0x358 kthread+0x14c/0x214 ret_from_fork+0x10/0x20 Code: 910003fd a90153f3 aa0003f3 2a0103f4 (f9431400) Fixes: f81455b2d332 ("drm: bridge: anx7625: implement minimal Type-C support") Reported-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> [db: dropped chunk anx7625_typec_unregister(), wrote commit message] Cc: Amit Kucheria <akucheri@qti.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260215-anx-fix-no-typec-v1-1-75172a5ca88b@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-11drm: bridge: anx7625: enforce CONFIG_USB_ROLE_SWITCH dependencyArnd Bergmann
When CONFIG_TYPEC is enabled, but USB_ROLE_SWITCH=m, the anx7625 driver fails to link as built-in: aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_i2c_remove': anx7625.c:(.text+0x6ec): undefined reference to `usb_role_switch_put' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_typec_set_status': anx7625.c:(.text+0x3080): undefined reference to `usb_role_switch_set_role' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_i2c_probe': anx7625.c:(.text+0x5368): undefined reference to `fwnode_usb_role_switch_get' The problem is that both dependencies are optional in the sense of allowing the anx7625 driver to call the exported interfaces to be used from a loadable module, but cannot work for built-in drivers. It would be possible to handle all nine combinations of the CONFIG_TYPEC and CONFIG_USB_ROLE_SWITCH tristate options, but that does add a lot of complexity that seems unnecessary when in reality any user of this driver would have both enabled anyway. Turn both dependencies into hard 'depends on' here to only allow configurations where it's possible to actually use them, and remove the misguided IS_REACHABLE() check that did nothing here. Fixes: f81455b2d332 ("drm: bridge: anx7625: implement minimal Type-C support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260304083604.724519-1-arnd@kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-10drm/xe: Translate C-state "reset value" into RC6Gustavo Sousa
There are higher level sleep states that will cause RC6 state readout to come back with an "in-reset" value. That is the case with NVL-P. As those states are only possible if the GT is already in C6, let's just translate the "reset value" into C6 when doing the readout. Bspec: 67651 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-7-be9c902ee34e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-03-10drm/xe/xe3p: Drop Wa_16028780921Gustavo Sousa
Wa_16028780921 involves writing to a register that is locked by firmware prior to driver loading and doesn't have any effect if implemented by the KMD. Since the implementation of the workaround actually belongs the firmware, just drop the ineffective implementation by the KMD. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-6-be9c902ee34e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-03-10drm/xe/nvlp: Implement Wa_14026539277Gustavo Sousa
Implement the KMD part of Wa_14026539277, which applies to NVL-P A0. The KMD implementation is just one component of the workaround, which also depends on Pcode to implement its part in order to be complete. v2: - Add FUNC(xe_rtp_match_not_sriov_vf) to skip applying the workaround to SRIOV VFs. (Matt) v3: - Make Wa_14026539277 a device workaround instead of a GT workaround. (Matt) v4: - Drop FUNC(xe_rtp_match_not_sriov_vf) and use a direct check with IS_SRIOV_VF() in the workaround implementation. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> # v3 Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-5-be9c902ee34e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-03-10drm/xe/rtp: Add support for matching platform-level steppingGustavo Sousa
Add support for matching platform-level stepping, which will be used for an upcoming NVL-P workaround. As support for reading platform-level stepping information is added only as needed in the driver, add a warning when the rule finds a STEP_NONE value, which is an indication that the driver is missing such a support. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-4-be9c902ee34e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-03-10drm/xe/nvlp: Read platform-level stepping infoGustavo Sousa
There will be a NVL-P workaround for which we will need to know the platform-level stepping information in order to decide whether to apply it or not. While NVL-P has a nice mapping between the PCI revid and our symbolic stepping enumeration, not all platforms are like that: (i) Some platforms will have a single PCI revid used for a set platform level steppings (ii) and some might even require specific mappings. To make things simpler, let's include stepping information in the device info only on demand, for those platforms where it is needed for workaround checks. v2: - Call xe_step_platform_get() very early, to allow device workarounds to use it in early stages of device initialization. (Matt) Bspec: 74201 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> # v1 Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-3-be9c902ee34e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-03-10drm/xe: Drop unused IS_PLATFORM_STEP() and IS_SUBPLATFORM_STEP()Gustavo Sousa
The macros IS_PLATFORM_STEP() and IS_SUBPLATFORM_STEP() are unused since commit 87c299fa3a97 ("drm/xe/guc: Port Wa_14014475959 to xe_wa and fix it") and commit 63bbd800ff01 ("drm/xe/guc: Port Wa_22012727170/Wa_22012727685 to xe_wa"), respectively, and we can drop them now. Furthermore, in upcoming changes we will add logic to read platform-level step information from PCI RevID and keeping those macros around would potentially cause confusion. v2: - Cite commits that made the macros unused. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-2-be9c902ee34e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-03-10drm/xe: Modify stepping info directly in xe_step_*_get()Gustavo Sousa
In an upcoming change, we will add a member to struct xe_step_info to represent the platform-level stepping. As such, we should stop assigning the value returned by functions xe_step_pre_gmdid_get() and xe_step_gmdid_get() directly to xe->info.step. Since there are no other users for those functions, let's simply update them to modify xe->info.step directly. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260309-extra-nvl-p-enabling-patches-v5-1-be9c902ee34e@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-03-10gpu: nova-core: fix stack overflow in GSP memory allocationTim Kovalenko
The `Cmdq::new` function was allocating a `PteArray` struct on the stack and was causing a stack overflow with 8216 bytes. Modify the `PteArray` to calculate and write the Page Table Entries directly into the coherent DMA buffer one-by-one. This reduces the stack usage quite a lot. Reported-by: Gary Guo <gary@garyguo.net> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/509436-Nova/topic/.60Cmdq.3A.3Anew.60.20uses.20excessive.20stack.20size/near/570375549 Link: https://lore.kernel.org/rust-for-linux/CANiq72mAQxbRJZDnik3Qmd4phvFwPA01O2jwaaXRh_T+2=L-qA@mail.gmail.com/ Fixes: f38b4f105cfc ("gpu: nova-core: Create initial Gsp") Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Tim Kovalenko <tim.kovalenko@proton.me> Link: https://patch.msgid.link/20260309-drm-rust-next-v4-4-4ef485b19a4c@proton.me [ * Use PteArray::entry() in LogBuffer::new(), * Add TODO comment to use IoView projections once available, * Add PTE_ARRAY_SIZE constant to avoid duplication. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-10drm/i915: handle failure from vga_get_uninterruptible()Simon Richter
The vga_get_uninterruptible() function can return an error if it fails to set up VGA decoding for the requested device. If VGA decoding is unavailable, we don't need to be careful to leave the VGA emulation in a usable state, as vgacon will also be unable to get access later on, so just skip over the VGA accesses and the vga_put() call matching the failed vga_get_uninterruptible(). Signed-off-by: Simon Richter <Simon.Richter@hogyros.de> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1824 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260306151347.758836-1-Simon.Richter@hogyros.de
2026-03-10drm/xe: Allow per queue programming of COMMON_SLICE_CHICKEN3 bit13Lionel Landwerlin
Similar to i915's commit cebc13de7e704b1355bea208a9f9cdb042c74588 ("drm/i915: Whitelist COMMON_SLICE_CHICKEN3 for UMD access"), except that instead of putting the register on the allowlist for UMD to program, the KMD is doing the programming at context initialization based on a queue creation flag. This is a recommended tuning setting for both gen12 and Xe_HP platforms. If a render queue is created with DRM_XE_EXEC_QUEUE_SET_STATE_CACHE_PERF_FIX, COMMON_SLICE_CHICKEN3 will be programmed at initialization to enable the render color cache to key with BTP+BTI (binding table pool + binding table entry) instead of just BTI (binding table entry). This enables the UMD to avoid emitting render-target-cache-flush + stall-at-pixel-scoreboard every time a binding table entry pointing to a render target is changed. v2: Use xe_lrc_write_ring() v3: Update xe_query.c to report availability v4: Rename defines to add DISABLE_ v5: update commit message v6: rebase Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39982 Bspec: 73993, 73994, 72161, 31870, 68331 Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patch.msgid.link/20260306075504.1288676-1-lionel.g.landwerlin@intel.com
2026-03-10gpu/drm: panel: add support for DSI panel used in Motorola Atrix 4G and Droid X2Svyatoslav Ryhel
Add support for the DSI LCD panel module found in Motorola Atrix 4G or Droid X2 smartphones. Exact panel vendor and model are unknown hence panel uses generic compatible based on board where it is used. The panel has a 540x960 resolution with 24 bit RGB per pixel. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260223064630.12720-3-clamor95@gmail.com
2026-03-10drm/panel: Add Novatek/Tianma NT37700F panelRichard Acayan
Some Pixel 3a XL devices have a Tianma panel. Add support for it, with the aid of linux-mdss-dsi-panel-driver-generator. Link: https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator Signed-off-by: Richard Acayan <mailingradian@gmail.com> Tested-by: Yifei Zhan <yifei@zhan.science> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260310002606.16413-4-mailingradian@gmail.com
2026-03-10drm/panel: simple: Add Waveshare 13.3" panel supportMarek Vasut
Add WaveShare 13.3inch 1920x1080 DSI Capacitive Touch Display support. While the panel is described as DPI panel, it is part of a larger unit in non-removable metal casing, so the actual internal configuration is not known. The panel is attached to "waveshare,dsi2dpi" bridge via DT. It is likely that internally, this panel is an LVDS panel, connected to ICN6211 DSI-to-DPI bridge and then another unknown DPI-to-LVDS bridge. Current device link is at https://www.waveshare.com/13.3inch-dsi-lcd.htm Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260117005028.126361-1-marek.vasut+renesas@mailbox.org
generated by cgit v1.2.3 (git 2.25.1) at 2026-06-08 22:22:00 +0000