[v3,2/2] drm/i915/uapi: Add query for hwconfig table

Commit Message

John Harrison Jan. 19, 2022, 8:35 p.m. UTC

From: Rodrigo Vivi <[e-mail]>

GuC contains a consolidated table with a bunch of information about the
current device.

Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interested components can grab the
very latest and synchronized information using a simple query.

As per most of the other queries, this one can be called twice.
Once with item.length=0 to determine the exact buffer size, then
allocate the user memory and call it again for to retrieve the
table data. For example:
  struct drm_i915_query_item item = {
    .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
  };
  query.items_ptr = (int64_t) &item;
  query.num_items = 1;

  ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));

  if (item.length <= 0)
    return -ENOENT;

  data = malloc(item.length);
  item.data_ptr = (int64_t) &data;
  ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));

  // Parse the data as appropriate...

The returned array is a simple and flexible KLV (Key/Length/Value)
formatted table. For example, it could be just:
  enum device_attr {
     ATTR_SOME_VALUE = 0,
     ATTR_SOME_MASK  = 1,
  };

  static const u32 hwconfig[] = {
      ATTR_SOME_VALUE,
      1,             // Value Length in DWords
      8,             // Value

      ATTR_SOME_MASK,
      3,
      0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
  };

The attribute ids are defined in a hardware spec.

Cc: Tvrtko Ursulin <[e-mail]>
Cc: Kenneth Graunke <[e-mail]>
Cc: Michal Wajdeczko <[e-mail]>
Cc: Slawomir Milczarek <[e-mail]>
Signed-off-by: Rodrigo Vivi <[e-mail]>
Signed-off-by: John Harrison <[e-mail]>
Reviewed-by: Matthew Brost <[e-mail]>
---
 drivers/gpu/drm/i915/i915_query.c | 23 +++++++++++++++++++++++
 include/uapi/drm/i915_drm.h       |  1 +
 2 files changed, 24 insertions(+)

Comments

Jordan Justen Jan. 28, 2022, 12:48 a.m. UTC | #1

[e-mail] writes:

> From: Rodrigo Vivi <[e-mail]>
>
> GuC contains a consolidated table with a bunch of information about the
> current device.
>
> Previously, this information was spread and hardcoded to all the components
> including GuC, i915 and various UMDs. The goal here is to consolidate
> the data into GuC in a way that all interested components can grab the
> very latest and synchronized information using a simple query.

This "consolidate" goal is not what I was told for the purpose of this.
I don't think these paragraphs are the true.

> As per most of the other queries, this one can be called twice.
> Once with item.length=0 to determine the exact buffer size, then
> allocate the user memory and call it again for to retrieve the
> table data. For example:
>   struct drm_i915_query_item item = {
>     .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>   };
>   query.items_ptr = (int64_t) &item;
>   query.num_items = 1;
>
>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
>   if (item.length <= 0)
>     return -ENOENT;
>
>   data = malloc(item.length);
>   item.data_ptr = (int64_t) &data;
>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
>   // Parse the data as appropriate...
>
> The returned array is a simple and flexible KLV (Key/Length/Value)
> formatted table. For example, it could be just:
>   enum device_attr {
>      ATTR_SOME_VALUE = 0,
>      ATTR_SOME_MASK  = 1,
>   };
>
>   static const u32 hwconfig[] = {
>       ATTR_SOME_VALUE,
>       1,             // Value Length in DWords
>       8,             // Value
>
>       ATTR_SOME_MASK,
>       3,
>       0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>   };

You said on 03 Nov 2021 that you would remove the parts of this commit
message that document the format. Why? Because i915 will not make any
guarantees as to the format of what is returned. Thus, i915 should not
comment on the format.

Can you Cc me on future postings of this patch?

> The attribute ids are defined in a hardware spec.

As this spec is not published, it's hard to verify or refute this claim.

Think this is a more accurate commit message for this patch:

    In this interface i915 is returning a currently undocumented blob of
    data which it receives from the closed source guc software. The
    format of this blob *might* be defined in a hardware spec in the
    future.

I'm sure you will prefer to replace "might" with "is planned to". I
think "might" is more accurate, but I suppose the other would be
acceptable.

-Jordan

>
> Cc: Tvrtko Ursulin <[e-mail]>
> Cc: Kenneth Graunke <[e-mail]>
> Cc: Michal Wajdeczko <[e-mail]>
> Cc: Slawomir Milczarek <[e-mail]>
> Signed-off-by: Rodrigo Vivi <[e-mail]>
> Signed-off-by: John Harrison <[e-mail]>
> Reviewed-by: Matthew Brost <[e-mail]>
> ---
>  drivers/gpu/drm/i915/i915_query.c | 23 +++++++++++++++++++++++
>  include/uapi/drm/i915_drm.h       |  1 +
>  2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
> index 2dfbc22857a3..609e64d5f395 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -479,12 +479,35 @@ static int query_memregion_info(struct drm_i915_private *i915,
>  	return total_length;
>  }
>  
> +static int query_hwconfig_table(struct drm_i915_private *i915,
> +				struct drm_i915_query_item *query_item)
> +{
> +	struct intel_gt *gt = to_gt(i915);
> +	struct intel_guc_hwconfig *hwconfig = &gt->uc.guc.hwconfig;
> +
> +	if (!hwconfig->size || !hwconfig->ptr)
> +		return -ENODEV;
> +
> +	if (query_item->length == 0)
> +		return hwconfig->size;
> +
> +	if (query_item->length < hwconfig->size)
> +		return -EINVAL;
> +
> +	if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
> +			 hwconfig->ptr, hwconfig->size))
> +		return -EFAULT;
> +
> +	return hwconfig->size;
> +}
> +
>  static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
>  					struct drm_i915_query_item *query_item) = {
>  	query_topology_info,
>  	query_engine_info,
>  	query_perf_config,
>  	query_memregion_info,
> +	query_hwconfig_table,
>  };
>  
>  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 914ebd9290e5..132515199f27 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -2685,6 +2685,7 @@ struct drm_i915_query_item {
>  #define DRM_I915_QUERY_ENGINE_INFO	2
>  #define DRM_I915_QUERY_PERF_CONFIG      3
>  #define DRM_I915_QUERY_MEMORY_REGIONS   4
> +#define DRM_I915_QUERY_HWCONFIG_TABLE   5
>  /* Must be kept compact -- no holes and well documented */
>  
>  	/**
> -- 
> 2.25.1

John Harrison Jan. 28, 2022, 1:17 a.m. UTC | #2

On 1/27/2022 16:48, Jordan Justen wrote:
> [e-mail] writes:
>
>> From: Rodrigo Vivi <[e-mail]>
>>
>> GuC contains a consolidated table with a bunch of information about the
>> current device.
>>
>> Previously, this information was spread and hardcoded to all the components
>> including GuC, i915 and various UMDs. The goal here is to consolidate
>> the data into GuC in a way that all interested components can grab the
>> very latest and synchronized information using a simple query.
> This "consolidate" goal is not what I was told for the purpose of this.
> I don't think these paragraphs are the true.
The intention is to remove multiple hardcoded tables spread across a 
bunch of different drivers and replace them with a single table 
retrieved from the hardware itself. That sounds like consolidation to me.

>
>> As per most of the other queries, this one can be called twice.
>> Once with item.length=0 to determine the exact buffer size, then
>> allocate the user memory and call it again for to retrieve the
>> table data. For example:
>>    struct drm_i915_query_item item = {
>>      .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>    };
>>    query.items_ptr = (int64_t) &item;
>>    query.num_items = 1;
>>
>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>>    if (item.length <= 0)
>>      return -ENOENT;
>>
>>    data = malloc(item.length);
>>    item.data_ptr = (int64_t) &data;
>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>>    // Parse the data as appropriate...
>>
>> The returned array is a simple and flexible KLV (Key/Length/Value)
>> formatted table. For example, it could be just:
>>    enum device_attr {
>>       ATTR_SOME_VALUE = 0,
>>       ATTR_SOME_MASK  = 1,
>>    };
>>
>>    static const u32 hwconfig[] = {
>>        ATTR_SOME_VALUE,
>>        1,             // Value Length in DWords
>>        8,             // Value
>>
>>        ATTR_SOME_MASK,
>>        3,
>>        0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>    };
> You said on 03 Nov 2021 that you would remove the parts of this commit
> message that document the format. Why? Because i915 will not make any
> guarantees as to the format of what is returned. Thus, i915 should not
> comment on the format.
And you replied that you would prefer to keep it.

>
> Can you Cc me on future postings of this patch?
>
>> The attribute ids are defined in a hardware spec.
> As this spec is not published, it's hard to verify or refute this claim.
>
> Think this is a more accurate commit message for this patch:
>
>      In this interface i915 is returning a currently undocumented blob of
>      data which it receives from the closed source guc software. The
>      format of this blob *might* be defined in a hardware spec in the
>      future.
>
> I'm sure you will prefer to replace "might" with "is planned to". I
> think "might" is more accurate, but I suppose the other would be
> acceptable.
>
> -Jordan
Getting brand new spec documents published is not a fast process. That 
doesn't mean it isn't going to happen. Also, just because a document is 
currently confidential and private doesn't mean that it doesn't exist.

John.


>
>> Cc: Tvrtko Ursulin <[e-mail]>
>> Cc: Kenneth Graunke <[e-mail]>
>> Cc: Michal Wajdeczko <[e-mail]>
>> Cc: Slawomir Milczarek <[e-mail]>
>> Signed-off-by: Rodrigo Vivi <[e-mail]>
>> Signed-off-by: John Harrison <[e-mail]>
>> Reviewed-by: Matthew Brost <[e-mail]>
>> ---
>>   drivers/gpu/drm/i915/i915_query.c | 23 +++++++++++++++++++++++
>>   include/uapi/drm/i915_drm.h       |  1 +
>>   2 files changed, 24 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
>> index 2dfbc22857a3..609e64d5f395 100644
>> --- a/drivers/gpu/drm/i915/i915_query.c
>> +++ b/drivers/gpu/drm/i915/i915_query.c
>> @@ -479,12 +479,35 @@ static int query_memregion_info(struct drm_i915_private *i915,
>>   	return total_length;
>>   }
>>   
>> +static int query_hwconfig_table(struct drm_i915_private *i915,
>> +				struct drm_i915_query_item *query_item)
>> +{
>> +	struct intel_gt *gt = to_gt(i915);
>> +	struct intel_guc_hwconfig *hwconfig = &gt->uc.guc.hwconfig;
>> +
>> +	if (!hwconfig->size || !hwconfig->ptr)
>> +		return -ENODEV;
>> +
>> +	if (query_item->length == 0)
>> +		return hwconfig->size;
>> +
>> +	if (query_item->length < hwconfig->size)
>> +		return -EINVAL;
>> +
>> +	if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
>> +			 hwconfig->ptr, hwconfig->size))
>> +		return -EFAULT;
>> +
>> +	return hwconfig->size;
>> +}
>> +
>>   static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
>>   					struct drm_i915_query_item *query_item) = {
>>   	query_topology_info,
>>   	query_engine_info,
>>   	query_perf_config,
>>   	query_memregion_info,
>> +	query_hwconfig_table,
>>   };
>>   
>>   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 914ebd9290e5..132515199f27 100644
>> --- a/include/uapi/drm/i915_drm.h
>> +++ b/include/uapi/drm/i915_drm.h
>> @@ -2685,6 +2685,7 @@ struct drm_i915_query_item {
>>   #define DRM_I915_QUERY_ENGINE_INFO	2
>>   #define DRM_I915_QUERY_PERF_CONFIG      3
>>   #define DRM_I915_QUERY_MEMORY_REGIONS   4
>> +#define DRM_I915_QUERY_HWCONFIG_TABLE   5
>>   /* Must be kept compact -- no holes and well documented */
>>   
>>   	/**
>> -- 
>> 2.25.1

Jordan Justen Jan. 28, 2022, 2:41 a.m. UTC | #3

John Harrison <[e-mail]> writes:

> On 1/27/2022 16:48, Jordan Justen wrote:
>> [e-mail] writes:
>>
>>> From: Rodrigo Vivi <[e-mail]>
>>>
>>> GuC contains a consolidated table with a bunch of information about the
>>> current device.
>>>
>>> Previously, this information was spread and hardcoded to all the components
>>> including GuC, i915 and various UMDs. The goal here is to consolidate
>>> the data into GuC in a way that all interested components can grab the
>>> very latest and synchronized information using a simple query.
>> This "consolidate" goal is not what I was told for the purpose of this.
>> I don't think these paragraphs are the true.
> The intention is to remove multiple hardcoded tables spread across a 
> bunch of different drivers and replace them with a single table 
> retrieved from the hardware itself. That sounds like consolidation to me.

That is not what I was told. That is apparently what someone is trying
to sell here.

Mesa would prefer to "hardcode" info rather than depend on the closed
source guc software.

>>
>>> As per most of the other queries, this one can be called twice.
>>> Once with item.length=0 to determine the exact buffer size, then
>>> allocate the user memory and call it again for to retrieve the
>>> table data. For example:
>>>    struct drm_i915_query_item item = {
>>>      .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>>    };
>>>    query.items_ptr = (int64_t) &item;
>>>    query.num_items = 1;
>>>
>>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>
>>>    if (item.length <= 0)
>>>      return -ENOENT;
>>>
>>>    data = malloc(item.length);
>>>    item.data_ptr = (int64_t) &data;
>>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>>
>>>    // Parse the data as appropriate...
>>>
>>> The returned array is a simple and flexible KLV (Key/Length/Value)
>>> formatted table. For example, it could be just:
>>>    enum device_attr {
>>>       ATTR_SOME_VALUE = 0,
>>>       ATTR_SOME_MASK  = 1,
>>>    };
>>>
>>>    static const u32 hwconfig[] = {
>>>        ATTR_SOME_VALUE,
>>>        1,             // Value Length in DWords
>>>        8,             // Value
>>>
>>>        ATTR_SOME_MASK,
>>>        3,
>>>        0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>>    };
>> You said on 03 Nov 2021 that you would remove the parts of this commit
>> message that document the format. Why? Because i915 will not make any
>> guarantees as to the format of what is returned. Thus, i915 should not
>> comment on the format.
> And you replied that you would prefer to keep it.

No, I did not.

You said, "Sure. Can remove comments." to which, I replied, "Obviously
not what should be done, but apparently all i915 is willing to do."

So, i915 should document and stand behind this blob's format. But, if
they are not willing to, they shouldn't half-heartedly put some text in
a commit message.

>>
>> Can you Cc me on future postings of this patch?
>>
>>> The attribute ids are defined in a hardware spec.
>> As this spec is not published, it's hard to verify or refute this claim.
>>
>> Think this is a more accurate commit message for this patch:
>>
>>      In this interface i915 is returning a currently undocumented blob of
>>      data which it receives from the closed source guc software. The
>>      format of this blob *might* be defined in a hardware spec in the
>>      future.
>>
>> I'm sure you will prefer to replace "might" with "is planned to". I
>> think "might" is more accurate, but I suppose the other would be
>> acceptable.
>>
>> -Jordan
> Getting brand new spec documents published is not a fast process.

Heh.

Have you learned anything new about the status of it in the past 3
months?

> That doesn't mean it isn't going to happen.

It also doesn't mean it is going to happen either. Maybe you want to add
some text wherein Intel guarantees that it will be released in a spec by
some date?

> Also, just because a document is currently confidential and private
> doesn't mean that it doesn't exist.

Should we add "This is documented in a private spec, so it really does
exist!"?

-Jordan

Jordan Justen Jan. 30, 2022, 11:22 p.m. UTC | #4

John, Rodrigo,

It is now clear to me just how dependent i915 is going to be on the
closed source guc software, and that's just a fact of life for our
graphics stack going forward.

In that context, it seems kind of pointless for me to make a big deal
out of this peripheral "query item" commit message. I still think
something as simple and to the point as:

"In this interface i915 is returning a blob of data which it receives
from the guc software. This blob provides some useful data about the
hardware for drivers. The format of this blob will be documented in the
Programmer Reference Manuals when released."

... would be better, but obviously this is really just down in the noise
in terms of concerns about the greater issue. So, feel free (to
continue) to ignore my suggestion.

Sorry for having wasted your time,

-Jordan

[e-mail] writes:

> From: Rodrigo Vivi <[e-mail]>
>
> GuC contains a consolidated table with a bunch of information about the
> current device.
>
> Previously, this information was spread and hardcoded to all the components
> including GuC, i915 and various UMDs. The goal here is to consolidate
> the data into GuC in a way that all interested components can grab the
> very latest and synchronized information using a simple query.
>
> As per most of the other queries, this one can be called twice.
> Once with item.length=0 to determine the exact buffer size, then
> allocate the user memory and call it again for to retrieve the
> table data. For example:
>   struct drm_i915_query_item item = {
>     .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>   };
>   query.items_ptr = (int64_t) &item;
>   query.num_items = 1;
>
>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
>   if (item.length <= 0)
>     return -ENOENT;
>
>   data = malloc(item.length);
>   item.data_ptr = (int64_t) &data;
>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
>   // Parse the data as appropriate...
>
> The returned array is a simple and flexible KLV (Key/Length/Value)
> formatted table. For example, it could be just:
>   enum device_attr {
>      ATTR_SOME_VALUE = 0,
>      ATTR_SOME_MASK  = 1,
>   };
>
>   static const u32 hwconfig[] = {
>       ATTR_SOME_VALUE,
>       1,             // Value Length in DWords
>       8,             // Value
>
>       ATTR_SOME_MASK,
>       3,
>       0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>   };
>
> The attribute ids are defined in a hardware spec.
>
> Cc: Tvrtko Ursulin <[e-mail]>
> Cc: Kenneth Graunke <[e-mail]>
> Cc: Michal Wajdeczko <[e-mail]>
> Cc: Slawomir Milczarek <[e-mail]>
> Signed-off-by: Rodrigo Vivi <[e-mail]>
> Signed-off-by: John Harrison <[e-mail]>
> Reviewed-by: Matthew Brost <[e-mail]>
> ---
>  drivers/gpu/drm/i915/i915_query.c | 23 +++++++++++++++++++++++
>  include/uapi/drm/i915_drm.h       |  1 +
>  2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
> index 2dfbc22857a3..609e64d5f395 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -479,12 +479,35 @@ static int query_memregion_info(struct drm_i915_private *i915,
>  	return total_length;
>  }
>  
> +static int query_hwconfig_table(struct drm_i915_private *i915,
> +				struct drm_i915_query_item *query_item)
> +{
> +	struct intel_gt *gt = to_gt(i915);
> +	struct intel_guc_hwconfig *hwconfig = &gt->uc.guc.hwconfig;
> +
> +	if (!hwconfig->size || !hwconfig->ptr)
> +		return -ENODEV;
> +
> +	if (query_item->length == 0)
> +		return hwconfig->size;
> +
> +	if (query_item->length < hwconfig->size)
> +		return -EINVAL;
> +
> +	if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
> +			 hwconfig->ptr, hwconfig->size))
> +		return -EFAULT;
> +
> +	return hwconfig->size;
> +}
> +
>  static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
>  					struct drm_i915_query_item *query_item) = {
>  	query_topology_info,
>  	query_engine_info,
>  	query_perf_config,
>  	query_memregion_info,
> +	query_hwconfig_table,
>  };
>  
>  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 914ebd9290e5..132515199f27 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -2685,6 +2685,7 @@ struct drm_i915_query_item {
>  #define DRM_I915_QUERY_ENGINE_INFO	2
>  #define DRM_I915_QUERY_PERF_CONFIG      3
>  #define DRM_I915_QUERY_MEMORY_REGIONS   4
> +#define DRM_I915_QUERY_HWCONFIG_TABLE   5
>  /* Must be kept compact -- no holes and well documented */
>  
>  	/**
> -- 
> 2.25.1

Jordan Justen Feb. 3, 2022, 11:19 p.m. UTC | #5

Jordan Justen <[e-mail]> writes:

> John, Rodrigo,
>
> It is now clear to me just how dependent i915 is going to be on the
> closed source guc software, and that's just a fact of life for our
> graphics stack going forward.
>
> In that context, it seems kind of pointless for me to make a big deal
> out of this peripheral "query item" commit message. I still think
> something as simple and to the point as:
>
> "In this interface i915 is returning a blob of data which it receives
> from the guc software. This blob provides some useful data about the
> hardware for drivers. The format of this blob will be documented in the
> Programmer Reference Manuals when released."

As I said on the internal email thread, *if you use my commit message
suggestion*, then, begrudgingly, you can add my:

Acked-by: Jordan Justen <[e-mail]>

to the patch.

Regardless of the commit message, I think you can add:

Tested-by: Jordan Justen <[e-mail]>

In truth, I've only tested this via the "prelim" i915 Linux uapi fork on
an internal kernel tree, but I think that probably is close enough.

In case you find it helpful, maybe:

Ref: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14511

-Jordan

>
> ... would be better, but obviously this is really just down in the noise
> in terms of concerns about the greater issue. So, feel free (to
> continue) to ignore my suggestion.
>
> Sorry for having wasted your time,
>
> -Jordan
>
> [e-mail] writes:
>
>> From: Rodrigo Vivi <[e-mail]>
>>
>> GuC contains a consolidated table with a bunch of information about the
>> current device.
>>
>> Previously, this information was spread and hardcoded to all the components
>> including GuC, i915 and various UMDs. The goal here is to consolidate
>> the data into GuC in a way that all interested components can grab the
>> very latest and synchronized information using a simple query.
>>
>> As per most of the other queries, this one can be called twice.
>> Once with item.length=0 to determine the exact buffer size, then
>> allocate the user memory and call it again for to retrieve the
>> table data. For example:
>>   struct drm_i915_query_item item = {
>>     .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>   };
>>   query.items_ptr = (int64_t) &item;
>>   query.num_items = 1;
>>
>>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>>   if (item.length <= 0)
>>     return -ENOENT;
>>
>>   data = malloc(item.length);
>>   item.data_ptr = (int64_t) &data;
>>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>>   // Parse the data as appropriate...
>>
>> The returned array is a simple and flexible KLV (Key/Length/Value)
>> formatted table. For example, it could be just:
>>   enum device_attr {
>>      ATTR_SOME_VALUE = 0,
>>      ATTR_SOME_MASK  = 1,
>>   };
>>
>>   static const u32 hwconfig[] = {
>>       ATTR_SOME_VALUE,
>>       1,             // Value Length in DWords
>>       8,             // Value
>>
>>       ATTR_SOME_MASK,
>>       3,
>>       0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>   };
>>
>> The attribute ids are defined in a hardware spec.
>>
>> Cc: Tvrtko Ursulin <[e-mail]>
>> Cc: Kenneth Graunke <[e-mail]>
>> Cc: Michal Wajdeczko <[e-mail]>
>> Cc: Slawomir Milczarek <[e-mail]>
>> Signed-off-by: Rodrigo Vivi <[e-mail]>
>> Signed-off-by: John Harrison <[e-mail]>
>> Reviewed-by: Matthew Brost <[e-mail]>
>> ---
>>  drivers/gpu/drm/i915/i915_query.c | 23 +++++++++++++++++++++++
>>  include/uapi/drm/i915_drm.h       |  1 +
>>  2 files changed, 24 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
>> index 2dfbc22857a3..609e64d5f395 100644
>> --- a/drivers/gpu/drm/i915/i915_query.c
>> +++ b/drivers/gpu/drm/i915/i915_query.c
>> @@ -479,12 +479,35 @@ static int query_memregion_info(struct drm_i915_private *i915,
>>  	return total_length;
>>  }
>>  
>> +static int query_hwconfig_table(struct drm_i915_private *i915,
>> +				struct drm_i915_query_item *query_item)
>> +{
>> +	struct intel_gt *gt = to_gt(i915);
>> +	struct intel_guc_hwconfig *hwconfig = &gt->uc.guc.hwconfig;
>> +
>> +	if (!hwconfig->size || !hwconfig->ptr)
>> +		return -ENODEV;
>> +
>> +	if (query_item->length == 0)
>> +		return hwconfig->size;
>> +
>> +	if (query_item->length < hwconfig->size)
>> +		return -EINVAL;
>> +
>> +	if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
>> +			 hwconfig->ptr, hwconfig->size))
>> +		return -EFAULT;
>> +
>> +	return hwconfig->size;
>> +}
>> +
>>  static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
>>  					struct drm_i915_query_item *query_item) = {
>>  	query_topology_info,
>>  	query_engine_info,
>>  	query_perf_config,
>>  	query_memregion_info,
>> +	query_hwconfig_table,
>>  };
>>  
>>  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 914ebd9290e5..132515199f27 100644
>> --- a/include/uapi/drm/i915_drm.h
>> +++ b/include/uapi/drm/i915_drm.h
>> @@ -2685,6 +2685,7 @@ struct drm_i915_query_item {
>>  #define DRM_I915_QUERY_ENGINE_INFO	2
>>  #define DRM_I915_QUERY_PERF_CONFIG      3
>>  #define DRM_I915_QUERY_MEMORY_REGIONS   4
>> +#define DRM_I915_QUERY_HWCONFIG_TABLE   5
>>  /* Must be kept compact -- no holes and well documented */
>>  
>>  	/**
>> -- 
>> 2.25.1

Daniel Vetter Feb. 4, 2022, 9:55 a.m. UTC | #6

On Wed, Jan 19, 2022 at 9:35 PM <[e-mail]> wrote:
>
> From: Rodrigo Vivi <[e-mail]>
>
> GuC contains a consolidated table with a bunch of information about the
> current device.
>
> Previously, this information was spread and hardcoded to all the components
> including GuC, i915 and various UMDs. The goal here is to consolidate
> the data into GuC in a way that all interested components can grab the
> very latest and synchronized information using a simple query.
>
> As per most of the other queries, this one can be called twice.
> Once with item.length=0 to determine the exact buffer size, then
> allocate the user memory and call it again for to retrieve the
> table data. For example:
>   struct drm_i915_query_item item = {
>     .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>   };
>   query.items_ptr = (int64_t) &item;
>   query.num_items = 1;
>
>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
>   if (item.length <= 0)
>     return -ENOENT;
>
>   data = malloc(item.length);
>   item.data_ptr = (int64_t) &data;
>   ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>
>   // Parse the data as appropriate...
>
> The returned array is a simple and flexible KLV (Key/Length/Value)
> formatted table. For example, it could be just:
>   enum device_attr {
>      ATTR_SOME_VALUE = 0,
>      ATTR_SOME_MASK  = 1,
>   };
>
>   static const u32 hwconfig[] = {
>       ATTR_SOME_VALUE,
>       1,             // Value Length in DWords
>       8,             // Value
>
>       ATTR_SOME_MASK,
>       3,
>       0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>   };
>
> The attribute ids are defined in a hardware spec.
>
> Cc: Tvrtko Ursulin <[e-mail]>
> Cc: Kenneth Graunke <[e-mail]>
> Cc: Michal Wajdeczko <[e-mail]>
> Cc: Slawomir Milczarek <[e-mail]>
> Signed-off-by: Rodrigo Vivi <[e-mail]>
> Signed-off-by: John Harrison <[e-mail]>
> Reviewed-by: Matthew Brost <[e-mail]>
> ---
>  drivers/gpu/drm/i915/i915_query.c | 23 +++++++++++++++++++++++
>  include/uapi/drm/i915_drm.h       |  1 +
>  2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
> index 2dfbc22857a3..609e64d5f395 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -479,12 +479,35 @@ static int query_memregion_info(struct drm_i915_private *i915,
>         return total_length;
>  }
>
> +static int query_hwconfig_table(struct drm_i915_private *i915,
> +                               struct drm_i915_query_item *query_item)
> +{
> +       struct intel_gt *gt = to_gt(i915);
> +       struct intel_guc_hwconfig *hwconfig = &gt->uc.guc.hwconfig;
> +
> +       if (!hwconfig->size || !hwconfig->ptr)
> +               return -ENODEV;
> +
> +       if (query_item->length == 0)
> +               return hwconfig->size;
> +
> +       if (query_item->length < hwconfig->size)
> +               return -EINVAL;
> +
> +       if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
> +                        hwconfig->ptr, hwconfig->size))
> +               return -EFAULT;
> +
> +       return hwconfig->size;
> +}
> +
>  static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
>                                         struct drm_i915_query_item *query_item) = {
>         query_topology_info,
>         query_engine_info,
>         query_perf_config,
>         query_memregion_info,
> +       query_hwconfig_table,
>  };
>
>  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 914ebd9290e5..132515199f27 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -2685,6 +2685,7 @@ struct drm_i915_query_item {
>  #define DRM_I915_QUERY_ENGINE_INFO     2
>  #define DRM_I915_QUERY_PERF_CONFIG      3
>  #define DRM_I915_QUERY_MEMORY_REGIONS   4
> +#define DRM_I915_QUERY_HWCONFIG_TABLE   5
>  /* Must be kept compact -- no holes and well documented */

New uapi needs kerneldoc in the uapi header, and please fill in any
gaps you have (i.e. if the query uapi this is built on top of isn't
fully documented yet).

Also this holds across the board, so please keep in mind in patch review.
-Daniel

John Harrison Feb. 4, 2022, 7:03 p.m. UTC | #7

On 2/4/2022 01:55, Daniel Vetter wrote:
> On Wed, Jan 19, 2022 at 9:35 PM <[e-mail]> wrote:
>> From: Rodrigo Vivi <[e-mail]>
>>
>> GuC contains a consolidated table with a bunch of information about the
>> current device.
>>
>> Previously, this information was spread and hardcoded to all the components
>> including GuC, i915 and various UMDs. The goal here is to consolidate
>> the data into GuC in a way that all interested components can grab the
>> very latest and synchronized information using a simple query.
>>
>> As per most of the other queries, this one can be called twice.
>> Once with item.length=0 to determine the exact buffer size, then
>> allocate the user memory and call it again for to retrieve the
>> table data. For example:
>>    struct drm_i915_query_item item = {
>>      .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>>    };
>>    query.items_ptr = (int64_t) &item;
>>    query.num_items = 1;
>>
>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>>    if (item.length <= 0)
>>      return -ENOENT;
>>
>>    data = malloc(item.length);
>>    item.data_ptr = (int64_t) &data;
>>    ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>>    // Parse the data as appropriate...
>>
>> The returned array is a simple and flexible KLV (Key/Length/Value)
>> formatted table. For example, it could be just:
>>    enum device_attr {
>>       ATTR_SOME_VALUE = 0,
>>       ATTR_SOME_MASK  = 1,
>>    };
>>
>>    static const u32 hwconfig[] = {
>>        ATTR_SOME_VALUE,
>>        1,             // Value Length in DWords
>>        8,             // Value
>>
>>        ATTR_SOME_MASK,
>>        3,
>>        0x00FFFFFFFF, 0xFFFFFFFF, 0xFF000000,
>>    };
>>
>> The attribute ids are defined in a hardware spec.
>>
>> Cc: Tvrtko Ursulin <[e-mail]>
>> Cc: Kenneth Graunke <[e-mail]>
>> Cc: Michal Wajdeczko <[e-mail]>
>> Cc: Slawomir Milczarek <[e-mail]>
>> Signed-off-by: Rodrigo Vivi <[e-mail]>
>> Signed-off-by: John Harrison <[e-mail]>
>> Reviewed-by: Matthew Brost <[e-mail]>
>> ---
>>   drivers/gpu/drm/i915/i915_query.c | 23 +++++++++++++++++++++++
>>   include/uapi/drm/i915_drm.h       |  1 +
>>   2 files changed, 24 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
>> index 2dfbc22857a3..609e64d5f395 100644
>> --- a/drivers/gpu/drm/i915/i915_query.c
>> +++ b/drivers/gpu/drm/i915/i915_query.c
>> @@ -479,12 +479,35 @@ static int query_memregion_info(struct drm_i915_private *i915,
>>          return total_length;
>>   }
>>
>> +static int query_hwconfig_table(struct drm_i915_private *i915,
>> +                               struct drm_i915_query_item *query_item)
>> +{
>> +       struct intel_gt *gt = to_gt(i915);
>> +       struct intel_guc_hwconfig *hwconfig = &gt->uc.guc.hwconfig;
>> +
>> +       if (!hwconfig->size || !hwconfig->ptr)
>> +               return -ENODEV;
>> +
>> +       if (query_item->length == 0)
>> +               return hwconfig->size;
>> +
>> +       if (query_item->length < hwconfig->size)
>> +               return -EINVAL;
>> +
>> +       if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
>> +                        hwconfig->ptr, hwconfig->size))
>> +               return -EFAULT;
>> +
>> +       return hwconfig->size;
>> +}
>> +
>>   static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
>>                                          struct drm_i915_query_item *query_item) = {
>>          query_topology_info,
>>          query_engine_info,
>>          query_perf_config,
>>          query_memregion_info,
>> +       query_hwconfig_table,
>>   };
>>
>>   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 914ebd9290e5..132515199f27 100644
>> --- a/include/uapi/drm/i915_drm.h
>> +++ b/include/uapi/drm/i915_drm.h
>> @@ -2685,6 +2685,7 @@ struct drm_i915_query_item {
>>   #define DRM_I915_QUERY_ENGINE_INFO     2
>>   #define DRM_I915_QUERY_PERF_CONFIG      3
>>   #define DRM_I915_QUERY_MEMORY_REGIONS   4
>> +#define DRM_I915_QUERY_HWCONFIG_TABLE   5
>>   /* Must be kept compact -- no holes and well documented */
> New uapi needs kerneldoc in the uapi header, and please fill in any
> gaps you have (i.e. if the query uapi this is built on top of isn't
> fully documented yet).
>
> Also this holds across the board, so please keep in mind in patch review.
> -Daniel
There is no extra documentation to add.

The query interface itself is already documented. This new query does 
not have any kernel defined data structures associated with it. There is 
just 'struct drm_i915_query_item' with a length and a pointer, all of 
which are fully documented.

John.

Patch

diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c
index 2dfbc22857a3..609e64d5f395 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -479,12 +479,35 @@  static int query_memregion_info(struct drm_i915_private *i915,
 	return total_length;
 }
 
+static int query_hwconfig_table(struct drm_i915_private *i915,
+				struct drm_i915_query_item *query_item)
+{
+	struct intel_gt *gt = to_gt(i915);
+	struct intel_guc_hwconfig *hwconfig = &gt->uc.guc.hwconfig;
+
+	if (!hwconfig->size || !hwconfig->ptr)
+		return -ENODEV;
+
+	if (query_item->length == 0)
+		return hwconfig->size;
+
+	if (query_item->length < hwconfig->size)
+		return -EINVAL;
+
+	if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+			 hwconfig->ptr, hwconfig->size))
+		return -EFAULT;
+
+	return hwconfig->size;
+}
+
 static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
 					struct drm_i915_query_item *query_item) = {
 	query_topology_info,
 	query_engine_info,
 	query_perf_config,
 	query_memregion_info,
+	query_hwconfig_table,
 };
 
 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 914ebd9290e5..132515199f27 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2685,6 +2685,7 @@  struct drm_i915_query_item {
 #define DRM_I915_QUERY_ENGINE_INFO	2
 #define DRM_I915_QUERY_PERF_CONFIG      3
 #define DRM_I915_QUERY_MEMORY_REGIONS   4
+#define DRM_I915_QUERY_HWCONFIG_TABLE   5
 /* Must be kept compact -- no holes and well documented */
 
 	/**