kernel/git/next/linux-next.git/drivers/gpu/drm/xe, branch master

Merge branch 'drm-xe-next' of https://gitlab.freedesktop.org/drm/xe/kernel.git

2026-09-10T15:06:32+00:00

Merge branch 'for-linux-next' of https://gitlab.freedesktop.org/drm/i915/kernel.git

2026-09-10T15:06:29+00:00

# Conflicts: # drivers/gpu/drm/i915/display/intel_cdclk.c

drm/xe/sysctrl: Add helper to check oCode firmware readiness

2026-09-09T19:44:22+00:00

Add xe_sysctrl_is_oobmsm_fw_ready(), a convenience wrapper around xe_sysctrl_check_app_status() to check oCode application readiness. Signed-off-by: Anoop Vijay Reviewed-by: Michael J. Ruhl Reviewed-by: Umesh Nerlige Ramappa Signed-off-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260904134935.674507-6-anoop.c.vijay@intel.com

drm/xe/sysctrl: Add helper to query application status

2026-09-09T19:44:20+00:00

Add xe_sysctrl_check_app_status() to query the state of a System Controller application using get_app_status_by_id mailbox command. The helper maps xe_sysctrl_app_id values to firmware application IDs and returns the reported application state. Add a convenience wrapper to check diag firmware application readiness. Signed-off-by: Anoop Vijay Reviewed-by: Michael J. Ruhl Reviewed-by: Umesh Nerlige Ramappa Signed-off-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260904134935.674507-5-anoop.c.vijay@intel.com

drm/xe: convert PCI barrier mmap to use xe_mmio_gem

2026-09-09T09:57:11+00:00

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 Cc: Thomas Hellström Cc: Tejas Upadhyay Cc: Matthew Brost Cc: Ilia Levi Reviewed-by: Ilia Levi Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260908165046.1393557-18-matthew.auld@intel.com

drm/xe/mmio_gem: reject VM_EXEC and drop VM_DONTCOPY

2026-09-09T09:57:10+00:00

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 Cc: Thomas Hellström Cc: Tejas Upadhyay Cc: Matthew Brost Cc: Ilia Levi Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260908165046.1393557-17-matthew.auld@intel.com

drm/xe/mmio_gem: fix destroy flow

2026-09-09T09:57:10+00:00

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 Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-16-matthew.auld@intel.com

drm/xe/mmio_gem: cache the dummy page per object

2026-09-09T09:57:10+00:00

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 Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-15-matthew.auld@intel.com

drm/xe/mmio_gem: Revoke drm_vma_node on xe_mmio_gem destroy

2026-09-09T09:57:10+00:00

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 Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Shuicheng Lin Reviewed-by: Ilia Levi Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-14-matthew.auld@intel.com

drm/xe/mmio_gem: simplify fault handler loop

2026-09-09T09:57:10+00:00

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 Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260908165046.1393557-13-matthew.auld@intel.com