From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Francois Dugast <francois.dugast@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 1/2] drm/xe/uapi: Typo lingo and other small backwards compatible fixes.
Date: Wed, 6 Sep 2023 14:13:45 -0400 [thread overview]
Message-ID: <ZPjBWbRnwpY8HK3g@intel.com> (raw)
In-Reply-To: <ZPiSbH39eeMoNOQ2@fdugast-desk.home>
On Wed, Sep 06, 2023 at 04:53:32PM +0200, Francois Dugast wrote:
> On Wed, Aug 30, 2023 at 05:47:14PM -0400, Rodrigo Vivi wrote:
> > Fix typos, lingo and other small things identified during uapi
> > review.
> >
> > v2: Also fix ALIGNMENT typo at xe_query.c
> >
> > Link: https://lore.kernel.org/all/863bebd0c624d6fc2b38c0a06b63e468b4185128.camel@linux.intel.com/
> > Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > ---
> > drivers/gpu/drm/xe/xe_query.c | 2 +-
> > include/uapi/drm/xe_drm.h | 23 ++++++++++++-----------
> > 2 files changed, 13 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_query.c b/drivers/gpu/drm/xe/xe_query.c
> > index 1db77a7c9039..c3d396904c7b 100644
> > --- a/drivers/gpu/drm/xe/xe_query.c
> > +++ b/drivers/gpu/drm/xe/xe_query.c
> > @@ -195,7 +195,7 @@ static int query_config(struct xe_device *xe, struct drm_xe_device_query *query)
> > if (xe_device_get_root_tile(xe)->mem.vram.usable_size)
> > config->info[XE_QUERY_CONFIG_FLAGS] =
> > XE_QUERY_CONFIG_FLAGS_HAS_VRAM;
> > - config->info[XE_QUERY_CONFIG_MIN_ALIGNEMENT] =
> > + config->info[XE_QUERY_CONFIG_MIN_ALIGNMENT] =
> > xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K ? SZ_64K : SZ_4K;
> > config->info[XE_QUERY_CONFIG_VA_BITS] = xe->info.va_bits;
> > config->info[XE_QUERY_CONFIG_GT_COUNT] = xe->info.gt_count;
> > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > index 86f16d50e9cc..7c08bedbeeaf 100644
> > --- a/include/uapi/drm/xe_drm.h
> > +++ b/include/uapi/drm/xe_drm.h
> > @@ -256,7 +256,7 @@ struct drm_xe_query_config {
> > #define XE_QUERY_CONFIG_REV_AND_DEVICE_ID 0
> > #define XE_QUERY_CONFIG_FLAGS 1
> > #define XE_QUERY_CONFIG_FLAGS_HAS_VRAM (0x1 << 0)
> > -#define XE_QUERY_CONFIG_MIN_ALIGNEMENT 2
> > +#define XE_QUERY_CONFIG_MIN_ALIGNMENT 2
> > #define XE_QUERY_CONFIG_VA_BITS 3
> > #define XE_QUERY_CONFIG_GT_COUNT 4
> > #define XE_QUERY_CONFIG_MEM_REGION_COUNT 5
> > @@ -449,7 +449,6 @@ struct drm_xe_gem_create {
> > * If a VM is specified, this BO must:
> > *
> > * 1. Only ever be bound to that VM.
> > - *
> > * 2. Cannot be exported as a PRIME fd.
> > */
> > __u32 vm_id;
> > @@ -489,7 +488,7 @@ struct drm_xe_gem_mmap_offset {
> > * struct drm_xe_vm_bind_op_error_capture - format of VM bind op error capture
> > */
> > struct drm_xe_vm_bind_op_error_capture {
> > - /** @error: errno that occured */
> > + /** @error: errno that occurred */
> > __s32 error;
> >
> > /** @op: operation that encounter an error */
> > @@ -609,7 +608,7 @@ struct drm_xe_vm_bind_op {
> > * caused the error will be captured in drm_xe_vm_bind_op_error_capture.
> > * Once the user sees the error (via a ufence +
> > * XE_VM_PROPERTY_BIND_OP_ERROR_CAPTURE_ADDRESS), it should free memory
> > - * via non-async unbinds, and then restart all queue'd async binds op via
> > + * via non-async unbinds, and then restart all queued async binds op via
> > * XE_VM_BIND_OP_RESTART. Or alternatively the user should destroy the
> > * VM.
> > *
> > @@ -620,7 +619,7 @@ struct drm_xe_vm_bind_op {
> > #define XE_VM_BIND_FLAG_ASYNC (0x1 << 17)
> > /*
> > * Valid on a faulting VM only, do the MAP operation immediately rather
> > - * than differing the MAP to the page fault handler.
> > + * than deferring the MAP to the page fault handler.
> > */
> > #define XE_VM_BIND_FLAG_IMMEDIATE (0x1 << 18)
> > /*
> > @@ -727,7 +726,7 @@ struct drm_xe_exec_queue_set_property {
> > #define XE_EXEC_QUEUE_SET_PROPERTY_ACC_TRIGGER 6
> > #define XE_EXEC_QUEUE_SET_PROPERTY_ACC_NOTIFY 7
> > #define XE_EXEC_QUEUE_SET_PROPERTY_ACC_GRANULARITY 8
> > - /** @property: property to set */
> > + /** @property: property to be set */
> > __u32 property;
> >
> > /** @value: property value */
> > @@ -796,7 +795,7 @@ struct drm_xe_exec_queue_get_property {
> > __u32 exec_queue_id;
> >
> > #define XE_EXEC_QUEUE_GET_PROPERTY_BAN 0
> > - /** @property: property to get */
> > + /** @property: property to be gotten */
> > __u32 property;
>
> LGTM but as a non-native speaker I am just wondering about the use of "to get"
> vs. "to be gotten" in this context (and to a lesser extent "to set" vs. "to be
> set") as it seems not to be widely used:
well, I'm not a native speaker as well and I bet your English is better than mine ;)
>
> $ grep -E "@.*to get" . -ir | wc -l
> 701
but I don't believe it applies... about all of these occurrences is
'to get *something*'
while in our case here the 'property' item is what we want to get.
> $ grep -E "@.*to be gotten" . -ir | wc -l
> 1
Okay, I don't want to be the first one hehe...
I will just accept my English is broken and although my brain cannot parse that
(no verb before, no object after)
I will leave it alone and remove from this patch :)
>
> Francois
>
> >
> > /** @value: property value */
> > @@ -907,7 +906,7 @@ struct drm_xe_mmio {
> > /**
> > * struct drm_xe_wait_user_fence - wait user fence
> > *
> > - * Wait on user fence, XE will wakeup on every HW engine interrupt in the
> > + * Wait on user fence, XE will wake-up on every HW engine interrupt in the
> > * instances list and check if user fence is complete::
> > *
> > * (*addr & MASK) OP (VALUE & MASK)
> > @@ -1039,9 +1038,11 @@ struct drm_xe_vm_madvise {
> > */
> > #define DRM_XE_VM_MADVISE_PRIORITY 5
> > #define DRM_XE_VMA_PRIORITY_LOW 0
> > -#define DRM_XE_VMA_PRIORITY_NORMAL 1 /* Default */
> > -#define DRM_XE_VMA_PRIORITY_HIGH 2 /* Must be elevated user */
> > - /* Pin the VMA in memory, must be elevated user */
> > + /* Default */
> > +#define DRM_XE_VMA_PRIORITY_NORMAL 1
> > + /* Must be user with elevated privileges */
> > +#define DRM_XE_VMA_PRIORITY_HIGH 2
> > + /* Pin the VMA in memory, must be user with elevated privileges */
> > #define DRM_XE_VM_MADVISE_PIN 6
> > /** @property: property to set */
> > __u32 property;
> > --
> > 2.41.0
> >
next prev parent reply other threads:[~2023-09-06 18:16 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-30 21:47 [Intel-xe] [PATCH 1/2] drm/xe/uapi: Typo lingo and other small backwards compatible fixes Rodrigo Vivi
2023-08-30 21:47 ` [Intel-xe] [PATCH 2/2] drm/xe/uapi: Remove useless max_page_size Rodrigo Vivi
2023-09-06 9:28 ` Francois Dugast
2023-08-30 22:57 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with [1/2] drm/xe/uapi: Typo lingo and other small backwards compatible fixes Patchwork
2023-08-30 22:57 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-08-30 22:58 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-08-30 23:05 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-08-30 23:05 ` [Intel-xe] ✗ CI.Hooks: failure " Patchwork
2023-08-30 23:06 ` [Intel-xe] ✗ CI.checksparse: warning " Patchwork
2023-08-30 23:38 ` [Intel-xe] ✓ CI.BAT: success " Patchwork
2023-09-06 14:53 ` [Intel-xe] [PATCH 1/2] " Francois Dugast
2023-09-06 18:13 ` Rodrigo Vivi [this message]
2023-09-06 18:16 ` [Intel-xe] [PATCH] " Rodrigo Vivi
2023-09-07 7:08 ` Francois Dugast
2023-09-07 10:23 ` Thomas Hellström
2023-09-06 18:19 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with drm/xe/uapi: Typo lingo and other small backwards compatible fixes. (rev2) Patchwork
2023-09-06 18:19 ` [Intel-xe] ✓ CI.checkpatch: " Patchwork
2023-09-06 18:20 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-09-06 18:27 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-09-06 18:28 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-09-06 18:29 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-09-07 11:54 ` [Intel-xe] ✓ CI.Patch_applied: success for series starting with drm/xe/uapi: Typo lingo and other small backwards compatible fixes. (rev3) Patchwork
2023-09-07 11:54 ` [Intel-xe] ✓ CI.checkpatch: " Patchwork
2023-09-07 11:56 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-09-07 12:03 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-09-07 12:03 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-09-07 12:04 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-09-07 12:36 ` [Intel-xe] ✓ CI.BAT: " 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=ZPjBWbRnwpY8HK3g@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=francois.dugast@intel.com \
--cc=intel-xe@lists.freedesktop.org \
/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.