On Tue, 12 Dec 2023, Randy Dunlap <rdun...@infradead.org> wrote:
> Correct spelling mistakes that were identified by codespell.
>
> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> Cc: David Airlie <airl...@gmail.com>
> Cc: Daniel Vetter <dan...@ffwll.ch>
> Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> Cc: Maxime Ripard <mrip...@kernel.org>
> Cc: Thomas Zimmermann <tzimmerm...@suse.de>
Reviewed-by: Jani Nikula <jani.nik...@intel.com>
> ---
> include/uapi/drm/drm_fourcc.h | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff -- a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -54,7 +54,7 @@ extern "C" {
> * Format modifiers may change any property of the buffer, including the
> number
> * of planes and/or the required allocation size. Format modifiers are
> * vendor-namespaced, and as such the relationship between a fourcc code and
> a
> - * modifier is specific to the modifer being used. For example, some
> modifiers
> + * modifier is specific to the modifier being used. For example, some
> modifiers
> * may preserve meaning - such as number of planes - from the fourcc code,
> * whereas others may not.
> *
> @@ -79,7 +79,7 @@ extern "C" {
> * format.
> * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: these
> users
> * see modifiers as opaque tokens they can check for equality and
> intersect.
> - * These users musn't need to know to reason about the modifier value
> + * These users mustn't need to know to reason about the modifier value
> * (i.e. they are not expected to extract information out of the modifier).
> *
> * Vendors should document their modifier usage in as much detail as
> @@ -540,7 +540,7 @@ extern "C" {
> * This is a tiled layout using 4Kb tiles in row-major layout.
> * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
> * are arranged in four groups (two wide, two high) with column-major layout.
> - * Each group therefore consits out of four 256 byte units, which are also
> laid
> + * Each group therefore consists out of four 256 byte units, which are also
> laid
> * out as 2x2 column-major.
> * 256 byte units are made out of four 64 byte blocks of pixels, producing
> * either a square block or a 2:1 unit.
> @@ -1103,7 +1103,7 @@ drm_fourcc_canonicalize_nvidia_format_mo
> */
>
> /*
> - * The top 4 bits (out of the 56 bits alloted for specifying vendor specific
> + * The top 4 bits (out of the 56 bits allotted for specifying vendor specific
> * modifiers) denote the category for modifiers. Currently we have three
> * categories of modifiers ie AFBC, MISC and AFRC. We can have a maximum of
> * sixteen different categories.
> @@ -1419,7 +1419,7 @@ drm_fourcc_canonicalize_nvidia_format_mo
> * Amlogic FBC Memory Saving mode
> *
> * Indicates the storage is packed when pixel size is multiple of word
> - * boudaries, i.e. 8bit should be stored in this mode to save allocation
> + * boundaries, i.e. 8bit should be stored in this mode to save allocation
> * memory.
> *
> * This mode reduces body layout to 3072 bytes per 64x32 superblock with
--
Jani Nikula, Intel
