[RFC PATCH 0/3] ARm64: amlogic: Introduce common GX family dtsi

[RFC PATCH 0/3] ARm64: amlogic: Introduce common GX family dtsi

[Neil Armstrong]

The new Amlogic GLX SoCs (S905X and S905D) are part of the Meson GX family so
they share some basic characteritics that can be described in a common GX
dtsi file used by the Meson GXBB and Meson GXL dtsi.

This patchset introduces the common dtsi and switches the GLX and GXBB to use
the common dtsi, the GXBB dtsi is reformated to handle this situation.

This patchset depends on Carlo Caione "ARM64: dts: amlogic: Add basic support for Amlogic S905X" [1]

[1] http://lkml.kernel.org/r/1472382113-10754-1-git-send-email-carlo@caione.org

Neil Armstrong (3):
  ARM64: dts: amlogic: Add Meson GX Family common dtsi
  ARM64: dts: amlogic: Switch Meson GXL dtsi to use common GX dtsi
  ARM64: dts: amlogic: Switch Meson GXBB dtsi to use common GX dtsi

 arch/arm64/boot/dts/amlogic/meson-gx-common.dtsi | 181 +++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi      | 320 +++++++----------------
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi       | 133 +---------
 3 files changed, 281 insertions(+), 353 deletions(-)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gx-common.dtsi

-- 
1.9.1

[RFC PATCH 1/3] ARM64: dts: amlogic: Add Meson GX Family common dtsi

[Neil Armstrong]

