linux.git/drivers/gpu/drm/drm_encoder.c, branch master

drm/encoder: drm_encoder_cleanup: lock the encoder chain mutex during removal

2026-04-16T07:08:42+00:00

drm_encoder_cleanup() modifies the encoder chain by removing bridges via drm_bridge_detach(). Protect this whole operation by taking the mutex, so that: * any users iterating over the chain will not access it during the change * other code willing to modify the list (drm_bridge_attach()) will wait until drm_encoder_cleanup() is done Note that the _safe macro in use here is providing a different and orthogonal kind of protection than the mutex: 1. list_for_each_entry_safe() allows removing the current entry from the list it is iterating on, synchronously; the non-safe version would be unable to find the next entry after the current entry has been removed 2. the mutex being added allows to ensure that the list is not used asynchronously by other code while it is being modified; this prevents such other concurrent code to derail because it is iterating over an element while it is removed The _safe macro, which works by taking the "next" pointer in addition to the "current" one, does not even try to provide the protection at item 2 above. This is visible e.g. when the "next" element is removed by other concurrent code. This is what would happen without the added mutex: 1. start loop: list_for_each_entry_safe(pos, n, ...) sets: pos = list_first_entry() = (bridge 1) n = list_next_entry(pos) = (bridge 2) 2. enter the loop 1st time, do something with *pos (bridge 1) 3. in the meanwhile bridge 2 is hot-unplugged -> another thread removes bridge 2 -> drm_bridge_detach() -> list_del() sets (bridge 2)->next = LIST_POISON1 4. loop iteration 1 finishes, list_for_each_entry_safe() sets: pos = n (previously set to bridge 2) n = (bridge 2)->next = LIST_POISON1 5. enter the loop 2nd time, do something with *pos (bridge 2) 6. loop iteration 2 finishes, list_for_each_entry_safe() sets: pos = n = LIST_POISON1 ==> bug! However, simply adding mutex_[un]lock(&encoder->bridge_chain_mutex) before/after the list_for_each_entry_safe() seems a simple and good solution, but it is introducing a possible ABBA deadlock (found by PROVE_LOCKING). The two code paths involved are: * drm_encoder_cleanup(): - takes the bridge_chain_mutex (A) - calls drm_bridge_detach -> drm_atomic_private_obj_fini -> DRM_MODESET_LOCK_ALL_BEGIN() which takes all locks in the acquisition context (B) * drm_mode_getconnector() (and other code paths): - calls drm_helper_probe_single_connector_modes() which: - takes a drm_modeset_lock in the acquisition context (B) - calls __drm_helper_update_and_validate -> drm_bridge_chain_mode_valid -> drm_for_each_bridge_in_chain_from() which takes the bridge_chain_mutex (A) To avoid this potential ABBA deadlock, move all list items to a temporary list while holding the bridge_chain_mutex, then detach all elements from the temporary list without the mutex. Reviewed-by: Louis Chauvet Link: https://patch.msgid.link/20260324-drm-bridge-alloc-encoder-chain-mutex-v5-2-8bf786c5c7e6@bootlin.com Signed-off-by: Luca Ceresoli

drm/encoder: add mutex to protect the bridge chain

2026-04-16T07:08:42+00:00

The per-encoder bridge chain is currently assumed to be static once it is fully initialized. Work is in progress to add hot-pluggable bridges, breaking that assumption. With bridge removal, the encoder chain can change without notice, removing tail bridges. This can be problematic while iterating over the chain. Add a mutex to be taken whenever looping or changing the encoder chain. Reviewed-by: Maxime Ripard Reviewed-by: Louis Chauvet Link: https://patch.msgid.link/20260324-drm-bridge-alloc-encoder-chain-mutex-v5-1-8bf786c5c7e6@bootlin.com Signed-off-by: Luca Ceresoli

drm/encoder: register per-encoder debugfs dir

2023-12-04T14:07:29+00:00

Each of connectors and CRTCs used by the DRM device provides debugfs directory, which is used by several standard debugfs files and can further be extended by the driver. Add such generic debugfs directories for encoder. Reviewed-by: Neil Armstrong Acked-by: Maxime Ripard Signed-off-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20231203115315.1306124-2-dmitry.baryshkov@linaro.org

drm/encoder: Introduce drmm_encoder_init

2022-07-13T08:46:05+00:00

The DRM-managed function to register an encoder is drmm_encoder_alloc() and its variants, which will allocate the underlying structure and initialisation the encoder. However, we might want to separate the structure creation and the encoder initialisation, for example if the structure is shared across multiple DRM entities, for example an encoder and a connector. Let's create an helper to only initialise an encoder that would be passed as an argument. Acked-by: Thomas Zimmermann Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220711173939.1132294-4-maxime@cerno.tech

drm: use ENOMEM for drmm_kzalloc allocation failures

2022-05-25T15:39:49+00:00

Other callers of drmm_kzalloc already return -ENOMEM on allocation failure. Change EINVAL to ENOMEM for consistency. Signed-off-by: Niels Dossche Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220521234104.88410-1-dossche.niels@gmail.com

drm: add drmm_encoder_alloc()

2021-01-04T11:59:33+00:00

Add an alternative to drm_encoder_init() that allocates and initializes an encoder and registers drm_encoder_cleanup() with drmm_add_action_or_reset(). Signed-off-by: Philipp Zabel Reviewed-by: Laurent Pinchart Reviewed-by: Daniel Vetter

drm/encoder: make encoder control functions optional

2021-01-04T11:59:33+00:00

Simple managed encoders do not require the .destroy callback, make the whole funcs structure optional. Signed-off-by: Philipp Zabel Reviewed-by: Laurent Pinchart Reviewed-by: Daniel Vetter

drm/bridge: Make the bridge chain a double-linked list

2019-12-09T09:03:01+00:00

So that each element in the chain can easily access its predecessor. This will be needed to support bus format negotiation between elements of the bridge chain. Signed-off-by: Boris Brezillon Reviewed-by: Neil Armstrong Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-5-boris.brezillon@collabora.com

drm: Stop accessing encoder->bridge directly

2019-12-09T09:02:45+00:00

We are about to replace the single-linked bridge list by a double-linked one based on list.h, leading to the suppression of the encoder->bridge field. But before we can do that we must provide a drm_bridge_chain_get_first_bridge() bridge helper and patch all drivers and core helpers to use it instead of directly accessing encoder->bridge. Note that we still have 2 drivers (VC4 and Exynos) manipulating the encoder->bridge field directly because they need to cut the bridge chain in order to control the enable/disable sequence. This is definitely not something we want to encourage, so let's keep those 2 oddities around until we find a better solution. Signed-off-by: Boris Brezillon Reviewed-by: Laurent Pinchart Reviewed-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-4-boris.brezillon@collabora.com

drm/bridge: Introduce drm_bridge_get_next_bridge()

2019-12-09T09:02:22+00:00

And use it in drivers accessing the bridge->next field directly. This is part of our attempt to make the bridge chain a double-linked list based on the generic list helpers. Signed-off-by: Boris Brezillon Reviewed-by: Neil Armstrong Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-3-boris.brezillon@collabora.com