linux.git/drivers/gpu/drm/bridge/adv7511, branch master

drm/bridge: adv7511: switch to of_drm_get_bridge_by_endpoint()

2026-05-19T08:57:26+00:00

This driver calls drm_of_find_panel_or_bridge() with a NULL pointer in the
@panel parameter, thus using a reduced feature set of that function.
Replace this call with the simpler of_drm_get_bridge_by_endpoint().

Since of_drm_get_bridge_by_endpoint() increases the refcount of the
returned bridge, ensure it is put on removal. To achieve this, instead of
adding an explicit drm_bridge_put(), migrate to the bridge::next_bridge
pointer which is automatically put when the bridge is eventually freed.

Tested-by: Biju Das 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Laurent Pinchart 
Link: https://patch.msgid.link/20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-8-f61c9e498b3f@bootlin.com
Signed-off-by: Luca Ceresoli

Merge drm/drm-next into drm-misc-next

2026-05-07T14:17:01+00:00

Merge drm-next to bring the drm_atomic_state renaming patch.

Signed-off-by: Maxime Ripard

drm: Rename struct drm_atomic_state to drm_atomic_commit

2026-05-04T04:05:04+00:00

The KMS framework uses two slightly different definitions for the state
concept. For a given object (plane, CRTC, encoder, etc., so
drm_$OBJECT_state), the state is the entire state of that object.
However, at the device level, drm_atomic_state refers to a state update
for a limited number of objects.

Thus, drm_atomic_state isn't the entire device state, but only the full
state of some objects in that device. This has been an endless source of
confusion and thus bugs.

We can rename the drm_atomic_state structure to drm_atomic_commit to
make it less confusing.

This patch was created using:

rg -l drm_atomic_state | \
	xargs sed -i 's/drm_atomic_state/drm_atomic_commit/g; s/drm_atomic_commit_helper/drm_atomic_state_helper/g'
mv drivers/gpu/drm/tests/drm_atomic_state_test.c drivers/gpu/drm/tests/drm_atomic_commit_test.c

Acked-by: Simona Vetter 
Acked-by: Thomas Zimmermann 
Acked-by: Jani Nikula 
Reviewed-by: Luca Ceresoli 
Tested-by: Luca Ceresoli 
Signed-off-by: Maxime Ripard 
Signed-off-by: Dave Airlie 
Link: https://patch.msgid.link/20260427-drm-drm-atomic-update-v4-1-c0e713bfdf25@kernel.org

drm/bridge: adv7511: remove now-redundant call to drm_connector_attach_encoder()

2026-04-30T08:22:52+00:00

drm_connector_attach_encoder() is now called by
drm_bridge_connector_init().

Reviewed-by: Dmitry Baryshkov 
Link: https://patch.msgid.link/20260423-drm-bridge-connector-attach_encoder-v2-3-2ae6ca69b390@bootlin.com
Signed-off-by: Luca Ceresoli

drm/bridge: adv7511: Convert to drm_output_color_format

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

Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.

The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.

The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.

Acked-by: Jani Nikula 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-5-f3935f6db579@kernel.org
Signed-off-by: Maxime Ripard

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

drm/bridge: write full Audio InfoFrame

2025-09-09T14:34:39+00:00

Instead of writing the first byte of the infoframe (and hoping that the
rest is default / zeroes), hook Audio InfoFrame support into the
write_infoframe / clear_infoframes callbacks and use
drm_atomic_helper_connector_hdmi_update_audio_infoframe() to write the
frame.

Acked-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-2-05b24459b9a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov

drm/bridge: adv7511: use update latch for AVI infoframes

2025-09-09T14:34:39+00:00

Instead of disabling and then reenabling AVI infoframe, use the
recommended way of updating it on the fly: latch current values using
the ADV7511_REG_INFOFRAME_UPDATE register.

Acked-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20250903-adv7511-audio-infoframe-v1-1-05b24459b9a4@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov

drm/bridge: adv7511: provide SPD and HDMI infoframes

2025-08-29T12:41:55+00:00

ADV75xx hardware supports sending SPD InfoFrame over the HDMI link. Also
it provides support for two generic (Spare) InfoFrames. Use those
capabilities to be able to send SPD and HDMI Vendor-Specific Infoframes.

Reviewed-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20250827-adv7511-infoframes-v1-1-f89b9690f89c@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov

drm/bridge: Pass down connector to drm bridge detect hook

2025-07-14T15:23:18+00:00

In some application scenarios, we hope to get the corresponding
connector when the bridge's detect hook is invoked.

In most cases, we can get the connector by drm_atomic_get_connector_for_encoder
if the encoder attached to the bridge is enabled, however there will
still be some scenarios where the detect hook of the bridge is called
but the corresponding encoder has not been enabled yet. For instance,
this occurs when the device is hot plug in for the first time.

Since the call to bridge's detect is initiated by the connector, passing
down the corresponding connector directly will make things simpler.

Signed-off-by: Andy Yan 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20250703125027.311109-3-andyshrk@163.com
[DB: added the chunk to the cdn-dp driver]
Signed-off-by: Dmitry Baryshkov