- 21 Dec, 2023 40 commits
-
-
Michal Wajdeczko authored
We will be using extra logs during enabling of the SR-IOV features or when adding support for new platforms. Define separate config flag to keep that low level logs disabled if we're not debugging. Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20231128151507.1015-2-michal.wajdeczko@intel.comSigned-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Niranjana Vishwanathapura authored
Ensure that there are no drm clients when changing CCS mode. Allow exec_queue creation only with enabled CCS engines. v2: Rebase Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
-
Niranjana Vishwanathapura authored
Allow user to configure the CCS mode setting through a 'ccs_mode' sysfs interface. Also report the current CCS mode configuration and number of compute slices available through this interface. v2: Rebase, make it platform agnostic v3: Separte out num_cslices sysfs interface and make xe_gt_ccs_mode_sysfs_init() return void Reviewed-by: -
Niranjana Vishwanathapura authored
Disable dynamic HW load balancing of compute resource assignment to engines and instead enabled fixed mode of mapping compute resources to engines on all platforms with more than one compute engine. By default enable only one CCS engine with all compute slices assigned to it. This is the desired configuration for common workloads. PVC platform supports only the fixed CCS mode (workaround 16016805146). v2: Rebase, make it platform agnostic v3: Minor code refactoring Reviewed-by:
-
Tejas Upadhyay authored
This workaround applies to graphics 20.04 on all engines. Workaround has three parts : 1. Pipe flush before MI_ATOMIC - This part isn't relevant to Xe (at least not right now) since we don't use MI_ATOMIC anywhere in the kernel mode driver. 2. Memory-based interrupt masking - Memory-based interrupt processing isn't supported on physical functions, only virtual functions, according to bspec 60352. So this is probably only relevant once SRIOV support lands in the driver. 3. Disabling CSB/timestamp updates to the ghwsp and pphwsp - Workaround is added by this change. The CSB reports to gHWSP and ppHWSP have been discussed as part of a different topic on some internal threads and we've confirmed that neither the KMD nor the GuC firmware use those for anything, so disabling them is always "safe" and should have no functional or performance impact on system operation. The same is true for the timestamp updates in the ppHWSP as well. Given that, it might make sense to just combine these two workarounds into a single record (and single patch) and apply it on all steppings. Disabling the reports for RCS on higher steppings doesn't have any kind of negative impact and will simplify the overall situation. V3(MattR): - Combine WA apply same WA for all engines, no performance impact V2(MattR): - Mention detail in commit message - Reorder bit define - Improve bit naming - Remove workaround part which isnt relevant Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by:
-
Tejas Upadhyay authored
This workaround applies to Graphics 20.04 as engine workaround V2(MattR): - Reorder bit define - Apply WA for RCS only Reviewed-by:
-
Daniele Ceraolo Spurio authored
HuC authentication via GSC is performed by submitting the appropriate PXP packet to the GSC FW. This packet can trigger a "pending" reply from the FW, so we need to handle that and resubmit. Note that the auth via GSC can only be performed if the HuC has already been authenticated by the GuC. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Reviewed-by:
Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
Starting on MTL, the HuC is authenticated twice, once via GuC (same as with older integrated platforms) and once via GSC; the first authentication allows the HuC to be used for clear-media workloads, while the second one unlocks support for protected content. Ahead of adding the authentication flow via GSC, this patch adds support for differentiating the 2 auth steps and checking if they're complete. Signed-off-by:
-
Lucas De Marchi authored
Now that the kunit infra has proper support for GMD_ID platforms, add a few variants of MTL and LNL. v2: Remove bogus check for setting both media and graphics version in test (Matt Roper) Reviewed-by: -
Lucas De Marchi authored
Currently it's not possible to test the WAs for platforms using gmdid since they don't have the IP information on the descriptor struct. In order to allow that, add a stub function for read_gmdid() that is activated when the test executes, replacing the iomap and read of the real register. Reviewed-by:
-
Lucas De Marchi authored
Instead of passing as parameter to xe_pci_fake_device_init(), use test->priv to pass parameters down the call stack. The main advantage is that then the data is readily available on other functions by using kunit_get_current_test(). This is a preparation to fix the initialization of fake devices when they were supposed to be using GMD_ID. Reviewed-by:
-
Lucas De Marchi authored
The only user passing XE_TEST_SUBPLATFORM_ANY is xe_pci_fake_device_init_any(), but then the function would return earlier when handling XE_TEST_PLATFORM_ANY. Platforms without a subplatform use XE_SUBPLATFORM_NONE. Reviewed-by:
-
Lucas De Marchi authored
Expand documentation and add an example to make clear this isn't about generic masks in registers. Also, fix the doc regarding read operations: the mask part has no effect on them. Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
All the properties should be immutable and set upon exec_queue creation using the existent extension. So, let's kill this useless and dangerous uapi. Cc: Francois Dugast <francois.dugast@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Francois Dugast <francois.dugast@intel.com>
-
Rodrigo Vivi authored
The vm_create ioctl function doesn't accept any extension. Remove this left over. A backward compatible change. Cc: Francois Dugast <francois.dugast@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Thomas Hellström authored
Currently we're using "compute mode" for long running VMs using preempt-fences for memory management, and "fault mode" for long running VMs using page faults. Change this to use the terminology "long-running" abbreviated as LR for long-running VMs. These VMs can then either be in preempt-fence mode or fault mode. The user can force fault mode at creation time, but otherwise the driver can choose to use fault- or preempt-fence mode for long-running vms depending on the device capabilities. Initially unless fault-mode is specified, the driver uses preempt-fence mode. v2: - Fix commit message wording and the documentation around CREATE_FLAG_LR_MODE and CREATE_FLAG_FAULT_MODE Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Although the exec ioctl is a very important one, it makes no sense to explain xe_exec before explaining the exec_queue. So, let's move this down to help bring a better flow on the documentation and code readability. It is important to highlight that this patch is changing all the ioctl numbers in a non-backward compatible way. However, we are doing this final uapi clean-up before we submit our first pull-request to be part of the upstream Kernel. Once we get there, no other change like this will ever happen and all the backward compatibility will be respected. Signed-off-by:
-
Rodrigo Vivi authored
Let's respect Documentation/process/botching-up-ioctls.rst and add the proper padding for a 64b alignment with all as well as all the required checks and settings for the pads and the reserved entries. v2: Fix remaining holes and double check with pahole (Jose) Ensure with pahole that both 32b and 64b have exact same layout (Thomas) Do not set query's pad and reserved bits to zero since it is redundant and already done by kzalloc (Matt) v3: Fix alignment after rebase (José Roberto de Souza) v4: Fix pad check (Francois Dugast) Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: -
Rodrigo Vivi authored
As an information only. So Userspace can use this information and be able to correlate different GTs. Make API symmetric between Engine and GT info. There's no need right now to include a tile_query entry since there's no other information that we need from tile that is not already exposed through different queries. However, this could be added later if we have different Tile information that could matter to userspace. But let's keep the API ready for a direct reference to Tile ID based on the GT entry. Signed-off-by:
-
Rodrigo Vivi authored
First of all, let's remove the duplication. But also, let's rename it to remove the word 'frequency' out of it. In general, the first thing people think of frequency is the frequency in which the GTs are operating to execute the GPU instructions. While this frequency here is a crystal reference clock frequency which is the base of everything else, and in this case of this uAPI it is used to calculate a better and precise timestamp. v2: (Suggested by Jose) Remove the engine_cs and keep the GT info one since it might be useful for other SRIOV cases where the engine_cs will be zeroed. So, grabbing from the GT_LIST should be cleaner. v3: Keep comment on put_user() call (José Roberto de Souza) Cc: Matt Roper <matthew.d.roper@intel.com> Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Jose Souza <jose.souza@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
It is currently unused, so by the rules it cannot go upstream. Also there was the desire to convert that to align with the engine_class_instance selection, but the consensus on that one is to remain with the global gt_id. So we are keeping the gt_id there, not converting to a generic sched_group and also killing this tile_mask and only using the default behavior of 0 that is to create a mapping / page_table entry on every tile, similar to what i915. Signed-off-by:
-
Rodrigo Vivi authored
Let's continue on the uapi clean-up with more splits with stuff into their own exclusive fields instead of reusing stuff. Signed-off-by:
-
Francois Dugast authored
The uAPI provides queries which return arrays of elements. As of now the format used in the struct is different depending on which element is queried. Fix this for engines by applying the pattern below: struct drm_xe_query_Xs { __u32 num_Xs; struct drm_xe_X Xs[]; ... } Instead of directly returning an array of struct drm_xe_query_engine_info, a new struct drm_xe_query_engines is introduced. It contains itself an array of struct drm_xe_engine which holds the information about each engine. v2: Use plural for struct drm_xe_query_engines as multiple engines are returned (José Roberto de Souza) Signed-off-by: -
Francois Dugast authored
The uAPI provides queries which return arrays of elements. As of now the format used in the struct is different depending on which element is queried. However, aligning on the new common pattern: struct drm_xe_query_Xs { __u32 num_Xs; struct drm_xe_X Xs[]; ... } ... would mean bringing back the name "gts" which is avoided per commit fca54ba12470 ("drm/xe/uapi: Rename gts to gt_list") so make an exception for gt and leave gt_list. Also, this change removes "query" in the name of struct drm_xe_query_gt as it is not returned from the query IOCTL. There is no functional change. v2: Leave gt_list (Matt Roper) Signed-off-by: -
Francois Dugast authored
The uAPI provides queries which return arrays of elements. As of now the format used in the struct is different depending on which element is queried. Fix this for memory regions by applying the pattern below: struct drm_xe_query_Xs { __u32 num_Xs; struct drm_xe_X Xs[]; ... } This removes "query" in the name of struct drm_xe_query_mem_region as it is not returned from the query IOCTL. There is no functional change. v2: Only rename drm_xe_query_mem_region to drm_xe_mem_region (José Roberto de Souza) v3: Rename usage to mem_regions in xe_query.c (José Roberto de Souza) Signed-off-by: -
Mauro Carvalho Chehab authored
For xe bo creation we request passing size which matches system or vram minimum page alignment. This way we want to ensure userspace is aware of region constraints and not aligned allocations will be rejected returning EINVAL. v2: - Rebase, Update uAPI documentation. (Thomas) v3: - Adjust the dma-buf kunit test accordingly. (Thomas) v4: - Fixed rebase conflicts and updated commit message. (Francois) Signed-off-by:
Mauro Carvalho Chehab <mauro.chehab@linux.intel.com> Signed-off-by:
Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
We have at least 2 future features(OA and future media engines capabilities) that will require Xe to provide more information about engines to UMDs. But this information should not just be added to drm_xe_engine_class_instance for a couple of reasons: - drm_xe_engine_class_instance is used as input to other structs/uAPIs and those uAPIs don't care about any of these future new engine fields - those new fields are useless information after initialization for some UMDs, so it should not need to carry that around So here my proposal is to make DRM_XE_DEVICE_QUERY_ENGINES return an array of drm_xe_query_engine_info that contain drm_xe_engine_class_instance and 3 u64s to be used for future features. Reference OA: https://patchwork.freedesktop.org/patch/558362/?series=121084&rev=6 v2: Reduce reserved[] to 3 u64 (Matthew Brost) Cc: Francois Dugast <francois.dugast@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Although the flags are about the creation, the memory placement of the BO deserves a proper dedicated field in the uapi. Besides getting more clear, it also allows to remove the 'magic' shifts from the flags that was a concern during the uapi reviews. Signed-off-by:
-
Mika Kuoppala authored
The bind api is extensible but for a single bind op, there is not a mechanism to extend. Add extensions field to struct drm_xe_vm_bind_op. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Matthew Auld authored
From the CI logs we want to easily know if the machine is capable and allowed to enter d3cold, and can therefore potentially trigger the d3cold RPM suspend and resume path. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Riana Tauro <riana.tauro@intel.com> Reviewed-by:
-
Michał Winiarski authored
Move params that are not used for initial "hwconfig" load to "post-hwconfig" phase. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
Michał Winiarski authored
Earlier GuC load will require more fine-grained control over reset. Extract it outside of xe_uc_init_hw. Signed-off-by:
-
Michał Winiarski authored
The firmware loading for GuC is about to be moved, and will happen much earlier in the probe process, when local-memory is not yet available. While this has the potential to make the firmware loading process slower, this is only happening during probe and full device reset. Since both are not hot-paths - store all UC-like firmware in system memory. Signed-off-by:
-
Michał Winiarski authored
The function does a driver specific "request firmware" step that includes validating the input, followed by wrapping the firmware binary into a buffer object. Split it into smaller parts. Signed-off-by:
-
Michał Winiarski authored
A helper for managed BO allocations makes it possible to remove specific "fini" actions and will simplify the following patches adding ability to execute a release action for specific BO directly. Signed-off-by:
-
Michał Winiarski authored
GuC will need to be loaded earlier during probe. Having functional GGTT is one of the prerequisites. Also rename xe_ggtt_init_noalloc to xe_ggtt_init_early to match the new call site. Signed-off-by:
-
Michał Winiarski authored
GuC will need to be loaded earlier during probe. And in order to load GuC, being able to take the forcewake is going to be needed. Signed-off-by:
-
Michał Winiarski authored
GuC will need to be loaded earlier during probe. And in order to load GuC, we will need the ability to create system memory allocations. Signed-off-by:
-
Michał Winiarski authored
Now that MMIO init got moved to device early, we can use regular xe_mmio_read helpers to get to GMD_ID register. Signed-off-by:
-
Michał Winiarski authored
SR-IOV VF doesn't have access to MMIO registers used to determine graphics/media ID. It can however communicate with GuC. Introduce xe_device_probe_early, which initializes enough HW to use MMIO GuC communication. This will allow both VF and PF/native driver to have unified probe ordering. Signed-off-by:
-
