Re: [PATCH v3 1/5] drm/bridge: Implement generic USB Type-C DP HPD bridge

[Chaoyi Chen]

Hi Sebastian, 

On 7/21/2026 10:22 AM, Chaoyi Chen wrote:
> Hi Sebastian,
> 
> On 7/21/2026 1:59 AM, Sebastian Reichel wrote:
>> Hi,
>>
>> On Fri, Jul 17, 2026 at 07:19:29PM +0200, Sebastian Reichel wrote:
>>> On Fri, Jul 17, 2026 at 03:23:19PM +0800, Chaoyi Chen wrote:
>>>> From: Chaoyi Chen <chaoyi.chen@xxxxxxxxxxxxxx>
>>>>
>>>> The HPD function of Type-C DP is implemented through
>>>> drm_connector_oob_hotplug_event(). For embedded DP, it is required
>>>> that the DRM connector fwnode corresponds to the Type-C port fwnode.
>>>>
>>>> To describe the relationship between the DP controller and the Type-C
>>>> port device, we usually using drm_bridge to build a bridge chain.
>>>>
>>>> Now several USB-C controller drivers have already implemented the DP
>>>> HPD bridge function provided by aux-hpd-bridge.c, it will build a DP
>>>> HPD bridge on USB-C connector port device.
>>>>
>>>> But this requires the USB-C controller driver to manually register the
>>>> HPD bridge. If the driver does not implement this feature, the bridge
>>>> will not be create.
>>>>
>>>> So this patch implements a generic DP HPD bridge based on
>>>> aux-hpd-bridge.c. It will monitor Type-C bus events, and when a
>>>> Type-C port device containing the DP svid is registered, it will
>>>> create an HPD bridge for it without the need for the USB-C controller
>>>> driver to implement it.
>>>>
>>>> Signed-off-by: Chaoyi Chen <chaoyi.chen@xxxxxxxxxxxxxx>
>>>> Reviewed-by: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>
>>>> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@xxxxxxxxxxxxx>
>>>> ---
>>>
>>> Reviewed-by: Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxx>
>>> Tested-by: Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxx> # ArmSom Sige5
>>>
>>> I gave this a test together with the RK3588/RK3576 USB-C DP AltMode
>>> patches I'm working on. As the fusb302 does a manual registration
>>> for the DRM bridge in its probe function, the bridge is registered
>>> twice:
>>>
>>> root@sige5 # cat /sys/kernel/debug/dri/bridges
>>> ...
>>> bridge[1]: drm_aux_hpd_bridge_funcs
>>> 	refcount: 4
>>> 	type: [10] DP
>>> 	OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector
>>> 	ops: [0x4] hpd
>>> bridge[2]: drm_aux_hpd_bridge_funcs
>>> 	refcount: 2
>>> 	type: [10] DP
>>> 	OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector
>>> 	ops: [0x4] hpd
>>> ...
>>>
>>> Apparently the USB-C DP AltMode keeps working, so this just wastes
>>> a few CPU cycles and some memory. So this can land and then we can
>>> remove the manual code from the driver as a follow-up step. I also
>>> gave that a try and things keep working. I won't send the fusb302
>>> patch for now to ensure its not applied before this patch lands.

My initial idea was to implement this in the Type-C Alt Mode driver,
so that we wouldn't need to implement HPD registration for every
individual USB connector driver.

And yes, once this patch is merged, we can remove the relevant code
from fusb302.

>>
>> The above test was done with a kernel having all config options
>> built-in (i.e. no modules). Using arm64 defconfig one ends up with
>>
>> CONFIG_DRM_AUX_HPD_TYPEC_BRIDGE=m
>>
>> But the resulting 'aux-hpd-typec-dp-bridge' module is not loaded
>> automatically resulting in missing bridge registration. Running
>> 'modprobe aux-hpd-typec-dp-bridge' manually in the booted system
>> does not work either as the TypeC controller has already been
>> registered and no new BUS_NOTIFY_ADD_DEVICE is generated.
>>
> 
> Oh, we indeed didn't consider that such a probe ordering issue exists.
> 
> The approach I came up with is to iterate through the &typec_bus after
> registering the notifier, to ensure we don't miss any events that 
> occurred prior:
> 
>  static int __init drm_aux_hpd_typec_dp_bridge_module_init(void)
>  {
>         bus_register_notifier(&typec_bus, &drm_typec_event_nb);
> -
> +       bus_for_each_dev(&typec_bus, NULL, NULL,
> +                        check_altmode_dev_and_register_hpd_bridge);
>         return 0;
>  }
> 
> 
> But I'm not sure if there are potential race conditions involved.
> Perhaps @Heikki and others have better ideas? Thanks.
> 

I tried analyzing the code, and this order ensures that it gets
registered.

I'll fix this in v4, thanks!

-- 
Best, 
Chaoyi