summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
30 hoursMerge branch 'headers' of git://git.infradead.org/users/willy/pagecache.gitMark Brown
# Conflicts: # net/ceph/osd_client.c
30 hoursMerge branch 'for-next' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
30 hoursMerge branch 'for-linux-next' of ↵Mark Brown
https://gitlab.freedesktop.org/drm/rust/kernel.git
30 hoursMerge branch 'drm-xe-next' of https://gitlab.freedesktop.org/drm/xe/kernel.gitMark Brown
30 hoursMerge branch 'for-linux-next' of ↵Mark Brown
https://gitlab.freedesktop.org/drm/i915/kernel.git # Conflicts: # drivers/gpu/drm/i915/display/intel_cdclk.c
30 hoursMerge branch 'drm-next' of https://gitlab.freedesktop.org/agd5f/linux.gitMark Brown
30 hoursMerge branch 'for-linux-next' of ↵Mark Brown
https://gitlab.freedesktop.org/drm/misc/kernel.git
32 hoursMerge branch 'for-linux-next-fixes' of ↵Mark Brown
https://gitlab.freedesktop.org/drm/misc/kernel.git
32 hoursMerge branch 'rust-fixes' of https://github.com/Rust-for-Linux/linux.gitMark Brown
33 hoursdrm/xe: convert PCI barrier mmap to use xe_mmio_gemMatthew Auld
Convert the PCI barrier mmap over to use xe_mmio_gem, which is a good match for this functionality. This has the following advantages: 1. Removes a bunch of code. 2. Replaces the fragile hard coded fake offset design. 3. Adds the first user for xe_mmio_gem, which is preferred over nuking it. There are also potentially other upcoming usecases wanting this type of functionality, so having standard component to do this would be good. There shouldn't be any big functional change here. From userspace pov, they still query the fake offset like before, just that now it is no longer hard coded in the KMD. v2 (Thomas): - Prefer scoped_guard(). Also, just annotate ALL locations, even if not strictly needed. Reflect that in the kernel-doc. This will also shut up static analysis tools. Assisted-by: LLM Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260908165046.1393557-18-matthew.auld@intel.com
33 hoursdrm/xe/mmio_gem: reject VM_EXEC and drop VM_DONTCOPYMatthew Auld
Hardware MMIO registers should never be executable; reject VM_EXEC at mmap time and clear VM_MAYEXEC to prevent later mprotect attempts. Also drop VM_DONTCOPY so that child processes across fork() can inherit the mapping and lazily fault in the PFNs, matching standard DRM GEM semantics and making the existing drm_gem_vm_open() callback functional. This aligns with existing PCI_BARRIER, which will use this in the next patch. We don't want any noticeable behaviour change there, since this will be user visible. This will also be the first user. Assisted-by: LLM Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260908165046.1393557-17-matthew.auld@intel.com
33 hoursdrm/xe/mmio_gem: fix destroy flowIlia Levi
xe_mmio_gem_destroy() currently frees the GEM object directly, bypassing reference counting. Since existing VMAs hold a reference and the fault handler accesses the object through vma->vm_private_data, this is use-after-free. Additionally, nothing prevents the fault handler from installing PTEs to the real MMIO after destroy. Fix this with proper synchronization and refcounting. Also, do not set vm_pgoff to zero. Many DRM drivers do this because helpers like dma_mmap_pages() interpret vm_pgoff as an intra-buffer page offset; leaving the DRM fake offset there would break these helpers. Those drivers can get away with zeroing it because they map eagerly - all PTEs are established before mmap returns, so vm_pgoff is never consulted again. Our driver does not use such helpers and the newly introduced call to drm_vma_node_unmap() relies on vm_pgoff being untouched. v2: (Matt Auld) - use dma_resv lock to serialize fault handler with destroy - SIGBUS on access after destroy Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-16-matthew.auld@intel.com
33 hoursdrm/xe/mmio_gem: cache the dummy page per objectIlia Levi
Currently, when the fault handler provides a dummy page, it allocates a new one on every invocation and ties its lifetime to the drm_device via drmm_add_action_or_reset(). Concurrent faults after hot-unplug therefore accumulate pages that persist until device teardown. Cache a single dummy page in the xe_mmio_gem object and use dma_resv lock to protect its allocation. Free it with the object. v2: use dma_resv lock to protect the allocation (Matt Auld) Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-15-matthew.auld@intel.com
33 hoursdrm/xe/mmio_gem: Revoke drm_vma_node on xe_mmio_gem destroyShuicheng Lin
xe_mmio_gem_create() calls drm_vma_node_allow() but nothing ever calls drm_vma_node_revoke(). The drm_vma_offset_file rb-tree entry allocated by drm_vma_node_allow() is not freed by drm_gem_object_release(), so it is leaked on every create/destroy cycle. Add a struct drm_file * parameter to xe_mmio_gem_destroy() and call drm_vma_node_revoke() from there, mirroring the drm_vma_node_allow() call in xe_mmio_gem_create(). Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Suggested-by: Ilia Levi <ilia.levi@intel.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Ilia Levi <ilia.levi@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-14-matthew.auld@intel.com
33 hoursdrm/xe/mmio_gem: simplify fault handler loopIlia Levi
Make the iteration over the addresses in the VMA more explicit. No functional change, as the VMA matches the GEM object exactly. Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-13-matthew.auld@intel.com
33 hoursdrm/xe/mmio_gem: use write-back mapping for dummy pageIlia Levi
Currently vmf_insert_pfn() maps the dummy page as UC, inheriting the VMA's page protection which was set for the real MMIO region. This conflicts with the direct map's WB mapping of the same page, creating a cache type alias which is architecturally undefined on some platforms. Use vmf_insert_pfn_prot() with a WB pgprot instead. Also simplify to fault in the requested page instead of the whole VMA. Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260525125801.975038-6-ilia.levi%40intel.com Assisted-by: GitHub-Copilot:claude-opus-4.6 Signed-off-by: Ilia Levi <ilia.levi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-12-matthew.auld@intel.com
33 hoursdrm/xe/mmio_gem: forbid VMA splitIlia Levi
The fault handler assumes it always operates on a VMA spanning the entire GEM object. This does not hold when the VMA has been split, e.g. by a partial munmap or mprotect. In that case the handler may map wrong physical pages or cause SIGBUS. Handle this by forbidding VMA split, as partial unmaps are not deemed useful for MMIO GEMs. Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Ilia Levi <ilia.levi@intel.com> Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions") Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-11-matthew.auld@intel.com
34 hoursdrm/bridge: tc358768: Enforce input bus flags via atomic_checkLeonardo Costa
The tc358768 declares static bridge timings requiring pixel data to be sampled on the positive clock edge. However, the DRM core default propagation simply copies the output-side bus flags, coming from the next bridge, connector or panel, to the input side. If the propagated flags are incompatible with the bridge ones, the data is wrongly sampled, typically resulting in visual artifacts on the panel. Implement the atomic_check hook, replacing the mutually exclusive mode_fixup, and set the bridge state input bus flags to the ones required by the tc358768. The sync polarity defaulting previously done in mode_fixup is carried over into atomic_check unchanged. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Cc: stable@vger.kernel.org Signed-off-by: Leonardo Costa <leonardo.costa@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Swamil Jain <s-jain1@ti.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260706132440.1594239-1-leoreis.costa@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2 daysdrm/drm_exec: fix up contended obj when num_objects is 0Sunil Khatri
drm_exec_prepare_array() silently returns success without calling drm_exec_lock_contended() when num_objects is zero. This breaks the invariant upheld by drm_exec_lock_obj(), where every entry point into the locking sequence must first attempt to lock any previously contended object before proceeding. Drivers that chain multiple drm_exec_prepare_array() calls per drm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait ioctls, which prepare separate read and write BO arrays) can pass an empty array for one of the two calls. If contention is hit while preparing the non-empty array, exec->contended is set and the loop retries; on retry, the empty-array call preceding it is a no-op that never clears exec->contended, so drm_exec_retry_on_contention() immediately jumps back to the top of the loop without ever reaching the call that would resolve the contention. This spins forever. Fix it by having drm_exec_prepare_array() call drm_exec_lock_contended() directly when num_objects is zero, so a pending contended object dont loop infinitely. Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") CC: stable@vger.kernel.org # v6.6+ Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Link: https://lore.kernel.org/r/20260908091729.2749399-1-sunil.khatri@amd.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2 daysdrm/xe: Add multi_queue_active_lrca debugfsVarun Gupta
Add a per-GT debugfs file, multi_queue_active_lrca, that prints, for every engine supporting multi-queue, the currently active queue ID (CSMQDEBUG) and the LRCA of the exec queue occupying that slot within the running multi-queue group. RING_CURRENT_LRCA only reports the primary queue's LRCA for the group and does not update to reflect the active queue in multi-queue mode, which makes it hard to tell which queue is actually running when debugging multi-queue CSB/context-switch issues. Resolve the active LRCA by matching the primary LRCA against each queue's group and picking the queue at the reported active_id position. v4: - Extracted multi_queue_active_lrca into a dedicated multi_queue_debugfs_list to prevent debugfs node registration on platforms lacking multi-queue support entirely, via xe_gt_has_multi_queue() gating. (Tejas) v3: - Use xe_exec_queue_get_lrc() instead of raw pointer dereference to safely handle concurrent multi-queue group creation and avoid race conditions (Sashiko) v2: - Maintain alphabetical order for includes and pf_only_debugfs_list (Tejas) - Export and reuse xe_lrc_get_multi_queue_active_queue_id() instead of duplicate MMIO read (Tejas) Bspec: 60321, 73976 Signed-off-by: Varun Gupta <varun.gupta@intel.com> Link: https://patch.msgid.link/20260908033417.1019602-2-varun.gupta@intel.com Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2 daysdrm/amd/display: Drop KUnit tests for removed parse_hdmi_amd_vsdb()Rodrigo Vivi
parse_hdmi_amd_vsdb() was removed when HDMI FreeSync detection moved to the common EDID parser, but its declaration and KUnit tests remained, breaking modpost: ERROR: modpost: "parse_hdmi_amd_vsdb" [...connector_test.ko] undefined! Remove the stale declaration and the three dead test cases. Fixes: f65198b3d073 ("drm/amd/display: Use HDMI FreeSync range from common EDID parser") Cc: Alex Huang <Alex.Huang2@amd.com> Cc: Mario Limonciello <superm1@kernel.org> Assisted-by: Copilot:Claude-Opus-5 Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260820142802.1342066-2-rodrigo.vivi@intel.com
2 daysdrm/logicvc: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPERKarl Mehltretter
CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option"). When commit 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") later renamed the select in this Kconfig to CONFIG_DRM_KMS_DMA_HELPER, no symbol of that name existed, and git log -S finds no Kconfig file that has defined one since. The select is silently ignored. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 6bcfe8eaeef0 ("drm/fb: rename FB CMA helpers to FB DMA helpers") Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260905080344.34077-1-kmehltretter@gmail.com
2 daysdrm/adp: Drop the select of the nonexistent CONFIG_DRM_KMS_DMA_HELPERKarl Mehltretter
There is no Kconfig symbol CONFIG_DRM_KMS_DMA_HELPER. The former CONFIG_DRM_KMS_CMA_HELPER was removed by commit 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option") before this driver was added, so the select does nothing. The driver already selects CONFIG_DRM_GEM_DMA_HELPER, which is what it needs. Remove the dead line. Fixes: 332122eba628 ("drm: adp: Add Apple Display Pipe driver") Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260905080426.34224-1-kmehltretter@gmail.com
2 daysdrm/vboxvideo: create blend mode property on planesQinyun Tan
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. Both the vboxvideo primary and cursor planes expose ARGB8888 and trip this on driver load. VirtualBox draws the cursor through the host windowing system, which treats the guest-supplied pointer shape as straight (non-pre-multiplied) alpha: the host frontend loads the pixels verbatim into an unpremultiplied ARGB image before handing them to the host cursor APIs. This corresponds to DRM_MODE_BLEND_COVERAGE. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_COVERAGE to make these semantics explicit and silence the warning. The primary plane's alpha channel is ignored by the host (opaque blit) and it is the bottom-most plane anyway; advertise the same value there for consistency. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260901083234.1828755-5-qinyuntan@linux.alibaba.com
2 daysdrm/virtio: create blend mode property on cursor planeQinyun Tan
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. The virtio-gpu cursor plane (HOST_ARGB8888) trips this. The virtio-gpu specification does not define the cursor alpha semantics. The host forwards the cursor pixels verbatim to its display frontends, and the remote cursor protocols among them (SPICE alpha cursors, the VNC "Cursor With Alpha" encoding) both define pre-multiplied alpha, matching what userspace has always assumed when the property is not attached. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_PREMULTI to make these semantics explicit and silence the warning. The primary plane only exposes HOST_XRGB8888, so the call is gated to the cursor. No functional change. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260901083234.1828755-4-qinyuntan@linux.alibaba.com
2 daysdrm/qxl: create blend mode property on primary and cursor planesQinyun Tan
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. Both the qxl primary and cursor planes expose ARGB8888 and trip this on driver load. qxl submits cursors as SPICE_CURSOR_TYPE_ALPHA, which the SPICE protocol explicitly defines as a "pre-multiplied ARGB8888 pixmap" (Spice Protocol, "Cursor channel definition" section [1]). This matches the blend mode userspace has always assumed when the property is not attached. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_PREMULTI to make these semantics explicit and silence the warning. The primary plane is the bottom-most plane so its blend mode has no visible effect; advertise the same value there for consistency. No functional change. [1] https://www.spice-space.org/spice-protocol.html Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260901083234.1828755-3-qinyuntan@linux.alibaba.com
2 daysdrm/ast: create blend mode property on cursor planeQinyun Tan
Since commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed"), drm_mode_config_validate() warns when a plane exposes an alpha pixel format but not the "pixel blend mode" property. The ast cursor plane (ARGB4444, ARGB8888) trips this on driver load: [PLANE:37:plane-1] pixel format with alpha exposed but blend mode not setup WARNING: drivers/gpu/drm/drm_mode_config.c:872 at drm_mode_config_validate+0x48f/0x510 [drm] ... Call Trace: drm_dev_register+0x1ce/0x290 [drm] ast_pci_probe+0x19d/0x3f0 [ast] local_pci_probe+0x41/0x90 Per Thomas Zimmermann's review, the ASPEED documentation describes the hardware cursor as blending with straight (non-pre-multiplied) alpha, which corresponds to DRM_MODE_BLEND_COVERAGE. Expose a "pixel blend mode" property advertising only DRM_MODE_BLEND_COVERAGE to make the hardware semantics explicit and silence the warning. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Qinyun Tan <qinyuntan@linux.alibaba.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260901083234.1828755-2-qinyuntan@linux.alibaba.com
2 daysdrm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batchesThomas Hellström
emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to flush the L2/HDC data cache before fence signalling, but it never requests a flush of the LSC untyped L1 data cache via the 'Untyped Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11]. Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to also flush/invalidate the untyped L1 cache, but only depending on how HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling between HDC Pipeline Flush and the untyped L1 cache flush no longer holds in practice, regardless of how HDC_CHICKEN0 is programmed, so relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan driver (anv) has been assuming the kernel flushes both caches between submissions, and hit user-visible corruption in apps such as Llama.cpp because of this gap; it now works around it by flushing both caches again from userspace at the end of every command buffer. Correctness between submissions on the same queue is userspace's responsibility and belongs in Mesa, not the kernel. However, for security we must ensure stale data can't leak through the untyped L1 dataport cache once memory is reclaimed or evicted, which requires the KMD to flush it before releasing memory for reuse. Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline Flush coupled to the untyped L1 cache flush, so those platforms are unaffected. Mesa's own anv driver found that on MTL the HW disconnected the two independently of how HDC_CHICKEN0 is programmed, and could not bring the old behavior back even by writing the register by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don't prevent L1 untyped cache flush in 3D mode"). The kernel can't reliably request the flush from the CS on MTL either, so restrict the new PIPE_CONTROL bit to GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on. Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on Xe2 and later, so the L1 data cache is known clean before memory is released for reuse, without depending on undocumented platform-specific HDC_CHICKEN0 behavior. Bspec: 56551 Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/7c2ff46a4fc3e537573ac9503057e0cd29b6fff3 Fixes: 9f8f93bee3ef ("drm/xe: Emit a render cache flush after each rcs/ccs batch") Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8909 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.8+ Assisted-by: GitHub_Copilot:claude-sonnet-5 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260903114552.48634-1-thomas.hellstrom@linux.intel.com
2 daysdrm/sched: Create a fake device for KUnit testsShixiong Ou
The DRM scheduler KUnit tests pass NULL for the dev field in drm_sched_init_args, which NULL-pointer dereferences in the drm_sched_job trace event via dev_name() on sched->dev. Give the mock scheduler a device with kunit_device_register(), which is also cleaned up at test exit. A per-function counter keeps the device names unique, since some tests create several mock schedulers. Fixes: 5a99350794fe ("drm/sched: Add scheduler unit testing infrastructure and some basic tests") Cc: stable@vger.kernel.org Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Acked-by: Maxime Ripard <mripard@kernel.org> [phasta: removed static variable init to 0 again] Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260908055941.351486-1-oushixiong1025@163.com
2 daysMerge drm/drm-fixes into drm-misc-fixesThomas Zimmermann
Backmerging to get drm-misc-fixes up to v7.3-rc2. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2 daysdrm/xe/gt: Report GT reset failure using SIGIDArvind Yadav
Route the GT reset failure log through the structured SIGID logging helper. Failure to complete the full graphics reset means GT reset did not finish as expected. Use the GT component, which maps to XE_SIGID_GT_TDR, and pass the reset errno value to the helper. Also update the message to describe the actual failure. The driver does not clear GRDOM_FULL directly. The reset should complete and clear it within the timeout. Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Suggested-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260903054610.3640788-5-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2 daysdrm/xe/svm: Report terminal page-fault failures using SIGIDArvind Yadav
Use structured SIGID logging for SVM page-fault errors after retries are exhausted. Report these failures with the PAGEFAULT component, which maps to XE_SIGID_MEM_FAULT. Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Suggested-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260903054610.3640788-4-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2 daysdrm/xe/guc: Report reset failure using SIGIDArvind Yadav
Route the GuC submission engine reset failure through the structured SIGID logging helper. Use the GUCSUBMIT component, which maps to XE_SIGID_GT_TDR, and pass -EIO as the errno value. Cc: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260903054610.3640788-3-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2 daysdrm/xe/log: Add GUCSUBMIT componentArvind Yadav
The proper SIGID for GuC submission failures is GT_TDR, but using the generic GT component may hide the real source of the report. Add GUCSUBMIT as a DRIVER component and map it to XE_SIGID_GT_TDR. Cc: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20260903054610.3640788-2-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
3 daysdrm/gpusvm: keep an IOVA mapped range dma address inlineHonglei Huang
dma_iova_try_alloc() reserves one contiguous IOVA for the whole range and links each page at the next offset, so the device addresses run contiguously from entry 0 and one entry describes them all. A 2 MiB range of 4 KiB pages then drops the same 8 KiB array as a THP backed one. Fold only when state_offset covers the full range, which proves no device page was mapped in between, and only single page entries, so the order kept is 0 and stays true. Widening it instead would tell a consumer to use a huge page for npages separate CPU pages, which hangs Vega20 on amdgpu. The kept entry no longer bounds the segment, so skip the unmap walk when it has nothing to do, keyed off dpagemap rather than the flags, which are not published yet on the error unwind. Consumers need the same distinction, so drm_gpusvm_pages_first_dma() returns it alongside the array from one read of the flags; xe passes it to xe_res_first_dma(). Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-7-honghuan@amd.com
3 daysdrm/gpusvm: keep a single DMA mapping inline for THPHonglei Huang
drm_gpusvm_get_pages() sizes the dma_addr array for one drm_pagemap_addr per page, but the mapping loop advances by page order, so a range backed by one huge page needs a single entry. For a 2 MiB THP that is an 8 KiB array holding 16 bytes of address. Union that entry with the array pointer, discriminated by a new inline_dma_mapping flag. When drm_gpusvm_dma_map_pages() ends up with one entry it stores it inline and frees the array, after the last error unwind, which still walks the array form. An unchecked dma_addr read is now type confusion rather than a compile error, so reads go through the new drm_gpusvm_pages_first_dma() accessor, including the two xe_pt_stage_bind() paths. Only get_pages() and the free path write the union, never the notifier, and both run under the driver lock that every address reader already holds. The unlocked short circuit in drm_gpusvm_pages_valid_unlocked() goes for the same reason: it cannot resolve the union, and every instance it rejects has to be reset before the allocation loop reuses it. Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-6-honghuan@amd.com
3 daysdrm/gpusvm: make the DMA mapping step in get_pages() optionalHonglei Huang
Some drivers (e.g. AMDXDNA) only need the CPU pages faulted in and tracked by the notifier, no need DMA mapping. Add a drm_gpusvm_ctx::no_dma_map flag. When set, get_pages() does the shared HMM fault and records notifier_seq, but skips svm_pages->drm validation, the dma_addr allocation and drm_gpusvm_dma_map_pages(). With no mapping state to check, the fault is redone on every call. The default (no_dma_map == 0) is unchanged. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-5-honghuan@amd.com
3 daysdrm/gpusvm: let drm_gpusvm_get_pages() map an array of pagesHonglei Huang
With the N:1 drm_gpusvm_pages layout, one CPU range mirrored on several drm_devices, the caller had to invoke get_pages() once per device and repeat the HMM fault every time. Make get_pages() take a contiguous array of drm_gpusvm_pages plus a count: fault once, then DMA map each instance by drm_gpusvm_dma_map_pages() under a single read_retry gate. xe range and userptr callers are updated. Document the N:1 array usage in the Overview, showing how get_pages() and drm_gpusvm_range_set_unmapped() take the whole array and its count while the unmap and free paths stay per-instance. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-4-honghuan@amd.com
3 daysdrm/gpusvm: extract drm_gpusvm_dma_map_pages() helperHonglei Huang
Move the per-device DMA mapping loop of drm_gpusvm_get_pages() into a helper drm_gpusvm_dma_map_pages(). The mapping logic is only moved, not changed, so there is no functional change. The helper maps the already-faulted pfns into one drm_gpusvm_pages instance under the notifier lock and unwinds its own partial mapping on error. The HMM fault and the notifier retry loop stay in get_pages() common code rather than being pushed down to drivers, so no driver has to reimplement the subtle fault and retry logic. With the mapping isolated per instance, get_pages() can later fault once and DMA map an array of drm_gpusvm_pages plus a count, one per owning drm_device. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-3-honghuan@amd.com
3 daysdrm/gpusvm: move dma_addr allocation before the notifier lockHonglei Huang
The dma_addr allocation was in a lazy allocation flow, it needs unlock and goto map_pages. The allocation only needs npages, so just do it before taking the lock. Drop the map_pages label and the relock flow, so the sequence becomes fault, allocate, then lock, validate, map and unlock. No functional change intended. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260905133142.3628027-2-honghuan@amd.com
3 daysdrm/i915/bios: remove VS/PE-O warningMichał Grzelak
There is not much use of warning when port asks to override default VS/PE since it is already logged. Remove drm_WARN() and child_device from print_ddi_port() since drm_WARN() was the only user of it. Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-9-michal.grzelak@intel.com
3 daysdrm/i915: override Combo's VS/PE when requestedMichał Grzelak
Add accessor function for Combo to read requested table from VBT #57. Parse the requested table and transform data into port's buffer. Actual data is fully stored in the lowest byte although each entry is 4 bytes wide. Thus convert u32 into u8 and store the data. For EHL, in cases when eDP encoder uses low vswing, choose 3rd table if encoder supports HBR3. Otherwise use 2nd table for eDP using low vswing. In cases when eDP encoder does not use low vswing, choose 2nd table if encoder supports mode higher or including HBR2. Otherwise use 1st table for eDP not using low vswing. For external DP follow same path and use same indices as in eDP without low vswing case. For JSL, always use 1st table for external DP. For eDPs not using low vswing use 1st table as well. In cases when eDP encoder uses low vswing, choose 1st table if encoder supports HBR3. When encoder supports HBR2 choose 3rd table. When encoder supports modes lower than HBR2 choose 2nd table. There are no changes to intel_ddi_dp_level() since selection of correct row of intel_ddi_buf_trans_entry is same as when no override request has been done. Looking from other OSes, in case when encoder does not support DP we could theoretically use 1st table. However, as of now, use default tables. v11->v12 - don't set vspeo->num_entries per PHY/platform - check for low vswing eDP for EHL (Sashiko) - reverse order of indices for JSL (Sashiko) v10->v11 - initialize local variables at declaration block (Jani) - branch with 'else` instead of initializing twice (Jani) v9->v10 - call dedicated VS/PE-O vfunc - drop deconstifying default tables (Suraj, Jani) - cache `entries` into const field after data is overwritten (Jani) v8->v9 - deconstify intel_ddi_buf_trans_entry v6->v7 - handle VS/PE-O's VBT details in intel_bios_* functions (Jani) - remove vspeo's cast to (void *) (Jani) - call encoder->get_buf_trans() once (Jani) - return NULL from intel_bios_get_* when using default (Jani) - validate VS/PE-O in intel_bios.c (Jani) - check devdata->vspeo if VS/PE-O was requested - inline {jsl,ehl}_combo_get_vspeo_buf_trans() - remove temporarily LT v4->v5 - blend index computation with table parsing - remove enums entirely - add spaces around operators (Suraj) - remove spaces after type casting (Suraj) - remove INTEL_DISPLAY_STATE_WARN (Suraj) Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260907122742.2512901-1-michal.grzelak@intel.com
3 daysdrm/i915: override Snps's VS/PE when requestedMichał Grzelak
Add accessor functions for Snps to read requested table from VBT #57. Parse the requested table and transform data into port's buffer. Actual data is fully stored in the lowest byte although each entry is 4 bytes wide. Thus convert u32 into u8 and store the data. For C20, use 6th table if encoder supports DP 2.0 or higher. Otherwise use 5th table for DP. For C20, tables 1-4 are not used at all and are most likely to be zeroed. 5th table is used for any mode below DP 2.0 (exclusive). 6th table is used for any mode above DP 2.0 (inclusive). For C10, use 2nd table for external DP if encoder supports any mode beyond or including HBR2. Use 1st table if external DP encoder supports anything lower than HBR2. For eDP, use 4th table if encoder supports HBR3. Otherwise use 3rd table for eDP. For C10, 1st table is used for external DP with modes below HBR2 (exclusive). 2nd table is used for external DP with modes higher than HBR2 (inclusive). 3rd table is used for eDP with modes lower than HBR3 (exclusive). 4th table is used for eDP with modes higher than HBR3 (inclusive). Indices for other tables have not yet been observed to be used as of now. There are no changes to intel_ddi_dp_level() since selection of correct row of intel_ddi_buf_trans_entry is same as when no override request has been done. v11->v12 - don't set vspeo->num_entries per PHY - don't refer to 1st table as fallback for non-DP for C10 (Sashiko) v10->v11 - remove no-longer-relevant check for NULL devdata (Jani) - initialize local variables at declaration block (Jani) - branch with 'else` instead of initializing twice (Jani) - use blank line before 'return` (Jani) v9->v10 - call dedicated VS/PE-O vfunc - drop deconstifying default tables (Suraj, Jani) - cache `entries` into const field after data is overwritten (Jani) v8->v9 - init vspeo before using it - deconstify intel_ddi_buf_trans_entry v7->v8 - remove comments (Suraj) - add check for LT (Suraj) v6->v7 - handle VS/PE-O's VBT details in intel_bios_* functions (Jani) - remove vspeo's cast to (void *) (Jani) - check devdata->vspeo if VS/PE-O was requested - call encoder->get_buf_trans() once (Jani) - return NULL from intel_bios_get_* when using default (Jani) - validate VS/PE-O in intel_bios.c (Jani) - inline mtl_{c10,c20}_get_vspeo_buf_trans() - remove temporarily LT v4->v5 - blend index computation with table parsing - remove enums entirely - change funcs prefix from snps_ to mtl_ (Suraj) - add spaces around operators (Suraj) - remove spaces after type casting (Suraj) - remove INTEL_DISPLAY_STATE_WARN (Suraj) v3->v4 - stick to solely changing VBT data into current structures (Jani) - move iterator declaration to declaration block (Suraj) v2->v3 - remove unnecessary braces from if block (Suraj) - return -EINVAL instead of -1 (Suraj) Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-7-michal.grzelak@intel.com
3 daysdrm/i915/buf_trans: add vfunc for VS/PE-OMichał Grzelak
Choosing correct table for Vswing / Pre-emphasis Override is platform specific. It also requires different checks that are already used for choosing predefined tables. Add new get_buf_trans_override() vfunc into intel_encoder returning deparsed table from VBT#57. In next patches, set it inside already present if-ladder from intel_ddi_buf_trans_init() instead of duplicating it. Note that get_buf_trans() cannot be overwritten since there are cases when we need to rollback although VS/PE-O was requested, eg. DP is not connected or feature is not yet implemented for the platform. Assume that vfunc returns NULL on rollback and return predefined tables. Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-6-michal.grzelak@intel.com
3 daysdrm/i915/bios: de/allocate VS/PE-O buffers for each portMichał Grzelak
Every devdata needs VS/PE-O dedicated buffers since each port can request an override. Add intel_ddi_buf_trans{,_entry} pointers into intel_bios_encoder_data. Allocate struct intel_ddi_buf_trans{,_entry} for the port if VS/PE-O was requested and is supported. Keep NULL in vspeo if any allocation failed or VS/PE-O was not requested. It will be used later for checking if override should actually take place. Note that we theoretically could store intel_ddi_buf_trans_entry inside `entries` field of newly allocated intel_ddi_buf_trans. However it will be impossible to overwrite the buffer during intel_ddi_get_buf_trans() without discarding const qualifier of `entries` field. This would involve either void casting or deconstifying entries field and in turn all predefined tables as well. Thus add a separate non-const qualified field into intel_bios_encoder_data for the buffer, which after overwriting will be promoted to be const qualified. Deallocate the buffer as well as entries if requested. v11->v12 - set vspeo->num_entries once (Sashiko) - free allocated vspeo->entries (Sashiko) v9->v10 - add separate non-const field for `entries` caching - cache `entries` into const field after data is overwritten (Jani) v4->v5 - set devdata->vspeo->num_entries in intel_bios.c Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-5-michal.grzelak@intel.com
3 daysdrm/i915/bios: print VS/PE-O port infoMichał Grzelak
Issue a debug message when port asks to override default Vswing / Preemphasis tables. Add helper intel_bios_encoder_requests_vspeo() to check if port requests for overriding default VS/PE tables. v6->v7 - expand VS/PE-O acronym in debug logging (Jani) v3->v4 - change debug message when requesting VS/PE-O (Suraj) Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-4-michal.grzelak@intel.com
3 daysdrm/i915/bios: store VBT #57's metadata in intel_vbt_dataMichał Grzelak
Store tables, number of tables, number of rows and number of columns in intel_vbt_data when search for the VBT #57 has succeeded. Structurize all VS/PE-O relevant metadata inside anonymous struct named as vspeo. Presence of C20 or newer PHY causes each table to contain 16 rows. Each table contains 10 rows in case C20 PHY is absent. Use display version to determine number of rows since there is no helper in intel_bios.c to check presence of any C20+ PHY. pre-MTL platforms should have 10 rows while MTL+ should have 16 rows. v5->v6 - add Bspec (Suraj) v3->v4 - remove unnecessary init of VS/PE-O metadata (Suraj) - add helper for computing number of rows (Suraj) - fix num_rows's type (Jani, Suraj) - declare num_rows (Suraj) Bspec: 68963 Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-3-michal.grzelak@intel.com
3 daysdrm/i915/bios: search for VBT #57 by defaultMichał Grzelak
Start searching for Vswing / Preemphasis Override Block during VBT parsing at init_bdb_blocks(). Check for failure since pre-ICL GOPs do not contain the block. Check also if VBT version is appropriately up-to-date. v6->v7 - parse VBT#57 before blocks dependent on child device list (Jani) - remove debug message (Suraj) v3->v4 - add Bspec (Suraj) Bspec: 32063 Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260904123148.2165596-2-michal.grzelak@intel.com
3 daysdrm/xe: Guard page-fault worker with runtime PM checkVarun Gupta
During VM teardown, the VM's runtime PM reference is dropped asynchronously, allowing the device to autosuspend while stale page faults belonging to the now-dead VM are still queued. When the page-fault worker later tries to ack one of these, it calls into guc_ct_send_locked() on an already-suspended device, tripping:   Assertion `!xe_pm_runtime_suspended(xe)` failed!   WARNING at xe_device.c:1267 xe_device_assert_mem_access+0x11c/0x140 [xe] A live VM/exec queue always holds a PM reference while it has outstanding work, so if the device is suspended at ack time, the owning context is already gone and the fault is stale. Take a runtime PM reference across the entire pagefault queue worker to safely deliver acks for torn-down VMs. v3: - Move PM ref to the generic xe_pagefault_queue_work using guard(xe_pm_runtime)(xe) instead of tracking it in the GuC backend(Matt Brost). v2: - Hold PM ref across the entire batch (begin/end) instead of per-ack. This prevents the device from autosuspending mid-batch, which would leave write_only acks written but the end flush skipped, and skip counter++, desyncing the cadence check.(Himal) - Add a comment explaining stale faults.(Himal) Fixes: f289f7807119 ("drm/xe: Add xe_guc_pagefault layer") Signed-off-by: Varun Gupta <varun.gupta@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patch.msgid.link/20260907050011.497181-2-varun.gupta@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
3 daysMerge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to get drm-misc-next up to v7.3-rc2. Requested for commit 3a2c4d55e32a ("treewide: refresh kmalloc_obj() conversions"). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-10 19:01:40 +0000