Introduce a common DTSI for Amlogic Meson GX Family including the
GXBB SoC and the GLX SoCs (S905X and S905D).

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gx-common.dtsi | 181 +++++++++++++++++++++++
 1 file changed, 181 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gx-common.dtsi

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-common.dtsi
new file mode 100644
index 0000000..fb393e9
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-common.dtsi
@@ -0,0 +1,181 @@
+/*
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * Copyright (c) 2016 Endless Computers, Inc.
+ * Author: Carlo Caione <carlo@endlessm.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <0x2>;
+		#size-cells = <0x0>;
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x1>;
+			enable-method = "psci";
+		};
+
+		cpu2: cpu@2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x2>;
+			enable-method = "psci";
+		};
+
+		cpu3: cpu@3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x3>;
+			enable-method = "psci";
+		};
+	};
+
+	arm-pmu {
+		compatible = "arm,cortex-a53-pmu";
+		interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>;
+	};
+
+	xtal: xtal-clk {
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+		clock-output-names = "xtal";
+		#clock-cells = <0>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		cbus: cbus@c1100000 {
+			compatible = "simple-bus";
+			reg = <0x0 0xc1100000 0x0 0x100000>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges = <0x0 0x0 0x0 0xc1100000 0x0 0x100000>;
+
+			uart_A: serial@84c0 {
+				compatible = "amlogic,meson-uart";
+				reg = <0x0 0x084c0 0x0 0x14>;
+				interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
+				clocks = <&xtal>;
+				status = "disabled";
+			};
+		};
+
+		gic: interrupt-controller@c4301000 {
+			compatible = "arm,gic-400";
+			reg = <0x0 0xc4301000 0 0x1000>,
+			      <0x0 0xc4302000 0 0x2000>,
+			      <0x0 0xc4304000 0 0x2000>,
+			      <0x0 0xc4306000 0 0x2000>;
+			interrupt-controller;
+			interrupts = <GIC_PPI 9
+				(GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+			#interrupt-cells = <3>;
+			#address-cells = <0>;
+		};
+
+		aobus: aobus@c8100000 {
+			compatible = "simple-bus";
+			reg = <0x0 0xc8100000 0x0 0x100000>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
+
+			uart_AO: serial@4c0 {
+				compatible = "amlogic,meson-uart";
+				reg = <0x0 0x004c0 0x0 0x14>;
+				interrupts = <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>;
+				clocks = <&xtal>;
+				status = "disabled";
+			};
+		};
+
+		apb: apb@d0000000 {
+			compatible = "simple-bus";
+			reg = <0x0 0xd0000000 0x0 0x200000>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges = <0x0 0x0 0x0 0xd0000000 0x0 0x200000>;
+		};
+	};
+};
-- 
1.9.1

[RFC PATCH 2/3] ARM64: dts: amlogic: Switch Meson GXL dtsi to use common GX dtsi

[Neil Armstrong]

The Amlogic Meson GXL should use the common GX dtsi as base.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 133 +----------------------------
 1 file changed, 1 insertion(+), 132 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 2aa4555..16891e0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -41,139 +41,8 @@
  *     OTHER DEALINGS IN THE SOFTWARE.
  */
 
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/interrupt-controller/irq.h>
-#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "meson-gx-common.dtsi"
 
 / {
 	compatible = "amlogic,meson-gxl";
-	interrupt-parent = <&gic>;
-	#address-cells = <2>;
-	#size-cells = <2>;
-
-	cpus {
-		#address-cells = <0x2>;
-		#size-cells = <0x0>;
-
-		cpu0: cpu@0 {
-			device_type = "cpu";
-			compatible = "arm,cortex-a53", "arm,armv8";
-			reg = <0x0 0x0>;
-			enable-method = "psci";
-		};
-
-		cpu1: cpu@1 {
-			device_type = "cpu";
-			compatible = "arm,cortex-a53", "arm,armv8";
-			reg = <0x0 0x1>;
-			enable-method = "psci";
-		};
-
-		cpu2: cpu@2 {
-			device_type = "cpu";
-			compatible = "arm,cortex-a53", "arm,armv8";
-			reg = <0x0 0x2>;
-			enable-method = "psci";
-		};
-
-		cpu3: cpu@3 {
-			device_type = "cpu";
-			compatible = "arm,cortex-a53", "arm,armv8";
-			reg = <0x0 0x3>;
-			enable-method = "psci";
-		};
-	};
-
-	arm-pmu {
-		compatible = "arm,cortex-a53-pmu";
-		interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
-	};
-
-	psci {
-		compatible = "arm,psci-0.2";
-		method = "smc";
-	};
-
-	timer {
-		compatible = "arm,armv8-timer";
-		interrupts = <GIC_PPI 13
-			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
-			     <GIC_PPI 14
-			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
-			     <GIC_PPI 11
-			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
-			     <GIC_PPI 10
-			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>;
-	};
-
-	xtal: xtal-clk {
-		compatible = "fixed-clock";
-		clock-frequency = <24000000>;
-		clock-output-names = "xtal";
-		#clock-cells = <0>;
-	};
-
-	soc {
-		compatible = "simple-bus";
-		#address-cells = <2>;
-		#size-cells = <2>;
-		ranges;
-
-		cbus: cbus@c1100000 {
-			compatible = "simple-bus";
-			reg = <0x0 0xc1100000 0x0 0x100000>;
-			#address-cells = <2>;
-			#size-cells = <2>;
-			ranges = <0x0 0x0 0x0 0xc1100000 0x0 0x100000>;
-
-			uart_A: serial@84c0 {
-				compatible = "amlogic,meson-uart";
-				reg = <0x0 0x084c0 0x0 0x14>;
-				interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
-				clocks = <&xtal>;
-				status = "disabled";
-			};
-		};
-
-		gic: interrupt-controller@c4301000 {
-			compatible = "arm,gic-400";
-			reg = <0x0 0xc4301000 0 0x1000>,
-			      <0x0 0xc4302000 0 0x2000>,
-			      <0x0 0xc4304000 0 0x2000>,
-			      <0x0 0xc4306000 0 0x2000>;
-			interrupt-controller;
-			interrupts = <GIC_PPI 9
-				(GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
-			#interrupt-cells = <3>;
-			#address-cells = <0>;
-		};
-
-		aobus: aobus@c8100000 {
-			compatible = "simple-bus";
-			reg = <0x0 0xc8100000 0x0 0x100000>;
-			#address-cells = <2>;
-			#size-cells = <2>;
-			ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
-
-			uart_AO: serial@4c0 {
-				compatible = "amlogic,meson-uart";
-				reg = <0x0 0x004c0 0x0 0x14>;
-				interrupts = <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>;
-				clocks = <&xtal>;
-				status = "disabled";
-			};
-		};
-
-		apb: apb@d0000000 {
-			compatible = "simple-bus";
-			reg = <0x0 0xd0000000 0x0 0x200000>;
-			#address-cells = <2>;
-			#size-cells = <2>;
-			ranges = <0x0 0x0 0x0 0xd0000000 0x0 0x200000>;
-		};
-	};
 };
-- 
1.9.1

[RFC PATCH 3/3] ARM64: dts: amlogic: Switch Meson GXBB dtsi to use common GX dtsi

[Neil Armstrong]

The Amlogic Meson GXBB should use the common GX dtsi as base.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 320 +++++++++-------------------
 1 file changed, 99 insertions(+), 221 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 2ea7bbd..e1e22fd 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -40,9 +40,7 @@
  *     OTHER DEALINGS IN THE SOFTWARE.
  */
 
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/interrupt-controller/irq.h>
-#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "meson-gx-common.dtsi"
 #include <dt-bindings/gpio/meson-gxbb-gpio.h>
 #include <dt-bindings/reset/amlogic,meson-gxbb-reset.h>
 #include <dt-bindings/clock/gxbb-clkc.h>
@@ -51,185 +49,8 @@
 
 / {
 	compatible = "amlogic,meson-gxbb";
-	interrupt-parent = <&gic>;
-	#address-cells = <2>;
-	#size-cells = <2>;
-
-	cpus {
-		#address-cells = <0x2>;
-		#size-cells = <0x0>;
-
-		cpu0: cpu@0 {
-			device_type = "cpu";
-			compatible = "arm,cortex-a53", "arm,armv8";
-			reg = <0x0 0x0>;
-			enable-method = "psci";
-		};
-
-		cpu1: cpu@1 {
-			device_type = "cpu";
-			compatible = "arm,cortex-a53", "arm,armv8";
-			reg = <0x0 0x1>;
-			enable-method = "psci";
-		};
-
-		cpu2: cpu@2 {
-			device_type = "cpu";
-			compatible = "arm,cortex-a53", "arm,armv8";
-			reg = <0x0 0x2>;
-			enable-method = "psci";
-		};
-
-		cpu3: cpu@3 {
-			device_type = "cpu";
-			compatible = "arm,cortex-a53", "arm,armv8";
-			reg = <0x0 0x3>;
-			enable-method = "psci";
-		};
-	};
-
-	arm-pmu {
-		compatible = "arm,cortex-a53-pmu";
-		interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
-	};
-
-	psci {
-		compatible = "arm,psci-0.2";
-		method = "smc";
-	};
-
-	timer {
-		compatible = "arm,armv8-timer";
-		interrupts = <GIC_PPI 13
-			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
-			     <GIC_PPI 14
-			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
-			     <GIC_PPI 11
-			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>,
-			     <GIC_PPI 10
-			(GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_EDGE_RISING)>;
-	};
-
-	xtal: xtal-clk {
-		compatible = "fixed-clock";
-		clock-frequency = <24000000>;
-		clock-output-names = "xtal";
-		#clock-cells = <0>;
-	};
 
 	soc {
-		compatible = "simple-bus";
-		#address-cells = <2>;
-		#size-cells = <2>;
-		ranges;
-
-		cbus: cbus@c1100000 {
-			compatible = "simple-bus";
-			reg = <0x0 0xc1100000 0x0 0x100000>;
-			#address-cells = <2>;
-			#size-cells = <2>;
-			ranges = <0x0 0x0 0x0 0xc1100000 0x0 0x100000>;
-
-			reset: reset-controller@4404 {
-				compatible = "amlogic,meson-gxbb-reset";
-				reg = <0x0 0x04404 0x0 0x20>;
-				#reset-cells = <1>;
-			};
-
-			uart_A: serial@84c0 {
-				compatible = "amlogic,meson-uart";
-				reg = <0x0 0x84c0 0x0 0x14>;
-				interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
-				clocks = <&xtal>;
-				status = "disabled";
-			};
-
-			uart_B: serial@84dc {
-				compatible = "amlogic,meson-uart";
-				reg = <0x0 0x84dc 0x0 0x14>;
-				interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
-				clocks = <&xtal>;
-				status = "disabled";
-			};
-
-			uart_C: serial@8700 {
-				compatible = "amlogic,meson-uart";
-				reg = <0x0 0x8700 0x0 0x14>;
-				interrupts = <GIC_SPI 93 IRQ_TYPE_EDGE_RISING>;
-				clocks = <&xtal>;
-				status = "disabled";
-			};
-
-			watchdog@98d0 {
-				compatible = "amlogic,meson-gxbb-wdt";
-				reg = <0x0 0x098d0 0x0 0x10>;
-				clocks = <&xtal>;
-			};
-		};
-
-		gic: interrupt-controller@c4301000 {
-			compatible = "arm,gic-400";
-			reg = <0x0 0xc4301000 0 0x1000>,
-			      <0x0 0xc4302000 0 0x2000>,
-			      <0x0 0xc4304000 0 0x2000>,
-			      <0x0 0xc4306000 0 0x2000>;
-			interrupt-controller;
-			interrupts = <GIC_PPI 9
-				(GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
-			#interrupt-cells = <3>;
-			#address-cells = <0>;
-		};
-
-		aobus: aobus@c8100000 {
-			compatible = "simple-bus";
-			reg = <0x0 0xc8100000 0x0 0x100000>;
-			#address-cells = <2>;
-			#size-cells = <2>;
-			ranges = <0x0 0x0 0x0 0xc8100000 0x0 0x100000>;
-
-			pinctrl_aobus: pinctrl@14 {
-				compatible = "amlogic,meson-gxbb-aobus-pinctrl";
-				#address-cells = <2>;
-				#size-cells = <2>;
-				ranges;
-
-				gpio_ao: bank@14 {
-					reg = <0x0 0x00014 0x0 0x8>,
-					      <0x0 0x0002c 0x0 0x4>,
-					      <0x0 0x00024 0x0 0x8>;
-					reg-names = "mux", "pull", "gpio";
-					gpio-controller;
-					#gpio-cells = <2>;
-				};
-
-				uart_ao_a_pins: uart_ao_a {
-					mux {
-						groups = "uart_tx_ao_a", "uart_rx_ao_a";
-						function = "uart_ao";
-					};
-				};
-			};
-
-			clkc_AO: clock-controller@040 {
-				compatible = "amlogic,gxbb-aoclkc";
-				reg = <0x0 0x00040 0x0 0x4>;
-				#clock-cells = <1>;
-				#reset-cells = <1>;
-			};
-
-			uart_AO: serial@4c0 {
-				compatible = "amlogic,meson-uart";
-				reg = <0x0 0x004c0 0x0 0x14>;
-				interrupts = <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>;
-				clocks = <&xtal>;
-				status = "disabled";
-			};
-		};
-
 		periphs: periphs@c8834000 {
 			compatible = "simple-bus";
 			reg = <0x0 0xc8834000 0x0 0x2000>;
@@ -340,47 +161,6 @@
 			};
 		};
 
-		apb: apb@d0000000 {
-			compatible = "simple-bus";
-			reg = <0x0 0xd0000000 0x0 0x200000>;
-			#address-cells = <2>;
-			#size-cells = <2>;
-			ranges = <0x0 0x0 0x0 0xd0000000 0x0 0x200000>;
-
-			sd_emmc_a: mmc@70000 {
-				compatible = "amlogic,meson-gxbb-mmc";
-				reg = <0x0 0x70000 0x0 0x2000>;
-				interrupts = <GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
-				clocks = <&clkc CLKID_SD_EMMC_A>,
-					 <&xtal>,
-					 <&clkc CLKID_FCLK_DIV2>;
-				clock-names = "core", "clkin0", "clkin1";
-				status = "disabled";
-			};
-
-			sd_emmc_b: mmc@72000 {
-				compatible = "amlogic,meson-gxbb-mmc";
-				reg = <0x0 0x72000 0x0 0x2000>;
-				interrupts = <GIC_SPI 217 IRQ_TYPE_EDGE_RISING>;
-				clocks = <&clkc CLKID_SD_EMMC_B>,
-					 <&xtal>,
-					 <&clkc CLKID_FCLK_DIV2>;
-				clock-names = "core", "clkin0", "clkin1";
-				status = "disabled";
-			};
-
-			sd_emmc_c: mmc@74000 {
-				compatible = "amlogic,meson-gxbb-mmc";
-				reg = <0x0 0x74000 0x0 0x2000>;
-				interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>;
-				clocks = <&clkc CLKID_SD_EMMC_C>,
-					 <&xtal>,
-					 <&clkc CLKID_FCLK_DIV2>;
-				clock-names = "core", "clkin0", "clkin1";
-				status = "disabled";
-			};
-		};
-
 		ethmac: ethernet@c9410000 {
 			compatible = "amlogic,meson6-dwmac", "snps,dwmac";
 			reg = <0x0 0xc9410000 0x0 0x10000
@@ -394,3 +174,101 @@
 		};
 	};
 };
+
+&cbus {
+	reset: reset-controller@4404 {
+		compatible = "amlogic,meson-gxbb-reset";
+		reg = <0x0 0x04404 0x0 0x20>;
+		#reset-cells = <1>;
+	};
+
+	uart_B: serial@84dc {
+		compatible = "amlogic,meson-uart";
+		reg = <0x0 0x84dc 0x0 0x14>;
+		interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
+		clocks = <&xtal>;
+		status = "disabled";
+	};
+
+	uart_C: serial@8700 {
+		compatible = "amlogic,meson-uart";
+		reg = <0x0 0x8700 0x0 0x14>;
+		interrupts = <GIC_SPI 93 IRQ_TYPE_EDGE_RISING>;
+		clocks = <&xtal>;
+		status = "disabled";
+	};
+
+	watchdog@98d0 {
+		compatible = "amlogic,meson-gxbb-wdt";
+		reg = <0x0 0x098d0 0x0 0x10>;
+		clocks = <&xtal>;
+	};
+};
+
+&aobus {
+	pinctrl_aobus: pinctrl@14 {
+		compatible = "amlogic,meson-gxbb-aobus-pinctrl";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		gpio_ao: bank@14 {
+			reg = <0x0 0x00014 0x0 0x8>,
+			      <0x0 0x0002c 0x0 0x4>,
+			      <0x0 0x00024 0x0 0x8>;
+			reg-names = "mux", "pull", "gpio";
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
+		uart_ao_a_pins: uart_ao_a {
+			mux {
+				groups = "uart_tx_ao_a", "uart_rx_ao_a";
+				function = "uart_ao";
+			};
+		};
+	};
+
+	clkc_AO: clock-controller@040 {
+		compatible = "amlogic,gxbb-aoclkc";
+		reg = <0x0 0x00040 0x0 0x4>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+};
+
+&apb {
+	sd_emmc_a: mmc@70000 {
+		compatible = "amlogic,meson-gxbb-mmc";
+		reg = <0x0 0x70000 0x0 0x2000>;
+		interrupts = <GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
+		clocks = <&clkc CLKID_SD_EMMC_A>,
+			 <&xtal>,
+			 <&clkc CLKID_FCLK_DIV2>;
+		clock-names = "core", "clkin0", "clkin1";
+		status = "disabled";
+	};
+
+	sd_emmc_b: mmc@72000 {
+		compatible = "amlogic,meson-gxbb-mmc";
+		reg = <0x0 0x72000 0x0 0x2000>;
+		interrupts = <GIC_SPI 217 IRQ_TYPE_EDGE_RISING>;
+		clocks = <&clkc CLKID_SD_EMMC_B>,
+			 <&xtal>,
+			 <&clkc CLKID_FCLK_DIV2>;
+		clock-names = "core", "clkin0", "clkin1";
+		status = "disabled";
+	};
+
+	sd_emmc_c: mmc@74000 {
+		compatible = "amlogic,meson-gxbb-mmc";
+		reg = <0x0 0x74000 0x0 0x2000>;
+		interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>;
+		clocks = <&clkc CLKID_SD_EMMC_C>,
+			 <&xtal>,
+			 <&clkc CLKID_FCLK_DIV2>;
+		clock-names = "core", "clkin0", "clkin1";
+		status = "disabled";
+	};
+};
+
-- 
1.9.1

Re: [RFC PATCH 0/3] ARm64: amlogic: Introduce common GX family dtsi

[Carlo Caione]

On Mon, Aug 29, 2016 at 9:56 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> The new Amlogic GLX SoCs (S905X and S905D) are part of the Meson GX family so
> they share some basic characteritics that can be described in a common GX
> dtsi file used by the Meson GXBB and Meson GXL dtsi.
>
> This patchset introduces the common dtsi and switches the GLX and GXBB to use
> the common dtsi, the GXBB dtsi is reformated to handle this situation.
>
> This patchset depends on Carlo Caione "ARM64: dts: amlogic: Add basic support for Amlogic S905X" [1]
>
> [1] http://lkml.kernel.org/r/1472382113-10754-1-git-send-email-carlo@caione.org
>
> Neil Armstrong (3):
>   ARM64: dts: amlogic: Add Meson GX Family common dtsi
>   ARM64: dts: amlogic: Switch Meson GXL dtsi to use common GX dtsi
>   ARM64: dts: amlogic: Switch Meson GXBB dtsi to use common GX dtsi

FWIW
Acked-by: Carlo Caione <carlo@endlessm.com>

-- 
Carlo Caione

Re: [RFC PATCH 0/3] ARm64: amlogic: Introduce common GX family dtsi

[Andreas Färber]

Am 29.08.2016 um 10:01 schrieb Carlo Caione:
> On Mon, Aug 29, 2016 at 9:56 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> The new Amlogic GLX SoCs (S905X and S905D) are part of the Meson GX family so
>> they share some basic characteritics that can be described in a common GX
>> dtsi file used by the Meson GXBB and Meson GXL dtsi.
>>
>> This patchset introduces the common dtsi and switches the GLX and GXBB to use
>> the common dtsi, the GXBB dtsi is reformated to handle this situation.
>>
>> This patchset depends on Carlo Caione "ARM64: dts: amlogic: Add basic support for Amlogic S905X" [1]
>>
>> [1] http://lkml.kernel.org/r/1472382113-10754-1-git-send-email-carlo@caione.org
>>
>> Neil Armstrong (3):
>>   ARM64: dts: amlogic: Add Meson GX Family common dtsi
>>   ARM64: dts: amlogic: Switch Meson GXL dtsi to use common GX dtsi
>>   ARM64: dts: amlogic: Switch Meson GXBB dtsi to use common GX dtsi
> 
> FWIW
> Acked-by: Carlo Caione <carlo@endlessm.com>

Adding an unused .dtsi duplicating GXBB makes me uneasy.

Any chance we can simplify this to at most two steps?
1) Move code from gxbb to gx (1/3 + 3/3)
2) Add gxl using gx ("Add basic support for Amlogic S905X" + 2/3)

Alternatively:
1) "Add basic support for Amlogic S905X"
2) Factor out common bits (1/3 + 2/3 + 3/3)

