NanoPC-T4 (and a bit of NanoPi M4) support

From: Tomeu Vizoso <[email protected]>

This adds a device tree for the NanoPC-T4 SBC, which is based on the Rockchip RK3399 SoC and marketed by FriendlyELEC.

Known working:

- Serial
- Ethernet
- HDMI
- USB 2.0

All of the interesting stuff is in a .dtsi because there are at least two other boards that share most of it: NanoPi M4 and NanoPi NEO4.

Signed-off-by Tomeu Vizoso <[email protected]>

Reviewed-by Rob Herring <[email protected]>

[rm: various further cleanup]

Signed-off-by Robin Murphy <[email protected]>

Am Dienstag, 8. Januar 2019, 22:57:23 CET schrieb Robin Murphy:

Quoted 15 lines

From: Tomeu Vizoso <[email protected]>

This adds a device tree for the NanoPC-T4 SBC, which is based on the Rockchip RK3399 SoC and marketed by FriendlyELEC.

Known working:

- Serial
- Ethernet
- HDMI
- USB 2.0

All of the interesting stuff is in a .dtsi because there are at least two other boards that share most of it: NanoPi M4 and NanoPi NEO4.

Quoted 4 lines

Signed-off-by Tomeu Vizoso <[email protected]>

Reviewed-by Rob Herring <[email protected]>

[rm: various further cleanup]

Signed-off-by Robin Murphy <[email protected]>

nobody complained, the binding was reviewed and all looks good so I've gone forward and applied this one for 5.1 already.

Quoted 21 lines · Heiko Stuebner

Am Dienstag, 8. Januar 2019, 22:57:23 CET schrieb Robin Murphy:

Quoted 19 lines

From: Tomeu Vizoso <[email protected]>

This adds a device tree for the NanoPC-T4 SBC, which is based on the Rockchip RK3399 SoC and marketed by FriendlyELEC.

Known working:

- Serial
- Ethernet
- HDMI
- USB 2.0

All of the interesting stuff is in a .dtsi because there are at least two other boards that share most of it: NanoPi M4 and NanoPi NEO4.

Signed-off-by Tomeu Vizoso <[email protected]>

Reviewed-by Rob Herring <[email protected]>

[rm: various further cleanup]

Signed-off-by Robin Murphy <[email protected]>

Quoted 2 lines

nobody complained, the binding was reviewed and all looks good so I've gone forward and applied this one for 5.1 already.

Awesome, thanks!

I'll probably follow up with a v2 of the rest of the patches next week, after I've had the chance to play some more over the weekend.

There are a number of subtle differences between the nanopi4 variants, and where they disagree, the common DTSI currently follows the details of NanoPi M4. In order to improve matters even more, let's add a separate DTS for the M4 to which we can start splitting things out appropriately. The third variant, NanoPi NEO4, is a lot closer to the M4 than either is to the larger T4, so arguably could get away with just sharing the M4 DT for now (plus I have neither of the smaller boards to actually test with).

Signed-off-by Robin Murphy <[email protected]>

---
 .../devicetree/bindings/arm/rockchip.yaml      |  5 +++++
 arch/arm64/boot/dts/rockchip/Makefile          |  1 +
 .../boot/dts/rockchip/rk3399-nanopi-m4.dts     | 18 ++++++++++++++++++
 3 files changed, 24 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dts

Documentation/devicetree/bindings/arm/rockchip.yaml +0 -0

index bcc60c492a12..b4756e0cb7d0 100644

Documentation/devicetree/bindings/arm/rockchip.yaml +0 -0

       - description: GeekBuying GeekBox
         items:
           - const: geekbuying,geekbox

arch/arm64/boot/dts/rockchip/Makefile +1 -0

index 1c7406111dfd..91a669378605 100644
@@ -17,6 +17,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-scarlet-inx.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-scarlet-kd.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb

arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dts new file +18 -0

new file mode 100644
index 000000000000..8d3f0ba29c72
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPi M4 board device tree source
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+	model = "FriendlyElec NanoPi M4";
+	compatible = "friendlyarm,nanopi-m4", "rockchip,rk3399";
+};

Hi Robin,

Am Dienstag, 8. Januar 2019, 22:57:24 CET schrieb Robin Murphy:

Quoted 9 lines

There are a number of subtle differences between the nanopi4 variants, and where they disagree, the common DTSI currently follows the details of NanoPi M4. In order to improve matters even more, let's add a separate DTS for the M4 to which we can start splitting things out appropriately. The third variant, NanoPi NEO4, is a lot closer to the M4 than either is to the larger T4, so arguably could get away with just sharing the M4 DT for now (plus I have neither of the smaller boards to actually test with).

Quoted 1 line

Signed-off-by Robin Murphy <[email protected]>

