On Tue, 12 Dec 2023, Randy Dunlap <rdun...@infradead.org> wrote: > Fix spelling problems as 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/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