The KMS framework uses two slightly different definitions for the state
concept. For a given object (plane, CRTC, encoder, etc., so
drm_$OBJECT_state), the state is the entire state of that object.
However, at the device level, drm_atomic_state refers to a state update
for a limited number of objects.
Thus, drm_atomic_state isn't the entire device state, but only the full
state of some objects in that device. This has been an endless source of
confusion and thus bugs.
We can rename the drm_atomic_state structure to drm_atomic_commit to
make it less confusing.
This patch was created using:
rg -l drm_atomic_state | \
xargs sed -i 's/drm_atomic_state/drm_atomic_commit/g; s/drm_atomic_commit_helper/drm_atomic_state_helper/g'
mv drivers/gpu/drm/tests/drm_atomic_state_test.c drivers/gpu/drm/tests/drm_atomic_commit_test.c
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260427-drm-drm-atomic-update-v4-1-c0e713bfdf25@kernel.org
Pull more drm fixes from Dave Airlie:
"These are the regular fixes that have built up over last couple of
weeks, all pretty minor and spread all over.
atomic:
- raise the vblank timeout to avoid it on virtual drivers
- fix colorop duplication
bridge:
- stm_lvds: state check fix
- dw-mipi-dsi: bridge reference leak fix
panel:
- visionx-rm69299: init fix
dma-fence:
- fix sparse warning
dma-buf:
- UAF fix
panthor:
- mapping fix
arcgpu:
- device_node reference leak fix
nouveau:
- memory leak in error path fix
- overflow in reloc path for old hw fix
hv:
- Kconfig fix
v3d:
- infinite loop fix"
* tag 'drm-fixes-2026-04-24' of https://gitlab.freedesktop.org/drm/kernel:
drm/nouveau: fix u32 overflow in pushbuf reloc bounds check
MAINTAINERS: split hisilicon maintenance and add Yongbang Shi for hibmc-drm matainers
drm/v3d: Reject empty multisync extension to prevent infinite loop
drm/panel: visionox-rm69299: Make use of prepare_prev_first
drm/drm_atomic: duplicate colorop states if plane color pipeline in use
drm/nouveau: fix nvkm_device leak on aperture removal failure
hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS
dma-fence: Silence sparse warning in dma_fence_describe
drm/bridge: dw-mipi-dsi: Fix bridge leak when host attach fails
drm/arcpgu: fix device node leak
drm/panthor: Fix outdated function documentation
drm/panthor: Extend VM locked region for remap case to be a superset
dma-buf: fix UAF in dma_buf_put() tracepoint
drm/bridge: stm_lvds: Do not fail atomic_check on disabled connector
drm/atomic: Increase timeout in drm_atomic_helper_wait_for_vblanks()
For suspend/resume to work correctly, do for colorop state the same we
do for plane/crtc/connector states: duplicate the state of colorops in a
color pipeline if it's in use by a given plane when suspending and
restore cached colorop states when resuming. While at it, prevent
unused-variable warning when using for_each_new_colorop_in_stage here.
Fixes: 2afc3184f3 ("drm/plane: Add COLOR PIPELINE property")
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
Link: https://patch.msgid.link/20260318163629.300627-1-mwen@igalia.com
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
The drm_private_obj initialization was inconsistent with the rest of the
KMS objects. Indeed, it required to pass a preallocated state in
drm_private_obj_init(), while all the others objects would have a reset
callback that would be called later on to create the state.
However, reset really is meant to reset the hardware and software state.
That it creates an initial state is a side-effect that has been used in
all objects but drm_private_obj. This is made more complex since some
drm_private_obj, the DisplayPort ones in particular, need to be
persistent across and suspend/resume cycle, and such a cycle would call
drm_mode_config_reset().
Thus, we need to add a new callback to allocate a pristine state for a
given private object.
This discussion has also came up during the atomic state readout
discussion, so it might be introduced into the other objects later on.
Until all drivers are converted to that new allocation pattern, we will
only call it if the passed state is NULL. This will be removed
eventually.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-2-90891fa3d3b0@redhat.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The state pointer found in the struct drm_atomic_state internals for
most object is a bit ambiguous, and confusing when those internals also
have old state and new state.
After the recent cleanups, the state pointer only use is to point to the
state we need to free when destroying the atomic state.
We can thus rename it something less ambiguous, and hopefully more
meaningful.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20251008-drm-rename-state-v2-1-49b490b2676a@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The __drm_atomic_get_current_plane_state() function tries to get and
return the existing plane state, and if it doesn't exist returns the one
stored in the drm_plane->state field.
Using the current nomenclature, it tries to get the existing plane state
with an ad-hoc implementation of drm_atomic_get_existing_plane_state(),
and falls back to either the old or new plane state, depending on
whether it is called before or after drm_atomic_helper_swap_state().
The existing plane state itself is deprecated, because it also changes
when swapping states from the new state to the old state.
Fortunately for us, we can simplify things. Indeed,
__drm_atomic_get_current_plane_state() is only used in two macros:
intel_atomic_crtc_state_for_each_plane_state and
drm_atomic_crtc_state_for_each_plane_state().
The intel variant is only used through the intel_wm_compute() function
that is only ever called in intel_crtc_atomic_check().
The generic variant is more widely used, and can be found in the malidp,
msm, tegra and vc4 drivers. All of these call sites though are during
atomic_check(), so we end up in the same situation than Intel's.
Thus, we only ever use the existing state as the new state, and
plane->state is always going to be the old state. Any plane isn't
guaranteed to be part of the state though, so we can't rely on
drm_atomic_get_old_plane_state() and we still need to use plane->state.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250930-drm-no-more-existing-state-v5-4-eeb9e1287907@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
With the bridges switching over to drm_bridge_connector, the direct
association between a bridge driver and its connector was lost.
This is mitigated for atomic bridge drivers by the fact you can access
the encoder, and then call drm_atomic_get_old_connector_for_encoder() or
drm_atomic_get_new_connector_for_encoder() with drm_atomic_state.
This was also made easier by providing drm_atomic_state directly to all
atomic hooks bridges can implement.
However, bridge drivers don't have a way to access drm_atomic_state
outside of the modeset path, like from the hotplug interrupt path or any
interrupt handler.
Let's introduce a function to retrieve the connector currently assigned
to an encoder, without using drm_atomic_state, to make these drivers'
life easier.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Tested-by: Herve Codina <herve.codina@bootlin.com>
Co-developed-by: Simona Vetter <simona.vetter@intel.com>
Signed-off-by: Simona Vetter <simona.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-4-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Maxime RipardandDave Airlie
Linus Torvalds
Melissa WenandMelissa Wen
Jani Nikula
Alex HungandSimon Ser
Harry WentlandandSimon Ser
Ville Syrjälä
Simona Vetter