I'm not sure if Rob actually checks the devicetree list or relies on patches Cc'ed directly to him for binding review, so you might want to add the 2 dt maintainers explicitly.

Quoted 12 lines

---
  .../devicetree/bindings/arm/rockchip.yaml      |  5 +++++
  arch/arm64/boot/dts/rockchip/Makefile          |  1 +
  .../boot/dts/rockchip/rk3399-nanopi-m4.dts     | 18 ++++++++++++++++++
  3 files changed, 24 insertions(+)

create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4.dts

Documentation/devicetree/bindings/arm/rockchip.yaml +0 -0

index bcc60c492a12..b4756e0cb7d0 100644

Documentation/devicetree/bindings/arm/rockchip.yaml properties: · line 99

Quoted 8 lines

Documentation/devicetree/bindings/arm/rockchip.yaml +5 -0

@@ -92,6 +92,11 @@ properties:
            - const: friendlyarm,nanopc-t4
            - const: rockchip,rk3399
 
+      - description: FriendlyElec NanoPi M4
+        items:
+          - const: friendlyarm,nanopi-m4
+          - const: rockchip,rk3399
+

When we hashed out the Rockchip yaml thingy, there also came up the possibility of grouping the similar boards together into an enum, see the rk3399-firefly or the rk3288-evb-* for example.

So the binding for both could possibly become:

- description: FriendlyElec NanoPi
items:
- enum:
- friendlyarm,nanopi-m4
- friendlyarm,nanopi-t4
- const: rockchip,rk3399

We didn't come up with a hard rule for all cases, but the Nano PI feels like it qualifies ;-)

The nanopi4 boards differ primarily in their power trees, with the main 5V and 3.3V rails having very different topologies on the smaller USB-C powered boards vs. the 12V-powered T4, as well as minor variation in other regulators related to various external connectors.

Additionally, the recovery key is only present on the T4 - ADC_IN1 is simply pulled high and not exposed on the other boards - and the lowest common denominator for MMC speed is actually HS200 according to the vendor DTs.

Signed-off-by Robin Murphy <[email protected]>

In common with most Rockchip reference designs, NanoPC-T4 has a passive IR receiver connected to PWM3. In lieu of a specialised driver for PWM-based IR pulse measurement, running the pin as a GPIO with the basic driver works perfectly well.

Signed-off-by Robin Murphy <[email protected]>

For whatever reason, the sdmmc_dectn function isn't working properly as-is, and microSD insertion and removal goes unnoticed. Flipping the pin into GPIO mode, however, does do the job, so let's just handle it that way for now until someone feels inclined to figure out what GRF voodoo or otherwise is needed for correct 'native' operation.

Signed-off-by Robin Murphy <[email protected]>

---
 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi +0 -0

index 9c723038d8f8..2a183a6af150 100644

arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi +4 -1

