Unverified Commit 37c476d6 authored by Randy Dunlap's avatar Randy Dunlap Committed by Maxime Ripard
Browse files

drm/drm_modeset_helper_vtables.h: fix typos/spellos



Fix spelling problems as identified by codespell.

Signed-off-by: default avatarRandy 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: default avatarJani Nikula <jani.nikula@intel.com>
Signed-off-by: default avatarMaxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213043226.10046-1-rdunlap@infradead.org
parent c4c5391a
Loading
Loading
Loading
Loading
+3 −3
Original line number Diff line number Diff line
@@ -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.