From: John Harrison <john.c.harrison@intel.com>
To: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
<intel-gfx@lists.freedesktop.org>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/7] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so
Date: Thu, 1 Jun 2023 13:42:14 -0700 [thread overview]
Message-ID: <5acacf14-2785-963a-91c4-47e9487e9e4d@intel.com> (raw)
In-Reply-To: <20230531235415.1467475-4-daniele.ceraolospurio@intel.com>
On 5/31/2023 16:54, Daniele Ceraolo Spurio wrote:
> 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>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 49 +++++++++++++++++------
> drivers/gpu/drm/i915/gt/uc/intel_huc.h | 4 +-
> drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 12 +++---
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
> 5 files changed, 47 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> index 6d795438b3e4..27c5e41fa84c 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> @@ -298,31 +298,54 @@ void intel_huc_init_early(struct intel_huc *huc)
> static int check_huc_loading_mode(struct intel_huc *huc)
> {
> struct intel_gt *gt = huc_to_gt(huc);
> - bool fw_needs_gsc = intel_huc_is_loaded_by_gsc(huc);
> - bool hw_uses_gsc = false;
> + bool gsc_enabled = huc->fw.has_gsc_headers;
>
> /*
> * The fuse for HuC load via GSC is only valid on platforms that have
> * GuC deprivilege.
> */
> if (HAS_GUC_DEPRIVILEGE(gt->i915))
> - hw_uses_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
> - GSC_LOADS_HUC;
> + huc->loaded_via_gsc = intel_uncore_read(gt->uncore, GUC_SHIM_CONTROL2) &
> + GSC_LOADS_HUC;
>
> - if (fw_needs_gsc != hw_uses_gsc) {
> - huc_err(huc, "mismatch between FW (%s) and HW (%s) load modes\n",
> - HUC_LOAD_MODE_STRING(fw_needs_gsc), HUC_LOAD_MODE_STRING(hw_uses_gsc));
> + if (huc->loaded_via_gsc && !gsc_enabled) {
> + huc_err(huc, "HW requires a GSC-enabled blob, but we found a legacy one\n");
> return -ENOEXEC;
> }
>
> - /* make sure we can access the GSC via the mei driver if we need it */
> - if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) && IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
> - fw_needs_gsc) {
> - huc_info(huc, "can't load due to missing MEI modules\n");
> - return -EIO;
> + /*
> + * On newer platforms we have GSC-enabled binaries but we load the HuC
> + * via DMA. To do so we need to find the location of the legacy-style
> + * binary inside the GSC-enabled one, which we do at fetch time. Make
> + * sure that we were able to do so if the fuse says we need to load via
> + * DMA and the binary is GSC-enabled.
> + */
> + if (!huc->loaded_via_gsc && gsc_enabled && !huc->fw.dma_start_offset) {
> + huc_err(huc, "HW in DMA mode, but we have an incompatible GSC-enabled blob\n");
> + return -ENOEXEC;
> + }
> +
> + /*
> + * If the HuC is loaded via GSC, we need to be able to access the GSC.
> + * On DG2 this is done via the mei components, while on newer platforms
> + * it is done via the GSCCS,
> + */
> + if (huc->loaded_via_gsc) {
> + if (IS_DG2(gt->i915)) {
> + if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP) ||
> + !IS_ENABLED(CONFIG_INTEL_MEI_GSC)) {
> + huc_info(huc, "can't load due to missing mei modules\n");
> + return -EIO;
> + }
> + } else {
> + if (!HAS_ENGINE(gt, GSC0)){
Checkpatch is complaining about lack of a space here. Maybe fix on merge
rather than repost if that is the only issue?
John.
next prev parent reply other threads:[~2023-06-01 20:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-31 23:54 [Intel-gfx] [PATCH v5 0/7] drm/i915: HuC loading and authentication for MTL Daniele Ceraolo Spurio
2023-05-31 23:54 ` [Intel-gfx] [PATCH v5 1/7] drm/i915/uc: perma-pin firmwares Daniele Ceraolo Spurio
2023-05-31 23:54 ` [Intel-gfx] [PATCH v5 2/7] drm/i915/huc: Parse the GSC-enabled HuC binary Daniele Ceraolo Spurio
2023-06-01 20:33 ` John Harrison
2023-05-31 23:54 ` [Intel-gfx] [PATCH v5 3/7] drm/i915/huc: Load GSC-enabled HuC via DMA xfer if the fuse says so Daniele Ceraolo Spurio
2023-06-01 20:36 ` John Harrison
2023-06-01 20:42 ` John Harrison [this message]
2023-05-31 23:54 ` [Intel-gfx] [PATCH v5 4/7] drm/i915/huc: differentiate the 2 steps of the MTL HuC auth flow Daniele Ceraolo Spurio
2023-06-01 20:40 ` John Harrison
2023-05-31 23:54 ` [Intel-gfx] [PATCH v5 5/7] drm/i915/mtl/huc: auth HuC via GSC Daniele Ceraolo Spurio
2023-06-01 23:12 ` Teres Alexis, Alan Previn
2023-05-31 23:54 ` [Intel-gfx] [PATCH v5 6/7] drm/i915/mtl/huc: Use the media gt for the HuC getparam Daniele Ceraolo Spurio
2023-05-31 23:54 ` [Intel-gfx] [PATCH v5 7/7] drm/i915/huc: define HuC FW version for MTL Daniele Ceraolo Spurio
2023-06-01 3:06 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: HuC loading and authentication for MTL (rev7) Patchwork
2023-06-01 3:06 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-06-01 3:20 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-06-02 18:24 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5acacf14-2785-963a-91c4-47e9487e9e4d@intel.com \
--to=john.c.harrison@intel.com \
--cc=alan.previn.teres.alexis@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox