From: Jens Glathe <jens.glathe@oldschoolsolutions.biz>

The usb0 port didn't switch to dp altmode, investigation into DSDT
UCS0 device resulted in GPIO 165.

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
---
This patch amends the enable gpio for the usb0-sbu-mux to the one
found in the DSDT file for this laptop. UCS0 shows a list of GPIOs in 
a certain order, and it has 2 buffers with slightly different length. 
At the place where one would expect the GPIO for the select pin of USB0 
(by pattern application from USB1) is a deviating value (165 instead of 
101). This value is the same in both buffers. The GPIO previously used
is also there, but at the end of the UCS0 buffer structure. Changing it
resulted in a working dp altmode functionality on usb0.

Since the X13s dt looks derived from the SC8280XP CRD, it is likely that
the change also needs to be done there. 

This debug effort is a result of work / testing of the 4-lanes patch
[1] on all available devices. Independent of it, it enables dp 
altmode on usb0, and with it, also 4 lanes, making it even more useful.

[1]: https://lore.kernel.org/all/20250527-topic-4ln_dp_respin-v3-0-f9a0763ec289@oss.qualcomm.com/
---
Changes in v2:
- Fixed typos.
- Link to v1: https://lore.kernel.org/r/20250610-x13s-usb0-mux-v1-1-683213580ff1@oldschoolsolutions.biz
---
 arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 4 ++--
 1 file changed, 2 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 ae7a275fd2236a2c71808b003fbcb66687e6e45e..abb742337359e88b7db62a3ea2d7cf3f8ab71c53 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -366,7 +366,7 @@ map1 {
 	usb0-sbu-mux {
 		compatible = "pericom,pi3usb102", "gpio-sbu-mux";
 
-		enable-gpios = <&tlmm 101 GPIO_ACTIVE_LOW>;
+		enable-gpios = <&tlmm 165 GPIO_ACTIVE_LOW>;
 		select-gpios = <&tlmm 164 GPIO_ACTIVE_HIGH>;
 
 		pinctrl-names = "default";
@@ -1781,7 +1781,7 @@ tx-pins {
 
 	usb0_sbu_default: usb0-sbu-state {
 		oe-n-pins {
-			pins = "gpio101";
+			pins = "gpio165";
 			function = "gpio";
 			bias-disable;
 			drive-strength = <16>;

---
base-commit: 475c850a7fdd0915b856173186d5922899d65686
change-id: 20250610-x13s-usb0-mux-82a9e02998c8

Best regards,
-- 
Jens Glathe <jens.glathe@oldschoolsolutions.biz>

On Tue, Jun 10, 2025 at 07:04:46AM +0200, Jens Glathe via B4 Relay wrote:
> From: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> 
> The usb0 port didn't switch to dp altmode, investigation into DSDT
> UCS0 device resulted in GPIO 165.

DP alt mode works on both ports of the X13s and "resulted in
gpio165" makes little sense so this commit message would need to be
extended.

> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> ---
> This patch amends the enable gpio for the usb0-sbu-mux to the one
> found in the DSDT file for this laptop. UCS0 shows a list of GPIOs in 
> a certain order, and it has 2 buffers with slightly different length. 
> At the place where one would expect the GPIO for the select pin of USB0 
> (by pattern application from USB1) is a deviating value (165 instead of 
> 101). This value is the same in both buffers. The GPIO previously used
> is also there, but at the end of the UCS0 buffer structure. Changing it
> resulted in a working dp altmode functionality on usb0.

GPIO 101 *is* the OE_N pin, while GPIO 165 is not even connected
according to the schematics. The mux may still work after this change,
but you'd be relying on it having been enabled by the boot firmware.

> Since the X13s dt looks derived from the SC8280XP CRD, it is likely that
> the change also needs to be done there. 

To some degree that's true, but we have schematics for both machines and
they are not identical.

> This debug effort is a result of work / testing of the 4-lanes patch
> [1] on all available devices. Independent of it, it enables dp 
> altmode on usb0, and with it, also 4 lanes, making it even more useful.
> 
> [1]: https://lore.kernel.org/all/20250527-topic-4ln_dp_respin-v3-0-f9a0763ec289@oss.qualcomm.com/

NAK

Johan

On 6/10/25 09:31, Johan Hovold wrote:
> On Tue, Jun 10, 2025 at 07:04:46AM +0200, Jens Glathe via B4 Relay wrote:
> DP alt mode works on both ports of the X13s and "resulted in
> gpio165" makes little sense so this commit message would need to be
> extended.

Well, that was the problem. It didn't on USB0. without and with the 4 
lanes patch.

Observed on Windows Dev Kit 2023 and X13s, what prompted me to look deeper.

> GPIO 101 *is* the OE_N pin, while GPIO 165 is not even connected
> according to the schematics. The mux may still work after this change,
> but you'd be relying on it having been enabled by the boot firmware.
>
Schematics trump any other data, of course. After a lot of tests and 
some wild
results I could narrow it down to the display I used for testing, iiyama 
XUB2792QSN.
It works with HDMI adapters on ~all other displays I have - with and 
without any
4-lanes, lttpr patches. And the original GPIO. The issue with the 
display appears to
be something linked to how negotiation is done by it on that specific port.

Do I need to do anything since its already NAK?

with best regards

Jens

On Wed, Jun 11, 2025 at 09:25:20PM +0200, Jens Glathe wrote:
> 
> On 6/10/25 09:31, Johan Hovold wrote:
> > On Tue, Jun 10, 2025 at 07:04:46AM +0200, Jens Glathe via B4 Relay wrote:
> > DP alt mode works on both ports of the X13s and "resulted in
> > gpio165" makes little sense so this commit message would need to be
> > extended.
> 
> Well, that was the problem. It didn't on USB0. without and with the 4 
> lanes patch.
> 
> Observed on Windows Dev Kit 2023 and X13s, what prompted me to look deeper.
> 
> > GPIO 101 *is* the OE_N pin, while GPIO 165 is not even connected
> > according to the schematics. The mux may still work after this change,
> > but you'd be relying on it having been enabled by the boot firmware.
> >
> Schematics trump any other data, of course. After a lot of tests and 
> some wild
> results I could narrow it down to the display I used for testing, iiyama 
> XUB2792QSN.
> It works with HDMI adapters on ~all other displays I have - with and 
> without any
> 4-lanes, lttpr patches. And the original GPIO. The issue with the 
> display appears to
> be something linked to how negotiation is done by it on that specific port.
> 
> Do I need to do anything since its already NAK?

No, this patch should not be picked up now.

But you may want to revisit the other related patches for other boards
that you sent in case they too are based on some misunderstanding.

Johan

On 16.06.25 10:57, Johan Hovold wrote:
> No, this patch should not be picked up now.
>
> But you may want to revisit the other related patches for other boards
> that you sent in case they too are based on some misunderstanding.
>
> Johan

That, I did. No changes except for this one.

with best regards

Jens

On Wed, Jun 11, 2025 at 09:25:20PM +0200, Jens Glathe wrote:
> 
> On 6/10/25 09:31, Johan Hovold wrote:
> > On Tue, Jun 10, 2025 at 07:04:46AM +0200, Jens Glathe via B4 Relay wrote:
> > DP alt mode works on both ports of the X13s and "resulted in
> > gpio165" makes little sense so this commit message would need to be
> > extended.
> 
> Well, that was the problem. It didn't on USB0. without and with the 4 lanes
> patch.
> 
> Observed on Windows Dev Kit 2023 and X13s, what prompted me to look deeper.

I have verified, on my X13s (21BXCTO1WW) DP works on both USB-C ports.
Moreover, according to the schematics that I have, GPIO 165 is not
connected.

> 
> > GPIO 101 *is* the OE_N pin, while GPIO 165 is not even connected
> > according to the schematics. The mux may still work after this change,
> > but you'd be relying on it having been enabled by the boot firmware.
> > 
> Schematics trump any other data, of course. After a lot of tests and some
> wild
> results I could narrow it down to the display I used for testing, iiyama
> XUB2792QSN.
> It works with HDMI adapters on ~all other displays I have - with and without
> any
> 4-lanes, lttpr patches. And the original GPIO. The issue with the display
> appears to
> be something linked to how negotiation is done by it on that specific port.
> 
> Do I need to do anything since its already NAK?
> 
> with best regards
> 
> Jens
> 

-- 
With best wishes
Dmitry