[PATCH RFC 0/2] arm64: dts: rockchip: add USB-C DP AltMode for ROCK 5B family

[PATCH RFC 0/2] arm64: dts: rockchip: add USB-C DP AltMode for ROCK 5B family

[Sebastian Reichel]

People started to become impatient regarding USB-C DP AltMode support on
the RK3588 platform now that the DP controller support has been merged.

I'm sending this as RFC for now, because

1. I'm not sure if the binding change for rockchip-usbdp is considered
   an ABI break. As far as I can see the Linux drivers don't need any
   changes and combinations of kernel and DT should work. At some point
   the kernel might rely on the new binding for some features, though.

2. I've noticed USB-C DP AltMode only seems to work when the cable is
   plugged after the system has been booted. My guess is that there
   are some issues with the Rockchip USBDP PHY driver, but I didn't
   have the time to track this down properly.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
Sebastian Reichel (2):
      dt-bindings: phy: rockchip-usbdp: add improved ports scheme
      arm64: dts: rockchip: add USB-C DP AltMode for ROCK 5B family

 .../bindings/phy/phy-rockchip-usbdp.yaml           | 23 ++++++
 .../boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi   | 83 +++++++++++++++++++---
 2 files changed, 95 insertions(+), 11 deletions(-)
---
base-commit: 6cc18e940db6731556843b7fa2924eb2efcef53f
change-id: 20250904-rock5b-dp-alt-mode-dcff20e80b0d

Best regards,
-- 
Sebastian Reichel <sebastian.reichel@collabora.com>


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

[Sebastian Reichel]

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 <sebastian.reichel@collabora.com>
---
 .../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.
+
+      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.
+
 required:
   - compatible
   - reg

-- 
2.50.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

[Dmitry Baryshkov]

On Thu, Sep 04, 2025 at 08:26:02PM +0200, Sebastian Reichel wrote:
> 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 <sebastian.reichel@collabora.com>
> ---
>  .../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?

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

> +
>  required:
>    - compatible
>    - reg
> 
> -- 
> 2.50.1
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

-- 
With best wishes
Dmitry

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

[Sebastian Reichel]

[-- Attachment #1.1: Type: text/plain, Size: 3531 bytes --]

Hi,

On Sat, Sep 06, 2025 at 10:24:54PM +0300, Dmitry Baryshkov wrote:
> On Thu, Sep 04, 2025 at 08:26:02PM +0200, Sebastian Reichel wrote:
> > 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 <sebastian.reichel@collabora.com>
> > ---
> >  .../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.

> > +      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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 112 bytes --]

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

[Dmitry Baryshkov]

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:
> > On Thu, Sep 04, 2025 at 08:26:02PM +0200, Sebastian Reichel wrote:
> > > 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 <sebastian.reichel@collabora.com>
> > > ---
> > >  .../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.

> 
> > > +      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

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

[Sebastian Reichel]

Hi,

On Sun, Sep 07, 2025 at 12:34:24AM +0300, Dmitry Baryshkov wrote:
> On Sat, Sep 06, 2025 at 10:42:22PM +0200, Sebastian Reichel wrote:
> > On Sat, Sep 06, 2025 at 10:24:54PM +0300, Dmitry Baryshkov wrote:
> > > On Thu, Sep 04, 2025 at 08:26:02PM +0200, Sebastian Reichel wrote:
> > > > 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 <sebastian.reichel@collabora.com>
> > > > ---
> > > >  .../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 :)

> 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

> > > > +      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

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

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

[Neil Armstrong]

On 10/09/2025 01:52, Sebastian Reichel wrote:
> Hi,
> 
> On Sun, Sep 07, 2025 at 12:34:24AM +0300, Dmitry Baryshkov wrote:
>> On Sat, Sep 06, 2025 at 10:42:22PM +0200, Sebastian Reichel wrote:
>>> On Sat, Sep 06, 2025 at 10:24:54PM +0300, Dmitry Baryshkov wrote:
>>>> On Thu, Sep 04, 2025 at 08:26:02PM +0200, Sebastian Reichel wrote:
>>>>> 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 <sebastian.reichel@collabora.com>
>>>>> ---
>>>>>   .../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 :)
> 
>> 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
> 
>>>>> +      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

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


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH RFC 2/2] arm64: dts: rockchip: add USB-C DP AltMode for ROCK 5B family

