Date: Fri, 10 May 2024 08:51:17 +0200
From: "Luca Weiss" <luca.weiss@...rphone.com>
To: <neil.armstrong@...aro.org>, "Konrad Dybcio" <konrad.dybcio@...aro.org>,
 "Bjorn Andersson" <andersson@...nel.org>
Cc: "Vinod Koul" <vkoul@...nel.org>, "Kishon Vijay Abraham I"
 <kishon@...nel.org>, "Rob Herring" <robh@...nel.org>, "Krzysztof Kozlowski"
 <krzysztof.kozlowski+dt@...aro.org>, "Conor Dooley" <conor+dt@...nel.org>,
 "Abhinav Kumar" <quic_abhinavk@...cinc.com>,
 <linux-arm-msm@...r.kernel.org>, <linux-phy@...ts.infradead.org>,
 <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C
 DisplayPort Altmode

On Tue Apr 23, 2024 at 4:08 PM CEST,  wrote:
> On 23/04/2024 15:03, Konrad Dybcio wrote:
> > 
> > 
> > On 4/5/24 12:19, Luca Weiss wrote:
> >> On Fri Apr 5, 2024 at 10:08 AM CEST, Neil Armstrong wrote:
> >>> Hi Luca,
> >>>
> >>> On 29/03/2024 10:02, Luca Weiss wrote:
> >>>> On Tue Mar 26, 2024 at 10:02 PM CET, Konrad Dybcio wrote:
> >>>>> On 16.03.2024 5:01 PM, 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.
> >>>>>>
> >>>>>> As such, my expectation is that there's something wrong in the QMP PHY
> >>>>>> (or possibly redriver) for this platform.
> >>>>>
> >>>>> Do we have any downstream tag where 4lane dp works? I'm willing to believe
> >>>>> the PHY story..
> >>>>
> >>>> Just tested on Fairphone 5 downstream and 4 lane appears to work there.
> >>>> This is with an USB-C to HDMI adapter that only does HDMI.
> >>>>
> >>>> FP5:/ # cat /sys/kernel/debug/drm_dp/dp_debug
> >>>>           state=0x20a5
> >>>>           link_rate=270000
> >>>>           num_lanes=4
> >>>>           resolution=2560x1440@...z
> >>>>           pclock=241500KHz
> >>>>           bpp=24
> >>>>           test_req=DP_LINK_STATUS_UPDATED
> >>>>           lane_count=4
> >>>>           bw_code=10
> >>>>           v_level=0
> >>>>           p_level=0
> >>>>
> >>>> Sources are here:
> >>>> https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-5.4/+/refs/heads/odm/rc/target/13/fp5
> >>>> And probably more importantly techpack/display:
> >>>> https://gerrit-public.fairphone.software/plugins/gitiles/platform/vendor/opensource/display-drivers/+/refs/heads/odm/rc/target/13/fp5
> >>>> Dts if useful:
> >>>> https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-extra/devicetree/+/refs/heads/kernel/13/fp5
> >>>
> >>> Could you retry with this applied ?
> >>>
> >>> https://lore.kernel.org/all/20240405000111.1450598-1-swboyd@chromium.org/
> >>
> >> Unfortunately I do not see any change with this on QCM6490 Fairphone 5
> >> and 4-lane DP.
> > 
> > Hm, could you like dump all the PHY regions up and downstream with the display
> > connected (and nothing connected) and compare them?
>
> Yes would be great, PHY regions and DP regions as well.

Hi all,

This mail is mostly a dump, maybe someone sees something interesting in
there...

With this script here I dumped the usb_1_qmpphy region, unfortunately
for mdss_dp regions the board crashed so we probably aren't allowed to
read some of the registers there. I didn't try to narrow this down
further.

https://github.com/z3ntu/dotfiles/blob/master/scripts/usr/local/bin/devmem-dump.sh

  ./devmem-dump.sh 0x88e8000 0x3000

With that out of the way, here's a first 'dump diff' between Android
(5.4 kernel) and mainline - this was with the device being plugged in to
my computer in both cases, so without DP.

