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>
The current documentation of drm_atomic_state says that it's the "global
state object". This is confusing since, while it does contain all the
objects affected by an update and their respective states, if an object
isn't affected by this update it won't be part of it.
Thus, it's not truly a "global state", unlike object state structures
that do contain the entire state of a given object.
Reviewed-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Link: https://lore.kernel.org/r/20231214100917.277842-4-mripard@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Commits 63e83c1dba ("drm: Consolidate connector arrays in
drm_atomic_state"), b8b5342b69 ("drm: Consolidate plane arrays in
drm_atomic_state") and 5d943aa6c0 ("drm: Consolidate crtc arrays in
drm_atomic_state") moved the object pointer and their state pointer to
an intermediate structure storing both.
The CRTC commit didn't update the doc of the crtcs field to reflect
that, and the doc for the planes and connectors fields mention that they
are pointers to an array of structures with per-$OBJECT data.
The private_objs field was added later on by commit b430c27a7d ("drm:
Add driver-private objects to atomic state") reusing the same sentence
than the crtcs field, probably due to copy and paste.
While these fields are indeed pointers to an array, each item of that
array contain a pointer to the object structure affected by the update,
and its old and new state. There's no per-object data there, and there's
more than just a pointer to the objects.
Let's rephrase those fields a bit to better match the current situation.
Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://lore.kernel.org/r/20231214100917.277842-3-mripard@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Add description for parameters for
for_each_new_plane_in_state_reverse to fix warnings:
include/drm/drm_atomic.h:908: warning: Function parameter or member '__state' not described in 'for_each_new_plane_in_state_reverse'
include/drm/drm_atomic.h:908: warning: Function parameter or member 'plane' not described in 'for_each_new_plane_in_state_reverse'
include/drm/drm_atomic.h:908: warning: Function parameter or member 'new_plane_state' not described in 'for_each_new_plane_in_state_reverse'
include/drm/drm_atomic.h:908: warning: Function parameter or member '__i' not described in 'for_each_new_plane_in_state_reverse'
Fixes: a6c3c37b66 ("drm/amd/display: fix gcc set but not used warning of variable 'old_plane_state'")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
define a new macro for_each_new_plane_in_state_reverse to replace
for_each_oldnew_plane_in_state_reverse, so that the unused variable
'old_plane_state' can be removed.
Fix gcc warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:10066:26: warning:
variable ‘old_plane_state’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge, or a bridge and a connector.
The bus configuration is stored in drm_bridge_state separately for
the input and output buses, as seen from the point of view of each
bridge. The bus configuration of a bridge output is usually identical
to the configuration of the next bridge's input, but may differ if
the signals are modified between the two bridges, for instance by an
inverter on the board. The input and output configurations of a
bridge may differ if the bridge modifies the signals internally,
for instance by performing format conversion, or*modifying signals
polarities.
Bus format negotiation is automated by the core, drivers just have
to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
want to take part to this negotiation. Negotiation happens in reverse
order, starting from the last element of the chain (the one directly
connected to the display) up to the first element of the chain (the one
connected to the encoder).
During this negotiation all supported formats are tested until we find
one that works, meaning that the formats array should be in decreasing
preference order (assuming the driver has a preference order).
Note that the bus format negotiation works even if some elements in the
chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
the previous bridge element decide what to do (most of the time, bridge
drivers will pick a default bus format or extract this piece of
information from somewhere else, like a FW property).
v10:
* Add changelog to the commit message
v9:
* No changes
v8:
* Fix a test in drm_atomic_bridge_chain_select_bus_fmts() (Reported by
Jonas)
v7:
* Adapt the code to deal with the fact that not all bridges in the
chain have a bridge state
v5 -> v6:
* No changes
v4:
* Enhance the doc
* Fix typos
* Rename some parameters/fields
* Reword the commit message
v3:
* Fix the commit message (Reported by Laurent)
* Document the fact that bus formats should not be directly modified by
drivers (Suggested by Laurent)
* Document the fact that format order matters (Suggested by Laurent)
* Propagate bus flags by default
* Document the fact that drivers can tweak bus flags if needed
* Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
array (Suggested by Laurent)
* Add a drm_atomic_helper_bridge_propagate_bus_fmt()
* Mandate that bridge drivers return accurate input_fmts even if they
are known to be the first element in the bridge chain
v2:
* Rework things to support more complex use cases
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-7-boris.brezillon@collabora.com
One of the last remaining objects to not have its atomic state.
This is being motivated by our attempt to support runtime bus-format
negotiation between elements of the bridge chain.
This patch just paves the road for such a feature by adding a new
drm_bridge_state object inheriting from drm_private_obj so we can
re-use some of the existing state initialization/tracking logic.
v10:
* Add changelog to the commit message
v9:
* Clarify the fact that the bridge->atomic_reset() and
{connector,plane,crtc,...}->reset() semantics are different
* Move the drm_atomic_private_obj_init() call back to
drm_bridge_attach()
* Check the presence of ->atomic_duplicate_state instead of
->atomic_reset in drm_atomic_add_encoder_bridges()
* Fix copy&paste errors in the atomic bridge state helpers doc
* Add A-b/R-b tags
v8:
* Move bridge state helpers out of the CONFIG_DEBUGFS section
v7:
* Move helpers, struct-defs, ... to atomic helper files to avoid the
drm -> drm_kms_helper -> drm circular dep
* Stop providing default implementation for atomic state reset,
duplicate and destroy hooks (has to do with the helper/core split)
* Drop all R-b/T-b as helpers have now be moved to other places
v6:
* Made helpers private, removed doc and moved them to satisfy dependencies
* Renamed helpers to _default_
v5:
* Re-introduced the helpers from v4
v4:
* Fix the doc
* Kill default helpers (inlined)
* Fix drm_atomic_get_bridge_state() to check for an ERR_PTR()
* Add Neil's R-b
v3:
* No changes
v2:
* Use drm_for_each_bridge_in_chain()
* Rename helpers to be more consistent with the rest of the DRM API
* Improve/fix the doc
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128135514.108171-2-boris.brezillon@collabora.com
