Re: [PATCH v3 1/2] arm64: dts: qcom: monaco: add lt8713sx bridge with displayport

[Dmitry Baryshkov]

On Mon, Mar 09, 2026 at 02:38:41PM +0530, Vishnu Saini wrote:
> On Sun, Feb 22, 2026 at 09:16:54PM +0200, Dmitry Baryshkov wrote:
> > On Sun, Feb 22, 2026 at 04:56:45AM +0530, Vishnu Saini wrote:
> > > On Sun, Dec 28, 2025 at 05:49:30PM +0200, Dmitry Baryshkov wrote:
> > > > On Sun, Dec 28, 2025 at 07:10:38PM +0530, Vishnu Saini wrote:
> > > > > Monaco-evk has LT8713sx which act as DP to 3 DP output
> > > > > converter. Edp PHY from monaco soc is connected to lt8713sx
> > > > > as input and output of lt8713sx is connected to 3 mini DP ports.
> > > > > 
> > > > > Two ports are available in mainboard and one port
> > > > > is available on Mezz board.
> > > > > 
> > > > > lt8713sx is connected to soc over i2c0 and with reset gpio
> > > > > connected to pin6 of ioexpander5.
> > > > > 
> > > > > Enable the edp nodes from monaco and enable lontium lt8713sx
> > > > > bridge node.
> > > > > 
> > > > > Co-developed-by: Prahlad Valluru <vvalluru@xxxxxxxxxxxxxxxx>
> > > > > Signed-off-by: Prahlad Valluru <vvalluru@xxxxxxxxxxxxxxxx>
> > > > > Signed-off-by: Vishnu Saini <vishnu.saini@xxxxxxxxxxxxxxxx>
> > > > > ---
> > > > >  arch/arm64/boot/dts/qcom/monaco-evk.dts | 89 +++++++++++++++++++++++++++++++++
> > > > >  arch/arm64/boot/dts/qcom/monaco.dtsi    |  6 +++
> > > > >  2 files changed, 95 insertions(+)
> > > > > 
> > > > > +
> > > > > +	status = "okay";
> > > > > +};
> > > > > +
> > > > > +&mdss_dp0_out {
> > > > > +	data-lanes = <0 1 2 3>;
> > > > > +	link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
> > > > > +	remote-endpoint = <&lt8713sx_dp_in>;
> > > > 
> > > > Does the bridge use DP signalling or does it use USB-C signalling here?
> > > > And even if it is DP signalling, it should be correctly described as
> > > > it uses signals coming from the QMP PHY. See how it's done for laptops
> > > > with DP-HDMI convertors.
> > > Yes, the LT8713SX is using native DP signalling, not USB‑C DP Alt‑Mode.
> > > The QMP DP PHY is already implicitly part of the mdss_dp0 pipeline,
> > > similar to other Qualcomm platforms where external DP bridges are connected. Because of that, I intentionally modeled the connection as:
> > > MDSS DP controller -> LT8713SX bridge
> > > This keeps the DT consistent with existing Qualcomm DP bridge descriptions, where the PHY is not represented as a separate graph endpoint unless there is external lane muxing or alternative signalling paths.
> > > If you feel strongly that the DT should explicitly model:
> > > MDSS DP controller -> QMP DP PHY → LT8713SX bridge
> > > I can update the graph accordingly. Otherwise, please let me know if documenting this more clearly in the binding or commit message would be sufficient.
> > 
> > Please check how (and why) other boards handle the similar usecase of
> > DP-to-HDMI bridges. To put it short, in your DT there is no notion that
> > it is a native DP rather than USB-C signalling.
> 
> Sorry i couldn't find any good reference for DP-HDMI bridges to check signaling. I checked these
> DP-HDMI bridges PS175, PS176, PS186, PS195, PS196, RTD2171, RTD2142, TI DP159, VM5200 but none of them 
> wire DT graph endpoints, Please let me know if there are any specific DP-HDMI bridge you are referring to.
> 
> I looked for other references where USB‑C signaling is used, in those case the datapath always involves a
> USB‑C controller/Type‑C mux/switch explicitly represented in the DT.
> For native DP signaling, the common pattern is that the DP controller output is wired directly to a
> DP connector/bridge, without any UCB‑C components in the path.

Yes. Please see qcom/x1p42100-lenovo-thinkbook-16.dts for the example.

> 
> 
> > > 
> > > > > +};
> > > > > +
> > > > > +&mdss_dp0_phy {
> > > > > +	vdda-phy-supply = <&vreg_l5a>;
> > > > > +	vdda-pll-supply = <&vreg_l4a>;
> > > > > +
> > > > > +	status = "okay";
> > > > > +};
> > > > > +
> > 
> > -- 
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry