drivers/gpu/drm/bridge/ti-sn65dsi83.c | 86 +++++++++++++++++++++++++++-------- drivers/gpu/drm/drm_bridge.c | 62 +++++++++++++++++++++++++ include/drm/drm_bridge.h | 12 +++++ 3 files changed, 140 insertions(+), 20 deletions(-)
This is a first attempt at gracefully handling the case of atomic updates
happening concurrently to physical removal of DRM bridges.
This is part of the work to support hotplug of DRM bridges. The grand plan
was discussed in [1].
Here's the work breakdown (➜ marks the current series):
1. … add refcounting to DRM bridges (struct drm_bridge)
(based on devm_drm_bridge_alloc() [0])
A. ✔ add new alloc API and refcounting (v6.16)
B. ✔ convert all bridge drivers to new API (v6.17)
C. ✔ kunit tests (v6.17)
D. ✔ add get/put to drm_bridge_add/remove() + attach/detach()
and warn on old allocation pattern (v6.17)
E. … add get/put on drm_bridge accessors
1. ✔ drm_bridge_chain_get_first_bridge(), add cleanup action (v6.18)
2. ✔ drm_bridge_get_prev_bridge() (v6.18)
3. ✔ drm_bridge_get_next_bridge() (v6.19)
4. ✔ drm_for_each_bridge_in_chain() (v6.19)
5. ✔ drm_bridge_connector_init (v6.19)
6. … protect encoder bridge chain with a mutex
7. of_drm_find_bridge
8. drm_of_find_panel_or_bridge, *_of_get_bridge
9. ✔ enforce drm_bridge_add before drm_bridge_attach (v6.19)
F. ✔ debugfs improvements
1. ✔ add top-level 'bridges' file (v6.16)
2. ✔ show refcount and list lingering bridges (v6.19)
2. ➜ handle gracefully atomic updates during bridge removal
A. ➜ Add drm_dev_enter/exit() to protect device resources
B. … protect private_obj removal from list
3. … DSI host-device driver interaction
4. ✔ removing the need for the "always-disconnected" connector
5. finish the hotplug bridge work, moving code to the core and potentially
removing the hotplug-bridge itself (this needs to be clarified as
points 1-3 are developed)
The idea was proposed by Maxime [1] and is based on the existing
drm_dev_enter/exit() already existing for the DRM device.
This small series implements the core mechanism in drm_bridge.c and uses it
in the ti-sn65dsi83 driver. This prevents usage of device resources by
various code paths that can happen concurrently to unplug of the SN65DSI8x
bridge.
[0] https://lore.kernel.org/lkml/20250206-hotplug-drm-bridge-v6-0-9d6f2c9c3058@bootlin.com/#t
[1] https://lore.kernel.org/all/20250106-vigorous-talented-viper-fa49d9@houat/
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v3:
- Call drm_bridge_remove() in drm_bridge_unplug() as suggested by Maxime
- Fix kerneldoc errors (reported here:
https://lore.kernel.org/lkml/202509271654.j3IsjsAJ-lkp@intel.com/)
- Some cleanups in patch 2
- Link to v2: https://lore.kernel.org/r/20250926-drm-bridge-atomic-vs-remove-v2-0-69f7d5ca1a92@bootlin.com
Changes in v2:
- No changes to patch 1, discussion pending
- Use devres instead of a flag in patch 2
- Link to v1: https://lore.kernel.org/r/20250808-drm-bridge-atomic-vs-remove-v1-0-a52e933b08a8@bootlin.com
---
Luca Ceresoli (2):
drm/bridge: add drm_bridge_unplug() and drm_bridge_enter/exit()
drm/bridge: ti-sn65dsi83: protect device resources on unplug
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 86 +++++++++++++++++++++++++++--------
drivers/gpu/drm/drm_bridge.c | 62 +++++++++++++++++++++++++
include/drm/drm_bridge.h | 12 +++++
3 files changed, 140 insertions(+), 20 deletions(-)
---
base-commit: 604046a2d68bf5a67f111579d749a046c3a26669
change-id: 20250808-drm-bridge-atomic-vs-remove-1d7bb202c8ef
Best regards,
--
Luca Ceresoli <luca.ceresoli@bootlin.com>
On Wed, 12 Nov 2025 17:34:33 +0100, Luca Ceresoli wrote:
> This is a first attempt at gracefully handling the case of atomic updates
> happening concurrently to physical removal of DRM bridges.
>
> This is part of the work to support hotplug of DRM bridges. The grand plan
> was discussed in [1].
>
> Here's the work breakdown (➜ marks the current series):
>
> [...]
Applied, thanks!
[1/2] drm/bridge: add drm_bridge_unplug() and drm_bridge_enter/exit()
commit: d36137085a4aa2d2f039359a0d67d9e07667f2de
[2/2] drm/bridge: ti-sn65dsi83: protect device resources on unplug
commit: d2e8d1bc840b849fc23d8812995645cc79990e7b
Best regards,
--
Luca Ceresoli <luca.ceresoli@bootlin.com>
On Wed, 12 Nov 2025 17:34:33 +0100, Luca Ceresoli wrote: > This is a first attempt at gracefully handling the case of atomic updates > happening concurrently to physical removal of DRM bridges. > > This is part of the work to support hotplug of DRM bridges. The grand plan > was discussed in [1]. > > [ ... ] Reviewed-by: Maxime Ripard <mripard@kernel.org> Thanks! Maxime
Hi Maxime, +Cc Emanuele, Francesco, João On Thu Nov 27, 2025 at 7:35 PM CET, Maxime Ripard wrote: > On Wed, 12 Nov 2025 17:34:33 +0100, Luca Ceresoli wrote: >> This is a first attempt at gracefully handling the case of atomic updates >> happening concurrently to physical removal of DRM bridges. >> >> This is part of the work to support hotplug of DRM bridges. The grand plan >> was discussed in [1]. >> >> [ ... ] > > Reviewed-by: Maxime Ripard <mripard@kernel.org> Thanks for reviewing! Two alternative patches [0][1] have been sent to address the issue with PLL_UNLOCK, and both would conflict with patch 2 of this series. So I'd keep this series on hold for a while, waiting for a decision to be taken about how the PLL_UNLOCK issue will be handled. I'll then rebase this series as needed. [0] https://lore.kernel.org/lkml/20251127-drm-ti-sn65dsi83-ignore-pll-unlock-v1-1-8a03fdf562e9@bootlin.com/ [1] https://lore.kernel.org/lkml/20251125103900.31750-1-francesco@dolcini.it/ Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Fri, Nov 28, 2025 at 09:09:17AM +0100, Luca Ceresoli wrote: > Hi Maxime, > > +Cc Emanuele, Francesco, João > > On Thu Nov 27, 2025 at 7:35 PM CET, Maxime Ripard wrote: > > On Wed, 12 Nov 2025 17:34:33 +0100, Luca Ceresoli wrote: > >> This is a first attempt at gracefully handling the case of atomic updates > >> happening concurrently to physical removal of DRM bridges. > >> > >> This is part of the work to support hotplug of DRM bridges. The grand plan > >> was discussed in [1]. > >> > >> [ ... ] > > > > Reviewed-by: Maxime Ripard <mripard@kernel.org> > > Thanks for reviewing! > > Two alternative patches [0][1] have been sent to address the issue with > PLL_UNLOCK, and both would conflict with patch 2 of this series. So I'd > keep this series on hold for a while, waiting for a decision to be taken > about how the PLL_UNLOCK issue will be handled. I'll then rebase this > series as needed. Yep, agreed. Maxime
Hello, On Fri Nov 28, 2025 at 11:07 AM CET, Maxime Ripard wrote: > On Fri, Nov 28, 2025 at 09:09:17AM +0100, Luca Ceresoli wrote: >> Hi Maxime, >> >> +Cc Emanuele, Francesco, João >> >> On Thu Nov 27, 2025 at 7:35 PM CET, Maxime Ripard wrote: >> > On Wed, 12 Nov 2025 17:34:33 +0100, Luca Ceresoli wrote: >> >> This is a first attempt at gracefully handling the case of atomic updates >> >> happening concurrently to physical removal of DRM bridges. >> >> >> >> This is part of the work to support hotplug of DRM bridges. The grand plan >> >> was discussed in [1]. >> >> >> >> [ ... ] >> > >> > Reviewed-by: Maxime Ripard <mripard@kernel.org> >> >> Thanks for reviewing! >> >> Two alternative patches [0][1] have been sent to address the issue with >> PLL_UNLOCK, and both would conflict with patch 2 of this series. So I'd >> keep this series on hold for a while, waiting for a decision to be taken >> about how the PLL_UNLOCK issue will be handled. I'll then rebase this >> series as needed. > > Yep, agreed. Turns out the patch that got applied does not conflict with this series, out of luck with the code layout. So I'm applying this one today. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
© 2016 - 2025 Red Hat, Inc.