[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aLyo4N59o4CIYm-6@umbar.lan>
Date: Sun, 7 Sep 2025 00:34:24 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Sebastian Reichel <sebastian.reichel@...labora.com>
Cc: Vinod Koul <vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
Frank Wang <frank.wang@...k-chips.com>,
Zhang Yubing <yubing.zhang@...k-chips.com>,
Andy Yan <andyshrk@....com>,
Maud Spierings <maud_spierings@...mail.com>,
linux-phy@...ts.infradead.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/2] dt-bindings: phy: rockchip-usbdp: add improved
ports scheme
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@...labora.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@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
With best wishes
Dmitry
Powered by blists - more mailing lists