- 15 Jan, 2024 5 commits
-
-
Thomas Hellström authored
The pointer points to IO memory, but the __iomem annotation was incorrectly placed. Annotate it correctly, update its usage accordingly and fix the corresponding sparse error. Fixes: 0887a2e7 ("drm/xe: Make xe_mem_region struct") Cc: Oak Zeng <oak.zeng@intel.com> Cc: Michael J. Ruhl <michael.j.ruhl@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240109112405.108136-3-thomas.hellstrom@linux.intel.com (cherry picked from commit 20855b62) Signed-off-by:
-
Thomas Hellström authored
The regs pointer points to IO memory. Annotate it properly and fix the corresponding sparse warning. Fixes: a4e2f3a2 ("drm/xe: refactor xe_mmio_probe_tiles to support MMIO extension") Cc: Koby Elbaz <kelbaz@habana.ai> Cc: Ofir Bitton <obitton@habana.ai> Cc: Moti Haimovski <mhaimovski@habana.ai> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
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:
-
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:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Brian Welty <brian.welty@intel.com> (cherry picked from commit 97d0047c) 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 <jani.nikula@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit fdbadf50) Signed-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:
-
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:
-
- 22 Dec, 2023 4 commits
-
-
Dave Airlie authored
Merge tag 'drm-habanalabs-next-2023-12-19' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into drm-next This tag contains habanalabs driver changes for v6.8. The notable changes are: - uAPI changes: - Add sysfs entry to allow users to identify a device minor id with its debugfs path - Add sysfs entry to expose the device's module id as given to us from the f/w - Add signed device information retrieval through the INFO ioctl - New features and improvements: - Update documentation of debugfs paths - Add support for Gaudi2C device (new PCI revision number) - Add pcie reset prepare/done hooks - Firmware related fixes and changes: - Print three instances version numbers of Infineon second stage - Assume hard-reset is done by f/w upon PCIe AXI drain - Bug fixes and code cleanups: - Fix information leak in sec_attest_info() - Avoid overriding existing undefined opcode data in Gaudi2 - Multiple Queue Manager (QMAN) fixes for Gaudi2 - Set hard reset flag if graceful reset is skipped - Remove 'get temperature' debug print - Fix the new Event Queue heartbeat mechanism Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Oded Gabbay <ogabbay@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/ZYFpihZscr/fsRRd@ogabbay-vm-u22.habana-labs.com
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2023-12-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-next More fixes for the new imagination drier, a DT node refcount fix for the new aux bridge driver and a missing header fix for the LUT management code. Signed-off-by:
-
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. Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-xe-next-2023-12-21-pr1-1' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Introduce a new DRM driver for Intel GPUs Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms. The experimental support starts with Tiger Lake. i915 will continue be the main production driver for the platforms up to Meteor Lake and Alchemist. Then the goal is to make this Intel Xe driver the primary driver for Lunar Lake and newer platforms. It uses most, if not all, of the key drm concepts, in special: TTM, drm-scheduler, drm-exec, drm-gpuvm/gpuva and others. Signed-off-by:
-
- 21 Dec, 2023 29 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:
-
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:
-
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:
-
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 <matthew.d.roper@intel.com> Signed-off-by:
-
