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
..
Signed-off-by: Neil Armstrong <[email protected]>
---
Neil Armstrong (7):
dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp: Add mode-switch
phy: qcom: qmp-combo: store DP phy power state
phy: qcom: qmp-combo: introduce QPHY_MODE
phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
arm64: dts: qcom-sm8550: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
arm64: dts: qcom-sm8650: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
.../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 5 +
.../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 +-
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 3 +-
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 3 +-
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 3 +-
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 168 +++++++++++++++++++--
6 files changed, 173 insertions(+), 15 deletions(-)
---
base-commit: b321c0e8ca754d8cd9f23ceba958e3ea93c6519e
change-id: 20240229-topic-sm8x50-upstream-phy-combo-typec-mux-31b5252513c9
Best regards,
--
Neil Armstrong <[email protected]>
The QMP USB3/DP Combo PHY can work in 3 modes:
- DisplayPort Only
- USB3 Only
- USB3 + DisplayPort Combo mode
In order to switch between those modes, the PHY needs to receive
Type-C events, allow marking to the phy with the mode-switch
property in order to allow the PHY to Type-C events.
Signed-off-by: Neil Armstrong <[email protected]>
---
.../devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
index 2d0d7e9e6431..49c6539b9df0 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
@@ -71,6 +71,11 @@ properties:
description:
See include/dt-bindings/phy/phy-qcom-qmp.h
+ mode-switch:
+ description:
+ Flag the PHY as possible handler of USB Type-C altmode switching
+ type: boolean
+
orientation-switch:
description:
Flag the PHY as possible handler of USB Type-C orientation switching
--
2.34.1
Introduce an enum for the QMP Combo PHY modes, use it in the
QMP commmon phy init function and default to COMBO mode.
Signed-off-by: Neil Armstrong <[email protected]>
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 41 +++++++++++++++++++++++++++----
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index 3721bbea9eae..ac5d528fd7a1 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -61,6 +61,12 @@
#define PHY_INIT_COMPLETE_TIMEOUT 10000
+enum qphy_mode {
+ QPHY_MODE_COMBO = 0,
+ QPHY_MODE_DP_ONLY,
+ QPHY_MODE_USB_ONLY,
+};
+
/* set of registers with offsets different per-PHY */
enum qphy_reg_layout {
/* PCS registers */
@@ -1491,6 +1497,7 @@ struct qmp_combo {
struct mutex phy_mutex;
int init_count;
+ enum qphy_mode init_mode;
struct phy *usb_phy;
enum phy_mode mode;
@@ -2531,12 +2538,33 @@ static int qmp_combo_com_init(struct qmp_combo *qmp, bool force)
if (qmp->orientation == TYPEC_ORIENTATION_REVERSE)
val |= SW_PORTSELECT_VAL;
writel(val, com + QPHY_V3_DP_COM_TYPEC_CTRL);
- writel(USB3_MODE | DP_MODE, com + QPHY_V3_DP_COM_PHY_MODE_CTRL);
- /* bring both QMP USB and QMP DP PHYs PCS block out of reset */
- qphy_clrbits(com, QPHY_V3_DP_COM_RESET_OVRD_CTRL,
- SW_DPPHY_RESET_MUX | SW_DPPHY_RESET |
- SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
+ switch (qmp->init_mode) {
+ case QPHY_MODE_COMBO:
+ writel(USB3_MODE | DP_MODE, com + QPHY_V3_DP_COM_PHY_MODE_CTRL);
+
+ /* bring both QMP USB and QMP DP PHYs PCS block out of reset */
+ qphy_clrbits(com, QPHY_V3_DP_COM_RESET_OVRD_CTRL,
+ SW_DPPHY_RESET_MUX | SW_DPPHY_RESET |
+ SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
+ break;
+
+ case QPHY_MODE_DP_ONLY:
+ writel(DP_MODE, com + QPHY_V3_DP_COM_PHY_MODE_CTRL);
+
+ /* bring QMP DP PHY PCS block out of reset */
+ qphy_clrbits(com, QPHY_V3_DP_COM_RESET_OVRD_CTRL,
+ SW_DPPHY_RESET_MUX | SW_DPPHY_RESET);
+ break;
+
+ case QPHY_MODE_USB_ONLY:
+ writel(USB3_MODE, com + QPHY_V3_DP_COM_PHY_MODE_CTRL);
+
+ /* bring QMP USB PHY PCS block out of reset */
+ qphy_clrbits(com, QPHY_V3_DP_COM_RESET_OVRD_CTRL,
+ SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
+ break;
+ }
qphy_clrbits(com, QPHY_V3_DP_COM_SWI_CTRL, 0x03);
qphy_clrbits(com, QPHY_V3_DP_COM_SW_RESET, SW_RESET);
@@ -3545,6 +3573,9 @@ static int qmp_combo_probe(struct platform_device *pdev)
if (ret)
goto err_node_put;
+ /* Set PHY_MODE as combo by default */
+ qmp->init_mode = QPHY_MODE_COMBO;
+
qmp->usb_phy = devm_phy_create(dev, usb_np, &qmp_combo_usb_phy_ops);
if (IS_ERR(qmp->usb_phy)) {
ret = PTR_ERR(qmp->usb_phy);
--
2.34.1
On Thu, Feb 29, 2024 at 02:07:01PM +0100, Neil Armstrong wrote:
> The QMP USB3/DP Combo PHY can work in 3 modes:
> - DisplayPort Only
> - USB3 Only
> - USB3 + DisplayPort Combo mode
>
> In order to switch between those modes, the PHY needs to receive
> Type-C events, allow marking to the phy with the mode-switch
> property in order to allow the PHY to Type-C events.
>
> Signed-off-by: Neil Armstrong <[email protected]>
> ---
> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> index 2d0d7e9e6431..49c6539b9df0 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> @@ -71,6 +71,11 @@ properties:
> description:
> See include/dt-bindings/phy/phy-qcom-qmp.h
>
> + mode-switch:
> + description:
> + Flag the PHY as possible handler of USB Type-C altmode switching
> + type: boolean
> +
Perhaps you should be including the usb-switch.yaml schema that's in
next.
> orientation-switch:
> description:
> Flag the PHY as possible handler of USB Type-C orientation switching
>
> --
> 2.34.1
>
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.
On top of your patches I added the following for my device:
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index f5bd51806819..e7be17844da1 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -712,7 +712,7 @@ &mdss_dp {
};
&mdss_dp_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_dp_qmpphy_dp_in>;
};
@@ -1344,6 +1344,7 @@ &usb_1_qmpphy {
vdda-phy-supply = <&vreg_l6b>;
vdda-pll-supply = <&vreg_l1b>;
+ mode-switch;
orientation-switch;
status = "okay";
The output of the dp_debug file shows it's trying to use 4 lanes:
name = msm_dp
drm_dp_link
rate = 540000
num_lanes = 4
capabilities = 1
dp_panel_info:
active = 0x0
back_porch = 0x0
front_porch = 0x0
sync_width = 0x0
active_low = 0x0
h_skew = 0
refresh rate = 0
pixel clock khz = 0
bpp = 0
dp_link:
test_requested = 128
num_lanes = 4
bw_code = 20
lclk = 540000000
v_level = 2
p_level = 0
But the monitor stays black and the following appears in dmesg:
(starts with plugging in a dongle, ends with unplugging it again)
[ 1773.538161] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 1773.538197] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
[ 1773.540215] xhci-hcd xhci-hcd.2.auto: hcc params 0x0230fe65 hci version 0x110 quirks 0x0000008000000010
[ 1773.540260] xhci-hcd xhci-hcd.2.auto: irq 185, io mem 0x0a600000
[ 1773.540372] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 1773.540384] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2
[ 1773.540396] xhci-hcd xhci-hcd.2.auto: Host supports USB 3.0 SuperSpeed
[ 1773.540524] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.08
[ 1773.540534] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1773.540541] usb usb1: Product: xHCI Host Controller
[ 1773.540547] usb usb1: Manufacturer: Linux 6.8.0-00058-g113103fa3b95 xhci-hcd
[ 1773.540554] usb usb1: SerialNumber: xhci-hcd.2.auto
[ 1773.540999] hub 1-0:1.0: USB hub found
[ 1773.541028] hub 1-0:1.0: 1 port detected
[ 1773.542010] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 1773.542146] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.08
[ 1773.542162] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1773.542174] usb usb2: Product: xHCI Host Controller
[ 1773.542183] usb usb2: Manufacturer: Linux 6.8.0-00058-g113103fa3b95 xhci-hcd
[ 1773.542193] usb usb2: SerialNumber: xhci-hcd.2.auto
[ 1773.543241] hub 2-0:1.0: USB hub found
[ 1773.543282] hub 2-0:1.0: 1 port detected
[ 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
[ 1775.597965] [drm:dp_display_process_hpd_high] *ERROR* failed to complete DP link training
[ 1775.598149] [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
[ 1776.632081] [drm:dp_ctrl_link_train] *ERROR* max v_level reached
[ 1776.632145] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11
[ 1776.662978] [drm:dp_display_process_hpd_high] *ERROR* failed to complete DP link training
[ 1776.663039] [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
[ 1777.717501] [drm:dp_ctrl_link_train] *ERROR* max v_level reached
[ 1777.717524] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11
[ 1777.751427] [drm:dp_display_process_hpd_high] *ERROR* failed to complete DP link training
[ 1777.751518] [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
[ 1778.793550] [drm:dp_ctrl_link_train] *ERROR* max v_level reached
[ 1778.793617] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11
[ 1778.827260] [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
[ 1778.827334] [drm:dp_display_process_hpd_high] *ERROR* failed to complete DP link training
[ 1779.279889] xhci-hcd xhci-hcd.2.auto: remove, state 1
[ 1779.279942] usb usb2: USB disconnect, device number 1
[ 1779.311920] xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered
[ 1779.311987] xhci-hcd xhci-hcd.2.auto: remove, state 4
[ 1779.312019] usb usb1: USB disconnect, device number 1
[ 1779.317772] xhci-hcd xhci-hcd.2.auto: USB bus 1 deregistered
Regards
Luca
> ...
>
> Signed-off-by: Neil Armstrong <[email protected]>
> ---
> Neil Armstrong (7):
> dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp: Add mode-switch
> phy: qcom: qmp-combo: store DP phy power state
> phy: qcom: qmp-combo: introduce QPHY_MODE
> phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
> arm64: dts: qcom-sm8550: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
> arm64: dts: qcom-sm8650: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
> arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
>
> .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 5 +
> .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 +-
> arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 3 +-
> arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 3 +-
> arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 3 +-
> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 168 +++++++++++++++++++--
> 6 files changed, 173 insertions(+), 15 deletions(-)
> ---
> base-commit: b321c0e8ca754d8cd9f23ceba958e3ea93c6519e
> change-id: 20240229-topic-sm8x50-upstream-phy-combo-typec-mux-31b5252513c9
>
> Best regards,
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.
>
> On top of your patches I added the following for my device:
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index f5bd51806819..e7be17844da1 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -712,7 +712,7 @@ &mdss_dp {
> };
>
> &mdss_dp_out {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
> remote-endpoint = <&usb_dp_qmpphy_dp_in>;
> };
>
> @@ -1344,6 +1344,7 @@ &usb_1_qmpphy {
> vdda-phy-supply = <&vreg_l6b>;
> vdda-pll-supply = <&vreg_l1b>;
>
> + mode-switch;
> orientation-switch;
>
> status = "okay";
>
>
> The output of the dp_debug file shows it's trying to use 4 lanes:
>
> name = msm_dp
> drm_dp_link
> rate = 540000
> num_lanes = 4
> capabilities = 1
> dp_panel_info:
> active = 0x0
> back_porch = 0x0
> front_porch = 0x0
> sync_width = 0x0
> active_low = 0x0
> h_skew = 0
> refresh rate = 0
> pixel clock khz = 0
> bpp = 0
> dp_link:
> test_requested = 128
> num_lanes = 4
> bw_code = 20
> lclk = 540000000
> v_level = 2
> p_level = 0
>
> But the monitor stays black and the following appears in dmesg:
> (starts with plugging in a dongle, ends with unplugging it again)
>
> [ 1773.538161] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
> [ 1773.538197] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
> [ 1773.540215] xhci-hcd xhci-hcd.2.auto: hcc params 0x0230fe65 hci version 0x110 quirks 0x0000008000000010
> [ 1773.540260] xhci-hcd xhci-hcd.2.auto: irq 185, io mem 0x0a600000
> [ 1773.540372] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
> [ 1773.540384] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2
> [ 1773.540396] xhci-hcd xhci-hcd.2.auto: Host supports USB 3.0 SuperSpeed
> [ 1773.540524] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.08
> [ 1773.540534] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [ 1773.540541] usb usb1: Product: xHCI Host Controller
> [ 1773.540547] usb usb1: Manufacturer: Linux 6.8.0-00058-g113103fa3b95 xhci-hcd
> [ 1773.540554] usb usb1: SerialNumber: xhci-hcd.2.auto
> [ 1773.540999] hub 1-0:1.0: USB hub found
> [ 1773.541028] hub 1-0:1.0: 1 port detected
> [ 1773.542010] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
> [ 1773.542146] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.08
> [ 1773.542162] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [ 1773.542174] usb usb2: Product: xHCI Host Controller
> [ 1773.542183] usb usb2: Manufacturer: Linux 6.8.0-00058-g113103fa3b95 xhci-hcd
> [ 1773.542193] usb usb2: SerialNumber: xhci-hcd.2.auto
> [ 1773.543241] hub 2-0:1.0: USB hub found
> [ 1773.543282] hub 2-0:1.0: 1 port detected
> [ 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.
Abhinav, any suggestions ?
Neil
> [ 1775.597965] [drm:dp_display_process_hpd_high] *ERROR* failed to complete DP link training
> [ 1775.598149] [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
> [ 1776.632081] [drm:dp_ctrl_link_train] *ERROR* max v_level reached
> [ 1776.632145] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11
> [ 1776.662978] [drm:dp_display_process_hpd_high] *ERROR* failed to complete DP link training
> [ 1776.663039] [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
> [ 1777.717501] [drm:dp_ctrl_link_train] *ERROR* max v_level reached
> [ 1777.717524] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11
> [ 1777.751427] [drm:dp_display_process_hpd_high] *ERROR* failed to complete DP link training
> [ 1777.751518] [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
> [ 1778.793550] [drm:dp_ctrl_link_train] *ERROR* max v_level reached
> [ 1778.793617] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11
> [ 1778.827260] [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy
> [ 1778.827334] [drm:dp_display_process_hpd_high] *ERROR* failed to complete DP link training
> [ 1779.279889] xhci-hcd xhci-hcd.2.auto: remove, state 1
> [ 1779.279942] usb usb2: USB disconnect, device number 1
> [ 1779.311920] xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered
> [ 1779.311987] xhci-hcd xhci-hcd.2.auto: remove, state 4
> [ 1779.312019] usb usb1: USB disconnect, device number 1
> [ 1779.317772] xhci-hcd xhci-hcd.2.auto: USB bus 1 deregistered
>
> Regards
> Luca
>
>
>> ...
>>
>> Signed-off-by: Neil Armstrong <[email protected]>
>> ---
>> Neil Armstrong (7):
>> dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp: Add mode-switch
>> phy: qcom: qmp-combo: store DP phy power state
>> phy: qcom: qmp-combo: introduce QPHY_MODE
>> phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
>> arm64: dts: qcom-sm8550: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
>> arm64: dts: qcom-sm8650: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
>> arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
>>
>> .../phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 5 +
>> .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 +-
>> arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 3 +-
>> arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 3 +-
>> arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 3 +-
>> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 168 +++++++++++++++++++--
>> 6 files changed, 173 insertions(+), 15 deletions(-)
>> ---
>> base-commit: b321c0e8ca754d8cd9f23ceba958e3ea93c6519e
>> change-id: 20240229-topic-sm8x50-upstream-phy-combo-typec-mux-31b5252513c9
>>
>> Best regards,
>
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.
Regards,
Bjorn
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
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..
Konrad
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@60Hz
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
Regards
Luca
>
> Konrad
On 29-02-24, 14:07, Neil Armstrong wrote:
> Introduce an enum for the QMP Combo PHY modes, use it in the
> QMP commmon phy init function and default to COMBO mode.
>
> Signed-off-by: Neil Armstrong <[email protected]>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 41 +++++++++++++++++++++++++++----
> 1 file changed, 36 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> index 3721bbea9eae..ac5d528fd7a1 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> @@ -61,6 +61,12 @@
>
> #define PHY_INIT_COMPLETE_TIMEOUT 10000
>
> +enum qphy_mode {
> + QPHY_MODE_COMBO = 0,
> + QPHY_MODE_DP_ONLY,
> + QPHY_MODE_USB_ONLY,
> +};
> +
> /* set of registers with offsets different per-PHY */
> enum qphy_reg_layout {
> /* PCS registers */
> @@ -1491,6 +1497,7 @@ struct qmp_combo {
>
> struct mutex phy_mutex;
> int init_count;
> + enum qphy_mode init_mode;
>
> struct phy *usb_phy;
> enum phy_mode mode;
> @@ -2531,12 +2538,33 @@ static int qmp_combo_com_init(struct qmp_combo *qmp, bool force)
> if (qmp->orientation == TYPEC_ORIENTATION_REVERSE)
> val |= SW_PORTSELECT_VAL;
> writel(val, com + QPHY_V3_DP_COM_TYPEC_CTRL);
> - writel(USB3_MODE | DP_MODE, com + QPHY_V3_DP_COM_PHY_MODE_CTRL);
>
> - /* bring both QMP USB and QMP DP PHYs PCS block out of reset */
> - qphy_clrbits(com, QPHY_V3_DP_COM_RESET_OVRD_CTRL,
> - SW_DPPHY_RESET_MUX | SW_DPPHY_RESET |
> - SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
> + switch (qmp->init_mode) {
> + case QPHY_MODE_COMBO:
Case should be at same indent as switch :-) coding style 101
> + writel(USB3_MODE | DP_MODE, com + QPHY_V3_DP_COM_PHY_MODE_CTRL);
> +
> + /* bring both QMP USB and QMP DP PHYs PCS block out of reset */
> + qphy_clrbits(com, QPHY_V3_DP_COM_RESET_OVRD_CTRL,
> + SW_DPPHY_RESET_MUX | SW_DPPHY_RESET |
> + SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
> + break;
> +
> + case QPHY_MODE_DP_ONLY:
> + writel(DP_MODE, com + QPHY_V3_DP_COM_PHY_MODE_CTRL);
> +
> + /* bring QMP DP PHY PCS block out of reset */
> + qphy_clrbits(com, QPHY_V3_DP_COM_RESET_OVRD_CTRL,
> + SW_DPPHY_RESET_MUX | SW_DPPHY_RESET);
> + break;
> +
> + case QPHY_MODE_USB_ONLY:
> + writel(USB3_MODE, com + QPHY_V3_DP_COM_PHY_MODE_CTRL);
> +
> + /* bring QMP USB PHY PCS block out of reset */
> + qphy_clrbits(com, QPHY_V3_DP_COM_RESET_OVRD_CTRL,
> + SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
> + break;
> + }
>
> qphy_clrbits(com, QPHY_V3_DP_COM_SWI_CTRL, 0x03);
> qphy_clrbits(com, QPHY_V3_DP_COM_SW_RESET, SW_RESET);
> @@ -3545,6 +3573,9 @@ static int qmp_combo_probe(struct platform_device *pdev)
> if (ret)
> goto err_node_put;
>
> + /* Set PHY_MODE as combo by default */
> + qmp->init_mode = QPHY_MODE_COMBO;
> +
> qmp->usb_phy = devm_phy_create(dev, usb_np, &qmp_combo_usb_phy_ops);
> if (IS_ERR(qmp->usb_phy)) {
> ret = PTR_ERR(qmp->usb_phy);
>
> --
> 2.34.1
--
~Vinod
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@60Hz
> 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/[email protected]/
Thanks,
Neil
>
> Regards
> Luca
>
>>
>> Konrad
>
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@60Hz
> > 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/[email protected]/
Unfortunately I do not see any change with this on QCM6490 Fairphone 5
and 4-lane DP.
Regards
Luca
>
> Thanks,
> Neil
>
> >
> > Regards
> > Luca
> >
> >>
> >> Konrad
> >
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@60Hz
>>> 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/[email protected]/
>
> 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?
Konrad
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@60Hz
>>>> 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/[email protected]/
>>
>> 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.
Neil
>
> Konrad
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@60Hz
> >>>> 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/[email protected]/
> >>
> >> 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
Hi Lucas,
On 10/05/2024 08:51, Luca Weiss wrote:
> 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:
<snip>
>
> 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.
Thanks a lot for the traces, it founds out the QPHY_V3_DP_COM_PHY_MODE_CTRL stays at 0x3,
which means the mode doesn't get broadcasted to the phy because.... the retimer only broadcasts
the orientation and not the mode... and it works on the HDKs and the X13s because they don't have retimers.
So I made the changes in nb7vpq904m and ptn36502 drivers to get the next mux and broadcast the typec mode,
if you find time could you test it ?
Bjorn could you also test on the rb3gen2 ?
The changes:
https://git.codelinaro.org/neil.armstrong/linux/-/commit/a61fb3b816ecbe28a12480367d9e09b700ec09e1
https://git.codelinaro.org/neil.armstrong/linux/-/commit/f6f976ff692bad430cd945f02b835e355f19632b
Thanks,
Neil
>
> Regards
> Luca
>
>>
>> Neil
>>
>>>
>>> Konrad
>
>
On Thu May 23, 2024 at 11:06 AM CEST, wrote:
> Hi Lucas,
>
> On 10/05/2024 08:51, Luca Weiss wrote:
> > 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:
>
> <snip>
>
> >
> > 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.
>
> Thanks a lot for the traces, it founds out the QPHY_V3_DP_COM_PHY_MODE_CTRL stays at 0x3,
> which means the mode doesn't get broadcasted to the phy because.... the retimer only broadcasts
> the orientation and not the mode... and it works on the HDKs and the X13s because they don't have retimers.
Hi Neil,
This was it!
>
> So I made the changes in nb7vpq904m and ptn36502 drivers to get the next mux and broadcast the typec mode,
> if you find time could you test it ?
>
> Bjorn could you also test on the rb3gen2 ?
>
> The changes:
> https://git.codelinaro.org/neil.armstrong/linux/-/commit/a61fb3b816ecbe28a12480367d9e09b700ec09e1
With this ptn36502 patch on top, I can confirm that DP 4-lane seems to
work on qcm6490-fairphone-fp5 smartphone with DP over USB-C!
Tested with a USB-C dongle that only has a HDMI port on the other side
(so no USB), and cat'ing dp_debug while connected showed num_lanes = 4
So feel free to add my:
Tested-by: Luca Weiss <[email protected]>
Regards
Luca
> https://git.codelinaro.org/neil.armstrong/linux/-/commit/f6f976ff692bad430cd945f02b835e355f19632b
>
> Thanks,
> Neil
>
> >
> > Regards
> > Luca
> >
> >>
> >> Neil
> >>
> >>>
> >>> Konrad
> >
> >
On 24/05/2024 08:51, Luca Weiss wrote:
> On Thu May 23, 2024 at 11:06 AM CEST, wrote:
>> Hi Lucas,
>>
>> On 10/05/2024 08:51, Luca Weiss wrote:
>>> 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:
>>
>> <snip>
>>
>>>
>>> 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.
>>
>> Thanks a lot for the traces, it founds out the QPHY_V3_DP_COM_PHY_MODE_CTRL stays at 0x3,
>> which means the mode doesn't get broadcasted to the phy because.... the retimer only broadcasts
>> the orientation and not the mode... and it works on the HDKs and the X13s because they don't have retimers.
>
> Hi Neil,
>
> This was it!
>
>>
>> So I made the changes in nb7vpq904m and ptn36502 drivers to get the next mux and broadcast the typec mode,
>> if you find time could you test it ?
>>
>> Bjorn could you also test on the rb3gen2 ?
>>
>> The changes:
>> https://git.codelinaro.org/neil.armstrong/linux/-/commit/a61fb3b816ecbe28a12480367d9e09b700ec09e1
>
> With this ptn36502 patch on top, I can confirm that DP 4-lane seems to
> work on qcm6490-fairphone-fp5 smartphone with DP over USB-C!
>
> Tested with a USB-C dongle that only has a HDMI port on the other side
> (so no USB), and cat'ing dp_debug while connected showed num_lanes = 4
>
> So feel free to add my:
>
> Tested-by: Luca Weiss <[email protected]>
Thanks a lot for testing, spinning a v2 with those patches!
Neil
>
> Regards
> Luca
>
>> https://git.codelinaro.org/neil.armstrong/linux/-/commit/f6f976ff692bad430cd945f02b835e355f19632b
>>
>> Thanks,
>> Neil
>>
>>>
>>> Regards
>>> Luca
>>>
>>>>
>>>> Neil
>>>>
>>>>>
>>>>> Konrad
>>>
>>>
>