All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Balasubrawmanian, Vivaik" <vivaik.balasubrawmanian@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	<intel-gfx@lists.freedesktop.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [Patch v1] drm/i915: Add uAPI to query micro-controller FW version
Date: Wed, 27 Sep 2023 21:46:56 -0700	[thread overview]
Message-ID: <de4ce324-eacd-09a8-6e2d-4a9d41a0683a@intel.com> (raw)
In-Reply-To: <c248c6b1-923d-2e19-9ee9-60445d822fa9@linux.intel.com>

On 9/27/2023 2:20 AM, Tvrtko Ursulin wrote:
>
> On 27/09/2023 05:14, Balasubrawmanian, Vivaik wrote:
>> Due to a bug in GuC firmware, Mesa can't enable by default the usage 
>> of compute engines in DG2 and newer.
>>
>>
>> A new GuC firmware fixed the issue but until now there was no way
>>
>> for Mesa to know if KMD was running with the fixed GuC version or not,
>>
>> so this uAPI is required.
>
> Is the firmware bug making the ccs engines generally useless, or just 
> not suitable for this specific Mesa use case?

My understanding is that this issue was found as part of this specific 
use case (enabling async compute queues on DG2).

We are adding the new uAPI to cover for similar situations in the 
future. Will clarify in the description above.