$ diff --ignore-case -U0 usb_1_qmpphy_20240503_142336_android.txt usb_1_qmpphy_20240503_113953_mainline.txt
--- usb_1_qmpphy_20240503_142336_android.txt    2024-05-03 14:28:38.363607165 +0200
+++ usb_1_qmpphy_20240503_113953_mainline.txt   2024-05-03 14:32:38.923709704 +0200
@@ -5 +5 @@
-0x88E8010 - 0x00
+0x88E8010 - 0x02
@@ -21 +21 @@
-0x88E8050 - 0x00
+0x88E8050 - 0x02
@@ -37 +37 @@
-0x88E8090 - 0x00
+0x88E8090 - 0x02
@@ -53 +53 @@
-0x88E80D0 - 0x00
+0x88E80D0 - 0x02
@@ -69 +69 @@
-0x88E8110 - 0x00
+0x88E8110 - 0x02
@@ -85 +85 @@
-0x88E8150 - 0x00
+0x88E8150 - 0x02
@@ -101 +101 @@
-0x88E8190 - 0x00
+0x88E8190 - 0x02
@@ -117 +117 @@
-0x88E81D0 - 0x00
+0x88E81D0 - 0x02
@@ -1107,2 +1107,2 @@
-0x88E9148 - 0x4c
-0x88E914C - 0x48
+0x88E9148 - 0x4D
+0x88E914C - 0x3C
@@ -1236,3 +1236,3 @@
-0x88E934C - 0x12
-0x88E9350 - 0x11
-0x88E9354 - 0x11
+0x88E934C - 0x11
+0x88E9350 - 0x12
+0x88E9354 - 0x12
@@ -1268,3 +1268,3 @@
-0x88E93CC - 0x12
-0x88E93D0 - 0x11
-0x88E93D4 - 0x11
+0x88E93CC - 0x11
+0x88E93D0 - 0x12
+0x88E93D4 - 0x12
@@ -1401 +1401 @@
-0x88E95E0 - 0xef
+0x88E95E0 - 0xFF
@@ -2131 +2131 @@
-0x88EA148 - 0x4c
+0x88EA148 - 0x4D

Not quite sure what those registers are supposed to be - I didn't see
them in the driver so maybe they're not written from Linux at all?

Here trying to get which registers which offset are, by dividing them
into the different regions (COM, USB3_SERDES, TXA, RXA, DP_SERDES).

# COM start
-0x88E8010 - 0x00 => 0x10 QPHY_V3_DP_COM_TYPEC_CTRL
+0x88E8010 - 0x02
@@ -21 +21 @@
-0x88E8050 - 0x00 => 0x50
+0x88E8050 - 0x02
@@ -37 +37 @@
-0x88E8090 - 0x00 => 0x90
+0x88E8090 - 0x02
@@ -53 +53 @@
-0x88E80D0 - 0x00 => 0xd0
+0x88E80D0 - 0x02
@@ -69 +69 @@
-0x88E8110 - 0x00 => 0x110
+0x88E8110 - 0x02
@@ -85 +85 @@
-0x88E8150 - 0x00 => 0x150
+0x88E8150 - 0x02
@@ -101 +101 @@
-0x88E8190 - 0x00 => 0x190
+0x88E8190 - 0x02
@@ -117 +117 @@
-0x88E81D0 - 0x00 => 0x1d0
+0x88E81D0 - 0x02
# COM end

# USB3_SERDES start
@@ -1107,2 +1107,2 @@
-0x88E9148 - 0x4c => 0x148 QSERDES_V4_COM_RESTRIM_CODE_STATUS
-0x88E914C - 0x48 => 0x14c QSERDES_V4_COM_PLLCAL_CODE1_STATUS
+0x88E9148 - 0x4D
+0x88E914C - 0x3C
# USB3_SERDES end

# TXA start
@@ -1236,3 +1236,3 @@
-0x88E934C - 0x12 => 0x14c QSERDES_V4_TX_IDAC_STATUS_IBAR
-0x88E9350 - 0x11 => 0x150 QSERDES_V4_TX_IDAC_STATUS_Q
-0x88E9354 - 0x11 => 0x154 QSERDES_V4_TX_IDAC_STATUS_QBAR
+0x88E934C - 0x11
+0x88E9350 - 0x12
+0x88E9354 - 0x12
@@ -1268,3 +1268,3 @@
-0x88E93CC - 0x12 => 0x1cc ?
-0x88E93D0 - 0x11 => 0x1d0 ?
-0x88E93D4 - 0x11 => 0x1d4 ?
+0x88E93CC - 0x11
+0x88E93D0 - 0x12
+0x88E93D4 - 0x12
# TXA end

# RXA start
@@ -1401 +1401 @@
-0x88E95E0 - 0xef => 0x1e0 QSERDES_V4_RX_IDATA1
+0x88E95E0 - 0xFF
# RXA end

# DP_SERDES start
@@ -2131 +2131 @@
-0x88EA148 - 0x4c => 0x148 QSERDES_V4_COM_RESTRIM_CODE_STATUS
+0x88EA148 - 0x4D
# DP_SERDES end

Next, with DP 4 lane (not working on mainline but still plugged into a
screen) the diff is quite a bit bigger.

See attachments for the full files:
* usb_1_qmpphy_20240503_151052_android_4lane.txt
* usb_1_qmpphy_20240503_122443_mainline_4lane.txt 

Not attaching the diff because it's quite a lot
$ diff --ignore-case -U0 usb_1_qmpphy_20240503_151052_android_4lane.txt usb_1_qmpphy_20240503_122443_mainline_4lane.txt

Not sure this is helpful to anyone, but at least wanted to share what
I've done so far here.

Regards
Luca

>
> Neil
>
> > 
> > Konrad



View attachment "usb_1_qmpphy_20240503_151052_android_4lane.txt" of type "text/plain" (52224 bytes)

View attachment "usb_1_qmpphy_20240503_122443_mainline_4lane.txt" of type "text/plain" (52224 bytes)

Powered by blists - more mailing lists