- 31 Jul, 2024 1 commit
-
-
Matthew Brost authored
A chain fence is uninitialized if not installed in a drm sync obj. Thus if xe_sync_entry_cleanup is called and sync->chain_fence is non-NULL the proper cleanup is dma_fence_chain_free rather than a dma-fence put. Reported-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2411 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2261 Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727012216.2118276-1-matthew.brost@intel.com
-
- 30 Jul, 2024 1 commit
-
-
Geert Uytterhoeven authored
When building with gcc-5: In function ‘decode_oa_format.isra.26’, inlined from ‘xe_oa_set_prop_oa_format’ at drivers/gpu/drm/xe/xe_oa.c:1664:6: ././include/linux/compiler_types.h:510:38: error: call to ‘__compiletime_assert_1336’ declared with attribute error: FIELD_GET: mask is not constant [...] ./include/linux/bitfield.h:155:3: note: in expansion of macro ‘__BF_FIELD_CHECK’ __BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \ ^ drivers/gpu/drm/xe/xe_oa.c:1573:18: note: in expansion of macro ‘FIELD_GET’ u32 bc_report = FIELD_GET(DRM_XE_OA_FORMAT_MASK_BC_REPORT, fmt); ^ Fixes: b6fd51c6 ("drm/xe/oa/uapi: Define and parse OA stream properties") Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240729092634.2227611-1-geert+renesas@glider.beSigned-off-by:
-
- 29 Jul, 2024 10 commits
-
-
Sai Teja Pottumuttu authored
Add performance tuning changes for Xe2_HPG Bspec: 72161 Signed-off-by:
Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240724121521.2347524-1-sai.teja.pottumuttu@intel.com
-
Lucas De Marchi authored
Now that rtp has OR rules, it's not needed to extend it to process OOB WAs. Previously if an entry had no name, it was considered as "a set of rules OR'ed with the last named entry". Instead of generating new entries, add OR rules. The syntax for xe_wa_oob.rules remains the same, with xe_gen_wa_oob generating the slightly different table. Object sizes delta are negligible, but having just one logic makes it easier to maintain: add/remove: 0/0 grow/shrink: 1/2 up/down: 160/-269 (-109) Function old new delta __compound_literal 6104 6264 +160 xe_wa_dump 1839 1810 -29 oob_was 816 576 -240 Total: Before=17257, After=17148, chg -0.63% Reviewed-by:
-
Lucas De Marchi authored
Like commit 512660cd ("drm/xe/rtp: Expand max rules/actions per entry") did, expand the maximum number of actions/rules. That commit was too conservative, just incrementing 2. Other than the ugliness of these macros and additional preprocessor steps when they are used, there are no downsides on increasing the maximum: the tables in which they are used use a sentinel to mark the last element. With rtp processing now supporting OR rules, it's possible to migrate the extension made for OOB WAs that "entries with name are OR'ed in previous entry". For that the maximum number of rules needs to be increased. Just double it. Hopefully 12 is sufficient for longer than 6 was. Reviewed-by:
-
Lucas De Marchi authored
Stop doing the calculation both in rtp_mark_active() and in its caller. The caller easily knows the number of entries to mark, so just pass it forward. That also simplifies rtp_mark_active() since now it doesn't have a special case when handling 1 entry. Reviewed-by:
-
Lucas De Marchi authored
The OOB WAs use xe_rtp_process(), without passing an sr to save result of the actions since there are none. They are also executed in a gt-only context, making it harder to share the implementation. Thus, introduce a new set of tests to check these RTP entries. The only check that can be done is if the entry was marked as active. Before commit fd6797ec ("drm/xe/rtp: Fix off-by-one when processing rules") several of these tests were failing: the processing of OR'ed entries would make the subsequent entry to be inadvertently enabled. Reviewed-by:
-
Lucas De Marchi authored
Those tests check the behavior of xe_rtp_process_to_sr(), so name them accordingly to allow adding tests for xe_rtp_process() later. Reviewed-by:
-
Lucas De Marchi authored
Enabling active tracking in the rtp context and check for all the tests the expected entries become active. Reviewed-by:
-
Lucas De Marchi authored
The RTP tests check both the result of processing the RTP entries and the outcome saved as SR entries. Rename "count" to be explicit about what's being counted. Reviewed-by:
-
Lucas De Marchi authored
Add one variant for BMG to make sure the workarounds do not conflict. This matches the machine with BMG in CI: BATTLEMAGE e20b:0000 dgfx:1 gfx:Xe2_LPG / Xe2_HPG (20.01) media:Xe2_LPM / Xe2_HPM (13.01) display:yes dma_m_s:46 tc:1 gscfi:0 cscfi:1 Stepping = (G:A0, M:A1, D:**, B:**) Reviewed-by: -
Matt Roper authored
Although all current Xe2 platforms support FlatCCS, we probably shouldn't assume that will be universally true forever. In the past we've had platforms like PVC that didn't support compression, and the same could show up again at some point in the future. Future-proof the migration code by adding an explicit check for FlatCCS support to the condition that decides whether to use a compressed PAT index for migration. While we're at it, we can drop the IS_DGFX check since it's redundant with the src_is_vram check (only dGPUs have VRAM). Cc: Akshata Jahagirdar <akshata.jahagirdar@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Akshata Jahagirdar <akshata.jahagirdar@intel.com> Reviewed-by:
-
- 26 Jul, 2024 2 commits
-
-
Lucas De Marchi authored
Gustavo noticed an odd "+ 2" in rtp_mark_active() while processing rtp rules and pointed that it should be "+ 1". In fact, while processing entries without actions (OOB workarounds), if the WA is activated and has OR rules, it will also inadvertently activate the very next workaround. Test in a LNL B0 platform by moving 18024947630 on top of 16020292621, makes the latter become active: $ cat /sys/kernel/debug/dri/0/gt0/workarounds ... OOB Workarounds 18024947630 16020292621 14018094691 16022287689 13011645652 22019338487_display In future a kunit test will be added to cover the rtp checks for entries without actions. Fixes: fe19328b ("drm/xe/rtp: Add support for entries with no action") Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
-
Matthew Brost authored
Ensure we are managing G2H credits correctly. Extra important now that this is tied to PM. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240725231801.1958038-1-matthew.brost@intel.com
-
- 25 Jul, 2024 5 commits
-
-
Gustavo Sousa authored
The implementations for xe_mmio_wait32() and xe_mmio_wait32_not() are almost identical. Let us avoid duplication of logic by having them calling a common __xe_mmio_wait32() function. Signed-off-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by:
-
Gustavo Sousa authored
The declaration of xe_mmio_probe_vram() became useless since commit 638d1c79 ("drm/xe: Promote VRAM initialization function to own file"). Remove it. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Add the unversioned define for the BMG HuC FW. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
As with previous binaries, we match the compatibility version instead of the build number. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Add the unversioned define for the LNL HuC FW. All new binaries are GSC-enabled (and even if they weren't the driver can detect the type of HuC binary), so the new lnl HuC filename doesn't use the _gsc postfix to avoid confusion with the GSC binary. Signed-off-by:
-
- 24 Jul, 2024 5 commits
-
-
Matthew Brost authored
Store xe_device ahead of processing message as message can be free'd in some cases. v2: - Including missing local changes v3: - Resend for CI Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202407231445.rpisd1vA-lkp@intel.com/ Fixes: d930c19f ("drm/xe: Build PM into GuC CT layer") Signed-off-by:
-
Himal Prasad Ghimiray authored
Register SOFTWARE_FLAGS_SPR33 is unused; therefore, delete it. Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240715105555.2220444-2-himal.prasad.ghimiray@intel.comSigned-off-by:
-
Lucas De Marchi authored
It's not always safe to call XE_WA() in the driver initialization. Add a xe_gt_assert() so this doesn't go unnoticed. While at it, fix typo in kernel-doc about OOB workarounds. Reviewed-by:
-
Lucas De Marchi authored
Extract functions to setup the multi-tile mmio space and extension space, while better documenting the final memory layout. No change in behavior. Reviewed-by:
-
Matthew Brost authored
'fence' argument in send_tlb_invalidation cannot be NULL, remove non-NULL check from send_tlb_invalidation. Reported-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240723190714.1744653-1-matthew.brost@intel.comSigned-off-by:
-
- 23 Jul, 2024 3 commits
-
-
Matthew Brost authored
An xe file can outlive the associated process as the GPU cleanup is just triggered upon file close (process kill) and completes sometime later. If the file close triggers error conditions (GPU hangs) the process cannot be safely referenced to retrieve the name and pid for debug information. Store the process name and pid directly in the xe file to be safe. v2: - Access file->pid via rcu_access_pointer (Matthew Auld) Fixes: b10d0c5e ("drm/xe: Add process name to devcoredump") Fixes: f6ca930d ("drm/xe: Add process name and PID to job timedout message") Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Matthew Brost authored
The size of an array of binds is directly tied to several kmalloc in the KMD, thus making these kmalloc more likely to fail. Return -ENOBUFS in the case of these failures. The expected UMD behavior upon returning -ENOBUFS is to split an array of binds into a series of single binds. v2: - Resend for CI v3: - Resend for CI Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240723011702.1684013-1-matthew.brost@intel.com
-
Matthew Brost authored
When restoring the children PT entries on a bind failure the incorrect loop index has used resulting in PT entries being leaked. This is shown by running xe_vm.bind-array-conflict-error-inject on a VRAM device going into a suspend state after the test completes. v2: - s/childern/children (CI, Matt Auld) Fixes: a708f650 ("drm/xe: Update PT layer with better error handling") Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
- 22 Jul, 2024 11 commits
-
-
Lucas De Marchi authored
eu_type_to_str() relies on -Wswitch to warn (and -Werror) to make sure it handles all enum values. However it's perfectly legal to pass an int to that function so in the end that function may happen to return nothing. There's too much implicit knowledge about the initialization of eu_type for a compiler to notice eu_type is never assigned to anything other than those values. Trying to reproduce this issue, none of gcc-9, gcc-10 and gcc-13 triggered for me, but this was reported in a different system with gcc-10: drivers/gpu/drm/xe/xe.o: warning: objtool: xe_gt_topology_dump() falls through to next function xe_gt_topology_init() Also it was reported these warnings when building with clang: drivers/gpu/drm/xe/xe.o: warning: objtool: xe_gt_topology_dump+0x77: sibling call from callable instruction with modified stack frame drivers/gpu/drm/xe/xe.o: warning: objtool: xe_gt_topology_dump() falls through to next function xe_dss_mask_group_ffs() drivers/gpu/drm/xe/xe.o: warning: objtool: xe_gt_topology_dump+0x77: can't find jump dest instruction at .text.xe_gt_topology_dump+0xc0 Since that value is not really possible in real world, just take the simple approach and return NULL. Fixes: 7108b4a5 ("drm/xe/uapi: Expose SIMD16 EU mask in topology query") Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Tested-by:
-
Michal Wajdeczko authored
In addition of NEEDS_64K BO flag, add similar one to force 2 MiB alignment of the buffer objects. Explicitly use this flag during VF LMEM provisioning as LMTT uses 2 MiB pages and one day we may drop requirement of allocating pinned objects as contiguous. Signed-off-by:
-
Michal Wajdeczko authored
In commit 62742d12 ("drm/xe: Normalize bo flags macros"), we normalized all BO flags but XE_BO_NEEDS_64K. Do it now. Signed-off-by:
-
Michal Wajdeczko authored
There is no point to run those tests on VFs devices as they can't access any of the MOCS registers. Skip testing on the VF device. [ ] =================== xe_mocs (1 subtest) ==================== [ ] ================ xe_live_mocs_kernel_kunit ================ [ ] [PASSED] 0000:4d:00.0 [ ] [SKIPPED] 0000:4d:00.1 [ ] ============ [PASSED] xe_live_mocs_kernel_kunit ============ [ ] ===================== [PASSED] xe_mocs ===================== Signed-off-by:
-
Michal Wajdeczko authored
Convert xe_mocs live tests to parameterized style. Signed-off-by:
-
Michal Wajdeczko authored
Convert xe_migrate live tests to parameterized style. Signed-off-by:
-
Michal Wajdeczko authored
Convert xe_dma_buf live tests to parameterized style. Signed-off-by:
-
Michal Wajdeczko authored
Convert xe_bo live tests to parameterized style. Signed-off-by:
-
Michal Wajdeczko authored
Instead of iterating over available Xe devices within a testcase, without being able to distinguish potential failures from different devices on system with many Xe devices, introduce helpers that will allow to treat each Xe device as a parameter for the testcase like: static void bar(struct kunit *test) { struct xe_device *xe = test->priv; ... } struct kunit_case foo_live_tests[] = { KUNIT_CASE_PARAM(bar, xe_pci_live_device_gen_param), {} }; struct kunit_suite foo_suite = { .name = "foo_live", .test_cases = foo_live_tests, .init = xe_kunit_helper_xe_device_live_test_init, }; Signed-off-by: -
Michal Wajdeczko authored
Typically we want to preserve pointer constness when converting from one xe pointer to another, but in some rare cases, like kunit parameter conversions, we might want to discard this constness. Add a helper that we will use to clearly indicate our intention. Signed-off-by:
-
Ohad Sharabi authored
The current implementation uses hardcoded values instead of common defines. v2: - Make the commit a regular commit instead of a fixup commit - slightly modify commit message Signed-off-by:
Ohad Sharabi <osharabi@habana.ai> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
- 20 Jul, 2024 2 commits
-
-
Matthew Brost authored
Take PM ref when any G2H are outstanding, drop when none are outstanding. To safely ensure we have PM ref when in the GuC CT layer, a PM ref needs to be held when scheduler messages are pending too. v2: - Add outer PM protections to xe_file_close (CI) v3: - Only take PM ref 0->1 and drop on 1->0 (Matthew Auld) v4: - Add assert to G2H increment function v5: - Rebase v6: - Declare xe as local variable in xe_file_close (CI) Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by:
-
Matthew Brost authored
Avoid GT TLB invalidation timeouts by holding a PM ref when invalidations are inflight. v2: - Drop PM ref before signaling fence (CI) v3: - Move invalidation_fence_signal helper in tlb timeout to previous patch (Matthew Auld) Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by:
-
