- 09 Jan, 2024 5 commits
-
-
Thomas Hellström authored
If using the VM_BIND_OP_UNMAP_ALL without any bound vmas for the vm, we will end up dereferencing an uninitialized variable and leak a bo lock. Fix this. v2: - Updated commit message (Lucas De Marchi) Reported-by:
Dafna Hirschfeld <dhirschfeld@habana.ai> Closes: https://lore.kernel.org/intel-xe/jrwua7ckbiozfcaodx4gg2h4taiuxs53j5zlpf3qzvyhyiyl2d@pbs3plurokrj/Suggested-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Matthew Brost authored
Protect entire IRQ handler by CT being enabled rather than just G2H handler. v2: Return on not enabled in CT irq handler (Michal) Suggested-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Matthew Brost authored
The intent is to return -EWOULDBLOCK to the user if a long running exec queue is full during the exec IOCTL. -EWOULDBLOCK aliases to -EAGAIN which results in the exec IOCTL doing a retry loop. Fix this by ensuring the retry loop is broken when returning -EWOULDBLOCK. Fixes: 8ae8a2e8 ("drm/xe: Long running job update") Reported-by:
Sai Gowtham Ch <sai.gowtham.ch@intel.com> Signed-off-by:
Brian Welty <brian.welty@intel.com>
-
Matthew Auld authored
Looks possible to switch from CPU binding to GPU binding mid exec, and if that happens for the same dma-resv we might use two fence slots, once for the dummy fence, and another for the actual GPU bind. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/698Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com>
-
Matthew Auld authored
We currently assume that we can upfront know exactly how many fence slots we will need at the start of the exec, however the TTM bo_validate can itself consume numerous fence slots, and due to how the dma_resv_reserve_fences() works it only ensures that at least that many fence slots are available. With this it is quite possible that TTM steals some of the fence slots and then when it comes time to do the vma binding and final exec stage we are lacking enough fence slots, leading to some nasty BUG_ON(). A simple fix is to reserve our own fences later, after the validate stage. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/698Signed-off-by:
-
- 08 Jan, 2024 4 commits
-
-
Badal Nilawar authored
Release all mmap mappings for all vram objects which are associated with userfault such that, while pcie function in D3hot, any access to memory mappings will raise a userfault. Upon userfault, in order to access memory mappings, if graphics function is in D3 then runtime resume of dgpu will be triggered to transition to D0. v2: - Avoid iomem check before bo migration check as bo can migrate to system memory (Matthew Auld) v3: - Delete bo userfault link during bo destroy - Upon bo move (vram-smem), do bo userfault link deletion in xe_bo_move_notify instead of xe_bo_move (Thomas Hellström) - Grab lock in rpm hook while deleting bo userfault link (Matthew Auld) v4: - Add kernel doc and wrap vram_userfault related stuff in the structure (Matthew Auld) - Get rpm wakeref before taking dma reserve lock (Matthew Auld) - In suspend path apply lock for entire list op including list iteration (Matthew Auld) v5: - Use mutex lock instead of spin lock v6: - Fix review comments (Matthew Auld) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:Badal Nilawar <badal.nilawar@intel.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> #For the xe_bo_move_notify() changes Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Nirmoy Das authored
Recommendation is to read FUSE4 register to check if WMTP has been enabled/disabled by HW. If enabled we don't need to do anything special, however if disabled recommendation is to also disable the WMTP mode in the FF_SLICE_CS_CHICKEN2 register, falling back to thread-group and mid-batch preemption only. However on Linux, the per-context CS_CHICKEN1 is how userspace controls pre-emption, so instead use the default lrc to disable WMTP using CS_CHICKEN1, if disabled by HW. Userspace is still free to set CS_CHICKEN1 to whatever they want later. v2: remove redundant version check and also add descriptive name(Matt) v3: remove usage of REG_FIELD_GET(Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Co-developed-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20240104182615.21327-1-nirmoy.das@intel.comSigned-off-by:
-
Lucas De Marchi authored
As workarounds for pre-production DG2 were dropped in commit 707d1b992cfe ("drm/xe/dg2: Drop pre-production workarounds"), there's no point running the kunit tests for them. Drop those steppings from kunit. Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: -
Colin Ian King authored
There is a spelling mistake in a drm_info message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
-
- 05 Jan, 2024 15 commits
-
-
Michal Wajdeczko authored
It looks that declaration of kunit_get_current_test() was available in xe_guc_relay.c only with CONFIG_KUNIT enabled. If CONFIG_KUNIT is disabled we fail with: In file included from ../include/linux/build_bug.h:5, from ../include/linux/bitfield.h:10, from ../drivers/gpu/drm/xe/xe_guc_relay.c:6: ../drivers/gpu/drm/xe/xe_guc_relay.c: In function ‘xe_guc_relay_process_guc2vf’: ../drivers/gpu/drm/xe/xe_guc_relay.c:863:52: error: implicit declaration of function ‘kunit_get_current_test’ [-Werror=implicit-function-declaration] 863 | if (unlikely(!IS_SRIOV_VF(relay_to_xe(relay)) && !kunit_get_current_test())) | ^~~~~~~~~~~~~~~~~~~~~~ ../include/linux/compiler.h:77:42: note: in definition of macro ‘unlikely’ 77 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ Reported-by:Mika Kuoppala <mika.kuoppala@linux.intel.com> Fixes: 811fe9f5 ("drm/xe/guc: Introduce Relay Communication for SR-IOV") Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://lore.kernel.org/r/20240105171947.321-1-michal.wajdeczko@intel.comSigned-off-by:
-
Ruthuvikas Ravikumar authored
This kunit verifies the mocs registers content with the KMD programmed values before and after GT reset. v2: Remove extra blank lines between the local variables definitions (Matt Roper) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Ruthuvikas Ravikumar <ruthuvikas.ravikumar@intel.com> Signed-off-by:
Janga Rahul Kumar <janga.rahul.kumar@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
GuC Relay infrastructure is ready, start handling relay messages from the GuC to unblock testing on the live system. Reviewed-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20240104222031.277-11-michal.wajdeczko@intel.comSigned-off-by:
-
Michal Wajdeczko authored
Add few tests to make sure that some negative and normal use scenarios of the GuC Relay are implemented correctly. Reviewed-by:
-
Michal Wajdeczko authored
We want to use replacement functions in upcoming kunit tests. Reviewed-by:
-
Michal Wajdeczko authored
There are scenarios where SR-IOV Virtual Function (VF) driver will need to get additional data that is not available over VF MMIO BAR nor could be queried from the GuC firmware and must be obtained from the Physical Function (PF) driver. To allow such communication between VF and PF drivers, GuC supports set of H2G and G2H actions which allows relaying embedded messages, that are otherwise opaque for the GuC. To allow use of this communication mechanism, provide functions for sending requests and handling replies and placeholder where we will put handlers for incoming requests. Reviewed-by:
-
Michal Wajdeczko authored
The communication between Virtual Function (VF) drivers and Physical Function (PF) drivers is based on the GuC firmware acting as a proxy (relay) agent. Add related ABI definitions that we will be using in upcoming patches with our GuC Relay implementation. Reviewed-by:
-
Michal Wajdeczko authored
In upcoming new GuC ABI definitions we will want to refer to max number of dwords that could fit into CTB HXG message. Add explicit definition named as GUC_CTB_MAX_DWORDS and start using it. Reviewed-by:
-
Michal Wajdeczko authored
In addition to MMIO and CTB communication between the host driver and the GUC firmware, we will start using GuC HXG message protocol in communication between SR-IOV VFs and PF. Define helpers related to HXG message protocol to minimize code duplication. Reviewed-by:
-
Michal Wajdeczko authored
To simplify logging and help identify SR-IOV specific messages related to the GT, define set of helper macros that will add prefix to the messages based on the current SR-IOV mode. Reviewed-by:
-
Michal Wajdeczko authored
According to the PCI Express specification, the SR-IOV Virtual Functions (VFs) are numbered starting with 1 (VF1, VF2, ...). Additionally, both driver and GuC will refer to Physical Function (PF) as VF0. Define helper macro to represent VFn and PF. Reviewed-by:
-
Michal Wajdeczko authored
We plan to use several workers where we might be running long operations. Allocate dedicated workqueue to avoid undesired interaction with non-virtualized workers. Reviewed-by:
-
José Roberto de Souza authored
Now intel_wakeref_t is a unsigned long and Xe KMD version of those functions should use the same type, so changing from bool to intel_wakeref_t. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
José Roberto de Souza authored
i915 defines it as unsigned long so Xe should do the same to avoid compilation warnings: CC [M] drivers/gpu/drm/i915/i915_gem.o CC [M] drivers/gpu/drm/xe/i915-display/intel_display_power_well.o In file included from ./include/drm/drm_mm.h:51, from drivers/gpu/drm/xe/xe_bo_types.h:11, from drivers/gpu/drm/xe/xe_bo.h:11, from ./drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h:11, from ./drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:15, from drivers/gpu/drm/i915/display/intel_display_power.c:8: drivers/gpu/drm/i915/display/intel_display_power.c: In function ‘print_async_put_domains_state’: drivers/gpu/drm/i915/display/intel_display_power.c:408:29: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘int’ [-Wformat=] 408 | drm_dbg(&i915->drm, "async_put_wakeref %lu\n", | ^~~~~~~~~~~~~~~~~~~~~~~~~ 409 | power_domains->async_put_wakeref); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | int ./include/drm/drm_print.h:410:39: note: in definition of macro ‘drm_dev_dbg’ 410 | __drm_dev_dbg(NULL, dev, cat, fmt, ##__VA_ARGS__) | ^~~ ./include/drm/drm_print.h:510:33: note: in expansion of macro ‘drm_dbg_driver’ 510 | #define drm_dbg(drm, fmt, ...) drm_dbg_driver(drm, fmt, ##__VA_ARGS__) | ^~~~~~~~~~~~~~ drivers/gpu/drm/i915/display/intel_display_power.c:408:9: note: in expansion of macro ‘drm_dbg’ 408 | drm_dbg(&i915->drm, "async_put_wakeref %lu\n", | ^~~~~~~ drivers/gpu/drm/i915/display/intel_display_power.c:408:50: note: format string is defined here 408 | drm_dbg(&i915->drm, "async_put_wakeref %lu\n", | ~~^ | | | long unsigned int | %u CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CC [M] drivers/gpu/drm/xe/i915-display/intel_display_trace.o CC [M] drivers/gpu/drm/xe/i915-display/intel_display_wa.o CC [M] drivers/gpu/drm/i915/i915_query.o Fixes: 44e69495 ("drm/xe/display: Implement display support") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: -
Jani Nikula authored
intel_wakeref_t is supposed to be a mostly opaque cookie to its users. It should only be checked for being non-zero and set to zero. Debug logging its actual value is meaningless. Switch to just debug logging whether the async_put_wakeref is non-zero. The issue dates back to much earlier than commit b49e894c ("drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library"), but this is the one that brought about a build failure due to the printf format. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20240102111222.2db11208@canb.auug.org.au Fixes: b49e894c ("drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library") Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104164600.783371-1-jani.nikula@intel.com
-
- 27 Dec, 2023 1 commit
-
-
Lucas De Marchi authored
Graphics version 20.04, used in Lunar Lake, needs WA 16020183090 for steppings A*. Set ENABLE_SEMAPHORE_POLL_BIT in INSTPM(RENDER_RING_BASE) and whitelist CSBE_DEBUG_STATUS for userspace to be able to use it and complement the workaround. Cc: Haridhar Kalvala <haridhar.kalvala@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
- 26 Dec, 2023 1 commit
-
-
José Roberto de Souza authored
This is a comment left over of commit d3d76739 ("drm/xe/uapi: Remove sync binds"). Fixes: d3d76739 ("drm/xe/uapi: Remove sync binds") Reviewed-by:
-
- 22 Dec, 2023 1 commit
-
-
Lucas De Marchi authored
Add a dependency on CONFIG_64BIT since currently the xe driver doesn't build on 32bits. It may be enabled again after all the issues are fixed. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reviewed-by:
-
- 21 Dec, 2023 13 commits
-
-
Daniele Ceraolo Spurio authored
We're currently sending non-blocking H2G messages using the EVENT type, which suppresses all CTB protocol replies from the GuC, including the failure cases. This might cause errors to slip through and manifest as unexpected behavior (e.g. a context state might not be what the driver thinks it is because the state change command was silently rejected by the GuC). To avoid this kind of problems, we can use the FAST_REQUEST type instead, which suppresses the reply only on success; this way we still get the advantage of not having to wait for an ack from the GuC (i.e. the H2G is still non-blocking) while still detecting errors. Since we can't escalate to the caller when a non-blocking message fails, we need to escalate to GT reset instead. Note that FAST_REQUEST failures are NOT expected and are usually a sign that the H2G was either malformed or requested an illegal operation. v2: assign fence values to FAST_REQUEST messages, fix abi doc, use xe_gt printers (Michal). v3: fix doc alignment, fix and improve prints (Michal) 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> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v2 Reviewed-by:
-
Tejas Upadhyay authored
Wa_14019877138 is also needed for xe_lpg graphics 12.70/71 Reviewed-by:
Tejas Upadhyay <tejas.upadhyay@intel.com>
-
Michal Wajdeczko authored
Add few tests to make sure that basic usage scenarios of the GuC Doorbells Manager are implemented correctly. Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Tests might use locking, better to have LOCKDEP enabled. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Use xe helper code to allocate fake xe device. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Replace drm_kunit_helper_alloc_drm_device with xe helper. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Current KUnit implementation does not reset test->priv in case of parametrized tests and that may lead to wrongly treat our output pointer to fake xe_device from first call as input pointer with xe_pci_fake_data on subsequent calls. Restore test->priv to original value to avoid invalid access. Acked-by:
-
Michal Wajdeczko authored
There will be more KUnit tests added that will require fake device. Define generic helper functions to avoid code duplications. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
We want to add code that will check the driver's SR-IOV mode. Update xe_pci_fake_device_init() and struct xe_pci_fake_data to either explicitly specify desired SR-IOV mode of the fake device or fallback to the default bare-metal mode. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
The GFX doorbell solution provides a mechanism for submission of workload to the graphics hardware by a ring3 application without the penalty of ring transition for each workload submission. This feature is not currently used by the Linux drivers, but in SR-IOV mode the doorbells are treated as shared resource and the PF driver must be able to provision exclusive range of doorbells IDs across all enabled VFs. Introduce simple GuC doorbell ID manager that will be used by the PF driver for VFs provisioning and can later be used by submission code once we are ready to switch from H2G based notifications to doorbells mechanism. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
We track TLB invalidation seqno per GT and we have GT oriented message helpers, so it's better to use GT oriented log functions. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Instead of using generic drm_err_printer() that just adds static prefix, or drm_info_printer() that outputs only device name, add new helpers that create dedicated drm_printers that use our GT oriented xe_gt_err() and xe_gt_info() functions. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
There are small differences in handling of the register based interrupts on the VF driver as some registers are not accessible to the VF driver. Additionally VFs must support Memory Based Interrupts. Add VF specific interrupt handler for this. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
