Thread (8 messages) 8 messages, 3 authors, 2025-09-10

Re: [PATCH RFC 1/2] dt-bindings: phy: rockchip-usbdp: add improved ports scheme

From: Dmitry Baryshkov <hidden>
Date: 2025-09-06 21:34:31
Also in: linux-devicetree, linux-phy, linux-rockchip, lkml

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

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)

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.
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).

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

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

-- 
With best wishes
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help