Re: [PATCH] drm/fourcc: fix spelling/typos

[Jani Nikula <jani.nikula@linux.intel.com>]

On Tue, 12 Dec 2023, Randy Dunlap <rdunlap@infradead.org> wrote:
> Correct spelling mistakes that were identified by codespell.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>

Reviewed-by: Jani Nikula <jani.nikula@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