All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Nitin Gote <nitin.r.gote@intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>
Cc: <krzysztof.niemiec@intel.com>, <andi.shyti@intel.com>,
	<jani.nikula@linux.intel.com>, <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v4 3/8] drm/i915/gem: fix typos in i915/gem files
Date: Tue, 21 Jan 2025 11:14:51 -0500	[thread overview]
Message-ID: <Z4_H-1qhW1AjH_-m@intel.com> (raw)
In-Reply-To: <20250120081517.3237326-4-nitin.r.gote@intel.com>

On Mon, Jan 20, 2025 at 01:45:12PM +0530, Nitin Gote wrote:
> Fix all typos in files under drm/i915/gem reported by codespell tool.
> 
> v2: Codespell won't catch it, but it should be
>     "user defined" and not "use defined". <Krzysztof Niemiec>
> 
> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c        | 6 +++---
>  drivers/gpu/drm/i915/gem/i915_gem_context_types.h  | 6 +++---
>  drivers/gpu/drm/i915/gem/i915_gem_domain.c         | 2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c     | 4 ++--
>  drivers/gpu/drm/i915/gem/i915_gem_region.c         | 2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c       | 4 ++--
>  drivers/gpu/drm/i915/gem/i915_gem_tiling.c         | 2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c            | 2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c       | 2 +-

Joonas, Tvrtko, ack on taking this and the other gt related patch from this
series both in drm-intel-next?

