All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jordan Justen <jordan.l.justen@intel.com>
To: John.C.Harrison@Intel.com, Intel-GFX@Lists.FreeDesktop.Org
Cc: Matthew Brost <matthew.brost@intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Kenneth Graunke <kenneth.w.graunke@intel.com>,
	DRI-Devel@Lists.FreeDesktop.Org,
	Slawomir Milczarek <slawomir.milczarek@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	John Harrison <John.C.Harrison@Intel.com>,
	Michal Wajdeczko <michal.wajdeczko@intel.com>
Subject: Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table
Date: Mon, 01 Nov 2021 08:39:14 -0700	[thread overview]
Message-ID: <877ddr51i5.fsf@jljusten-skl> (raw)
In-Reply-To: <20210916184012.2642295-3-John.C.Harrison@Intel.com>

<John.C.Harrison@Intel.com> writes:

> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> 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,
>   };

Seems simple enough, so why doesn't i915 define the format of the
returned hwconfig blob in i915_drm.h?

struct drm_i915_hwconfig {
	uint32_t key;
	uint32_t length;
	uint32_t values[];
};

It sounds like the kernel depends on the closed source guc being loaded
to return this information. Is that right? Will i915 also become
dependent on some of this data such that it won't be able to initialize
without the firmware being loaded?

> The attribute ids are defined in a hardware spec.

Which spec?

-Jordan

WARNING: multiple messages have this Message-ID (diff)
From: Jordan Justen <jordan.l.justen@intel.com>
To: John.C.Harrison@Intel.com, Intel-GFX@Lists.FreeDesktop.Org
Cc: Kenneth Graunke <kenneth.w.graunke@intel.com>,
	DRI-Devel@Lists.FreeDesktop.Org,
	Slawomir Milczarek <slawomir.milczarek@intel.com>
Subject: Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/uapi: Add query for hwconfig table
Date: Mon, 01 Nov 2021 08:39:14 -0700	[thread overview]
Message-ID: <877ddr51i5.fsf@jljusten-skl> (raw)
In-Reply-To: <20210916184012.2642295-3-John.C.Harrison@Intel.com>

<John.C.Harrison@Intel.com> writes:

> From: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> 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,
>   };

Seems simple enough, so why doesn't i915 define the format of the
returned hwconfig blob in i915_drm.h?

struct drm_i915_hwconfig {
	uint32_t key;
	uint32_t length;
	uint32_t values[];
};

It sounds like the kernel depends on the closed source guc being loaded
to return this information. Is that right? Will i915 also become
dependent on some of this data such that it won't be able to initialize
without the firmware being loaded?

> The attribute ids are defined in a hardware spec.

Which spec?

-Jordan

  reply	other threads:[~2021-11-01 15:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16 18:40 [PATCH v2 0/2] Add support for querying hw info that UMDs need John.C.Harrison
2021-09-16 18:40 ` [Intel-gfx] " John.C.Harrison
2021-09-16 18:40 ` [PATCH v2 1/2] drm/i915/guc: Add fetch of hwconfig table John.C.Harrison
2021-09-16 18:40   ` [Intel-gfx] " John.C.Harrison
2021-09-16 18:40 ` [PATCH v2 2/2] drm/i915/uapi: Add query for " John.C.Harrison
2021-09-16 18:40   ` [Intel-gfx] " John.C.Harrison
2021-11-01 15:39   ` Jordan Justen [this message]
2021-11-01 15:39     ` Jordan Justen
2021-11-03  0:05     ` John Harrison
2021-11-03  0:05       ` John Harrison
2021-11-03 21:38       ` Jordan Justen
2021-11-03 21:38         ` Jordan Justen
2021-11-03 23:49         ` John Harrison
2021-11-03 23:49           ` John Harrison
2021-11-04  8:43           ` Jordan Justen
2021-11-04  8:43             ` Jordan Justen
2021-11-04  9:38           ` Lionel Landwerlin
2021-09-16 23:30 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add support for querying hw info that UMDs need Patchwork
2021-09-16 23:57 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-09-17  3:51 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=877ddr51i5.fsf@jljusten-skl \
    --to=jordan.l.justen@intel.com \
    --cc=DRI-Devel@Lists.FreeDesktop.Org \
    --cc=Intel-GFX@Lists.FreeDesktop.Org \
    --cc=John.C.Harrison@Intel.com \
    --cc=kenneth.w.graunke@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=slawomir.milczarek@intel.com \
    --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.