Currently, xe_display_bo_framebuffer_init() unconditionally attempts to
apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB creation with
-EINVAL if the BO is already VM_BINDed.
However, for imported dma-bufs (ttm_bo_type_sg), this check doesn't seem
to make much sense since CPU caching policy is entirely controlled by
the exporter. Plus there is no place to set this flag, in the first
place. Also this is not rejected if not yet vm_binded, but that seems
arbitrary since setting or not setting FORCE_WC should a noop either
way, at this stage, and whether it is currently VM_BINDed makes no
difference.
Currently if we run an app and offload rendering to an external dGPU,
like NV or another xe device, the dma-buf passed back to the compositor
(igpu) will be an actual external import from xe pov, and it will be
missing FORCE_WC, and if the compositor side did a VM_BIND before
turning into it into an fb the whole thing gets rejected.
So it looks like we either need to reject outright, no matter what, or
this usecase is valid and we need to loosen the restriction for sg
buffers. Proposing here to loosen the restriction.
Assisted-by: Gemini:gemini-3.1-pro-preview
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919
Fixes: 44e694958b ("drm/xe/display: Implement display support")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Cc: <stable@vger.kernel.org> # v6.12+
Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260612170501.550816-2-matthew.auld@intel.com
(cherry picked from commit 3e493f88c8)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
- Fix Xe oops in suspend/shutdown when display was disabled (Jani)
Display in general:
- More general refactor towards display separation (Jani)
- Preparation for fix Adaptive-Sync SDP for PR with Link ON + Auxless-ALPM (Ankit)
- PSR related fixes and improvements (Jouni)
- Use polling when irqs are unavailable (Michal)
- Split bandwidth params into platform- and display-IP-specific structs (Gustavo)
- Revert "drm/i915/backlight: Remove try_vesa_interface" (Suraj)
- Casf & scaler refactoring (Michal)
- Add support for pipe background color (Maarten)
- General clean-ups (Maarten)
- Sanitize DP link capability change handling (Imre)
- Multiple BW QGV fixes (Ville)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmoYRLYACgkQ+mJfZA7r
E8rtVQgArEfJhvSxvoALAQjfeM/mjWHj0AThfCxROed2Z1TO5WN+BB9hXzwGwEqA
EE6TnKhDEQZy22a/t/iNhDDUy1UTYifMbfFAsdVz7NYfXKZpkRdJ4/mZk6MVEcrd
jEbrIw8ZQ7SPTvhVdKn6zWvLzPskrJqzfIS4JFYJn61MepfD+QhOayoUxEU9gTjZ
+SNSHu0lQSpwYwz+0AV65CkDwSbFZDqMLtDd8MxI0b4X8kjX1D9MH+QNu2wYnk7i
9hqcErJ/jH/hMCNHwCIdPh6sfli8qpN7GbAdDcgkA+/E0hsJBkdJe2cSDGxUA/Ws
76P8PjtZ3sGbq7vPL/Db6t0lY1yVJQ==
=cTLp
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-2026-05-28' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
Xe related:
- Fix Xe oops in suspend/shutdown when display was disabled (Jani)
Display in general:
- More general refactor towards display separation (Jani)
- Preparation for fix Adaptive-Sync SDP for PR with Link ON + Auxless-ALPM (Ankit)
- PSR related fixes and improvements (Jouni)
- Use polling when irqs are unavailable (Michal)
- Split bandwidth params into platform- and display-IP-specific structs (Gustavo)
- Revert "drm/i915/backlight: Remove try_vesa_interface" (Suraj)
- Casf & scaler refactoring (Michal)
- Add support for pipe background color (Maarten)
- General clean-ups (Maarten)
- Sanitize DP link capability change handling (Imre)
- Multiple BW QGV fixes (Ville)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/ahhFE5Co5PdZQKG8@intel.com
It's confusing that intel_display_power.[ch] exposes two groups of
interfaces, one named intel_power_domains_*() and one
intel_display_power_*().
Unify on the latter, based on the file name, but also because it's more
generic. This makes the caller side easier to follow.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/8fae4b0e3476aeffb0164215b7e0f0ae1d825f72.1779800132.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
xe_display_flush_cleanup_work() is a bit of an oddball function in xe
display code. There shouldn't be anything this specific or xe
specific. While I'm not sure what the correct refactor for the function
should be, move it to shared display code for starters, next to the
eerily similar but slightly different intel_has_pending_fb_unpin() that
is only called from i915 core.
The main goal here is to unblock some refactors on
for_each_intel_crtc().
v2: Add FIXME comment (Ville)
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260525110553.651208-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add a number of *_display_irq_handler() functions to group together the
various display irq handler parts for the platforms, to declutter the
core i915 irq code from the details.
Add master_ctl to struct intel_display_irq_state, and pass the state
pointer to the handlers where necessary. The handler function signatures
are intentionally the same to allow for more refactoring.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/5088a9a658ce9a57049c999ee2ebababd7536b6c.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Call the platform specific display irq postinstall hooks via
intel_display_irq_postinstall().
Relocate the gen11 HAS_DISPLAY() check to
intel_display_irq_postinstall(), as the funcs pointer won't be
initialized for no display.
v2:
- relocate HAS_DISPLAY() (Sashiko)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/65f1ad73628fb6dbdf6e782493eaecb1d61abaf7.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Introduce display irq hooks with struct intel_display_irq_funcs, and add
the ->reset hook as the first thing. Call the reset hooks from i915 and
xe core via intel_display_irq_reset().
Relocate the gen8 and gen11 HAS_DISPLAY() check to
intel_display_irq_reset(), as the funcs pointer won't be initialized for
no display.
Note: We're increasingly moving to the territory of not touching display
at all if there's no display or it has been fused off. Which is good,
but care must be taken to not have hardware setup required also for no
display cases in display code. Also note that the line is fuzzy for
older platforms, but there we also don't have fusing.
v2:
- make the structs static const (Sashiko)
- relocate HAS_DISPLAY() (Sashiko)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/f9d75e8af92b5550a9d07f29491be5313b7c866b.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The xe driver keeps track of whether to probe display, and whether
display hardware is there, using xe->info.probe_display. It gets set to
false if there's no display after intel_display_device_probe(). However,
the display may also be disabled via fuses, detected at a later time in
intel_display_device_info_runtime_init().
In this case, the xe driver does for_each_intel_crtc() on uninitialized
mode config in xe_display_flush_cleanup_work(), leading to a NULL
pointer dereference, and generally calls display code with display info
cleared.
Check for intel_display_device_present() after
intel_display_device_info_runtime_init(), and reset
xe->info.probe_display as necessary. Also do unset_display_features()
for completeness, although display runtime init has already done
that. This will need to be unified across all cases later.
Move intel_display_device_info_runtime_init() call slightly earlier,
similar to i915, to avoid a bunch of unnecessary setup for no display
cases.
Note #1: The xe driver has no business doing low level display plumbing
like for_each_intel_crtc() to begin with. It all needs to happen in
display code.
Note #2: The actual bug is present already in commit 44e694958b
("drm/xe/display: Implement display support"), but the oops was likely
introduced later at commit ddf6492e0e ("drm/xe/display: Make display
suspend/resume work on discrete").
Fixes: 44e694958b ("drm/xe/display: Implement display support")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7904
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/6150
Cc: stable@vger.kernel.org # v6.8+
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260515160920.1082842-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Instead of updating drm_driver.driver_features in the runtime, we
can use macro which value depends on the CONFIG_DRM_XE_DISPLAY.
And if display support is later disabled by the xe_modparam then we
will clear related bits in the drm_device.driver_features instead.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260512183342.3374-6-michal.wajdeczko@intel.com
Instead of updating the drm_driver.fbdev_probe field in the runtime,
we can use macro which value depends on the actual Kconfig setup.
The .fbdev_probe hook will not be used by the drm core unless we
also enable a DRIVER_MODESET driver feature flag, and this flag
still depends on the xe_modparam.probe_display parameter.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260512183342.3374-5-michal.wajdeczko@intel.com
There is no need to include xe_device.h in the xe_display.h header.
Include it in the xe_display.c file instead.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260512183342.3374-4-michal.wajdeczko@intel.com
Currently i915 and xe each implement their own versions of
intel_plane_(un)pin(). Now that we have the fb_pin parent
interface we can consolidate this to a single implementation.
The result is a mixture of the i915 and xe implementations.
The reuse_vma() hack comes from xe (and i915 doesn't implement
that part of the parent interface, and the pin_params are
taken from i915 since the platforms supported by i915 need
more things.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-17-ville.syrjala@linux.intel.com
Use xe_fb_pin_ggtt_pin() instead of intel_fb_pin_to_ggtt() for
the initial FB pin. We want to get rid of intel_fb_pin_to_ggtt()
and just use the new fb_pin parent interface.
This still isn't quite the final solution since we bypass the
actual parent interface and call the implementation directly.
But sorting that out will require more cleanup to the initial
FB code.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-16-ville.syrjala@linux.intel.com
Replace the intel_fb_pin_to_ggtt() and intel_fb_unpin_vma() with the
new abstract parent interface (intel_parent_fb_pin_ggtt_(un)pin()).
xe no longer needs intel_fb_unpin_vma(), and in i915 it now
becomes and internal function to i915_fb_pin.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-15-ville.syrjala@linux.intel.com
Introduce the main part of the new fb_pin parent interface:
- intel_parent_fb_pin_ggtt_(un)pin()
- intel_parent_fb_pin_dpt_(un)pin()
- intel_parent_fb_pin_reuse_vma()
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-14-ville.syrjala@linux.intel.com
Restructure reuse_vma() into a form that doesn't need the plane
state structs, and rename the result to xe_fb_pin_reuse_vma().
This will become the new fb_pin parent interface.
v2: Fix memcmp() arguments
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-13-ville.syrjala@linux.intel.com
Extract the inner DPT parts of intel_plane_(un)pin() into the
xe_fb_pin_ggtt_(un)pin(). These will become part of the new
fb_pin parent interface.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-12-ville.syrjala@linux.intel.com
Extract the inner DPT parts of intel_plane_(un)pin() into the
xe_fb_pin_dpt_(un)pin(). These will become part of the new
fb_pin parent interface.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-11-ville.syrjala@linux.intel.com
Move most of the plane state stuff out from the inner parts
of intel_plane_pin_fb(). The plan is to take those inner parts and
abstract them into the new fb_pin parent interface, and we don't
want any plane_state stuff there.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-10-ville.syrjala@linux.intel.com
This fbdev vma reuse hacks is a massive layering violation. It
really does not belong in the fb pinning code. And it's in the
way of properly abstracting this stuff, so kill it.
I don't think this hack even does anything useful because the
normal view will just use bo->ggtt_node when present, and the
fbdev bo will be permanenly pinned with xe_bo_create_pin_map_at_novm()
which does set up bo->ggtt_node. So we should never end up
rebuilding the PTEs for the fbdev bo, even without the reuse hack.
v2: Pimp the commit message a a bit (Jani)
v3: Also nuke intel_fbdev_vma_pointer()
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-9-ville.syrjala@linux.intel.com
No need to bother the higher level pinning code with the
FORCE_WC assert. Move it into the lower level function.
This also introduces the check to intel_fb_pin_to_ggtt(), which
(for the moment) is still used for the fbdev bo setup. But this
is all display stuff we're talking about here so having the check
is correct everywhere.
v2: Pimp the commit message a bit (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-8-ville.syrjala@linux.intel.com
Introduce the "fb_pin" parent interface, as the first trivial step
move the *_get_map() stuff there.
The whole "fb_pin" as an interface might not really make sense,
and perhaps this (and other stuff) should just be collected into
some kind of "bo" interface. But let's go with "fb_pin" for now
to match where things are implemented, and possibly restructure
it later.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-2-ville.syrjala@linux.intel.com
Stolen memory requires physically contiguous allocations for display
scanout and compressed framebuffers. The stolen memory manager was
sharing the gpu_buddy allocator backend with the VRAM manager, but
buddy manages non-contiguous power-of-two blocks making it a poor fit.
Stolen memory also has fundamentally different allocation patterns:
- Allocation sizes are not power-of-two. Since buddy rounds up to the
next power-of-two block size, a ~17MB request can fail even with
~22MB free, because the free space is fragmented across non-fitting
power-of-two blocks.
- Hardware restrictions prevent using the first 4K page of stolen for
certain allocations (e.g., FBC). The display code sets fpfn=1 to
enforce this, but when fpfn != 0, gpu_buddy enables
GPU_BUDDY_RANGE_ALLOCATION mode which disables the try_harder
coalescing path, further reducing allocation success.
This combination caused FBC compressed framebuffer (CFB) allocation
failures on platforms like NVL/PTL. In case of NVL where stolen memory
is ~56MB and the initial plane framebuffer consumes ~34MB at probe time,
leaving ~22MB for subsequent allocations.
Use ttm_range_man_init_nocheck() to set up a drm_mm-backed TTM resource
manager for stolen memory. This reuses the TTM core's ttm_range_manager
callbacks, avoiding duplicate implementations.
Tested on NVL with a 4K DP display: stolen_mm shows a single ~22MB
contiguous free hole after initial plane framebuffer allocation, and
FBC successfully allocates its CFB from that region. The corresponding
IGT was previously skipped and now passes.
v2:
- Clarify that stolen memory requires contiguous allocations (Matt B)
- Properly handle xe_ttm_resource_visible() for stolen instead of
unconditionally returning true (Matt A)
v3:
- Rebase
- Fix xe_display_bo_fbdev_prefer_stolen() to compare in pages, since
ttm_range_manager stores stolen->size in pages not bytes (Matt A)
v4:
- Add kernel-doc for struct xe_ttm_stolen_mgr (Matt B)
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7631
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Assisted-by: GitHub Copilot:claude-sonnet-4.6
Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260422125502.3088222-2-sanjay.kumar.yadav@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fix __xe_pin_fb_vma_ggtt() to actually respect the GGTT alignment
specified by the display code. Misalignment can cause GTT faults
etc.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260430154602.11393-2-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Instead of just looking at the first plane use the fb cached overall
minimum alignment.
This aligns with how the i915 version of intel_plane_pin_fb works.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
[vsyrjala: Rebase due to pin_params]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260430154602.11393-1-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
- Debugfs multi-LRC engine info (Xin Wang, 2 commits)
Expose multi-LRC engine classes in the debugfs engine info output
and improve the output readability.
- drm/drm_ras: Add clear-error-counter netlink command to drm_ras
Cross-subsystem Changes:
Core Changes:
- drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges
- drm/i915/display: switch to including common step file directly
Driver Changes:
- Engine initialization cleanup (Matt Roper, 10 commits)
Clean up engine initialization code inherited from i915 by moving
hardware programming (CCS enablement, HWSTAM, GFX_MODE, BLIT_CCTL,
STOP_RING) into the RTP infrastructure. This makes the programming
visible and verifiable via debugfs, and applies consistently across
both normal and execlist init paths. Also fixes the name/definition
of GFX_MODE, marks BCS engines as belonging to the GT forcewake
domain, and drops the now-unused xe_hw_engine_mmio_write32() helper.
- PF fair scheduling auto-provisioning (Michal Wajdeczko, 13 commits)
Fix several corner cases in SR-IOV PF scheduling policy provisioning,
then auto-provision PF and all VFs with 16ms execution-quantum and
preemption-timeout defaults. This prevents a VF from monopolizing
the GPU by submitting workloads without gaps, without requiring the
user to configure sysfs manually.
- System Controller support for CRI/Xe3p (Anoop Vijay + Raag Jadav, 10 commits)
Add xe_sysctrl infrastructure for communicating with the System
Controller firmware entity on CRI/Xe3p discrete GPU platforms via a
mailbox interface. Includes type definitions, register definitions,
mailbox communication, initialization, power management, interrupt
handling, and event dispatch. Builds on this to add initial RAS
correctable error handling, using sysctrl interrupts to receive
threshold-crossed events.
- PXP state machine fixes (Daniele Ceraolo Spurio, 4 commits)
Fix PXP state machine handling: reject PXP sessions on PTL platforms
with older GSC firmware that does not support it, fix the restart
flag not being cleared after jumping back in pxp_start, remove
incorrect handling of an impossible state during suspend, and clean
up termination status on failure.
- Reset/wedge/unload corner case fixes (Zhanjun Dong + Matthew Brost, 5 commits)
Fix memory leaks and fence signal failures that occurred during GPU
reset, device wedging, and driver unload by forcefully tearing down
remaining exec queues in GuC submit fini, always killing queues in
pause/abort, and triggering queue cleanup when not in wedged mode 2.
Also ensures GuC CT state transitions via STOP before DISABLED.
- Wedge path memory allocation fixes (Matthew Brost, 3 commits)
Avoid GFP_KERNEL allocations in xe_device_declare_wedged(), which
runs in the DMA-fence signaling path. Also drops the
guc_submit_wedged_fini devm registration from xe_guc_submit_wedge()
to clean up the wedge shutdown sequence.
- PAT type cleanup and invalid index hardening (Xin Wang, 3 commits)
Standardize pat_index fields to u16 across the driver, default
XE_CACHE_NONE_COMPRESSION to XE_PAT_INVALID_IDX (matching
WB_COMPRESSION), and introduce xe_cache_pat_idx() — a macro helper
that validates cache_mode bounds and asserts on invalid PAT indices
before returning the index.
- Reject unsafe PAT indices for CPU cached memory (Jia Yao, 2 commits)
Reject incoherent (coh_none) PAT indices for CPU cached memory in
both the madvise ioctl and vm_bind with CPU_ADDR_MIRROR flag, closing
a security gap where the GPU could bypass CPU caches and observe
stale or sensitive data.
- OA improvements for CRI device memory (Ashutosh Dixit, 3 commits)
Move OA buffer access to the xe_map layer to support both system and
device memory (required for CRI), switch OA buffer mmap to use
drm_gem_mmap_obj, and implement workaround Wa_14026633728.
- xe_drm.h documentation fixes (Shuicheng Lin, 6 commits)
Fix multiple documentation issues in the xe_drm.h UAPI header:
typos, spelling errors, grammar, wrong names and references,
kernel-doc cross-reference syntax, and broken code examples.
- kernel-doc syntax fixes in xe headers (Shuicheng Lin, 4 commits)
Fix kernel-doc syntax issues across xe header files: missing '@'
prefixes on member tags, stale/mismatched member tags, comment
syntax errors, and type/parameter name mismatches in references.
- Buffer object and DMA-buf resource leak fixes (Shuicheng Lin, 4 commits)
Fix resource leaks on error paths: DMA-buf attachment leak in
xe_gem_prime_import(), BO leak in xe_dma_buf_init_obj() on
allocation failure, and BO leaks in xe_bo_init_locked() on GGTT
flag validation and unaligned size validation failures.
- Include guard cleanup (Shuicheng Lin, 5 commits)
Fix and standardize include guards across xe header files: normalize
double-underscore guards to single, add missing leading/trailing
underscores, add missing _H suffixes, and add guards to previously
unprotected headers.
- VF CCS memory pool (Satyanarayana K V P, 2 commits)
Switch VF CCS read/write operations from the DRM sub-allocator to
DRM mm, fixing allocation failures in fence-disabled mode where
the sub-allocator's hole cursor assumption breaks. Also introduces
a general BO-backed memory pool with shadow support using drm_mm.
- i915/xe step definition unification (Jani Nikula, 3 commits)
Complete the migration to the shared intel_step header: switch xe
from its own xe_step enum to the shared intel_step naming and
definitions, and update i915 display code to include the common
step header directly.
- Xe3p GT tuning fixes (3 commits)
Three Xe3p GT tuning corrections: fix the register offset for
GAMSTLB_CTRL, stop applying the CCCHKNREG1 tuning from Xe3p onward
(no longer needed), and mark ROW_CHICKEN5 as a masked register.
- Forcewake cleanup in GT and GuC PC (Raag Jadav, 3 commits)
Drop a redundant forcewake reference in xe_gt, reorder forcewake
usage in xe_guc_pc_fini_hw() to avoid a redundant hold, and convert
xe_guc_pc_stop() to void since it can no longer fail.
- SVM garbage collector fix on close (Matthew Brost, 2 commits)
Disable the SVM garbage collector work item when an SVM is closed
to prevent use-after-free when the GC fires after the SVM is freed.
- Admin-only PF mode (Satyanarayana K V P, 2 commits)
Derive an "admin-only PF" mode flag from xe_device state instead of
using a local flag, and restrict device query responses when running
in admin-only PF mode to avoid exposing internal state.
- Enable hwmon energy attributes and accepted power limit for CRI (2 commits)
Enable energy consumption hwmon attributes for the CRI platform and
add support for reading the accepted (sustained) power limit via
hwmon.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRskUM7w1oG5rx2IZO4FpNVCsYGvwUCafNROQAKCRC4FpNVCsYG
v31cAQCS/7wH9kwyUxQZOgs/HfuZvbgu5IyrGxaDSrHY7twRtAD7BhvkfOcyB9VK
6M2a7Y+QiVICgwjuDiwXikJalmRBmQE=
=Y9j3
-----END PGP SIGNATURE-----
Merge tag 'drm-xe-next-2026-04-30' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next
UAPI Changes:
- Debugfs multi-LRC engine info (Xin Wang, 2 commits)
Expose multi-LRC engine classes in the debugfs engine info output
and improve the output readability.
- drm/drm_ras: Add clear-error-counter netlink command to drm_ras
Cross-subsystem Changes:
Core Changes:
- drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges
- drm/i915/display: switch to including common step file directly
Driver Changes:
- Engine initialization cleanup (Matt Roper, 10 commits)
Clean up engine initialization code inherited from i915 by moving
hardware programming (CCS enablement, HWSTAM, GFX_MODE, BLIT_CCTL,
STOP_RING) into the RTP infrastructure. This makes the programming
visible and verifiable via debugfs, and applies consistently across
both normal and execlist init paths. Also fixes the name/definition
of GFX_MODE, marks BCS engines as belonging to the GT forcewake
domain, and drops the now-unused xe_hw_engine_mmio_write32() helper.
- PF fair scheduling auto-provisioning (Michal Wajdeczko, 13 commits)
Fix several corner cases in SR-IOV PF scheduling policy provisioning,
then auto-provision PF and all VFs with 16ms execution-quantum and
preemption-timeout defaults. This prevents a VF from monopolizing
the GPU by submitting workloads without gaps, without requiring the
user to configure sysfs manually.
- System Controller support for CRI/Xe3p (Anoop Vijay + Raag Jadav, 10 commits)
Add xe_sysctrl infrastructure for communicating with the System
Controller firmware entity on CRI/Xe3p discrete GPU platforms via a
mailbox interface. Includes type definitions, register definitions,
mailbox communication, initialization, power management, interrupt
handling, and event dispatch. Builds on this to add initial RAS
correctable error handling, using sysctrl interrupts to receive
threshold-crossed events.
- PXP state machine fixes (Daniele Ceraolo Spurio, 4 commits)
Fix PXP state machine handling: reject PXP sessions on PTL platforms
with older GSC firmware that does not support it, fix the restart
flag not being cleared after jumping back in pxp_start, remove
incorrect handling of an impossible state during suspend, and clean
up termination status on failure.
- Reset/wedge/unload corner case fixes (Zhanjun Dong + Matthew Brost, 5 commits)
Fix memory leaks and fence signal failures that occurred during GPU
reset, device wedging, and driver unload by forcefully tearing down
remaining exec queues in GuC submit fini, always killing queues in
pause/abort, and triggering queue cleanup when not in wedged mode 2.
Also ensures GuC CT state transitions via STOP before DISABLED.
- Wedge path memory allocation fixes (Matthew Brost, 3 commits)
Avoid GFP_KERNEL allocations in xe_device_declare_wedged(), which
runs in the DMA-fence signaling path. Also drops the
guc_submit_wedged_fini devm registration from xe_guc_submit_wedge()
to clean up the wedge shutdown sequence.
- PAT type cleanup and invalid index hardening (Xin Wang, 3 commits)
Standardize pat_index fields to u16 across the driver, default
XE_CACHE_NONE_COMPRESSION to XE_PAT_INVALID_IDX (matching
WB_COMPRESSION), and introduce xe_cache_pat_idx() — a macro helper
that validates cache_mode bounds and asserts on invalid PAT indices
before returning the index.
- Reject unsafe PAT indices for CPU cached memory (Jia Yao, 2 commits)
Reject incoherent (coh_none) PAT indices for CPU cached memory in
both the madvise ioctl and vm_bind with CPU_ADDR_MIRROR flag, closing
a security gap where the GPU could bypass CPU caches and observe
stale or sensitive data.
- OA improvements for CRI device memory (Ashutosh Dixit, 3 commits)
Move OA buffer access to the xe_map layer to support both system and
device memory (required for CRI), switch OA buffer mmap to use
drm_gem_mmap_obj, and implement workaround Wa_14026633728.
- xe_drm.h documentation fixes (Shuicheng Lin, 6 commits)
Fix multiple documentation issues in the xe_drm.h UAPI header:
typos, spelling errors, grammar, wrong names and references,
kernel-doc cross-reference syntax, and broken code examples.
- kernel-doc syntax fixes in xe headers (Shuicheng Lin, 4 commits)
Fix kernel-doc syntax issues across xe header files: missing '@'
prefixes on member tags, stale/mismatched member tags, comment
syntax errors, and type/parameter name mismatches in references.
- Buffer object and DMA-buf resource leak fixes (Shuicheng Lin, 4 commits)
Fix resource leaks on error paths: DMA-buf attachment leak in
xe_gem_prime_import(), BO leak in xe_dma_buf_init_obj() on
allocation failure, and BO leaks in xe_bo_init_locked() on GGTT
flag validation and unaligned size validation failures.
- Include guard cleanup (Shuicheng Lin, 5 commits)
Fix and standardize include guards across xe header files: normalize
double-underscore guards to single, add missing leading/trailing
underscores, add missing _H suffixes, and add guards to previously
unprotected headers.
- VF CCS memory pool (Satyanarayana K V P, 2 commits)
Switch VF CCS read/write operations from the DRM sub-allocator to
DRM mm, fixing allocation failures in fence-disabled mode where
the sub-allocator's hole cursor assumption breaks. Also introduces
a general BO-backed memory pool with shadow support using drm_mm.
- i915/xe step definition unification (Jani Nikula, 3 commits)
Complete the migration to the shared intel_step header: switch xe
from its own xe_step enum to the shared intel_step naming and
definitions, and update i915 display code to include the common
step header directly.
- Xe3p GT tuning fixes (3 commits)
Three Xe3p GT tuning corrections: fix the register offset for
GAMSTLB_CTRL, stop applying the CCCHKNREG1 tuning from Xe3p onward
(no longer needed), and mark ROW_CHICKEN5 as a masked register.
- Forcewake cleanup in GT and GuC PC (Raag Jadav, 3 commits)
Drop a redundant forcewake reference in xe_gt, reorder forcewake
usage in xe_guc_pc_fini_hw() to avoid a redundant hold, and convert
xe_guc_pc_stop() to void since it can no longer fail.
- SVM garbage collector fix on close (Matthew Brost, 2 commits)
Disable the SVM garbage collector work item when an SVM is closed
to prevent use-after-free when the GC fires after the SVM is freed.
- Admin-only PF mode (Satyanarayana K V P, 2 commits)
Derive an "admin-only PF" mode flag from xe_device state instead of
using a local flag, and restrict device query responses when running
in admin-only PF mode to avoid exposing internal state.
- Enable hwmon energy attributes and accepted power limit for CRI (2 commits)
Enable energy consumption hwmon attributes for the CRI platform and
add support for reading the accepted (sustained) power limit via
hwmon.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
Link: https://patch.msgid.link/afNSeZJHC3X2m3-N@fedora
When media GT is disabled via configfs, there is no allocation for
media_gt, which is kept as NULL. In such scenario,
intel_hdcp_gsc_check_status() results in a kernel pagefault error due to
>->uc.gsc being evaluated as an invalid memory address.
Fix that by introducing a NULL check on media_gt and bailing out early
if so.
While at it, also drop the NULL check for gsc, since it can't be NULL if
media_gt is not NULL.
v2:
- Get address for gsc only after checking that gt is not NULL.
(Shuicheng)
- Drop the NULL check for gsc. (Shuicheng)
v3:
- Add "Fixes" and "Cc: <stable...>" tags. (Matt)
Fixes: 4af50beb4e ("drm/xe: Use gsc_proxy_init_done to check proxy status")
Cc: <stable@vger.kernel.org> # v6.10+
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260416-check-for-null-media_gt-in-intel_hdcp_gsc_check_status-v2-1-9adb9fd3b621@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Wrap pat.idx[] reads with xe_cache_pat_idx() so invalid PAT index use
is caught by xe_assert() in debug builds.
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260416045526.536497-4-x.wang@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Now that we have the pin_params the low level pinning code no
longer needs the entire framebuffer structure. The gem object
alone (along with the pin_params) is enough.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-12-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Move the intel_fb_uses_dpt() out from __xe_pin_fb_vma() into
intel_plane_pin_fb() so that we don't do have display stuff
that deep in the pinning code.
And intel_fb_pin_to_ggtt() can just say "this does not need DPT"
always since it's specifically about pinning the fb into GGTT.
The previous logic here was kinda insane with the high level code
assuming GGTT, and low level code potentially deciding otherwise.
In practice it should have been fine because intel_fb_pin_to_ggtt()
only gets used from the initial_plane code, and there we are
not supposed to be have a framebuffer that needs DPT.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Add a new flag pin_params.neeeds_cpu_lmem_access so that the
low level pinning code doesn't need to peek into the display
driver's framebuffer structure.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Replace the naked "does the framebuffer have a clear color
plane?" checks with a more abstract helper that simply tells
us whether we require CPU access to the framebuffer's memory.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We need to pass a lot of information between the display driver
and the core driver to get framebuffers mapped into GGTT/DPT
correctly. Rather than passing around a swarm of integers and
boolean as function arguments, let's collect it all into a
structure (struct intel_fb_pin_params).
Start by moving the gtt view, alignment, phys_alignment,
and vtd_guard there. Going forward additional things need
to added as well (mainly various boolean flags).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Use the proper gtt view from the plane state rather than always
assuming that it came directly from the FB. This is in the DPT
codepath so the view should currently always come from the FB,
but in the future we may also want per-plane remapping with DPT.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-2-ville.syrjala@linux.intel.com
Don't leave a stale xe->display pointer hanging around after
the display driver has been torn down.
While xe shouldn't hit the display reset related issue that
affects i915, leaving stale pointer floating around still
seems like a bad idea.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Get rid of the needlessly complicated PLANE_HAS_FENCE +
intel_parent_vma_fence_id() dance by simply tracking the
fence_id directly in the plane state.
v2: Don't request the redundant fence for fbdev (Jani)
Assign *out_fence_id with '=' instead of '|=' (Sashiko,Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407170942.16515-1-ville.syrjala@linux.intel.com
The initial plane vblank wait operates on display registers,
so it really belongs in the display code proper. Move it there.
We can use intel_parent_irq_enabled() to determine if we can
rely on interrupts or not.
On average we should end up waiting half a frame here, so the
polling interval can be fairly long. 1 ms (which actually
makes poll_timeout_us() use ~250-1000 usec) seems good enough
to me.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
There's no need to use the intel specific struct intel_framebuffer*
type in the initial plane_config structure. Just make it a
struct drm_framebuffer*.
I think the fewer special types we expose in the interface (even
if just pointers) the better. At least then there is no need to
change the interface definition if we ever change the internal
types. And I hope that the existing examples will generally
encourage people to not expose more special types unless
absolutely necessary.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Currently our crtcs are registered in pipe order, and thus
all the for_intel_crtc*() iterators walk the crtcs in pipe
order. There are a bunch of places that more or less depend
on that. Eg. during plane updates and such we want joined
pipes to be processed back-to-back to give a better chance
of an atomic update across the whole set.
When we start to register crtcs in a different order we don't
want to change the order in which the pipes get handled.
Decouple the for_each_intel_crtc*() iterators from the crtc
registration order by using a separate list which will be
sorted by the pipe rather than the crtc index.
We could probably use a simple array or something, but that
would require some kind of extra iterator variable for the
macros, and thus would require a lot more changes. Using
a linked list keeps the fallout minimal. We can look at
using a more optimal data structure later.
I also added this extra junk to the atomic state iterators:
"(__i) = drm_crtc_index(&(crtc)->base), (void)(__i)"
even though the macro itself no longer needs the "__i" iterator.
This in case the "__i" is used by the caller, and to
avoid compiler warnings if it's completely unused now.
v2: Flip the pipe comparison (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260408155744.13326-3-ville.syrjala@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move the driver specific fbdev fb calls to the display parent
interface. Reuse the existing struct intel_display_bo_interface, as this
is mostly about gem objects.
Put everything behind IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) to catch
configuration issues at build or link time.
v2: Rebase
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1
Link: https://patch.msgid.link/a6bb24909a58181cfc41b91a4c6538a181d27158.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The struct drm_device *drm parameter of intel_fbdev_fb_fill_info() is
redundant, as you can obtain the same information via obj->dev. Drop the
drm parameter, and move obj as first (or the context) parameter.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/6c617dc41c07b0e3e9af01b82d0d1dadbd4760fc.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Unify the behaviour with i915. Similar to commit b63c6b9b7f
("drm/i915/fbdev: fix link failure without FBDEV emulation"). The
difference is that unlike i915, xe doesn't build
display/intel_fbdev_fb.c conditional to CONFIG_DRM_FBDEV_EMULATION.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/245880a591fe5267a1c06bfbbcc42a4dd9f2e4ee.1774950508.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
