linux-toradex.git/include/drm/drm_bridge.h, branch v7.0-rc3

BackMerge tag 'v6.19-rc7' into drm-next

2026-01-28T02:44:28+00:00

Linux 6.19-rc7

This is needed for msm and rust trees.

Signed-off-by: Dave Airlie

drm/bridge: refactor HDMI InfoFrame callbacks

2026-01-19T11:11:46+00:00

Having only a single set of callbacks, hdmi_clear_infoframe and
hdmi_write_infoframe, bridge drivers don't have an easy way to signal to
the DRM framework, which InfoFrames are actually supported by the
hardware and by the driver and which are not. Also, it makes it
extremely easy for HDMI bridge drivers to skip implementing the
seemingly required InfoFrames (e.g. HDMI VSI). Last, but not least,
those callbacks take a single 'type' parameter, which makes it
impossible to implement support for multiple VSIs (which will be
required once we start working on HDMI Forum VSI).

Split the callbacks into a per-InfoFrame-kind pairs, letting the bridge
drivers actually signal supported features. The implementation follows
the overall drm_bridge design, where the bridge has a single
drm_bridge_funcs implementation and signals, which functions are to be
called using the drm_bridge->ops flags.

The AVI and HDMI VSI are assumed to be required for a normal HDMI
operation (with the drivers getting a drm_warn_once() stub
implementation if one is missing). The Audio InfoFrame is handled by the
existing DRM_BRIDGE_OP_HDMI_AUDIO, while the SPD and HDR DRM InfoFrames
got new drm_bridge_ops values.

Acked-by: Maxime Ripard 
Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-5-213d0d3bd490@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov

Revert "drm/atomic-helper: Re-order bridge chain pre-enable and post-disable"

2026-01-03T19:06:54+00:00

This reverts commit c9b1150a68d9362a0827609fc0dc1664c0d8bfe1.

Changing the enable/disable sequence has caused regressions on multiple
platforms: R-Car, MCDE, Rockchip. A series (see link below)  was sent to
fix these, but it was decided that it's better to revert the original
patch and change the enable/disable sequence only in the tidss driver.

Reverting this commit breaks tidss's DSI and OLDI outputs, which will be
fixed in the following commits.

Signed-off-by: Tomi Valkeinen 
Link: https://lore.kernel.org/all/20251202-mcde-drm-regression-thirdfix-v6-0-f1bffd4ec0fa%40kernel.org/
Fixes: c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
Cc: stable@vger.kernel.org # v6.17+
Reviewed-by: Aradhya Bhatia 
Reviewed-by: Maxime Ripard 
Reviewed-by: Linus Walleij 
Tested-by: Linus Walleij 
Signed-off-by: Linus Walleij 
Link: https://patch.msgid.link/20251205-drm-seq-fix-v1-1-fda68fa1b3de@ideasonboard.com

drm/bridge: add next_bridge pointer to struct drm_bridge

2025-12-30T09:11:33+00:00

Many bridge drivers store a next_bridge pointer in their private data and
use it for attach and sometimes other purposes. This is going to be risky
when bridge hot-unplug is used.

Considering this example scenario:

  1. pipeline: encoder --> bridge A --> bridge B --> bridge C
  2. encoder takes a reference to bridge B
  3. bridge B takes a next_bridge reference to bridge C
  4. encoder calls (bridge B)->b_foo(), which in turns references
     next_bridge, e.g.:

       b_foo() {
           bar(b->next_bridge);
       }

If bridges B and C are removed, bridge C can be freed but B is still
allocated because the encoder holds a reference to B. So when step 4
happens, 'b->next-bridge' would be a use-after-free.

Calling drm_bridge_put() in the B bridge .remove function does not solve
the problem as it leaves a (potentially long) risk window between B removal
and the final deallocation of B. A safe moment to put the B reference is in
__drm_bridge_free(), when the last reference has been put. This can be done
by drivers in the .destroy func. However to avoid the need for so many
drivers to implement a .destroy func, just offer a next_bridge pointer to
all bridges that is automatically put it in __drm_bridge_free(), exactly
when the .destroy func is called.

Suggested-by: Maxime Ripard 
Link: https://lore.kernel.org/all/20251201-thick-jasmine-oarfish-1eceb0@houat/
Reviewed-by: Maxime Ripard 
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli

drm/bridge: add of_drm_find_and_get_bridge()

2025-12-30T09:11:32+00:00

of_drm_find_bridge() does not increment the refcount for the returned
bridge, but that is required now. However converting it and all its users
is not realistically doable at once given the large amount of (direct and
indirect) callers and the complexity of some.

Solve this issue by creating a new of_drm_find_and_get_bridge() function
that is identical to of_drm_find_bridge() except also it takes a
reference. Then of_drm_find_bridge() will be deprecated to be eventually
removed.

Suggested-by: Maxime Ripard 
Link: https://lore.kernel.org/dri-devel/20250319-stylish-lime-mongoose-0a18ad@houat/
Reviewed-by: Maxime Ripard 
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-1-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli

drm/bridge: add connector argument to .hpd_notify callback

2025-12-24T22:22:13+00:00

Drivers might need to update DRM connector in the
drm_bridge_funcs.hpd_notify callback (e.g. it might be necessary to
update EDID before setting ELD). Add corresponding argument to the
callback.

Reviewed-by: Neil Armstrong 
Link: https://patch.msgid.link/20250803-lt9611uxc-hdmi-v1-1-cb9ce1793acf@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov

drm/bridge: add drm_bridge_unplug() and drm_bridge_enter/exit()

2025-12-11T10:28:43+00:00

To allow DRM bridges to be removable, add synchronization functions
allowing to tell when a bridge hardware has been physically unplugged and
to mark a critical section that should not be entered after that.

This is inspired by the drm_dev_unplugged/enter/exit() functions for struct
drm_device.

Suggested-by: Maxime Ripard 
Link: https://lore.kernel.org/all/20250106-vigorous-talented-viper-fa49d9@houat/
Reviewed-by: Maxime Ripard 
Link: https://patch.msgid.link/20251112-drm-bridge-atomic-vs-remove-v3-1-85db717ce094@bootlin.com
Signed-off-by: Luca Ceresoli

drm/bridge: get the bridge returned by drm_bridge_get_next_bridge()

2025-09-16T13:22:41+00:00

drm_bridge_get_next_bridge() returns a bridge pointer that the
caller could hold for a long time. Increment the refcount of the returned
bridge and document it must be put by the caller.

Reviewed-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20250801-drm-bridge-alloc-getput-drm_bridge_get_next_bridge-v2-7-888912b0be13@bootlin.com
Signed-off-by: Luca Ceresoli

drm/bridge: add drm_for_each_bridge_in_chain_from()

2025-09-16T13:02:50+00:00

Add variant of drm_for_each_bridge_in_chain_scoped() that iterates on the
encoder bridge from a given bridge until the end of the chain.

Reviewed-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20250808-drm-bridge-alloc-getput-for_each_bridge-v2-8-edb6ee81edf1@bootlin.com
Signed-off-by: Luca Ceresoli

drm/bridge: remove drm_for_each_bridge_in_chain()

2025-09-16T13:02:48+00:00

All users have been replaced by drm_for_each_bridge_in_chain_scoped().

Reviewed-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20250808-drm-bridge-alloc-getput-for_each_bridge-v2-7-edb6ee81edf1@bootlin.com
Signed-off-by: Luca Ceresoli