From: Johan Hovold <johan@kernel.org>
To: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Cc: Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Johan Hovold <johan+linaro@kernel.org>
Subject: Re: [PATCH v2] dt: arm64: qcom: sc8280xp-x13s: amend usb0-sbu-mux enable gpio
Date: Mon, 16 Jun 2025 10:57:30 +0200 [thread overview]
Message-ID: <aE_cejDMmmU48jMp@hovoldconsulting.com> (raw)
In-Reply-To: <64d963bd-b38c-4f14-bb1d-f7e89dad999a@oldschoolsolutions.biz>
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
next prev parent reply other threads:[~2025-06-16 8:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 5:04 [PATCH v2] dt: arm64: qcom: sc8280xp-x13s: amend usb0-sbu-mux enable gpio Jens Glathe via B4 Relay
2025-06-10 7:31 ` Johan Hovold
2025-06-11 19:25 ` Jens Glathe
2025-06-11 23:50 ` Dmitry Baryshkov
2025-06-16 8:57 ` Johan Hovold [this message]
2025-06-16 9:04 ` Jens Glathe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aE_cejDMmmU48jMp@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jens.glathe@oldschoolsolutions.biz \
--cc=johan+linaro@kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox