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

[Chaoyi Chen]

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