Message-ID: <9924d04d-179c-428a-b2f7-001e075e8f38@amd.com>
Date: Thu, 21 Aug 2025 09:03:19 +0200
From: Christian König <christian.koenig@....com>
To: Rakuram Eswaran <rakuram.e96@...il.com>, linux-doc@...r.kernel.org,
 alexander.deucher@....com, airlied@...il.com, corbet@....net
Cc: tzimmermann@...e.de, mripard@...nel.org,
 maarten.lankhorst@...ux.intel.com, simona@...ll.ch, siqueira@...lia.com,
 harry.wentland@....com, amd-gfx@...ts.freedesktop.org,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 linux-kernel-mentees@...ts.linuxfoundation.org, skhan@...uxfoundation.org
Subject: Re: [PATCH] docs: gpu: Fix spelling mistakes

On 20.08.25 20:22, Rakuram Eswaran wrote:
> Fixed following typos reported by Codespell
> 
> 1. filp ==> flip
> In Documentation/gpu/drm-mm.rst


That is not a spelling mistake. filp is often used as acronym for "file private" and as far as I can see that is exactly what is meant here.

All others look valid to me.

Regards,
Christian.

> 
> 2. complection ==> completion
>    implementions ==> implementations
> In Documentation/gpu/todo.rst
> 
> 3. unpriviledged ==> unprivileged
> In Documentation/gpu/drm-uapi.rst
> 
> 4. propogated ==> propagated
>    aperatures ==> apertures
> In Documentation/gpu/amdgpu/debugfs.rst
> 
> 5. parition ==> partition
> In Documentation/gpu/amdgpu/process-isolation.rst
> 
> 6. conections ==> connections
> In Documentation/gpu/amdgpu/display/programming-model-dcn.rst
> 
> Signed-off-by: Rakuram Eswaran <rakuram.e96@...il.com>
> ---
>  Documentation/gpu/amdgpu/debugfs.rst                       | 4 ++--
>  Documentation/gpu/amdgpu/display/programming-model-dcn.rst | 2 +-
>  Documentation/gpu/amdgpu/process-isolation.rst             | 2 +-
>  Documentation/gpu/drm-mm.rst                               | 2 +-
>  Documentation/gpu/drm-uapi.rst                             | 2 +-
>  Documentation/gpu/todo.rst                                 | 4 ++--
>  6 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/gpu/amdgpu/debugfs.rst b/Documentation/gpu/amdgpu/debugfs.rst
> index 5150d0a95658..151d8bfc79e2 100644
> --- a/Documentation/gpu/amdgpu/debugfs.rst
> +++ b/Documentation/gpu/amdgpu/debugfs.rst
> @@ -94,7 +94,7 @@ amdgpu_error_<name>
>  -------------------
>  
>  Provides an interface to set an error code on the dma fences associated with
> -ring <name>.  The error code specified is propogated to all fences associated
> +ring <name>.  The error code specified is propagated to all fences associated
>  with the ring.  Use this to inject a fence error into a ring.
>  
>  amdgpu_pm_info
> @@ -165,7 +165,7 @@ GTT memory.
>  amdgpu_regs_*
>  -------------
>  
> -Provides direct access to various register aperatures on the GPU.  Used
> +Provides direct access to various register apertures on the GPU.  Used
>  by tools like UMR to access GPU registers.
>  
>  amdgpu_regs2
> diff --git a/Documentation/gpu/amdgpu/display/programming-model-dcn.rst b/Documentation/gpu/amdgpu/display/programming-model-dcn.rst
> index c1b48d49fb0b..bc7de97a746f 100644
> --- a/Documentation/gpu/amdgpu/display/programming-model-dcn.rst
> +++ b/Documentation/gpu/amdgpu/display/programming-model-dcn.rst
> @@ -100,7 +100,7 @@ represents the connected display.
>     For historical reasons, we used the name `dc_link`, which gives the
>     wrong impression that this abstraction only deals with physical connections
>     that the developer can easily manipulate. However, this also covers
> -   conections like eDP or cases where the output is connected to other devices.
> +   connections like eDP or cases where the output is connected to other devices.
>  
>  There are two structs that are not represented in the diagram since they were
>  elaborated in the DCN overview page  (check the DCN block diagram :ref:`Display
> diff --git a/Documentation/gpu/amdgpu/process-isolation.rst b/Documentation/gpu/amdgpu/process-isolation.rst
> index 6b6d70e357a7..c1297a9e4d09 100644
> --- a/Documentation/gpu/amdgpu/process-isolation.rst
> +++ b/Documentation/gpu/amdgpu/process-isolation.rst
> @@ -26,7 +26,7 @@ Example of enabling enforce isolation on a GPU with multiple partitions:
>      $ cat /sys/class/drm/card0/device/enforce_isolation
>      1 0 1 0
>  
> -The output indicates that enforce isolation is enabled on zeroth and second parition and disabled on first and fourth parition.
> +The output indicates that enforce isolation is enabled on zeroth and second partition and disabled on first and fourth partition.
>  
>  For devices with a single partition or those that do not support partitions, there will be only one element:
>  
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index d55751cad67c..3496ef28b15c 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -153,7 +153,7 @@ size in bytes.
>  GEM uses shmem to allocate anonymous pageable memory.
>  drm_gem_object_init() will create an shmfs file of the
>  requested size and store it into the struct :c:type:`struct
> -drm_gem_object <drm_gem_object>` filp field. The memory is
> +drm_gem_object <drm_gem_object>` flip field. The memory is
>  used as either main storage for the object when the graphics hardware
>  uses system memory directly or as a backing store otherwise.
>  
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 843facf01b2d..7435664a1ffe 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -535,7 +535,7 @@ ENOSPC:
>  EPERM/EACCES:
>          Returned for an operation that is valid, but needs more privileges.
>          E.g. root-only or much more common, DRM master-only operations return
> -        this when called by unpriviledged clients. There's no clear
> +        this when called by unprivileged clients. There's no clear
>          difference between EACCES and EPERM.
>  
>  ENODEV:
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index be8637da3fe9..1d064e617699 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -319,7 +319,7 @@ everything after it has done the write-protect/mkwrite trickery:
>  
>        vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);
>  
> -- Set the mkwrite and fsync callbacks with similar implementions to the core
> +- Set the mkwrite and fsync callbacks with similar implementations to the core
>    fbdev defio stuff. These should all work on plain ptes, they don't actually
>    require a struct page.  uff. These should all work on plain ptes, they don't
>    actually require a struct page.
> @@ -854,7 +854,7 @@ Querying errors from drm_syncobj
>  ================================
>  
>  The drm_syncobj container can be used by driver independent code to signal
> -complection of submission.
> +completion of submission.
>  
>  One minor feature still missing is a generic DRM IOCTL to query the error
>  status of binary and timeline drm_syncobj.

Powered by blists - more mailing lists