>
>> It may be expanded in future to query other firmware versions too.
>>
>> More information: 
>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23661
>>
>> Mesa usage: 
>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
>>
>>
>> Cc: John Harrison <John.C.Harrison@Intel.com>
>>
>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>
>> Cc: José Roberto de Souza <jose.souza@intel.com>
>>
>> Signed-off-by: Vivaik Balasubrawmanian 
>> <vivaik.balasubrawmanian@intel.com>
>> ---
>>   drivers/gpu/drm/i915/i915_query.c | 47 +++++++++++++++++++++++++++++++
>>   include/uapi/drm/i915_drm.h       | 32 +++++++++++++++++++++
>>   2 files changed, 79 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_query.c 
>> b/drivers/gpu/drm/i915/i915_query.c
>> index 00871ef99792..7f22a49faae7 100644
>> --- a/drivers/gpu/drm/i915/i915_query.c
>> +++ b/drivers/gpu/drm/i915/i915_query.c
>> @@ -551,6 +551,52 @@ static int query_hwconfig_blob(struct 
>> drm_i915_private *i915,
>>       return hwconfig->size;
>>   }
>>
>> +static int
>> +query_uc_fw_version(struct drm_i915_private *i915, struct 
>> drm_i915_query_item *query)
>> +{
>> +    struct drm_i915_query_uc_fw_version __user *query_ptr = 
>> u64_to_user_ptr(query->data_ptr);
>> +    size_t size = sizeof(struct drm_i915_query_uc_fw_version);
>> +    struct drm_i915_query_uc_fw_version resp;
>> +
>> +    if (query->length == 0) {
>> +        query->length = size;
>> +        return 0;
>> +    } else if (query->length != size) {
>> +        drm_dbg(&i915->drm,
>> +            "Invalid uc_fw_version query item size=%u expected=%zu\n",
>> +            query->length,    size);
>> +        return -EINVAL;
>> +    }
>> +
>> +    if (copy_from_user(&resp, query_ptr, size))
>> +        return -EFAULT;
>
> The above can probably be replaced by using the copy_query_item() 
> helper and it would work a bit better even since no reason to reject a 
> buffer too large.
>
Yes makes sense. Will send out an updated revision.
>> +
>> +    if (resp.pad || resp.pad2 || resp.reserved) {
>> +        drm_dbg(&i915->drm,
>> +            "Invalid input fw version query structure parameters 
>> received");
>> +        return -EINVAL;
>> +    }
>> +
>> +    switch (resp.uc_type) {
>> +    case I915_QUERY_UC_TYPE_GUC: {
>> +        struct intel_guc *guc = &i915->gt0.uc.guc;
>> +
>> +        resp.major_ver = guc->submission_version.major;
>> +        resp.minor_ver = guc->submission_version.minor;
>> +        resp.patch_ver = guc->submission_version.patch;
>
> Submission version is not the same as fw version, right? So 
> DRM_I915_QUERY_UC_FW_VERSION and uapi kerneldoc is misleading.
>
> Name the query type I915_QUERY_UC_TYPE_GUC*_SUBMISSION* and make it 
> clear?
>
> Regards,
>
> Tvrtko
I think this makes sense. The use case requires a read of submission 
version vs. the file version. Will update in the next revision.
>
>> +        resp.branch_ver = 0;
>> +        break;
>> +    }
>> +    default:
>> +        return -EINVAL;
>> +    }
>> +
>> +    if (copy_to_user(query_ptr, &resp, size))
>> +        return -EFAULT;
>> +
>> +    return 0;
>> +}
>> +
>>   static int (* const i915_query_funcs[])(struct drm_i915_private 
>> *dev_priv,
>>                       struct drm_i915_query_item *query_item) = {
>>       query_topology_info,
>> @@ -559,6 +605,7 @@ static int (* const i915_query_funcs[])(struct 
>> drm_i915_private *dev_priv,
>>       query_memregion_info,
>>       query_hwconfig_blob,
>>       query_geometry_subslices,
>> +    query_uc_fw_version,
>>   };
>>
>>   int i915_query_ioctl(struct drm_device *dev, void *data, struct 
>> drm_file *file)
>> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
>> index 7000e5910a1d..9be241fb77d8 100644
>> --- a/include/uapi/drm/i915_drm.h
>> +++ b/include/uapi/drm/i915_drm.h
>> @@ -3013,6 +3013,7 @@ struct drm_i915_query_item {
>>        *  - %DRM_I915_QUERY_MEMORY_REGIONS (see struct 
>> drm_i915_query_memory_regions)
>>        *  - %DRM_I915_QUERY_HWCONFIG_BLOB (see `GuC HWCONFIG blob uAPI`)
>>        *  - %DRM_I915_QUERY_GEOMETRY_SUBSLICES (see struct 
>> drm_i915_query_topology_info)
>> +     *  - %DRM_I915_QUERY_UC_FW_VERSION (see struct 
>> drm_i915_query_uc_fw_version)
>>        */
>>       __u64 query_id;
>>   #define DRM_I915_QUERY_TOPOLOGY_INFO        1
>> @@ -3021,6 +3022,7 @@ struct drm_i915_query_item {
>>   #define DRM_I915_QUERY_MEMORY_REGIONS        4
>>   #define DRM_I915_QUERY_HWCONFIG_BLOB        5
>>   #define DRM_I915_QUERY_GEOMETRY_SUBSLICES    6
>> +#define DRM_I915_QUERY_UC_FW_VERSION        7
>>   /* Must be kept compact -- no holes and well documented */
>>
>>       /**
>> @@ -3213,6 +3215,36 @@ struct drm_i915_query_topology_info {
>>       __u8 data[];
>>   };
>>
>> +/**
>> +* struct drm_i915_query_uc_fw_version - query a micro-controller 
>> firmware version
>> +*
>> +* Given a uc_type this will return the major, minor, patch and 
>> branch version
>> +* of the micro-controller firmware.
>> +*/
>> +struct drm_i915_query_uc_fw_version {
>> +    /** @uc: The micro-controller type to query firmware version */
>> +#define I915_QUERY_UC_TYPE_GUC 0
>> +    __u16 uc_type;
>> +
>> +    /** @pad: MBZ */
>> +    __u16 pad;
>> +
>> +    /* @major_ver: major uc fw version */
>> +    __u32 major_ver;
>> +    /* @minor_ver: minor uc fw version */
>> +    __u32 minor_ver;
>> +    /* @patch_ver: patch uc fw version */
>> +    __u32 patch_ver;
>> +    /* @branch_ver: branch uc fw version */
>> +    __u32 branch_ver;
>> +
>> +    /** @pad2: MBZ */
>> +    __u32 pad2;
>> +
>> +    /** @reserved: Reserved */
>> +    __u64 reserved;
>> +};
>> +
>>   /**
>>    * DOC: Engine Discovery uAPI
>>    *
>>
>> base-commit: a42554bf0755b80fdfb8e91ca35ae6835bb3534d

Thank you Tvrtko for the review and feedback. Deeply appreciated. - VB.


      reply	other threads:[~2023-09-28  4:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27  4:14 [Intel-gfx] [Patch v1] drm/i915: Add uAPI to query micro-controller FW version Balasubrawmanian, Vivaik
2023-09-27  4:14 ` Balasubrawmanian, Vivaik
2023-09-27  5:02 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for " Patchwork
2023-09-27  8:22 ` [Intel-gfx] [Patch v1] " Jani Nikula
2023-09-27  8:22   ` Jani Nikula
2023-09-27  9:20 ` [Intel-gfx] " Tvrtko Ursulin
2023-09-28  4:46   ` Balasubrawmanian, Vivaik [this message]

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=de4ce324-eacd-09a8-6e2d-4a9d41a0683a@intel.com \
    --to=vivaik.balasubrawmanian@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.