- 05 Jan, 2024 3 commits
-
-
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 <jose.souza@intel.com>
-
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:
Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20231207175117.2334022-1-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
- 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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-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 23 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:
Michal Wajdeczko <michal.wajdeczko@intel.com>
-
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:
Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20231218190629.502-11-michal.wajdeczko@intel.comSigned-off-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:
-
Michal Wajdeczko authored
When Memory Based Interrupts are used, the VF driver must provide to the GuC references to the Source and Status Report Pages. Reviewed-by:
-
Michal Wajdeczko authored
When Memory Based Interrupts are used, the VF driver must provide in the LRC the references to the Source and Status Report Pages. Update the LRC according to the requirements. Reviewed-by:
-
Michal Wajdeczko authored
The register based interrupts infrastructure does not scale efficiently to allow delivering interrupts to a large number of virtual machines. Memory based interrupt reporting provides an efficient and scalable infrastructure. Define handler to read and dispatch memory based interrupts. We will use this handler in upcoming patch. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
When we map BO in GGTT, then by default we are using PAT index that corresponds to XE_CACHE_WB but ppcoming feature will require use of the PAT index of the XE_CACHE_UC. Define new BO flag that could be used during BO creation to force alternate caching. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
When interrupts are delivered using memory based mechanism, engines will write status to the report page at the offset (in bytes) that corresponds to their interrupt bit from the GT_INTR_DW register. Add engine interrupt offset definitions to engine info as we will need this to process memory based interrupts. Bspec: 46149, 50829, 50844 Reviewed-by:
-
Michal Wajdeczko authored
Add bits definitions that we will be using in upcoming patch. Reviewed-by:
-
Michal Wajdeczko authored
The new memory based interrupt processing uses additional entries in the context. Add required definitions. Bspec: 45585, 60184 Reviewed-by:
-
Michal Wajdeczko authored
The RING_INT_SRC_RPT_PTR register points to a cacheline in memory to which an engine must report as source of interrupt prior to generating an interrupt to the host. The RING_INT_STATUS_RPT_PTR register points to the first cacheline of the Interrupt Status Report (ISR) page (4KB) in graphics memory to which all engines report their interrupt status. The RING_IMR register has the interrupt enables and interrupt masks for an engine. We will refer to these registers shortly. Bspec: 45963, 45964, 45965 Reviewed-by:
-
Michal Wajdeczko authored
We will need this shortly during context state preparation. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Matt Roper authored
Pre-production hardware is anything before C0 (for DG2-G10), before B1 (for DG2-G11), or before A1 (for DG2-G12). Workarounds specific to such hardware was already removed from i915 in commit eaeb4b36 ("drm/i915/dg2: Drop pre-production GT workarounds") and there's even less value keeping these around in the Xe driver. v2: - Drop Wa_14011441408 from xe_mocs.c. (Gustavo) - Drop Wa_14010648519, Wa_14010198302, and Wa_1608949956 which were mis-implemented; they were only supposed to apply to early steppings of DG2-G10, but were being applied unconditionally on all DG2. (Gustavo) - Drop reference to Wa_16011620976; the implementation stays because it still matches Wa_22015475538. (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20231215214531.2576215-2-matthew.d.roper@intel.comSigned-off-by:
-
- 26 Dec, 2023 2 commits
-
-
Lucas De Marchi authored
Having a different value for op is not possible: this is already kept out of user-visible warning by the check in xe_wait_user_fence_ioctl() if op > MAX_OP. The warning is useful as if this switch() is not update when a new op is added, it should be triggered. Fix warning as reported by 0-DAY CI Kernel: drivers/gpu/drm/xe/xe_wait_user_fence.c:46:2: warning: variable 'passed' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] Closes: https://lore.kernel.org/oe-kbuild-all/202312170357.KPSinwPs-lkp@intel.com/ Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reviewed-by:
-
Matthew Brost authored
add_preempt_fences() calls dma_resv_reserve_fences() with num_fences == 0 resulting in the below UBSAN splat. Short circuit add_preempt_fences() if num_fences == 0. [ 58.652241] ================================================================================ [ 58.660736] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 [ 58.667281] shift exponent 64 is too large for 64-bit type 'long unsigned int' [ 58.674539] CPU: 2 PID: 1170 Comm: xe_gpgpu_fill Not tainted 6.6.0-rc3-guc+ #630 [ 58.674545] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.3243.A01.2006102133 06/10/2020 [ 58.674547] Call Trace: [ 58.674548] <TASK> [ 58.674550] dump_stack_lvl+0x92/0xb0 [ 58.674555] __ubsan_handle_shift_out_of_bounds+0x15a/0x300 [ 58.674559] ? rcu_is_watching+0x12/0x60 [ 58.674564] ? software_resume+0x141/0x210 [ 58.674575] ? new_vma+0x44b/0x600 [xe] [ 58.674606] dma_resv_reserve_fences.cold+0x40/0x66 [ 58.674612] new_vma+0x4b3/0x600 [xe] [ 58.674638] xe_vm_bind_ioctl+0xffd/0x1e00 [xe] [ 58.674663] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] [ 58.674680] drm_ioctl_kernel+0xc1/0x170 [ 58.674686] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] [ 58.674703] drm_ioctl+0x247/0x4c0 [ 58.674709] ? find_held_lock+0x2b/0x80 [ 58.674716] __x64_sys_ioctl+0x8c/0xb0 [ 58.674720] do_syscall_64+0x3c/0x90 [ 58.674723] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 58.674727] RIP: 0033:0x7fce4bd1aaff [ 58.674730] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 [ 58.674731] RSP: 002b:00007ffc57434050 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 58.674734] RAX: ffffffffffffffda RBX: 00007ffc574340e0 RCX: 00007fce4bd1aaff [ 58.674736] RDX: 00007ffc574340e0 RSI: 0000000040886445 RDI: 0000000000000003 [ 58.674737] RBP: 0000000040886445 R08: 0000000000000002 R09: 00007ffc574341b0 [ 58.674739] R10: 000055de43eb3780 R11: 0000000000000246 R12: 00007ffc574340e0 [ 58.674740] R13: 0000000000000003 R14: 00007ffc574341b0 R15: 0000000000000001 [ 58.674747] </TASK> [ 58.674748] ================================================================================ Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
- 21 Dec, 2023 9 commits
-
-
Lucas De Marchi authored
"err" is not initialized when failing to create and add the freq0 sysfs file. Remove it from the message. This fixes the following warning with clang: ../drivers/gpu/drm/xe/xe_gt_freq.c:202:30: error: variable 'err' is uninitialized when used here [-Werror,-Wuninitialized] kobject_name(gt->sysfs), err); ^~~ Fixes: bef52b5c ("drm/xe: Create a xe_gt_freq component for raw management and sysfs") Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Link: https://lore.kernel.org/r/20231220161923.3740489-1-lucas.demarchi@intel.comSigned-off-by:
-
Daniele Ceraolo Spurio authored
As part of the FW definitions, we declare each blob as required via the MODULE_FIRMWARE() macro. This causes the initramfs update (or equivalent process) to look for the blobs on disk when the kernel is installed; therefore, we need to make sure that all FWs we define are available in linux-firmware. We currently don't plan to push the PVC blob to linux-firmware, while the LNL one will only be pushed once we have machines in CI to test it, so we need to remove them from the list for now. Signed-off-by:
-
Rodrigo Vivi authored
Ideally this header could be included without the CONFIG_FAULT_INJECTION and it would take care itself for the includes it needs. So, let's temporary workaround this by moving this below and including only when CONFIG_FAULT_INJECTION is selected to avoid build breakages. Another solution would be us including the linux/types.h as well, but this creates unnecessary cases. Reference: https://lore.kernel.org/all/20230816134748.979231-1-himal.prasad.ghimiray@intel.com/ Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Oded Gabbay <ogabbay@kernel.org> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
Rodrigo Vivi authored
Introduce the Maintainers of the new drm/xe driver for upcoming Intel GPUs. Since it has a shared display with drm/i915, let's also create a dedicated block to group display related files. But without any substantial change to the i915 side. The display patches will continue to flow through i915 from drm-intel-next branches for now. Acked-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Acked-by:
Oded Gabbay <ogabbay@kernel.org> Acked-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Rodrigo Vivi authored
This kernel uevent is getting removed for now. It will come back later with a better future proof name. v2: Rebase (Francois Dugast) Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com> Signed-off-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Acked-by:
Mateusz Naklicki <mateusz.naklicki@intel.com> Signed-off-by:
Francois Dugast <francois.dugast@intel.com>
-
Francois Dugast authored
Bring those defines close to the context where they can be used. Also apply indentation as it is done for other subsets of defines. Reviewed-by:
-
Francois Dugast authored
Move those defines to align on the rule used elsewhere in the file which was introduced by commit 4f082f2c ("drm/xe: Move defines before relevant fields"). Reviewed-by:
-
Francois Dugast authored
Complete the documentation of some structs by adding functional examples of user space code. Those examples are intentionally kept very simple. Put together, they provide a foundation for a minimal application that executes a job using the Xe driver. v2: Remove use of DRM_XE_VM_BIND_FLAG_ASYNC (Francois Dugast) Reviewed-by:
-
Francois Dugast authored
In order to make proper use the uAPI, a prerequisite is to understand some key concepts about the discrete GPU devices which are supported by the Xe driver. For example, some structs defined in the uAPI are an abstraction of a hardware component with a specific role. This diagram helps to build a mental representation of a device how it is seen by the Xe driver. As written in the documentation, it does not intend to be a literal representation of an existing device. A lot more information could be added but the intention for the overview is to keep it simple, and go into detail as needed in other sections. v2: Add GT1 inside Tile0 (José Roberto de Souza) Reviewed-by:
-