>  drivers/gpu/drm/i915/gem/selftests/huge_pages.c    | 2 +-
>  drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 2 +-
>  11 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index c0543c35cd6a..ab1af978911b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -238,7 +238,7 @@ static int proto_context_set_persistence(struct drm_i915_private *i915,
>  		 *
>  		 * However, if we cannot reset an engine by itself, we cannot
>  		 * cleanup a hanging persistent context without causing
> -		 * colateral damage, and we should not pretend we can by
> +		 * collateral damage, and we should not pretend we can by
>  		 * exposing the interface.
>  		 */
>  		if (!intel_has_reset_engine(to_gt(i915)))
> @@ -1589,7 +1589,7 @@ static int __context_set_persistence(struct i915_gem_context *ctx, bool state)
>  		 *
>  		 * However, if we cannot reset an engine by itself, we cannot
>  		 * cleanup a hanging persistent context without causing
> -		 * colateral damage, and we should not pretend we can by
> +		 * collateral damage, and we should not pretend we can by
>  		 * exposing the interface.
>  		 */
>  		if (!intel_has_reset_engine(to_gt(ctx->i915)))
> @@ -2328,7 +2328,7 @@ finalize_create_context_locked(struct drm_i915_file_private *file_priv,
>  
>  	/*
>  	 * One for the xarray and one for the caller.  We need to grab
> -	 * the reference *prior* to making the ctx visble to userspace
> +	 * the reference *prior* to making the ctx visible to userspace
>  	 * in gem_context_register(), as at any point after that
>  	 * userspace can try to race us with another thread destroying
>  	 * the context under our feet.
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index b6d97da63d1f..67ac2586a0f3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -245,9 +245,9 @@ struct i915_gem_context {
>  	 * Execbuf uses the I915_EXEC_RING_MASK as an index into this
>  	 * array to select which HW context + engine to execute on. For
>  	 * the default array, the user_ring_map[] is used to translate
> -	 * the legacy uABI onto the approprate index (e.g. both
> +	 * the legacy uABI onto the appropriate index (e.g. both
>  	 * I915_EXEC_DEFAULT and I915_EXEC_RENDER select the same
> -	 * context, and I915_EXEC_BSD is weird). For a use defined
> +	 * context, and I915_EXEC_BSD is weird). For a user defined
>  	 * array, execbuf uses I915_EXEC_RING_MASK as a plain index.
>  	 *
>  	 * User defined by I915_CONTEXT_PARAM_ENGINE (when the
> @@ -276,7 +276,7 @@ struct i915_gem_context {
>  	 * @vm: unique address space (GTT)
>  	 *
>  	 * In full-ppgtt mode, each context has its own address space ensuring
> -	 * complete seperation of one client from all others.
> +	 * complete separation of one client from all others.
>  	 *
>  	 * In other modes, this is a NULL pointer with the expectation that
>  	 * the caller uses the shared global GTT.
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index 3770828f2eaf..ee55caca67a1 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -276,7 +276,7 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
>  	 * For objects created by userspace through GEM_CREATE with pat_index
>  	 * set by set_pat extension, simply return 0 here without touching
>  	 * the cache setting, because such objects should have an immutable
> -	 * cache setting by desgin and always managed by userspace.
> +	 * cache setting by design and always managed by userspace.
>  	 */
>  	if (i915_gem_object_has_cache_level(obj, cache_level))
>  		return 0;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index f151640c1d13..c8107502190d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -303,7 +303,7 @@ struct i915_execbuffer {
>  	struct intel_gt_buffer_pool_node *batch_pool; /** pool node for batch buffer */
>  
>  	/**
> -	 * Indicate either the size of the hastable used to resolve
> +	 * Indicate either the size of the hashtable used to resolve
>  	 * relocation handles, or if negative that we are using a direct
>  	 * index into the execobj[].
>  	 */
> @@ -2543,7 +2543,7 @@ static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
>  
>  			/*
>  			 * Error path, cannot use intel_context_timeline_lock as
> -			 * that is user interruptable and this clean up step
> +			 * that is user interruptible and this clean up step
>  			 * must be done.
>  			 */
>  			mutex_lock(&ce->timeline->mutex);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c b/drivers/gpu/drm/i915/gem/i915_gem_region.c
> index b09b74a2448b..636768d0f57e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
> @@ -82,7 +82,7 @@ __i915_gem_object_create_region(struct intel_memory_region *mem,
>  
>  	/*
>  	 * Anything smaller than the min_page_size can't be freely inserted into
> -	 * the GTT, due to alignemnt restrictions. For such special objects,
> +	 * the GTT, due to alignment restrictions. For such special objects,
>  	 * make sure we force memcpy based suspend-resume. In the future we can
>  	 * revisit this, either by allowing special mis-aligned objects in the
>  	 * migration path, or by mapping all of LMEM upfront using cheap 1G
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> index 9117e9422844..aec41f0f098f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> @@ -25,7 +25,7 @@ static bool swap_available(void)
>  
>  static bool can_release_pages(struct drm_i915_gem_object *obj)
>  {
> -	/* Consider only shrinkable ojects. */
> +	/* Consider only shrinkable objects. */
>  	if (!i915_gem_object_is_shrinkable(obj))
>  		return false;
>  
> @@ -261,7 +261,7 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww,
>   * i915_gem_shrink_all - Shrink buffer object caches completely
>   * @i915: i915 device
>   *
> - * This is a simple wraper around i915_gem_shrink() to aggressively shrink all
> + * This is a simple wrapper around i915_gem_shrink() to aggressively shrink all
>   * caches completely. It also first waits for and retires all outstanding
>   * requests to also be able to release backing storage for active objects.
>   *
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> index d9eb84c1d2f1..5ac23ff3feff 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> @@ -39,7 +39,7 @@
>   * Since neither of this applies for new tiling layouts on modern platforms like
>   * W, Ys and Yf tiling GEM only allows object tiling to be set to X or Y tiled.
>   * Anything else can be handled in userspace entirely without the kernel's
> - * invovlement.
> + * involvement.
>   */
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 10d8673641f7..1f4814968868 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -994,7 +994,7 @@ void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj)
>  		 * If we need to place an LMEM resource which doesn't need CPU
>  		 * access then we should try not to victimize mappable objects
>  		 * first, since we likely end up stealing more of the mappable
> -		 * portion. And likewise when we try to find space for a mappble
> +		 * portion. And likewise when we try to find space for a mappable
>  		 * object, we know not to ever victimize objects that don't
>  		 * occupy any mappable pages.
>  		 */
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> index 041dab543b78..2f6b33edb9c9 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -603,7 +603,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
>  		 * sequence, where at the end we can do the move for real.
>  		 *
>  		 * The special case here is when the dst_mem is TTM_PL_SYSTEM,
> -		 * which doens't require any kind of move, so it should be safe
> +		 * which doesn't require any kind of move, so it should be safe
>  		 * to skip all the below and call ttm_bo_move_null() here, where
>  		 * the caller in __i915_ttm_get_pages() will take care of the
>  		 * rest, since we should have a valid ttm_tt.
> diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> index 84d41e6ccf05..bd08605a1611 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> @@ -1781,7 +1781,7 @@ static int igt_tmpfs_fallback(void *arg)
>  
>  	/*
>  	 * Make sure that we don't burst into a ball of flames upon falling back
> -	 * to tmpfs, which we rely on if on the off-chance we encouter a failure
> +	 * to tmpfs, which we rely on if on the off-chance we encounter a failure
>  	 * when setting up gemfs.
>  	 */
>  
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> index 99a9ade73956..804f74084bd4 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> @@ -1342,7 +1342,7 @@ static int igt_mmap_migrate(void *arg)
>  		}
>  
>  		/*
> -		 * Allocate in the mappable portion, should be no suprises here.
> +		 * Allocate in the mappable portion, should be no surprises here.
>  		 */
>  		err = __igt_mmap_migrate(mixed, ARRAY_SIZE(mixed), mr, 0);
>  		if (err)
> -- 
> 2.25.1
> 

  parent reply	other threads:[~2025-01-21 16:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-20  8:15 [PATCH v4 0/8] Fix all typos in i915 Nitin Gote
2025-01-20  8:15 ` [PATCH v4 1/8] drm/i915/gt: fix typos in i915/gt files Nitin Gote
2025-01-20 13:14   ` Krzysztof Niemiec
2025-01-20  8:15 ` [PATCH v4 2/8] drm/i915/gvt: fix typos in i915/gvt files Nitin Gote
2025-01-20 13:15   ` Krzysztof Niemiec
2025-01-20  8:15 ` [PATCH v4 3/8] drm/i915/gem: fix typos in i915/gem files Nitin Gote
2025-01-20 13:15   ` Krzysztof Niemiec
2025-01-21 16:14   ` Rodrigo Vivi [this message]
2025-01-23 10:41     ` Joonas Lahtinen
2025-01-23 10:49       ` Rodrigo Vivi
2025-01-20  8:15 ` [PATCH v4 4/8] drm/i915/pxp: fix typos in i915/pxp files Nitin Gote
2025-01-20 13:16   ` Krzysztof Niemiec
2025-01-20  8:15 ` [PATCH v4 5/8] drm/i915/selftests: fix typos in i915/selftests files Nitin Gote
2025-01-20 13:16   ` Krzysztof Niemiec
2025-01-20  8:15 ` [PATCH v4 6/8] drm/i915/soc: fix typos in i915/soc files Nitin Gote
2025-01-20 13:17   ` Krzysztof Niemiec
2025-01-20  8:15 ` [PATCH v4 7/8] drm/i915/display: fix typos in i915/display files Nitin Gote
2025-01-20 13:17   ` Krzysztof Niemiec
2025-01-20  8:15 ` [PATCH v4 8/8] drm/i915: fix typos in drm/i915 files Nitin Gote
2025-01-20 13:18   ` Krzysztof Niemiec
2025-01-20  9:42 ` ✗ Fi.CI.SPARSE: warning for Fix all typos in i915 (rev6) Patchwork
2025-01-20  9:56 ` ✓ i915.CI.BAT: success " Patchwork
2025-01-21  4:59 ` ✗ i915.CI.Full: failure " Patchwork
2025-01-21  5:04   ` Gote, Nitin R
2025-01-22  4:41     ` Ravali, JupallyX
2025-01-21 14:45 ` ✓ i915.CI.Full: success " 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=Z4_H-1qhW1AjH_-m@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=andi.shyti@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=krzysztof.niemiec@intel.com \
    --cc=nitin.r.gote@intel.com \
    --cc=tursulin@ursulin.net \
    /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.