As for bike-shedding, is there a GX family as well or could we drop
-common? .dtsi is always something common - compare Exynos or i.MX.
Since there are meson8b and meson8 I was anticipating that after gxbb
would come gx, not gxl.

Do you know what the L in GXL is for? Should we consider renaming gxbb
to gxb, and then also insert -s905 as suggested by Kevin, for symmetry?
U-Boot is still in an early stage with $fdtfile issues remaining that I
need to iterate over; DT compatible strings would need to remain though.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC PATCH 0/3] ARm64: amlogic: Introduce common GX family dtsi

[Carlo Caione]

On 29/08/16 20:38, Andreas Färber wrote:
> Am 29.08.2016 um 10:01 schrieb Carlo Caione:
> > On Mon, Aug 29, 2016 at 9:56 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> >> The new Amlogic GLX SoCs (S905X and S905D) are part of the Meson GX family so
> >> they share some basic characteritics that can be described in a common GX
> >> dtsi file used by the Meson GXBB and Meson GXL dtsi.
> >>
> >> This patchset introduces the common dtsi and switches the GLX and GXBB to use
> >> the common dtsi, the GXBB dtsi is reformated to handle this situation.
> >>
> >> This patchset depends on Carlo Caione "ARM64: dts: amlogic: Add basic support for Amlogic S905X" [1]
> >>
> >> [1] http://lkml.kernel.org/r/1472382113-10754-1-git-send-email-carlo@caione.org
> >>
> >> Neil Armstrong (3):
> >>   ARM64: dts: amlogic: Add Meson GX Family common dtsi
> >>   ARM64: dts: amlogic: Switch Meson GXL dtsi to use common GX dtsi
> >>   ARM64: dts: amlogic: Switch Meson GXBB dtsi to use common GX dtsi
> > 
> > FWIW
> > Acked-by: Carlo Caione <carlo@endlessm.com>
> 
> Adding an unused .dtsi duplicating GXBB makes me uneasy.

