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