[PATCH 2/4] drm/xe/guc: Add firmware build type to available info
John Harrison
john.c.harrison at intel.com
Wed Jul 30 20:06:56 UTC 2025
On 7/25/2025 1:39 AM, Michal Wajdeczko wrote:
>
> On 7/25/2025 2:21 AM, John.C.Harrison at Intel.com wrote:
>> From: John Harrison <John.C.Harrison at Intel.com>
>>
>> Some test features are not available in production builds of the GuC
>> firmware. So add the build type field to the available information
>> that tests can inspect to decide if they should skip or run.
>>
>> Signed-off-by: John Harrison <John.C.Harrison at Intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_uc_fw.c | 1 +
>> drivers/gpu/drm/xe/xe_uc_fw_types.h | 3 +++
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_uc_fw.c b/drivers/gpu/drm/xe/xe_uc_fw.c
>> index c8378f3e0032..d51827c969b8 100644
>> --- a/drivers/gpu/drm/xe/xe_uc_fw.c
>> +++ b/drivers/gpu/drm/xe/xe_uc_fw.c
>> @@ -348,6 +348,7 @@ static int guc_read_css_info(struct xe_uc_fw *uc_fw, struct uc_css_header *css)
>> compatibility->minor = FIELD_GET(CSS_SW_VERSION_UC_MINOR, css->guc_info.submission_version);
>> compatibility->patch = FIELD_GET(CSS_SW_VERSION_UC_PATCH, css->guc_info.submission_version);
>>
>> + uc_fw->build_type = FIELD_GET(CSS_UKERNEL_INFO_BUILDTYPE, css->guc_info.ukernel_info);
>> uc_fw->private_data_size = css->guc_info.private_data_size;>
>> return 0;
> maybe we could extend our info message to include build type? instead
>
> [drm] GT0: Using GuC firmware from xe/ptl_guc_70.bin version 70.47.0
>
> something like:
>
> [drm] GT0: Using GuC firmware from xe/ptl_guc_70.bin version 70.47.0 debug
> [drm] GT0: Using GuC firmware from xe/ptl_guc_70.bin version 70.47.0 pre-production
>
> or
>
> [drm] GT0: Using GuC debug firmware from xe/ptl_guc_70.bin version 70.47.0
> [drm] GT0: Using GuC pre-prod firmware from xe/ptl_guc_70.bin version 70.47.0
That gets quite messy to implement. The version print (and the code
which calls it) is generic to all firmware types but the build type is
GuC specific.
It would be easy to print something in guc_read_css_info() when it pulls
the field out, but not sure it is really worth an extra line of debug
output just to print the build type. It is almost never a question. As
in, a given platform will be at a given level of build for quite some
time and then switch to the next level up with a version bump. So for
official builds, knowing the platform and version will tell you the
build type. And for local debug builds, the developer should know what
they are running with!
John.
>
>> diff --git a/drivers/gpu/drm/xe/xe_uc_fw_types.h b/drivers/gpu/drm/xe/xe_uc_fw_types.h
>> index 914026015019..77a1dcf8b4ed 100644
>> --- a/drivers/gpu/drm/xe/xe_uc_fw_types.h
>> +++ b/drivers/gpu/drm/xe/xe_uc_fw_types.h
>> @@ -147,6 +147,9 @@ struct xe_uc_fw {
>>
>> /** @private_data_size: size of private data found in uC css header */
>> u32 private_data_size;
>> +
>> + /** @build_type: Firmware build type (see CSS_UKERNEL_INFO_BUILDTYPE for definitions) */
>> + u32 build_type;
>> };
>>
>> #endif
More information about the Intel-xe
mailing list