* [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-02-29 13:07 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
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 <neil.armstrong@linaro.org>
---
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 <neil.armstrong@linaro.org>
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-02-29 13:07 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
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 <neil.armstrong@linaro.org>
---
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 <neil.armstrong@linaro.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH RFT 1/7] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp: Add mode-switch
2024-02-29 13:07 ` Neil Armstrong
@ 2024-02-29 13:07 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
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 <neil.armstrong@linaro.org>
---
.../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
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 1/7] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp: Add mode-switch
@ 2024-02-29 13:07 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
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 <neil.armstrong@linaro.org>
---
.../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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 2/7] phy: qcom: qmp-combo: store DP phy power state
2024-02-29 13:07 ` Neil Armstrong
@ 2024-02-29 13:07 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
Switching the PHY Mode requires the DisplayPort PHY to be powered off,
keep track of the DisplayPort phy power state.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index 2f341613fd31..3721bbea9eae 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -1500,6 +1500,7 @@ struct qmp_combo {
unsigned int dp_aux_cfg;
struct phy_configure_opts_dp dp_opts;
unsigned int dp_init_count;
+ bool dp_powered_on;
struct clk_fixed_rate pipe_clk_fixed;
struct clk_hw dp_link_hw;
@@ -2627,6 +2628,8 @@ static int qmp_combo_dp_power_on(struct phy *phy)
/* Configure link rate, swing, etc. */
cfg->configure_dp_phy(qmp);
+ qmp->dp_powered_on = true;
+
mutex_unlock(&qmp->phy_mutex);
return 0;
@@ -2641,6 +2644,8 @@ static int qmp_combo_dp_power_off(struct phy *phy)
/* Assert DP PHY power down */
writel(DP_PHY_PD_CTL_PSR_PWRDN, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
+ qmp->dp_powered_on = false;
+
mutex_unlock(&qmp->phy_mutex);
return 0;
--
2.34.1
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 2/7] phy: qcom: qmp-combo: store DP phy power state
@ 2024-02-29 13:07 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
Switching the PHY Mode requires the DisplayPort PHY to be powered off,
keep track of the DisplayPort phy power state.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index 2f341613fd31..3721bbea9eae 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -1500,6 +1500,7 @@ struct qmp_combo {
unsigned int dp_aux_cfg;
struct phy_configure_opts_dp dp_opts;
unsigned int dp_init_count;
+ bool dp_powered_on;
struct clk_fixed_rate pipe_clk_fixed;
struct clk_hw dp_link_hw;
@@ -2627,6 +2628,8 @@ static int qmp_combo_dp_power_on(struct phy *phy)
/* Configure link rate, swing, etc. */
cfg->configure_dp_phy(qmp);
+ qmp->dp_powered_on = true;
+
mutex_unlock(&qmp->phy_mutex);
return 0;
@@ -2641,6 +2644,8 @@ static int qmp_combo_dp_power_off(struct phy *phy)
/* Assert DP PHY power down */
writel(DP_PHY_PD_CTL_PSR_PWRDN, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
+ qmp->dp_powered_on = false;
+
mutex_unlock(&qmp->phy_mutex);
return 0;
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 3/7] phy: qcom: qmp-combo: introduce QPHY_MODE
2024-02-29 13:07 ` Neil Armstrong
@ 2024-02-29 13:07 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
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 <neil.armstrong@linaro.org>
---
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
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 3/7] phy: qcom: qmp-combo: introduce QPHY_MODE
@ 2024-02-29 13:07 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
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 <neil.armstrong@linaro.org>
---
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
2024-02-29 13:07 ` Neil Armstrong
@ 2024-02-29 13:07 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
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.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 122 ++++++++++++++++++++++++++++--
1 file changed, 117 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index ac5d528fd7a1..b5fb6cbcf867 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -19,6 +19,7 @@
#include <linux/reset.h>
#include <linux/slab.h>
#include <linux/usb/typec.h>
+#include <linux/usb/typec_dp.h>
#include <linux/usb/typec_mux.h>
#include <drm/bridge/aux-bridge.h>
@@ -1515,6 +1516,10 @@ struct qmp_combo {
struct typec_switch_dev *sw;
enum typec_orientation orientation;
+
+ struct typec_mux_dev *mux;
+ unsigned long mux_mode;
+ unsigned int svid;
};
static void qmp_v3_dp_aux_init(struct qmp_combo *qmp);
@@ -3295,17 +3300,111 @@ static int qmp_combo_typec_switch_set(struct typec_switch_dev *sw,
return 0;
}
-static void qmp_combo_typec_unregister(void *data)
+static int qmp_combo_typec_mux_set(struct typec_mux_dev *mux, struct typec_mux_state *state)
+{
+ struct qmp_combo *qmp = typec_mux_get_drvdata(mux);
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ enum qphy_mode new_mode;
+ unsigned int svid;
+
+ if (state->mode == qmp->mode)
+ return 0;
+
+ mutex_lock(&qmp->phy_mutex);
+
+ if (state->alt)
+ svid = state->alt->svid;
+ else
+ svid = 0; // No SVID
+
+ if (svid) {
+ switch (state->mode) {
+ /* DP Only */
+ case TYPEC_DP_STATE_C:
+ case TYPEC_DP_STATE_E:
+ new_mode = QPHY_MODE_DP_ONLY;
+ break;
+
+ /* DP + USB */
+ case TYPEC_DP_STATE_D:
+ case TYPEC_DP_STATE_F:
+ /* Safe fallback...*/
+ default:
+ new_mode = QPHY_MODE_COMBO;
+ break;
+ }
+ } else {
+ /* Only switch to USB_ONLY when we know we only have USB3 */
+ if (qmp->mux_mode == TYPEC_MODE_USB3)
+ new_mode = QPHY_MODE_USB_ONLY;
+ else
+ new_mode = QPHY_MODE_COMBO;
+ }
+
+ if (new_mode == qmp->init_mode) {
+ dev_dbg(qmp->dev, "typec_mux_set: same phy mode, bail out\n");
+ qmp->mode = state->mode;
+ goto out;
+ }
+
+ if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_powered_on) {
+ dev_dbg(qmp->dev, "typec_mux_set: DP is still powered on, delaying switch\n");
+ goto out;
+ }
+
+ dev_dbg(qmp->dev, "typec_mux_set: switching from phy mode %d to %d\n",
+ qmp->init_mode, new_mode);
+
+ qmp->mux_mode = state->mode;
+ qmp->init_mode = new_mode;
+
+ if (qmp->init_count) {
+ if (qmp->usb_init_count)
+ qmp_combo_usb_power_off(qmp->usb_phy);
+ if (qmp->dp_init_count)
+ writel(DP_PHY_PD_CTL_PSR_PWRDN, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
+ qmp_combo_com_exit(qmp, true);
+
+ /* Now everything's powered down, power up the right PHYs */
+
+ qmp_combo_com_init(qmp, true);
+ if (qmp->init_mode == QPHY_MODE_DP_ONLY && qmp->usb_init_count) {
+ qmp->usb_init_count--;
+ } else if (qmp->init_mode != QPHY_MODE_DP_ONLY) {
+ qmp_combo_usb_power_on(qmp->usb_phy);
+ if (!qmp->usb_init_count)
+ qmp->usb_init_count++;
+ }
+ if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_init_count)
+ cfg->dp_aux_init(qmp);
+ }
+
+out:
+ mutex_unlock(&qmp->phy_mutex);
+
+ return 0;
+}
+
+static void qmp_combo_typec_switch_unregister(void *data)
{
struct qmp_combo *qmp = data;
typec_switch_unregister(qmp->sw);
}
-static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
+static void qmp_combo_typec_mux_unregister(void *data)
+{
+ struct qmp_combo *qmp = data;
+
+ typec_mux_unregister(qmp->mux);
+}
+
+static int qmp_combo_typec_register(struct qmp_combo *qmp)
{
struct typec_switch_desc sw_desc = {};
+ struct typec_mux_desc mux_desc = { };
struct device *dev = qmp->dev;
+ int ret;
sw_desc.drvdata = qmp;
sw_desc.fwnode = dev->fwnode;
@@ -3316,10 +3415,23 @@ static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
return PTR_ERR(qmp->sw);
}
- return devm_add_action_or_reset(dev, qmp_combo_typec_unregister, qmp);
+ ret = devm_add_action_or_reset(dev, qmp_combo_typec_switch_unregister, qmp);
+ if (ret)
+ return ret;
+
+ mux_desc.drvdata = qmp;
+ mux_desc.fwnode = dev->fwnode;
+ mux_desc.set = qmp_combo_typec_mux_set;
+ qmp->mux = typec_mux_register(dev, &mux_desc);
+ if (IS_ERR(qmp->mux)) {
+ dev_err(dev, "Unable to register typec mux: %pe\n", qmp->mux);
+ return PTR_ERR(qmp->mux);
+ }
+
+ return devm_add_action_or_reset(dev, qmp_combo_typec_mux_unregister, qmp);
}
#else
-static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
+static int qmp_combo_typec_register(struct qmp_combo *qmp)
{
return 0;
}
@@ -3532,7 +3644,7 @@ static int qmp_combo_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = qmp_combo_typec_switch_register(qmp);
+ ret = qmp_combo_typec_register(qmp);
if (ret)
return ret;
--
2.34.1
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
@ 2024-02-29 13:07 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
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.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 122 ++++++++++++++++++++++++++++--
1 file changed, 117 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index ac5d528fd7a1..b5fb6cbcf867 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -19,6 +19,7 @@
#include <linux/reset.h>
#include <linux/slab.h>
#include <linux/usb/typec.h>
+#include <linux/usb/typec_dp.h>
#include <linux/usb/typec_mux.h>
#include <drm/bridge/aux-bridge.h>
@@ -1515,6 +1516,10 @@ struct qmp_combo {
struct typec_switch_dev *sw;
enum typec_orientation orientation;
+
+ struct typec_mux_dev *mux;
+ unsigned long mux_mode;
+ unsigned int svid;
};
static void qmp_v3_dp_aux_init(struct qmp_combo *qmp);
@@ -3295,17 +3300,111 @@ static int qmp_combo_typec_switch_set(struct typec_switch_dev *sw,
return 0;
}
-static void qmp_combo_typec_unregister(void *data)
+static int qmp_combo_typec_mux_set(struct typec_mux_dev *mux, struct typec_mux_state *state)
+{
+ struct qmp_combo *qmp = typec_mux_get_drvdata(mux);
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ enum qphy_mode new_mode;
+ unsigned int svid;
+
+ if (state->mode == qmp->mode)
+ return 0;
+
+ mutex_lock(&qmp->phy_mutex);
+
+ if (state->alt)
+ svid = state->alt->svid;
+ else
+ svid = 0; // No SVID
+
+ if (svid) {
+ switch (state->mode) {
+ /* DP Only */
+ case TYPEC_DP_STATE_C:
+ case TYPEC_DP_STATE_E:
+ new_mode = QPHY_MODE_DP_ONLY;
+ break;
+
+ /* DP + USB */
+ case TYPEC_DP_STATE_D:
+ case TYPEC_DP_STATE_F:
+ /* Safe fallback...*/
+ default:
+ new_mode = QPHY_MODE_COMBO;
+ break;
+ }
+ } else {
+ /* Only switch to USB_ONLY when we know we only have USB3 */
+ if (qmp->mux_mode == TYPEC_MODE_USB3)
+ new_mode = QPHY_MODE_USB_ONLY;
+ else
+ new_mode = QPHY_MODE_COMBO;
+ }
+
+ if (new_mode == qmp->init_mode) {
+ dev_dbg(qmp->dev, "typec_mux_set: same phy mode, bail out\n");
+ qmp->mode = state->mode;
+ goto out;
+ }
+
+ if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_powered_on) {
+ dev_dbg(qmp->dev, "typec_mux_set: DP is still powered on, delaying switch\n");
+ goto out;
+ }
+
+ dev_dbg(qmp->dev, "typec_mux_set: switching from phy mode %d to %d\n",
+ qmp->init_mode, new_mode);
+
+ qmp->mux_mode = state->mode;
+ qmp->init_mode = new_mode;
+
+ if (qmp->init_count) {
+ if (qmp->usb_init_count)
+ qmp_combo_usb_power_off(qmp->usb_phy);
+ if (qmp->dp_init_count)
+ writel(DP_PHY_PD_CTL_PSR_PWRDN, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
+ qmp_combo_com_exit(qmp, true);
+
+ /* Now everything's powered down, power up the right PHYs */
+
+ qmp_combo_com_init(qmp, true);
+ if (qmp->init_mode == QPHY_MODE_DP_ONLY && qmp->usb_init_count) {
+ qmp->usb_init_count--;
+ } else if (qmp->init_mode != QPHY_MODE_DP_ONLY) {
+ qmp_combo_usb_power_on(qmp->usb_phy);
+ if (!qmp->usb_init_count)
+ qmp->usb_init_count++;
+ }
+ if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_init_count)
+ cfg->dp_aux_init(qmp);
+ }
+
+out:
+ mutex_unlock(&qmp->phy_mutex);
+
+ return 0;
+}
+
+static void qmp_combo_typec_switch_unregister(void *data)
{
struct qmp_combo *qmp = data;
typec_switch_unregister(qmp->sw);
}
-static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
+static void qmp_combo_typec_mux_unregister(void *data)
+{
+ struct qmp_combo *qmp = data;
+
+ typec_mux_unregister(qmp->mux);
+}
+
+static int qmp_combo_typec_register(struct qmp_combo *qmp)
{
struct typec_switch_desc sw_desc = {};
+ struct typec_mux_desc mux_desc = { };
struct device *dev = qmp->dev;
+ int ret;
sw_desc.drvdata = qmp;
sw_desc.fwnode = dev->fwnode;
@@ -3316,10 +3415,23 @@ static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
return PTR_ERR(qmp->sw);
}
- return devm_add_action_or_reset(dev, qmp_combo_typec_unregister, qmp);
+ ret = devm_add_action_or_reset(dev, qmp_combo_typec_switch_unregister, qmp);
+ if (ret)
+ return ret;
+
+ mux_desc.drvdata = qmp;
+ mux_desc.fwnode = dev->fwnode;
+ mux_desc.set = qmp_combo_typec_mux_set;
+ qmp->mux = typec_mux_register(dev, &mux_desc);
+ if (IS_ERR(qmp->mux)) {
+ dev_err(dev, "Unable to register typec mux: %pe\n", qmp->mux);
+ return PTR_ERR(qmp->mux);
+ }
+
+ return devm_add_action_or_reset(dev, qmp_combo_typec_mux_unregister, qmp);
}
#else
-static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
+static int qmp_combo_typec_register(struct qmp_combo *qmp)
{
return 0;
}
@@ -3532,7 +3644,7 @@ static int qmp_combo_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = qmp_combo_typec_switch_register(qmp);
+ ret = qmp_combo_typec_register(qmp);
if (ret)
return ret;
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 5/7] arm64: dts: qcom-sm8550: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
2024-02-29 13:07 ` Neil Armstrong
@ 2024-02-29 13:07 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
Allow up to 4 lanes for the DisplayPort link from the PHY to the Controller
and allow mode-switch events to the QMP Combo PHY.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 3 ++-
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
index 12d60a0ee095..86d6f993acd5 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
@@ -941,7 +941,7 @@ &mdss_dp0 {
&mdss_dp0_out {
remote-endpoint = <&usb_dp_qmpphy_dp_in>;
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
};
&pcie0 {
@@ -1284,6 +1284,7 @@ &usb_dp_qmpphy {
vdda-phy-supply = <&vreg_l3e_1p2>;
vdda-pll-supply = <&vreg_l3f_0p88>;
+ mode-switch;
orientation-switch;
status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
index 92f015017418..2f6c76c9a135 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
@@ -806,7 +806,7 @@ &mdss_dp0 {
};
&mdss_dp0_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_dp_qmpphy_dp_in>;
};
@@ -1161,6 +1161,7 @@ &usb_dp_qmpphy {
vdda-phy-supply = <&vreg_l3e_1p2>;
vdda-pll-supply = <&vreg_l3f_0p88>;
+ mode-switch;
orientation-switch;
status = "okay";
--
2.34.1
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 5/7] arm64: dts: qcom-sm8550: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
@ 2024-02-29 13:07 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
Allow up to 4 lanes for the DisplayPort link from the PHY to the Controller
and allow mode-switch events to the QMP Combo PHY.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 3 ++-
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
index 12d60a0ee095..86d6f993acd5 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
@@ -941,7 +941,7 @@ &mdss_dp0 {
&mdss_dp0_out {
remote-endpoint = <&usb_dp_qmpphy_dp_in>;
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
};
&pcie0 {
@@ -1284,6 +1284,7 @@ &usb_dp_qmpphy {
vdda-phy-supply = <&vreg_l3e_1p2>;
vdda-pll-supply = <&vreg_l3f_0p88>;
+ mode-switch;
orientation-switch;
status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
index 92f015017418..2f6c76c9a135 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
@@ -806,7 +806,7 @@ &mdss_dp0 {
};
&mdss_dp0_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_dp_qmpphy_dp_in>;
};
@@ -1161,6 +1161,7 @@ &usb_dp_qmpphy {
vdda-phy-supply = <&vreg_l3e_1p2>;
vdda-pll-supply = <&vreg_l3f_0p88>;
+ mode-switch;
orientation-switch;
status = "okay";
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 6/7] arm64: dts: qcom-sm8650: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
2024-02-29 13:07 ` Neil Armstrong
@ 2024-02-29 13:07 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
Allow up to 4 lanes for the DisplayPort link from the PHY to the Controller
and allow mode-switch events to the QMP Combo PHY.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
index b07cac2e5bc8..35259ebd07ce 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
@@ -823,7 +823,7 @@ &mdss_dp0 {
};
&mdss_dp0_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_dp_qmpphy_dp_in>;
};
@@ -1224,6 +1224,7 @@ &usb_dp_qmpphy {
vdda-phy-supply = <&vreg_l3i_1p2>;
vdda-pll-supply = <&vreg_l3g_0p91>;
+ mode-switch;
orientation-switch;
status = "okay";
--
2.34.1
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 6/7] arm64: dts: qcom-sm8650: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
@ 2024-02-29 13:07 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
Allow up to 4 lanes for the DisplayPort link from the PHY to the Controller
and allow mode-switch events to the QMP Combo PHY.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8650-qrd.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
index b07cac2e5bc8..35259ebd07ce 100644
--- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
@@ -823,7 +823,7 @@ &mdss_dp0 {
};
&mdss_dp0_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_dp_qmpphy_dp_in>;
};
@@ -1224,6 +1224,7 @@ &usb_dp_qmpphy {
vdda-phy-supply = <&vreg_l3i_1p2>;
vdda-pll-supply = <&vreg_l3g_0p91>;
+ mode-switch;
orientation-switch;
status = "okay";
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 7/7] arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
2024-02-29 13:07 ` Neil Armstrong
@ 2024-02-29 13:07 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
Allow up to 4 lanes for the DisplayPort link from the PHYs to the Controllers
and allow mode-switch events to the QMP Combo PHYs.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index a0fdef55a40a..6c73e0fc001f 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -556,7 +556,7 @@ &mdss0_dp0 {
};
&mdss0_dp0_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_0_qmpphy_dp_in>;
};
@@ -565,7 +565,7 @@ &mdss0_dp1 {
};
&mdss0_dp1_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_1_qmpphy_dp_in>;
};
@@ -1112,6 +1112,7 @@ &usb_0_qmpphy {
vdda-phy-supply = <&vreg_l9d>;
vdda-pll-supply = <&vreg_l4d>;
+ mode-switch;
orientation-switch;
status = "okay";
@@ -1149,6 +1150,7 @@ &usb_1_qmpphy {
vdda-phy-supply = <&vreg_l4b>;
vdda-pll-supply = <&vreg_l3b>;
+ mode-switch;
orientation-switch;
status = "okay";
--
2.34.1
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH RFT 7/7] arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
@ 2024-02-29 13:07 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Neil Armstrong
Allow up to 4 lanes for the DisplayPort link from the PHYs to the Controllers
and allow mode-switch events to the QMP Combo PHYs.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index a0fdef55a40a..6c73e0fc001f 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -556,7 +556,7 @@ &mdss0_dp0 {
};
&mdss0_dp0_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_0_qmpphy_dp_in>;
};
@@ -565,7 +565,7 @@ &mdss0_dp1 {
};
&mdss0_dp1_out {
- data-lanes = <0 1>;
+ data-lanes = <0 1 2 3>;
remote-endpoint = <&usb_1_qmpphy_dp_in>;
};
@@ -1112,6 +1112,7 @@ &usb_0_qmpphy {
vdda-phy-supply = <&vreg_l9d>;
vdda-pll-supply = <&vreg_l4d>;
+ mode-switch;
orientation-switch;
status = "okay";
@@ -1149,6 +1150,7 @@ &usb_1_qmpphy {
vdda-phy-supply = <&vreg_l4b>;
vdda-pll-supply = <&vreg_l3b>;
+ mode-switch;
orientation-switch;
status = "okay";
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 7/7] arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
2024-02-29 13:07 ` Neil Armstrong
@ 2024-02-29 13:11 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:11 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
Bad copy-pasta, subject should be:
[PATCH RFT 7/7] arm64: dts: wcom-sc8280xp-lenovo-thinkpad-x13: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
On 29/02/2024 14:07, Neil Armstrong wrote:
> Allow up to 4 lanes for the DisplayPort link from the PHYs to the Controllers
> and allow mode-switch events to the QMP Combo PHYs.
>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index a0fdef55a40a..6c73e0fc001f 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -556,7 +556,7 @@ &mdss0_dp0 {
> };
>
> &mdss0_dp0_out {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
> remote-endpoint = <&usb_0_qmpphy_dp_in>;
> };
>
> @@ -565,7 +565,7 @@ &mdss0_dp1 {
> };
>
> &mdss0_dp1_out {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
> remote-endpoint = <&usb_1_qmpphy_dp_in>;
> };
>
> @@ -1112,6 +1112,7 @@ &usb_0_qmpphy {
> vdda-phy-supply = <&vreg_l9d>;
> vdda-pll-supply = <&vreg_l4d>;
>
> + mode-switch;
> orientation-switch;
>
> status = "okay";
> @@ -1149,6 +1150,7 @@ &usb_1_qmpphy {
> vdda-phy-supply = <&vreg_l4b>;
> vdda-pll-supply = <&vreg_l3b>;
>
> + mode-switch;
> orientation-switch;
>
> status = "okay";
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 7/7] arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
@ 2024-02-29 13:11 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 13:11 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
Bad copy-pasta, subject should be:
[PATCH RFT 7/7] arm64: dts: wcom-sc8280xp-lenovo-thinkpad-x13: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
On 29/02/2024 14:07, Neil Armstrong wrote:
> Allow up to 4 lanes for the DisplayPort link from the PHYs to the Controllers
> and allow mode-switch events to the QMP Combo PHYs.
>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index a0fdef55a40a..6c73e0fc001f 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -556,7 +556,7 @@ &mdss0_dp0 {
> };
>
> &mdss0_dp0_out {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
> remote-endpoint = <&usb_0_qmpphy_dp_in>;
> };
>
> @@ -565,7 +565,7 @@ &mdss0_dp1 {
> };
>
> &mdss0_dp1_out {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
> remote-endpoint = <&usb_1_qmpphy_dp_in>;
> };
>
> @@ -1112,6 +1112,7 @@ &usb_0_qmpphy {
> vdda-phy-supply = <&vreg_l9d>;
> vdda-pll-supply = <&vreg_l4d>;
>
> + mode-switch;
> orientation-switch;
>
> status = "okay";
> @@ -1149,6 +1150,7 @@ &usb_1_qmpphy {
> vdda-phy-supply = <&vreg_l4b>;
> vdda-pll-supply = <&vreg_l3b>;
>
> + mode-switch;
> orientation-switch;
>
> status = "okay";
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
2024-02-29 13:07 ` Neil Armstrong
@ 2024-02-29 15:25 ` Dmitry Baryshkov
-1 siblings, 0 replies; 54+ messages in thread
From: Dmitry Baryshkov @ 2024-02-29 15:25 UTC (permalink / raw)
To: Neil Armstrong
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
On Thu, 29 Feb 2024 at 15:08, Neil Armstrong <neil.armstrong@linaro.org> 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.
I think this is not fully correct. Please correct me if I'm wrong, but
it is possible to switch between USB / USB+DP / DP-only at runtime.
See the Status Update and Configure commands.
>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 122 ++++++++++++++++++++++++++++--
> 1 file changed, 117 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> index ac5d528fd7a1..b5fb6cbcf867 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> @@ -19,6 +19,7 @@
> #include <linux/reset.h>
> #include <linux/slab.h>
> #include <linux/usb/typec.h>
> +#include <linux/usb/typec_dp.h>
> #include <linux/usb/typec_mux.h>
>
> #include <drm/bridge/aux-bridge.h>
> @@ -1515,6 +1516,10 @@ struct qmp_combo {
>
> struct typec_switch_dev *sw;
> enum typec_orientation orientation;
> +
> + struct typec_mux_dev *mux;
> + unsigned long mux_mode;
> + unsigned int svid;
> };
>
> static void qmp_v3_dp_aux_init(struct qmp_combo *qmp);
> @@ -3295,17 +3300,111 @@ static int qmp_combo_typec_switch_set(struct typec_switch_dev *sw,
> return 0;
> }
>
> -static void qmp_combo_typec_unregister(void *data)
> +static int qmp_combo_typec_mux_set(struct typec_mux_dev *mux, struct typec_mux_state *state)
> +{
> + struct qmp_combo *qmp = typec_mux_get_drvdata(mux);
> + const struct qmp_phy_cfg *cfg = qmp->cfg;
> + enum qphy_mode new_mode;
> + unsigned int svid;
> +
> + if (state->mode == qmp->mode)
> + return 0;
> +
> + mutex_lock(&qmp->phy_mutex);
> +
> + if (state->alt)
> + svid = state->alt->svid;
> + else
> + svid = 0; // No SVID
> +
> + if (svid) {
We should check svid against USB_TYPEC_DP_SID. Otherwise the driver
will mishandle the USB_SID_PD states.
> + switch (state->mode) {
> + /* DP Only */
> + case TYPEC_DP_STATE_C:
> + case TYPEC_DP_STATE_E:
> + new_mode = QPHY_MODE_DP_ONLY;
> + break;
> +
> + /* DP + USB */
> + case TYPEC_DP_STATE_D:
> + case TYPEC_DP_STATE_F:
> + /* Safe fallback...*/
> + default:
> + new_mode = QPHY_MODE_COMBO;
> + break;
> + }
> + } else {
> + /* Only switch to USB_ONLY when we know we only have USB3 */
> + if (qmp->mux_mode == TYPEC_MODE_USB3)
> + new_mode = QPHY_MODE_USB_ONLY;
> + else
> + new_mode = QPHY_MODE_COMBO;
> + }
> +
> + if (new_mode == qmp->init_mode) {
> + dev_dbg(qmp->dev, "typec_mux_set: same phy mode, bail out\n");
> + qmp->mode = state->mode;
> + goto out;
> + }
> +
> + if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_powered_on) {
> + dev_dbg(qmp->dev, "typec_mux_set: DP is still powered on, delaying switch\n");
> + goto out;
> + }
> +
> + dev_dbg(qmp->dev, "typec_mux_set: switching from phy mode %d to %d\n",
> + qmp->init_mode, new_mode);
> +
> + qmp->mux_mode = state->mode;
> + qmp->init_mode = new_mode;
> +
> + if (qmp->init_count) {
> + if (qmp->usb_init_count)
> + qmp_combo_usb_power_off(qmp->usb_phy);
> + if (qmp->dp_init_count)
> + writel(DP_PHY_PD_CTL_PSR_PWRDN, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
> + qmp_combo_com_exit(qmp, true);
> +
> + /* Now everything's powered down, power up the right PHYs */
> +
> + qmp_combo_com_init(qmp, true);
> + if (qmp->init_mode == QPHY_MODE_DP_ONLY && qmp->usb_init_count) {
> + qmp->usb_init_count--;
> + } else if (qmp->init_mode != QPHY_MODE_DP_ONLY) {
> + qmp_combo_usb_power_on(qmp->usb_phy);
> + if (!qmp->usb_init_count)
> + qmp->usb_init_count++;
> + }
> + if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_init_count)
> + cfg->dp_aux_init(qmp);
> + }
> +
> +out:
> + mutex_unlock(&qmp->phy_mutex);
> +
> + return 0;
> +}
> +
> +static void qmp_combo_typec_switch_unregister(void *data)
> {
> struct qmp_combo *qmp = data;
>
> typec_switch_unregister(qmp->sw);
> }
>
> -static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
> +static void qmp_combo_typec_mux_unregister(void *data)
> +{
> + struct qmp_combo *qmp = data;
> +
> + typec_mux_unregister(qmp->mux);
> +}
> +
> +static int qmp_combo_typec_register(struct qmp_combo *qmp)
> {
> struct typec_switch_desc sw_desc = {};
> + struct typec_mux_desc mux_desc = { };
> struct device *dev = qmp->dev;
> + int ret;
>
> sw_desc.drvdata = qmp;
> sw_desc.fwnode = dev->fwnode;
> @@ -3316,10 +3415,23 @@ static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
> return PTR_ERR(qmp->sw);
> }
>
> - return devm_add_action_or_reset(dev, qmp_combo_typec_unregister, qmp);
> + ret = devm_add_action_or_reset(dev, qmp_combo_typec_switch_unregister, qmp);
> + if (ret)
> + return ret;
> +
> + mux_desc.drvdata = qmp;
> + mux_desc.fwnode = dev->fwnode;
> + mux_desc.set = qmp_combo_typec_mux_set;
> + qmp->mux = typec_mux_register(dev, &mux_desc);
> + if (IS_ERR(qmp->mux)) {
> + dev_err(dev, "Unable to register typec mux: %pe\n", qmp->mux);
> + return PTR_ERR(qmp->mux);
> + }
> +
> + return devm_add_action_or_reset(dev, qmp_combo_typec_mux_unregister, qmp);
> }
> #else
> -static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
> +static int qmp_combo_typec_register(struct qmp_combo *qmp)
> {
> return 0;
> }
> @@ -3532,7 +3644,7 @@ static int qmp_combo_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - ret = qmp_combo_typec_switch_register(qmp);
> + ret = qmp_combo_typec_register(qmp);
> if (ret)
> return ret;
>
>
> --
> 2.34.1
>
>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
@ 2024-02-29 15:25 ` Dmitry Baryshkov
0 siblings, 0 replies; 54+ messages in thread
From: Dmitry Baryshkov @ 2024-02-29 15:25 UTC (permalink / raw)
To: Neil Armstrong
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
On Thu, 29 Feb 2024 at 15:08, Neil Armstrong <neil.armstrong@linaro.org> 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.
I think this is not fully correct. Please correct me if I'm wrong, but
it is possible to switch between USB / USB+DP / DP-only at runtime.
See the Status Update and Configure commands.
>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 122 ++++++++++++++++++++++++++++--
> 1 file changed, 117 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> index ac5d528fd7a1..b5fb6cbcf867 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> @@ -19,6 +19,7 @@
> #include <linux/reset.h>
> #include <linux/slab.h>
> #include <linux/usb/typec.h>
> +#include <linux/usb/typec_dp.h>
> #include <linux/usb/typec_mux.h>
>
> #include <drm/bridge/aux-bridge.h>
> @@ -1515,6 +1516,10 @@ struct qmp_combo {
>
> struct typec_switch_dev *sw;
> enum typec_orientation orientation;
> +
> + struct typec_mux_dev *mux;
> + unsigned long mux_mode;
> + unsigned int svid;
> };
>
> static void qmp_v3_dp_aux_init(struct qmp_combo *qmp);
> @@ -3295,17 +3300,111 @@ static int qmp_combo_typec_switch_set(struct typec_switch_dev *sw,
> return 0;
> }
>
> -static void qmp_combo_typec_unregister(void *data)
> +static int qmp_combo_typec_mux_set(struct typec_mux_dev *mux, struct typec_mux_state *state)
> +{
> + struct qmp_combo *qmp = typec_mux_get_drvdata(mux);
> + const struct qmp_phy_cfg *cfg = qmp->cfg;
> + enum qphy_mode new_mode;
> + unsigned int svid;
> +
> + if (state->mode == qmp->mode)
> + return 0;
> +
> + mutex_lock(&qmp->phy_mutex);
> +
> + if (state->alt)
> + svid = state->alt->svid;
> + else
> + svid = 0; // No SVID
> +
> + if (svid) {
We should check svid against USB_TYPEC_DP_SID. Otherwise the driver
will mishandle the USB_SID_PD states.
> + switch (state->mode) {
> + /* DP Only */
> + case TYPEC_DP_STATE_C:
> + case TYPEC_DP_STATE_E:
> + new_mode = QPHY_MODE_DP_ONLY;
> + break;
> +
> + /* DP + USB */
> + case TYPEC_DP_STATE_D:
> + case TYPEC_DP_STATE_F:
> + /* Safe fallback...*/
> + default:
> + new_mode = QPHY_MODE_COMBO;
> + break;
> + }
> + } else {
> + /* Only switch to USB_ONLY when we know we only have USB3 */
> + if (qmp->mux_mode == TYPEC_MODE_USB3)
> + new_mode = QPHY_MODE_USB_ONLY;
> + else
> + new_mode = QPHY_MODE_COMBO;
> + }
> +
> + if (new_mode == qmp->init_mode) {
> + dev_dbg(qmp->dev, "typec_mux_set: same phy mode, bail out\n");
> + qmp->mode = state->mode;
> + goto out;
> + }
> +
> + if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_powered_on) {
> + dev_dbg(qmp->dev, "typec_mux_set: DP is still powered on, delaying switch\n");
> + goto out;
> + }
> +
> + dev_dbg(qmp->dev, "typec_mux_set: switching from phy mode %d to %d\n",
> + qmp->init_mode, new_mode);
> +
> + qmp->mux_mode = state->mode;
> + qmp->init_mode = new_mode;
> +
> + if (qmp->init_count) {
> + if (qmp->usb_init_count)
> + qmp_combo_usb_power_off(qmp->usb_phy);
> + if (qmp->dp_init_count)
> + writel(DP_PHY_PD_CTL_PSR_PWRDN, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
> + qmp_combo_com_exit(qmp, true);
> +
> + /* Now everything's powered down, power up the right PHYs */
> +
> + qmp_combo_com_init(qmp, true);
> + if (qmp->init_mode == QPHY_MODE_DP_ONLY && qmp->usb_init_count) {
> + qmp->usb_init_count--;
> + } else if (qmp->init_mode != QPHY_MODE_DP_ONLY) {
> + qmp_combo_usb_power_on(qmp->usb_phy);
> + if (!qmp->usb_init_count)
> + qmp->usb_init_count++;
> + }
> + if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_init_count)
> + cfg->dp_aux_init(qmp);
> + }
> +
> +out:
> + mutex_unlock(&qmp->phy_mutex);
> +
> + return 0;
> +}
> +
> +static void qmp_combo_typec_switch_unregister(void *data)
> {
> struct qmp_combo *qmp = data;
>
> typec_switch_unregister(qmp->sw);
> }
>
> -static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
> +static void qmp_combo_typec_mux_unregister(void *data)
> +{
> + struct qmp_combo *qmp = data;
> +
> + typec_mux_unregister(qmp->mux);
> +}
> +
> +static int qmp_combo_typec_register(struct qmp_combo *qmp)
> {
> struct typec_switch_desc sw_desc = {};
> + struct typec_mux_desc mux_desc = { };
> struct device *dev = qmp->dev;
> + int ret;
>
> sw_desc.drvdata = qmp;
> sw_desc.fwnode = dev->fwnode;
> @@ -3316,10 +3415,23 @@ static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
> return PTR_ERR(qmp->sw);
> }
>
> - return devm_add_action_or_reset(dev, qmp_combo_typec_unregister, qmp);
> + ret = devm_add_action_or_reset(dev, qmp_combo_typec_switch_unregister, qmp);
> + if (ret)
> + return ret;
> +
> + mux_desc.drvdata = qmp;
> + mux_desc.fwnode = dev->fwnode;
> + mux_desc.set = qmp_combo_typec_mux_set;
> + qmp->mux = typec_mux_register(dev, &mux_desc);
> + if (IS_ERR(qmp->mux)) {
> + dev_err(dev, "Unable to register typec mux: %pe\n", qmp->mux);
> + return PTR_ERR(qmp->mux);
> + }
> +
> + return devm_add_action_or_reset(dev, qmp_combo_typec_mux_unregister, qmp);
> }
> #else
> -static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
> +static int qmp_combo_typec_register(struct qmp_combo *qmp)
> {
> return 0;
> }
> @@ -3532,7 +3644,7 @@ static int qmp_combo_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - ret = qmp_combo_typec_switch_register(qmp);
> + ret = qmp_combo_typec_register(qmp);
> if (ret)
> return ret;
>
>
> --
> 2.34.1
>
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
2024-02-29 15:25 ` Dmitry Baryshkov
@ 2024-02-29 15:47 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 15:47 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
On 29/02/2024 16:25, Dmitry Baryshkov wrote:
> On Thu, 29 Feb 2024 at 15:08, Neil Armstrong <neil.armstrong@linaro.org> 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.
>
> I think this is not fully correct. Please correct me if I'm wrong, but
> it is possible to switch between USB / USB+DP / DP-only at runtime.
> See the Status Update and Configure commands.
Yes, but the current implementation is still valid because we need to
have the DP powered-off before changing the PHY mode.
I never encountered such setup and I have no idea how to test this.
>
>>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 122 ++++++++++++++++++++++++++++--
>> 1 file changed, 117 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
>> index ac5d528fd7a1..b5fb6cbcf867 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
>> @@ -19,6 +19,7 @@
>> #include <linux/reset.h>
>> #include <linux/slab.h>
>> #include <linux/usb/typec.h>
>> +#include <linux/usb/typec_dp.h>
>> #include <linux/usb/typec_mux.h>
>>
>> #include <drm/bridge/aux-bridge.h>
>> @@ -1515,6 +1516,10 @@ struct qmp_combo {
>>
>> struct typec_switch_dev *sw;
>> enum typec_orientation orientation;
>> +
>> + struct typec_mux_dev *mux;
>> + unsigned long mux_mode;
>> + unsigned int svid;
>> };
>>
>> static void qmp_v3_dp_aux_init(struct qmp_combo *qmp);
>> @@ -3295,17 +3300,111 @@ static int qmp_combo_typec_switch_set(struct typec_switch_dev *sw,
>> return 0;
>> }
>>
>> -static void qmp_combo_typec_unregister(void *data)
>> +static int qmp_combo_typec_mux_set(struct typec_mux_dev *mux, struct typec_mux_state *state)
>> +{
>> + struct qmp_combo *qmp = typec_mux_get_drvdata(mux);
>> + const struct qmp_phy_cfg *cfg = qmp->cfg;
>> + enum qphy_mode new_mode;
>> + unsigned int svid;
>> +
>> + if (state->mode == qmp->mode)
>> + return 0;
>> +
>> + mutex_lock(&qmp->phy_mutex);
>> +
>> + if (state->alt)
>> + svid = state->alt->svid;
>> + else
>> + svid = 0; // No SVID
>> +
>> + if (svid) {
>
> We should check svid against USB_TYPEC_DP_SID. Otherwise the driver
> will mishandle the USB_SID_PD states.
Ack will do
>
>> + switch (state->mode) {
>> + /* DP Only */
>> + case TYPEC_DP_STATE_C:
>> + case TYPEC_DP_STATE_E:
>> + new_mode = QPHY_MODE_DP_ONLY;
>> + break;
>> +
>> + /* DP + USB */
>> + case TYPEC_DP_STATE_D:
>> + case TYPEC_DP_STATE_F:
>> + /* Safe fallback...*/
>> + default:
>> + new_mode = QPHY_MODE_COMBO;
>> + break;
>> + }
>> + } else {
>> + /* Only switch to USB_ONLY when we know we only have USB3 */
>> + if (qmp->mux_mode == TYPEC_MODE_USB3)
>> + new_mode = QPHY_MODE_USB_ONLY;
>> + else
>> + new_mode = QPHY_MODE_COMBO;
>> + }
>> +
>> + if (new_mode == qmp->init_mode) {
>> + dev_dbg(qmp->dev, "typec_mux_set: same phy mode, bail out\n");
>> + qmp->mode = state->mode;
>> + goto out;
>> + }
>> +
>> + if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_powered_on) {
>> + dev_dbg(qmp->dev, "typec_mux_set: DP is still powered on, delaying switch\n");
>> + goto out;
>> + }
>> +
>> + dev_dbg(qmp->dev, "typec_mux_set: switching from phy mode %d to %d\n",
>> + qmp->init_mode, new_mode);
>> +
>> + qmp->mux_mode = state->mode;
>> + qmp->init_mode = new_mode;
>> +
>> + if (qmp->init_count) {
>> + if (qmp->usb_init_count)
>> + qmp_combo_usb_power_off(qmp->usb_phy);
>> + if (qmp->dp_init_count)
>> + writel(DP_PHY_PD_CTL_PSR_PWRDN, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
>> + qmp_combo_com_exit(qmp, true);
>> +
>> + /* Now everything's powered down, power up the right PHYs */
>> +
>> + qmp_combo_com_init(qmp, true);
>> + if (qmp->init_mode == QPHY_MODE_DP_ONLY && qmp->usb_init_count) {
>> + qmp->usb_init_count--;
>> + } else if (qmp->init_mode != QPHY_MODE_DP_ONLY) {
>> + qmp_combo_usb_power_on(qmp->usb_phy);
>> + if (!qmp->usb_init_count)
>> + qmp->usb_init_count++;
>> + }
>> + if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_init_count)
>> + cfg->dp_aux_init(qmp);
>> + }
>> +
>> +out:
>> + mutex_unlock(&qmp->phy_mutex);
>> +
>> + return 0;
>> +}
>> +
>> +static void qmp_combo_typec_switch_unregister(void *data)
>> {
>> struct qmp_combo *qmp = data;
>>
>> typec_switch_unregister(qmp->sw);
>> }
>>
>> -static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
>> +static void qmp_combo_typec_mux_unregister(void *data)
>> +{
>> + struct qmp_combo *qmp = data;
>> +
>> + typec_mux_unregister(qmp->mux);
>> +}
>> +
>> +static int qmp_combo_typec_register(struct qmp_combo *qmp)
>> {
>> struct typec_switch_desc sw_desc = {};
>> + struct typec_mux_desc mux_desc = { };
>> struct device *dev = qmp->dev;
>> + int ret;
>>
>> sw_desc.drvdata = qmp;
>> sw_desc.fwnode = dev->fwnode;
>> @@ -3316,10 +3415,23 @@ static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
>> return PTR_ERR(qmp->sw);
>> }
>>
>> - return devm_add_action_or_reset(dev, qmp_combo_typec_unregister, qmp);
>> + ret = devm_add_action_or_reset(dev, qmp_combo_typec_switch_unregister, qmp);
>> + if (ret)
>> + return ret;
>> +
>> + mux_desc.drvdata = qmp;
>> + mux_desc.fwnode = dev->fwnode;
>> + mux_desc.set = qmp_combo_typec_mux_set;
>> + qmp->mux = typec_mux_register(dev, &mux_desc);
>> + if (IS_ERR(qmp->mux)) {
>> + dev_err(dev, "Unable to register typec mux: %pe\n", qmp->mux);
>> + return PTR_ERR(qmp->mux);
>> + }
>> +
>> + return devm_add_action_or_reset(dev, qmp_combo_typec_mux_unregister, qmp);
>> }
>> #else
>> -static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
>> +static int qmp_combo_typec_register(struct qmp_combo *qmp)
>> {
>> return 0;
>> }
>> @@ -3532,7 +3644,7 @@ static int qmp_combo_probe(struct platform_device *pdev)
>> if (ret)
>> return ret;
>>
>> - ret = qmp_combo_typec_switch_register(qmp);
>> + ret = qmp_combo_typec_register(qmp);
>> if (ret)
>> return ret;
>>
>>
>> --
>> 2.34.1
>>
>>
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
@ 2024-02-29 15:47 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-02-29 15:47 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
On 29/02/2024 16:25, Dmitry Baryshkov wrote:
> On Thu, 29 Feb 2024 at 15:08, Neil Armstrong <neil.armstrong@linaro.org> 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.
>
> I think this is not fully correct. Please correct me if I'm wrong, but
> it is possible to switch between USB / USB+DP / DP-only at runtime.
> See the Status Update and Configure commands.
Yes, but the current implementation is still valid because we need to
have the DP powered-off before changing the PHY mode.
I never encountered such setup and I have no idea how to test this.
>
>>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 122 ++++++++++++++++++++++++++++--
>> 1 file changed, 117 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
>> index ac5d528fd7a1..b5fb6cbcf867 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
>> @@ -19,6 +19,7 @@
>> #include <linux/reset.h>
>> #include <linux/slab.h>
>> #include <linux/usb/typec.h>
>> +#include <linux/usb/typec_dp.h>
>> #include <linux/usb/typec_mux.h>
>>
>> #include <drm/bridge/aux-bridge.h>
>> @@ -1515,6 +1516,10 @@ struct qmp_combo {
>>
>> struct typec_switch_dev *sw;
>> enum typec_orientation orientation;
>> +
>> + struct typec_mux_dev *mux;
>> + unsigned long mux_mode;
>> + unsigned int svid;
>> };
>>
>> static void qmp_v3_dp_aux_init(struct qmp_combo *qmp);
>> @@ -3295,17 +3300,111 @@ static int qmp_combo_typec_switch_set(struct typec_switch_dev *sw,
>> return 0;
>> }
>>
>> -static void qmp_combo_typec_unregister(void *data)
>> +static int qmp_combo_typec_mux_set(struct typec_mux_dev *mux, struct typec_mux_state *state)
>> +{
>> + struct qmp_combo *qmp = typec_mux_get_drvdata(mux);
>> + const struct qmp_phy_cfg *cfg = qmp->cfg;
>> + enum qphy_mode new_mode;
>> + unsigned int svid;
>> +
>> + if (state->mode == qmp->mode)
>> + return 0;
>> +
>> + mutex_lock(&qmp->phy_mutex);
>> +
>> + if (state->alt)
>> + svid = state->alt->svid;
>> + else
>> + svid = 0; // No SVID
>> +
>> + if (svid) {
>
> We should check svid against USB_TYPEC_DP_SID. Otherwise the driver
> will mishandle the USB_SID_PD states.
Ack will do
>
>> + switch (state->mode) {
>> + /* DP Only */
>> + case TYPEC_DP_STATE_C:
>> + case TYPEC_DP_STATE_E:
>> + new_mode = QPHY_MODE_DP_ONLY;
>> + break;
>> +
>> + /* DP + USB */
>> + case TYPEC_DP_STATE_D:
>> + case TYPEC_DP_STATE_F:
>> + /* Safe fallback...*/
>> + default:
>> + new_mode = QPHY_MODE_COMBO;
>> + break;
>> + }
>> + } else {
>> + /* Only switch to USB_ONLY when we know we only have USB3 */
>> + if (qmp->mux_mode == TYPEC_MODE_USB3)
>> + new_mode = QPHY_MODE_USB_ONLY;
>> + else
>> + new_mode = QPHY_MODE_COMBO;
>> + }
>> +
>> + if (new_mode == qmp->init_mode) {
>> + dev_dbg(qmp->dev, "typec_mux_set: same phy mode, bail out\n");
>> + qmp->mode = state->mode;
>> + goto out;
>> + }
>> +
>> + if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_powered_on) {
>> + dev_dbg(qmp->dev, "typec_mux_set: DP is still powered on, delaying switch\n");
>> + goto out;
>> + }
>> +
>> + dev_dbg(qmp->dev, "typec_mux_set: switching from phy mode %d to %d\n",
>> + qmp->init_mode, new_mode);
>> +
>> + qmp->mux_mode = state->mode;
>> + qmp->init_mode = new_mode;
>> +
>> + if (qmp->init_count) {
>> + if (qmp->usb_init_count)
>> + qmp_combo_usb_power_off(qmp->usb_phy);
>> + if (qmp->dp_init_count)
>> + writel(DP_PHY_PD_CTL_PSR_PWRDN, qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
>> + qmp_combo_com_exit(qmp, true);
>> +
>> + /* Now everything's powered down, power up the right PHYs */
>> +
>> + qmp_combo_com_init(qmp, true);
>> + if (qmp->init_mode == QPHY_MODE_DP_ONLY && qmp->usb_init_count) {
>> + qmp->usb_init_count--;
>> + } else if (qmp->init_mode != QPHY_MODE_DP_ONLY) {
>> + qmp_combo_usb_power_on(qmp->usb_phy);
>> + if (!qmp->usb_init_count)
>> + qmp->usb_init_count++;
>> + }
>> + if (qmp->init_mode != QPHY_MODE_USB_ONLY && qmp->dp_init_count)
>> + cfg->dp_aux_init(qmp);
>> + }
>> +
>> +out:
>> + mutex_unlock(&qmp->phy_mutex);
>> +
>> + return 0;
>> +}
>> +
>> +static void qmp_combo_typec_switch_unregister(void *data)
>> {
>> struct qmp_combo *qmp = data;
>>
>> typec_switch_unregister(qmp->sw);
>> }
>>
>> -static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
>> +static void qmp_combo_typec_mux_unregister(void *data)
>> +{
>> + struct qmp_combo *qmp = data;
>> +
>> + typec_mux_unregister(qmp->mux);
>> +}
>> +
>> +static int qmp_combo_typec_register(struct qmp_combo *qmp)
>> {
>> struct typec_switch_desc sw_desc = {};
>> + struct typec_mux_desc mux_desc = { };
>> struct device *dev = qmp->dev;
>> + int ret;
>>
>> sw_desc.drvdata = qmp;
>> sw_desc.fwnode = dev->fwnode;
>> @@ -3316,10 +3415,23 @@ static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
>> return PTR_ERR(qmp->sw);
>> }
>>
>> - return devm_add_action_or_reset(dev, qmp_combo_typec_unregister, qmp);
>> + ret = devm_add_action_or_reset(dev, qmp_combo_typec_switch_unregister, qmp);
>> + if (ret)
>> + return ret;
>> +
>> + mux_desc.drvdata = qmp;
>> + mux_desc.fwnode = dev->fwnode;
>> + mux_desc.set = qmp_combo_typec_mux_set;
>> + qmp->mux = typec_mux_register(dev, &mux_desc);
>> + if (IS_ERR(qmp->mux)) {
>> + dev_err(dev, "Unable to register typec mux: %pe\n", qmp->mux);
>> + return PTR_ERR(qmp->mux);
>> + }
>> +
>> + return devm_add_action_or_reset(dev, qmp_combo_typec_mux_unregister, qmp);
>> }
>> #else
>> -static int qmp_combo_typec_switch_register(struct qmp_combo *qmp)
>> +static int qmp_combo_typec_register(struct qmp_combo *qmp)
>> {
>> return 0;
>> }
>> @@ -3532,7 +3644,7 @@ static int qmp_combo_probe(struct platform_device *pdev)
>> if (ret)
>> return ret;
>>
>> - ret = qmp_combo_typec_switch_register(qmp);
>> + ret = qmp_combo_typec_register(qmp);
>> if (ret)
>> return ret;
>>
>>
>> --
>> 2.34.1
>>
>>
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
2024-02-29 15:47 ` Neil Armstrong
@ 2024-02-29 15:54 ` Dmitry Baryshkov
-1 siblings, 0 replies; 54+ messages in thread
From: Dmitry Baryshkov @ 2024-02-29 15:54 UTC (permalink / raw)
To: neil.armstrong
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
On Thu, 29 Feb 2024 at 17:47, Neil Armstrong <neil.armstrong@linaro.org> wrote:
>
> On 29/02/2024 16:25, Dmitry Baryshkov wrote:
> > On Thu, 29 Feb 2024 at 15:08, Neil Armstrong <neil.armstrong@linaro.org> 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.
> >
> > I think this is not fully correct. Please correct me if I'm wrong, but
> > it is possible to switch between USB / USB+DP / DP-only at runtime.
> > See the Status Update and Configure commands.
>
> Yes, but the current implementation is still valid because we need to
> have the DP powered-off before changing the PHY mode.
Even for switching between 2 lane and 4 lane modes?
I'll check how my USB-A+DP dongles work with respect to the altmode
configuration.
>
> I never encountered such setup and I have no idea how to test this.
>
> >
> >>
> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
@ 2024-02-29 15:54 ` Dmitry Baryshkov
0 siblings, 0 replies; 54+ messages in thread
From: Dmitry Baryshkov @ 2024-02-29 15:54 UTC (permalink / raw)
To: neil.armstrong
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
On Thu, 29 Feb 2024 at 17:47, Neil Armstrong <neil.armstrong@linaro.org> wrote:
>
> On 29/02/2024 16:25, Dmitry Baryshkov wrote:
> > On Thu, 29 Feb 2024 at 15:08, Neil Armstrong <neil.armstrong@linaro.org> 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.
> >
> > I think this is not fully correct. Please correct me if I'm wrong, but
> > it is possible to switch between USB / USB+DP / DP-only at runtime.
> > See the Status Update and Configure commands.
>
> Yes, but the current implementation is still valid because we need to
> have the DP powered-off before changing the PHY mode.
Even for switching between 2 lane and 4 lane modes?
I'll check how my USB-A+DP dongles work with respect to the altmode
configuration.
>
> I never encountered such setup and I have no idea how to test this.
>
> >
> >>
> >> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
2024-02-29 15:54 ` Dmitry Baryshkov
@ 2024-02-29 15:57 ` neil.armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: neil.armstrong @ 2024-02-29 15:57 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
On 29/02/2024 16:54, Dmitry Baryshkov wrote:
> On Thu, 29 Feb 2024 at 17:47, Neil Armstrong <neil.armstrong@linaro.org> wrote:
>>
>> On 29/02/2024 16:25, Dmitry Baryshkov wrote:
>>> On Thu, 29 Feb 2024 at 15:08, Neil Armstrong <neil.armstrong@linaro.org> 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.
>>>
>>> I think this is not fully correct. Please correct me if I'm wrong, but
>>> it is possible to switch between USB / USB+DP / DP-only at runtime.
>>> See the Status Update and Configure commands.
>>
>> Yes, but the current implementation is still valid because we need to
>> have the DP powered-off before changing the PHY mode.
>
> Even for switching between 2 lane and 4 lane modes?
So the Altmode pin assignment says how much lanes you can get (2 or 4),
and AUX data will say how much the adapter/display supports.
My native DP monitor uses the 4 lanes, while my USB-C->HDMI dongles
declares the 4lanes pin assigment but DP controller only ever tries 2 lanes.
I don't have USB-C->HDMI with 4lanes DP, but it should work fine.
Neil
>
> I'll check how my USB-A+DP dongles work with respect to the altmode
> configuration.
>
>>
>> I never encountered such setup and I have no idea how to test this.
>>
>>>
>>>>
>>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE
@ 2024-02-29 15:57 ` neil.armstrong
0 siblings, 0 replies; 54+ messages in thread
From: neil.armstrong @ 2024-02-29 15:57 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
On 29/02/2024 16:54, Dmitry Baryshkov wrote:
> On Thu, 29 Feb 2024 at 17:47, Neil Armstrong <neil.armstrong@linaro.org> wrote:
>>
>> On 29/02/2024 16:25, Dmitry Baryshkov wrote:
>>> On Thu, 29 Feb 2024 at 15:08, Neil Armstrong <neil.armstrong@linaro.org> 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.
>>>
>>> I think this is not fully correct. Please correct me if I'm wrong, but
>>> it is possible to switch between USB / USB+DP / DP-only at runtime.
>>> See the Status Update and Configure commands.
>>
>> Yes, but the current implementation is still valid because we need to
>> have the DP powered-off before changing the PHY mode.
>
> Even for switching between 2 lane and 4 lane modes?
So the Altmode pin assignment says how much lanes you can get (2 or 4),
and AUX data will say how much the adapter/display supports.
My native DP monitor uses the 4 lanes, while my USB-C->HDMI dongles
declares the 4lanes pin assigment but DP controller only ever tries 2 lanes.
I don't have USB-C->HDMI with 4lanes DP, but it should work fine.
Neil
>
> I'll check how my USB-A+DP dongles work with respect to the altmode
> configuration.
>
>>
>> I never encountered such setup and I have no idea how to test this.
>>
>>>
>>>>
>>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 7/7] arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
2024-02-29 13:07 ` Neil Armstrong
@ 2024-03-01 3:00 ` Bjorn Andersson
-1 siblings, 0 replies; 54+ messages in thread
From: Bjorn Andersson @ 2024-03-01 3:00 UTC (permalink / raw)
To: Neil Armstrong
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
devicetree, linux-kernel
On Thu, Feb 29, 2024 at 02:07:07PM +0100, Neil Armstrong wrote:
> Allow up to 4 lanes for the DisplayPort link from the PHYs to the Controllers
> and allow mode-switch events to the QMP Combo PHYs.
>
Please adjust $subject and commit message to suite the x13s.dts...
With this series I'm reaching 4k@60 on my X13s (with some difficulty due
to current hotplug issues in the DP driver) - but 4-lane DP works, and
so does 2-lane combo.
I tested switching between DP-only and a USB device, this worked fine a
few (3-4) times, after which the USB device stopped showing up. The DP
display continued to work nicely and the debug prints from the driver
indicates that we're moving back and forth between the modes...
The problems I had when trying to implement this previously, with the
device crashing on disconnect have not been seen, across 20+
attempts.
Regards,
Bjorn
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index a0fdef55a40a..6c73e0fc001f 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -556,7 +556,7 @@ &mdss0_dp0 {
> };
>
> &mdss0_dp0_out {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
> remote-endpoint = <&usb_0_qmpphy_dp_in>;
> };
>
> @@ -565,7 +565,7 @@ &mdss0_dp1 {
> };
>
> &mdss0_dp1_out {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
> remote-endpoint = <&usb_1_qmpphy_dp_in>;
> };
>
> @@ -1112,6 +1112,7 @@ &usb_0_qmpphy {
> vdda-phy-supply = <&vreg_l9d>;
> vdda-pll-supply = <&vreg_l4d>;
>
> + mode-switch;
> orientation-switch;
>
> status = "okay";
> @@ -1149,6 +1150,7 @@ &usb_1_qmpphy {
> vdda-phy-supply = <&vreg_l4b>;
> vdda-pll-supply = <&vreg_l3b>;
>
> + mode-switch;
> orientation-switch;
>
> status = "okay";
>
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 7/7] arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
@ 2024-03-01 3:00 ` Bjorn Andersson
0 siblings, 0 replies; 54+ messages in thread
From: Bjorn Andersson @ 2024-03-01 3:00 UTC (permalink / raw)
To: Neil Armstrong
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
devicetree, linux-kernel
On Thu, Feb 29, 2024 at 02:07:07PM +0100, Neil Armstrong wrote:
> Allow up to 4 lanes for the DisplayPort link from the PHYs to the Controllers
> and allow mode-switch events to the QMP Combo PHYs.
>
Please adjust $subject and commit message to suite the x13s.dts...
With this series I'm reaching 4k@60 on my X13s (with some difficulty due
to current hotplug issues in the DP driver) - but 4-lane DP works, and
so does 2-lane combo.
I tested switching between DP-only and a USB device, this worked fine a
few (3-4) times, after which the USB device stopped showing up. The DP
display continued to work nicely and the debug prints from the driver
indicates that we're moving back and forth between the modes...
The problems I had when trying to implement this previously, with the
device crashing on disconnect have not been seen, across 20+
attempts.
Regards,
Bjorn
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index a0fdef55a40a..6c73e0fc001f 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -556,7 +556,7 @@ &mdss0_dp0 {
> };
>
> &mdss0_dp0_out {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
> remote-endpoint = <&usb_0_qmpphy_dp_in>;
> };
>
> @@ -565,7 +565,7 @@ &mdss0_dp1 {
> };
>
> &mdss0_dp1_out {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
> remote-endpoint = <&usb_1_qmpphy_dp_in>;
> };
>
> @@ -1112,6 +1112,7 @@ &usb_0_qmpphy {
> vdda-phy-supply = <&vreg_l9d>;
> vdda-pll-supply = <&vreg_l4d>;
>
> + mode-switch;
> orientation-switch;
>
> status = "okay";
> @@ -1149,6 +1150,7 @@ &usb_1_qmpphy {
> vdda-phy-supply = <&vreg_l4b>;
> vdda-pll-supply = <&vreg_l3b>;
>
> + mode-switch;
> orientation-switch;
>
> status = "okay";
>
> --
> 2.34.1
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 7/7] arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
2024-03-01 3:00 ` Bjorn Andersson
@ 2024-03-01 18:31 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-03-01 18:31 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
devicetree, linux-kernel
On 01/03/2024 04:00, Bjorn Andersson wrote:
> On Thu, Feb 29, 2024 at 02:07:07PM +0100, Neil Armstrong wrote:
>> Allow up to 4 lanes for the DisplayPort link from the PHYs to the Controllers
>> and allow mode-switch events to the QMP Combo PHYs.
>>
>
> Please adjust $subject and commit message to suite the x13s.dts...
Sure I realized this after sending the patches....
>
>
> With this series I'm reaching 4k@60 on my X13s (with some difficulty due
> to current hotplug issues in the DP driver) - but 4-lane DP works, and
> so does 2-lane combo.
>
> I tested switching between DP-only and a USB device, this worked fine a
> few (3-4) times, after which the USB device stopped showing up. The DP
> display continued to work nicely and the debug prints from the driver
> indicates that we're moving back and forth between the modes...
>
> The problems I had when trying to implement this previously, with the
> device crashing on disconnect have not been seen, across 20+
> attempts.
Greatm nice this was fixed!
I also experienced USB issue after a few connect/disconnects, it seems that messing
with the USB PHY doesn't make DWC3 very happy, not sure how we could actually fix that.
Thx for testing!
Neil
>
> Regards,
> Bjorn
>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
>> index a0fdef55a40a..6c73e0fc001f 100644
>> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
>> @@ -556,7 +556,7 @@ &mdss0_dp0 {
>> };
>>
>> &mdss0_dp0_out {
>> - data-lanes = <0 1>;
>> + data-lanes = <0 1 2 3>;
>> remote-endpoint = <&usb_0_qmpphy_dp_in>;
>> };
>>
>> @@ -565,7 +565,7 @@ &mdss0_dp1 {
>> };
>>
>> &mdss0_dp1_out {
>> - data-lanes = <0 1>;
>> + data-lanes = <0 1 2 3>;
>> remote-endpoint = <&usb_1_qmpphy_dp_in>;
>> };
>>
>> @@ -1112,6 +1112,7 @@ &usb_0_qmpphy {
>> vdda-phy-supply = <&vreg_l9d>;
>> vdda-pll-supply = <&vreg_l4d>;
>>
>> + mode-switch;
>> orientation-switch;
>>
>> status = "okay";
>> @@ -1149,6 +1150,7 @@ &usb_1_qmpphy {
>> vdda-phy-supply = <&vreg_l4b>;
>> vdda-pll-supply = <&vreg_l3b>;
>>
>> + mode-switch;
>> orientation-switch;
>>
>> status = "okay";
>>
>> --
>> 2.34.1
>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 7/7] arm64: dts: qcom-mode-switch: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch
@ 2024-03-01 18:31 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-03-01 18:31 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
devicetree, linux-kernel
On 01/03/2024 04:00, Bjorn Andersson wrote:
> On Thu, Feb 29, 2024 at 02:07:07PM +0100, Neil Armstrong wrote:
>> Allow up to 4 lanes for the DisplayPort link from the PHYs to the Controllers
>> and allow mode-switch events to the QMP Combo PHYs.
>>
>
> Please adjust $subject and commit message to suite the x13s.dts...
Sure I realized this after sending the patches....
>
>
> With this series I'm reaching 4k@60 on my X13s (with some difficulty due
> to current hotplug issues in the DP driver) - but 4-lane DP works, and
> so does 2-lane combo.
>
> I tested switching between DP-only and a USB device, this worked fine a
> few (3-4) times, after which the USB device stopped showing up. The DP
> display continued to work nicely and the debug prints from the driver
> indicates that we're moving back and forth between the modes...
>
> The problems I had when trying to implement this previously, with the
> device crashing on disconnect have not been seen, across 20+
> attempts.
Greatm nice this was fixed!
I also experienced USB issue after a few connect/disconnects, it seems that messing
with the USB PHY doesn't make DWC3 very happy, not sure how we could actually fix that.
Thx for testing!
Neil
>
> Regards,
> Bjorn
>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
>> index a0fdef55a40a..6c73e0fc001f 100644
>> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
>> @@ -556,7 +556,7 @@ &mdss0_dp0 {
>> };
>>
>> &mdss0_dp0_out {
>> - data-lanes = <0 1>;
>> + data-lanes = <0 1 2 3>;
>> remote-endpoint = <&usb_0_qmpphy_dp_in>;
>> };
>>
>> @@ -565,7 +565,7 @@ &mdss0_dp1 {
>> };
>>
>> &mdss0_dp1_out {
>> - data-lanes = <0 1>;
>> + data-lanes = <0 1 2 3>;
>> remote-endpoint = <&usb_1_qmpphy_dp_in>;
>> };
>>
>> @@ -1112,6 +1112,7 @@ &usb_0_qmpphy {
>> vdda-phy-supply = <&vreg_l9d>;
>> vdda-pll-supply = <&vreg_l4d>;
>>
>> + mode-switch;
>> orientation-switch;
>>
>> status = "okay";
>> @@ -1149,6 +1150,7 @@ &usb_1_qmpphy {
>> vdda-phy-supply = <&vreg_l4b>;
>> vdda-pll-supply = <&vreg_l3b>;
>>
>> + mode-switch;
>> orientation-switch;
>>
>> status = "okay";
>>
>> --
>> 2.34.1
>>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 1/7] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp: Add mode-switch
2024-02-29 13:07 ` Neil Armstrong
@ 2024-03-04 16:22 ` Rob Herring
-1 siblings, 0 replies; 54+ messages in thread
From: Rob Herring @ 2024-03-04 16:22 UTC (permalink / raw)
To: Neil Armstrong
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-phy, devicetree, linux-kernel
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 <neil.armstrong@linaro.org>
> ---
> .../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
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 1/7] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp: Add mode-switch
@ 2024-03-04 16:22 ` Rob Herring
0 siblings, 0 replies; 54+ messages in thread
From: Rob Herring @ 2024-03-04 16:22 UTC (permalink / raw)
To: Neil Armstrong
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-phy, devicetree, linux-kernel
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 <neil.armstrong@linaro.org>
> ---
> .../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
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
2024-02-29 13:07 ` Neil Armstrong
@ 2024-03-15 17:19 ` Luca Weiss
-1 siblings, 0 replies; 54+ messages in thread
From: Luca Weiss @ 2024-03-15 17:19 UTC (permalink / raw)
To: Neil Armstrong, Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
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 <neil.armstrong@linaro.org>
> ---
> 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,
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-03-15 17:19 ` Luca Weiss
0 siblings, 0 replies; 54+ messages in thread
From: Luca Weiss @ 2024-03-15 17:19 UTC (permalink / raw)
To: Neil Armstrong, Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
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 <neil.armstrong@linaro.org>
> ---
> 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,
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
2024-03-15 17:19 ` Luca Weiss
@ 2024-03-15 17:35 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-03-15 17:35 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abhinav Kumar
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
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 <neil.armstrong@linaro.org>
>> ---
>> 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,
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-03-15 17:35 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-03-15 17:35 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abhinav Kumar
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
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 <neil.armstrong@linaro.org>
>> ---
>> 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,
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
2024-03-15 17:35 ` Neil Armstrong
@ 2024-03-16 16:01 ` Bjorn Andersson
-1 siblings, 0 replies; 54+ messages in thread
From: Bjorn Andersson @ 2024-03-16 16:01 UTC (permalink / raw)
To: Neil Armstrong
Cc: Luca Weiss, Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar,
linux-arm-msm, linux-phy, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-03-16 16:01 ` Bjorn Andersson
0 siblings, 0 replies; 54+ messages in thread
From: Bjorn Andersson @ 2024-03-16 16:01 UTC (permalink / raw)
To: Neil Armstrong
Cc: Luca Weiss, Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar,
linux-arm-msm, linux-phy, devicetree, linux-kernel
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
2024-03-16 16:01 ` Bjorn Andersson
@ 2024-03-18 10:45 ` Luca Weiss
-1 siblings, 0 replies; 54+ messages in thread
From: Luca Weiss @ 2024-03-18 10:45 UTC (permalink / raw)
To: Bjorn Andersson, Neil Armstrong
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-03-18 10:45 ` Luca Weiss
0 siblings, 0 replies; 54+ messages in thread
From: Luca Weiss @ 2024-03-18 10:45 UTC (permalink / raw)
To: Bjorn Andersson, Neil Armstrong
Cc: Konrad Dybcio, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
On Sat Mar 16, 2024 at 5:01 PM CET, Bjorn Andersson wrote:
> On Fri, Mar 15, 2024 at 06:35:15PM +0100, Neil Armstrong wrote:
> > On 15/03/2024 18:19, Luca Weiss wrote:
> > > On Thu Feb 29, 2024 at 2:07 PM CET, Neil Armstrong wrote:
> > > > Register a typec mux in order to change the PHY mode on the Type-C
> > > > mux events depending on the mode and the svid when in Altmode setup.
> > > >
> > > > The DisplayPort phy should be left enabled if is still powered on
> > > > by the DRM DisplayPort controller, so bail out until the DisplayPort
> > > > PHY is not powered off.
> > > >
> > > > The Type-C Mode/SVID only changes on plug/unplug, and USB SAFE states
> > > > will be set in between of USB-Only, Combo and DisplayPort Only so
> > > > this will leave enough time to the DRM DisplayPort controller to
> > > > turn of the DisplayPort PHY.
> > > >
> > > > The patchset also includes bindings changes and DT changes.
> > > >
> > > > This has been successfully tested on an SM8550 board, but the
> > > > Thinkpad X13s deserved testing between non-PD USB, non-PD DisplayPort,
> > > > PD USB Hubs and PD Altmode Dongles to make sure the switch works
> > > > as expected.
> > > >
> > > > The DisplayPort 4 lanes setup can be check with:
> > > > $ cat /sys/kernel/debug/dri/ae01000.display-controller/DP-1/dp_debug
> > > > name = msm_dp
> > > > drm_dp_link
> > > > rate = 540000
> > > > num_lanes = 4
> > >
> > > Hi Neil,
> > >
> > > I tried this on QCM6490/SC7280 which should also support 4-lane DP but I
> > > haven't had any success so far.
> > >
> [..]
> > > [ 1775.563969] [drm:dp_ctrl_link_train] *ERROR* max v_level reached
> > > [ 1775.564031] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11
> >
> > Interesting #1 means the 4 lanes are not physically connected to the other side,
> > perhaps QCM6490/SC7280 requires a specific way to enable the 4 lanes in the PHY,
> > or some fixups in the init tables.
> >
>
> I tested the same on rb3gen2 (qcs6490) a couple of weeks ago, with the
> same outcome. Looking at the AUX reads, after switching to 4-lane the
> link training is failing on all 4 lanes, in contrast to succeeding only
> on the first 2 if you e.g. forget to mux the other two.
Good to know it's not just my device then ;)
>
> As such, my expectation is that there's something wrong in the QMP PHY
> (or possibly redriver) for this platform.
Since I imagine rb3gen2 uses a different redriver setup compared to FP5,
I wouldn't say that's at fault for now? And at least my ptn36502 driver
only has very little difference between 2-lane and 4-lane setup, only
setting the mode to DP-only and 4-lane (vs USB+DP and 2-lane), nothing
else.
Regards
Luca
>
> Regards,
> Bjorn
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
2024-03-16 16:01 ` Bjorn Andersson
@ 2024-03-26 21:02 ` Konrad Dybcio
-1 siblings, 0 replies; 54+ messages in thread
From: Konrad Dybcio @ 2024-03-26 21:02 UTC (permalink / raw)
To: Bjorn Andersson, Neil Armstrong
Cc: Luca Weiss, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-03-26 21:02 ` Konrad Dybcio
0 siblings, 0 replies; 54+ messages in thread
From: Konrad Dybcio @ 2024-03-26 21:02 UTC (permalink / raw)
To: Bjorn Andersson, Neil Armstrong
Cc: Luca Weiss, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
2024-03-26 21:02 ` Konrad Dybcio
@ 2024-03-29 9:02 ` Luca Weiss
-1 siblings, 0 replies; 54+ messages in thread
From: Luca Weiss @ 2024-03-29 9:02 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Neil Armstrong
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-03-29 9:02 ` Luca Weiss
0 siblings, 0 replies; 54+ messages in thread
From: Luca Weiss @ 2024-03-29 9:02 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Neil Armstrong
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 3/7] phy: qcom: qmp-combo: introduce QPHY_MODE
2024-02-29 13:07 ` Neil Armstrong
@ 2024-03-29 16:56 ` Vinod Koul
-1 siblings, 0 replies; 54+ messages in thread
From: Vinod Koul @ 2024-03-29 16:56 UTC (permalink / raw)
To: Neil Armstrong
Cc: Bjorn Andersson, Konrad Dybcio, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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 <neil.armstrong@linaro.org>
> ---
> 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 3/7] phy: qcom: qmp-combo: introduce QPHY_MODE
@ 2024-03-29 16:56 ` Vinod Koul
0 siblings, 0 replies; 54+ messages in thread
From: Vinod Koul @ 2024-03-29 16:56 UTC (permalink / raw)
To: Neil Armstrong
Cc: Bjorn Andersson, Konrad Dybcio, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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 <neil.armstrong@linaro.org>
> ---
> 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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
2024-03-29 9:02 ` Luca Weiss
@ 2024-04-05 8:08 ` Neil Armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-04-05 8:08 UTC (permalink / raw)
To: Luca Weiss, Konrad Dybcio, Bjorn Andersson
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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/20240405000111.1450598-1-swboyd@chromium.org/
Thanks,
Neil
>
> Regards
> Luca
>
>>
>> Konrad
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-04-05 8:08 ` Neil Armstrong
0 siblings, 0 replies; 54+ messages in thread
From: Neil Armstrong @ 2024-04-05 8:08 UTC (permalink / raw)
To: Luca Weiss, Konrad Dybcio, Bjorn Andersson
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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/20240405000111.1450598-1-swboyd@chromium.org/
Thanks,
Neil
>
> Regards
> Luca
>
>>
>> Konrad
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
2024-04-05 8:08 ` Neil Armstrong
@ 2024-04-05 10:19 ` Luca Weiss
-1 siblings, 0 replies; 54+ messages in thread
From: Luca Weiss @ 2024-04-05 10:19 UTC (permalink / raw)
To: neil.armstrong, Konrad Dybcio, Bjorn Andersson
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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/20240405000111.1450598-1-swboyd@chromium.org/
Unfortunately I do not see any change with this on QCM6490 Fairphone 5
and 4-lane DP.
Regards
Luca
>
> Thanks,
> Neil
>
> >
> > Regards
> > Luca
> >
> >>
> >> Konrad
> >
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-04-05 10:19 ` Luca Weiss
0 siblings, 0 replies; 54+ messages in thread
From: Luca Weiss @ 2024-04-05 10:19 UTC (permalink / raw)
To: neil.armstrong, Konrad Dybcio, Bjorn Andersson
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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/20240405000111.1450598-1-swboyd@chromium.org/
Unfortunately I do not see any change with this on QCM6490 Fairphone 5
and 4-lane DP.
Regards
Luca
>
> Thanks,
> Neil
>
> >
> > Regards
> > Luca
> >
> >>
> >> Konrad
> >
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
2024-04-05 10:19 ` Luca Weiss
@ 2024-04-23 13:03 ` Konrad Dybcio
-1 siblings, 0 replies; 54+ messages in thread
From: Konrad Dybcio @ 2024-04-23 13:03 UTC (permalink / raw)
To: Luca Weiss, neil.armstrong, Bjorn Andersson
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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/20240405000111.1450598-1-swboyd@chromium.org/
>
> Unfortunately I do not see any change with this on QCM6490 Fairphone 5
> and 4-lane DP.
Hm, could you like dump all the PHY regions up and downstream with the display
connected (and nothing connected) and compare them?
Konrad
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-04-23 13:03 ` Konrad Dybcio
0 siblings, 0 replies; 54+ messages in thread
From: Konrad Dybcio @ 2024-04-23 13:03 UTC (permalink / raw)
To: Luca Weiss, neil.armstrong, Bjorn Andersson
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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/20240405000111.1450598-1-swboyd@chromium.org/
>
> Unfortunately I do not see any change with this on QCM6490 Fairphone 5
> and 4-lane DP.
Hm, could you like dump all the PHY regions up and downstream with the display
connected (and nothing connected) and compare them?
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
2024-04-23 13:03 ` Konrad Dybcio
@ 2024-04-23 14:08 ` neil.armstrong
-1 siblings, 0 replies; 54+ messages in thread
From: neil.armstrong @ 2024-04-23 14:08 UTC (permalink / raw)
To: Konrad Dybcio, Luca Weiss, Bjorn Andersson
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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/20240405000111.1450598-1-swboyd@chromium.org/
>>
>> Unfortunately I do not see any change with this on QCM6490 Fairphone 5
>> and 4-lane DP.
>
> Hm, could you like dump all the PHY regions up and downstream with the display
> connected (and nothing connected) and compare them?
Yes would be great, PHY regions and DP regions as well.
Neil
>
> Konrad
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
@ 2024-04-23 14:08 ` neil.armstrong
0 siblings, 0 replies; 54+ messages in thread
From: neil.armstrong @ 2024-04-23 14:08 UTC (permalink / raw)
To: Konrad Dybcio, Luca Weiss, Bjorn Andersson
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
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/20240405000111.1450598-1-swboyd@chromium.org/
>>
>> Unfortunately I do not see any change with this on QCM6490 Fairphone 5
>> and 4-lane DP.
>
> Hm, could you like dump all the PHY regions up and downstream with the display
> connected (and nothing connected) and compare them?
Yes would be great, PHY regions and DP regions as well.
Neil
>
> Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~2024-04-23 14:08 UTC | newest]
Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-29 13:07 [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode Neil Armstrong
2024-02-29 13:07 ` Neil Armstrong
2024-02-29 13:07 ` [PATCH RFT 1/7] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp: Add mode-switch Neil Armstrong
2024-02-29 13:07 ` Neil Armstrong
2024-03-04 16:22 ` Rob Herring
2024-03-04 16:22 ` Rob Herring
2024-02-29 13:07 ` [PATCH RFT 2/7] phy: qcom: qmp-combo: store DP phy power state Neil Armstrong
2024-02-29 13:07 ` Neil Armstrong
2024-02-29 13:07 ` [PATCH RFT 3/7] phy: qcom: qmp-combo: introduce QPHY_MODE Neil Armstrong
2024-02-29 13:07 ` Neil Armstrong
2024-03-29 16:56 ` Vinod Koul
2024-03-29 16:56 ` Vinod Koul
2024-02-29 13:07 ` [PATCH RFT 4/7] phy: qcom: qmp-combo: register a typec mux to change the QPHY_MODE Neil Armstrong
2024-02-29 13:07 ` Neil Armstrong
2024-02-29 15:25 ` Dmitry Baryshkov
2024-02-29 15:25 ` Dmitry Baryshkov
2024-02-29 15:47 ` Neil Armstrong
2024-02-29 15:47 ` Neil Armstrong
2024-02-29 15:54 ` Dmitry Baryshkov
2024-02-29 15:54 ` Dmitry Baryshkov
2024-02-29 15:57 ` neil.armstrong
2024-02-29 15:57 ` neil.armstrong
2024-02-29 13:07 ` [PATCH RFT 5/7] arm64: dts: qcom-sm8550: allow 4 lanes for DisplayPort and enable QMP PHY mode-switch Neil Armstrong
2024-02-29 13:07 ` Neil Armstrong
2024-02-29 13:07 ` [PATCH RFT 6/7] arm64: dts: qcom-sm8650: " Neil Armstrong
2024-02-29 13:07 ` Neil Armstrong
2024-02-29 13:07 ` [PATCH RFT 7/7] arm64: dts: qcom-mode-switch: " Neil Armstrong
2024-02-29 13:07 ` Neil Armstrong
2024-02-29 13:11 ` Neil Armstrong
2024-02-29 13:11 ` Neil Armstrong
2024-03-01 3:00 ` Bjorn Andersson
2024-03-01 3:00 ` Bjorn Andersson
2024-03-01 18:31 ` Neil Armstrong
2024-03-01 18:31 ` Neil Armstrong
2024-03-15 17:19 ` [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode Luca Weiss
2024-03-15 17:19 ` Luca Weiss
2024-03-15 17:35 ` Neil Armstrong
2024-03-15 17:35 ` Neil Armstrong
2024-03-16 16:01 ` Bjorn Andersson
2024-03-16 16:01 ` Bjorn Andersson
2024-03-18 10:45 ` Luca Weiss
2024-03-18 10:45 ` Luca Weiss
2024-03-26 21:02 ` Konrad Dybcio
2024-03-26 21:02 ` Konrad Dybcio
2024-03-29 9:02 ` Luca Weiss
2024-03-29 9:02 ` Luca Weiss
2024-04-05 8:08 ` Neil Armstrong
2024-04-05 8:08 ` Neil Armstrong
2024-04-05 10:19 ` Luca Weiss
2024-04-05 10:19 ` Luca Weiss
2024-04-23 13:03 ` Konrad Dybcio
2024-04-23 13:03 ` Konrad Dybcio
2024-04-23 14:08 ` neil.armstrong
2024-04-23 14:08 ` neil.armstrong
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.