public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>,
	<Intel-GFX@Lists.FreeDesktop.Org>
Cc: DRI-Devel@Lists.FreeDesktop.Org
Subject: Re: [Intel-gfx] [PATCH 3/5] drm/i915/uc: Track patch level versions on reduced version firmware files
Date: Wed, 19 Apr 2023 09:06:36 -0700	[thread overview]
Message-ID: <fdbe9a14-e1f4-ecfa-32f8-d5bcdfe3c336@intel.com> (raw)
In-Reply-To: <23ca7d75-e96d-5536-25a1-a1c8a0167b48@intel.com>

On 4/18/2023 15:46, Ceraolo Spurio, Daniele wrote:
> On 4/14/2023 5:57 PM, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> When reduced version firmware files were added (matching major
>> component being the only strict requirement), the minor version was
>> still tracked and a notification reported if it was older. However,
>> the patch version should really be tracked as well for the same
>> reasons. The KMD can work without the change but if the effort has
>> been taken to release a new firmware with the change then there must
>> be a valid reason for doing so - important bug fix, security fix, etc.
>> And in that case it would be good to alert the user if they are
>> missing out on that new fix.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> ---
>>   drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 41 +++++++++++++++++-------
>>   1 file changed, 30 insertions(+), 11 deletions(-)
>>
>> 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 a82a53dbbc86d..6bb45d6b8da5f 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
>> @@ -80,14 +80,14 @@ void intel_uc_fw_change_status(struct intel_uc_fw 
>> *uc_fw,
>>    */
>>   #define INTEL_GUC_FIRMWARE_DEFS(fw_def, guc_maj, guc_mmp) \
>>       fw_def(METEORLAKE,   0, guc_mmp(mtl,  70, 6, 5)) \
>> -    fw_def(DG2,          0, guc_maj(dg2,  70, 5)) \
>> -    fw_def(ALDERLAKE_P,  0, guc_maj(adlp, 70, 5)) \
>> +    fw_def(DG2,          0, guc_maj(dg2,  70, 5, 4)) \
>> +    fw_def(ALDERLAKE_P,  0, guc_maj(adlp, 70, 5, 4)) \
>>       fw_def(ALDERLAKE_P,  0, guc_mmp(adlp, 70, 1, 1)) \
>>       fw_def(ALDERLAKE_P,  0, guc_mmp(adlp, 69, 0, 3)) \
>> -    fw_def(ALDERLAKE_S,  0, guc_maj(tgl,  70, 5)) \
>> +    fw_def(ALDERLAKE_S,  0, guc_maj(tgl,  70, 5, 4)) \
>>       fw_def(ALDERLAKE_S,  0, guc_mmp(tgl,  70, 1, 1)) \
>>       fw_def(ALDERLAKE_S,  0, guc_mmp(tgl,  69, 0, 3)) \
>> -    fw_def(DG1,          0, guc_maj(dg1,  70, 5)) \
>> +    fw_def(DG1,          0, guc_maj(dg1,  70, 5, 4)) \
>>       fw_def(ROCKETLAKE,   0, guc_mmp(tgl,  70, 1, 1)) \
>>       fw_def(TIGERLAKE,    0, guc_mmp(tgl,  70, 1, 1)) \
>>       fw_def(JASPERLAKE,   0, guc_mmp(ehl,  70, 1, 1)) \
>
> AFAICS in linux-firmware we don't have any 70.5.4 binaries, the newest 
> ones are 70.5.1.
You would be correct. Hence the CI results all say:
<5> [27.947440] i915 0000:00:02.0: [drm] GT0: GuC firmware 
i915/adlp_guc_70.bin (70.5.4) is recommended, but only 
i915/adlp_guc_70.bin (70.5.1) was found

I was just testing that the code worked ;)...

Although it does beg the question that maybe we should bump the print 
from a 'notice' to an 'err' if CONFIG_DEBUG_GEM is defined or something? 
Ensure that CI is actually testing against the correct firmware versions.


