From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com> To: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>, "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org> Cc: "Harrison, John C" <john.c.harrison@intel.com>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org> Subject: Re: [PATCH 4/6] drm/i915/uc/gsc: query the GSC FW for its compatibility version Date: Thu, 25 May 2023 23:29:39 +0000 [thread overview] Message-ID: <f34f960c06971bc784fdfb1cf2f9e067bddacf47.camel@intel.com> (raw) In-Reply-To: <20230505160415.889525-5-daniele.ceraolospurio@intel.com> On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote: > The compatibility version is queried via an MKHI command. Right now, the > only existing interface is 1.0 > This is basically the interface version for the GSC FW, so the plan is > to use it as the main tracked version, including for the binary naming > in the fetch code. > > Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > alan: just a couple of minor things nits below. One ask though, in line with the clarification we had over the offline coversation, I am wondering if we can document the fact that the file_selected.ver remains as major-minor::zero-zero for the case of gsc until after the firmware is loaded and we query via this function (which happens later at gt-late-init). However, that comment might not belong here - perhaps it belongs in the prior patch together with the other comment i requested for (asking for additional explainations about the different types of versions for gsc). That said, for this patch, LGTM: Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> alan:snip > +static int gsc_fw_query_compatibility_version(struct intel_gsc_uc *gsc) > +{ > + struct intel_gt *gt = gsc_uc_to_gt(gsc); > + struct mtl_gsc_ver_msg_in *msg_in; > + struct mtl_gsc_ver_msg_out *msg_out; > + struct i915_vma *vma; > + u64 offset; > + void *vaddr; > + int err; > + > + err = intel_guc_allocate_and_map_vma(>->uc.guc, PAGE_SIZE * 2, > + &vma, &vaddr); alan: nit: im assuming this code will be used for future discrete cards,.. if so, perhaps we should also be using "SZ_4K * 2" above since different host-cpu-arch could have different PAGE sizes - this way we'll be consistent with exact size allocations. also its more consistent in this function - maybe a #define GSC_UC_GET_ABI_VER_PKT_SIZE SZ_4K at top of function is nice. either way, i consider this a nit. > + if (err) { > + gt_err(gt, "failed to allocate vma for GSC version query\n"); > + return err; > + } alan:snip > + > int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc) > { > struct intel_gt *gt = gsc_uc_to_gt(gsc); > @@ -327,11 +406,21 @@ int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc) > if (err) > goto fail; > > + err = gsc_fw_query_compatibility_version(gsc); > + if (err) > + goto fail; > + > + /* we only support compatibility version 1.0 at the moment */ > + err = intel_uc_check_file_version(gsc_fw, NULL); > + if (err) > + goto fail; > + > /* FW is not fully operational until we enable SW proxy */ > intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED); > > - gt_info(gt, "Loaded GSC firmware %s (r%u.%u.%u.%u, svn%u)\n", > + gt_info(gt, "Loaded GSC firmware %s (cv%u.%u, r%u.%u.%u.%u, svn %u)\n", alan:nit "abi" instead of "cv"? > gsc_fw->file_selected.path, > + gsc_fw->file_selected.ver.major, gsc_fw->file_selected.ver.minor, > gsc->release.major, gsc->release.minor, > gsc->release.patch, gsc->release.build, > gsc->security_version); > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h > index 8f199d5f963e..fb1453ed4ecf 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h > +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h alan:snip > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c > index cd8fc194f7fa..36ee96c02d74 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c alan:snip > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h > index 279244744d43..4406e7b48b27 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h alan:snip
WARNING: multiple messages have this Message-ID (diff)
From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com> To: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>, "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org> Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org> Subject: Re: [Intel-gfx] [PATCH 4/6] drm/i915/uc/gsc: query the GSC FW for its compatibility version Date: Thu, 25 May 2023 23:29:39 +0000 [thread overview] Message-ID: <f34f960c06971bc784fdfb1cf2f9e067bddacf47.camel@intel.com> (raw) In-Reply-To: <20230505160415.889525-5-daniele.ceraolospurio@intel.com> On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote: > The compatibility version is queried via an MKHI command. Right now, the > only existing interface is 1.0 > This is basically the interface version for the GSC FW, so the plan is > to use it as the main tracked version, including for the binary naming > in the fetch code. > > Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > alan: just a couple of minor things nits below. One ask though, in line with the clarification we had over the offline coversation, I am wondering if we can document the fact that the file_selected.ver remains as major-minor::zero-zero for the case of gsc until after the firmware is loaded and we query via this function (which happens later at gt-late-init). However, that comment might not belong here - perhaps it belongs in the prior patch together with the other comment i requested for (asking for additional explainations about the different types of versions for gsc). That said, for this patch, LGTM: Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> alan:snip > +static int gsc_fw_query_compatibility_version(struct intel_gsc_uc *gsc) > +{ > + struct intel_gt *gt = gsc_uc_to_gt(gsc); > + struct mtl_gsc_ver_msg_in *msg_in; > + struct mtl_gsc_ver_msg_out *msg_out; > + struct i915_vma *vma; > + u64 offset; > + void *vaddr; > + int err; > + > + err = intel_guc_allocate_and_map_vma(>->uc.guc, PAGE_SIZE * 2, > + &vma, &vaddr); alan: nit: im assuming this code will be used for future discrete cards,.. if so, perhaps we should also be using "SZ_4K * 2" above since different host-cpu-arch could have different PAGE sizes - this way we'll be consistent with exact size allocations. also its more consistent in this function - maybe a #define GSC_UC_GET_ABI_VER_PKT_SIZE SZ_4K at top of function is nice. either way, i consider this a nit. > + if (err) { > + gt_err(gt, "failed to allocate vma for GSC version query\n"); > + return err; > + } alan:snip > + > int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc) > { > struct intel_gt *gt = gsc_uc_to_gt(gsc); > @@ -327,11 +406,21 @@ int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc) > if (err) > goto fail; > > + err = gsc_fw_query_compatibility_version(gsc); > + if (err) > + goto fail; > + > + /* we only support compatibility version 1.0 at the moment */ > + err = intel_uc_check_file_version(gsc_fw, NULL); > + if (err) > + goto fail; > + > /* FW is not fully operational until we enable SW proxy */ > intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED); > > - gt_info(gt, "Loaded GSC firmware %s (r%u.%u.%u.%u, svn%u)\n", > + gt_info(gt, "Loaded GSC firmware %s (cv%u.%u, r%u.%u.%u.%u, svn %u)\n", alan:nit "abi" instead of "cv"? > gsc_fw->file_selected.path, > + gsc_fw->file_selected.ver.major, gsc_fw->file_selected.ver.minor, > gsc->release.major, gsc->release.minor, > gsc->release.patch, gsc->release.build, > gsc->security_version); > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h > index 8f199d5f963e..fb1453ed4ecf 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h > +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h alan:snip > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c > index cd8fc194f7fa..36ee96c02d74 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c alan:snip > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h > index 279244744d43..4406e7b48b27 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h alan:snip
next prev parent reply other threads:[~2023-05-25 23:29 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-05-05 16:04 [PATCH 0/6] drm/i915: GSC FW support for MTL Daniele Ceraolo Spurio 2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio 2023-05-05 16:04 ` [PATCH 1/6] DO NOT REVIEW: drm/i915: HuC loading and authentication " Daniele Ceraolo Spurio 2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio 2023-05-05 16:04 ` [PATCH 2/6] drm/i915/uc/gsc: fixes and updates for GSC memory allocation Daniele Ceraolo Spurio 2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio 2023-05-23 0:13 ` Teres Alexis, Alan Previn 2023-05-23 0:13 ` [Intel-gfx] " Teres Alexis, Alan Previn 2023-05-23 15:21 ` Ceraolo Spurio, Daniele 2023-05-23 15:21 ` [Intel-gfx] " Ceraolo Spurio, Daniele 2023-06-06 0:00 ` Teres Alexis, Alan Previn 2023-06-06 0:00 ` [Intel-gfx] " Teres Alexis, Alan Previn 2023-05-05 16:04 ` [PATCH 3/6] drm/i915/uc/gsc: extract release and security versions from the gsc binary Daniele Ceraolo Spurio 2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio 2023-05-25 5:14 ` Teres Alexis, Alan Previn 2023-05-25 5:14 ` [Intel-gfx] " Teres Alexis, Alan Previn 2023-05-25 16:56 ` Ceraolo Spurio, Daniele 2023-05-25 16:56 ` [Intel-gfx] " Ceraolo Spurio, Daniele 2023-05-25 22:03 ` Teres Alexis, Alan Previn 2023-05-25 22:03 ` [Intel-gfx] " Teres Alexis, Alan Previn 2023-05-27 1:27 ` Ceraolo Spurio, Daniele 2023-05-27 1:27 ` [Intel-gfx] " Ceraolo Spurio, Daniele 2023-06-05 23:51 ` Teres Alexis, Alan Previn 2023-06-05 23:51 ` [Intel-gfx] " Teres Alexis, Alan Previn 2023-05-05 16:04 ` [PATCH 4/6] drm/i915/uc/gsc: query the GSC FW for its compatibility version Daniele Ceraolo Spurio 2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio 2023-05-25 23:29 ` Teres Alexis, Alan Previn [this message] 2023-05-25 23:29 ` Teres Alexis, Alan Previn 2023-05-05 16:04 ` [PATCH 5/6] drm/i915/uc/gsc: define gsc fw Daniele Ceraolo Spurio 2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio 2023-05-25 23:48 ` Teres Alexis, Alan Previn 2023-05-25 23:48 ` [Intel-gfx] " Teres Alexis, Alan Previn 2023-06-01 0:32 ` Ceraolo Spurio, Daniele 2023-06-01 0:32 ` [Intel-gfx] " Ceraolo Spurio, Daniele 2023-05-05 16:04 ` [PATCH 6/6] drm/i915/uc/gsc: Add a gsc_info debugfs Daniele Ceraolo Spurio 2023-05-05 16:04 ` [Intel-gfx] " Daniele Ceraolo Spurio 2023-05-26 22:57 ` Teres Alexis, Alan Previn 2023-05-26 22:57 ` [Intel-gfx] " Teres Alexis, Alan Previn 2023-06-01 0:25 ` Ceraolo Spurio, Daniele 2023-06-01 0:25 ` [Intel-gfx] " Ceraolo Spurio, Daniele 2023-06-05 23:46 ` Teres Alexis, Alan Previn 2023-06-05 23:46 ` [Intel-gfx] " Teres Alexis, Alan Previn 2023-06-05 23:53 ` Ceraolo Spurio, Daniele 2023-06-05 23:53 ` [Intel-gfx] " Ceraolo Spurio, Daniele 2023-05-05 21:02 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: GSC FW support for MTL 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=f34f960c06971bc784fdfb1cf2f9e067bddacf47.camel@intel.com \ --to=alan.previn.teres.alexis@intel.com \ --cc=daniele.ceraolospurio@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=john.c.harrison@intel.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.