From: Robin Murphy <robin.murphy@arm.com>
To: "Tianling Shen" <cnsztl@gmail.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Jagan Teki" <jagan@amarulasolutions.com>,
"Chen-Yu Tsai" <wens@csie.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"David Bauer" <mail@david-bauer.net>,
"Uwe Kleine-König" <uwe@kleine-koenig.org>,
"Johan Jonker" <jbx6244@gmail.com>,
"Michael Trimarchi" <michael@amarulasolutions.com>,
"Marty Jones" <mj8263788@gmail.com>,
"Jensen Huang" <jensenhuang@friendlyarm.com>
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v3 2/2] rockchip: rk3399: Add support for FriendlyARM NanoPi R4S
Date: Sat, 13 Mar 2021 11:54:49 +0000 [thread overview]
Message-ID: <1f7f1a11-0b9b-b2e4-efbc-193f61d62832@arm.com> (raw)
In-Reply-To: <20210313032515.12590-2-cnsztl@gmail.com>
On 2021-03-13 03:25, Tianling Shen wrote:
> This adds support for the NanoPi R4S from FriendlyArm.
>
> Rockchip RK3399 SoC
> 1GB DDR3 or 4GB LPDDR4 RAM
> Gigabit Ethernet (WAN)
> Gigabit Ethernet (PCIe) (LAN)
> USB 3.0 Port x 2
> MicroSD slot
> Reset button
> WAN - LAN - SYS LED
>
> [initial DTS file]
> Co-developed-by: Jensen Huang <jensenhuang@friendlyarm.com>
> Signed-off-by: Jensen Huang <jensenhuang@friendlyarm.com>
> [minor adjustments]
> Co-developed-by: Marty Jones <mj8263788@gmail.com>
> Signed-off-by: Marty Jones <mj8263788@gmail.com>
> [fixed format issues]
> Signed-off-by: Tianling Shen <cnsztl@gmail.com>
>
> Reported-by: kernel test robot <lkp@intel.com>
> ---
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../boot/dts/rockchip/rk3399-nanopi-r4s.dts | 179 ++++++++++++++++++
> 2 files changed, 180 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 62d3abc17a24..c3e00c0e2db7 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -36,6 +36,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-r4s.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-pinebook-pro.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
> new file mode 100644
> index 000000000000..41b3d5c5043c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
> @@ -0,0 +1,179 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * FriendlyElec NanoPC-T4 board device tree source
> + *
> + * Copyright (c) 2020 FriendlyElec Computer Tech. Co., Ltd.
> + * (http://www.friendlyarm.com)
> + *
> + * Copyright (c) 2018 Collabora Ltd.
> + *
> + * Copyright (c) 2020 Jensen Huang <jensenhuang@friendlyarm.com>
> + * Copyright (c) 2020 Marty Jones <mj8263788@gmail.com>
> + * Copyright (c) 2021 Tianling Shen <cnsztl@gmail.com>
> + */
> +
> +/dts-v1/;
> +#include "rk3399-nanopi4.dtsi"
> +
> +/ {
> + model = "FriendlyElec NanoPi R4S";
> + compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
> +
> + /delete-node/ gpio-leds;
Why? You could justify deleting &status_led, but redefining the whole
node from scratch seems unnecessary.
> + gpio-leds {
> + compatible = "gpio-leds";
> + pinctrl-0 = <&lan_led_pin>, <&sys_led_pin>, <&wan_led_pin>;
> + pinctrl-names = "default";
> +
> + lan_led: led-0 {
> + gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_HIGH>;
> + label = "nanopi-r4s:green:lan";
> + };
> +
> + sys_led: led-1 {
> + gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
> + label = "nanopi-r4s:red:sys";
> + default-state = "on";
> + };
> +
> + wan_led: led-2 {
> + gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
> + label = "nanopi-r4s:green:wan";
> + };
> + };
> +
> + /delete-node/ gpio-keys;
Ditto - just removing the power key node itself should suffice.
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&reset_button_pin>;
> +
> + reset {
> + debounce-interval = <50>;
> + gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
> + label = "reset";
> + linux,code = <KEY_RESTART>;
> + };
> + };
> +
> + vdd_5v: vdd-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_5v";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + fan: pwm-fan {
> + compatible = "pwm-fan";
> + /*
> + * With 20KHz PWM and an EVERCOOL EC4007H12SA fan, these levels
> + * work out to 0, ~1200, ~3000, and 5000RPM respectively.
> + */
> + cooling-levels = <0 12 18 255>;
This is clearly not true - those numbers refer to a 12V fan on my
NanoPC-T4's 12V PWM circuit, while the output circuit here is 5V. If you
really want a placeholder here maybe just use <0 255>, or figure out
some empirical values with a suitable 5V fan that are actually meaningful.
> + #cooling-cells = <2>;
> + fan-supply = <&vdd_5v>;
> + pwms = <&pwm1 0 50000 0>;
> + };
> +};
> +
> +&cpu_thermal {
> + trips {
> + cpu_warm: cpu_warm {
> + temperature = <55000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> +
> + cpu_hot: cpu_hot {
> + temperature = <65000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map2 {
> + trip = <&cpu_warm>;
> + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> + };
> +
> + map3 {
> + trip = <&cpu_hot>;
> + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +&emmc_phy {
> + status = "disabled";
> +};
> +
> +&fusb0 {
> + status = "disabled";
This can never be enabled since it doesn't exist in the design at all,
so it's one place where deletion *would* make good sense. AFAICS this
means you also don't need i2c4 enabled either.
> +};
It might be nice to disable HDMI and all the other display pieces given
that the board is physically headless.
> +
> +&pcie0 {
> + max-link-speed = <1>;
> + num-lanes = <1>;
> + vpcie3v3-supply = <&vcc3v3_sys>;
> +
> + pcie@0 {
> + reg = <0x00000000 0 0 0 0>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + };
What's this for?
> +};
> +
> +&pinctrl {
> + /delete-node/ gpio-leds;
Again, at most you'd only need to delete &status_led_pin.
> + gpio-leds {
> + lan_led_pin: lan-led-pin {
> + rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + sys_led_pin: sys-led-pin {
> + rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + wan_led_pin: wan-led-pin {
> + rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + /delete-node/ rockchip-key;
Ditto for &power_key.
> + rockchip-key {
> + reset_button_pin: reset-button-pin {
> + rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +};
> +
> +&sdhci {
> + status = "disabled";
> +};
> +
> +&sdio0 {
> + status = "disabled";
> +};
> +
> +&sdmmc {
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
Are those modes unique to this particular board?
> +};
> +
What about the Bluetooth stuff on uart0?
Robin.
> +&u2phy0_host {
> + phy-supply = <&vdd_5v>;
> +};
> +
> +&u2phy1_host {
> + status = "disabled";
> +};
> +
> +&usbdrd_dwc3_0 {
> + dr_mode = "host";
> +};
> +
> +&vcc3v3_sys {
> + vin-supply = <&vcc5v0_sys>;
> +};
>
next prev parent reply other threads:[~2021-03-13 11:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-13 3:25 [PATCH v3 1/2] dt-bindings: Add doc " Tianling Shen
2021-03-13 3:25 ` [PATCH v3 2/2] rockchip: rk3399: Add support " Tianling Shen
2021-03-13 11:54 ` Robin Murphy [this message]
2021-03-13 13:22 ` CN_SZTL
2021-03-15 16:32 ` Robin Murphy
2021-03-15 16:38 ` Geert Uytterhoeven
2021-03-15 16:52 ` Heiko Stübner
2021-03-15 18:13 ` Geert Uytterhoeven
2021-03-16 15:00 ` Tianling Shen
2021-03-16 15:34 ` Geert Uytterhoeven
2021-03-16 16:38 ` Tianling Shen
2021-03-16 19:38 ` Pavel Machek
2021-03-17 4:38 ` Tianling Shen
2021-04-25 21:25 ` Pavel Machek
2021-03-16 14:52 ` Tianling Shen
2021-03-16 14:49 Tianling Shen
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=1f7f1a11-0b9b-b2e4-efbc-193f61d62832@arm.com \
--to=robin.murphy@arm.com \
--cc=cnsztl@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=heiko@sntech.de \
--cc=jagan@amarulasolutions.com \
--cc=jbx6244@gmail.com \
--cc=jensenhuang@friendlyarm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lkp@intel.com \
--cc=mail@david-bauer.net \
--cc=michael@amarulasolutions.com \
--cc=mj8263788@gmail.com \
--cc=robh+dt@kernel.org \
--cc=uwe@kleine-koenig.org \
--cc=wens@csie.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
all inboxes | Powered by JetHome®