>
>> @@ -141,7 +141,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw 
>> *uc_fw,
>>       __stringify(patch_) ".bin"
>>     /* Minor for internal driver use, not part of file name */
>> -#define MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_) \
>> +#define MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_) \
>>       __MAKE_UC_FW_PATH_MAJOR(prefix_, "guc", major_)
>>     #define MAKE_GUC_FW_PATH_MMP(prefix_, major_, minor_, patch_) \
>> @@ -197,9 +197,9 @@ struct __packed uc_fw_blob {
>>       { UC_FW_BLOB_BASE(major_, minor_, patch_, path_) \
>>         .legacy = true }
>>   -#define GUC_FW_BLOB(prefix_, major_, minor_) \
>> -    UC_FW_BLOB_NEW(major_, minor_, 0, false, \
>> -               MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_))
>> +#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \
>> +    UC_FW_BLOB_NEW(major_, minor_, patch_, false, \
>> +               MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_))
>>     #define GUC_FW_BLOB_MMP(prefix_, major_, minor_, patch_) \
>>       UC_FW_BLOB_OLD(major_, minor_, patch_, \
>> @@ -296,6 +296,7 @@ __uc_fw_auto_select(struct drm_i915_private 
>> *i915, struct intel_uc_fw *uc_fw)
>>           uc_fw->file_wanted.path = blob->path;
>>           uc_fw->file_wanted.ver.major = blob->major;
>>           uc_fw->file_wanted.ver.minor = blob->minor;
>> +        uc_fw->file_wanted.ver.patch = blob->patch;
>>           uc_fw->loaded_via_gsc = blob->loaded_via_gsc;
>>           found = true;
>>           break;
>> @@ -776,6 +777,17 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
>>       if (uc_fw->type == INTEL_UC_FW_TYPE_GUC && 
>> !guc_check_version_range(uc_fw))
>>           goto fail;
>>   +    gt_info(gt, "%s firmware: wanted = %s / %d.%d.%d, got = %s / 
>> %d.%d.%d\n",
>> +        intel_uc_fw_type_repr(uc_fw->type),
>> +        uc_fw->file_wanted.path,
>> +        uc_fw->file_wanted.ver.major,
>> +        uc_fw->file_wanted.ver.minor,
>> +        uc_fw->file_wanted.ver.patch,
>> +        uc_fw->file_selected.path,
>> +        uc_fw->file_selected.ver.major,
>> +        uc_fw->file_selected.ver.minor,
>> +        uc_fw->file_selected.ver.patch);
>
> Some of the info here is redundant from print_fw_ver(). Can we have a 
> single print with all the info we need?
> Something like:
Hmm. I think this was just my test code that got left in by accident. As 
you say, we print the actual version in use later on when we do the load 
itself. And if the wanted does not match then we print the 'is 
recommended' message below. So this line is basically redundant. I'll 
remove it.

John.

>
> GuC firmware i915/mtl_guc_70.bin (v70.6.5, expected v70.6.4 or newer)
>
> Otherwise, I'd suggest demoting this to gt_dbg to avoid printing the 
> same thing twice at info verbosity
>
> Daniele
>
>> +
>>       if (uc_fw->file_wanted.ver.major && 
>> uc_fw->file_selected.ver.major) {
>>           /* Check the file's major version was as it claimed */
>>           if (uc_fw->file_selected.ver.major != 
>> uc_fw->file_wanted.ver.major) {
>> @@ -790,6 +802,9 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
>>           } else {
>>               if (uc_fw->file_selected.ver.minor < 
>> uc_fw->file_wanted.ver.minor)
>>                   old_ver = true;
>> +            else if ((uc_fw->file_selected.ver.minor == 
>> uc_fw->file_wanted.ver.minor) &&
>> +                 (uc_fw->file_selected.ver.patch < 
>> uc_fw->file_wanted.ver.patch))
>> +                old_ver = true;
>>           }
>>       }
>>   @@ -797,12 +812,16 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
>>           /* Preserve the version that was really wanted */
>>           memcpy(&uc_fw->file_wanted, &file_ideal, 
>> sizeof(uc_fw->file_wanted));
>>   -        gt_notice(gt, "%s firmware %s (%d.%d) is recommended, but 
>> only %s (%d.%d) was found\n",
>> +        gt_notice(gt, "%s firmware %s (%d.%d.%d) is recommended, but 
>> only %s (%d.%d.%d) was found\n",
>>                 intel_uc_fw_type_repr(uc_fw->type),
>>                 uc_fw->file_wanted.path,
>> -              uc_fw->file_wanted.ver.major, 
>> uc_fw->file_wanted.ver.minor,
>> +              uc_fw->file_wanted.ver.major,
>> +              uc_fw->file_wanted.ver.minor,
>> +              uc_fw->file_wanted.ver.patch,
>>                 uc_fw->file_selected.path,
>> -              uc_fw->file_selected.ver.major, 
>> uc_fw->file_selected.ver.minor);
>> +              uc_fw->file_selected.ver.major,
>> +              uc_fw->file_selected.ver.minor,
>> +              uc_fw->file_selected.ver.patch);
>>           gt_info(gt, "Consider updating your linux-firmware pkg or 
>> downloading from %s\n",
>>               INTEL_UC_FIRMWARE_URL);
>>       }
>


  reply	other threads:[~2023-04-19 16:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-15  0:57 [Intel-gfx] [PATCH 0/5] Improvements to uc firmare management John.C.Harrison
2023-04-15  0:57 ` [Intel-gfx] [PATCH 1/5] drm/i915/guc: Decode another GuC load failure case John.C.Harrison
2023-04-18 18:41   ` Ceraolo Spurio, Daniele
2023-04-15  0:57 ` [Intel-gfx] [PATCH 2/5] drm/i915/guc: Print status register when waiting for GuC to load John.C.Harrison
2023-04-18 18:37   ` Ceraolo Spurio, Daniele
2023-04-15  0:57 ` [Intel-gfx] [PATCH 3/5] drm/i915/uc: Track patch level versions on reduced version firmware files John.C.Harrison
2023-04-18 22:46   ` Ceraolo Spurio, Daniele
2023-04-19 16:06     ` John Harrison [this message]
2023-04-15  0:57 ` [Intel-gfx] [PATCH 4/5] drm/i915/uc: Split firmware table validation to a separate function John.C.Harrison
2023-04-18 23:14   ` Ceraolo Spurio, Daniele
2023-04-19 15:45     ` John Harrison
2023-04-15  0:57 ` [Intel-gfx] [PATCH 5/5] drm/i915/uc: Reject doplicate entries in firmware table John.C.Harrison
2023-04-18 23:24   ` Ceraolo Spurio, Daniele
2023-04-19 17:02     ` John Harrison
2023-04-19 17:12       ` John Harrison
2023-04-19 17:33         ` Ceraolo Spurio, Daniele
2023-04-19 17:59           ` John Harrison
2023-04-15  1:28 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Improvements to uc firmare management Patchwork
2023-04-15  1:28 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-04-15  1:44 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-15  8:09 ` [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=fdbe9a14-e1f4-ecfa-32f8-d5bcdfe3c336@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=DRI-Devel@Lists.FreeDesktop.Org \
    --cc=Intel-GFX@Lists.FreeDesktop.Org \
    --cc=daniele.ceraolospurio@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