aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-21drm/xe: proper setting of irq enabled flagDani Liberman1-5/+3
IRQ enabled flag should be set only after request irq succeeds. Reviewed-by: Ohad Sharabi <osharabi@habana.ai> Signed-off-by: Dani Liberman <dliberman@habana.ai> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Implement fdinfo memory stats printingTejas Upadhyay2-1/+99
Use the newly added drm_print_memory_stats helper to show memory utilisation of our objects in drm/driver specific fdinfo output. To collect the stats we walk the per memory regions object lists and accumulate object size into the respective drm_memory_stats categories. Objects with multiple possible placements are reported in multiple regions for total and shared sizes, while other categories are counted only for the currently active region. V4: - Remove rcu lock - Auld/Thomas - take refcnt only if its non-zero - Auld - DMA_RESV_USAGE_BOOKKEEP covers all fences - Auld - covert to xe_bo for public objects V3: - dont use xe_bo_get/put, not needed - use designated initializer - Jani - use list_for_each_entry_rcu - Fix Checkpatch err - CI V2: - Use static initializer for mem_type - Himal/Jani Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Account ring buffer and context state storageTejas Upadhyay1-1/+6
Account ring buffers and logical context space against the owning client memory usage stats. Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Track page table memory usage for clientTejas Upadhyay2-0/+10
Account page table memory usage in the owning client memory usage stats. V2: - Minor tweak to if (vm->pt_root[id]) check - Himal Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Record each drm client with its VMTejas Upadhyay2-0/+3
Enable accounting of indirect client memory usage. Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Add tracking support for bos per clientTejas Upadhyay4-0/+92
In order to show per client memory consumption, we need tracking support APIs to add at every bo consumption and removal. Adding APIs here to add tracking calls at places wherever it is applicable. V5: - Rebase V4: - remove client bo before vm_put - spin_lock_irqsave not required - Auld V3: - update .h to return xe_drm_client_remove_bo void - protect xe_drm_client_remove_bo under CONFIG_PROC_FS check - Himal - Fixed Checkpatch error - CI V2: - make xe_drm_client_remove_bo return void - Himal Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Interface xe drm client with fdinfo interfaceTejas Upadhyay3-1/+26
DRM core driver has introduced recently fdinfo interface to show memory stats of individual drm client. Lets interface xe drm client to fdinfo interface. V2: - cover call to xe_drm_client_fdinfo under PROC_FS Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Add drm-client infrastructureTejas Upadhyay5-1/+116
Add drm-client infrastructure to record stats of consumption done by individual drm client. V2: - Typo - CI Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Add child contexts to the GuC context lookupDaniele Ceraolo Spurio1-14/+30
The CAT_ERROR message from the GuC provides the guc id of the context that caused the problem, which can be a child context. We therefore need to be able to match that id to the exec_queue that owns it, which we do by adding child context to the context lookup. While at it, fix the error path of the guc id allocation code to correctly free the ids allocated for parallel queues. v2: rebase on s/XE_WARN_ON/xe_assert Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/590 Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/wa: Apply tile workarounds at probe/resumeMatt Roper6-0/+34
Although the vast majority of workarounds the driver needs to implement are either GT-based or display-based, there are occasionally workarounds that reside outside those parts of the hardware (i.e., in they target registers in the sgunit/soc); we can consider these to be "tile" workarounds since there will be instance of these registers per tile. The registers in question should only lose their values during a function-level reset, so they only need to be applied during probe and resume; the registers will not be affected by GT/engine resets. Tile workarounds are rare (there's only one, 22010954014, that's relevant to Xe at the moment) so it's probably not worth updating the xe_rtp design to handle tile-level workarounds yet, although we may want to consider that in the future if/when more of these show up on future platforms. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20230913231411.291933-13-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Disallow pinning dma-bufs in VRAMThomas Hellström2-8/+33
For now only support pinning in TT memory, for two reasons: 1) Avoid pinning in a placement not accessible to some importers. 2) Pinning in VRAM requires PIN accounting which is a to-do. v2: - Adjust the dma-buf kunit test accordingly. Suggested-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230920095001.5539-1-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Simplify final return from xe_irq_install()Gustavo Sousa1-5/+1
At the end of the function, we will always return err no matter it's value. Simplify this by just returning the result of drmm_add_action_or_reset(). Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230915220233.59736-1-gustavo.sousa@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Reinstate pipelined fence enable_signalingThomas Hellström3-6/+3
With the GPUVA conversion, the xe_bo::vmas member became replaced with drm_gem_object::gpuva.list, however there was a couple of usage instances left using the old member. Most notably the pipelined fence enable_signaling. Remove the xe_bo::vmas member completely, fix usage instances and also enable this pipelined fence enable_signaling even for faulting VM:s since we actually wait for bind fences to complete. v2: - Rebase. v3: - Fix display code build error. Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230915172606.14436-1-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uc: Add GuC/HuC firmware path overridesDaniele Ceraolo Spurio3-1/+41
When testing a new binary and/or debugging binary-related issues, it is useful to have the option to change which binary is loaded without having to update and re-compile the kernel. To support this option, this patch adds 2 new modparams to override the FW path for GuC and HuC. The HuC modparam can also be set to an empty string to disable HuC loading. Note that those modparams only take effect on platforms where we already have a default FW, so we're sure there is support for FW loading and the kernel isn't going to explode in an undefined path. v2: simplify comment (John), rebase on s/guc_submission_enabled/uc_enabled Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uc: Fix uC status trackingDaniele Ceraolo Spurio5-19/+26
The current uC status tracking has a few issues: 1) the HuC is moved to "disabled" instead of "not supported" 2) the status is left uninitialized instead of "disabled" when the modparam is used to disable support 3) due to #1, a number of checks are done against "disabled" instead of the appropriate status. Address all of those by making sure to follow the appropriate state transition and checking against the required state. v2: rebase on s/guc_submission_enabled/uc_enabled/ Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uc: Rename guc_submission_enabled() to uc_enabled()Daniele Ceraolo Spurio10-22/+22
The guc_submission_enabled() function is being used as a boolean toggle for all firmwares and all related features, not just GuC submission. We could add additional flags/functions to distinguish and allow different use-cases (e.g. loading HuC but not using GuC submission), but given that not using GuC is a debug-only scenario having a global switch for all FWs is enough. However, we want to make it clear that this switch turns off everything, so rename it to uc_enabled(). v2: rebase on s/XE_WARN_ON/xe_assert Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/pmu: Enable PMU interfaceAravind Iddamsetty11-0/+833
There are a set of engine group busyness counters provided by HW which are perfect fit to be exposed via PMU perf events. BSPEC: 46559, 46560, 46722, 46729, 52071, 71028 events can be listed using: perf list xe_0000_03_00.0/any-engine-group-busy-gt0/ [Kernel PMU event] xe_0000_03_00.0/copy-group-busy-gt0/ [Kernel PMU event] xe_0000_03_00.0/interrupts/ [Kernel PMU event] xe_0000_03_00.0/media-group-busy-gt0/ [Kernel PMU event] xe_0000_03_00.0/render-group-busy-gt0/ [Kernel PMU event] and can be read using: perf stat -e "xe_0000_8c_00.0/render-group-busy-gt0/" -I 1000 time counts unit events 1.001139062 0 ns xe_0000_8c_00.0/render-group-busy-gt0/ 2.003294678 0 ns xe_0000_8c_00.0/render-group-busy-gt0/ 3.005199582 0 ns xe_0000_8c_00.0/render-group-busy-gt0/ 4.007076497 0 ns xe_0000_8c_00.0/render-group-busy-gt0/ 5.008553068 0 ns xe_0000_8c_00.0/render-group-busy-gt0/ 6.010531563 43520 ns xe_0000_8c_00.0/render-group-busy-gt0/ 7.012468029 44800 ns xe_0000_8c_00.0/render-group-busy-gt0/ 8.013463515 0 ns xe_0000_8c_00.0/render-group-busy-gt0/ 9.015300183 0 ns xe_0000_8c_00.0/render-group-busy-gt0/ 10.017233010 0 ns xe_0000_8c_00.0/render-group-busy-gt0/ 10.971934120 0 ns xe_0000_8c_00.0/render-group-busy-gt0/ The pmu base implementation is taken from i915. v2: Store last known value when device is awake return that while the GT is suspended and then update the driver copy when read during awake. v3: 1. drop init_samples, as storing counters before going to suspend should be sufficient. 2. ported the "drm/i915/pmu: Make PMU sample array two-dimensional" and dropped helpers to store and read samples. 3. use xe_device_mem_access_get_if_ongoing to check if device is active before reading the OA registers. 4. dropped format attr as no longer needed 5. introduce xe_pmu_suspend to call engine_group_busyness_store 6. few other nits. v4: minor nits. v5: take forcewake when accessing the OAG registers v6: 1. drop engine_busyness_sample_type 2. update UAPI documentation v7: 1. update UAPI documentation 2. drop MEDIA_GT specific change for media busyness counter. Co-developed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Co-developed-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Use spinlock in forcewake instead of mutexAravind Iddamsetty2-8/+8
In PMU we need to access certain registers which fall under GT power domain for which we need to take forcewake. But as PMU being an atomic context can't expect to have any sleeping calls. Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Get GT clock to nanosecsAravind Iddamsetty2-1/+8
Helper to convert GT clock cycles to nanoseconds. v2: Use DIV_ROUND_CLOSEST_ULL helper(Ashutosh) v3: rename xe_gt_clock_interval_to_ns to xe_gt_clock_cycles_to_ns Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/guc: Switch to major-only GuC FW tracking for MTLDaniele Ceraolo Spurio1-1/+1
Newer HuC binaries for MTL (8.5.1+) require GuC 70.7 or newer, so we need to move on from 70.6.4. Given that the MTL GuC uses major-only version matching in i915, we can do the same here instead of just bumping the version (and having to push the versioned binaries, because they're not there already for i915). Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Use Xe assert macros instead of XE_WARN_ON macroFrancois Dugast31-201/+235
The XE_WARN_ON macro maps to WARN_ON which is not justified in many cases where only a simple debug check is needed. Replace the use of the XE_WARN_ON macro with the new xe_assert macros which relies on drm_*. This takes a struct drm_device argument, which is one of the main changes in this commit. The other main change is that the condition is reversed, as with XE_WARN_ON a message is displayed if the condition is true, whereas with xe_assert it is if the condition is false. v2: - Rebase - Keep WARN splats in xe_wopcm.c (Matt Roper) v3: - Rebase Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Introduce Xe assert macrosMichal Wajdeczko1-0/+174
As we are moving away from the controversial XE_BUG_ON macro, relying just on WARN_ON or drm_err does not cover the cases where we want to annotate functions with additional detailed debug checks to assert that all prerequisites are satisfied, without paying footprint or performance penalty on non-debug builds, where all misuses introduced during code integration were already fixed. Introduce family of Xe assert macros that try to follow classic assert() utility and can be compiled out on non-debug builds. Macros are based on drm_WARN, but unlikely to origin, disallow use in expressions since we will compile that code out. As we are operating on the xe pointers, we can print additional information about the device, like tile or GT identifier, that is not available from generic WARN report: [ ] xe 0000:00:02.0: [drm] Assertion `true == false` failed! platform: 1 subplatform: 1 graphics: Xe_LP 12.00 step B0 media: Xe_M 12.00 step B0 display: enabled step D0 tile: 0 VRAM 0 B GT: 0 type 1 [ ] xe 0000:b3:00.0: [drm] Assertion `true == false` failed! platform: 7 subplatform: 3 graphics: Xe_HPG 12.55 step A1 media: Xe_HPM 12.55 step A1 display: disabled step ** tile: 0 VRAM 14.0 GiB GT: 0 type 1 [ ] WARNING: CPU: 0 PID: 2687 at drivers/gpu/drm/xe/xe_device.c:281 xe_device_probe+0x374/0x520 [xe] [ ] RIP: 0010:xe_device_probe+0x374/0x520 [xe] [ ] Call Trace: [ ] ? __warn+0x7b/0x160 [ ] ? xe_device_probe+0x374/0x520 [xe] [ ] ? report_bug+0x1c3/0x1d0 [ ] ? handle_bug+0x42/0x70 [ ] ? exc_invalid_op+0x14/0x70 [ ] ? asm_exc_invalid_op+0x16/0x20 [ ] ? xe_device_probe+0x374/0x520 [xe] [ ] ? xe_device_probe+0x374/0x520 [xe] [ ] xe_pci_probe+0x6e3/0x950 [xe] [ ] ? lockdep_hardirqs_on+0xc7/0x140 [ ] pci_device_probe+0x9e/0x160 [ ] really_probe+0x19d/0x400 v2: use lowercase names v3: apply xe coding style v4: fix non-debug build and improve kernel-doc Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Oded Gabbay <ogabbay@kernel.org> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@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> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Replace XE_WARN_ON with drm_warn when just printing a stringFrancois Dugast6-17/+22
Use the generic drm_warn instead of the driver-specific XE_WARN_ON in cases where XE_WARN_ON is used to unconditionally print a debug message. v2: Rebase Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Fix fence reservation accoutingMatthew Brost2-2/+11
Both execs and the preempt rebind worker can issue rebinds. Rebinds require a fence, per tile, inserted into dma-resv slots of the VM and BO (if external). The fence reservation accouting did not take into account the number of fences required for rebinds, fix this. v2: Rebase Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reported-by: Christopher Snowhill <kode54@gmail.com> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/518 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Convert remaining instances of ttm_eu_reserve_buffers to drm_execThomas Hellström2-69/+36
The VM_BIND functionality and vma destruction was locking potentially multiple dma_resv objects using the ttm_eu_reserve_buffers() function. Rework those to use the drm_exec helper, taking care that any calls to xe_bo_validate() ends up inside an unsealed locking transaction. v4: - Remove an unbalanced xe_bo_put() (igt and Matthew Brost) v5: - Rebase conflict Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230908091716.36984-7-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Convert pagefaulting code to use drm_execThomas Hellström3-62/+84
Replace the calls into ttm_eu_reserve_buffers with the drm_exec helpers. Also reuse some code. v4: - Kerneldoc xe_vm_prepare_vma(). Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230908091716.36984-6-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Rework xe_exec and the VM rebind worker to use the drm_exec helperThomas Hellström4-219/+153
Replace the calls to ttm_eu_reserve_buffers() by using the drm_exec helper instead. Also make sure the locking loop covers any calls to xe_bo_validate() / ttm_bo_validate() so that these function calls may easily benefit from being called from within an unsealed locking transaction and may thus perform blocking dma_resv locks in the future. For the unlock we remove an assert that the vm->rebind_list is empty when locks are released. Since if the error path is hit with a partly locked list, that assert may no longer hold true we chose to remove it. v3: - Don't accept duplicate bo locks in the rebind worker. v5: - Loop over drm_exec objects in reverse when unlocking. v6: - We can't keep the WW ticket when retrying validation on OOM. Fix. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230908091716.36984-5-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/bo: Remove the lock_no_vm()/unlock_no_vm() interfaceThomas Hellström6-35/+11
Apart from asserts, it's essentially the same as xe_bo_lock()/xe_bo_unlock(), and the usage intentions of this interface was unclear. Remove it. v2: - Update the xe_display subsystem as well. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230908091716.36984-4-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/vm: Simplify and document xe_vm_lock()Thomas Hellström8-50/+41
The xe_vm_lock() function was unnecessarily using ttm_eu_reserve_buffers(). Simplify and document the interface. v4: - Improve on xe_vm_lock() documentation (Matthew Brost) v5: - Rebase conflict. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230908091716.36984-3-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/bo: Simplify xe_bo_lock()Thomas Hellström7-100/+89
xe_bo_lock() was, although it only grabbed a single lock, unnecessarily using ttm_eu_reserve_buffers(). Simplify and document the interface. v2: - Update also the xe_display subsystem. v4: - Reinstate a lost dma_resv_reserve_fences(). - Improve on xe_bo_lock() documentation (Matthew Brost) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230908091716.36984-2-thomas.hellstrom@linux.intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/mmio: Account for GSI offset when checking rangesLucas De Marchi2-3/+7
Change xe_mmio_in_range() to use the same logic to account for the GT's adj_offset as the read and write functions. This is needed when checking ranges for the MCR registers if the GT has an offset to adjust. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230908225227.1276610-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uapi: Remove useless max_page_sizeRodrigo Vivi2-7/+0
The min_page_size is useful information to ensure alignment and it is an API actually in use. However max_page_size doesn't bring any useful information to the userspace hence being not used at all. So, let's remove and only bring it back if that ever gets used. Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com>
2023-12-21drm/xe/uapi: Typo lingo and other small backwards compatible fixesRodrigo Vivi2-10/+11
Fix typos, lingo and other small things identified during uapi review. v2: Also fix ALIGNMENT typo at xe_query.c v3: Do not touch property to get/set. (Francois) Link: https://lore.kernel.org/all/863bebd0c624d6fc2b38c0a06b63e468b4185128.camel@linux.intel.com/ Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com>
2023-12-21drm/xe: Fix LRC workaroundsLucas De Marchi1-7/+34
Fix 2 issues when writing LRC workarounds by copying the same handling done when processing other RTP entries: For masked registers, it was not correctly setting the upper 16bits. Differently than i915, the entry itself doesn't set the upper bits for masked registers: this is done when applying them. Testing on ADL-P: Before: [drm:xe_gt_record_default_lrcs [xe]] LRC WA rcs0 save-restore MMIOs [drm:xe_gt_record_default_lrcs [xe]] REG[0x2580] = 0x00000002 ... [drm:xe_gt_record_default_lrcs [xe]] REG[0x7018] = 0x00002000 [drm:xe_gt_record_default_lrcs [xe]] REG[0x7300] = 0x00000040 [drm:xe_gt_record_default_lrcs [xe]] REG[0x7304] = 0x00000200 After: [drm:xe_gt_record_default_lrcs [xe]] LRC WA rcs0 save-restore MMIOs [drm:xe_gt_record_default_lrcs [xe]] REG[0x2580] = 0x00060002 ... [drm:xe_gt_record_default_lrcs [xe]] REG[0x7018] = 0x20002000 [drm:xe_gt_record_default_lrcs [xe]] REG[0x7300] = 0x00400040 [drm:xe_gt_record_default_lrcs [xe]] REG[0x7304] = 0x02000200 All of these registers are masked registers, so writing to them without the relevant bits in the upper 16b doesn't have any effect. Also, this adds support to regular registers; previously it was assumed that LRC entries would only contain masked registers. However this is not true. 0x6604 is not a masked register, but used in workarounds for e.g. ADL-P. See commit 28cf243a341a ("drm/i915/gt: Fix context workarounds with non-masked regs"). In the same test with ADL-P as above: Before: [drm:xe_gt_record_default_lrcs [xe]] REG[0x6604] = 0xe0000000 After: [drm:xe_gt_record_default_lrcs [xe]] REG[0x6604] = 0xe0efef6f As can be seen, now it will read what was in the register rather than completely overwrite the other bits. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230906012053.1733755-5-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Add dbg messages for LRC WAsLucas De Marchi1-0/+4
Just like the GT and engine workarounds, add debug message with the final value being written to the register for easy debugging. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230906012053.1733755-4-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/reg_sr: Use xe_gt_dbgLucas De Marchi1-5/+3
Use xe_gt_dbg() instead of drm_dbg() so the GT is added to the log for easy identification. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230906012053.1733755-3-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/reg_sr: Simplify check for masked registersLucas De Marchi2-5/+8
For all RTP actions, clr_bits is a superset of the bits being modified. That's also why the check for "changing all bits" can be done with `clr_bits + 1`. So always use clr_bits for setting the upper bits of a masked register. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://lore.kernel.org/r/20230906012053.1733755-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/pat: Use 0 instead of space on errorLucas De Marchi1-1/+1
Use 0 in format string instead of space so it shows as [drm] *ERROR* Missing PAT table for platform with graphics version 20.04! instead of [drm] *ERROR* Missing PAT table for platform with graphics version 20. 4! Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20230906193009.1912129-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/selftests: make eviction test tile centricMatthew Auld1-7/+7
The concern here is that we may have platforms with dedicated media GT, and we anyway allocate the object on the tile, which just means running the same test twice (i.e primary vs media GT). Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/selftests: consider multi-GT for eviction testMatthew Auld1-4/+8
We need to sanitize and reset each GT, since xe_bo_evict_all() will evict everything regardless of GT, which can leave other GTs in a broken state. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/pm: Use PM functions only if CONFIG_PM_SLEEP is enabledFrancois Dugast1-23/+25
This fixes the build without CONFIG_PM_SLEEP such as for riscv. Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Fix array of bindsMatthew Brost1-206/+212
If multiple bind ops in an array of binds touch the same address range invalid GPUVA operations are generated as each GPUVA operation is generated based on the orignal GPUVA state. To fix this, after each GPUVA operations is generated, commit the GPUVA operation updating the GPUVA state so subsequent bind ops can see a current GPUVA state. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/gpuva: Add drm_gpuva_for_each_op_reverseMatthew Brost1-0/+10
Add a helper to walk op list in reverse. Xe will make use of this when unwinding GPUVA operations. v2: (Rodrigo) reword commit message Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Fixup unwind on VM ops errorsMatthew Brost2-10/+24
Remap ops have 3 parts: unmap, prev, and next. The commit step can fail on any of these. Add a flag for each to these so the unwind is only done the steps that have been committed. v2: (Rodrigo) Use bit macros Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Convert xe_vma_op_flags to BIT macrosMatthew Brost1-3/+3
Rather than open code the shift for values, use BIT macros. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: fix has_llc on rklMatthew Auld1-0/+1
Matches i915. Assumption going forward is that non-llc + igpu is only a thing on MTL+ which should have explicit coherency pat_index settings for COH_NONE, 1WAY and 2WAY. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Pallavi Mishra <pallavi.mishra@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Pallavi Mishra <pallavi.mishra@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: nuke GuC on unloadMatthew Auld5-7/+25
On PVC unloading followed by reloading the module often results in a completely dead machine (seems to be plaguing CI). Resetting the GuC like we do at load seems to cure it at least when locally testing this. v2: - Move pc_fini into guc_fini. We want to do the GuC reset just after calling pc_fini, otherwise we encounter communication failures. It also seems like a good idea to do the reset before we start releasing the various other GuC resources. In the case of pc_fini there is an explicit stop, but for other stuff like logs, ads, ctb there is not. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/542 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/597 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Prevent return with locked vmPallavi Mishra1-11/+11
Reorder vm_id check after the one for VISIBLE_VRAM. This should prevent returning with locked vm in error scenario. Signed-off-by: Pallavi Mishra <pallavi.mishra@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Add patch version on guc firmware initZhanjun Dong2-6/+9
Add patch version info on GuC firmware init. This is required info for GuC log decoder. Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://lore.kernel.org/r/20230817213028.838531-1-zhanjun.dong@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/pvc: Use fast copy engines as migrate engine on PVCNiranjana Vishwanathapura3-5/+34
Some copy hardware engine instances are faster than others on PVC. Use a virtual engine of these plus the reserved instance for the migrate engine on PVC. The idea being if a fast instance is available it will be used and the throughput of kernel copies, clears, and pagefault servicing will be higher. v2: Use OOB WA, use all copy engines if no WA is required Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>