From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Souza, Jose" <jose.souza@intel.com>
Cc: "Dugast, Francois" <francois.dugast@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-xe] [PATCH v1 6/8] drm/xe/uapi: Align on a common way to return arrays (gt)
Date: Thu, 16 Nov 2023 15:56:29 -0500 [thread overview]
Message-ID: <ZVaB/d2fR0GBje3T@intel.com> (raw)
In-Reply-To: <b53c6f92cafa55a32d2315dfabc4698b6cea17ac.camel@intel.com>
On Thu, Nov 16, 2023 at 08:40:26PM +0000, Souza, Jose wrote:
> On Thu, 2023-11-16 at 14:43 +0000, Francois Dugast wrote:
> > The uAPI provides queries which return arrays of elements. As of now
> > the format used in the struct is different depending on which element
> > is queried. Fix this for gt by applying the pattern below:
> >
> > struct drm_xe_query_X {
> > __u32 num_X;
> > struct drm_xe_X Xs[];
> > ...
> > }
> >
> > However, strictly following this rule would bring back the name "gts"
> > which is avoided as per commit ("drm/xe/uapi: Rename gts to gt_list")
> > so leave exceptions in the case of gt with num_gt (singular) and
> > "gt_list". Also, this change removes "query" in the name of struct
> > drm_xe_query_gt as it is not returned from the query IOCTL. There is
> > no functional change.
> >
> > Signed-off-by: Francois Dugast <francois.dugast@intel.com>
> > ---
> > drivers/gpu/drm/xe/xe_query.c | 8 ++++----
> > include/uapi/drm/xe_drm.h | 18 +++++++++---------
> > 2 files changed, 13 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_query.c b/drivers/gpu/drm/xe/xe_query.c
> > index b31e00bd29bc..5756d8eaf972 100644
> > --- a/drivers/gpu/drm/xe/xe_query.c
> > +++ b/drivers/gpu/drm/xe/xe_query.c
> > @@ -353,11 +353,11 @@ static int query_config(struct xe_device *xe, struct drm_xe_device_query *query)
> > static int query_gt_list(struct xe_device *xe, struct drm_xe_device_query *query)
> > {
> > struct xe_gt *gt;
> > - size_t size = sizeof(struct drm_xe_query_gt_list) +
> > - xe->info.gt_count * sizeof(struct drm_xe_query_gt);
> > - struct drm_xe_query_gt_list __user *query_ptr =
> > + size_t size = sizeof(struct drm_xe_query_gt) +
> > + xe->info.gt_count * sizeof(struct drm_xe_gt);
> > + struct drm_xe_query_gt __user *query_ptr =
> > u64_to_user_ptr(query->data);
> > - struct drm_xe_query_gt_list *gt_list;
> > + struct drm_xe_query_gt *gt_list;
> > u8 id;
> >
> > if (query->size == 0) {
> > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > index f54e545cc4fb..fa4f554b5264 100644
> > --- a/include/uapi/drm/xe_drm.h
> > +++ b/include/uapi/drm/xe_drm.h
> > @@ -356,14 +356,14 @@ struct drm_xe_query_config {
> > };
> >
> > /**
> > - * struct drm_xe_query_gt - describe an individual GT.
> > + * struct drm_xe_gt - describe an individual GT.
> > *
> > - * To be used with drm_xe_query_gt_list, which will return a list with all the
> > + * To be used with drm_xe_query_gt, which will return a list with all the
> > * existing GT individual descriptions.
> > * Graphics Technology (GT) is a subset of a GPU/tile that is responsible for
> > * implementing graphics and/or media operations.
> > */
> > -struct drm_xe_query_gt {
> > +struct drm_xe_gt {
> > #define DRM_XE_QUERY_GT_TYPE_MAIN 0
> > #define DRM_XE_QUERY_GT_TYPE_MEDIA 1
> > /** @type: GT type: Main or Media */
> > @@ -390,19 +390,19 @@ struct drm_xe_query_gt {
> > };
> >
> > /**
> > - * struct drm_xe_query_gt_list - A list with GT description items.
> > + * struct drm_xe_query_gt - A list with GT description items.
> > *
> > * If a query is made with a struct drm_xe_device_query where .query
> > - * is equal to DRM_XE_DEVICE_QUERY_GT_LIST, then the reply uses struct
> > - * drm_xe_query_gt_list in .data.
> > + * is equal to DRM_XE_DEVICE_QUERY_GT, then the reply uses struct
> > + * drm_xe_query_gt in .data.
> > */
> > -struct drm_xe_query_gt_list {
> > +struct drm_xe_query_gt {
>
> In my opinion it should be drm_xe_query_gts or keep drm_xe_query_gt_list
Cc: Matt Roper <matthew.d.roper@intel.com>
I honestly prefer gts better to align better with the plural of
everything else. But Matt's point is that a plural of an acronym
looks another acronym and people might ask what is "gee-tee-ess"?
so, I like Francois attempt to align them all in a consistent way.
But maybe we need to keep plural everywhere and accept "gts"?
>
> > /** @num_gt: number of GT items returned in gt_list */
> > __u32 num_gt;
> > /** @pad: MBZ */
> > __u32 pad;
> > /** @gt_list: The GT list returned for this device */
> > - struct drm_xe_query_gt gt_list[];
> > + struct drm_xe_gt gt_list[];
> > };
> >
> > /**
> > @@ -495,7 +495,7 @@ struct drm_xe_device_query {
> > #define DRM_XE_DEVICE_QUERY_ENGINES 0
> > #define DRM_XE_DEVICE_QUERY_MEM_REGION 1
> > #define DRM_XE_DEVICE_QUERY_CONFIG 2
> > -#define DRM_XE_DEVICE_QUERY_GT_LIST 3
> > +#define DRM_XE_DEVICE_QUERY_GT 3
> > #define DRM_XE_DEVICE_QUERY_HWCONFIG 4
> > #define DRM_XE_DEVICE_QUERY_GT_TOPOLOGY 5
> > #define DRM_XE_DEVICE_QUERY_ENGINE_CYCLES 6
>
next prev parent reply other threads:[~2023-11-16 20:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-16 14:43 [Intel-xe] [PATCH v1 0/8] uAPI Alignment - Cleanup and future proof Francois Dugast
2023-11-16 14:43 ` [Intel-xe] [PATCH v1 1/8] drm/xe: Extend drm_xe_vm_bind_op Francois Dugast
2023-11-16 20:57 ` Rodrigo Vivi
2023-11-16 14:43 ` [Intel-xe] [PATCH v1 2/8] drm/xe/uapi: Separate bo_create placement from flags Francois Dugast
2023-11-16 14:43 ` [Intel-xe] [PATCH v1 3/8] drm/xe: Make DRM_XE_DEVICE_QUERY_ENGINES future proof Francois Dugast
2023-11-16 14:43 ` [Intel-xe] [PATCH v1 4/8] drm/xe/uapi: Reject bo creation of unaligned size Francois Dugast
2023-11-16 14:43 ` [Intel-xe] [PATCH v1 5/8] drm/xe/uapi: Align on a common way to return arrays (memory regions) Francois Dugast
2023-11-16 20:39 ` Souza, Jose
2023-11-16 14:43 ` [Intel-xe] [PATCH v1 6/8] drm/xe/uapi: Align on a common way to return arrays (gt) Francois Dugast
2023-11-16 20:40 ` Souza, Jose
2023-11-16 20:56 ` Rodrigo Vivi [this message]
2023-11-16 21:28 ` Matt Roper
2023-11-16 14:43 ` [Intel-xe] [PATCH v1 7/8] drm/xe/uapi: Align on a common way to return arrays (engines) Francois Dugast
2023-11-16 20:42 ` Souza, Jose
2023-11-16 14:43 ` [Intel-xe] [PATCH v1 8/8] drm/xe/uapi: Add Tile ID information to the GT info query Francois Dugast
2023-11-16 20:44 ` Souza, Jose
2023-11-16 20:52 ` Rodrigo Vivi
2023-11-16 20:54 ` Souza, Jose
2023-11-17 4:06 ` [Intel-xe] [PATCH] drm/xe/uapi: Fix various struct padding for 64b alignment Rodrigo Vivi
2023-11-17 14:25 ` Souza, Jose
2023-11-17 16:24 ` Matt Roper
2023-11-16 14:46 ` [Intel-xe] ✗ CI.Patch_applied: failure for uAPI Alignment - Cleanup and future proof Patchwork
2023-11-18 3:14 ` [Intel-xe] ✓ CI.Patch_applied: success " Patchwork
2023-11-18 3:14 ` [Intel-xe] ✓ CI.checkpatch: " Patchwork
2023-11-18 3:15 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-11-18 3:23 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-11-18 3:23 ` [Intel-xe] ✗ CI.Hooks: failure " Patchwork
2023-11-18 3:24 ` [Intel-xe] ✓ CI.checksparse: success " Patchwork
2023-11-18 3:59 ` [Intel-xe] ✗ CI.BAT: failure " Patchwork
2023-11-20 12:44 ` [Intel-xe] ✗ CI.Patch_applied: failure for uAPI Alignment - Cleanup and future proof (rev3) 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=ZVaB/d2fR0GBje3T@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=francois.dugast@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jose.souza@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