- 21 Dec, 2023 3 commits
-
-
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:
Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20231214185955.1791-3-michal.wajdeczko@intel.comSigned-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com>
-
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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20231218163301.3453285-1-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-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 35 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:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-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:
Jani Nikula <jani.nikula@intel.com> 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:
José Roberto de Souza <jose.souza@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:
-
Rodrigo Vivi authored
The uAPI should stay generic in regarding to the bitmask. It is the userspace responsibility to check for the type/class of the memory, without any assumption. Also add comments inside the code to explain how it is actually constructed so we don't accidentally change the assignment of the instance and the masks. No functional change in this patch. It only explains and document the memory_region masks. A further follow-up work with the organization of all memory regions around struct xe_mem_regions is desired, but not part of this patch. Signed-off-by:
-
Rodrigo Vivi authored
No functional change in this patch. Let's ensure all of our structs are documented and with a certain standard. Also, let's have an overview and list of IOCTLs as the very beginning of the generated HTML doc. v2: Nits (Lucas De Marchi) Signed-off-by:
-
Rodrigo Vivi authored
This patch doesn't modify any text or uapi entries themselves. It only move things up and down aiming a better organization of the uAPI. While fixing the documentation I noticed that query_engine_cs_cycles was in the middle of the memory_region info. Then I noticed more mismatches on the order when compared to the order of the IOCTL and QUERY entries declaration. So this patch aims to bring some order to the uAPI so it gets easier to read and the documentation generated in the end is able to tell a consistent story. Overall order: 1. IOCTL definition 2. Extension definition and helper structs 3. IOCTL's Query structs in the order of the Query's entries. 4. The rest of IOCTL structs in the order of IOCTL declaration. 5. uEvents Signed-off-by:
-
Francois Dugast authored
As there is no direct way to make comments of constants directly visible in the kernel doc, move them to the description of the structure where they can be used. By doing so they appear in the "Description" section of the struct documentation. v2: Remove DRM_XE_UFENCE_WAIT_MASK_* (Francois Dugast) Reviewed-by:
-
Francois Dugast authored
Add a documentation on the content and format of when using query type DRM_XE_DEVICE_QUERY_HWCONFIG. The list of keys can be found in IGT under lib/intel_hwconfig_types.h. Reviewed-by:
-
Francois Dugast authored
Provide a description of the keys used the struct drm_xe_query_config info array. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/637Reviewed-by:
-
Francois Dugast authored
Document the behavior of the driver for IOCTL DRM_IOCTL_XE_DEVICE_QUERY depending on the size value provided in struct drm_xe_device_query. Reviewed-by:
-
Francois Dugast authored
This removes the documentation build warnings below: include/uapi/drm/xe_drm.h:828: warning: Function parameter or \ member 'pad2' not described in 'drm_xe_vm_bind_op' include/uapi/drm/xe_drm.h:875: warning: Function parameter or \ member 'pad2' not described in 'drm_xe_vm_bind' include/uapi/drm/xe_drm.h:1006: warning: Function parameter or \ member 'handle' not described in 'drm_xe_sync' include/uapi/drm/xe_drm.h:1006: warning: Function parameter or \ member 'timeline_value' not described in 'drm_xe_sync' Reviewed-by:
-
Francois Dugast authored
Add a comment to each struct to complete documentation, ensure all struct appear in the kernel doc, and bind structs to IOCTLs. Reviewed-by:
-
Matthew Brost authored
Remove concept of async vs sync VM bind queues, rather make all binds async. The following bits have dropped from the uAPI: DRM_XE_ENGINE_CLASS_VM_BIND_ASYNC DRM_XE_ENGINE_CLASS_VM_BIND_SYNC DRM_XE_VM_CREATE_FLAG_ASYNC_DEFAULT DRM_XE_VM_BIND_FLAG_ASYNC To implement sync binds the UMD is expected to use the out-fence interface. v2: Send correct version v3: Drop drm_xe_syncs Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
To ensure consistency and avoid possible later conflicts, let's add drm_xe prefix to xe_user_extension struct. Cc: Francois Dugast <francois.dugast@intel.com> Suggested-by:
-
Ashutosh Dixit authored
PMU uapi is likely to change in the future. Till the uapi is finalized, remove PMU from Xe. PMU can be re-added after uapi is finalized. v2: Include xe_drm.h in xe/tests/xe_dma_buf.c (Francois) Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Acked-by:
Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com> Acked-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Acked-by:
-
Francois Dugast authored
Those are just possible values for the comparison mask but they are not specific magic values. Let's keep them as examples in the documentation but remove them from the uAPI. Suggested-by:
-
Francois Dugast authored
The exec_queue_set_property feature was removed in a previous commit 0f1d88f2 ("drm/xe/uapi: Kill exec_queue_set_property") and is no longer usable, struct drm_xe_exec_queue_set_property does not exist anymore, so let's remove this. Reviewed-by:
-
Bommu Krishnaiah authored
Currently xe_wait_user_fence_ioctl is not checking exec_queue state and blocking until timeout, with this patch wakeup the blocking wait if exec_queue reset happen and returning proper error code Signed-off-by:
Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Oak Zeng <oak.zeng@intel.com> Cc: Kempczynski Zbigniew <Zbigniew.Kempczynski@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Bommu Krishnaiah authored
remove the num_engines/instances members from drm_xe_wait_user_fence structure and add a exec_queue_id member Right now this is only checking if the engine list is sane and nothing else. In the end every operation with this IOCTL is a soft check. So, let's formalize that and only use this IOCTL to wait on the fence. exec_queue_id member will help to user space to get proper error code from kernel while in exec_queue reset Signed-off-by:
-
Lucas De Marchi authored
Like done in commit 2250c7ea ("drm/i915: enable W=1 warnings by default") for i915, enable W=1 warnings by default in xe. Reviewed-by:
-
Lucas De Marchi authored
When CONFIG_DRM_I915_DEBUG is not set, a dummy __i915_inject_probe_error() is provided on the xe side. Use the same logic as in drivers/gpu/drm/i915/i915_utils.c to ifdef it out. This fixes the build with W=1 and without that config: CC [M] drivers/gpu/drm/xe/display/ext/i915_utils.o ../drivers/gpu/drm/xe/display/ext/i915_utils.c:19:5: error: no previous prototype for ‘__i915_inject_probe_error’ [-Werror=missing-prototypes] 19 | int __i915_inject_probe_error(struct drm_i915_private *i915, int err, | ^~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by:
-
Lucas De Marchi authored
bo is not used since all the checks are against tbo. Fix warning: ../drivers/gpu/drm/xe/xe_bo.c: In function ‘xe_evict_flags’: ../drivers/gpu/drm/xe/xe_bo.c:250:23: error: variable ‘bo’ set but not used [-Werror=unused-but-set-variable] 250 | struct xe_bo *bo; Signed-off-by:
-
Lucas De Marchi authored
Fix warning: ../drivers/gpu/drm/xe/xe_ttm_vram_mgr.c: In function ‘__xe_ttm_vram_mgr_init’: ../drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:340:13: error: variable ‘err’ set but not used [-Werror=unused-but-set-variable] 340 | int err; | ^~~ Check for the error return and return it, like done by other drivers. Reviewed-by:
-
Matt Roper authored
Several files were including register headers that they no longer require. Drop the unnecessary includes to reduce build dependencies. Reviewed-by:
-
Matt Roper authored
Keeping the register definitions sorted will make it easy to find existing definitions and prevent accidental introduction of duplicate definitions. v2: - Reorder FUSE3/FUSE4 registers and move GT0_PERF_LIMIT_REASONS / MTL_MEDIA_PERF_LIMIT_REASONS to proper places. (Lucas) Reviewed-by:
-
Matt Roper authored
The bit definitions had become a bit orphaned; move them to the same location as the interrupt registers that they're used with. Reviewed-by:
-
Matt Roper authored
These offsets are only used to setup the auxiliary device BAR information and are never used for driver read/write operations. Move them to the GSC HECI file where they're actually used. Reviewed-by:
-
Matt Roper authored
These offsets are primarily used as parameters for the engine register definitions, so it makes more sense to define them in the engine header rather than the general register header. Reviewed-by:
-
Matt Roper authored
Our register headers use tabs to align the definition values. Convert a few definitions that were using spaces instead. Reviewed-by:
-