+			rockchip,pins = <0 RK_PA7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
 	};
 
 	sdio-pwrseq {

@@ -563,9 +567,10 @@
 	bus-width = <4>;
 	cap-sd-highspeed;
 	cap-mmc-highspeed;
+	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
 	disable-wp;
 	pinctrl-names = "default";
-	pinctrl-0 = <&sdmmc_bus4 &sdmmc_cd &sdmmc_clk &sdmmc_cmd>;
+	pinctrl-0 = <&sdmmc_bus4 &sdmmc0_det_l &sdmmc_clk &sdmmc_cmd>;
 	sd-uhs-sdr104;
 	vmmc-supply = <&vcc3v0_sd>;
 	vqmmc-supply = <&vcc_sdio>;

Am Dienstag, 8. Januar 2019, 22:57:27 CET schrieb Robin Murphy:

Quoted 11 lines

For whatever reason, the sdmmc_dectn function isn't working properly as-is, and microSD insertion and removal goes unnoticed. Flipping the pin into GPIO mode, however, does do the job, so let's just handle it that way for now until someone feels inclined to figure out what GRF voodoo or otherwise is needed for correct 'native' operation.

Signed-off-by Robin Murphy <[email protected]>

---
  arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 7 ++++++-
  1 file changed, 6 insertions(+), 1 deletion(-)

arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi line 509

Quoted 10 lines

arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi +2 -0

index 9c723038d8f8..2a183a6af150 100644
@@ -505,6 +505,10 @@
  		sdmmc0_pwr_h: sdmmc0-pwr-h {
  			rockchip,pins = <0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
  		};
+
+		sdmmc0_det_l: sdmmc0-det-l {

alphabetically by node-name please,
aka sdmmc0-det-* should be above sdmmc0-pwr-*

If you're respinning the whole series this should be fixed, otherwise I can also do that when applying.

Heiko

Quoted 18 lines

arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi +4 -1

+			rockchip,pins = <0 RK_PA7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
  	};
 
  	sdio-pwrseq {

@@ -563,9 +567,10 @@
  	bus-width = <4>;
  	cap-sd-highspeed;
  	cap-mmc-highspeed;
+	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
  	disable-wp;
  	pinctrl-names = "default";
-	pinctrl-0 = <&sdmmc_bus4 &sdmmc_cd &sdmmc_clk &sdmmc_cmd>;
+	pinctrl-0 = <&sdmmc_bus4 &sdmmc0_det_l &sdmmc_clk &sdmmc_cmd>;
  	sd-uhs-sdr104;
  	vmmc-supply = <&vcc3v0_sd>;
  	vqmmc-supply = <&vcc_sdio>;

Quoted 12 lines

Am Dienstag, 8. Januar 2019, 22:57:27 CET schrieb Robin Murphy:

Quoted 11 lines

For whatever reason, the sdmmc_dectn function isn't working properly as-is, and microSD insertion and removal goes unnoticed. Flipping the pin into GPIO mode, however, does do the job, so let's just handle it that way for now until someone feels inclined to figure out what GRF voodoo or otherwise is needed for correct 'native' operation.

Signed-off-by Robin Murphy <[email protected]>

---
  arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 7 ++++++-
  1 file changed, 6 insertions(+), 1 deletion(-)

Quoted 13 lines

arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi line 509

Quoted 10 lines

arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi +2 -0

index 9c723038d8f8..2a183a6af150 100644
@@ -505,6 +505,10 @@
  		sdmmc0_pwr_h: sdmmc0-pwr-h {
  			rockchip,pins = <0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
  		};
+
+		sdmmc0_det_l: sdmmc0-det-l {

alphabetically by node-name please,
aka sdmmc0-det-* should be above sdmmc0-pwr-*

Right you are, not sure how that one slipped through.

Quoted 2 lines

If you're respinning the whole series this should be fixed, otherwise I can also do that when applying.

I've fixed it up locally, although it might be worth holding off on this particular patch for the moment now that I've taken another look through the TRM and noticed those smoking-gun-looking bits in GRF_SIG_DETECT_CON{0,1} - I'll investigate...

[ side note - do you reckon there'd be any value in bolting a debugfs interface onto the GRF driver, or is the realistic answer to just use /dev/mem like everyone else and stop having silly ideas? ]

Am Mittwoch, 9. Januar 2019, 00:22:01 CET schrieb Robin Murphy:

Quoted 29 lines · Heiko Stuebner

Quoted 12 lines

Am Dienstag, 8. Januar 2019, 22:57:27 CET schrieb Robin Murphy:

Quoted 11 lines

For whatever reason, the sdmmc_dectn function isn't working properly as-is, and microSD insertion and removal goes unnoticed. Flipping the pin into GPIO mode, however, does do the job, so let's just handle it that way for now until someone feels inclined to figure out what GRF voodoo or otherwise is needed for correct 'native' operation.

Signed-off-by Robin Murphy <[email protected]>

---
   arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 7 ++++++-
   1 file changed, 6 insertions(+), 1 deletion(-)

Quoted 13 lines

arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi line 509

Quoted 10 lines

arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi +2 -0

index 9c723038d8f8..2a183a6af150 100644
@@ -505,6 +505,10 @@
   		sdmmc0_pwr_h: sdmmc0-pwr-h {
   			rockchip,pins = <0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
   		};
+
+		sdmmc0_det_l: sdmmc0-det-l {

alphabetically by node-name please,
aka sdmmc0-det-* should be above sdmmc0-pwr-*

Right you are, not sure how that one slipped through.

Quoted 7 lines

Quoted 2 lines

If you're respinning the whole series this should be fixed, otherwise I can also do that when applying.

I've fixed it up locally, although it might be worth holding off on this particular patch for the moment now that I've taken another look through the TRM and noticed those smoking-gun-looking bits in GRF_SIG_DETECT_CON{0,1} - I'll investigate...

Personally I'm very much fine with using a cd-gpio instead of trying to bring order to the GRF "chaos" ;-) as I'm also not really sure if we gain anything with the IP-internal detect mechanism.

But then do as you like :-D

Quoted 3 lines

[ side note - do you reckon there'd be any value in bolting a debugfs interface onto the GRF driver, or is the realistic answer to just use /dev/mem like everyone else and stop having silly ideas? ]

I don't think it would help much ... especially when it really only outputs the register contents in the same way as mem or so does.

Having to fiddle with GRF bits really should only happen in rare cases, so I guess mem should do the trick for that.

And the GRF driver also was a bit controversial anyway, with the title of "dumping ground" looming over it ... so I'd like to keep it small and simple ;-) .