On Tue, 12 Dec 2023, Randy Dunlap <[email protected]> wrote: > Fix spelling problems as identified by codespell. > > Signed-off-by: Randy Dunlap <[email protected]> > Cc: David Airlie <[email protected]> > Cc: Daniel Vetter <[email protected]> > Cc: Maarten Lankhorst <[email protected]> > Cc: Maxime Ripard <[email protected]> > Cc: Thomas Zimmermann <[email protected]>
Reviewed-by: Jani Nikula <[email protected]> > --- > 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
