All of lore.kernel.org
 help / color / mirror / Atom feed
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(&gt->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(&gt->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

  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: link
Be 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.