- 22 Dec, 2023 1 commit
-
-
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:
Dave Airlie <airlied@redhat.com> [airlied: add an extra X86 check, fix a typo, fix drm_exec_init interface change]. From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZYSwLgXZUZ57qGPQ@intel.com
-
- 21 Dec, 2023 39 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:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
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:
-
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:
Matthew Brost <matthew.brost@intel.com> Reviewed-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:
-
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:
-
Matt Roper authored
Although we only work with the RCS instances today, the FF_SLICE_CS_CHICKEN1[1,2] CS_DEBUG_MODE1, CS_CHICKEN1, and FF_THREAD_MODE registers all have instances on both the RCS and CCS engines. Convert these to parameterized macros and move them to the engine register header. Reviewed-by:
-
Matt Roper authored
We don't use this suffix on any other registers, and it isn't part of the register's official name either, so drop it for consistency. While at it, move the register definition slightly so that it isn't separating RING_CMD_CCTL's definition from its fields. Reviewed-by:
-
Himal Prasad Ghimiray authored
Enable flat ccs for XE2_GFX_FEATURES. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Himal Prasad Ghimiray authored
Modify test to valid ccs clear and copy during evict/restore on igfx. v2: -Vram is associated with tiles not with gt. Use tile based iterator for ccs_test_run_gt. (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
