Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32 |
|
#
08872cb1 |
| 31-May-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/mtl/huc: auth HuC via GSC
The full authentication via the GSC requires an heci packet submission to the GSC FW via the GSC CS. The GSC has new PXP command for this (literally called NEW_HUC
drm/i915/mtl/huc: auth HuC via GSC
The full authentication via the GSC requires an heci packet submission to the GSC FW via the GSC CS. The GSC has new PXP command for this (literally called NEW_HUC_AUTH). The intel_huc_auth function is also updated to handle both authentication types.
v2: check that the GuC auth for clear media has completed before proceding with the full auth
v3: use a define for the object size (Alan)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230531235415.1467475-6-daniele.ceraolospurio@intel.com
show more ...
|
#
98d2722a |
| 31-May-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
Before we add the second step of the MTL HuC auth (via GSC), we need to have the ability to differentiate between them. To do so, the
drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow
Before we add the second step of the MTL HuC auth (via GSC), we need to have the ability to differentiate between them. To do so, the huc authentication check is duplicated for GuC and GSC auth, with GSC-enabled binaries being considered fully authenticated only after the GSC auth step.
To report the difference between the 2 auth steps, a new case is added to the HuC getparam. This way, the clear media driver can start submitting before full auth, as partial auth is enough for those workloads.
v2: fix authentication status check for DG2
v3: add a better comment at the top of the HuC file to explain the different approaches to load and auth (John)
v4: update call to intel_huc_is_authenticated in the pxp code to check for GSC authentication
v5: drop references to meu and esclamation mark in huc_auth print (John)
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> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> #v2 Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230531235415.1467475-5-daniele.ceraolospurio@intel.com
show more ...
|
#
6a9b6c45 |
| 31-May-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
In the previous patch we extracted the offset of the legacy-style HuC binary located within the GSC-enabled blob, so now we can us
drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
In the previous patch we extracted the offset of the legacy-style HuC binary located within the GSC-enabled blob, so now we can use that to load the HuC via DMA if the fuse is set that way. Note that we now need to differentiate between "GSC-enabled binary" and "loaded by GSC", so the former case has been renamed to "has GSC headers" for clarity, while the latter is now based on the fuse instead of the binary format. This way, all the legacy load paths are automatically taken (including the auth by GuC) without having to implement further code changes.
v2: s/is_meu_binary/has_gsc_headers/, clearer logs (John)
v3: split check for GSC access, better comments (John)
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> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230531235415.1467475-4-daniele.ceraolospurio@intel.com
show more ...
|
Revision tags: v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20 |
|
#
c7423749 |
| 13-Mar-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/huc: Cancel HuC delayed load timer on reset.
In the rare case where we do a full GT reset after starting the HuC load and before it completes (which basically boils down to i915 hanging dur
drm/i915/huc: Cancel HuC delayed load timer on reset.
In the rare case where we do a full GT reset after starting the HuC load and before it completes (which basically boils down to i915 hanging during init), we need to cancel the delayed load fence, as it will be re-initialized in the post-reset recovery.
Fixes: 27536e03271d ("drm/i915/huc: track delayed HuC load with a fence") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230313205556.1174503-1-daniele.ceraolospurio@intel.com (cherry picked from commit cdf7911f7dbcb37228409a63bf75630776c45a15) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
show more ...
|
#
cdf7911f |
| 13-Mar-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/huc: Cancel HuC delayed load timer on reset.
In the rare case where we do a full GT reset after starting the HuC load and before it completes (which basically boils down to i915 hanging dur
drm/i915/huc: Cancel HuC delayed load timer on reset.
In the rare case where we do a full GT reset after starting the HuC load and before it completes (which basically boils down to i915 hanging during init), we need to cancel the delayed load fence, as it will be re-initialized in the post-reset recovery.
Fixes: 27536e03271d ("drm/i915/huc: track delayed HuC load with a fence") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230313205556.1174503-1-daniele.ceraolospurio@intel.com
show more ...
|
#
c9a9f18d |
| 13-Mar-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
drm/i915/huc: use const struct bus_type pointers
The struct bus_type pointers in the functions intel_huc_register_gsc_notifier() and intel_huc_unregister_gsc_notifier() should be a const pointer, as
drm/i915/huc: use const struct bus_type pointers
The struct bus_type pointers in the functions intel_huc_register_gsc_notifier() and intel_huc_unregister_gsc_notifier() should be a const pointer, as the structure is not modified anywhere in the functions, and the pointer they are passed will be a const * in the near future.
Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tony Ye <tony.ye@intel.com> Cc: Vitaly Lubart <vitaly.lubart@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://lore.kernel.org/r/20230313182918.1312597-30-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71 |
|
#
e6177ec5 |
| 27-Sep-2022 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/huc: stall media submission until HuC is loaded
Wait on the fence to be signalled to avoid the submissions finding HuC not yet loaded.
v2: use dedicaded wait_queue_entry for waiting in HuC
drm/i915/huc: stall media submission until HuC is loaded
Wait on the fence to be signalled to avoid the submissions finding HuC not yet loaded.
v2: use dedicaded wait_queue_entry for waiting in HuC load, as submitq can't be re-used for it.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tony Ye <tony.ye@intel.com> Acked-by: Tony Ye <tony.ye@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-13-daniele.ceraolospurio@intel.com
show more ...
|
#
27536e03 |
| 27-Sep-2022 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/huc: track delayed HuC load with a fence
Given that HuC load is delayed on DG2, this patch adds support for a fence that can be used to wait for load completion. No waiters are added in thi
drm/i915/huc: track delayed HuC load with a fence
Given that HuC load is delayed on DG2, this patch adds support for a fence that can be used to wait for load completion. No waiters are added in this patch (they're coming up in the next one), to keep the focus of the patch on the tracking logic.
The full HuC loading flow on boot DG2 is as follows: 1) i915 exports the GSC as an aux device; 2) the mei-gsc driver is loaded on the aux device; 3) the mei-pxp component is loaded; 4) mei-pxp calls back into i915 and we load the HuC.
Between steps 1 and 2 there can be several seconds of gap, mainly due to the kernel doing other work during the boot. The resume flow is slightly different, because we don't need to re-expose or re-probe the aux device, so we go directly to step 3 once i915 and mei-gsc have completed their resume flow.
Here's an example of the boot timing, captured with some logs added to i915:
[ 17.908307] [drm] adding GSC device [ 17.915717] [drm] i915 probe done [ 22.282917] [drm] mei-gsc bound [ 22.938153] [drm] HuC authenticated
Also to note is that if something goes wrong during GSC HW init the mei-gsc driver will still bind, but steps 3 and 4 will not happen.
The status tracking is done by registering a bus_notifier to receive a callback when the mei-gsc driver binds, with a large enough timeout to account for delays. Once mei-gsc is bound, we switch to a smaller timeout to wait for the mei-pxp component to load. The fence is signalled on HuC load complete or if anything goes wrong in any of the tracking steps. Timeout are enforced via hrtimer callbacks.
v2: fix includes (Jani) v5: gsc_notifier() remove unneeded ()
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-12-daniele.ceraolospurio@intel.com
show more ...
|
#
087b6818 |
| 27-Sep-2022 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/dg2: setup HuC loading via GSC
The GSC will perform both the load and the authentication, so we just need to check the auth bit after the GSC has replied. Since we require the PXP module to
drm/i915/dg2: setup HuC loading via GSC
The GSC will perform both the load and the authentication, so we just need to check the auth bit after the GSC has replied. Since we require the PXP module to load the HuC, the earliest we can trigger the load is during the pxp_bind operation.
Note that GSC-loaded HuC survives GT reset, so we need to just mark it as ready when we re-init the GT HW.
V2: move setting of HuC fw error state to the failure path of the HuC auth function, so it covers both the legacy and new auth flows V4: 1. Fix typo in the commit message 2. style fix in intel_huc_wait_for_auth_complete()
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220928004145.745803-11-daniele.ceraolospurio@intel.com
show more ...
|
Revision tags: v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38 |
|
#
6f67930a |
| 04-May-2022 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/huc: Prepare for GSC-loaded HuC
HuC loading via GSC is performed via a PXP command sent through the mei modules, so we need both MEI_GSC and MEI_PXP to be available. Given that the GSC will
drm/i915/huc: Prepare for GSC-loaded HuC
HuC loading via GSC is performed via a PXP command sent through the mei modules, so we need both MEI_GSC and MEI_PXP to be available. Given that the GSC will do both the transfer and the authentication, the legacy HuC loading paths can be safely skipped. Also note that the GSC-loaded HuC survives GT reset.
v2: move the huc_is_authenticated() function to this patch.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220504204816.2082588-4-daniele.ceraolospurio@intel.com
show more ...
|
#
315241d2 |
| 04-May-2022 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/huc: drop intel_huc_is_authenticated
The function name is confusing, because it doesn't check the actual auth status in HW but the SW status. Given that there is only one user (the huc_auth
drm/i915/huc: drop intel_huc_is_authenticated
The function name is confusing, because it doesn't check the actual auth status in HW but the SW status. Given that there is only one user (the huc_auth function itself), just get rid of it and use the FW status checker directly.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220504204816.2082588-2-daniele.ceraolospurio@intel.com
show more ...
|
Revision tags: v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18 |
|
#
ce2fce25 |
| 27-Jan-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Only include i915_reg.h from .c files
Several of our i915 header files, have been including i915_reg.h. This means that any change to i915_reg.h will trigger a full rebuild of pretty much
drm/i915: Only include i915_reg.h from .c files
Several of our i915 header files, have been including i915_reg.h. This means that any change to i915_reg.h will trigger a full rebuild of pretty much every file of the driver, even those that don't have any kind of register access. Let's delete the i915_reg.h include from all headers and add an explicit include from the .c files that truly need the register definitions; those that need a definition of i915_reg_t for a function definition can get it from i915_reg_defs.h instead.
We also remove two non-register #define's (VLV_DISPLAY_BASE and GEN12_SFC_DONE_MAX) into i915_reg_defs.h to allow us to drop the i915_reg.h include from a couple of headers.
There's probably a lot more header dependency optimization possible, but the changes here roughly cut the number of files compiled after 'touch i915_reg.h' in half --- a good first step.
Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-7-matthew.d.roper@intel.com
show more ...
|
Revision tags: v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8 |
|
#
b2657ed0 |
| 10-Dec-2021 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/guc: support bigger RSA keys
Some of the newer HW will use bigger RSA keys to authenticate the GuC binary. On those platforms the HW will read the key from memory instead of the RSA registe
drm/i915/guc: support bigger RSA keys
Some of the newer HW will use bigger RSA keys to authenticate the GuC binary. On those platforms the HW will read the key from memory instead of the RSA registers, so we need to copy it in a dedicated vma, like we do for the HuC. The address of the key is provided to the HW via the first RSA register.
v2: clarify that the RSA behavior is hardcoded in the bootrom (Matt)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211211000756.1698923-4-daniele.ceraolospurio@intel.com
show more ...
|
Revision tags: v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6 |
|
#
34904bd6 |
| 26-Mar-2020 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/debugfs: move uC printers and update debugfs file names
Move the printers to the respective files for clarity. The guc_load_status debugfs has been squashed in the guc_info one, has having
drm/i915/debugfs: move uC printers and update debugfs file names
Move the printers to the respective files for clarity. The guc_load_status debugfs has been squashed in the guc_info one, has having separate ones wasn't very useful. The HuC debugfs has been renamed huc_info to match.
v2: keep printing HUC_STATUS2 (Tony), avoid const->non-const container_of (Jani)
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Tony Ye <tony.ye@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200326181121.16869-5-daniele.ceraolospurio@intel.com
show more ...
|
Revision tags: v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21 |
|
#
bfe5a40a |
| 18-Feb-2020 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/uc: Improve tracking of uC init status
To be able to setup GuC submission functions during engine init we need to commit to using GuC as soon as possible. Currently, the only thing that can
drm/i915/uc: Improve tracking of uC init status
To be able to setup GuC submission functions during engine init we need to commit to using GuC as soon as possible. Currently, the only thing that can stop us from using the microcontrollers once we've fetched the blobs is a fundamental error (e.g. OOM); given that if we hit such an error we can't really fall-back to anything, we can "officialize" the FW fetching completion as the moment at which we're committing to using GuC.
To better differentiate this case, the uses_guc check, which indicates that GuC is supported and was selected in modparam, is renamed to wants_guc and a new uses_guc is introduced to represent the case were we're committed to using the GuC. Note that uses_guc does still not imply that the blob is actually loaded on the HW (is_running is the check for that). Also, since we need to have attempted the fetch for the result of uses_guc to be meaningful, we need to make sure we've moved away from INTEL_UC_FIRMWARE_SELECTED.
All the GuC changes have been mirrored on the HuC for coherency.
v2: split fetch return changes and new macros to their own patches, support HuC only if GuC is wanted, improve "used" state description (Michal)
v3: s/wants_huc/uses_huc in uc_init_wopcm
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com> #v1 Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-6-daniele.ceraolospurio@intel.com
show more ...
|
Revision tags: v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10 |
|
#
356c4848 |
| 16-Aug-2019 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915/uc: Add explicit DISABLED state for firmware
We really need to have separate NOT_SUPPORTED state (for lack of hardware support) and DISABLED state (to indicate user decision) as we will hav
drm/i915/uc: Add explicit DISABLED state for firmware
We really need to have separate NOT_SUPPORTED state (for lack of hardware support) and DISABLED state (to indicate user decision) as we will have to take special steps even if GuC firmware is now disabled but hardware exists and could have been previously used.
v2: fix logic (Chris/CI) v3: use proper check to avoid probe failure (CI) v4: explain status transitions (Chris)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816205658.15020-1-michal.wajdeczko@intel.com
show more ...
|
Revision tags: v5.2.9 |
|
#
3ea58029 |
| 12-Aug-2019 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915/uc: Update copyright and license
Include 2019 in copyright years and start using SPDX tag.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen
drm/i915/uc: Update copyright and license
Include 2019 in copyright years and start using SPDX tag.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190812092935.21048-1-michal.wajdeczko@intel.com
show more ...
|
Revision tags: v5.2.8, v5.2.7, v5.2.6 |
|
#
db81bc6e |
| 31-Jul-2019 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915/uc: Consider enable_guc modparam during fw selection
We can use value of enable_guc modparam during firmware path selection and start using firmware status to see if GuC/HuC is being used.
drm/i915/uc: Consider enable_guc modparam during fw selection
We can use value of enable_guc modparam during firmware path selection and start using firmware status to see if GuC/HuC is being used. This is first step to make enable_guc modparam read-only.
v2: rebased, don't care about <0 (Chris) v3: oops
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190731223321.36436-3-michal.wajdeczko@intel.com
show more ...
|
Revision tags: v5.2.5, v5.2.4, v5.2.3 |
|
#
9cb27945 |
| 24-Jul-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/huc: Copy huc rsa only once
The binary is perma-pinned and the rsa is not going to change, so copy it only once and not on every load.
v2: onion unwind (Chris)
Signed-off-by: Daniele Cera
drm/i915/huc: Copy huc rsa only once
The binary is perma-pinned and the rsa is not going to change, so copy it only once and not on every load.
v2: onion unwind (Chris)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Fernando Pacheco <fernando.pacheco@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1 Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-7-daniele.ceraolospurio@intel.com
show more ...
|
#
91e55e54 |
| 24-Jul-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/uc: Unify uc_fw status tracking
We currently track fetch and load status separately, but the 2 are actually sequential in the uc lifetime (fetch must complete before we can attempt the load
drm/i915/uc: Unify uc_fw status tracking
We currently track fetch and load status separately, but the 2 are actually sequential in the uc lifetime (fetch must complete before we can attempt the load!). Unifying the 2 variables we can better follow the sequential states and improve our trackng of the uC state.
Also, sprinkle some GEM_BUG_ON to make sure we transition correctly between states.
v2: rename states, add the running state (Michal), drop some logs in the fetch path (Michal, Chris)
v3: re-rename states, extend early status check to all helpers (Michal)
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-5-daniele.ceraolospurio@intel.com
show more ...
|
Revision tags: v5.2.2, v5.2.1 |
|
#
0f261b24 |
| 13-Jul-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/uc: move GuC and HuC files under gt/uc/
Both microcontrollers are part of the GT HW and are closely related to GT operations. To keep all the files cleanly together, they've been placed in
drm/i915/uc: move GuC and HuC files under gt/uc/
Both microcontrollers are part of the GT HW and are closely related to GT operations. To keep all the files cleanly together, they've been placed in their own subdir inside the gt/ folder
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-6-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
show more ...
|
Revision tags: v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6 |
|
#
34904bd6 |
| 26-Mar-2020 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/debugfs: move uC printers and update debugfs file names Move the printers to the respective files for clarity. The guc_load_status debugfs has been squashed in the guc_info one,
drm/i915/debugfs: move uC printers and update debugfs file names Move the printers to the respective files for clarity. The guc_load_status debugfs has been squashed in the guc_info one, has having separate ones wasn't very useful. The HuC debugfs has been renamed huc_info to match. v2: keep printing HUC_STATUS2 (Tony), avoid const->non-const container_of (Jani) Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Tony Ye <tony.ye@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200326181121.16869-5-daniele.ceraolospurio@intel.com
show more ...
|
Revision tags: v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21 |
|
#
bfe5a40a |
| 18-Feb-2020 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/uc: Improve tracking of uC init status To be able to setup GuC submission functions during engine init we need to commit to using GuC as soon as possible. Currently, the onl
drm/i915/uc: Improve tracking of uC init status To be able to setup GuC submission functions during engine init we need to commit to using GuC as soon as possible. Currently, the only thing that can stop us from using the microcontrollers once we've fetched the blobs is a fundamental error (e.g. OOM); given that if we hit such an error we can't really fall-back to anything, we can "officialize" the FW fetching completion as the moment at which we're committing to using GuC. To better differentiate this case, the uses_guc check, which indicates that GuC is supported and was selected in modparam, is renamed to wants_guc and a new uses_guc is introduced to represent the case were we're committed to using the GuC. Note that uses_guc does still not imply that the blob is actually loaded on the HW (is_running is the check for that). Also, since we need to have attempted the fetch for the result of uses_guc to be meaningful, we need to make sure we've moved away from INTEL_UC_FIRMWARE_SELECTED. All the GuC changes have been mirrored on the HuC for coherency. v2: split fetch return changes and new macros to their own patches, support HuC only if GuC is wanted, improve "used" state description (Michal) v3: s/wants_huc/uses_huc in uc_init_wopcm Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com> #v1 Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-6-daniele.ceraolospurio@intel.com
show more ...
|
Revision tags: v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10 |
|
#
356c4848 |
| 16-Aug-2019 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915/uc: Add explicit DISABLED state for firmware We really need to have separate NOT_SUPPORTED state (for lack of hardware support) and DISABLED state (to indicate user decision
drm/i915/uc: Add explicit DISABLED state for firmware We really need to have separate NOT_SUPPORTED state (for lack of hardware support) and DISABLED state (to indicate user decision) as we will have to take special steps even if GuC firmware is now disabled but hardware exists and could have been previously used. v2: fix logic (Chris/CI) v3: use proper check to avoid probe failure (CI) v4: explain status transitions (Chris) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190816205658.15020-1-michal.wajdeczko@intel.com
show more ...
|
Revision tags: v5.2.9 |
|
#
3ea58029 |
| 12-Aug-2019 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915/uc: Update copyright and license Include 2019 in copyright years and start using SPDX tag. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahti
drm/i915/uc: Update copyright and license Include 2019 in copyright years and start using SPDX tag. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190812092935.21048-1-michal.wajdeczko@intel.com
show more ...
|