S905x (GXL) is different from S905 (GXBB), it's unused now but in the
future we can expect something different in the two DTSI.

> Any chance we can simplify this to at most two steps?
> 1) Move code from gxbb to gx (1/3 + 3/3)
> 2) Add gxl using gx ("Add basic support for Amlogic S905X" + 2/3)

fine by me.

> Alternatively:
> 1) "Add basic support for Amlogic S905X"
> 2) Factor out common bits (1/3 + 2/3 + 3/3)

how is this different from this patchset?

> As for bike-shedding, is there a GX family as well or could we drop
> -common? .dtsi is always something common - compare Exynos or i.MX.
> Since there are meson8b and meson8 I was anticipating that after gxbb
> would come gx, not gxl.

AFAIK we have:
- GXBB
- GXL
- GXM
- GXTVBB

> Do you know what the L in GXL is for? Should we consider renaming gxbb
> to gxb, and then also insert -s905 as suggested by Kevin, for symmetry?

Yes, that make sense.

Cheers,

-- 
Carlo Caione

Re: [RFC PATCH 0/3] ARm64: amlogic: Introduce common GX family dtsi

[Andreas Färber]

Am 29.08.2016 um 21:50 schrieb Carlo Caione:
> On 29/08/16 20:38, Andreas Färber wrote:
>> Am 29.08.2016 um 10:01 schrieb Carlo Caione:
>>> On Mon, Aug 29, 2016 at 9:56 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>> Neil Armstrong (3):
>>>>   ARM64: dts: amlogic: Add Meson GX Family common dtsi
>>>>   ARM64: dts: amlogic: Switch Meson GXL dtsi to use common GX dtsi
>>>>   ARM64: dts: amlogic: Switch Meson GXBB dtsi to use common GX dtsi
>>
>> Adding an unused .dtsi duplicating GXBB makes me uneasy.
> 
> S905x (GXL) is different from S905 (GXBB), it's unused now but in the
> future we can expect something different in the two DTSI.

Guess I need to be --verbose. ;)

I meant: After patch 1/3 there is a gx-common.dtsi that duplicates
contents of gxbb.dtsi and is not yet #include'd anywhere, i.e., unused.

>> Any chance we can simplify this to at most two steps?
>> 1) Move code from gxbb to gx (1/3 + 3/3)
>> 2) Add gxl using gx ("Add basic support for Amlogic S905X" + 2/3)
> 
> fine by me.
> 
>> Alternatively:
>> 1) "Add basic support for Amlogic S905X"
>> 2) Factor out common bits (1/3 + 2/3 + 3/3)
> 
> how is this different from this patchset?

I'm suggesting we do "atomic" move operations, not copy and then remove.

The difference between my two suggestions is how many and which changes
we squash - I do appreciate that it's easy for review as is but what I
have in mind is that either we should get this refactoring applied asap
(#1 1)) and rebase all pending patches on it, or we may need to rebase
the refactoring onto any pending MMC, SDIO, etc. patches, which I feel
is safer to do in one big patch (#2 2)) than split over multiple ones.
It really depends on the merge order and roadmap you guys have in mind.

>> As for bike-shedding, is there a GX family as well or could we drop
>> -common? .dtsi is always something common - compare Exynos or i.MX.
>> Since there are meson8b and meson8 I was anticipating that after gxbb
>> would come gx, not gxl.
> 
> AFAIK we have:
> - GXBB
> - GXL
> - GXM
> - GXTVBB
> 
>> Do you know what the L in GXL is for? Should we consider renaming gxbb
>> to gxb, and then also insert -s905 as suggested by Kevin, for symmetry?
> 
> Yes, that make sense.

Hm, GXTVB would still be longer than GXL then, not much point then.
We could still do -gxbb-s905 though.

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC PATCH 0/3] ARm64: amlogic: Introduce common GX family dtsi

[Neil Armstrong]

On 08/29/2016 10:15 PM, Andreas Färber wrote:
> Am 29.08.2016 um 21:50 schrieb Carlo Caione:
>> On 29/08/16 20:38, Andreas Färber wrote:
>>> Am 29.08.2016 um 10:01 schrieb Carlo Caione:
>>>> On Mon, Aug 29, 2016 at 9:56 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>>> Neil Armstrong (3):
>>>>>   ARM64: dts: amlogic: Add Meson GX Family common dtsi
>>>>>   ARM64: dts: amlogic: Switch Meson GXL dtsi to use common GX dtsi
>>>>>   ARM64: dts: amlogic: Switch Meson GXBB dtsi to use common GX dtsi
>>>
>>> Adding an unused .dtsi duplicating GXBB makes me uneasy.
>>
>> S905x (GXL) is different from S905 (GXBB), it's unused now but in the
>> future we can expect something different in the two DTSI.
> 
> Guess I need to be --verbose. ;)
> 
> I meant: After patch 1/3 there is a gx-common.dtsi that duplicates
> contents of gxbb.dtsi and is not yet #include'd anywhere, i.e., unused.
> 
>>> Any chance we can simplify this to at most two steps?
>>> 1) Move code from gxbb to gx (1/3 + 3/3)
>>> 2) Add gxl using gx ("Add basic support for Amlogic S905X" + 2/3)
>>
>> fine by me.

