From: John Harrison <john.c.harrison@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>,
"Welty, Brian" <brian.welty@intel.com>
Cc: Intel-Xe@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/xe/guc: Update to GuC firmware 70.19.1
Date: Tue, 23 Jan 2024 15:24:45 -0800 [thread overview]
Message-ID: <773deddc-54e6-44b4-9ea1-16a314474abe@intel.com> (raw)
In-Reply-To: <wqlmadoyl4ifwavwaihupuc66nygylkxijofftrphjc4bv5djz@63tydn37unxg>
On 1/23/2024 08:41, Lucas De Marchi wrote:
> On Mon, Jan 22, 2024 at 02:14:56PM -0800, Welty, Brian wrote:
>> On 1/22/2024 1:37 PM, John.C.Harrison@Intel.com wrote:
>>> From: John Harrison <John.C.Harrison@Intel.com>
>>>
>>> UAPI compatibility version: 1.8.1
>
> what exactly is this? We don't seem to track it anywhere in the driver.
It is XE_UC_FW_VER_COMPATIBILITY. This is the version number that should
be looked at for tracking what features are or are not available. The
raw file version (e.g. 70.19.1) is XE_UC_FW_VER_RELEASE but that is not
accessible from a VF and cannot be exported to UMDs because again, it
would break in an SRIOV type scenario. The file version should only be
used for feature checks when actually loading the GuC itself (which can
only be done by native/PF), e.g. what to put in the ADS, what load time
w/a's should be enabled, etc.
>
>>
>> I've wondered for awhile why was lagging behind here....
>>
>> Reviewed-by: Brian Welty <brian.welty@intel.com>
>>
>>>
>>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>>> ---
>>> drivers/gpu/drm/xe/xe_uc_fw.c | 16 ++++++++--------
>>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_uc_fw.c
>>> b/drivers/gpu/drm/xe/xe_uc_fw.c
>>> index d3f0fe2101a7..8da6cbb8c9e2 100644
>>> --- a/drivers/gpu/drm/xe/xe_uc_fw.c
>>> +++ b/drivers/gpu/drm/xe/xe_uc_fw.c
>>> @@ -103,14 +103,14 @@ struct fw_blobs_by_type {
>>> };
>>> #define XE_GUC_FIRMWARE_DEFS(fw_def, mmp_ver, major_ver) \
>>> - fw_def(METEORLAKE, major_ver(i915, guc, mtl, 70, 7,
>>> 0)) \
>>> - fw_def(DG2, major_ver(i915, guc, dg2, 70, 5,
>>> 0)) \
>>> - fw_def(DG1, major_ver(i915, guc, dg1, 70, 5,
>>> 0)) \
>>> - fw_def(ALDERLAKE_N, major_ver(i915, guc, tgl, 70, 5,
>>> 0)) \
>>> - fw_def(ALDERLAKE_P, major_ver(i915, guc, adlp, 70, 5,
>>> 0)) \
>>> - fw_def(ALDERLAKE_S, major_ver(i915, guc, tgl, 70, 5,
>>> 0)) \
>>> - fw_def(ROCKETLAKE, major_ver(i915, guc, tgl, 70, 5,
>>> 0)) \
>>> - fw_def(TIGERLAKE, major_ver(i915, guc, tgl, 70, 5, 0))
>>> + fw_def(METEORLAKE, major_ver(i915, guc, mtl, 70, 19,
>>> 1)) \
>>> + fw_def(DG2, major_ver(i915, guc, dg2, 70, 19,
>>> 1)) \
>>> + fw_def(DG1, major_ver(i915, guc, dg1, 70, 19,
>>> 1)) \
>>> + fw_def(ALDERLAKE_N, major_ver(i915, guc, tgl, 70, 19,
>>> 1)) \
>>> + fw_def(ALDERLAKE_P, major_ver(i915, guc, adlp, 70, 19,
>>> 1)) \
>>> + fw_def(ALDERLAKE_S, major_ver(i915, guc, tgl, 70, 19,
>>> 1)) \
>>> + fw_def(ROCKETLAKE, major_ver(i915, guc, tgl, 70, 19,
>>> 1)) \
>>> + fw_def(TIGERLAKE, major_ver(i915, guc, tgl, 70, 19, 1))
>
> are all of these in linux-firmware repo?
Not in the upstream repo yet. I'm about to start that process.
John.
>
> Lucas De Marchi
>
>>> #define XE_HUC_FIRMWARE_DEFS(fw_def, mmp_ver, no_ver) \
>>> fw_def(METEORLAKE, no_ver(i915, huc_gsc, mtl)) \
next prev parent reply other threads:[~2024-01-23 23:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 21:37 [PATCH 0/2] Update to GuC 70.19.1 John.C.Harrison
2024-01-22 21:37 ` [PATCH 1/2] drm/xe/uc: Include patch version in expectations John.C.Harrison
2024-01-22 22:15 ` Welty, Brian
2024-02-01 18:10 ` Lucas De Marchi
2024-01-22 21:37 ` [PATCH 2/2] drm/xe/guc: Update to GuC firmware 70.19.1 John.C.Harrison
2024-01-22 22:14 ` Welty, Brian
2024-01-23 16:41 ` Lucas De Marchi
2024-01-23 23:24 ` John Harrison [this message]
2024-01-24 4:45 ` Lucas De Marchi
2024-01-22 22:54 ` ✗ CI.Patch_applied: failure for Update to GuC 70.19.1 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=773deddc-54e6-44b4-9ea1-16a314474abe@intel.com \
--to=john.c.harrison@intel.com \
--cc=Intel-Xe@lists.freedesktop.org \
--cc=brian.welty@intel.com \
--cc=lucas.demarchi@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