From: "Luca Weiss" <luca.weiss@fairphone.com> To: "Bjorn Andersson" <andersson@kernel.org>, "Neil Armstrong" <neil.armstrong@linaro.org> Cc: "Konrad Dybcio" <konrad.dybcio@linaro.org>, "Vinod Koul" <vkoul@kernel.org>, "Kishon Vijay Abraham I" <kishon@kernel.org>, "Rob Herring" <robh@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Conor Dooley" <conor+dt@kernel.org>, "Abhinav Kumar" <quic_abhinavk@quicinc.com>, <linux-arm-msm@vger.kernel.org>, <linux-phy@lists.infradead.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode Date: Mon, 18 Mar 2024 11:45:57 +0100 [thread overview] Message-ID: <CZWTD7P4CE12.1ZUNPF2WFTBHR@fairphone.com> (raw) In-Reply-To: <liah4xvkfattlen7s2zi3vt2bl5pbbxqgig3k5ljqpveoao656@iacnommxkjkt> On Sat Mar 16, 2024 at 5:01 PM CET, Bjorn Andersson wrote: > On Fri, Mar 15, 2024 at 06:35:15PM +0100, Neil Armstrong wrote: > > On 15/03/2024 18:19, Luca Weiss wrote: > > > On Thu Feb 29, 2024 at 2:07 PM CET, Neil Armstrong wrote: > > > > Register a typec mux in order to change the PHY mode on the Type-C > > > > mux events depending on the mode and the svid when in Altmode setup. > > > > > > > > The DisplayPort phy should be left enabled if is still powered on > > > > by the DRM DisplayPort controller, so bail out until the DisplayPort > > > > PHY is not powered off. > > > > > > > > The Type-C Mode/SVID only changes on plug/unplug, and USB SAFE states > > > > will be set in between of USB-Only, Combo and DisplayPort Only so > > > > this will leave enough time to the DRM DisplayPort controller to > > > > turn of the DisplayPort PHY. > > > > > > > > The patchset also includes bindings changes and DT changes. > > > > > > > > This has been successfully tested on an SM8550 board, but the > > > > Thinkpad X13s deserved testing between non-PD USB, non-PD DisplayPort, > > > > PD USB Hubs and PD Altmode Dongles to make sure the switch works > > > > as expected. > > > > > > > > The DisplayPort 4 lanes setup can be check with: > > > > $ cat /sys/kernel/debug/dri/ae01000.display-controller/DP-1/dp_debug > > > > name = msm_dp > > > > drm_dp_link > > > > rate = 540000 > > > > num_lanes = 4 > > > > > > Hi Neil, > > > > > > I tried this on QCM6490/SC7280 which should also support 4-lane DP but I > > > haven't had any success so far. > > > > [..] > > > [ 1775.563969] [drm:dp_ctrl_link_train] *ERROR* max v_level reached > > > [ 1775.564031] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11 > > > > Interesting #1 means the 4 lanes are not physically connected to the other side, > > perhaps QCM6490/SC7280 requires a specific way to enable the 4 lanes in the PHY, > > or some fixups in the init tables. > > > > I tested the same on rb3gen2 (qcs6490) a couple of weeks ago, with the > same outcome. Looking at the AUX reads, after switching to 4-lane the > link training is failing on all 4 lanes, in contrast to succeeding only > on the first 2 if you e.g. forget to mux the other two. Good to know it's not just my device then ;) > > As such, my expectation is that there's something wrong in the QMP PHY > (or possibly redriver) for this platform. Since I imagine rb3gen2 uses a different redriver setup compared to FP5, I wouldn't say that's at fault for now? And at least my ptn36502 driver only has very little difference between 2-lane and 4-lane setup, only setting the mode to DP-only and 4-lane (vs USB+DP and 2-lane), nothing else. Regards Luca > > Regards, > Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: "Luca Weiss" <luca.weiss@fairphone.com> To: "Bjorn Andersson" <andersson@kernel.org>, "Neil Armstrong" <neil.armstrong@linaro.org> Cc: "Konrad Dybcio" <konrad.dybcio@linaro.org>, "Vinod Koul" <vkoul@kernel.org>, "Kishon Vijay Abraham I" <kishon@kernel.org>, "Rob Herring" <robh@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Conor Dooley" <conor+dt@kernel.org>, "Abhinav Kumar" <quic_abhinavk@quicinc.com>, <linux-arm-msm@vger.kernel.org>, <linux-phy@lists.infradead.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode Date: Mon, 18 Mar 2024 11:45:57 +0100 [thread overview] Message-ID: <CZWTD7P4CE12.1ZUNPF2WFTBHR@fairphone.com> (raw) In-Reply-To: <liah4xvkfattlen7s2zi3vt2bl5pbbxqgig3k5ljqpveoao656@iacnommxkjkt> On Sat Mar 16, 2024 at 5:01 PM CET, Bjorn Andersson wrote: > On Fri, Mar 15, 2024 at 06:35:15PM +0100, Neil Armstrong wrote: > > On 15/03/2024 18:19, Luca Weiss wrote: > > > On Thu Feb 29, 2024 at 2:07 PM CET, Neil Armstrong wrote: > > > > Register a typec mux in order to change the PHY mode on the Type-C > > > > mux events depending on the mode and the svid when in Altmode setup. > > > > > > > > The DisplayPort phy should be left enabled if is still powered on > > > > by the DRM DisplayPort controller, so bail out until the DisplayPort > > > > PHY is not powered off. > > > > > > > > The Type-C Mode/SVID only changes on plug/unplug, and USB SAFE states > > > > will be set in between of USB-Only, Combo and DisplayPort Only so > > > > this will leave enough time to the DRM DisplayPort controller to > > > > turn of the DisplayPort PHY. > > > > > > > > The patchset also includes bindings changes and DT changes. > > > > > > > > This has been successfully tested on an SM8550 board, but the > > > > Thinkpad X13s deserved testing between non-PD USB, non-PD DisplayPort, > > > > PD USB Hubs and PD Altmode Dongles to make sure the switch works > > > > as expected. > > > > > > > > The DisplayPort 4 lanes setup can be check with: > > > > $ cat /sys/kernel/debug/dri/ae01000.display-controller/DP-1/dp_debug > > > > name = msm_dp > > > > drm_dp_link > > > > rate = 540000 > > > > num_lanes = 4 > > > > > > Hi Neil, > > > > > > I tried this on QCM6490/SC7280 which should also support 4-lane DP but I > > > haven't had any success so far. > > > > [..] > > > [ 1775.563969] [drm:dp_ctrl_link_train] *ERROR* max v_level reached > > > [ 1775.564031] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11 > > > > Interesting #1 means the 4 lanes are not physically connected to the other side, > > perhaps QCM6490/SC7280 requires a specific way to enable the 4 lanes in the PHY, > > or some fixups in the init tables. > > > > I tested the same on rb3gen2 (qcs6490) a couple of weeks ago, with the > same outcome. Looking at the AUX reads, after switching to 4-lane the > link training is failing on all 4 lanes, in contrast to succeeding only > on the first 2 if you e.g. forget to mux the other two. Good to know it's not just my device then ;) > > As such, my expectation is that there's something wrong in the QMP PHY > (or possibly redriver) for this platform. Since I imagine rb3gen2 uses a different redriver setup compared to FP5, I wouldn't say that's at fault for now? And at least my ptn36502 driver only has very little difference between 2-lane and 4-lane setup, only setting the mode to DP-only and 4-lane (vs USB+DP and 2-lane), nothing else. Regards Luca > > Regards, > Bjorn -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2024-03-18 10:46 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-29 13:07 [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode Neil Armstrong 2024-02-29 13:07 ` Neil Armstrong 2024-02-29 13:07 ` [PATCH RFT 1/7] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp: Add mode-switch Neil Armstrong 2024-02-29 13:07 ` Neil Armstrong 2024-03-04 16:22 ` Rob Herring 2024-03-04 16:22 ` Rob Herring 2024-02-29 13:07 ` [PATCH RFT 2/7] phy: qcom: qmp-combo: store DP phy power state Neil Armstrong 2024-02-29 13:07 ` Neil Armstrong 2024-02-29 13:07 ` [PATCH RFT 3/7] phy: qcom: qmp-combo: introduce QPHY_MODE Neil Armstrong 2024-02-29 13:07 ` Neil Armstrong 2024-03-29 16:56 ` Vinod Koul 2024-03-29 16:56 ` Vinod Koul 2024-02-29 13:07 ` [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE Neil Armstrong 2024-02-29 13:07 ` Neil Armstrong 2024-02-29 15:25 ` Dmitry Baryshkov 2024-02-29 15:25 ` Dmitry Baryshkov 2024-02-29 15:47 ` Neil Armstrong 2024-02-29 15:47 ` Neil Armstrong 2024-02-29 15:54 ` Dmitry Baryshkov 2024-02-29 15:54 ` Dmitry Baryshkov 2024-02-29 15:57 ` neil.armstrong 2024-02-29 15:57 ` neil.armstrong 2024-02-29 13:07 ` [PATCH RFT 5/7] arm64: dts: qcom-sm8550: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch Neil Armstrong 2024-02-29 13:07 ` Neil Armstrong 2024-02-29 13:07 ` [PATCH RFT 6/7] arm64: dts: qcom-sm8650: " Neil Armstrong 2024-02-29 13:07 ` Neil Armstrong 2024-02-29 13:07 ` [PATCH RFT 7/7] arm64: dts: qcom-mode-switch: " Neil Armstrong 2024-02-29 13:07 ` Neil Armstrong 2024-02-29 13:11 ` Neil Armstrong 2024-02-29 13:11 ` Neil Armstrong 2024-03-01 3:00 ` Bjorn Andersson 2024-03-01 3:00 ` Bjorn Andersson 2024-03-01 18:31 ` Neil Armstrong 2024-03-01 18:31 ` Neil Armstrong 2024-03-15 17:19 ` [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode Luca Weiss 2024-03-15 17:19 ` Luca Weiss 2024-03-15 17:35 ` Neil Armstrong 2024-03-15 17:35 ` Neil Armstrong 2024-03-16 16:01 ` Bjorn Andersson 2024-03-16 16:01 ` Bjorn Andersson 2024-03-18 10:45 ` Luca Weiss [this message] 2024-03-18 10:45 ` Luca Weiss 2024-03-26 21:02 ` Konrad Dybcio 2024-03-26 21:02 ` Konrad Dybcio 2024-03-29 9:02 ` Luca Weiss 2024-03-29 9:02 ` Luca Weiss 2024-04-05 8:08 ` Neil Armstrong 2024-04-05 8:08 ` Neil Armstrong 2024-04-05 10:19 ` Luca Weiss 2024-04-05 10:19 ` Luca Weiss 2024-04-23 13:03 ` Konrad Dybcio 2024-04-23 13:03 ` Konrad Dybcio 2024-04-23 14:08 ` neil.armstrong 2024-04-23 14:08 ` neil.armstrong 2024-05-10 6:51 ` Luca Weiss 2024-05-10 6:51 ` Luca Weiss
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CZWTD7P4CE12.1ZUNPF2WFTBHR@fairphone.com \ --to=luca.weiss@fairphone.com \ --cc=andersson@kernel.org \ --cc=conor+dt@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=kishon@kernel.org \ --cc=konrad.dybcio@linaro.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-phy@lists.infradead.org \ --cc=neil.armstrong@linaro.org \ --cc=quic_abhinavk@quicinc.com \ --cc=robh@kernel.org \ --cc=vkoul@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.