Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: Riana Tauro <riana.tauro@intel.com>, <intel-xe@lists.freedesktop.org>
Cc: <anshuman.gupta@intel.com>, <umesh.nerlige.ramappa@intel.com>,
	<lucas.demarchi@intel.com>, <vinay.belgaumkar@intel.com>,
	<soham.purkait@intel.com>
Subject: Re: [PATCH v4 5/8] drm/xe/guc: Bump minimum required GuC version to v70.36.0
Date: Thu, 30 Jan 2025 12:04:07 -0800	[thread overview]
Message-ID: <04bca992-f221-443e-9da5-3fb235ad52ea@intel.com> (raw)
In-Reply-To: <20250129101653.1976699-6-riana.tauro@intel.com>

On 1/29/2025 02:16, Riana Tauro wrote:
> The VF API version for this release is 1.17.1
>
> Bump the minimum required version to v70.36.0 to support
> engine activity.
We can only bump the minimum recommended version, not the required version.

>
> Suggested-by: John Harrison <John.C.Harrison@Intel.com>
> Signed-off-by: Riana Tauro <riana.tauro@intel.com>
> ---
>   drivers/gpu/drm/xe/xe_uc_fw.c | 28 ++++++++++++++--------------
>   1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_uc_fw.c b/drivers/gpu/drm/xe/xe_uc_fw.c
> index 18e06ee9e23f..d9ff285c5d1d 100644
> --- a/drivers/gpu/drm/xe/xe_uc_fw.c
> +++ b/drivers/gpu/drm/xe/xe_uc_fw.c
> @@ -108,17 +108,17 @@ struct fw_blobs_by_type {
>   
>   #define XE_GUC_FIRMWARE_DEFS(fw_def, mmp_ver, major_ver)			\
>   	fw_def(PANTHERLAKE,	mmp_ver(xe,	guc,	ptl,	70, 38, 1))	\
> -	fw_def(BATTLEMAGE,	major_ver(xe,	guc,	bmg,	70, 29, 2))	\
> -	fw_def(LUNARLAKE,	major_ver(xe,	guc,	lnl,	70, 29, 2))	\
> -	fw_def(METEORLAKE,	major_ver(i915,	guc,	mtl,	70, 29, 2))	\
> -	fw_def(PVC,		mmp_ver(xe,	guc,	pvc,	70, 29, 2))	\
> -	fw_def(DG2,		major_ver(i915,	guc,	dg2,	70, 29, 2))	\
> -	fw_def(DG1,		major_ver(i915,	guc,	dg1,	70, 29, 2))	\
> -	fw_def(ALDERLAKE_N,	major_ver(i915,	guc,	tgl,	70, 29, 2))	\
> -	fw_def(ALDERLAKE_P,	major_ver(i915,	guc,	adlp,	70, 29, 2))	\
> -	fw_def(ALDERLAKE_S,	major_ver(i915,	guc,	tgl,	70, 29, 2))	\
> -	fw_def(ROCKETLAKE,	major_ver(i915,	guc,	tgl,	70, 29, 2))	\
> -	fw_def(TIGERLAKE,	major_ver(i915,	guc,	tgl,	70, 29, 2))
> +	fw_def(BATTLEMAGE,	major_ver(xe,	guc,	bmg,	70, 36, 0))	\
> +	fw_def(LUNARLAKE,	major_ver(xe,	guc,	lnl,	70, 36, 0))	\
> +	fw_def(METEORLAKE,	major_ver(i915,	guc,	mtl,	70, 36, 0))	\
> +	fw_def(PVC,		mmp_ver(xe,	guc,	pvc,	70, 36, 0))	\
> +	fw_def(DG2,		major_ver(i915,	guc,	dg2,	70, 36, 0))	\
> +	fw_def(DG1,		major_ver(i915,	guc,	dg1,	70, 36, 0))	\
> +	fw_def(ALDERLAKE_N,	major_ver(i915,	guc,	tgl,	70, 36, 0))	\
> +	fw_def(ALDERLAKE_P,	major_ver(i915,	guc,	adlp,	70, 36, 0))	\
> +	fw_def(ALDERLAKE_S,	major_ver(i915,	guc,	tgl,	70, 36, 0))	\
> +	fw_def(ROCKETLAKE,	major_ver(i915,	guc,	tgl,	70, 36, 0))	\
> +	fw_def(TIGERLAKE,	major_ver(i915,	guc,	tgl,	70, 36, 0))
This part is technically fine, but note that we have just discovered an 
issue with recent GuC releases which means we need to wait for a bug fix 
before updating.

Also note that the purpose of the minor/patch version numbers in this 
table is just to provide a notice to the user that they should update. 
So after the update to 70.36.0, if a user boots a LNL with 70.29.2, they 
will get a line in dmesg saying "please update". But the driver will 
still load and run with no negative effects.

>   
>   #define XE_HUC_FIRMWARE_DEFS(fw_def, mmp_ver, no_ver)		\
>   	fw_def(PANTHERLAKE,	mmp_ver(xe,	huc,		ptl, 10, 2, 1))	\
> @@ -320,9 +320,9 @@ static int guc_read_css_info(struct xe_uc_fw *uc_fw, struct uc_css_header *css)
>   
>   	xe_gt_assert(gt, uc_fw->type == XE_UC_FW_TYPE_GUC);
>   
> -	/* We don't support GuC releases older than 70.29.2 */
> -	if (MAKE_GUC_VER_STRUCT(*release) < MAKE_GUC_VER(70, 29, 2)) {
> -		xe_gt_err(gt, "Unsupported GuC v%u.%u.%u! v70.29.2 or newer is required\n",
> +	/* We don't support GuC releases older than 70.36.0 */
> +	if (MAKE_GUC_VER_STRUCT(*release) < MAKE_GUC_VER(70, 36, 0)) {
> +		xe_gt_err(gt, "Unsupported GuC v%u.%u.%u! v70.36.0 or newer is required\n",
This is definitely not allowed.

Once a GuC has been released for a given platform, it must be supported 
forever on that platform. Which means that LNL and BMG must forever be 
able to run on 70.29.2.

If we really need to, we can add a per platform variant of this check 
for new platforms. E.g. PTL must be at least 70.39.42 or whatever. But 
we can't ever change the Xe global base line version. And there isn't 
much point in adding a new platform baseline because we just don't push 
the firmware upstream for new platforms until we are ready to do an 
official release. So there simply aren't any other versions available to 
warrant a baseline version check.

Rather than bumping the baseline here, individual features must check 
for a suitable GuC version. Which is what you have in patch #3 - the 
check for GUC_VER(1.14.1). That ensures that the new feature will not 
try to run if a new enough GuC is not available on the user's system.

John.

>   			  release->major, release->minor, release->patch);
>   		return -EINVAL;
>   	}


  parent reply	other threads:[~2025-01-30 20:04 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-29 10:16 [PATCH v4 0/8] PMU Support for per-engine-class activity Riana Tauro
2025-01-29 10:16 ` [PATCH v4 1/8] drm/xe: Add per-engine-class activity support Riana Tauro
2025-01-30  0:28   ` Umesh Nerlige Ramappa
2025-01-30  2:35     ` Rodrigo Vivi
2025-01-30  4:49       ` Riana Tauro
2025-01-30 22:36         ` Rodrigo Vivi
2025-01-30 23:56           ` Lucas De Marchi
2025-01-31 17:13             ` Umesh Nerlige Ramappa
2025-02-03  5:15               ` Riana Tauro
2025-01-30 23:00         ` Lucas De Marchi
2025-01-30 17:52       ` Umesh Nerlige Ramappa
2025-01-30 20:47       ` Lucas De Marchi
2025-01-30 20:38     ` Lucas De Marchi
2025-01-29 10:16 ` [PATCH v4 2/8] drm/xe/trace: Add trace for engine activity Riana Tauro
2025-01-29 10:16 ` [PATCH v4 3/8] drm/xe/guc: Expose engine activity only for supported GuC version Riana Tauro
2025-01-29 20:18   ` Michal Wajdeczko
2025-01-30  5:20     ` Riana Tauro
2025-01-29 10:16 ` [PATCH v4 4/8] drm/xe/xe_pmu: Add PMU support for per-engine-class activity Riana Tauro
2025-01-31 23:11   ` Umesh Nerlige Ramappa
2025-02-03 14:14     ` Riana Tauro
2025-02-05  1:28       ` Umesh Nerlige Ramappa
2025-01-29 10:16 ` [PATCH v4 5/8] drm/xe/guc: Bump minimum required GuC version to v70.36.0 Riana Tauro
2025-01-30 17:40   ` Umesh Nerlige Ramappa
2025-01-30 20:04   ` John Harrison [this message]
2025-01-31  7:01     ` Riana Tauro
2025-01-29 10:16 ` [PATCH v4 6/8] drm/xe: Add support for per-function engine activity Riana Tauro
2025-01-31 23:52   ` Umesh Nerlige Ramappa
2025-02-03  5:26     ` Riana Tauro
2025-02-05  1:30       ` Umesh Nerlige Ramappa
2025-01-29 10:16 ` [PATCH v4 7/8] drm/xe/xe_pmu: Add pmu support for per-function engine activity stats Riana Tauro
2025-02-01  0:00   ` Umesh Nerlige Ramappa
2025-02-01  0:23   ` Lucas De Marchi
2025-02-01  1:21     ` Umesh Nerlige Ramappa
2025-02-01  2:53       ` Lucas De Marchi
2025-02-03  9:59     ` Riana Tauro
2025-01-29 10:16 ` [PATCH v4 8/8] drm/xe/pf: Enable per-function per-engine-class " Riana Tauro
2025-01-29 11:38 ` ✓ CI.Patch_applied: success for PMU Support for per-engine-class activity (rev2) Patchwork
2025-01-29 11:39 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-29 11:40 ` ✓ CI.KUnit: success " Patchwork
2025-01-29 11:56 ` ✓ CI.Build: " Patchwork
2025-01-29 11:58 ` ✗ CI.Hooks: failure " Patchwork
2025-01-29 12:00 ` ✓ CI.checksparse: success " Patchwork
2025-01-29 12:36 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-01-29 21:35 ` ✗ Xe.CI.Full: " Patchwork
2025-01-30  0:06 ` [PATCH v4 0/8] PMU Support for per-engine-class activity Umesh Nerlige Ramappa

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=04bca992-f221-443e-9da5-3fb235ad52ea@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=riana.tauro@intel.com \
    --cc=soham.purkait@intel.com \
    --cc=umesh.nerlige.ramappa@intel.com \
    --cc=vinay.belgaumkar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox