- Aug 12, 2024
-
-
Vivek Kasireddy authored
When an imported dmabuf obj is used as part of an atomic commit, we need to pin it as part of prepare and unpin it during cleanup of the associated FB, to make sure that it does not move until the commit is completed (and also while it is being used on the Host). Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Chia-I Wu <olvaffe@gmail.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com>
-
Vivek Kasireddy authored
By importing scanout buffers from other devices, we should be able to use the virtio-gpu driver in KMS only mode. Note that we attach dynamically and register a move_notify() callback so that we can let the VMM know of any location changes associated with the backing store of the imported object by sending detach_backing cmd. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Chia-I Wu <olvaffe@gmail.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com>
-
Vivek Kasireddy authored
The imported object can be considered a guest blob resource; therefore, we use create_blob cmd while creating it. These helpers are used in the next patch which does the actual import. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Chia-I Wu <olvaffe@gmail.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com>
-
Vivek Kasireddy authored
This helper would be used when first initializing the object as part of import and also when updating the plane where we need to ensure that the imported object's backing is valid. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Chia-I Wu <olvaffe@gmail.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com>
-
Vivek Kasireddy authored
This cmd is useful to let the VMM (i.e, Qemu) know that the backing store associated with a resource is no longer valid, so that the VMM can perform any cleanup or unmap operations. The fence related changes and virtio_gpu_object_detach()/ virtio_gpu_detach_object_fenced() routines are extracted from a patch by Dmitry Osipenko <dmitry.osipenko@collabora.com>. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Chia-I Wu <olvaffe@gmail.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com>
-
- Aug 08, 2024
-
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
# Conflicts: # kernel/panic.c
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
# Conflicts: # drivers/gpu/drm/i915/gem/i915_gem_mman.c
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
# Conflicts: # drivers/gpu/drm/ast/ast_drv.h # drivers/gpu/drm/v3d/v3d_sched.c # drivers/gpu/drm/v3d/v3d_submit.c # drivers/gpu/drm/xe/xe_vm.c
-
Rodrigo Vivi authored
# Conflicts: # drivers/gpu/drm/xe/xe_device.c # drivers/gpu/drm/xe/xe_device_types.h
-
Rodrigo Vivi authored
# Conflicts: # drivers/gpu/drm/xe/xe_rtp.c
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
-
Rodrigo Vivi authored
-
Matthew Brost authored
Kernel BO's don't take a ref to the VM, we need the VM for the delayed snapshot, so take a ref to the VM in delayed snapshot. v2: - Check for lrc_bo before taking a VM ref (CI) - Check lrc_bo->vm before taking / dropping a VM ref (CI) - Drop VM in xe_lrc_snapshot_free v5: - Fix commit message wording (Johnathan) Fixes: 47058633 ("drm/xe: Move lrc snapshot capturing to xe_lrc.c") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240801154118.2547543-2-matthew.brost@intel.com (cherry picked from commit c3bc97d2) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Karthik Poosa authored
In xe_hwmon_power_max_write, for PL1 disable supported case, instead of returning after PL1 disable, PL1 enable path was also being run. Fixed it by returning after disable. v2: Correct typo and grammar in commit message. (Jonathan) Signed-off-by:
Karthik Poosa <karthik.poosa@intel.com> Fixes: fef6dd12 ("drm/xe/hwmon: Protect hwmon rw attributes with hwmon_lock") Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240801112424.1841766-1-karthik.poosa@intel.com (cherry picked from commit 14645864) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Brost authored
A chain fence is uninitialized if not installed in a drm sync obj. Thus if xe_sync_entry_cleanup is called and sync->chain_fence is non-NULL the proper cleanup is dma_fence_chain_free rather than a dma-fence put. Reported-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Closes: drm/xe/kernel#2411 Closes: drm/xe/kernel#2261 Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240727012216.2118276-1-matthew.brost@intel.com (cherry picked from commit 7f7a2da3) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
Gustavo noticed an odd "+ 2" in rtp_mark_active() while processing rtp rules and pointed that it should be "+ 1". In fact, while processing entries without actions (OOB workarounds), if the WA is activated and has OR rules, it will also inadvertently activate the very next workaround. Test in a LNL B0 platform by moving 18024947630 on top of 16020292621, makes the latter become active: $ cat /sys/kernel/debug/dri/0/gt0/workarounds ... OOB Workarounds 18024947630 16020292621 14018094691 16022287689 13011645652 22019338487_display In future a kunit test will be added to cover the rtp checks for entries without actions. Fixes: fe19328b ("drm/xe/rtp: Add support for entries with no action") Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240726064337.797576-6-lucas.demarchi@intel.com Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit fd6797ec) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Jani Nikula authored
With the previous cleanups, the last remaining user of __i915_printk() is i915_probe_error(). Switch that to use drm_dbg() and drm_err() instead, dropping the request to report bugs in the few remaining specific cases. It's not common for drivers to log bug filing requests to begin with, but these cases are in init, which is most likely to be tested in CI and least likely to be hit by end users anyway. Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/be9baeab281f75999e96cc7ad1c06c6680494bc1.1722951405.git.jani.nikula@intel.com Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Jani Nikula authored
i915_report_error() presently acts as a wrapper for __i915_printk(). In practice, it would be better to use drm level error reporting wherever possible, so replace all uses of i915_report_error() with the equivalent drm_err() call. These cases are not worth having a dedicated wrapper to also print bug reporting info. Replacing the calls leaves i915_report_error() with no users, so remove it. Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/19eab020c57c0fa45acacf4e4a8077e57cd4d561.1722951405.git.jani.nikula@intel.com Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Jani Nikula authored
__i915_printk() does nothing special for notice/info levels. Just use the regular drm_notice() and drm_info() calls. Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/82857a0c04d3c11ca6758f05c13a3cec4f1a2f01.1722951405.git.jani.nikula@intel.com Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Andi Shyti authored
Do not use double blanks, ", " in function parameters where it's not required by any alignment purpose. Replase it with a single blank, ", ". Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240807130516.491053-3-andi.shyti@linux.intel.com
-
Andi Shyti authored
Do not use double blanks, ", " in function parameters where it's not required by any alignment purpose. Replase it with a single blank, ", ". Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240807130516.491053-2-andi.shyti@linux.intel.com
-
Andi Shyti authored
By moving the pfn calculation to the set_address_limits() function we improve code readability. This way, set_address_limits() is responsible for calculating all memory mapping paramenters: "start", "end" and "pfn". This suggestion from Jonathan was made during the review of commit 8bdd9ef7 ("drm/i915/gem: Fix Virtual Memory mapping boundaries calculation"), which I liked, but it got lost on the way. Suggested-by:
Jonathan Cavitt <Jonathan.cavitt@intel.com> Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Krzysztof Niemiec <krzysztof.niemiec@intel.com> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240807104553.481763-1-andi.shyti@linux.intel.com
-
José Expósito authored
Building with Sparse enabled prints this warning for cpu_to_le16() calls: warning: incorrect type in assignment (different base types) expected unsigned short [usertype] got restricted __le16 [usertype] And this warning for le16_to_cpu() calls: warning: cast to restricted __le16 Declare the target buffer as __le16 to fix both warnings. Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Louis Chauvet <louis.chauvet@bootlin.com> Acked-by:
Maíra Canal <mcanal@igalia.com> Signed-off-by:
José Expósito <jose.exposito89@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240716161725.41408-2-jose.exposito89@gmail.com
-
- Aug 07, 2024
-
-
The function returns with the ppm_lock held if there's an error or the PPM reports BUSY condition. This is a core-for-ci patch for [1] [1] https://lore.kernel.org/linux-usb/20240806112029.2984319-1-heikki.krogerus@linux.intel.com/ Reported-by:
Luciano Coelho <luciano.coelho@intel.com> Fixes: 5e9c1662 ("usb: typec: ucsi: rework command execution functions") References: drm/i915/kernel#11849 Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240807062729.3159701-1-chaitanya.kumar.borah@intel.com Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Kernel test robot reports i915 can hit a warn in kvmalloc_node which has a purpose of dissalowing crazy size kernel allocations. This was added in 7661809d ("mm: don't allow oversized kvmalloc() calls"): /* Don't even allow crazy sizes */ if (WARN_ON_ONCE(size > INT_MAX)) return NULL; This would be kind of okay since i915 at one point dropped the need for making a shadow copy of the relocation list, but then it got re-added in fd1500fc ("Revert "drm/i915/gem: Drop relocation slowpath".") a year after Linus added the above warning. It is plausible that the issue was not seen until now because to trigger gem_exec_reloc test requires a combination of an relatively older generation hardware but with at least 8GiB of RAM installed. Probably even more depending on runtime checks. Lets cap what we allow userspace to pass in using the matching limit. There should be no issue for real userspace since we are talking about "crazy" number of relocations which have no practical purpose. *) Well IGT tests might get upset but they can be easily adjusted. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reported-by:
kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202405151008.6ddd1aaf-oliver.sang@intel.com Cc: Kees Cook <keescook@chromium.org> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Tvrtko Ursulin <tursulin@ursulin.net> Link: https://patchwork.freedesktop.org/patch/msgid/20240521101201.18978-1-tursulin@igalia.com
-
Nirmoy Das authored
Check size of the data not size of the pointer. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407300421.IBkAja96-lkp@intel.com/ Fixes: 0fde907d ("drm/xe: Validate user fence during creation") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by:
Apoorva Singh <apoorva.singh@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806110722.28661-1-nirmoy.das@intel.com Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com>
-
In commit a78a8da5 ("drm/ttm: replace busy placement with flags v6"), __i915_ttm_get_pages was updated to use flags instead of the separate 'busy' placement list. However, the behaviour was subtly changed. Originally, the function would attempt to use the preferred placement without eviction, and give an opportunity to restart the operation before falling back to allowing eviction. This was unintentionally changed, as the preferred placement was not given the TTM_PL_FLAG_DESIRED flag, and so eviction could be triggered in that first pass. This caused thrashing, and a significant performance regression on DG2 systems with small BAR. For example, Minecraft and Team Fortress 2 would drop to single-digit framerates. Restore the original behaviour by marking the initial placement as desired on that first attempt. Also, rework this to use a separate struct ttm_palcement, as the individual placements are marked 'const', so hot-patching the flags is even more dodgy than before. Thanks to Justin Brewer for bisecting this. Fixes: a78a8da5 ("drm/ttm: replace busy placement with flags v6") Link: drm/i915/kernel#11255 Signed-off-by:
David Gow <david@davidgow.net> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240804091851.122186-3-david@davidgow.net (cherry picked from commit 92653f2a) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
In commit a78a8da5 ("drm/ttm: replace busy placement with flags v6"), the old system of having a separate placement list (for placements which should be used without eviction) and a 'busy' placement list (for placements which should be attempted if eviction is required) was replaced with a new one where placements could be marked 'FALLBACK' (to be attempted if eviction is required) or 'DESIRED' (to be attempted first, but not if eviction is required). i915 had always included the requested placement in the list of 'busy' placements: i.e., the placement could be used either if eviction is required or not. But when the new system was put in place, the requested (first) placement was marked 'DESIRED', so would never be used if eviction became necessary. While a bug in the original commit prevented this flag from working, when this was fixed in 4a0e7b3c ("drm/i915: fix applying placement flag"), it caused long hangs on DG2 systems with small BAR. Don't mark the requested placement DESIRED (or FALLBACK), allowing it to be used in both situations. This matches the old behaviour, and resolves the hangs. Thanks to Justin Brewer for bisecting the issue. Fixes: a78a8da5 ("drm/ttm: replace busy placement with flags v6") Fixes: 4a0e7b3c ("drm/i915: fix applying placement flag") Link: drm/i915/kernel#11255 Signed-off-by:
David Gow <david@davidgow.net> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240804091851.122186-2-david@davidgow.net (cherry picked from commit 54bf0af9) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
We already have for_each_endpoint_of_node(), don't use of_graph_get_next_endpoint() directly. Replace it. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/87jzh3lnts.wl-kuninori.morimoto.gx@renesas.com
-
kerneldoc was missing from earlier commit where we exported xe_hw_engine_lookup. Add it. Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: intel-xe@lists.freedesktop.org Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806153009.1081382-2-mika.kuoppala@linux.intel.com
-
Export hw engine's mmio accessors. This is in preparation to use these from eudebug code. v2: s/hw_engine_mmio/xe_hw_engine_mmio (Matthew) v3: kernel doc (Matthew) Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Dominik Grzegorzek <dominik.grzegorzek@intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806153009.1081382-1-mika.kuoppala@linux.intel.com
-
- Aug 06, 2024
-
-
Add pre-release support for PVC. UAPI version 1.13.4. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Julia Filipchuk <julia.filipchuk@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240802222129.3976212-5-John.C.Harrison@Intel.com
-
We should now have sufficient changes in the Xe driver changes to run it on ADL and ATSM platforms in the PF mode, to configure VFs and successfully probe driver on the enabled VF devices. While some more changes are likely still needed to fix all corner cases, we will not find them without running any tests. To start testing this feature by the CI, we need to mark which platforms have basic SR-IOV support and let the driver run in the PF mode. Since this feature support is still in the early testing stage, make all enabling available only for CONFIG_DRM_XE_DEBUG=y and keep it on CI topic branch. Note that from this point, on selected platforms, the Xe driver will be acting as a PF driver, will some SR-IOV specific changes compared to running in the non-virtualized (native) mode. However, those specific changes are visible mostly on the debugfs, and should not impact normal driver execution, unless VFs will be manually provisioned or explicitly enabled. Once we finish adding the remaining SR-IOV tests to the CI and fix any issues that we find in the meantime, we will replace this patch with proper series outside the topic branch. Suggested-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Acked-by:
Lucas De Marchi <lucas.demarchi@intel.com> Acked-by:
Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240711192320.1198-3-michal.wajdeczko@intel.com Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
-
This patch introduces Ponte Vecchio support in Xe driver. Please note that besides this patch, likely the force_probe still needs to be used in order to actually enable the support for PVC. This patch was separated from the rest so we can ensure compliance with DRM uAPI rules on compute platforms. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Oded Gabbay <ogabbay@kernel.org> Link: drm/xe/kernel#1154 Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
-
UAPI version 1.13.4 Signed-off-by:
Julia Filipchuk <julia.filipchuk@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240802222129.3976212-4-John.C.Harrison@Intel.com
-