[PATCH 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms

[Sebastian Reichel]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20260331/ac91de68/attachment-0001.sig>