From: Chaoyi Chen <chaoyi.chen@rock-chips•com>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora•com>
Cc: Heikki Krogerus <heikki.krogerus@linux•intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation•org>,
Dmitry Baryshkov <dmitry.baryshkov@oss•qualcomm.com>,
Peter Chen <hzpeterchen@gmail•com>,
Luca Ceresoli <luca.ceresoli@bootlin•com>,
Rob Herring <robh@kernel•org>,
Krzysztof Kozlowski <krzk+dt@kernel•org>,
Conor Dooley <conor+dt@kernel•org>, Vinod Koul <vkoul@kernel•org>,
Kishon Vijay Abraham I <kishon@kernel•org>,
Heiko Stuebner <heiko@sntech•de>,
Sandy Huang <hjc@rock-chips•com>,
Andy Yan <andy.yan@rock-chips•com>,
Yubing Zhang <yubing.zhang@rock-chips•com>,
Frank Wang <frank.wang@rock-chips•com>,
Andrzej Hajda <andrzej.hajda@intel•com>,
Neil Armstrong <neil.armstrong@linaro•org>,
Robert Foss <rfoss@kernel•org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard•com>,
Jonas Karlman <jonas@kwiboo•se>,
Jernej Skrabec <jernej.skrabec@gmail•com>,
Maarten Lankhorst <maarten.lankhorst@linux•intel.com>,
Maxime Ripard <mripard@kernel•org>,
Thomas Zimmermann <tzimmermann@suse•de>,
David Airlie <airlied@gmail•com>, Simona Vetter <simona@ffwll•ch>,
Amit Sunil Dhamne <amitsd@google•com>,
Dragan Simic <dsimic@manjaro•org>,
Johan Jonker <jbx6244@gmail•com>,
Diederik de Haas <didi.debian@cknow•org>,
Peter Robinson <pbrobinson@gmail•com>,
Hugh Cole-Baker <sigmaris@gmail•com>,
dri-devel@lists•freedesktop.org, linux-usb@vger•kernel.org,
devicetree@vger•kernel.org, linux-kernel@vger•kernel.org,
linux-phy@lists•infradead.org,
linux-arm-kernel@lists•infradead.org,
linux-rockchip@lists•infradead.org,
Chaoyi Chen <chaoyi.chen@rock-chips•com>
Subject: Re: [PATCH v15 1/9] drm/bridge: Implement generic USB Type-C DP HPD bridge
Date: Fri, 29 May 2026 09:18:03 +0800 [thread overview]
Message-ID: <162da16e-6fec-4d47-ba67-46ec2ffa8e2f@rock-chips.com> (raw)
In-Reply-To: <q6ufdWF5QJ60i9KlIiE_AA@collabora.com>
Hello Nicolas,
On 5/28/2026 11:37 PM, Nicolas Frattaroli wrote:
> On Wednesday, 4 March 2026 10:41:44 Central European Summer Time Chaoyi Chen wrote:
>> From: Chaoyi Chen <chaoyi.chen@rock-chips•com>
>>
>> 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@rock-chips•com>
>> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux•intel.com>
>> ---
>>
>> (no changes since v14)
>>
>> Changes in v13:
>> - Only register drm dp hpd bridge for typec port altmode device.
>>
>> (no changes since v12)
>>
>> Changes in v11:
>> - Switch to using typec bus notifiers.
>>
>> (no changes since v10)
>>
>> Changes in v9:
>> - Remove the exposed DRM_AUX_HPD_BRIDGE option, and select
>> DRM_AUX_HPD_TYPEC_BRIDGE when it is available.
>> - Add more commit comment about problem background.
>>
>> Changes in v8:
>> - Merge generic DP HPD bridge into one module.
>> ---
>>
>> drivers/gpu/drm/bridge/Kconfig | 10 ++++
>> drivers/gpu/drm/bridge/Makefile | 1 +
>> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 49 +++++++++++++++++++
>> 3 files changed, 60 insertions(+)
>> create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index a250afd8d662..559487aa09a9 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -30,6 +30,16 @@ config DRM_AUX_HPD_BRIDGE
>> Simple bridge that terminates the bridge chain and provides HPD
>> support.
>>
>> +if DRM_AUX_HPD_BRIDGE
>> +config DRM_AUX_HPD_TYPEC_BRIDGE
>> + tristate
>> + depends on TYPEC || !TYPEC
>> + default TYPEC
>> + help
>> + Simple bridge that terminates the bridge chain and provides HPD
>> + support. It build bridge on each USB-C connector device node.
>> +endif
>> +
>> menu "Display Interface Bridges"
>> depends on DRM && DRM_BRIDGE
>>
>> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
>> index c7dc03182e59..a3a0393d2e72 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -1,6 +1,7 @@
>> # SPDX-License-Identifier: GPL-2.0
>> obj-$(CONFIG_DRM_AUX_BRIDGE) += aux-bridge.o
>> obj-$(CONFIG_DRM_AUX_HPD_BRIDGE) += aux-hpd-bridge.o
>> +obj-$(CONFIG_DRM_AUX_HPD_TYPEC_BRIDGE) += aux-hpd-typec-dp-bridge.o
>> obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
>> obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
>> obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
>> diff --git a/drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c b/drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>> new file mode 100644
>> index 000000000000..d915e0fb0668
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>> @@ -0,0 +1,49 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>
> Having a copyright statement added here is likely required.
> Something like
>
> /*
> * Copyright (C) 2026 Rockchip Electronics Co., Ltd.
> *
> * Author: Chaoyi Chen <chaoyi.chen@rock-chips•com>
> */
>
> will suffice. While I hope it's never relevant for a driver this
> small, explicit copyright statements in this form have a legal
> effect in some jurisdictions like the US, where by law it
> automatically dismisses the defense that the copyright holder
> wasn't known.
>
Oh! I hadn't noticed that. Thank you for your legal advice.
>> +#include <linux/of.h>
>> +#include <linux/usb/typec_altmode.h>
>> +#include <linux/usb/typec_dp.h>
>> +
>> +#include <drm/bridge/aux-bridge.h>
>> +
>> +static int drm_typec_bus_event(struct notifier_block *nb,
>> + unsigned long action, void *data)
>> +{
>> + struct device *dev = (struct device *)data;
>
> Small nitpick: The explicit (struct device *) cast of data isn't
> needed here. Just
>
> struct device *dev = data;
>
> will work fine. The benefit is that if the type of "data" ever changes
> (e.g. from void *data to const void *data) then we're not silencing
> a warning/error through an explicit cast.
>
Yep. Will fix in v2.
>> + struct typec_altmode *alt = to_typec_altmode(dev);
>> +
>> + if (action != BUS_NOTIFY_ADD_DEVICE)
>> + goto done;
>> +
>> + /*
>> + * alt->dev.parent->parent : USB-C controller device
>> + * alt->dev.parent : USB-C connector device
>> + */
>> + if (is_typec_port_altmode(&alt->dev) && alt->svid == USB_TYPEC_DP_SID)
>> + drm_dp_hpd_bridge_register(alt->dev.parent->parent,
>> + to_of_node(alt->dev.parent->fwnode));
>> +
>> +done:
>> + return NOTIFY_OK;
>> +}
>
> Nitpicking: the "done" label and "goto done" here is redundant.
> You could remove the label and replace the goto with another
> "return NOTIFY_OK;". There's no functional change here though.
>
Will fix in v2.
>> +
>> +static struct notifier_block drm_typec_event_nb = {
>> + .notifier_call = drm_typec_bus_event,
>> +};
>> +
>> +static void drm_aux_hpd_typec_dp_bridge_module_exit(void)
>> +{
>> + bus_unregister_notifier(&typec_bus, &drm_typec_event_nb);
>> +}
>> +
>> +static int __init drm_aux_hpd_typec_dp_bridge_module_init(void)
>> +{
>> + bus_register_notifier(&typec_bus, &drm_typec_event_nb);
>> +
>> + return 0;
>> +}
>> +
>> +module_init(drm_aux_hpd_typec_dp_bridge_module_init);
>> +module_exit(drm_aux_hpd_typec_dp_bridge_module_exit);
>> +
>> +MODULE_DESCRIPTION("DRM TYPEC DP HPD BRIDGE");
>> +MODULE_LICENSE("GPL");
>>
>
> Feel free to add yourself as MODULE_AUTHOR here. :)
>
> With those things changed:
>
> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora•com>
>
> Kind regards,
> Nicolas Frattaroli
>
>
>
--
Best,
Chaoyi
next prev parent reply other threads:[~2026-05-29 1:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 9:41 [PATCH v15 0/9] Add Type-C DP support for RK3399 EVB IND board Chaoyi Chen
2026-03-04 9:41 ` [PATCH v15 1/9] drm/bridge: Implement generic USB Type-C DP HPD bridge Chaoyi Chen
2026-05-28 15:37 ` Nicolas Frattaroli
2026-05-29 1:18 ` Chaoyi Chen [this message]
2026-03-04 9:41 ` [PATCH v15 2/9] drm/bridge: aux: Add drm_aux_bridge_register_from_node() Chaoyi Chen
2026-05-28 15:46 ` Nicolas Frattaroli
2026-03-04 9:41 ` [PATCH v15 3/9] dt-bindings: phy: rockchip: rk3399-typec-phy: Support mode-switch Chaoyi Chen
2026-03-04 9:41 ` [PATCH v15 4/9] phy: rockchip: phy-rockchip-typec: Add typec_mux/typec_switch support Chaoyi Chen
2026-05-28 20:16 ` Nicolas Frattaroli
2026-05-29 8:13 ` Chaoyi Chen
2026-03-04 9:41 ` [PATCH v15 5/9] phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge Chaoyi Chen
2026-03-04 9:41 ` [PATCH v15 6/9] drm/rockchip: cdn-dp: Support handle lane info without extcon Chaoyi Chen
2026-05-20 11:10 ` Heiko Stuebner
2026-03-04 9:41 ` [PATCH v15 7/9] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection Chaoyi Chen
2026-05-20 11:12 ` Heiko Stuebner
2026-03-04 9:41 ` [PATCH v15 8/9] arm64: dts: rockchip: Add missing dp_out port for RK3399 CDN-DP Chaoyi Chen
2026-03-04 9:41 ` [PATCH v15 9/9] arm64: dts: rockchip: rk3399-evb-ind: Add support for DisplayPort Chaoyi Chen
2026-05-20 11:06 ` Heiko Stuebner
2026-05-19 13:43 ` [PATCH v15 0/9] Add Type-C DP support for RK3399 EVB IND board Heikki Krogerus
2026-05-20 1:13 ` Chaoyi Chen
2026-05-20 11:03 ` Heiko Stuebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=162da16e-6fec-4d47-ba67-46ec2ffa8e2f@rock-chips.com \
--to=chaoyi.chen@rock-chips$(echo .)com \
--cc=Laurent.pinchart@ideasonboard$(echo .)com \
--cc=airlied@gmail$(echo .)com \
--cc=amitsd@google$(echo .)com \
--cc=andrzej.hajda@intel$(echo .)com \
--cc=andy.yan@rock-chips$(echo .)com \
--cc=conor+dt@kernel$(echo .)org \
--cc=devicetree@vger$(echo .)kernel.org \
--cc=didi.debian@cknow$(echo .)org \
--cc=dmitry.baryshkov@oss$(echo .)qualcomm.com \
--cc=dri-devel@lists$(echo .)freedesktop.org \
--cc=dsimic@manjaro$(echo .)org \
--cc=frank.wang@rock-chips$(echo .)com \
--cc=gregkh@linuxfoundation$(echo .)org \
--cc=heikki.krogerus@linux$(echo .)intel.com \
--cc=heiko@sntech$(echo .)de \
--cc=hjc@rock-chips$(echo .)com \
--cc=hzpeterchen@gmail$(echo .)com \
--cc=jbx6244@gmail$(echo .)com \
--cc=jernej.skrabec@gmail$(echo .)com \
--cc=jonas@kwiboo$(echo .)se \
--cc=kishon@kernel$(echo .)org \
--cc=krzk+dt@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-phy@lists$(echo .)infradead.org \
--cc=linux-rockchip@lists$(echo .)infradead.org \
--cc=linux-usb@vger$(echo .)kernel.org \
--cc=luca.ceresoli@bootlin$(echo .)com \
--cc=maarten.lankhorst@linux$(echo .)intel.com \
--cc=mripard@kernel$(echo .)org \
--cc=neil.armstrong@linaro$(echo .)org \
--cc=nicolas.frattaroli@collabora$(echo .)com \
--cc=pbrobinson@gmail$(echo .)com \
--cc=rfoss@kernel$(echo .)org \
--cc=robh@kernel$(echo .)org \
--cc=sigmaris@gmail$(echo .)com \
--cc=simona@ffwll$(echo .)ch \
--cc=tzimmermann@suse$(echo .)de \
--cc=vkoul@kernel$(echo .)org \
--cc=yubing.zhang@rock-chips$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox