linux-kernel - Re: [PATCH RFC 0/2] arm64: tegra: Add NVIDIA Jetson Nano 2GB Developer Kit support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <w2xzqdyg4pcblpwhk2kspekcngkfuzahqgm4xsw6ofsqgri2nk@a6377d5aiq4l>
Date: Wed, 11 Jun 2025 17:47:48 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Aaron Kling <webgeek1234@...il.com>
Cc: Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Jonathan Hunter <jonathanh@...dia.com>, devicetree@...r.kernel.org, linux-tegra@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/2] arm64: tegra: Add NVIDIA Jetson Nano 2GB
 Developer Kit support

On Tue, Jun 10, 2025 at 02:45:53PM -0500, Aaron Kling wrote:
> On Tue, Jun 10, 2025 at 4:15 AM Thierry Reding <thierry.reding@...il.com> wrote:
> >
> > On Sun, Jun 08, 2025 at 11:25:53PM -0500, Aaron Kling wrote:
> > > On Sun, Jun 8, 2025 at 11:24 PM Aaron Kling via B4 Relay
> > > <devnull+webgeek1234.gmail.com@...nel.org> wrote:
> > > >
> > > > Signed-off-by: Aaron Kling <webgeek1234@...il.com>
> > > > ---
> > > > Aaron Kling (2):
> > > >       dt-bindings: arm: tegra: Document Jetson Nano Devkits
> > > >       arm64: tegra: Add NVIDIA Jetson Nano 2GB Developer Kit support
> > > >
> > > >  Documentation/devicetree/bindings/arm/tegra.yaml   |  5 +++
> > > >  arch/arm64/boot/dts/nvidia/Makefile                |  2 +
> > > >  arch/arm64/boot/dts/nvidia/tegra210-p3541-0000.dts | 43 ++++++++++++++++++++++
> > > >  3 files changed, 50 insertions(+)
> > > > ---
> > > > base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
> > > > change-id: 20250513-p3452-059708ca9993
> > > >
> > > > Best regards,
> > > > --
> > > > Aaron Kling <webgeek1234@...il.com>
> > >
> > > This is sent as an RFC, because it doesn't fully work. In my tests,
> > > this boots and everything I can see works, except for hdmi. The
> > > hotplug detect pin never changes, regardless of hdmi plug state. This
> > > works as expected on the downstream 4.9 kernel. Based on the
> > > downstream kernel dt for p3541, it's almost identical to p3540, and
> > > I've mirrored those differences in this series. Things like the hpd
> > > pin are the same. I'm failing to see why hpd would work on p3450, but
> > > not on p3541, when using the same boot stack. Does anyone know why
> > > this doesn't work?
> >
> > My recollection is that the HPD pin essentially loops back the +5V pin,
> > so that would be my prime suspect. Other than that I suppose it could be
> > a pinmux issue where HPD is muxed as something else.
> 
> This got me looking at which regulators got removed from the power
> tree in my changes and it looks like the 3v3 usb hub one is the
> operable difference. If I do the following in the new p3541 dts, hpd
> works. This supply is not used downstream in p3541 for usb and is
> instead replaced with a 5v0 regulator tied to gpio pi2. While looking
> into this, I see that I got the usb power tree mapping wrong in v1 and
> am fixing for v2.
> 
> +       /* This supply is associated with hdmi hotplug and needs to remain on */
> +       regulator-vdd-hub-3v3 {
> +               regulator-always-on;
> +       };
> 
> This seems like a kludge, though. The implication is that whatever
> gpio pa6 is wired to for p3541 is related to hpd somehow. I'm not sure
> if the rail / wiring is different from p3450. Seems like it would have
> to be. Any thoughts on this, Thierry? Maybe a better way to map the
> dependency?

Let me look at the board schematics: The +5V pin on the HDMI connector
is supplied by VDD_5V0_HDMI_CON, which in turn is the output of a switch
that is supplied aby VDD_5V_IN and controlled using VDD_3V3_HDMI. The
latter is supplied by VDD_3V3_SYS and controlled by MOD_SLEEP*.
VDD_3V3_SYS is supplied by VDD_5V_IN and controlled by SYS_RST*.

Looking at the module schematics, MOD_SLEEP is indeed mapped to GPIO
PA6.

Despite the ominous name, MOD_SLEEP seems to be used exclusively for
HDMI HPD and some LED control, so it sure sounds like that's the right
GPIO to use as enable pin in the HDMI supply. Maybe all you need to do
is use a phandle reference to that HDMI supply in the SOR node's
hdmi-supply property? That should make sure that the regulator gets
enabled when HDMI is in use.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)