[PATCH] drm/drm_modeset_helper_vtables.h: fix typos/spellos

[Jani Nikula]

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

Reviewed-by: Jani Nikula <jani.nikula at intel.com>

> ---
>  include/drm/drm_modeset_helper_vtables.h |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff -- a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -134,7 +134,7 @@ struct drm_crtc_helper_funcs {
>  	 * Since this function is both called from the check phase of an atomic
>  	 * commit, and the mode validation in the probe paths it is not allowed
>  	 * to look at anything else but the passed-in mode, and validate it
> -	 * against configuration-invariant hardward constraints. Any further
> +	 * against configuration-invariant hardware constraints. Any further
>  	 * limits which depend upon the configuration can only be checked in
>  	 * @mode_fixup or @atomic_check.
>  	 *
> @@ -550,7 +550,7 @@ struct drm_encoder_helper_funcs {
>  	 * Since this function is both called from the check phase of an atomic
>  	 * commit, and the mode validation in the probe paths it is not allowed
>  	 * to look at anything else but the passed-in mode, and validate it
> -	 * against configuration-invariant hardward constraints. Any further
> +	 * against configuration-invariant hardware constraints. Any further
>  	 * limits which depend upon the configuration can only be checked in
>  	 * @mode_fixup or @atomic_check.
>  	 *
> @@ -1474,7 +1474,7 @@ struct drm_mode_config_helper_funcs {
>  	 * swapped into the various state pointers. The passed in state
>  	 * therefore contains copies of the old/previous state. This hook should
>  	 * commit the new state into hardware. Note that the helpers have
> -	 * already waited for preceeding atomic commits and fences, but drivers
> +	 * already waited for preceding atomic commits and fences, but drivers
>  	 * can add more waiting calls at the start of their implementation, e.g.
>  	 * to wait for driver-internal request for implicit syncing, before
>  	 * starting to commit the update to the hardware.

-- 
Jani Nikula, Intel