On Tue, 12 Dec 2023, Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote:
> Fix spelling problems as identified by codespell.
>
> Signed-off-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
> Cc: David Airlie <airlied@xxxxxxxxx>
> Cc: Daniel Vetter <daniel@xxxxxxxx>
> Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
> Cc: Maxime Ripard <mripard@xxxxxxxxxx>
> Cc: Thomas Zimmermann <tzimmermann@xxxxxxx>
Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx>
> ---
> 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
