[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZFEAfv2GnGeblk-x@hovoldconsulting.com>
Date: Tue, 2 May 2023 14:22:22 +0200
From: Johan Hovold <johan@...nel.org>
To: Bjorn Andersson <quic_bjorande@...cinc.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Vinod Koul <vkoul@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/7] arm64: dts: qcom: sc8280xp-crd: Add QMP to
SuperSpeed graph
On Mon, Apr 24, 2023 at 08:40:09PM -0700, Bjorn Andersson wrote:
> With support for the QMP combo phy to react to USB Type-C switch events,
> introduce it as the next hop for the SuperSpeed lanes of the two USB
> Type-C connectors, and connect the output of the DisplayPort controller
> to the QMP combo phy.
>
> This allows the TCPM to perform orientation switching of both USB and
> DisplayPort signals.
>
> Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
> ---
> arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 28 ++++++++++++++++---
> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 34 +++++++++++++++++++++++
> 2 files changed, 58 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
> index 547277924ea3..33c973661fa5 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-crd.dts
> @@ -64,7 +64,7 @@ port@1 {
> reg = <1>;
>
> pmic_glink_con0_ss: endpoint {
> - remote-endpoint = <&mdss0_dp0_out>;
> + remote-endpoint = <&usb_0_qmpphy_out>;
> };
> };
>
> @@ -99,7 +99,7 @@ port@1 {
> reg = <1>;
>
> pmic_glink_con1_ss: endpoint {
> - remote-endpoint = <&mdss0_dp1_out>;
> + remote-endpoint = <&usb_1_qmpphy_out>;
> };
> };
>
> @@ -412,7 +412,7 @@ &mdss0_dp0 {
>
> &mdss0_dp0_out {
> data-lanes = <0 1>;
> - remote-endpoint = <&pmic_glink_con0_ss>;
> + remote-endpoint = <&usb_0_qmpphy_dp_in>;
> };
It's a bit hard to follow what going on when using place holder nodes
from the dtsi like this (instead of describing all the ports directly in
the board dts). IIRC we went a bit back and forth over this earlier and
we already use this scheme for the display port controllers, so I guess
this is the price we pay for being consistent.
> &mdss0_dp1 {
> @@ -421,7 +421,7 @@ &mdss0_dp1 {
>
> &mdss0_dp1_out {
> data-lanes = <0 1>;
> - remote-endpoint = <&pmic_glink_con1_ss>;
> + remote-endpoint = <&usb_1_qmpphy_dp_in>;
> };
>
> &mdss0_dp3 {
> @@ -670,9 +670,19 @@ &usb_0_qmpphy {
> vdda-phy-supply = <&vreg_l9d>;
> vdda-pll-supply = <&vreg_l4d>;
>
> + orientation-switch;
> +
> status = "okay";
> };
>
> +&usb_0_qmpphy_dp_in {
> + remote-endpoint = <&mdss0_dp0_out>;
> +};
> +
> +&usb_0_qmpphy_out {
> + remote-endpoint = <&pmic_glink_con0_ss>;
> +};
> +
> &usb_0_role_switch {
> remote-endpoint = <&pmic_glink_con0_hs>;
> };
> @@ -697,9 +707,19 @@ &usb_1_qmpphy {
> vdda-phy-supply = <&vreg_l4b>;
> vdda-pll-supply = <&vreg_l3b>;
>
> + orientation-switch;
> +
> status = "okay";
> };
>
> +&usb_1_qmpphy_dp_in {
> + remote-endpoint = <&mdss0_dp1_out>;
> +};
> +
> +&usb_1_qmpphy_out {
> + remote-endpoint = <&pmic_glink_con1_ss>;
> +};
> +
> &usb_1_role_switch {
> remote-endpoint = <&pmic_glink_con1_hs>;
> };
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index 0e691bb0120c..1eb3a295e8fa 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> @@ -3006,6 +3006,23 @@ usb_0_qmpphy: phy@...b000 {
> #phy-cells = <1>;
>
> status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + usb_0_qmpphy_out: endpoint {};
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + usb_0_qmpphy_dp_in: endpoint {};
> + };
> + };
> };
The binding describes three ports, where dp-in is port 2.
Perhaps you don't need to describe ss-in yet, but shouldn't the port
numbers match? Should some of these be described as required in the
binding?
Johan
Powered by blists - more mailing lists