On 10/09/2025 01:52, Sebastian Reichel wrote:

Hi,

On Sun, Sep 07, 2025 at 12:34:24AM +0300, Dmitry Baryshkov wrote:

quoted

On Sat, Sep 06, 2025 at 10:42:22PM +0200, Sebastian Reichel wrote:

quoted

On Sat, Sep 06, 2025 at 10:24:54PM +0300, Dmitry Baryshkov wrote:

quoted

On Thu, Sep 04, 2025 at 08:26:02PM +0200, Sebastian Reichel wrote:

quoted

Currently the Rockchip USBDP PHY as a very simply port scheme: It just
offers a single port, which is supposed to point towards the connector.
Usually with 2 endpoints, one for the USB-C superspeed port and one for
the USB-C SBU port.

This scheme is not good enough to properly handle DP AltMode, so add
a new scheme, which has separate ports for everything. This has been
modelled after the Qualcomm QMP USB4-USB3-DP PHY controller binding
with a slight difference that there is an additional port for the
USB-C SBU port as the Rockchip USB-DP PHY also contains the mux.

Signed-off-by: Sebastian Reichel <redacted>
---
  .../bindings/phy/phy-rockchip-usbdp.yaml           | 23 ++++++++++++++++++++++
  1 file changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
index 8b7059d5b1826fdec5170cf78d6e27f2bd6766bb..f728acf057e4046a4d254ee687af3451f17bcd01 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml

@@ -114,6 +114,29 @@ properties:
        A port node to link the PHY to a TypeC controller for the purpose of
        handling orientation switching.
  
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description:
+          Output endpoint of the PHY for USB (or DP when configured into 4 lane
+          mode), which should point to the superspeed port of a USB connector.

What abourt USB+DP mode, where each one gets 2 lanes?

Right, I guess we would need one port more and have one port for
lane 0 + 1 and one port for 1 + 2. For USB-C both ports are
connected to the USB-C superspeed port. For DP 4-lane mode the
same is done for the input port of the connector. Last but not
least for 2 lanes USB + 2 lanes DP, one port can be connected
to the USB connector and one port can be connected to the DP
connector.

Hmm. I'm not sure what do you mean here. Basically, it should be:

- Normal USB-C case with DP AltMode:
   + port@0 routed to connector's port@1 (through mux or retimer if any)
   + port@4 routed to connector's port@2 (through mux or retimer if any)

- Actual DP or mini-DP connector:
   + port@0 routed to connector's sole port (most likely direcrly)
   + port@4 most likely unconnected (at least for now, dp-connector
     doesn't have AUX lines described)

- Weird mode of having both USB-A or -C and actual DisplayPort
   + port@0 should get two endpoints, each having data-lines properties,
     one endpoint being connected to the USB port, another endpoint being
     connected to DP connector.
   + port@4 unconnected (yep, we should extend DP properties, maybe I'll
     send a patch)

That's a bit different from what I described, but sounds more
sensible. Effectively the Rockchip USBDP PHY binding would need
to deprecate rockchip,dp-lane-mux and switch to using data-lines
on the endpoint instead, just like it is currently proposed for
Qualcomm (I follow the T14S HDMI thread).

AFAIK the Rockchip PHY hardware does not support 1-lane DP, so the
binding will have to forbid that. Shouldn't be a problem, though :)

quoted

I'd say, the first two options are the most important ones. Unless you
have actual hardware that uses the USB + separate DP, I'd say, we can
ignore that part.

The RK3588 evaluation board routes the first two lanes to a USB-A
connector and the second two lanes + AUX to a RTD2166 bridge, which
converts it to VGA and then terminates on a VGA connector. I have
that on my desk and can do some tests. But I don't have enough time
for preparing patches right now - especially since the RTD2166 is
not yet supported upstream.

Greetings,

-- Sebastian

quoted

quoted

quoted

quoted

+      port@1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Incoming endpoint from the USB controller
+
+      port@2:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: Incoming endpoint from the DisplayPort controller
+
+      port@3:
+        $ref: /schemas/graph.yaml#/properties/port
+        description:
+          Output endpoint of the PHY for DP, which should either point to the
+          SBU port of a USB-C connector or a DisplayPort connector input port.

I would suggest describing this port as 'DisplayPort AUX signals to be
connected to the SBU port of a USB-C connector (maybe through the
additinal mux, switch or retimer)'. It should not be confused with the
actual DisplayPort signals (as those go through the port@0).

This is the use-case we're trying to support aswell on the Radxa Dragon Q6A.

Neil

quoted

quoted

quoted

In the Qualcomm world we currently do not describe this link from the
PHY to the gpio-mux or retimer, but I think we will have to do that
soon.

It does looks like no upstream platform does a proper description of
USB-C setups :(

Thanks for having a look,

-- Sebastian

quoted

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

-- 
With best wishes
Dmitry