- 24 Apr, 2024 11 commits
-
-
Michal Wajdeczko authored
GuC is silently clamping values of the execution quantum and preemption timeout KLVs to 100s. Perform explicit clamping on the driver side as later there is no way to read back values used by the firmware and we shouldn't mislead the user about actual values being used when we print them in dmesg or debugfs. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240419123543.270-3-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
GuC firmware specification says that maximum value for the execution quantum KLV is 100s and anything exceeding that will be clamped. The same limitation applies to the preemption timeout KLV. Signed-off-by:
-
Michal Wajdeczko authored
We already have functions to configure SR-IOV policies. Allow to tweak those policy settings over debugfs. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
We already have functions to control the VF. Allow to control the VF using debugfs. Reviewed-by:
-
Michal Wajdeczko authored
We already have functions to configure VF resources and to print actual provisioning details. Expose this functionality in debugfs to allow experiment with different settings or inspect details in case of unexpected issues with the provisioning. As debugfs attributes are per-VF, we use parent d_inode->i_private to store VFID, similarly how we did for per-GT attributes. Reviewed-by:
-
Michal Wajdeczko authored
Start with basic tests for VF/PF ABI version negotiation. As we treat all platforms in the same way, we can run the tests on one platform. More tests will likely come later. Reviewed-by:
-
Michal Wajdeczko authored
We already have mechanism that allows a VF driver to communicate with the PF driver, now add PF side handlers for VF2PF requests defined in version 1.0 of VF/PF GuC Relay ABI specification. The VF2PF_HANDSHAKE request must be used by the VF driver to negotiate the ABI version prior to sending any other request. We will reset any negotiated version later during FLR. The outcome of the VF2PF_QUERY_RUNTIME requests depends on actual platform, for legacy platforms used as SDV is provided as-is, for latest platforms it is preliminary, and might be changed. Signed-off-by:
-
Michal Wajdeczko authored
While we are not using these registers right now, they are part of some runtime register lists that PF driver share with VFs on some legacy platforms that we might want to support as SDV. Reviewed-by:
-
Michal Wajdeczko authored
Our MMIO accessing functions automatically adjust addresses for the media registers based on mmio.adj_limit and mmio.adj_offset logic. Move it to the separate helper to avoid code duplication and to allow using it by the upcoming changes to PF driver code. Signed-off-by:
-
Michal Wajdeczko authored
This initial GuC Relay ABI specification includes messages for ABI version negotiation and to query values of runtime/fuse registers. We will start handling those messages on the PF driver soon. Reviewed-by:
-
Thomas Hellström authored
The recent backmerge from drm-next to drm-xe-next brought with it some silent unexpected results. One code snippet was added twice and a partial revert had merge errors. Fix that up to reinstate the affected code as it was before the backmerge. v2: - Commit log message rewording (Lucas DeMarchi) Fixes: 79790b68 ("Merge drm/drm-next into drm-xe-next") Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423121114.39325-1-thomas.hellstrom@linux.intel.com
-
- 23 Apr, 2024 1 commit
-
-
Rodrigo Vivi authored
Fix the new sparse warning: >> drivers/gpu/drm/xe/xe_pm.c:72:20: sparse: sparse: symbol 'xe_pm_runtime_lockdep_map' was not declared. Should it be static? Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404191329.EZzOTzwK-lkp@intel.com/Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Badal Nilawar <badal.nilawar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240422201454.699089-1-rodrigo.vivi@intel.comSigned-off-by:
-
- 22 Apr, 2024 3 commits
-
-
Michal Wajdeczko authored
By default CT code was passing just payload of the G2H event message, while Relay code expects full G2H message including HXG header which contains DATA0 field. Fix that. Fixes: 26d4481a ("drm/xe/guc: Start handling GuC Relay event messages") Signed-off-by:
-
Michal Wajdeczko authored
This function is using internal helper pf_get_spare_ggtt() that expects PF's master mutex to be locked. Fix that. Fixes: ac6598ae ("drm/xe/pf: Add support to configure SR-IOV VFs") Signed-off-by:
-
Rodrigo Vivi authored
Let's simply convert all the current callers towards direct xe_pm_runtime access and remove this extra layer of indirection. No functional change is expected with this patch since xe_mem_access_get was already using the xe_pm_runtime_get_noresume at this point. v2: Convert all the current callers instead of a big refactor at once. v3: - Rebased - Squashed the GSC/HDCP - Added a new case: sriov_pf_policy - Improved commit message to highlight that there's no functional change in this patch. Reviewed-by: Matthew Auld <matthew.auld@intel.com> #v2 Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240418143049.43231-1-rodrigo.vivi@intel.com
-
- 19 Apr, 2024 3 commits
-
-
Matt Roper authored
Rather than trying to identify exactly which engines are available on each platform in the IP descriptor, just include the list of all media engines that the IP could theoretically support (i.e., 8 VCS + 4 VECS). We still rely on the media fuse registers to tell us which specific engine instances are actually present on a given platform, so there shouldn't be any functional change. This will help prevent mistakes with engine numbering (for example ambiguity about whether the 2nd VCS engine on a platform with exactly two engines is numbered "VCS1" or "VCS2") and will also future-proof the code a bit more in case new SKUs or platform refreshes extend the engine list in the future. Note that the media fuse register technically has an 8-bit field for VECS engine presence starting on Xe2. However there's still no MMIO register range reserved for VE engines above VECS3, so VE0-VE3 is still consider the "maximum" VE engine mask that the driver can support for now. Bspec: 52614, 52615, 62567 Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
In the past, the noresume function was used by the GEM code to ensure wakelocks were held and bump its usage. This is no longer the case and this function was totally unused until it started to be used again by display with commit 77e619a8 ("drm/i915/display: convert inner wakeref get towards get_if_in_use") However, on the display code, most of the callers are using the raw wakeref, rather then the wakelock version. What caused a major regression caught by CI. Another option to this patch is to go with the original plan and use the get_if_in_use variant in the display code, what is enough to fulfil our needs. Then, an extra patch to delete the unused _noresume variant. v2: Keep grabbing wakelock but only assert for wakeref. (Imre) Cc: Imre Deak <imre.deak@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 77e619a8 ("drm/i915/display: convert inner wakeref get towards get_if_in_use") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10875Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240418223756.68427-1-rodrigo.vivi@intel.com
-
Ashutosh Dixit authored
When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below): Call Trace: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 component_unbind_all+0x8d/0xa0 component_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 device_release_driver_internal+0x19c/0x200 unbind_store+0x9c/0xb0 and Call Trace: release_nodes+0x11/0x70 devres_release_all+0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 This means that in i915, if use devm, we cannot gurantee that hwmon will always be released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't. The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind. v2: Change commit message and other minor code changes v3: Cleanup from i915_hwmon_register on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetch_and_zero (Jani) v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366Reviewed-by:Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417145646.793223-1-ashutosh.dixit@intel.com
-
- 18 Apr, 2024 18 commits
-
-
Himal Prasad Ghimiray authored
xe_pm_init may encounter failures for various reasons, such as a failure in initializing drmm_mutex, or when dealing with a d3cold-capable device for vram_threshold sysfs creation and setting default threshold. Presently, all these potential failures are disregarded. Move d3cold.lock initialization to xe_pm_init_early and cause driver abort if mutex initialization has failed. For xe_pm_init failures cleanup the driver and return error code -v2 Make mutex init cleaner (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by:
-
Himal Prasad Ghimiray authored
Ensure that the status of all tile associated sysfs entries creation is relayed to xe_tile_init_noalloc, leading to a driver load abort if any sysfs creation failures occur. -v2 Avoid unnecessary warn/error messages. (Lucas) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Himal Prasad Ghimiray authored
Instead of allowing the driver to load with incomplete sysfs entries in case of sysfs creation failure, we should terminate the driver loading. This change ensures that the status of all gt associated sysfs entries creation is relayed to xe_gt_init, leading to a driver load abort if any sysfs creation failures occur. -v2 use err_force_wake label instead of new. (Lucas) Avoid unnecessary warn/error messages. (Lucas) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Himal Prasad Ghimiray authored
In case of drmm_add_action_or_reset failure return NULL and no need to print warning messages as they will be printed implictly. Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Himal Prasad Ghimiray authored
The drmm_add_action_or_reset function automatically invokes the action (free_gsc_pkt) in the event of a failure; therefore, there's no necessity to call it within the return check. -v2 Fix commit message. (Lucas) Fixes: d8b15713 ("drm/xe/huc: HuC authentication via GSC") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Himal Prasad Ghimiray authored
The drmm_add_action_or_reset function automatically invokes the action (sysfs removal) in the event of a failure; therefore, there's no necessity to call it within the return check. Modify the return type of xe_gt_ccs_mode_sysfs_init to int, allowing the caller to pass errors up the call chain. Should sysfs creation or drmm_add_action_or_reset fail, error propagation will prompt a driver load abort. -v2 Edit commit message (Nikula/Lucas) use err_force_wake label instead of new. (Lucas) Avoid unnecessary warn/error messages. (Lucas) Fixes: f3bc5bb4 ("drm/xe: Allow userspace to configure CCS mode") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by:
-
Himal Prasad Ghimiray authored
Instead of assigning the value of drmm_add_action_or_reset() to err and returning err in case of failure and 0 in case of success, simply return the result of drmm_add_action_or_reset(). -v2: cleanup in xe_display too. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Gustavo Sousa authored
Wa_14020338487 also applies to Xe2_LPG. Replicate the existing entry to one specific for Xe2_LPG. Signed-off-by:
-
Rodrigo Vivi authored
Any kunit doing any memory access should get their own runtime_pm outer references since they don't use the standard driver API entries. In special this dma_buf from the same driver. Found by pre-merge CI on adding WARN calls for unprotected inner callers: <6> [318.639739] # xe_dma_buf_kunit: running xe_test_dmabuf_import_same_driver <4> [318.639957] ------------[ cut here ]------------ <4> [318.639967] xe 0000:4d:00.0: Missing outer runtime PM protection <4> [318.640049] WARNING: CPU: 117 PID: 3832 at drivers/gpu/drm/xe/xe_pm.c:533 xe_pm_runtime_get_noresume+0x48/0x60 [xe] Cc: Matthew Auld <matthew.auld@intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
At this point mem_access references should be only used as inner points of the execution and a get with synchronous resume previously called at an outer point. So, before killing mem_acces in favor of direct accsess, let's ensure that we first convert them towards the new _noresume variant that will WARN us if no inner caller happened. Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-9-rodrigo.vivi@intel.comSigned-off-by:
-
Rodrigo Vivi authored
Now that assert_mem_access is relying directly on the pm_runtime state instead of the counters, there's no reason why we cannot use the pm_runtime functions directly. Reviewed-by:
-
Rodrigo Vivi authored
This is not needed any longer, now that we have all the protection in place with the runtime pm itself. Reviewed-by:
-
Rodrigo Vivi authored
The gem page fault is one of the outer bound protections where we want to ensure that the hardware is in D0 before proceeding with memory access. Let's convert it towards the xe_pm_runtime functions directly so we can then convert the mem_access to be inner protection only and then Kill it for good. Reviewed-by:
-
Rodrigo Vivi authored
xe_pm_init is the very last thing during the xe_pci_probe(), hence these protections are useless from the point of view of ensuring that the device is awake. Let's remove it so we continue towards the goal of killing xe_device_mem_access. v2: Adding more cases v3: Provide a separate fix for xe_tile_init_noalloc return (Matt) Adding a new case where display HDCP init calls which are also called at display probe time. Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: -
Rodrigo Vivi authored
The mem_access itself is not holding any lock, but attempting to train lockdep with possible scarring locks happening during runtime pm. We are going soon to kill the mem_access get and put helpers in favor of direct xe_pm_runtime calls, so let's just move this lock around to where it now belongs. v2: s/lockdep_training/lockdep_prime (Matt Auld) Reviewed-by:
-
Rodrigo Vivi authored
This patch brings no functional change. Since at this point of the code we are already asserting a wakeref was held, it means that we are with runtime_pm 'in_use' and in practical terms we are only bumping the pm_runtime usage counter and moving on. However, xe driver has a lockdep annotation that warned us that if a sync resume was actually called at this point, we could have a deadlock because we are inside the power_domains->lock locked area and the resume would call the irq_reset, which would also try to get the power_domains->lock. For this reason, let's convert this call to a safer option and calm lockdep on. v2: use _noresume variant instead of get_in_use (Ville, Imre) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-3-rodrigo.vivi@intel.comSigned-off-by:
-
Rodrigo Vivi authored
The i915-display will start using the intel_runtime_pm_noresume. So we need to add the compat header before it. Reviewed-by:
-
Rodrigo Vivi authored
Let's ensure that we have an option for inner callers that will raise WARN if device is not active and not protected by outer callers. Make this also a void function forcing every caller to unconditionally put the reference back afterwards. This will be very important for cases where we want to hold the reference before scheduling a work in a queue. Then the work job will be responsible for putting it back. While at this, already convert a case from mem_access_get_ongoing where it is not checking for the reference and put it back, what would cause the underflow. v2: Fix identation. v3: Convert equivalent missing put from mem_access towards pm_runtime. Reviewed-by:
-
- 17 Apr, 2024 4 commits
-
-
Vinay Belgaumkar authored
Enable WA for a bug that could cause the C6 state machine to hang during RC6 exit. v2: Add comment clarifying the WA (John H) v3: Add more details to the comment (John H) Signed-off-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
-
Matthew Auld authored
clangd complains here, since nothing in xe_gt.h seems to be needed. Signed-off-by:
-
Matthew Auld authored
Now that we no longer grab the usm.lock mutex (which might sleep) it looks like it should be safe to directly perform xe_vm_free when vm refcount reaches zero, instead of punting that off to some worker. Signed-off-by:
-
Matthew Auld authored
The asid is only erased from the xarray when the vm refcount reaches zero, however this leads to potential UAF since the xe_vm_get() only works on a vm with refcount != 0. Since the asid is allocated in the vm create ioctl, rather erase it when closing the vm, prior to dropping the potential last ref. This should also work when user closes driver fd without explicit vm destroy. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1594Signed-off-by:
-
