summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/xe
AgeCommit message (Collapse)Author
2026-05-14drm/xe/display: Add macro with display driver opsMichal Wajdeczko
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
2026-05-14drm/xe/display: Prefer forward declarationsMichal Wajdeczko
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
2026-05-14drm/xe/display: Drop xe_display_driver_remove() stubMichal Wajdeczko
The function was removed by commit d41d048043c4 ("drm/xe/display: Drop xe_display_driver_remove()") but we missed to remove its stub. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260512183342.3374-3-michal.wajdeczko@intel.com
2026-05-14drm/xe: Drop unused drm/drm_atomic_helper.h includeMichal Wajdeczko
We don't need this header in xe_device.c file. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260512183342.3374-2-michal.wajdeczko@intel.com
2026-05-14drm/xe/sriov: Mark NVL as SR-IOV capableJakub Kolakowski
Enable SR-IOV support for NVL platforms. Signed-off-by: Jakub Kolakowski <jakub1.kolakowski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://patch.msgid.link/20260331152259.58270-1-jakub1.kolakowski@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-05-14drm/xe/gt_idle: Use NSEC_PER_MSEC instead of float literalShuicheng Lin
The residency multiplier conversion in get_residency_ms() used the floating-point literal 1e6 as the divisor of mul_u64_u32_div(). While the compiler constant-folds this to an integer, using float literals in kernel code is bad practice since the kernel generally avoids floating-point operations. Replace 1e6 with the standard NSEC_PER_MSEC macro from <linux/time64.h>, which is both self-documenting (ns to ms conversion) and unambiguously integer. Add the corresponding include rather than relying on transitive inclusion. No functional change. Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20260511153307.223435-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-05-14drm/xe/gsc: Fix double-free of managed BO in error pathShuicheng Lin
The error path in xe_gsc_init_post_hwconfig() explicitly frees a BO allocated with xe_managed_bo_create_pin_map() via xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm cleanup action registered, this causes a double-free when devm unwinds during probe failure. Remove the explicit free and let devm handle it, consistent with all other xe_managed_bo_create_pin_map() callers. Fixes: 2e5d47fe7839 ("drm/xe/uc: Use managed bo for HuC and GSC objects") Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Assisted-by: Claude:claude-opus-4.6 Link: https://patch.msgid.link/20260511154134.223696-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-05-13drm/xe/memirq: Enable GT_MI_USER_INTERRUPT onlyMichal Wajdeczko
We only expect and handle the GT_MI_USER_INTERRUPT from the engines, there is no point in enabling other interrupts, like GT_CONTEXT_SWITCH_INTERRUPT, if we don't intent to handle them. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260511172838.2299-3-michal.wajdeczko@intel.com
2026-05-13drm/xe/memirq: Update interrupt handler logicMichal Wajdeczko
To workaround some corner case hardware limitations, new programming note for the memory based interrupt handler suggests to assume that some status bytes, like GT_MI_USER_INTERRUPT and GUC_INTR_GUC2HOST, are always set. Update our interrupt handler to follow the new rules. Bspec: 53672 Fixes: a6581ebe7685 ("drm/xe/vf: Introduce Memory Based Interrupts Handler") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260511172838.2299-2-michal.wajdeczko@intel.com
2026-05-13drm/xe: Drop unused ggtt_balloon fieldMichal Wajdeczko
During recent GGTT refactoring we missed to drop now unused field from the xe_tile. Drop it now. Fixes: e904c56ba6e0 ("drm/xe: Rewrite GGTT VF initialization") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20260510205605.642-1-michal.wajdeczko@intel.com
2026-05-13drm/xe: Refactor emit_xy_fast_copy and emit_mem_copy functionsBalasubramani Vivekanandan
To perform copy, based on whether the platform supports service copy engines, either MEM_COPY or XY_FAST_COPY_BLT instruction is used. Length of both the instructions is same today and so they use a common define EMIT_COPY_DW. This is not true for the future platforms. Implement separate functions which return the length of the instruction to help in preparing for it. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260511123746.616662-8-balasubramani.vivekanandan@intel.com Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
2026-05-13drm/xe: Refactor emit_clear_link_copyBalasubramani Vivekanandan
Implement a function to return the length of the MEM_SET instruction. This is to prepare for future platforms where the length of MEM_SET instruction is expected to change. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260511123746.616662-7-balasubramani.vivekanandan@intel.com Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
2026-05-13drm/xe: Refactor emit_clear_main_copyBalasubramani Vivekanandan
Implement a function which returns the length of XY_FAST_COLOR_BLT instruction instead of hardcoding it inside the emit_clear_main_copy. In future platforms, the length of this instruction is expected to change and this patch helps in preparing for it. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260511123746.616662-6-balasubramani.vivekanandan@intel.com Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
2026-05-13drm/xe/devcoredump: Drop a FIXME in devcoredumpShekhar Chauhan
The FIXME says that xe_engine_snapshot_print.. is accessing persistent driver data, unlike what the FIXME says that it does. Drop the FIXME since the current code is not going to access the hardware while dumping. More details about this patch: https://patchwork.freedesktop.org/patch/703884/?series=161407&rev=1 The starting two feedbacks make sense and the original patch is wrong in adding those changes, but the last feedback is the one which highlights the point. Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20260512055508.1380191-1-shekhar.chauhan@intel.com Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
2026-05-12drm/xe/oa: MERTOA Wa_14026779378Ashutosh Dixit
Do not allow SYS_MEM_LAT_MEASURE_EN bit to be set in SYS_MEM_LAT_MEASURE register. Doing so can cause memory corruption. Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260430161459.2892545-5-ashutosh.dixit@intel.com
2026-05-12drm/xe/oa: Add val arg to xe_oa_is_valid_config_regAshutosh Dixit
Add val arg to xe_oa_is_valid_config_reg so that register values can also be verified, in addition to register address. Value verification is needed to implement MERTOA Wa_14026779378. Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260430161459.2892545-4-ashutosh.dixit@intel.com
2026-05-12drm/xe/oa: MERTOA Wa_14026746987Ashutosh Dixit
Wa_14026746987 implies that only XE_OAM_FORMAT_MPEC8u32_B8_C8 and not XE_OAM_FORMAT_MPEC8u64_B8_C8 can be supported for MERTOA unit. Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260430161459.2892545-3-ashutosh.dixit@intel.com
2026-05-12drm/xe/oa: Refactor oa_unit_supports_oa_formatAshutosh Dixit
Minor refactor of oa_unit_supports_oa_format to implement Wa_14026746987. Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260430161459.2892545-2-ashutosh.dixit@intel.com
2026-05-11drm/i915: Consolidate the intel_plane_(un)pin_fb() implementationsVille Syrjälä
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
2026-05-11drm/xe: Use xe_fb_pin_ggtt_pin() for the initial FB pinVille Syrjälä
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
2026-05-11drm/i915/fbdev: Use intel_parent_fb_pin_ggtt_(un)pin()Ville Syrjälä
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
2026-05-11drm/i915: Introduce the main fb_pin parent interfaceVille Syrjälä
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
2026-05-11drm/xe: Restructure reuse_vma()Ville Syrjälä
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
2026-05-11drm/xe: Introduce xe_fb_pin_ggtt_(un)pin()Ville Syrjälä
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
2026-05-11drm/xe: Introduce xe_fb_pin_dpt_(un)pin()Ville Syrjälä
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
2026-05-11drm/xe: Reorganize intel_plane_pin_fb() a bitVille Syrjälä
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
2026-05-11drm/xe: Kill the fbdev vma reuse hackVille Syrjälä
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
2026-05-11drm/xe: Move the FORCE_WC assert into __xe_pin_fb_vma()Ville Syrjälä
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
2026-05-11drm/i915: Introduce intel_parent_fb_pin_get_map()Ville Syrjälä
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
2026-05-11drm/xe/dma-buf: fix UAF with retry loopMatthew Auld
Retry doesn't work here, since bo will be freed on error, leading to UAF. However, now that we do the alloc & init before the attach, we can now combine this as one unit and have the init do the alloc for us. This should make the retry safe. Reported by Sashiko. v2: Fix up the error unwind (CI) Closes: https://sashiko.dev/#/patchset/20260506184332.86743-2-matthew.auld%40intel.com Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction") 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: <stable@vger.kernel.org> # v6.18+ Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260508102635.149172-4-matthew.auld@intel.com
2026-05-11drm/xe/dma-buf: handle empty bo and UAF racesMatthew Auld
There look to be some nasty races here when triggering the invalidate_mappings hook: 1) We do xe_bo_alloc() followed by the attach, before the actual full bo init step in xe_dma_buf_init_obj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidate_mappings hook, with an empty/bogus bo, leading to potential bugs/crashes. 2) Similar to 1) but here we get a UAF, when the invalidate_mappings hook is triggered. For example, we get as far as xe_bo_init_locked() but this fails in some way. But here the bo will be freed on error, but we still have it attached from dma-buf pov, so if the invalidate_mappings is now triggered then the bo we access is gone and we trigger UAF and more bugs/crashes. To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to. We have at least two different customers reporting hitting a NULL ptr deref in evict_flags when importing something from amdgpu, followed by triggering the evict flow. Hit rate is also pretty low, which would hint at some kind of race, so something like 1) or 2) might explain this. v2: - Shuffle the order of the ops slightly (no functional change) - Improve the comment to better explain the ordering (Matt B) Assisted-by: Gemini:gemini-3 #debug Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7903 Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/4055 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") 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: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260508102635.149172-3-matthew.auld@intel.com
2026-05-08drm/xe/multi_queue: Whitelist QUEUE_TIMESTAMP registerUmesh Nerlige Ramappa
In a multi-queue use case, when a job is running on the secondary queue, the CTX_TIMESTAMP does not reflect the queues run ticks. Instead, we use the QUEUE TIMESTAMP to check how long the job ran. For user space to see the run ticks for a secondary queue, whitelist the QUEUE_TIMESTAMP register. Compute PR: https://github.com/intel/compute-runtime/pull/923 Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-24-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Use QUEUE_TIMESTAMP as job timestamp for multi-queueUmesh Nerlige Ramappa
Each queue in a multi queue group has a dedicated timestamp counter. Use this QUEUE TIMESTAMP register to capture the start timestamp for the job. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-23-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Add trace event for the multi queue timestampUmesh Nerlige Ramappa
Add a trace event for multi queue timestamp capture. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-22-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Capture queue run times for active queuesUmesh Nerlige Ramappa
If a queue is currently active on the CS, query the QUEUE TIMESTAMP register to get an up to date value of the runtime. To do so, ensure that the primary queue is active and then check if the secondary queue is executing on the CS. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-21-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/lrc: Refactor out engine id to hwe conversionUmesh Nerlige Ramappa
We need to define more helpers that read engine ID specific register, so move that logic outside of get_ctx_timestamp(). Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-20-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Add helpers to access CS QUEUE TIMESTAMP from lrcUmesh Nerlige Ramappa
In secondary queue LRCs, the QUEUE TIMESTAMP register is saved and restored allowing us to view the individual queue run times. Add helpers to read this value from the LRC. BSpec: 73988 Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-19-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Store primary LRC and position info in LRCUmesh Nerlige Ramappa
For an LRC belonging to the secondary queue, in order to check if its context group is active, we need to check the LRC of the primary queue. In addition to that we want to compare the secondary queue position to CSMQDEBUG register to check if the queue itself is active. To do so, store primary LRC and position information in the LRC. A note on references involved: - In general the Queue takes a ref on its LRC. - In addition, for multi-queue, a. Primary Queue takes a ref for each Secondary LRC. b. Each Secondary Queue takes a ref to the Primary Queue In the current patch, each LRC in the queue group is storing a pointer to primary LRC. Both primary and secondary LRCs are freed only when primary queue is destroyed. At this time, all secondary queues are already destroyed, so there is no one using secondary LRCs. We should be good without taking any additional references. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-18-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/multi_queue: Refactor check for multi queue support for engine classUmesh Nerlige Ramappa
xe exec queue code is using a check to see if a class of engines support multi queue. This check is also needed by other code, so move it to xe_gt and export it for others. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-17-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/lrc: Refactor xe_lrc_timestamp to simplify logicUmesh Nerlige Ramappa
Use a context_active() helper and simplify the timestamp logic. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-16-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe: Add timestamp_ms to LRC snapshotMatthew Brost
Add a timestamp in milliseconds to the LRC snapshot to make it easier to reason about how long the LRC has been running and the average duration of each job. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-15-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/lrc: Use 64 bit ctx timestamp in the LRC snapshotUmesh Nerlige Ramappa
Use the 64 bit value when available for the context timestamp in the LRC snapshot. Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260507162016.3888309-14-umesh.nerlige.ramappa@intel.com
2026-05-08drm/xe/eustall: Return ENODEV from read if EU stall registers get resetHarish Chegondi
If a reset (GT or engine) happens during EU stall data sampling, all the EU stall registers can get reset to 0. This will result in EU stall data buffers' read and write pointer register values to be out of sync with the cached values. This will result in read() returning invalid data. To prevent this, check the value of a EU stall base register. If it is zero, it indicates a reset may have happened that wiped the register to zero. If this happens, return ENODEV from read() upon which the user space should disable and enable EU stall data sampling or close the fd and open a new fd for a new EU stall data collection session. This patch has been tested by running two IGT tests simultaneously xe_eu_stall and xe_exec_reset. Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Acked-by: Felix Degrood <felix.j.degrood@intel.com> Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/6935698d70b6c7c347ff8b138209d601030c2c9f.1776200094.git.harish.chegondi@intel.com
2026-05-08drm/xe/multi_queue: Refactor CGP_SYNC send pathNiranjana Vishwanathapura
Factor the repeated CGP_SYNC action build-and-send sequence into a new helper guc_exec_queue_send_cgp_sync(). Drop the redundant guc parameter from __register_exec_queue_group() since it can be derived via exec_queue_to_guc(q). Remove xe_guc_exec_queue_group_add() which is now identical to the helper and replace its call site directly. No functional change. Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260508194428.61819-6-niranjana.vishwanathapura@intel.com
2026-05-08drm/xe/multi_queue: Remove redundant assignment in guc_exec_queue_run_jobNiranjana Vishwanathapura
The 'killed_or_banned_or_wedged = true' assignment is redundant since the variable is never read after that point. Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260508194428.61819-5-niranjana.vishwanathapura@intel.com
2026-05-08drm/xe: Make decision to use Xe2-style blitter instructions a feature flagMatt Roper
The blitter engines' MEM_COPY and MEM_SET instructions were added as part of the same hardware change that introduced service copy engines (i.e., BCS1-BCS8) which is why the driver checks for service copy engine presence when deciding whether to use these instructions or the older XY_* instructions. However when making this decision the driver should consider which engines are part of the hardware architecture, not which engines are present/usable on the current device. For graphics IP versions that architecturally include service copy engines (i.e., everything Xe2 and later, plus PVC's Xe_HPC) we should use MEM_SET and MEM_COPY even in if all of the service copy engines wind up getting fused off. I.e., we need to decide based on whether the platform's graphics descriptor contains these engines, rather than whether the usable engine mask contains them. This logic got broken when gt->info.__engine_mask was removed, although in practice that mistake has been harmless so far because there haven't been any hardware SKUs that fuse off all of the service copy engines yet. Replace the incorrect has_service_copy_support() function with a GT feature flag that tracks more accurately whether the new blitter instructions are usable. In addition to fixing incorrect logic if all service copies are fused off, the flag also makes it more obvious what the calling code is trying to do; previously it wasn't terribly obvious why "has service copy engines" was being used as the condition for using different instructions on all copy engine types. The new feature flag is named 'has_xe2_blt_instructions' because we expect this flag to be set for all Xe2 and later platforms (i.e., everything officially supported by the Xe driver). Technically there's also one Xe1-era platform (PVC) that supports these engines/instructions and will set this flag, but this still seems to be the most clear and understandable name for the flag. Fixes: 61549a2ee594 ("drm/xe: Drop __engine_mask") Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20260507-xe2_copy-v1-1-26506381b821@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-05-08drm/xe: Convert stolen memory over to ttm_range_managerSanjay Yadav
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>
2026-05-08Merge drm/drm-next into drm-xe-nextThomas Hellström
Bringing in recent display changes. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-05-08drm/buddy: Integrate lockdep annotations for gpu buddy managerTejas Upadhyay
gpu_buddy APIs are expected to be called with the driver-provided lock held, but there is no runtime enforcement of this contract. Add lockdep annotations to catch locking violations early. Introduce gpu_buddy_driver_set_lock() for the driver to register the lock that protects the buddy manager. Add gpu_buddy_driver_lock_held() assertions to all exported gpu_buddy and drm_buddy APIs that access/modify the manager state. The lock_dep_map field is only compiled in when CONFIG_LOCKDEP is enabled, adding zero overhead to production builds. Wire up xe_ttm_vram_mgr to register its mutex with the buddy manager after initialization. Assisted-by: Copilot:claude-opus-4.6 Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patch.msgid.link/20260508065544.4049240-2-tejas.upadhyay@intel.com
2026-05-08drm/xe/madvise: Track purgeability with BO-local countersArvind Yadav
xe_bo_recompute_purgeable_state() walks all VMAs of a BO to determine whether the BO can be made purgeable. This makes VMA create/destroy and madvise updates O(n) in the number of mappings. Replace the walk with BO-local counters protected by the BO dma-resv lock: - vma_count tracks the number of VMAs mapping the BO. - willneed_count tracks active WILLNEED holders, including WILLNEED VMAs and active dma-buf exports for non-imported BOs. A DONTNEED BO is promoted back to WILLNEED on a 0->1 transition of willneed_count. A BO is demoted to DONTNEED on a 1->0 transition only when it still has VMAs, preserving the previous behaviour where a BO with no mappings keeps its current madvise state. PURGED remains terminal, preserving the existing "once purged, always purged" rule. Fixes: 4f44961eab84 ("drm/xe/vm: Prevent binding of purged buffer objects") v2: - Use early return for imported BOs in all four helpers to avoid nesting (Matt B). - Group purgeability state into a purgeable sub-struct on struct xe_bo (Matt B). - Reword xe_bo_willneed_put_locked() kernel-doc to explain that a 1->0 transition means all remaining active VMAs are DONTNEED (Matt B). v3: - Move DONTNEED/PURGED reject from vma_lock_and_validate() into xe_vma_create(), gated on attr->purgeable_state == WILLNEED. Fixes vm_bind bypass and partial-unbind rejection on DONTNEED BOs (Matt B). - Drop .check_purged from MAP and REMAP; keep it for PREFETCH and add a comment why (Matt B). - Skip BO validation in vma_lock_and_validate() for non-WILLNEED VMA remnants so cleanup/remap paths do not repopulate DONTNEED/PURGED BOs. Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260506132027.2556046-1-arvind.yadav@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>