kernel/linux.git/include/drm/drm_bridge.h, branch v7.1-rc5

drm/display: hdmi: Use drm_output_color_format instead of hdmi_colorspace

2026-03-24T12:54:35+00:00

The hdmi_colorspace enum was defined to represent the colorspace value of the HDMI infoframes. It was later used by some HDMI drivers to express the output format they should be setting up. During the introduction of the HDMI helpers, it then was used to represent it in the drm_connector_hdmi_state structure. However, it's always been somewhat redundant with the DRM_COLOR_FORMAT_* defines, and now with the drm_output_color_format enum. Let's consolidate around drm_output_color_format in drm_connector_hdmi_state to facilitate the current effort to provide a global output format selection mechanism. Acked-by: Jani Nikula Reviewed-by: Nicolas Frattaroli Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-14-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard

drm/bridge: add drm_bridge_clear_and_put()

2026-03-20T10:02:12+00:00

Drivers having a struct drm_bridge pointer pointing to a bridge in many cases hold that reference until the owning device is removed. In those cases the reference to the bridge can be put in the .remove callback (possibly using devm actions) or in the .destroy func (possibly with the help of struct drm_bridge::next_bridge). At those moments the driver should not be operating anymore and won't dereference the bridge pointer after it is put. However there are cases when drivers need to stop holding a reference to a bridge even when their device is not being removed. This is the case for bridge hot-unplug, when a bridge is removed but the previous entity (bridge or encoder) is staying. In such case the "previous entity" needs to put it but cannot do it via devm or .destroy, because it is not being removed. The easy way to dispose of such pointer is: drm_bridge_put(my_priv->some_bridge); my_priv->some_bridge = NULL; However this is risky because there is a time window between the two lines where the reference is put, and thus the bridge could be deallocated, but the pointer is still assigned. If other functions of the same driver were invoked concurrently they might dereference my_priv->some_bridge during that window, resulting in use-after-free. A correct solution is to clear the pointer before putting the reference, but that needs a temporary variable: struct drm_bridge *temp = my_priv->some_bridge; my_priv->some_bridge = NULL; drm_bridge_put(temp); This solution is however annoying to write, so the incorrect version might still sneak in. Add a simple, easy to use function to put a bridge after setting its pointer to NULL in the correct way. Acked-by: Maxime Ripard Link: https://patch.msgid.link/20260310-drm-bridge-atomic-vs-remove-clear_and_put-v2-1-51fe222f3cf0@bootlin.com Signed-off-by: Luca Ceresoli

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