summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/xe
AgeCommit message (Collapse)Author
2025-06-17drm/xe/oa: Assign hwe for OAM_SAGAshutosh Dixit
Because OAM_SAG doesn't have an attached hwe, assign another hwe belonging to the same gt (and different OAM unit) to OAM_SAG. A hwe is needed for batch submissions to program OA HW. v2: Assign an engine with a valid OA unit for OAM_SAG (Umesh) Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://lore.kernel.org/r/20250606192618.4133817-5-ashutosh.dixit@intel.com
2025-06-17drm/xe/oa: Introduce stream->oa_unitAshutosh Dixit
Previously, the oa_unit associated with an OA stream was derived from hwe associated with the stream (stream->hwe->oa_unit). This breaks with OAM_SAG since OAM_SAG does not have any attached hardware engines. Resolve this by introducing stream->oa_unit and stop depending on stream->hwe. Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://lore.kernel.org/r/20250606192618.4133817-4-ashutosh.dixit@intel.com
2025-06-17drm/xe/oa: Print hwe to OA unit mappingAshutosh Dixit
Print hwe to OA unit mapping to dmesg, to help debug for current and new platforms. v2: Separate out xe_oa_print_gt_oa_units() (Umesh) Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://lore.kernel.org/r/20250606192618.4133817-3-ashutosh.dixit@intel.com
2025-06-17drm/xe/oa/uapi: Expose media OA unitsAshutosh Dixit
On Xe2+ platforms, media engines are attached to "SCMI" OA media (OAM) units. One or more SCMI OAM units might be present on a platform. In addition there is another OAM unit for global events, called OAM-SAG. Performance metrics for media workloads can be obtained from these OAM units, similar to OAG. Expose these OAM units for userspace to use. OAM-SAG is exposed as an OA unit without any attached engines. Bspec: 70819, 67103, 63844, 72572, 74476, 61284 v2: Fix xe_gt_WARN_ON in __hwe_oam_unit for < 12.7 platforms v3: Return XE_OA_UNIT_INVALID for < 12.7 to indicate no OAM units v4: Move xe_oa_print_oa_units() to separate patch v5: Introduce DRM_XE_OA_UNIT_TYPE_OAM_SAG v6: Introduce DRM_XE_OA_CAPS_OAM Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://lore.kernel.org/r/20250606192618.4133817-2-ashutosh.dixit@intel.com
2025-06-17drm/xe: Move LRC_ENGINE_ID_PPHWSP_OFFSET outside of parallel offsetMatthew Brost
The parallel scratch layout spans 2k and LRC_ENGINE_ID_PPHWSP_OFFSET lands within than space. This happens to be ok as the offset lands in reserved part of guc_sched_wq_desc, but for future safety move LRC_ENGINE_ID_PPHWSP_OFFSET to the unused offset of 1024 below parallel scratch layout. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://lore.kernel.org/r/20250612172850.4170428-1-matthew.brost@intel.com
2025-06-17drm/xe: Do not kill VM in PT code on -ENODATAMatthew Brost
No need kill on -ENODATA as is this non-fatal error can occur when MMU notifiers race with prefetches. Fixes: 09ba0a8f06cd ("drm/xe/svm: Implement prefetch support for SVM ranges") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>> Link: https://lore.kernel.org/r/20250613231808.752616-1-matthew.brost@intel.com
2025-06-17drm: Create a task info option for wedge eventsAndré Almeida
When a device get wedged, it might be caused by a guilty application. For userspace, knowing which task was involved can be useful for some situations, like for implementing a policy, logs or for giving a chance for the compositor to let the user know what task was involved in the problem. This is an optional argument, when the task info is not available, the PID and TASK string won't appear in the event string. Sometimes just the PID isn't enough giving that the task might be already dead by the time userspace will try to check what was this PID's name, so to make the life easier also notify what's the task's name in the user event. Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250617124949.2151549-4-andrealmeid@igalia.com Signed-off-by: André Almeida <andrealmeid@igalia.com>
2025-06-16drm/xe/tests: Convert xe_pci tests to parametrized testsMichal Wajdeczko
Instead of looping over known IP descriptors within single test case, without any diagnostics which IP descriptor is eventually broken, define kunit parameter generators with IP descriptors, and make existing xe_pci tests fully parametrized: [ ] =================== xe_pci (2 subtests) ==================== [ ] ==================== check_graphics_ip ==================== [ ] [PASSED] 12.70 Xe_LPG [ ] [PASSED] 12.71 Xe_LPG [ ] [PASSED] 12.74 Xe_LPG+ [ ] [PASSED] 20.01 Xe2_HPG [ ] [PASSED] 20.04 Xe2_LPG [ ] [PASSED] 30.00 Xe3_LPG [ ] [PASSED] 30.01 Xe3_LPG [ ] ================ [PASSED] check_graphics_ip ================ [ ] ===================== check_media_ip ====================== [ ] [PASSED] 13.00 Xe_LPM+ [ ] [PASSED] 13.01 Xe2_HPM [ ] [PASSED] 20.00 Xe2_LPM [ ] [PASSED] 30.00 Xe3_LPM [ ] ================= [PASSED] check_media_ip ================== [ ] ===================== [PASSED] xe_pci ====================== Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250614182446.2024-1-michal.wajdeczko@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-06-16drm/xe/tests: Drop unused xe_device_fn typedefMichal Wajdeczko
We missed to drop it in commit 50680d1698f4 ("drm/xe/tests: remove unused leftover xe_call_for_each_device()") so drop it now. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250613191938.1980-2-michal.wajdeczko@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-06-16drm/xe: Fix kconfig promptLucas De Marchi
The xe driver is the official driver for Intel Xe2 and later, while maintaining experimental support for earlier GPUs. Reword the help message accordingly. Reviewed-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://lore.kernel.org/r/20250611-xe-kconfig-help-v1-1-8bcc6b47d11a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-16drm/xe/pat: Consolidate PAT programming logic for pre-Xe2 and post-Xe2Matt Roper
Now that the PAT settings for the new special entries introduced by Xe2 are decided during early software init and left NULL on platforms they don't apply to, there's no need to keep separate programming functions for pre-Xe2 and post-Xe2 platforms. Consolidate down to a single pair of programming functions (mcr and non-mcr) that can be used on any platform. Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20250613214751.792066-4-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-06-16drm/xe/pat: Determine ATS / PTA programming during early sw initMatt Roper
Decide whether programming of the special ATS and PTA PAT entries is necessary (and which entries should be programmed) during early software initialization rather than hardcoding this into the 'program' functions. Future platforms may want to re-use the same functions but utilize different special entry values. Consolidating all of the decisions into one place keeps things simple. Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20250613214751.792066-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-06-13drm/xe: Make dma-fences compliant with the safe access rulesTvrtko Ursulin
Xe can free some of the data pointed to by the dma-fences it exports. Most notably the timeline name can get freed if userspace closes the associated submit queue. At the same time the fence could have been exported to a third party (for example a sync_fence fd) which will then cause an use- after-free on subsequent access. To make this safe we need to make the driver compliant with the newly documented dma-fence rules. Driver has to ensure a RCU grace period between signalling a fence and freeing any data pointed to by said fence. For the timeline name we simply make the queue be freed via kfree_rcu and for the shared lock associated with multiple queues we add a RCU grace period before freeing the per GT structure holding the lock. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250610164226.10817-5-tvrtko.ursulin@igalia.com
2025-06-13drm/xe/vm: Add a helper xe_vm_range_tilemask_tlb_invalidation()Himal Prasad Ghimiray
Introduce xe_vm_range_tilemask_tlb_invalidation(), which issues a TLB invalidation for a specified address range across GTs indicated by a tilemask. v2 (Matthew Brost) - Move WARN_ON_ONCE to svm caller - Remove xe_gt_tlb_invalidation_vma - s/XE_WARN_ON/WARN_ON_ONCE v3 - Rebase Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250609041616.1723636-1-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-06-12drm/xe/bmg: Update Wa_14022085890Vinay Belgaumkar
Set GT min frequency to 1200Mhz once driver load is complete. v2: Review comments (Rodrigo) v3: Apply Wa earlier so user_req_min is not clobbered. v4: Apply to all GTs (Lucas) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250612-wa-14022085890-v4-3-94ba5dcc1e30@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-12drm/xe/bmg: Update Wa_16023588340Vinay Belgaumkar
This allows for additional L2 caching modes. Fixes: 01570b446939 ("drm/xe/bmg: implement Wa_16023588340") Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://lore.kernel.org/r/20250612-wa-14022085890-v4-2-94ba5dcc1e30@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-12drm/xe/guc: Ignore GuC CT errors when wedgedVinay Belgaumkar
Messaging to GuC may get canceled when device is wedged. Don't flag this as an error in xe_guc_pc code. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250612-wa-14022085890-v4-1-94ba5dcc1e30@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-12drm/xe: Add helper function to inject fault into ct_dead_capture()Satyanarayana K V P
When injecting fault to xe_guc_ct_send_recv() & xe_guc_mmio_send_recv() functions, the CI test systems are going out of space and crashing. To avoid this issue, a new helper function is created and when fault is injected into this xe_is_injection_active() helper function, ct dead capture is avoided which suppresses ct dumps in the log. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Suggested-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://lore.kernel.org/r/20250612080402.22011-1-satyanarayana.k.v.p@intel.com
2025-06-12drm/xe: Fix early wedge on GuC load failureDaniele Ceraolo Spurio
When the GuC fails to load we declare the device wedged. However, the very first GuC load attempt on GT0 (from xe_gt_init_hwconfig) is done before the GT1 GuC objects are initialized, so things go bad when the wedge code attempts to cleanup GT1. To fix this, check the initialization status in the functions called during wedge. Fixes: 7dbe8af13c18 ("drm/xe: Wedge the entire device") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Zhanjun Dong <zhanjun.dong@intel.com> Cc: stable@vger.kernel.org # v6.12+: 1e1981b16bb1: drm/xe: Fix taking invalid lock on wedge Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250611214453.1159846-2-daniele.ceraolospurio@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-12drm/xe: Make WA BB part of LRC BOMatthew Brost
No idea why, but without this GuC context switches randomly fail when running IGTs in a loop. Need to follow up why this fixes the aforementioned issue but can live with a stable driver for now. Fixes: 617d824c5323 ("drm/xe: Add WA BB to capture active context utilization") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Tested-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://lore.kernel.org/r/20250612031925.4009701-1-matthew.brost@intel.com
2025-06-12drm/xe: Use WRITE_ONCE for range->tile_invalidated updateMatthew Brost
Updating range->tile_invalidated should be done with WRITE_ONCE to pair with READ_ONCE in opportunistic checks. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Maarten Lankhrost <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/20250604234712.2441130-1-matthew.brost@intel.com
2025-06-12drm/xe: Don't use drm exec locking in SVM pagefaultsMatthew Brost
Only the VM dma-resv lock is needed in SVM pagefaults so xe_vm_lock/unlock can be used instead of drm exec. Micro optimization but should save some CPU cycles in a critical path. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250603174012.2195759-1-matthew.brost@intel.com
2025-06-12drm/xe/lrc: Use a temporary buffer for WA BBLucas De Marchi
In case the BO is in iomem, we can't simply take the vaddr and write to it. Instead, prepare a separate buffer that is later copied into io memory. Right now it's just a few words that could be using xe_map_write32(), but the intention is to grow the WA BB for other uses. Fixes: 617d824c5323 ("drm/xe: Add WA BB to capture active context utilization") Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://lore.kernel.org/r/20250604-wa-bb-fix-v1-1-0dfc5dafcef0@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit ef48715b2d3df17c060e23b9aa636af3d95652f8) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-11drm/xe/lrc: Prepare WA BB setup for more usersLucas De Marchi
The post context restore (WA BB) is a mechanism in HW that may be used for things other than the utilization setup. Create a new function called setup_wa_bb() that wraps any function writing useful commands in the buffer. Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/r/20250604-wa-bb-fix-v1-2-0dfc5dafcef0@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-11drm/xe/lrc: Use a temporary buffer for WA BBLucas De Marchi
In case the BO is in iomem, we can't simply take the vaddr and write to it. Instead, prepare a separate buffer that is later copied into io memory. Right now it's just a few words that could be using xe_map_write32(), but the intention is to grow the WA BB for other uses. Fixes: 82b98cadb01f ("drm/xe: Add WA BB to capture active context utilization") Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://lore.kernel.org/r/20250604-wa-bb-fix-v1-1-0dfc5dafcef0@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-11drm/xe/xe2_hpg: Define additional Xe2_HPG GMD_IDShekhar Chauhan
Add another GMD_ID for Xe2_HPG Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250605190804.1287289-4-dnyaneshwar.bhadane@intel.com
2025-06-11drm/xe/xe2_hpg: Add set of workaroundsShekhar Chauhan
Add set of workarounds for xe2_hpg. -v2: Fix xe2_hpg GMD version for some workarounds. -v3: Removed extra Workaround (Matt Roper) Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250605190804.1287289-3-dnyaneshwar.bhadane@intel.com
2025-06-11drm/i915/display: drop i915_reg.h include where possibleJani Nikula
A number of files have unnecessary i915_reg.h includes. Drop them. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://lore.kernel.org/r/7c4002322f4d8132fd2eaa1a4d688539cdd043c3.1749469962.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-11Revert "drm/xe/display: use xe->display to decide whether to do anything"Vivek Kasireddy
This reverts commit 5a9f299f956ef9764f56044cfca7aafa23cea1d1. The following crash/regression was seen with the reverted commit on a specific BMG SKU with no display capabilities: [ 115.582833] BUG: kernel NULL pointer dereference, address: 00000000000005d0 [ 115.589775] #PF: supervisor write access in kernel mode [ 115.594976] #PF: error_code(0x0002) - not-present page [ 115.600088] PGD 0 P4D 0 [ 115.602617] Oops: Oops: 0002 [#1] SMP [ 115.606267] CPU: 14 UID: 0 PID: 1547 Comm: kworker/14:3 Tainted: G U E 6.15.0-local+ #62 PREEMPT(voluntary) [ 115.617332] Tainted: [U]=USER, [E]=UNSIGNED_MODULE [ 115.622100] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPEMI1.R00.3471.D49.2401260852 01/26/2024 [ 115.635314] Workqueue: pm pm_runtime_work [ 115.639309] RIP: 0010:_raw_spin_lock+0x17/0x30 [ 115.662382] RSP: 0018:ffffd13f82e7bc30 EFLAGS: 00010246 [ 115.667581] RAX: 0000000000000000 RBX: ffff8be919076000 RCX: 0000000000000002 [ 115.674675] RDX: 0000000000000001 RSI: 000000000000004b RDI: 00000000000005d0 [ 115.681775] RBP: ffffd13f82e7bc60 R08: ffffd13f82e7bb00 R09: ffff8beb0c1b06c0 [ 115.688869] R10: ffff8be7c034f4c0 R11: fefefefefefefeff R12: fffffffffffffff0 [ 115.695965] R13: ffff8be9190762e8 R14: ffff8be919077798 R15: 00000000000005d0 [ 115.703062] FS: 0000000000000000(0000) GS:ffff8beb552b6000(0000) knlGS:0000000000000000 [ 115.711106] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 115.716826] CR2: 00000000000005d0 CR3: 000000024c68d002 CR4: 0000000000f72ef0 [ 115.723921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 115.731015] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 115.738113] PKRU: 55555554 [ 115.740816] Call Trace: [ 115.743258] <TASK> [ 115.745363] ? xe_display_flush_cleanup_work+0x92/0x120 [xe] [ 115.751102] xe_display_pm_runtime_suspend+0x42/0x80 [xe] [ 115.756542] xe_pm_runtime_suspend+0x11b/0x1b0 [xe] [ 115.761463] xe_pci_runtime_suspend+0x23/0xd0 [xe] [ 115.766291] pci_pm_runtime_suspend+0x6b/0x1a0 [ 115.770717] ? pci_pm_thaw_noirq+0xa0/0xa0 [ 115.774797] __rpm_callback+0x48/0x1e0 [ 115.778531] ? pci_pm_thaw_noirq+0xa0/0xa0 [ 115.782614] rpm_callback+0x66/0x70 [ 115.786090] ? pci_pm_thaw_noirq+0xa0/0xa0 [ 115.790173] rpm_suspend+0xe1/0x5e0 [ 115.793647] ? psi_task_switch+0xb8/0x200 [ 115.797643] ? finish_task_switch.isra.0+0x8d/0x270 [ 115.802502] pm_runtime_work+0xa6/0xc0 [ 115.806238] process_one_work+0x186/0x350 [ 115.810234] worker_thread+0x33a/0x480 [ 115.813968] ? process_one_work+0x350/0x350 [ 115.818132] kthread+0x10c/0x220 [ 115.821350] ? kthreads_online_cpu+0x120/0x120 [ 115.825774] ret_from_fork+0x3a/0x60 [ 115.829339] ? kthreads_online_cpu+0x120/0x120 [ 115.833768] ret_from_fork_asm+0x11/0x20 [ 115.829339] ? kthreads_online_cpu+0x120/0x120 [ 115.833768] ret_from_fork_asm+0x11/0x20 [ 115.837680] </TASK> [ 115.839907] acpi_tad(E) drm(E) [ 115.931629] CR2: 00000000000005d0 [ 115.934935] ---[ end trace 0000000000000000 ]--- [ 115.939531] RIP: 0010:_raw_spin_lock+0x17/0x30 We cannot yet use xe->display to determine whether display hardware has been successfully probed/initialized or not. This is because xe->display would not be set to NULL even with GPUs with no display capabilities (e.g, GMD_ID_DISPLAY = 0). However, this might change in the future as Xe and i915 code is unified to deal with no display cases. Therefore, for now we have to continue to rely on xe->info.probe_display (which would be set to false with display-less GPUs) to decide whether to invoke any display related functions or not. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250605054247.386633-1-vivek.kasireddy@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-11Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to forward to v6.16-rc1 Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-06-10drm/xe: Reorder 'Get pages failed' messageMatthew Brost
Print the error from get pages failing, not the cast to -ENODATA. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>> Link: https://lore.kernel.org/r/20250610045649.3149801-1-matthew.brost@intel.com
2025-06-09Merge drm/drm-next into drm-xe-nextThomas Hellström
Backmerging to bring in 6.16 Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-09drm/xe: GSM size should be constant on most platformsMatt Roper
On old Intel platforms, the size of the GSM (i.e., the stolen memory that holds the GGTT page table entries) could vary, so the driver needed to read the actual size from the PCI config space. However from Xe_HP onward, the GSM is now always guaranteed to be exactly 8MB (which translates to a 4GB GGTT address space); this is always true regardless of what the platform's much larger PPGTT address space is. The bspec doesn't document the PCI config space as being a valid way to query the size of the GSM after Xe_LP platforms, although so far it still seems to be giving us proper values for Xe_HP, Xe2, and Xe3. However we suspect that the config space will stop providing correct values on some upcoming platforms, so we should stop relying on it. Instead just use the hardcoded 8MB value as documented elsewhere in the bspec. Bspec: 49636, 67090, 50589 Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250605225352.2333981-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-06-09drm/xe/svm: Fix regression disallowing 64K SVM migrationMaarten Lankhorst
When changing the condition from >= SZ_64K, it was changed to <= SZ_64K. This disallows migration of 64K, which is the exact minimum allowed. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5057 Fixes: 794f5493f518 ("drm/xe: Strict migration policy for atomic SVM faults") Cc: stable@vger.kernel.org Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://lore.kernel.org/r/20250521090102.2965100-1-dev@lankhorst.se (cherry picked from commit 531bef26d189b28bf0d694878c0e064b30990b6c) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-09drm/xe/uc: Use GT-oriented firmware messagesMichal Wajdeczko
We are already prepared to define firmwares per-GT type, so we should also prepare our messages to be GT-oriented. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250606204311.813-1-michal.wajdeczko@intel.com
2025-06-09drm/i915: split out display register macros to a separate fileJani Nikula
This is a scripted split of the display related register macros from i915_reg.h to display/intel_display_regs.h. As a starting point, move all the macros that are only used in display code (or GVT). If there are users in core i915 code or soc/, or no users anywhere, keep the macros in i915_reg.h. This is done in groups of macros separated by blank lines, moving the comments along with the groups. Some manually picked macro groups are kept/moved regardless of the heuristics above. This is obviously a very crude approach. It's not perfect. But there are 4.2k lines in i915_reg.h, and its refactoring has ground to a halt. This is the big hammer that splits the file to two, and enables further cleanup. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> # v2 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250606102256.2080073-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-09Merge drm/drm-next into drm-intel-nextJani Nikula
Sync to v6.16-rc1, among other things to get the fixed size GENMASK_U*() and BIT_U*() macros. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-06-09drm/xe: Do not rely on GGTT internals in xe_guc_buf kunit testsMaarten Lankhorst
Add a function to init ggtt for kunit, and use the GGTT function for initialising the GGTT node without populating it. This prevents the test from ever knowing about struct xe_ggtt. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250505121924.921544-11-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe: Implement a helper for reading out a GGTT PTE at a specified offsetMaarten Lankhorst
Split the GGTT PTE readout to a separate function, this is useful for adding testcases in the next commit, and also cleaner than manually reading out GGTT. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://lore.kernel.org/r/20250505121924.921544-10-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe: Remove pte_encode_bo callbackMaarten Lankhorst
The users inside display have been converted to use thepte_encode_flags callback, we can now remove the pte_encode_bo cb. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://lore.kernel.org/r/20250505121924.921544-9-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe/display: Convert GGTT mapping to use pte_encode_flagsMaarten Lankhorst
Another small step in removing pte_encode_bo callback. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://lore.kernel.org/r/20250505121924.921544-8-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe/display: Dont poke into GGTT internals to fill a DPTMaarten Lankhorst
For DPT, it is sufficient to get the GGTT encode flags to fill the DPT. Create a function to return the encode flags, and then encode using the BO address. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://lore.kernel.org/r/20250505121924.921544-7-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe/ggtt: Seperate flags and address in PTE encodingMaarten Lankhorst
Pinning large linear display framebuffers is becoming a bottleneck. My plan of attack is doing a custom walk over the BO, this allows for easier optimization of consecutive entries. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250505121924.921544-6-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe/display: Remove dereferences of ggtt for tile idMaarten Lankhorst
Obtain the id from the root tile. Likely this can be hardcoded to 0, but use the clean solution of obtaining root id and doing that. to_xe_device(ggtt->tile) can also be easily replaced with xe. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250505121924.921544-5-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe: Add xe_ggtt_allocMaarten Lankhorst
Instead of allocating inside xe_tile, create a new function that returns an allocated struct xe_ggtt from xe_ggtt.c Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250505121924.921544-4-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe: Add xe_ggtt_might_lockMaarten Lankhorst
Another requirement of hiding more of struct xe_ggtt. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250505121924.921544-3-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe: Use xe_ggtt_map_bo_unlocked for resumeMaarten Lankhorst
This is the first step to hide the details of struct xe_ggtt. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250505121924.921544-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-09drm/xe: Remove IOSF_MBI select.Maarten Lankhorst
IOSF_MBI was only useful for some gen8 platforms, which were never supported by Xe. Presumably needed for display at one point, but display is fixed to put stubs in compat-i915-headers/vlv_sideband.h. (in drm-intel-next: vlv_iosf_sb.h) Link: https://lore.kernel.org/r/20250605074644.71036-1-dev@lankhorst.se Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-06-06drm/xe/topology: Stop trying to fix programming mistakesMichal Wajdeczko
We shouldn't ever pass more DSS registers than our hardcoded limit, it should be sufficient to just assert that instead of trying to fix it, as this will never happen in the production driver. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250604202908.769-4-michal.wajdeczko@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-06-06drm/xe/topology: Use register array size instead magic numberMichal Wajdeczko
Since we keep registers in the array we can simply count them and stop relying on magic number when checking if didn't make mistake. Also we can switch to use xe_gt_assert() since it could be just our programming mistake during platform bringup, no need to keep drm_WARN() in the production driver. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20250604202908.769-3-michal.wajdeczko@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
generated by cgit (git 2.34.1) at 2025-09-20 18:38:25 +0000