Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Riana Tauro <riana.tauro@intel.com>
To: John Harrison <john.c.harrison@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: Fri, 31 Jan 2025 12:31:06 +0530	[thread overview]
Message-ID: <0959ad09-ee58-4e19-b553-6e74434ebd99@intel.com> (raw)
In-Reply-To: <04bca992-f221-443e-9da5-3fb235ad52ea@intel.com>

Hi John

On 1/31/2025 1:34 AM, John Harrison wrote:
> 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.
I took the reference of 70.29.2 patch for this.
> 
>>
>> 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.
I added this as per your suggestion in the last rev. Should i drop this 
from the series till the guc release with the bug fix comes in?
> 
> 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.

Sorry about that. I took the reference of the patch 70.29.2. Looks like 
that was intended for baseline update.

I will drop the baseline update.

Thanks
Riana
> 
> John.
> 
>>                 release->major, release->minor, release->patch);
>>           return -EINVAL;
>>       }
> 


  reply	other threads:[~2025-01-31  7:01 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
2025-01-31  7:01     ` Riana Tauro [this message]
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=0959ad09-ee58-4e19-b553-6e74434ebd99@intel.com \
    --to=riana.tauro@intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=john.c.harrison@intel.com \
    --cc=lucas.demarchi@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