On 10/13/2025 10:11 AM, Dmitry Baryshkov wrote:
On Mon, Oct 13, 2025 at 09:26:06AM +0800, Chaoyi Chen wrote:
On 10/12/2025 2:52 AM, Dmitry Baryshkov wrote:
On Sat, Oct 11, 2025 at 11:32:31AM +0800, Chaoyi Chen wrote:
From: Chaoyi Chen <[email protected]>
The RK3399 has two USB/DP combo PHY and one CDN-DP controller. And
the CDN-DP can be switched to output to one of the PHYs. If both ports
are plugged into DP, DP will select the first port for output.
This patch adds support for multiple bridges, enabling users to flexibly
select the output port. For each PHY port, a separate encoder and bridge
are registered.
The change is based on the DRM AUX HPD bridge, rather than the
extcon approach. This requires the DT to correctly describe the
connections between the first bridge in bridge chain and DP
controller. For example, the bridge chain may be like this:
PHY aux birdge -> fsa4480 analog audio switch bridge ->
onnn,nb7vpq904m USB reminder bridge -> USB-C controller AUX HPD bridge
In this case, the connection relationships among the PHY aux bridge
and the DP contorller need to be described in DT.
In addition, the cdn_dp_parse_hpd_bridge_dt() will parses it and
determines whether to register one or two bridges.
Since there is only one DP controller, only one of the PHY ports can
output at a time. The key is how to switch between different PHYs,
which is handled by cdn_dp_switch_port() and cdn_dp_enable().
There are two cases:
1. Neither bridge is enabled. In this case, both bridges can
independently read the EDID, and the PHY port may switch before
reading the EDID.
2. One bridge is already enabled. In this case, other bridges are not
allowed to read the EDID. So we will try to return the cached EDID.
Since the scenario of two ports plug in at the same time is rare,
I don't have a board which support two TypeC connector to test this.
Therefore, I tested forced switching on a single PHY port, as well as
output using a fake PHY port alongside a real PHY port.
Signed-off-by: Chaoyi Chen <[email protected]>
---
+ /* One endpoint may correspond to one HPD bridge. */
+ for_each_of_graph_port_endpoint(port, dp_ep) {
+ struct device_node *phy_bridge_node __free(device_node) =
+ of_graph_get_remote_port_parent(dp_ep);
+
+ bridge = of_drm_find_bridge(phy_bridge_node);
+ if (!bridge) {
+ ret = -EPROBE_DEFER;
+ goto out;
+ }
+
+ dp->hpd_bridge_valid = true;
+ dp->hpd_bridge_list[count].bridge = bridge;
+ dp->hpd_bridge_list[count].parent = dp;
+ dp->hpd_bridge_list[count].id = count;
This looks misnamed. They are not necessarily HPD bridges. There can be
a random chain between your controller and the actual output / connector
/etc.
Yes, and more precisely, this should be `pervious_bridge_list` . Will fix in v6.
I think the typical convention is around next_bridge, not previous.
Oh, that's true. Will fix this in v6.
--
Best,
Chaoyi