[Sebastian Reichel]

Enable support for USB-C DP AltMode to the ROCK 5B/5B+/5T.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
 .../boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi   | 83 +++++++++++++++++++---
 1 file changed, 72 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
index 3bbe78810ec6f279a36d51d2fcef4a0f3f53036b..1e284dc48bd3fc2009f5f261e116bf8dbb96d7bd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi
@@ -177,6 +177,22 @@ &cpu_l3 {
 	cpu-supply = <&vdd_cpu_lit_s0>;
 };
 
+&dp0 {
+	status = "okay";
+};
+
+&dp0_in {
+	dp0_in_vp2: endpoint {
+		remote-endpoint = <&vp2_out_dp0>;
+	};
+};
+
+&dp0_out {
+	dp0_out_con: endpoint {
+		remote-endpoint = <&usbdp_phy0_dp_in>;
+	};
+};
+
 &gpu {
 	mali-supply = <&vdd_gpu_s0>;
 	status = "okay";
@@ -352,21 +368,21 @@ ports {
 				port@0 {
 					reg = <0>;
 					usbc0_hs: endpoint {
-						remote-endpoint = <&usb_host0_xhci_to_usbc0>;
+						remote-endpoint = <&usb_host0_xhci_hs>;
 					};
 				};
 
 				port@1 {
 					reg = <1>;
 					usbc0_ss: endpoint {
-						remote-endpoint = <&usbdp_phy0_ss>;
+						remote-endpoint = <&usbdp_phy0_ss_out>;
 					};
 				};
 
 				port@2 {
 					reg = <2>;
 					usbc0_sbu: endpoint {
-						remote-endpoint = <&usbdp_phy0_sbu>;
+						remote-endpoint = <&usbdp_phy0_dp_out>;
 					};
 				};
 			};
@@ -993,18 +1009,41 @@ &usbdp_phy0 {
 	orientation-switch;
 	status = "okay";
 
-	port {
+	ports {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		usbdp_phy0_ss: endpoint@0 {
+
+		port@0 {
 			reg = <0>;
-			remote-endpoint = <&usbc0_ss>;
+
+			usbdp_phy0_ss_out: endpoint {
+				remote-endpoint = <&usbc0_ss>;
+			};
 		};
 
-		usbdp_phy0_sbu: endpoint@1 {
+		port@1 {
 			reg = <1>;
-			remote-endpoint = <&usbc0_sbu>;
+
+			usbdp_phy0_ss_in: endpoint {
+				remote-endpoint = <&usb_host0_xhci_ss>;
+			};
+		};
+
+		port@2 {
+			reg = <2>;
+
+			usbdp_phy0_dp_in: endpoint {
+				remote-endpoint = <&dp0_out_con>;
+			};
+		};
+
+		port@3 {
+			reg = <3>;
+
+			usbdp_phy0_dp_out: endpoint {
+				remote-endpoint = <&usbc0_sbu>;
+			};
 		};
 	};
 };
@@ -1025,9 +1064,24 @@ &usb_host0_xhci {
 	usb-role-switch;
 	status = "okay";
 
-	port {
-		usb_host0_xhci_to_usbc0: endpoint {
-			remote-endpoint = <&usbc0_hs>;
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			reg = <0>;
+
+			usb_host0_xhci_hs: endpoint {
+				remote-endpoint = <&usbc0_hs>;
+			};
+		};
+
+		port@1 {
+			reg = <1>;
+
+			usb_host0_xhci_ss: endpoint {
+				remote-endpoint = <&usbdp_phy0_ss_in>;
+			};
 		};
 	};
 };
@@ -1066,3 +1120,10 @@ vp1_out_hdmi1: endpoint@ROCKCHIP_VOP2_EP_HDMI1 {
 		remote-endpoint = <&hdmi1_in_vp1>;
 	};
 };
+
+&vp2 {
+	vp2_out_dp0: endpoint@a {
+		reg = <ROCKCHIP_VOP2_EP_DP0>;
+		remote-endpoint = <&dp0_in_vp2>;
+	};
+};

-- 
2.50.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy