On 5/17/26 6:41 AM, Elliot Tester wrote:
> Fix various spelling errors in GPU docs:
> - indicies -> indices (userq.rst)
> - umap -> unmap (userq.rst)
> - pre-empt -> preempt (drm-compute.rst)
> - buffer-leaks -> buffer leaks (drm-uapi.rst)
> - Additionally to -> In addition to (drm-uapi.rst)
> - unpriviledged -> unprivileged (drm-uapi.rst)
> - fucntions -> functions (todo.rst)
> - varios -> various (todo.rst)
> - implementions -> implementations (todo.rst)
> - complection -> completion (todo.rst)
>
> Ale remove a duplicated sentance and stray "uff." in the todo.rst, add
> missing period after drm_ioctl.c reference, and add missing newline at
> end of drm-uapi.rst. Fixing this would make reading the docs just a
> little bit easier.
>
> Signed-off-by: Elliot Tester <[email protected]>
LGTM. Thanks.
Acked-by: Randy Dunlap <[email protected]>
> ---
> Documentation/gpu/amdgpu/userq.rst | 4 ++--
> Documentation/gpu/drm-compute.rst | 2 +-
> Documentation/gpu/drm-uapi.rst | 10 +++++-----
> Documentation/gpu/todo.rst | 11 +++++------
> 4 files changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/gpu/amdgpu/userq.rst
> b/Documentation/gpu/amdgpu/userq.rst
> index 88f54393b..94427e18a 100644
> --- a/Documentation/gpu/amdgpu/userq.rst
> +++ b/Documentation/gpu/amdgpu/userq.rst
> @@ -156,9 +156,9 @@ IOCTL Interfaces
> GPU virtual addresses used for queues and related data (rptrs, wptrs, context
> save areas, etc.) should be validated by the kernel mode driver to prevent
> the
> user from specifying invalid GPU virtual addresses. If the user provides
> -invalid GPU virtual addresses or doorbell indicies, the IOCTL should return
> an
> +invalid GPU virtual addresses or doorbell indices, the IOCTL should return an
> error message. These buffers should also be tracked in the kernel driver so
> -that if the user attempts to unmap the buffer(s) from the GPUVM, the umap
> call
> +that if the user attempts to unmap the buffer(s) from the GPUVM, the unmap
> call
> would return an error.
>
> INFO
> diff --git a/Documentation/gpu/drm-compute.rst
> b/Documentation/gpu/drm-compute.rst
> index f90c3e63a..35cc8d654 100644
> --- a/Documentation/gpu/drm-compute.rst
> +++ b/Documentation/gpu/drm-compute.rst
> @@ -7,7 +7,7 @@ seconds. (The time let the user wait before he reaches for
> the power button).
> This means that other techniques need to be used to manage those workloads,
> that cannot use fences.
>
> -Some hardware may schedule compute jobs, and have no way to pre-empt them, or
> +Some hardware may schedule compute jobs, and have no way to preempt them, or
> have their memory swapped out from them. Or they simply want their workload
> not to be preempted or swapped out at all.
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 579e87cb9..0ef498bff 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -150,10 +150,10 @@ separate render node called renderD<num>. There will be
> one render node
> per device. No ioctls except PRIME-related ioctls will be allowed on
> this node. Especially GEM_OPEN will be explicitly prohibited. For a
> complete list of driver-independent ioctls that can be used on render
> -nodes, see the ioctls marked DRM_RENDER_ALLOW in drm_ioctl.c Render
> -nodes are designed to avoid the buffer-leaks, which occur if clients
> +nodes, see the ioctls marked DRM_RENDER_ALLOW in drm_ioctl.c. Render
> +nodes are designed to avoid the buffer leaks, which occur if clients
> guess the flink names or mmap offsets on the legacy interface.
> -Additionally to this basic interface, drivers must mark their
> +In addition to this basic interface, drivers must mark their
> driver-dependent render-only ioctls as DRM_RENDER_ALLOW so render
> clients can use them. Driver authors must be careful not to allow any
> privileged ioctls on render nodes.
> @@ -568,7 +568,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:
> @@ -761,4 +761,4 @@ Stable uAPI events
> From ``drivers/gpu/drm/scheduler/gpu_scheduler_trace.h``
>
> .. kernel-doc:: drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> - :doc: uAPI trace events
> \ No newline at end of file
> + :doc: uAPI trace events
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index bc9f14c8a..b13cd4347 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -55,7 +55,7 @@ There are still drivers that use drm_simple_display_pipe.
> The task here is to
> convert them to use regular atomic helpers. Search for a driver that calls
> drm_simple_display_pipe_init() and inline all helpers from
> drm_simple_kms_helper.c
> into the driver, such that no simple-KMS interfaces are required. Please also
> -rename all inlined fucntions according to driver conventions.
> +rename all inlined functions according to driver conventions.
>
> Contact: Thomas Zimmermann, respective driver maintainer
>
> @@ -301,7 +301,7 @@ Various hold-ups:
> valid formats for atomic drivers.
>
> - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
> - version of the varios drm_gem_fb_create functions. Maybe called
> + version of the various drm_gem_fb_create functions. Maybe called
> drm_gem_fb_create/_with_dirty/_with_funcs as needed.
>
> Contact: Simona Vetter
> @@ -326,10 +326,9 @@ 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.
> + require a struct page.
>
> - Track the dirty pages in a separate structure (bitfield with one bit per
> page
> should work) to avoid clobbering struct page.
> @@ -914,7 +913,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.
--
~Randy
