From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.2 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89BF5C43381 for ; Tue, 19 Mar 2019 12:31:07 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 54FFC2146E for ; Tue, 19 Mar 2019 12:31:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="F+r8CGkq"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="CQe2URI8"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ecp1f8T3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 54FFC2146E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/2SRxRf1nkzol+cHmfG9+JDB6hM9KaNym4wd8Lrp2ic=; b=F+r8CGkqVjjipr/gCibTVQa3D +c0R1L5vmHJQrgwMZmOVScna+b0CfglnL/pNPVTiH3UJiV+DC2FIfxkkF3EC/BAHk6PBfNCfV9dCd gS88lIJl5MX9iv1Hrg2NR8Ic1ZY2FEbiDqgY60ypBnsfTZHgc43N6KeICRuSR9tKnTH32cFFX6VhR mfTySi+UQLxF9SGYSHE8tuNp68sOLxD6uhlsKv4Su185h8Hm+gNO9DY7uUfuNOMpJYWdPxi6wSC16 +Qn3Mfc0mFlhsg13JIdWohETuShMiXUrtxJATW4va5GT3ONlu9iiENY+xCOqJ2fCeIh9GhjOum8wk NrLVjaUag==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h6DtU-00083b-Fh; Tue, 19 Mar 2019 12:31:00 +0000 Received: from merlin.infradead.org ([2001:8b0:10b:1231::1]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h6DtR-00083D-1h for linux-arm-kernel@bombadil.infradead.org; Tue, 19 Mar 2019 12:30:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=y7BXsawGVuBv5Ax/alAFaBVYaPYNpRpqPCsLD2h359g=; b=CQe2URI8WUai2OjYgk6bYLlGz oXQLEFaHTBQViy4kAlHFcT2U6GC+KOL3lc++uxqC2ZcIRCKEeR9KB1vWElKjabL4dYMSzheE5l5Cf yv4dbtyUNWr4yR7zlJUHMuvjwSrMmUhCX+uABjL36R4xoT/3vbdk/TaMpdZ7teCK6+tkAJC+hvJp6 OaxU1eqJVouW8jjI0k0em/db3Ni7hONPN5apvE6q7tg6nQYzz8tn2zpGkoJM8EAPUOhzxu4QjNGt4 0+ZynAJhYu9LKHDbwcTTMLsS7HagSECk9BArLSms74YdNMiIuEi6QhGqHT0jvQLauhgLPLVQhf+tJ PKU2rXpqg==; Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]) by merlin.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h6DXI-0000NN-4c for linux-arm-kernel@lists.infradead.org; Tue, 19 Mar 2019 12:08:04 +0000 Received: by mail-wm1-x342.google.com with SMTP id 4so16363239wmf.5 for ; Tue, 19 Mar 2019 05:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=y7BXsawGVuBv5Ax/alAFaBVYaPYNpRpqPCsLD2h359g=; b=ecp1f8T3L0RZMbmKSJ7/IBadK8DqUNyPZV9+x511Po/8YaGdYMjZOSChWW/z4O3pNd 8rzXfFrRjjaYa6N5tkEC3ALvIGH0sYacj2h1JnrTxxh0vst3S0KjPxNlaYm8ZtZXe2nZ 1EX6gsck/yzu8sFngUH6xtpmp/agv22gr1gpr9sqBM9WLYYarE8/f7fvI3p2ABtlYSms QOWktIQhpeSYZsT2Cq78ODVr7Y/5wq/U7+k7Q7S+pKGdxn51/svDl7Yom1fs7rDgc3Wh 6mMQA1XS04RZ9humJME+ppkDzCWxm0ZW7cI3G1a40FnuBY6aGqD5ydVC6MRmtch4uTUy J+HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=y7BXsawGVuBv5Ax/alAFaBVYaPYNpRpqPCsLD2h359g=; b=LwajOnIZ5fn+YsuKNPDt9QHMMqE20U3nSmUnO8mzK0JPnW+Mu5BmcOz5SqdvUMV5Qk U3s8VAR8Gr0W8XaQGsYaaWkWiIKLZpSkR9PDaXwq5eQjAq69VwCiTO2LbpaIAFSIO8lY WQQVaNeReq4uJDagN8HW4t2vBikrCRU3ZA8QL+0pjA8upU8hcFjHSq37ZybY32IiX/VB 3Li+abAi3GnChGVPAi2i79KgVIOWUMFXeNvClUyMeZ3Zet6IzL5c2JgrYvu5b+IBCNc4 wjlDQgGVS6itqD3sm8eJzFiF4fYrKi4P6+6h7iDry1deaRRsziRXl34pkhVdnYmVe+Rf HzGQ== X-Gm-Message-State: APjAAAVI4oOV3LgqxGgELqt+G0SRaDe6bGQuukJh0Rrk2/MOOF+Buwce PL22OEPe4hNGScEuIbuZaV9dGdv6 X-Google-Smtp-Source: APXvYqzva3zysHA67cdeeULSSDp/L+YcnVCbKWGM7/v3x0rU7F2Yv6knECkk/hqdNwO1bgR+Ay0epg== X-Received: by 2002:a1c:4b03:: with SMTP id y3mr3389770wma.75.1552997277576; Tue, 19 Mar 2019 05:07:57 -0700 (PDT) Received: from localhost (pD9E51D2D.dip0.t-ipconnect.de. [217.229.29.45]) by smtp.gmail.com with ESMTPSA id f7sm10987319wru.3.2019.03.19.05.07.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Mar 2019 05:07:56 -0700 (PDT) Date: Tue, 19 Mar 2019 13:07:55 +0100 From: Thierry Reding To: Jon Hunter , Stephen Warren Subject: Re: [PATCH] arm64: tegra: Add NVIDIA Jetson Nano Developer Kit support Message-ID: <20190319120755.GA9309@ulmo> References: <20190318232313.24270-1-thierry.reding@gmail.com> <2b4ec55b-d9f3-3c09-5590-f586609f0b3e@nvidia.com> MIME-Version: 1.0 In-Reply-To: <2b4ec55b-d9f3-3c09-5590-f586609f0b3e@nvidia.com> User-Agent: Mutt/1.11.4 (2019-03-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190319_080804_252745_24631880 X-CRM114-Status: GOOD ( 36.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============8497094874531086724==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============8497094874531086724== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 19, 2019 at 10:16:49AM +0000, Jon Hunter wrote: >=20 > On 18/03/2019 23:23, Thierry Reding wrote: > > From: Thierry Reding > >=20 > > The Jetson Nano Developer Kit is a Tegra X1 based development board. It > > is similar to Jetson TX1 but it is not pin compatible. It features 4 GB > > of LPDDR4, an SPI NOR flash for early boot firmware and an SD card slot > > used for storage. > >=20 > > HDMI 2.0 or DP 1.2 are available for display, four USB ports (3 USB 2.0 > > and 1 USB 3.0) can be used to attach a variety of peripherals and a PCI > > Ethernet controller provides onboard network connectivity. > >=20 > > A 40-pin header on the board can be used to extend the capabilities and > > exposed interfaces of the Jetson Nano. > >=20 > > Signed-off-by: Thierry Reding > > --- > > This patch, along with some related patches can be found in the p3450 > > branch in the following repository: > >=20 > > https://github.com/thierryreding/linux > >=20 > > arch/arm64/boot/dts/nvidia/Makefile | 1 + > > .../boot/dts/nvidia/tegra210-p3450-0000.dts | 1911 +++++++++++++++++ > > 2 files changed, 1912 insertions(+) > > create mode 100644 arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts > >=20 > > diff --git a/arch/arm64/boot/dts/nvidia/Makefile b/arch/arm64/boot/dts/= nvidia/Makefile > > index 6b8ab5568481..bcd018c3162b 100644 > > --- a/arch/arm64/boot/dts/nvidia/Makefile > > +++ b/arch/arm64/boot/dts/nvidia/Makefile > > @@ -3,6 +3,7 @@ dtb-$(CONFIG_ARCH_TEGRA_132_SOC) +=3D tegra132-norrin.d= tb > > dtb-$(CONFIG_ARCH_TEGRA_210_SOC) +=3D tegra210-p2371-0000.dtb > > dtb-$(CONFIG_ARCH_TEGRA_210_SOC) +=3D tegra210-p2371-2180.dtb > > dtb-$(CONFIG_ARCH_TEGRA_210_SOC) +=3D tegra210-p2571.dtb > > +dtb-$(CONFIG_ARCH_TEGRA_210_SOC) +=3D tegra210-p3450-0000.dtb > > dtb-$(CONFIG_ARCH_TEGRA_210_SOC) +=3D tegra210-smaug.dtb > > dtb-$(CONFIG_ARCH_TEGRA_210_SOC) +=3D tegra210-p2894-0050-a08.dtb > > dtb-$(CONFIG_ARCH_TEGRA_186_SOC) +=3D tegra186-p2771-0000.dtb > > diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts b/arch/= arm64/boot/dts/nvidia/tegra210-p3450-0000.dts > > new file mode 100644 > > index 000000000000..b1d8a49ca8c4 > > --- /dev/null > > +++ b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts > > @@ -0,0 +1,1911 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/dts-v1/; > > + > > +#include > > +#include > > +#include > > + > > +#include "tegra210.dtsi" > > + > > +/ { > > + model =3D "NVIDIA Jetson Nano Developer Kit"; > > + compatible =3D "nvidia,p3450-0000", "nvidia,tegra210"; >=20 > I am just curious but any reason why we do not have a dtsi file for the > Nano module that we include for the developer kit? Or is there no point > because the module and kit will never be separate in this case? >=20 > The developer kit user guide lists both the module (p3448) and carrier > board (p3449) and so was just curious. We used to do that in the past but there never turned out to be a second board that shared the module or carrier DTSI, and the added complexity of spreading changes over multiple DTS files never came with any advantage, so I want to try something different this time. If there's ever a need to split the module specific bits so that they can be shared by multiple assemblies, we can still make the split. I just don't want to start out extra complicated if we don't have to. > > + > > + aliases { > > + ethernet =3D "/pcie@1003000/pci@2,0/ethernet@0,0"; > > + rtc0 =3D "/i2c@7000d000/pmic@3c"; > > + rtc1 =3D "/rtc@7000e000"; > > + serial0 =3D &uarta; > > + }; > > + > > + chosen { > > + stdout-path =3D "serial0:115200n8"; > > + }; > > + > > + memory { > > + device_type =3D "memory"; > > + reg =3D <0x0 0x80000000 0x1 0x0>; > > + }; > > + > > + pcie@1003000 { > > + status =3D "okay"; > > + > > + hvddio-pex-supply =3D <&vdd_1v8>; > > + dvddio-pex-supply =3D <&vdd_pex_1v05>; > > + vddio-pex-ctl-supply =3D <&vdd_1v8>; > > + > > + pci@1,0 { > > + phys =3D <&{/padctl@7009f000/pads/pcie/lanes/pcie-1}>, > > + <&{/padctl@7009f000/pads/pcie/lanes/pcie-2}>, > > + <&{/padctl@7009f000/pads/pcie/lanes/pcie-3}>, > > + <&{/padctl@7009f000/pads/pcie/lanes/pcie-4}>; > > + phy-names =3D "pcie-0", "pcie-1", "pcie-2", "pcie-3"; > > + nvidia,num-lanes =3D <4>; > > + status =3D "okay"; > > + }; > > + > > + pci@2,0 { > > + phys =3D <&{/padctl@7009f000/pads/pcie/lanes/pcie-0}>; > > + phy-names =3D "pcie-0"; > > + status =3D "okay"; > > + > > + ethernet@0,0 { > > + reg =3D <0x000000 0 0 0 0>; > > + mac-address =3D [ 00 00 00 00 00 00 ]; > > + }; > > + }; > > + }; > > + > > + host1x@50000000 { > > + dpaux@54040000 { > > + status =3D "okay"; > > + }; > > + > > + sor@54580000 { > > + status =3D "okay"; > > + > > + avdd-io-supply =3D <&avdd_1v05>; > > + vdd-pll-supply =3D <&vdd_1v8>; > > + hdmi-supply =3D <&vdd_hdmi>; > > + > > + nvidia,ddc-i2c-bus =3D <&hdmi_ddc>; > > + nvidia,hpd-gpio =3D <&gpio TEGRA_GPIO(CC, 1) > > + GPIO_ACTIVE_LOW>; > > + nvidia,xbar-cfg =3D <0 1 2 3 4>; > > + }; > > + }; > > + > > + gpu@57000000 { > > + vdd-supply =3D <&vdd_gpu>; > > + status =3D "okay"; > > + }; > > + > > + pinmux: pinmux@700008d4 { > > + pinctrl-names =3D "boot"; > > + pinctrl-0 =3D <&state_boot>; > > + > > + state_boot: pinmux { > > + pex_l0_rst_n_pa0 { > > + nvidia,pins =3D "pex_l0_rst_n_pa0"; > > + nvidia,function =3D "pe0"; > > + nvidia,pull =3D ; > > + nvidia,tristate =3D ; > > + nvidia,enable-input =3D ; > > + nvidia,open-drain =3D ; > > + nvidia,io-hv =3D ; > > + }; > > + pex_l0_clkreq_n_pa1 { > > + nvidia,pins =3D "pex_l0_clkreq_n_pa1"; > > + nvidia,function =3D "pe0"; > > + nvidia,pull =3D ; > > + nvidia,tristate =3D ; > > + nvidia,enable-input =3D ; > > + nvidia,open-drain =3D ; > > + nvidia,io-hv =3D ; > > + }; > > + pex_wake_n_pa2 { > > + nvidia,pins =3D "pex_wake_n_pa2"; > > + nvidia,function =3D "pe"; > > + nvidia,pull =3D ; > > + nvidia,tristate =3D ; > > + nvidia,enable-input =3D ; > > + nvidia,open-drain =3D ; > > + nvidia,io-hv =3D ; > > + }; > > + pex_l1_rst_n_pa3 { > > + nvidia,pins =3D "pex_l1_rst_n_pa3"; > > + nvidia,function =3D "pe1"; > > + nvidia,pull =3D ; > > + nvidia,tristate =3D ; > > + nvidia,enable-input =3D ; > > + nvidia,open-drain =3D ; > > + nvidia,io-hv =3D ; > > + }; > > + pex_l1_clkreq_n_pa4 { > > + nvidia,pins =3D "pex_l1_clkreq_n_pa4"; > > + nvidia,function =3D "pe1"; > > + nvidia,pull =3D ; > > + nvidia,tristate =3D ; > > + nvidia,enable-input =3D ; > > + nvidia,open-drain =3D ; > > + nvidia,io-hv =3D ; > > + }; > > + sata_led_active_pa5 { > > + nvidia,pins =3D "sata_led_active_pa5"; > > + nvidia,pull =3D ; > > + nvidia,tristate =3D ; > > + nvidia,enable-input =3D ; > > + nvidia,open-drain =3D ; > > + }; > > + pa6 { > > + nvidia,pins =3D "pa6"; > > + nvidia,pull =3D ; > > + nvidia,tristate =3D ; > > + nvidia,enable-input =3D ; > > + nvidia,open-drain =3D ; > > + }; > > + dap1_fs_pb0 { > > + nvidia,pins =3D "dap1_fs_pb0"; > > + nvidia,pull =3D ; > > + nvidia,tristate =3D ; > > + nvidia,enable-input =3D ; > > + nvidia,open-drain =3D ; >=20 > I am guessing this is generated by the pinmux spreadsheet, but any > reason why there is no 'nvidia,function' for some pins? Some that are > not used have the function defined as 'rsvd1', however, the above pin > does not, but AFAIK it is not used. Yes, this was generated from the pinmux spreadsheet. I'm not overly familiar with pinmux, but I think the idea was that if a property is missing, it means that the hardware default applies. Adding Stephen in case he knows. On that note, I guess we should publish the board file for the pinmux scripts as well. Thierry --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlyQ25gACgkQ3SOs138+ s6FiwQ//bFFN2aoqr86lfbb9d2lfRcYJcyFZruW1FhI0REieW5UnAMgQ3ctfVhBh h3GZEklWNr5BBS8NHE90UhJE5ZTVITL/Ofbd7NM2+sOUe6Upr+LXjoi2QDIKi+rM fNw8o5k8M76ylyHrQVu1Xfi6SGa5sYZAZuMO1vR7MEzMne4/xWMkgf2Xvp4fAw3I yOlhajRO1z4OODUxVlQsxvTLWZ6aBsC/CZKSnnfgUAxgTafCZ06OAbJPzEgLgWeg adOxdEgclHwSv728ujXAxer8FLzKMyACWj4dT4Vykt8z9RdLy/238nPKZLKiPuEM UT1uiibffEFiFI6sUYHs/ae++KYTD0bB704UqyzklJcpb/TGhkkEkI6WNTB1zWdO dkfFlhc+RpAACHABCFoN2aWyg9tA7ds0+lKIz6KojQ63pr7fx61mO5M+FoeoFDw9 lKEYRHBZN5ZI5x/rBsKQj//DvwKgciptuzsOCv6RZ0sZlWviaQ+5QC/Ba+Yk337B e1QKjnNvfjV+DshZ4lfUXFiiJ0Zp8P9bWU/DGX7DU7KThFEE8z5u7XZm7dCLMaxL ADF9vemtHXykHxrh0oeZ1QormOuarOIHmMtWDKd74cItrA5lvWn0EMlAt0mMHI76 FI9HmzJmmOf/ADI70Q1zqSNVj2dQshgEmy302QswpKSt3nuqgAo= =mza4 -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- --===============8497094874531086724== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============8497094874531086724==--