From nobody Mon May 25 06:41:07 2026 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 72F64175A9F for ; Sun, 17 May 2026 13:41:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779025299; cv=none; b=Go8tgH7eTibql78th+M/1l+pgB076fv8Zme9u06co9hHT3AsvkEb6RyW4ZVzdLIdd4zQQgTbBVp4mnxiMDFWureXPQQshbBgdfGaP04i6c8VRK24tBKj//Krn9R5K/NZ67NrePBRWyVI3iaaf1+JaXuOdk7nIO4tSXfL2TxqKVo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779025299; c=relaxed/simple; bh=7Y0ReJXNUS5w7p1PQFhAmWmhyBq6tUOUn6HIe366q6s=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=NJz+TZategOvaWjv0kcmUqcJT1fvNoq/y5nTwSPJBjLMpBjKpXudHnkpc1qzm70Ee1GyD31lkCiaBL/W7ddeH2c8ZG9dXk9oqkpgacpstFr0fgcMuvprag+ISpgNerTdXM7JXvqJg5yvjQQoi/eGCZCG/68H38Z/OHZW4RR0Lbw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=HopwKcDA; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HopwKcDA" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-449d6c68ed8so1244455f8f.0 for ; Sun, 17 May 2026 06:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779025295; x=1779630095; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=e0Fqrssiq5EKJqOqnUySdSTXrmaCviyXE8eaNVLH4Wo=; b=HopwKcDA3I+5h2/tRrvagVhpOEm8GcdxvUs24So0lbYwKzqGNlrKUxAALo8Hdn8WPb Vi2beSlEEwiPa9GCKN4gLKEmfY5nmne9CHKO+e7K6t+Ap0k3g9ELC1Omplr8u2pXW4jN q43vsW9GHY5TKt6HlkV3Bi4lKJWYscoSRbh+GNfhUl9X25ZdmjM0q1HLfDgPeukdzTWe IrEp8DfDmGBcEQbumrgT3f3Ay7wlhECrWtPkgNhnQFF54F2IDg0/TyBuJb/1Q0sSmvxj kufAx7ah2Ow8a0KZHyPkl4P3sSpdeL+ND1xW2ur8movBdo/VziFzAVRU7zqE1STEBKr7 eQAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779025295; x=1779630095; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=e0Fqrssiq5EKJqOqnUySdSTXrmaCviyXE8eaNVLH4Wo=; b=KYlpa3nnCMeDCXs1zBrPDHX9WFTYbmnkfB4mncNhPwheEiB4g1FjexadxXOWq4aZdw R7ytUMqCwlm+CE8oEJV+JdhFPFieCA4gEwoFfcuH600XZFJlAwqGsOQwy046JwEsr9S4 Kr7u2jSgvG8XqvxUdk6oRMzhTi6KYen0PdVFvzX/D0omXXkyjTu5eGCwDf+Yr8j6QfGp x8fymZDni+8+PYJBNWU2F2JgraYj0WYTv9Wk61QwkCZj1TS7l7aVrI/g3jnlussO/uae iY23H/FHofVvHLedZczYSv2kw0E8son5VJ8PSk9QGA3LySlGlVKH8igP5Wdug18AEAz5 Mh9A== X-Forwarded-Encrypted: i=1; AFNElJ/AIpyrg9wGhvVgEDV+giJfj0ted67NT4nsFY6d62F3aeUlw/gx1wABtM6xCIkEllBe7VvWHq4EgawGtO4=@vger.kernel.org X-Gm-Message-State: AOJu0YxjTTIOiyj/i4L9DSDFUi5+MCp8E588kPzUsZzKNpMHQprtRGsO sZp3es19NiKAe6vk1Kj4eZJJpvireWFteaoOjMlnAz9IZmj9qbb0cqxX X-Gm-Gg: Acq92OE8iB+CWzBdbQXjE3WLBrUjGmQ2xWQXH4wgYUk3Z//T5V9n6BHXK36JdBduVUB Ck//Cds+cenxq271+KjysU6mEt2sJwVO5Ow+ntPGdgUO1Uj2nBhzoxD/rrsrJfu1LGQAmTTd6qS W7XSq+OmabkhGnjSlI5rKvIzWWvLF0qHdsak/iOVUf13+mV/Sx0AOpN6w5YI7jQcctXLG2q/h2I IpXtHKqG4am/8keGnCJ3WN4240qorl92XMBtAQyfayodGs3uvxcNKlIM+5NQpAutluyggJLctqV 3je9geK68mVkvcnwlD3D60gN4+VdWw1i7Ae/P7WGRoFm92wOUXXGRSHRbaHBMJojx3CNRiT7C9+ lN3qaKW2KF8EHfbdcVTwFq+9H59XW5qC8HPqBZjejPXSvkEYE7B2wqAGCGyD4zwCgQ2tZJ2cZvn ZGRxqFFsWi+1U0daAccCJgO1+IqLEz0LNU/MXLDmlQfRUd4QiRjtKcU3VnI8v5Lt9l9KiPqvEMk w== X-Received: by 2002:a05:6000:4010:b0:43f:df1b:9e07 with SMTP id ffacd0b85a97d-45e5c5a5580mr16862802f8f.42.1779025294346; Sun, 17 May 2026 06:41:34 -0700 (PDT) Received: from localhost.localdomain (i59F7ABEC.versanet.de. [89.247.171.236]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45da15a666fsm28231673f8f.36.2026.05.17.06.41.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 May 2026 06:41:33 -0700 (PDT) From: Elliot Tester To: alexander.deucher@amd.com, christian.koenig@amd.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, corbet@lwn.net Cc: skhan@linuxfoundation.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Elliot Tester Subject: [PATCH] docs: gpu: fix spelling errors and remove duplicate sentence Date: Sun, 17 May 2026 15:41:22 +0200 Message-ID: <20260517134122.38389-1-elliotctester1@gmail.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 Acked-by: Randy Dunlap --- 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, cont= ext 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 retur= n 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. =20 INFO diff --git a/Documentation/gpu/drm-compute.rst b/Documentation/gpu/drm-comp= ute.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. =20 -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. =20 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. 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 ret= urn - 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. =20 ENODEV: @@ -761,4 +761,4 @@ Stable uAPI events From ``drivers/gpu/drm/scheduler/gpu_scheduler_trace.h`` =20 .. 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 a= lso -rename all inlined fucntions according to driver conventions. +rename all inlined functions according to driver conventions. =20 Contact: Thomas Zimmermann, respective driver maintainer =20 @@ -301,7 +301,7 @@ Various hold-ups: valid formats for atomic drivers. =20 - 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. =20 Contact: Simona Vetter @@ -326,10 +326,9 @@ everything after it has done the write-protect/mkwrite= trickery: =20 vma->vm_page_prot =3D pgprot_wrprotect(vma->vm_page_prot); =20 -- Set the mkwrite and fsync callbacks with similar implementions to the co= re +- 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 actua= lly - require a struct page. uff. These should all work on plain ptes, they d= on't - actually require a struct page. + require a struct page. =20 - 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =20 The drm_syncobj container can be used by driver independent code to signal -complection of submission. +completion of submission. =20 One minor feature still missing is a generic DRM IOCTL to query the error status of binary and timeline drm_syncobj. --=20 2.54.0