I can merge carlo's GXL support into this patchet.

>>
>>> Alternatively:
>>> 1) "Add basic support for Amlogic S905X"
>>> 2) Factor out common bits (1/3 + 2/3 + 3/3)
>>
>> how is this different from this patchset?
> 
> I'm suggesting we do "atomic" move operations, not copy and then remove.
> 
> The difference between my two suggestions is how many and which changes
> we squash - I do appreciate that it's easy for review as is but what I
> have in mind is that either we should get this refactoring applied asap
> (#1 1)) and rebase all pending patches on it, or we may need to rebase
> the refactoring onto any pending MMC, SDIO, etc. patches, which I feel
> is safer to do in one big patch (#2 2)) than split over multiple ones.
> It really depends on the merge order and roadmap you guys have in mind.

I'm not very convinced about the utility the reduce commits... having a dtsi alone won't arm anyone.
Nevertheless, I will squash the two commits.

> 
>>> As for bike-shedding, is there a GX family as well or could we drop
>>> -common? .dtsi is always something common - compare Exynos or i.MX.
>>> Since there are meson8b and meson8 I was anticipating that after gxbb
>>> would come gx, not gxl.
>>
>> AFAIK we have:
>> - GXBB
>> - GXL
>> - GXM
>> - GXTVBB
>>
>>> Do you know what the L in GXL is for? Should we consider renaming gxbb
>>> to gxb, and then also insert -s905 as suggested by Kevin, for symmetry?
>>
>> Yes, that make sense.

As Amlogic told us, we have at least two families :
 - GXBB with the S905
 - GXL with the S905D and S905X

The GXL and GXBB families will share a lot, except the clocks tree, pinctrl registers, USB IP versions and at least ethernet PHY handling.

But the two GXL SoCs will still share a lot, maybe everything, we are not sure for now.

In the Amlogic SDK kernel, we can see more families :
 - GXM seems to be the S912 since it has two clusters of 4xA53, but looks identical to GXL for pinctrl and clocks
 - GXTVBB looking at the Amlogic SDK it could be a GXBB variant with a different GPU (t83x instead of mali450), pinctrl and clocks

In their SDK, there is a single GXL pinctrl and clock driver for GXL and GXM.

Taking in account all the boards, families and SoCs, we should have the following:
meson-gx-common.dtsi
├── meson-gxbb-s905.dtsi
│   ├── meson-gxbb-s905-odroidc2.dts
│   └── meson-gxbb-s905-p20x.dtsi
│       ├── meson-gxbb-s905-p200.dts
│       └── meson-gxbb-s905-p201.dts
├── meson-gxl.dtsi
│   ├── meson-gxl-s905d.dtsi
│   │   └── meson-gxl-s905d-p23x.dts
│   │       ├── meson-gxl-s905d-p230.dts
│   │       └── meson-gxl-s905d-p231.dts
│   └── meson-gxl-s905x.dtsi
│       └── meson-gxl-s905x-p212.dts
└── meson-gxm-s912.dtsi
    └── meson-gxm-s912-q20x.dtsi
        ├── meson-gxm-s912-q200.dts
        └── meson-gxm-s912-q201.dts

But since GXBB will only be S905, we can drop the S905 naming and keep what is already upstream,
then GXM won't happen until a certain time so I plan to push the following :

meson-gx-common.dtsi
├── meson-gxbb.dtsi
│   ├── meson-gxbb-odroidc2.dts
│   └── meson-gxbb-p20x.dtsi
│       ├── meson-gxbb-p200.dts
│       └── meson-gxbb-p201.dts
└── meson-gxl.dtsi
    ├── meson-gxl-s905d.dtsi
    │   └── meson-gxl-s905d-p23x.dts
    │       ├── meson-gxl-s905d-p230.dts
    │       └── meson-gxl-s905d-p231.dts
    └── meson-gxl-s905x.dtsi
        └── meson-gxl-s905x-p212.dts

But the meson-gxl-s905d.dtsi, meson-gxl-s905x.dtsi and meson-gxl.dtsi will be empty until we push the pinctrl, clock, ethernet PHY and USB nodes for them.

> 
> Hm, GXTVB would still be longer than GXL then, not much point then.
> We could still do -gxbb-s905 though.
> 
> Cheers,
> Andreas
> 

Thanks,
Neil

Re: [RFC PATCH 0/3] ARm64: amlogic: Introduce common GX family dtsi

[Kevin Hilman]

Neil Armstrong <narmstrong@baylibre.com> writes:

> On 08/29/2016 10:15 PM, Andreas Färber wrote:
>> Am 29.08.2016 um 21:50 schrieb Carlo Caione:
>>> On 29/08/16 20:38, Andreas Färber wrote:
>>>> Am 29.08.2016 um 10:01 schrieb Carlo Caione:
>>>>> On Mon, Aug 29, 2016 at 9:56 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>>>> Neil Armstrong (3):
>>>>>>   ARM64: dts: amlogic: Add Meson GX Family common dtsi
>>>>>>   ARM64: dts: amlogic: Switch Meson GXL dtsi to use common GX dtsi
>>>>>>   ARM64: dts: amlogic: Switch Meson GXBB dtsi to use common GX dtsi
>>>>
>>>> Adding an unused .dtsi duplicating GXBB makes me uneasy.
>>>
>>> S905x (GXL) is different from S905 (GXBB), it's unused now but in the
>>> future we can expect something different in the two DTSI.
>> 
>> Guess I need to be --verbose. ;)
>> 
>> I meant: After patch 1/3 there is a gx-common.dtsi that duplicates
>> contents of gxbb.dtsi and is not yet #include'd anywhere, i.e., unused.
>> 
>>>> Any chance we can simplify this to at most two steps?
>>>> 1) Move code from gxbb to gx (1/3 + 3/3)
>>>> 2) Add gxl using gx ("Add basic support for Amlogic S905X" + 2/3)
>>>
>>> fine by me.
>
> I can merge carlo's GXL support into this patchet.
>
>>>
>>>> Alternatively:
>>>> 1) "Add basic support for Amlogic S905X"
>>>> 2) Factor out common bits (1/3 + 2/3 + 3/3)
>>>
>>> how is this different from this patchset?
>> 
>> I'm suggesting we do "atomic" move operations, not copy and then remove.
>> 
>> The difference between my two suggestions is how many and which changes
>> we squash - I do appreciate that it's easy for review as is but what I
>> have in mind is that either we should get this refactoring applied asap
>> (#1 1)) and rebase all pending patches on it, or we may need to rebase
>> the refactoring onto any pending MMC, SDIO, etc. patches, which I feel
>> is safer to do in one big patch (#2 2)) than split over multiple ones.
>> It really depends on the merge order and roadmap you guys have in mind.
>
> I'm not very convinced about the utility the reduce commits... having a dtsi alone won't arm anyone.
> Nevertheless, I will squash the two commits.
>
>> 
>>>> As for bike-shedding, is there a GX family as well or could we drop
>>>> -common? .dtsi is always something common - compare Exynos or i.MX.
>>>> Since there are meson8b and meson8 I was anticipating that after gxbb
>>>> would come gx, not gxl.
>>>
>>> AFAIK we have:
>>> - GXBB
>>> - GXL
>>> - GXM
>>> - GXTVBB
>>>
>>>> Do you know what the L in GXL is for? Should we consider renaming gxbb
>>>> to gxb, and then also insert -s905 as suggested by Kevin, for symmetry?
>>>
>>> Yes, that make sense.
>
> As Amlogic told us, we have at least two families :
>  - GXBB with the S905
>  - GXL with the S905D and S905X
>
> The GXL and GXBB families will share a lot, except the clocks tree, pinctrl registers, USB IP versions and at least ethernet PHY handling.
>
> But the two GXL SoCs will still share a lot, maybe everything, we are not sure for now.
>
> In the Amlogic SDK kernel, we can see more families :
>  - GXM seems to be the S912 since it has two clusters of 4xA53, but looks identical to GXL for pinctrl and clocks
>  - GXTVBB looking at the Amlogic SDK it could be a GXBB variant with a different GPU (t83x instead of mali450), pinctrl and clocks
>
> In their SDK, there is a single GXL pinctrl and clock driver for GXL and GXM.
>
> Taking in account all the boards, families and SoCs, we should have the following:
> meson-gx-common.dtsi
> ├── meson-gxbb-s905.dtsi
> │   ├── meson-gxbb-s905-odroidc2.dts
> │   └── meson-gxbb-s905-p20x.dtsi
> │       ├── meson-gxbb-s905-p200.dts
> │       └── meson-gxbb-s905-p201.dts
> ├── meson-gxl.dtsi
> │   ├── meson-gxl-s905d.dtsi
> │   │   └── meson-gxl-s905d-p23x.dts
> │   │       ├── meson-gxl-s905d-p230.dts
> │   │       └── meson-gxl-s905d-p231.dts
> │   └── meson-gxl-s905x.dtsi
> │       └── meson-gxl-s905x-p212.dts
> └── meson-gxm-s912.dtsi
>     └── meson-gxm-s912-q20x.dtsi
>         ├── meson-gxm-s912-q200.dts
>         └── meson-gxm-s912-q201.dts
>
> But since GXBB will only be S905, we can drop the S905 naming and keep what is already upstream,
> then GXM won't happen until a certain time so I plan to push the following :
>
> meson-gx-common.dtsi

nit: drop the -common, as suggested by Andreas since it's kidna
redundant since it's a .dtsi.

> ├── meson-gxbb.dtsi
> │   ├── meson-gxbb-odroidc2.dts
> │   └── meson-gxbb-p20x.dtsi
> │       ├── meson-gxbb-p200.dts
> │       └── meson-gxbb-p201.dts
> └── meson-gxl.dtsi
>     ├── meson-gxl-s905d.dtsi
>     │   └── meson-gxl-s905d-p23x.dts
>     │       ├── meson-gxl-s905d-p230.dts
>     │       └── meson-gxl-s905d-p231.dts
>     └── meson-gxl-s905x.dtsi
>         └── meson-gxl-s905x-p212.dts
>
> But the meson-gxl-s905d.dtsi, meson-gxl-s905x.dtsi and meson-gxl.dtsi will be empty until we push the pinctrl, clock, ethernet PHY and USB nodes for them.

Looks good to me.

Kevin