.../bindings/display/rockchip/rockchip,dw-dp.yaml | 5 +- drivers/gpu/drm/bridge/synopsys/dw-dp.c | 284 ++++++++++++++++++++- drivers/gpu/drm/display/drm_bridge_connector.c | 6 + drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 167 +++++++++++- include/drm/bridge/dw_dp.h | 6 + include/drm/drm_bridge.h | 14 + 6 files changed, 469 insertions(+), 13 deletions(-)
This patch series updates the Synopsys Designware DisplayPort bridge
together with the only existing user: The Rockchip RK3576/RK3588:
1. follow-up bridges (PHY, USB-C connector)
this is needed to get USB-C DP AltMode working; I've followed the
Qualcomm driver as reference
2. runtime PM
the initial driver has been upstreamed without RPM; add it to
avoid wasting power when nothing is plugged
3. audio
the initial driver has been upstreamed without audio support;
this adds all missing bits for audio with single stream transport
The series is based on drm-misc-next with Cristian's cleanup series
applied as I expect that to land first:
https://lore.kernel.org/linux-rockchip/20260310-drm-rk-fixes-v2-0-645ecfb43f49@collabora.com/
To properly make use of the bridge code the following USBDP PHY series
is also needed:
https://lore.kernel.org/linux-rockchip/20260313-rockchip-usbdp-cleanup-v3-0-3e8fe89a35b5@collabora.com/
There are two parts, which possibly need some discussion:
1. I added a dedicated bridge callback for out-of-band hotplug events,
which is separate from the hotplug_notify. I have a feeling, that
there might be a better solution, but haven't found it.
2. The DT binding for audio support - explicitly marked as RFC - works
perfectly fine, but is not ready for MST. I don't intend to
implement that right now, but the binding should obviously take it
into consideration to avoid breaking it in the future. I've put
some points for discussion into the relevant patch.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
Sebastian Reichel (10):
drm/bridge: synopsys: dw-dp: Simplify driver data setting
drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED
drm/bridge: synopsys: dw-dp: Add follow-up bridge support
drm/bridge: Add out-of-band HPD notify handler
drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD
drm/rockchip: dw_dp: Implement out-of-band HPD handling
drm/bridge: synopsys: dw-dp: Add Runtime PM support
drm/rockchip: dw_dp: Add runtime PM support
[RFC] dt-bindings: display: rockchip: dw-dp: fix sound DAI cells
drm/bridge: synopsys: dw-dp: Add audio support
.../bindings/display/rockchip/rockchip,dw-dp.yaml | 5 +-
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 284 ++++++++++++++++++++-
drivers/gpu/drm/display/drm_bridge_connector.c | 6 +
drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 167 +++++++++++-
include/drm/bridge/dw_dp.h | 6 +
include/drm/drm_bridge.h | 14 +
6 files changed, 469 insertions(+), 13 deletions(-)
---
base-commit: 0660ee19141e5e90b422b7daa0d8518a8d0d898b
change-id: 20260325-synopsys-dw-dp-improvements-7da2e98df1dd
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
Hello Sebastian, On 3/27/2026 1:31 AM, Sebastian Reichel wrote: > This patch series updates the Synopsys Designware DisplayPort bridge > together with the only existing user: The Rockchip RK3576/RK3588: > > 1. follow-up bridges (PHY, USB-C connector) > this is needed to get USB-C DP AltMode working; I've followed the > Qualcomm driver as reference > > 2. runtime PM > the initial driver has been upstreamed without RPM; add it to > avoid wasting power when nothing is plugged > > 3. audio > the initial driver has been upstreamed without audio support; > this adds all missing bits for audio with single stream transport > > The series is based on drm-misc-next with Cristian's cleanup series > applied as I expect that to land first: > > https://lore.kernel.org/linux-rockchip/20260310-drm-rk-fixes-v2-0-645ecfb43f49@collabora.com/ > > To properly make use of the bridge code the following USBDP PHY series > is also needed: > > https://lore.kernel.org/linux-rockchip/20260313-rockchip-usbdp-cleanup-v3-0-3e8fe89a35b5@collabora.com/ > > There are two parts, which possibly need some discussion: > > 1. I added a dedicated bridge callback for out-of-band hotplug events, > which is separate from the hotplug_notify. I have a feeling, that > there might be a better solution, but haven't found it. > Could you explain what an out-of-band hotplug event is? Can't the drivers/usb/typec/altmodes/displayport.c respond to these hot-plug events? Thank you. > 2. The DT binding for audio support - explicitly marked as RFC - works > perfectly fine, but is not ready for MST. I don't intend to > implement that right now, but the binding should obviously take it > into consideration to avoid breaking it in the future. I've put > some points for discussion into the relevant patch. > > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> > --- > Sebastian Reichel (10): > drm/bridge: synopsys: dw-dp: Simplify driver data setting > drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED > drm/bridge: synopsys: dw-dp: Add follow-up bridge support > drm/bridge: Add out-of-band HPD notify handler > drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD > drm/rockchip: dw_dp: Implement out-of-band HPD handling > drm/bridge: synopsys: dw-dp: Add Runtime PM support > drm/rockchip: dw_dp: Add runtime PM support > [RFC] dt-bindings: display: rockchip: dw-dp: fix sound DAI cells > drm/bridge: synopsys: dw-dp: Add audio support > > .../bindings/display/rockchip/rockchip,dw-dp.yaml | 5 +- > drivers/gpu/drm/bridge/synopsys/dw-dp.c | 284 ++++++++++++++++++++- > drivers/gpu/drm/display/drm_bridge_connector.c | 6 + > drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 167 +++++++++++- > include/drm/bridge/dw_dp.h | 6 + > include/drm/drm_bridge.h | 14 + > 6 files changed, 469 insertions(+), 13 deletions(-) > --- > base-commit: 0660ee19141e5e90b422b7daa0d8518a8d0d898b > change-id: 20260325-synopsys-dw-dp-improvements-7da2e98df1dd > > Best regards, -- Best, Chaoyi
Hello Chaoyi, On Mon, Mar 30, 2026 at 09:34:15AM +0800, Chaoyi Chen wrote: > > There are two parts, which possibly need some discussion: > > > > 1. I added a dedicated bridge callback for out-of-band hotplug events, > > which is separate from the hotplug_notify. I have a feeling, that > > there might be a better solution, but haven't found it. > > Could you explain what an out-of-band hotplug event is? > > Can't the drivers/usb/typec/altmodes/displayport.c respond to these > hot-plug events? Thank you. That is what generates the out-of-band hotplug event in the first place via drm_connector_oob_hotplug_event(). The oob in that call means out of band. If you look at that function it calls oob_hotplug_event() callback on the DRM connector, which is then implemented by drm_bridge_connector_oob_hotplug_event(). This function calls uses the normal hpd handling (shared by in-band and out-of-band) and I'm patching it, so that the bridges are aware of hpd explicitly being provided out-of-band. Greetings, -- Sebastian
Hello Sebastian, On 3/30/2026 7:50 PM, Sebastian Reichel wrote: > Hello Chaoyi, > > On Mon, Mar 30, 2026 at 09:34:15AM +0800, Chaoyi Chen wrote: >>> There are two parts, which possibly need some discussion: >>> >>> 1. I added a dedicated bridge callback for out-of-band hotplug events, >>> which is separate from the hotplug_notify. I have a feeling, that >>> there might be a better solution, but haven't found it. >> >> Could you explain what an out-of-band hotplug event is? >> >> Can't the drivers/usb/typec/altmodes/displayport.c respond to these >> hot-plug events? Thank you. > > That is what generates the out-of-band hotplug event in the first > place via drm_connector_oob_hotplug_event(). The oob in that call > means out of band. > > If you look at that function it calls oob_hotplug_event() callback > on the DRM connector, which is then implemented by > drm_bridge_connector_oob_hotplug_event(). This function calls uses > the normal hpd handling (shared by in-band and out-of-band) and I'm > patching it, so that the bridges are aware of hpd explicitly being > provided out-of-band. > Ah, I'm actually more concerned with the specific types of events. For example, the "explicitly" provided HPD you mentioned here. Isn't drm_connector_oob_hotplug_event able to provide those? I assume you’re looking for an oob event that is propagated along the bridge chain, rather than at the connector. Is that so? Thank you. > Greetings, > > -- Sebastian -- Best, Chaoyi
Hi, On Tue, Mar 31, 2026 at 09:18:32AM +0800, Chaoyi Chen wrote: > On 3/30/2026 7:50 PM, Sebastian Reichel wrote: > > On Mon, Mar 30, 2026 at 09:34:15AM +0800, Chaoyi Chen wrote: > >>> There are two parts, which possibly need some discussion: > >>> > >>> 1. I added a dedicated bridge callback for out-of-band hotplug events, > >>> which is separate from the hotplug_notify. I have a feeling, that > >>> there might be a better solution, but haven't found it. > >> > >> Could you explain what an out-of-band hotplug event is? > >> > >> Can't the drivers/usb/typec/altmodes/displayport.c respond to these > >> hot-plug events? Thank you. > > > > That is what generates the out-of-band hotplug event in the first > > place via drm_connector_oob_hotplug_event(). The oob in that call > > means out of band. > > > > If you look at that function it calls oob_hotplug_event() callback > > on the DRM connector, which is then implemented by > > drm_bridge_connector_oob_hotplug_event(). This function calls uses > > the normal hpd handling (shared by in-band and out-of-band) and I'm > > patching it, so that the bridges are aware of hpd explicitly being > > provided out-of-band. > > > > Ah, I'm actually more concerned with the specific types of events. > For example, the "explicitly" provided HPD you mentioned here. > Isn't drm_connector_oob_hotplug_event able to provide those? > > I assume you’re looking for an oob event that is propagated along the > bridge chain, rather than at the connector. Is that so? Thank you. The connector has a dedicated hotplug oob event callback, but I obviously need the event on the bridge, since the DP controller is implemented as bridge. The existing infrastructure propages it down to the bridge chain via drm_bridge_hpd_notify(), which can be received by the DP controller via the .hpd_notify callback in struct drm_bridge_funcs. The problem is, that this receives events for in-band AND out-of-band hotplug events. That's why I added a new bridge callback, which hooks into the existing framework, but only delivers out-of-band events and no in-band events. The problem with receiving in-band in addition to out-of-band is that the out-of-band signal should set the hotplug pin accordingly, but the in-band detection also checks the actual DP link. If the OOB hotplug signal says "nothing plugged", the hotplug pin should be forced off, but if the DP link detection fails, the hotplug pin should not be force disabled, as that makes any further detection tries useless. Greetings, -- Sebastian
Hello Sebastian,
On 3/31/2026 10:09 AM, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Mar 31, 2026 at 09:18:32AM +0800, Chaoyi Chen wrote:
>> On 3/30/2026 7:50 PM, Sebastian Reichel wrote:
>>> On Mon, Mar 30, 2026 at 09:34:15AM +0800, Chaoyi Chen wrote:
>>>>> There are two parts, which possibly need some discussion:
>>>>>
>>>>> 1. I added a dedicated bridge callback for out-of-band hotplug events,
>>>>> which is separate from the hotplug_notify. I have a feeling, that
>>>>> there might be a better solution, but haven't found it.
>>>>
>>>> Could you explain what an out-of-band hotplug event is?
>>>>
>>>> Can't the drivers/usb/typec/altmodes/displayport.c respond to these
>>>> hot-plug events? Thank you.
>>>
>>> That is what generates the out-of-band hotplug event in the first
>>> place via drm_connector_oob_hotplug_event(). The oob in that call
>>> means out of band.
>>>
>>> If you look at that function it calls oob_hotplug_event() callback
>>> on the DRM connector, which is then implemented by
>>> drm_bridge_connector_oob_hotplug_event(). This function calls uses
>>> the normal hpd handling (shared by in-band and out-of-band) and I'm
>>> patching it, so that the bridges are aware of hpd explicitly being
>>> provided out-of-band.
>>>
>>
>> Ah, I'm actually more concerned with the specific types of events.
>> For example, the "explicitly" provided HPD you mentioned here.
>> Isn't drm_connector_oob_hotplug_event able to provide those?
>>
>> I assume you’re looking for an oob event that is propagated along the
>> bridge chain, rather than at the connector. Is that so? Thank you.
>
> The connector has a dedicated hotplug oob event callback, but I obviously
> need the event on the bridge, since the DP controller is implemented as
> bridge. The existing infrastructure propages it down to the bridge chain
> via drm_bridge_hpd_notify(), which can be received by the DP controller
> via the .hpd_notify callback in struct drm_bridge_funcs.
>
> The problem is, that this receives events for in-band AND
> out-of-band hotplug events. That's why I added a new bridge
> callback, which hooks into the existing framework, but only delivers
> out-of-band events and no in-band events.
>
How to distinguish between in-band and out-of-band events? In your patch4:
@@ -180,6 +180,12 @@ static void drm_bridge_connector_oob_hotplug_event(struct drm_connector *connect
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
+ /* Notify all bridges in the pipeline of hotplug events. */
+ drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
+ if (bridge->funcs->oob_notify)
+ bridge->funcs->oob_notify(bridge, connector, status);
+ }
+
drm_bridge_connector_handle_hpd(bridge_connector, status);
Here, drm_bridge_connector_handle_hpd() will eventually call:
drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
if (bridge->funcs->hpd_notify)
bridge->funcs->hpd_notify(bridge, connector, status);
}
Therefore, for the bridge chain, you will call hpd_notify and
oob_notify separately.
This looks redundant, how do you distinguish between them?
> The problem with receiving in-band in addition to out-of-band is
> that the out-of-band signal should set the hotplug pin accordingly,
> but the in-band detection also checks the actual DP link. If the OOB
> hotplug signal says "nothing plugged", the hotplug pin should be
> forced off, but if the DP link detection fails, the hotplug pin
> should not be force disabled, as that makes any further detection
> tries useless.
>
--
Best,
Chaoyi
Hi,
On Tue, Mar 31, 2026 at 11:16:26AM +0800, Chaoyi Chen wrote:
> On 3/31/2026 10:09 AM, Sebastian Reichel wrote:
> > On Tue, Mar 31, 2026 at 09:18:32AM +0800, Chaoyi Chen wrote:
> >> On 3/30/2026 7:50 PM, Sebastian Reichel wrote:
> >>> On Mon, Mar 30, 2026 at 09:34:15AM +0800, Chaoyi Chen wrote:
> >>>>> There are two parts, which possibly need some discussion:
> >>>>>
> >>>>> 1. I added a dedicated bridge callback for out-of-band hotplug events,
> >>>>> which is separate from the hotplug_notify. I have a feeling, that
> >>>>> there might be a better solution, but haven't found it.
> >>>>
> >>>> Could you explain what an out-of-band hotplug event is?
> >>>>
> >>>> Can't the drivers/usb/typec/altmodes/displayport.c respond to these
> >>>> hot-plug events? Thank you.
> >>>
> >>> That is what generates the out-of-band hotplug event in the first
> >>> place via drm_connector_oob_hotplug_event(). The oob in that call
> >>> means out of band.
> >>>
> >>> If you look at that function it calls oob_hotplug_event() callback
> >>> on the DRM connector, which is then implemented by
> >>> drm_bridge_connector_oob_hotplug_event(). This function calls uses
> >>> the normal hpd handling (shared by in-band and out-of-band) and I'm
> >>> patching it, so that the bridges are aware of hpd explicitly being
> >>> provided out-of-band.
> >>>
> >>
> >> Ah, I'm actually more concerned with the specific types of events.
> >> For example, the "explicitly" provided HPD you mentioned here.
> >> Isn't drm_connector_oob_hotplug_event able to provide those?
> >>
> >> I assume you’re looking for an oob event that is propagated along the
> >> bridge chain, rather than at the connector. Is that so? Thank you.
> >
> > The connector has a dedicated hotplug oob event callback, but I obviously
> > need the event on the bridge, since the DP controller is implemented as
> > bridge. The existing infrastructure propages it down to the bridge chain
> > via drm_bridge_hpd_notify(), which can be received by the DP controller
> > via the .hpd_notify callback in struct drm_bridge_funcs.
> >
> > The problem is, that this receives events for in-band AND
> > out-of-band hotplug events. That's why I added a new bridge
> > callback, which hooks into the existing framework, but only delivers
> > out-of-band events and no in-band events.
> >
>
> How to distinguish between in-band and out-of-band events? In your patch4:
>
> @@ -180,6 +180,12 @@ static void drm_bridge_connector_oob_hotplug_event(struct drm_connector *connect
> struct drm_bridge_connector *bridge_connector =
> to_drm_bridge_connector(connector);
>
> + /* Notify all bridges in the pipeline of hotplug events. */
> + drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
> + if (bridge->funcs->oob_notify)
> + bridge->funcs->oob_notify(bridge, connector, status);
> + }
> +
this is the new handler that will only get OOB events, since it is
only called from the connector's oob hotplug event function.
> drm_bridge_connector_handle_hpd(bridge_connector, status);
this is the existing handler, which is not modified and keeps its
behaviour of receiving both hpd event types just as before.
> Here, drm_bridge_connector_handle_hpd() will eventually call:
>
> drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
> if (bridge->funcs->hpd_notify)
> bridge->funcs->hpd_notify(bridge, connector, status);
> }
>
> Therefore, for the bridge chain, you will call hpd_notify and
> oob_notify separately.
Correct, I keep existing functionality. Apparently it works for
everyone else.
> This looks redundant, how do you distinguish between them?
hpd_notify can be used in the same way as before. It is useful in
case the bridge driver does not care about the source of the hpd
event. In case of the Rockchip Synopsys DP bridge, .hpd_notify is
not bound and only .oob_notify is used, so it only receives the OOB
events. It's not necessary to receive the in-band events at all,
since those are generated by the driver itself anyways.
> > The problem with receiving in-band in addition to out-of-band is
> > that the out-of-band signal should set the hotplug pin accordingly,
> > but the in-band detection also checks the actual DP link. If the OOB
> > hotplug signal says "nothing plugged", the hotplug pin should be
> > forced off, but if the DP link detection fails, the hotplug pin
> > should not be force disabled, as that makes any further detection
> > tries useless.
Greetings,
-- Sebastian
© 2016 - 2026 Red Hat, Inc.