[PATCH v3 0/8] ARM: Initial RTD1195 and MeLE X1000 support

[PATCH v3 0/8] ARM: Initial RTD1195 and MeLE X1000 support

[Andreas Färber]

Hello,

This series adds initial support for Realtek RTD1195 SoC
and adds a Device Tree for the MeLE X1000 TV set-top-box.

v3 includes various memory range related cleanups and
collects follow-up patches from multiple other series.

The final patch is still in need of feedback from Realtek
for how to name and handle this magic register and bit(s).

SMP (i.e., the second core) is still dependent on two new
bindings/drivers.

More details on the device at:
https://en.opensuse.org/HCL:Mele_X1000

Latest experimental patches at:
https://github.com/afaerber/linux/commits/rtd1295-next

Have a lot of fun!

Cheers,
Andreas

v2 -> v3:
* Incorporate cleanup patches from RTD1395 series
* Fixed r-bus size (James)
* Fixed r-bus node name (Rob)
* Include reset patches from RTD1295 reset series, rebased onto r-bus

v1 -> v2:
* Do not redundantly select COMMON_CLK (Arnd)
* Drop further unneeded selects
* Clean up memory reservations (Rob)
* Enable arch timer

Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: James Tai <james.tai@realtek.com>

Andreas Färber (8):
  dt-bindings: arm: realtek: Add RTD1195 and MeLE X1000
  ARM: Prepare Realtek RTD1195
  ARM: dts: Prepare Realtek RTD1195 and MeLE X1000
  ARM: dts: rtd1195: Introduce r-bus
  dt-bindings: reset: Add Realtek RTD1195
  ARM: dts: rtd1195: Add reset nodes
  ARM: dts: rtd1195: Add UART resets
  ARM: realtek: Enable RTD1195 arch timer

 Documentation/devicetree/bindings/arm/realtek.yaml |   6 +
 arch/arm/Kconfig                                   |   2 +
 arch/arm/Makefile                                  |   3 +
 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/rtd1195-mele-x1000.dts           |  31 ++++
 arch/arm/boot/dts/rtd1195.dtsi                     | 162 +++++++++++++++++++++
 arch/arm/mach-realtek/Kconfig                      |  11 ++
 arch/arm/mach-realtek/Makefile                     |   2 +
 arch/arm/mach-realtek/rtd1195.c                    |  53 +++++++
 include/dt-bindings/reset/realtek,rtd1195.h        |  74 ++++++++++
 10 files changed, 346 insertions(+)
 create mode 100644 arch/arm/boot/dts/rtd1195-mele-x1000.dts
 create mode 100644 arch/arm/boot/dts/rtd1195.dtsi
 create mode 100644 arch/arm/mach-realtek/Kconfig
 create mode 100644 arch/arm/mach-realtek/Makefile
 create mode 100644 arch/arm/mach-realtek/rtd1195.c
 create mode 100644 include/dt-bindings/reset/realtek,rtd1195.h

-- 
2.16.4

[PATCH v3 1/8] dt-bindings: arm: realtek: Add RTD1195 and MeLE X1000

[Andreas Färber]

Add bindings for Realtek RTD1195 SoC and MeLE X1000 TV box.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v1 -> v2 -> v3: Unchanged
 
 Documentation/devicetree/bindings/arm/realtek.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml
index ab59de17152d..091616880d25 100644
--- a/Documentation/devicetree/bindings/arm/realtek.yaml
+++ b/Documentation/devicetree/bindings/arm/realtek.yaml
@@ -14,6 +14,12 @@ properties:
     const: '/'
   compatible:
     oneOf:
+      # RTD1195 SoC based boards
+      - items:
+          - enum:
+              - mele,x1000 # MeLE X1000
+          - const: realtek,rtd1195
+
       # RTD1293 SoC based boards
       - items:
           - enum:
-- 
2.16.4

[PATCH v3 2/8] ARM: Prepare Realtek RTD1195

[Andreas Färber]

Introduce ARCH_REALTEK Kconfig option also for 32-bit Arm.

Override the text offset to cope with boot ROM occupying first 0xa800
bytes and further reservations up to 0xf4000 (compare Device Tree).

Add a custom machine_desc to enforce memory carveout for I/O registers.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v2 -> v3:
 * Fixed r-bus size in .reserve from 0x100000 to 0x70000 (James)
 
 v1 -> v2:
 * Dropped selection of COMMON_CLK (Arnd)
 * Dropped selection of AMBA, SCU, TWD
 * Added comment about text offset to distinguish from HTC comment above
 * Added machine_desc with .reserve to exclude peripheral spaces (Rob)
 
 arch/arm/Kconfig                |  2 ++
 arch/arm/Makefile               |  3 +++
 arch/arm/mach-realtek/Kconfig   | 11 +++++++++++
 arch/arm/mach-realtek/Makefile  |  2 ++
 arch/arm/mach-realtek/rtd1195.c | 37 +++++++++++++++++++++++++++++++++++++
 5 files changed, 55 insertions(+)
 create mode 100644 arch/arm/mach-realtek/Kconfig
 create mode 100644 arch/arm/mach-realtek/Makefile
 create mode 100644 arch/arm/mach-realtek/rtd1195.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9771b56e79f1..cd37b5e9f86d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -699,6 +699,8 @@ source "arch/arm/mach-qcom/Kconfig"
 
 source "arch/arm/mach-rda/Kconfig"
 
+source "arch/arm/mach-realtek/Kconfig"
+
 source "arch/arm/mach-realview/Kconfig"
 
 source "arch/arm/mach-rockchip/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index db857d07114f..16d41efea7f2 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -148,6 +148,8 @@ head-y		:= arch/arm/kernel/head$(MMUEXT).o
 textofs-y	:= 0x00008000
 # We don't want the htc bootloader to corrupt kernel during resume
 textofs-$(CONFIG_PM_H1940)      := 0x00108000
+# RTD1195 has Boot ROM at start of address space
+textofs-$(CONFIG_ARCH_REALTEK)  := 0x00108000
 # SA1111 DMA bug: we don't want the kernel to live in precious DMA-able memory
 ifeq ($(CONFIG_ARCH_SA1100),y)
 textofs-$(CONFIG_SA1111) := 0x00208000
@@ -207,6 +209,7 @@ machine-$(CONFIG_ARCH_PICOXCELL)	+= picoxcell
 machine-$(CONFIG_ARCH_PXA)		+= pxa
 machine-$(CONFIG_ARCH_QCOM)		+= qcom
 machine-$(CONFIG_ARCH_RDA)		+= rda
+machine-$(CONFIG_ARCH_REALTEK)		+= realtek
 machine-$(CONFIG_ARCH_REALVIEW)		+= realview
 machine-$(CONFIG_ARCH_ROCKCHIP)		+= rockchip
 machine-$(CONFIG_ARCH_RPC)		+= rpc
diff --git a/arch/arm/mach-realtek/Kconfig b/arch/arm/mach-realtek/Kconfig
new file mode 100644
index 000000000000..19fdcf093fd1
--- /dev/null
+++ b/arch/arm/mach-realtek/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+menuconfig ARCH_REALTEK
+	bool "Realtek SoCs"
+	depends on ARCH_MULTI_V7
+	select ARM_GIC
+	select ARM_GLOBAL_TIMER
+	select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+	select GENERIC_IRQ_CHIP
+	select RESET_CONTROLLER
+	help
+	  This enables support for the Realtek RTD1195 SoC family.
diff --git a/arch/arm/mach-realtek/Makefile b/arch/arm/mach-realtek/Makefile
new file mode 100644
index 000000000000..5382d5bbdd3c
--- /dev/null
+++ b/arch/arm/mach-realtek/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+obj-y += rtd1195.o
diff --git a/arch/arm/mach-realtek/rtd1195.c b/arch/arm/mach-realtek/rtd1195.c
new file mode 100644
index 000000000000..b31a4066be87
--- /dev/null
+++ b/arch/arm/mach-realtek/rtd1195.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Realtek RTD1195
+ *
+ * Copyright (c) 2017-2019 Andreas Färber
+ */
+
+#include <linux/memblock.h>
+#include <asm/mach/arch.h>
+
+static void __init rtd1195_memblock_remove(phys_addr_t base, phys_addr_t size)
+{
+	int ret;
+
+	ret = memblock_remove(base, size);
+	if (ret)
+		pr_err("Failed to remove memblock %pa (%d)\n", &base, ret);
+}
+
+static void __init rtd1195_reserve(void)
+{
+	/* Exclude peripheral register spaces from RAM */
+	rtd1195_memblock_remove(0x18000000, 0x00070000);
+	rtd1195_memblock_remove(0x18100000, 0x01000000);
+}
+
+static const char *const rtd1195_dt_compat[] __initconst = {
+	"realtek,rtd1195",
+	NULL
+};
+
+DT_MACHINE_START(rtd1195, "Realtek RTD1195")
+	.dt_compat = rtd1195_dt_compat,
+	.reserve = rtd1195_reserve,
+	.l2c_aux_val = 0x0,
+	.l2c_aux_mask = ~0x0,
+MACHINE_END
-- 
2.16.4

[PATCH v3 3/8] ARM: dts: Prepare Realtek RTD1195 and MeLE X1000

[Andreas Färber]

Add Device Trees for Realtek RTD1195 SoC and MeLE X1000 TV box.

Reuse the existing RTD1295 watchdog compatible for now.

Reviewed-by: Rob Herring <robh@kernel.org>
[AF: Fixed r-bus size, fixed GIC CPU mask, updated memreserve]
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v2 -> v3:
 * Fixed r-bus size in /soc ranges from 0x1000000 to 0x70000 (James)
 * Adjusted /memreserve/ to close gap from 0xa800 to 0xc000 for full 0x100000
 * Changed arch timer from GIC_CPU_MASK_RAW(0xf) to GIC_CPU_MASK_SIMPLE(2)
   squashed from RTD1395 v1 series
 
 v1 -> v2:
 * Dropped /memreserve/ and reserved-memory nodes for peripherals and NOR (Rob)
 * Carved them out from memory reg instead (Rob)
 * Converted some /memreserve/s to reserved-memory nodes
 
 arch/arm/boot/dts/Makefile               |   2 +
 arch/arm/boot/dts/rtd1195-mele-x1000.dts |  31 ++++++++
 arch/arm/boot/dts/rtd1195.dtsi           | 127 +++++++++++++++++++++++++++++++
 3 files changed, 160 insertions(+)
 create mode 100644 arch/arm/boot/dts/rtd1195-mele-x1000.dts
 create mode 100644 arch/arm/boot/dts/rtd1195.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 08011dc8c7a6..4853a13c8cf2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -865,6 +865,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
 dtb-$(CONFIG_ARCH_RDA) += \
 	rda8810pl-orangepi-2g-iot.dtb \
 	rda8810pl-orangepi-i96.dtb
+dtb-$(CONFIG_ARCH_REALTEK) += \
+	rtd1195-mele-x1000.dtb
 dtb-$(CONFIG_ARCH_REALVIEW) += \
 	arm-realview-pb1176.dtb \
 	arm-realview-pb11mp.dtb \
diff --git a/arch/arm/boot/dts/rtd1195-mele-x1000.dts b/arch/arm/boot/dts/rtd1195-mele-x1000.dts
new file mode 100644
index 000000000000..834b430e6250
--- /dev/null
+++ b/arch/arm/boot/dts/rtd1195-mele-x1000.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Copyright (c) 2017-2019 Andreas Färber
+ */
+
+/dts-v1/;
+
+#include "rtd1195.dtsi"
+
+/ {
+	compatible = "mele,x1000", "realtek,rtd1195";
+	model = "MeLE X1000";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x18000000>,
+		      <0x19100000 0x26f00000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
new file mode 100644
index 000000000000..4e3866fe8f6e
--- /dev/null
+++ b/arch/arm/boot/dts/rtd1195.dtsi
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Copyright (c) 2017-2019 Andreas Färber
+ */
+
+/memreserve/ 0x00000000 0x0000a800; /* boot code */
+/memreserve/ 0x0000a800 0x000f5800;
+/memreserve/ 0x17fff000 0x00001000;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "realtek,rtd1195";
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x0>;
+			clock-frequency = <1000000000>;
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0x1>;
+			clock-frequency = <1000000000>;
+		};
+	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		rpc_comm: rpc@b000 {
+			reg = <0x0000b000 0x1000>;
+		};
+
+		audio@1b00000 {
+			reg = <0x01b00000 0x400000>;
+		};
+
+		rpc_ringbuf: rpc@1ffe000 {
+			reg = <0x01ffe000 0x4000>;
+		};
+
+		secure@10000000 {
+			reg = <0x10000000 0x100000>;
+			no-map;
+		};
+	};
+
+	arm-pmu {
+		compatible = "arm,cortex-a7-pmu";
+		interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+		clock-frequency = <27000000>;
+	};
+
+	osc27M: osc {
+		compatible = "fixed-clock";
+		clock-frequency = <27000000>;
+		#clock-cells = <0>;
+		clock-output-names = "osc27M";
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x18000000 0x18000000 0x00070000>,
+		         <0x18100000 0x18100000 0x01000000>,
+		         <0x40000000 0x40000000 0xc0000000>;
+
+		wdt: watchdog@18007680 {
+			compatible = "realtek,rtd1295-watchdog";
+			reg = <0x18007680 0x100>;
+			clocks = <&osc27M>;
+		};
+
+		uart0: serial@18007800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x18007800 0x400>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <27000000>;
+			status = "disabled";
+		};
+
+		uart1: serial@1801b200 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x1801b200 0x100>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clock-frequency = <27000000>;
+			status = "disabled";
+		};
+
+		gic: interrupt-controller@ff011000 {
+			compatible = "arm,cortex-a7-gic";
+			reg = <0xff011000 0x1000>,
+			      <0xff012000 0x2000>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+	};
+};
-- 
2.16.4

[PATCH v3 4/8] ARM: dts: rtd1195: Introduce r-bus

[Andreas Färber]

Model Realtek's register bus in DT.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v3: from RTD1395 v1
 * Fixed r-bus size from 0x100000 to 0x70000 in reg and ranges (James)
 * Renamed bus node from r-bus to bus (Rob)
 
 arch/arm/boot/dts/rtd1195.dtsi | 52 ++++++++++++++++++++++++------------------
 1 file changed, 30 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
index 4e3866fe8f6e..f5174f828a28 100644
--- a/arch/arm/boot/dts/rtd1195.dtsi
+++ b/arch/arm/boot/dts/rtd1195.dtsi
@@ -92,28 +92,36 @@
 		         <0x18100000 0x18100000 0x01000000>,
 		         <0x40000000 0x40000000 0xc0000000>;
 
-		wdt: watchdog@18007680 {
-			compatible = "realtek,rtd1295-watchdog";
-			reg = <0x18007680 0x100>;
-			clocks = <&osc27M>;
-		};
-
-		uart0: serial@18007800 {
-			compatible = "snps,dw-apb-uart";
-			reg = <0x18007800 0x400>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			clock-frequency = <27000000>;
-			status = "disabled";
-		};
-
-		uart1: serial@1801b200 {
-			compatible = "snps,dw-apb-uart";
-			reg = <0x1801b200 0x100>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			clock-frequency = <27000000>;
-			status = "disabled";
+		rbus: bus@18000000 {
+			compatible = "simple-bus";
+			reg = <0x18000000 0x70000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x18000000 0x70000>;
+
+			wdt: watchdog@7680 {
+				compatible = "realtek,rtd1295-watchdog";
+				reg = <0x7680 0x100>;
+				clocks = <&osc27M>;
+			};
+
+			uart0: serial@7800 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x7800 0x400>;
+				reg-shift = <2>;
+				reg-io-width = <4>;
+				clock-frequency = <27000000>;
+				status = "disabled";
+			};
+
+			uart1: serial@1b200 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x1b200 0x100>;
+				reg-shift = <2>;
+				reg-io-width = <4>;
+				clock-frequency = <27000000>;
+				status = "disabled";
+			};
 		};
 
 		gic: interrupt-controller@ff011000 {
-- 
2.16.4

[PATCH v3 5/8] dt-bindings: reset: Add Realtek RTD1195

[Andreas Färber]

Add a header with symbolic reset indices for Realtek RTD1195 SoC.
Naming was derived from BSP register description headers.

Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v3: Unchanged from RTD1295 reset v2
 
 include/dt-bindings/reset/realtek,rtd1195.h | 74 +++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 include/dt-bindings/reset/realtek,rtd1195.h

diff --git a/include/dt-bindings/reset/realtek,rtd1195.h b/include/dt-bindings/reset/realtek,rtd1195.h
new file mode 100644
index 000000000000..27902abf935b
--- /dev/null
+++ b/include/dt-bindings/reset/realtek,rtd1195.h
@@ -0,0 +1,74 @@
+/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */
+/*
+ * Realtek RTD1195 reset controllers
+ *
+ * Copyright (c) 2017 Andreas Färber
+ */
+#ifndef DT_BINDINGS_RESET_RTD1195_H
+#define DT_BINDINGS_RESET_RTD1195_H
+
+/* soft reset 1 */
+#define RTD1195_RSTN_MISC		0
+#define RTD1195_RSTN_RNG		1
+#define RTD1195_RSTN_USB3_POW		2
+#define RTD1195_RSTN_GSPI		3
+#define RTD1195_RSTN_USB3_P0_MDIO	4
+#define RTD1195_RSTN_VE_H265		5
+#define RTD1195_RSTN_USB		6
+#define RTD1195_RSTN_USB_PHY0		8
+#define RTD1195_RSTN_USB_PHY1		9
+#define RTD1195_RSTN_HDMIRX		11
+#define RTD1195_RSTN_HDMI		12
+#define RTD1195_RSTN_ETN		14
+#define RTD1195_RSTN_AIO		15
+#define RTD1195_RSTN_GPU		16
+#define RTD1195_RSTN_VE_H264		17
+#define RTD1195_RSTN_VE_JPEG		18
+#define RTD1195_RSTN_TVE		19
+#define RTD1195_RSTN_VO			20
+#define RTD1195_RSTN_LVDS		21
+#define RTD1195_RSTN_SE			22
+#define RTD1195_RSTN_DCU		23
+#define RTD1195_RSTN_DC_PHY		24
+#define RTD1195_RSTN_CP			25
+#define RTD1195_RSTN_MD			26
+#define RTD1195_RSTN_TP			27
+#define RTD1195_RSTN_AE			28
+#define RTD1195_RSTN_NF			29
+#define RTD1195_RSTN_MIPI		30
+
+/* soft reset 2 */
+#define RTD1195_RSTN_ACPU		0
+#define RTD1195_RSTN_VCPU		1
+#define RTD1195_RSTN_PCR		9
+#define RTD1195_RSTN_CR			10
+#define RTD1195_RSTN_EMMC		11
+#define RTD1195_RSTN_SDIO		12
+#define RTD1195_RSTN_I2C_5		18
+#define RTD1195_RSTN_RTC		20
+#define RTD1195_RSTN_I2C_4		23
+#define RTD1195_RSTN_I2C_3		24
+#define RTD1195_RSTN_I2C_2		25
+#define RTD1195_RSTN_I2C_1		26
+#define RTD1195_RSTN_UR1		28
+
+/* soft reset 3 */
+#define RTD1195_RSTN_SB2		0
+
+/* iso soft reset */
+#define RTD1195_ISO_RSTN_VFD		0
+#define RTD1195_ISO_RSTN_IR		1
+#define RTD1195_ISO_RSTN_CEC0		2
+#define RTD1195_ISO_RSTN_CEC1		3
+#define RTD1195_ISO_RSTN_DP		4
+#define RTD1195_ISO_RSTN_CBUSTX		5
+#define RTD1195_ISO_RSTN_CBUSRX		6
+#define RTD1195_ISO_RSTN_EFUSE		7
+#define RTD1195_ISO_RSTN_UR0		8
+#define RTD1195_ISO_RSTN_GMAC		9
+#define RTD1195_ISO_RSTN_GPHY		10
+#define RTD1195_ISO_RSTN_I2C_0		11
+#define RTD1195_ISO_RSTN_I2C_6		12
+#define RTD1195_ISO_RSTN_CBUS		13
+
+#endif
-- 
2.16.4

[PATCH v3 6/8] ARM: dts: rtd1195: Add reset nodes

[Andreas Färber]

Add reset controller nodes for Realtek RTD1195 SoC.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v3: from RTD1295 reset v2
 * Rebased onto r-bus - reg, unit address, indentation
 
 arch/arm/boot/dts/rtd1195.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
index f5174f828a28..e0f133a1354f 100644
--- a/arch/arm/boot/dts/rtd1195.dtsi
+++ b/arch/arm/boot/dts/rtd1195.dtsi
@@ -99,6 +99,30 @@
 			#size-cells = <1>;
 			ranges = <0x0 0x18000000 0x70000>;
 
+			reset1: reset-controller@0 {
+				compatible = "snps,dw-low-reset";
+				reg = <0x0 0x4>;
+				#reset-cells = <1>;
+			};
+
+			reset2: reset-controller@4 {
+				compatible = "snps,dw-low-reset";
+				reg = <0x4 0x4>;
+				#reset-cells = <1>;
+			};
+
+			reset3: reset-controller@8 {
+				compatible = "snps,dw-low-reset";
+				reg = <0x8 0x4>;
+				#reset-cells = <1>;
+			};
+
+			iso_reset: reset-controller@7088 {
+				compatible = "snps,dw-low-reset";
+				reg = <0x7088 0x4>;
+				#reset-cells = <1>;
+			};
+
 			wdt: watchdog@7680 {
 				compatible = "realtek,rtd1295-watchdog";
 				reg = <0x7680 0x100>;
-- 
2.16.4

[PATCH v3 7/8] ARM: dts: rtd1195: Add UART resets

[Andreas Färber]

Associate the UART nodes with the corresponding reset controller bits.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 v3: from RTD1295 reset v2
 * Rebased onto r-bus
 
 arch/arm/boot/dts/rtd1195.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
index e0f133a1354f..4eec45244132 100644
--- a/arch/arm/boot/dts/rtd1195.dtsi
+++ b/arch/arm/boot/dts/rtd1195.dtsi
@@ -8,6 +8,7 @@
 /memreserve/ 0x17fff000 0x00001000;
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset/realtek,rtd1195.h>
 
 / {
 	compatible = "realtek,rtd1195";
@@ -134,6 +135,7 @@
 				reg = <0x7800 0x400>;
 				reg-shift = <2>;
 				reg-io-width = <4>;
+				resets = <&iso_reset RTD1195_ISO_RSTN_UR0>;
 				clock-frequency = <27000000>;
 				status = "disabled";
 			};
@@ -143,6 +145,7 @@
 				reg = <0x1b200 0x100>;
 				reg-shift = <2>;
 				reg-io-width = <4>;
+				resets = <&reset2 RTD1195_RSTN_UR1>;
 				clock-frequency = <27000000>;
 				status = "disabled";
 			};
-- 
2.16.4

[PATCH v3 8/8] ARM: realtek: Enable RTD1195 arch timer

[Andreas Färber]

Without this magic write the timer doesn't work and boot gets stuck.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 What is the name of the register 0xff018000?
 Is 0x1 a BIT(0) write, or how are the register bits defined?
 Is this a reset or a clock gate? How should we model it in DT?
 
 v2 -> v3: Unchanged
 
 v2: New
 
 arch/arm/mach-realtek/rtd1195.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mach-realtek/rtd1195.c b/arch/arm/mach-realtek/rtd1195.c
index b31a4066be87..0532379c74f5 100644
--- a/arch/arm/mach-realtek/rtd1195.c
+++ b/arch/arm/mach-realtek/rtd1195.c
@@ -5,6 +5,9 @@
  * Copyright (c) 2017-2019 Andreas Färber
  */
 
+#include <linux/clk-provider.h>
+#include <linux/clocksource.h>
+#include <linux/io.h>
 #include <linux/memblock.h>
 #include <asm/mach/arch.h>
 
@@ -24,6 +27,18 @@ static void __init rtd1195_reserve(void)
 	rtd1195_memblock_remove(0x18100000, 0x01000000);
 }
 
+static void __init rtd1195_init_time(void)
+{
+	void __iomem *base;
+
+	base = ioremap(0xff018000, 4);
+	writel(0x1, base);
+	iounmap(base);
+
+	of_clk_init(NULL);
+	timer_probe();
+}
+
 static const char *const rtd1195_dt_compat[] __initconst = {
 	"realtek,rtd1195",
 	NULL
@@ -31,6 +46,7 @@ static const char *const rtd1195_dt_compat[] __initconst = {
 
 DT_MACHINE_START(rtd1195, "Realtek RTD1195")
 	.dt_compat = rtd1195_dt_compat,
+	.init_time = rtd1195_init_time,
 	.reserve = rtd1195_reserve,
 	.l2c_aux_val = 0x0,
 	.l2c_aux_mask = ~0x0,
-- 
2.16.4

Re: [PATCH v3 3/8] ARM: dts: Prepare Realtek RTD1195 and MeLE X1000

[Marc Zyngier]

On Sun, 17 Nov 2019 08:21:04 +0100
Andreas Färber <afaerber@suse.de> wrote:

Hi Andreas,

> Add Device Trees for Realtek RTD1195 SoC and MeLE X1000 TV box.
> 
> Reuse the existing RTD1295 watchdog compatible for now.
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> [AF: Fixed r-bus size, fixed GIC CPU mask, updated memreserve]
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
>  v2 -> v3:
>  * Fixed r-bus size in /soc ranges from 0x1000000 to 0x70000 (James)
>  * Adjusted /memreserve/ to close gap from 0xa800 to 0xc000 for full 0x100000
>  * Changed arch timer from GIC_CPU_MASK_RAW(0xf) to GIC_CPU_MASK_SIMPLE(2)
>    squashed from RTD1395 v1 series
>  
>  v1 -> v2:
>  * Dropped /memreserve/ and reserved-memory nodes for peripherals and NOR (Rob)
>  * Carved them out from memory reg instead (Rob)
>  * Converted some /memreserve/s to reserved-memory nodes
>  
>  arch/arm/boot/dts/Makefile               |   2 +
>  arch/arm/boot/dts/rtd1195-mele-x1000.dts |  31 ++++++++
>  arch/arm/boot/dts/rtd1195.dtsi           | 127 +++++++++++++++++++++++++++++++
>  3 files changed, 160 insertions(+)
>  create mode 100644 arch/arm/boot/dts/rtd1195-mele-x1000.dts
>  create mode 100644 arch/arm/boot/dts/rtd1195.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 08011dc8c7a6..4853a13c8cf2 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -865,6 +865,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>  dtb-$(CONFIG_ARCH_RDA) += \
>  	rda8810pl-orangepi-2g-iot.dtb \
>  	rda8810pl-orangepi-i96.dtb
> +dtb-$(CONFIG_ARCH_REALTEK) += \
> +	rtd1195-mele-x1000.dtb
>  dtb-$(CONFIG_ARCH_REALVIEW) += \
>  	arm-realview-pb1176.dtb \
>  	arm-realview-pb11mp.dtb \
> diff --git a/arch/arm/boot/dts/rtd1195-mele-x1000.dts b/arch/arm/boot/dts/rtd1195-mele-x1000.dts
> new file mode 100644
> index 000000000000..834b430e6250
> --- /dev/null
> +++ b/arch/arm/boot/dts/rtd1195-mele-x1000.dts
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> +/*
> + * Copyright (c) 2017-2019 Andreas Färber
> + */
> +
> +/dts-v1/;
> +
> +#include "rtd1195.dtsi"
> +
> +/ {
> +	compatible = "mele,x1000", "realtek,rtd1195";
> +	model = "MeLE X1000";
> +
> +	aliases {
> +		serial0 = &uart0;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	memory@0 {
> +		device_type = "memory";
> +		reg = <0x0 0x18000000>,
> +		      <0x19100000 0x26f00000>;
> +	};
> +};
> +
> +&uart0 {
> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
> new file mode 100644
> index 000000000000..4e3866fe8f6e
> --- /dev/null
> +++ b/arch/arm/boot/dts/rtd1195.dtsi
> @@ -0,0 +1,127 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
> +/*
> + * Copyright (c) 2017-2019 Andreas Färber
> + */
> +
> +/memreserve/ 0x00000000 0x0000a800; /* boot code */
> +/memreserve/ 0x0000a800 0x000f5800;
> +/memreserve/ 0x17fff000 0x00001000;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	compatible = "realtek,rtd1195";
> +	interrupt-parent = <&gic>;
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu0: cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a7";
> +			reg = <0x0>;
> +			clock-frequency = <1000000000>;
> +		};
> +
> +		cpu1: cpu@1 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a7";
> +			reg = <0x1>;
> +			clock-frequency = <1000000000>;
> +		};
> +	};
> +
> +	reserved-memory {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		rpc_comm: rpc@b000 {
> +			reg = <0x0000b000 0x1000>;
> +		};
> +
> +		audio@1b00000 {
> +			reg = <0x01b00000 0x400000>;
> +		};
> +
> +		rpc_ringbuf: rpc@1ffe000 {
> +			reg = <0x01ffe000 0x4000>;
> +		};
> +
> +		secure@10000000 {
> +			reg = <0x10000000 0x100000>;
> +			no-map;
> +		};
> +	};
> +
> +	arm-pmu {
> +		compatible = "arm,cortex-a7-pmu";
> +		interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-affinity = <&cpu0>, <&cpu1>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv7-timer";
> +		interrupts = <GIC_PPI 13
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> +			     <GIC_PPI 14
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> +			     <GIC_PPI 11
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> +			     <GIC_PPI 10
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
> +		clock-frequency = <27000000>;

This is 2019, and yet it feels like 2011. This should be setup in the
bootloader, not in DT...

> +	};
> +
> +	osc27M: osc {
> +		compatible = "fixed-clock";
> +		clock-frequency = <27000000>;
> +		#clock-cells = <0>;
> +		clock-output-names = "osc27M";
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges = <0x18000000 0x18000000 0x00070000>,
> +		         <0x18100000 0x18100000 0x01000000>,
> +		         <0x40000000 0x40000000 0xc0000000>;
> +
> +		wdt: watchdog@18007680 {
> +			compatible = "realtek,rtd1295-watchdog";
> +			reg = <0x18007680 0x100>;
> +			clocks = <&osc27M>;
> +		};
> +
> +		uart0: serial@18007800 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x18007800 0x400>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <27000000>;
> +			status = "disabled";
> +		};
> +
> +		uart1: serial@1801b200 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x1801b200 0x100>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clock-frequency = <27000000>;
> +			status = "disabled";
> +		};
> +
> +		gic: interrupt-controller@ff011000 {
> +			compatible = "arm,cortex-a7-gic";
> +			reg = <0xff011000 0x1000>,
> +			      <0xff012000 0x2000>;
> +			interrupt-controller;
> +			#interrupt-cells = <3>;

You know what I'm going to say: GICH and GIV are missing, as well as
the maintenance interrupt. This is all bog-standard HW (most probably a
GIC400), so there is no reason for this information not to be present.

	M.
-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v3 8/8] ARM: realtek: Enable RTD1195 arch timer

[Marc Zyngier]

On Sun, 17 Nov 2019 08:21:09 +0100
Andreas Färber <afaerber@suse.de> wrote:

> Without this magic write the timer doesn't work and boot gets stuck.
> 
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
>  What is the name of the register 0xff018000?
>  Is 0x1 a BIT(0) write, or how are the register bits defined?
>  Is this a reset or a clock gate? How should we model it in DT?
>  
>  v2 -> v3: Unchanged
>  
>  v2: New
>  
>  arch/arm/mach-realtek/rtd1195.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/arch/arm/mach-realtek/rtd1195.c b/arch/arm/mach-realtek/rtd1195.c
> index b31a4066be87..0532379c74f5 100644
> --- a/arch/arm/mach-realtek/rtd1195.c
> +++ b/arch/arm/mach-realtek/rtd1195.c
> @@ -5,6 +5,9 @@
>   * Copyright (c) 2017-2019 Andreas Färber
>   */
>  
> +#include <linux/clk-provider.h>
> +#include <linux/clocksource.h>
> +#include <linux/io.h>
>  #include <linux/memblock.h>
>  #include <asm/mach/arch.h>
>  
> @@ -24,6 +27,18 @@ static void __init rtd1195_reserve(void)
>  	rtd1195_memblock_remove(0x18100000, 0x01000000);
>  }
>  
> +static void __init rtd1195_init_time(void)
> +{
> +	void __iomem *base;
> +
> +	base = ioremap(0xff018000, 4);
> +	writel(0x1, base);
> +	iounmap(base);
> +
> +	of_clk_init(NULL);
> +	timer_probe();
> +}

Gawd... Why isn't this set from the bootloader? By the time the kernel
starts, everything should be up and running. What is it going to do
when you kexec? Shouldn't this be a read/modify/write sequence?

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v3 3/8] ARM: dts: Prepare Realtek RTD1195 and MeLE X1000

[Andreas Färber]

Hi Marc,

Am 17.11.19 um 11:47 schrieb Marc Zyngier:
> On Sun, 17 Nov 2019 08:21:04 +0100
> Andreas Färber <afaerber@suse.de> wrote:
>> Add Device Trees for Realtek RTD1195 SoC and MeLE X1000 TV box.
>>
>> Reuse the existing RTD1295 watchdog compatible for now.
>>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>> [AF: Fixed r-bus size, fixed GIC CPU mask, updated memreserve]
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>>  v2 -> v3:
>>  * Fixed r-bus size in /soc ranges from 0x1000000 to 0x70000 (James)
>>  * Adjusted /memreserve/ to close gap from 0xa800 to 0xc000 for full 0x100000
>>  * Changed arch timer from GIC_CPU_MASK_RAW(0xf) to GIC_CPU_MASK_SIMPLE(2)
>>    squashed from RTD1395 v1 series
>>  
>>  v1 -> v2:
>>  * Dropped /memreserve/ and reserved-memory nodes for peripherals and NOR (Rob)
>>  * Carved them out from memory reg instead (Rob)
>>  * Converted some /memreserve/s to reserved-memory nodes
>>  
>>  arch/arm/boot/dts/Makefile               |   2 +
>>  arch/arm/boot/dts/rtd1195-mele-x1000.dts |  31 ++++++++
>>  arch/arm/boot/dts/rtd1195.dtsi           | 127 +++++++++++++++++++++++++++++++
>>  3 files changed, 160 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/rtd1195-mele-x1000.dts
>>  create mode 100644 arch/arm/boot/dts/rtd1195.dtsi
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 08011dc8c7a6..4853a13c8cf2 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -865,6 +865,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>>  dtb-$(CONFIG_ARCH_RDA) += \
>>  	rda8810pl-orangepi-2g-iot.dtb \
>>  	rda8810pl-orangepi-i96.dtb
>> +dtb-$(CONFIG_ARCH_REALTEK) += \
>> +	rtd1195-mele-x1000.dtb
>>  dtb-$(CONFIG_ARCH_REALVIEW) += \
>>  	arm-realview-pb1176.dtb \
>>  	arm-realview-pb11mp.dtb \
>> diff --git a/arch/arm/boot/dts/rtd1195-mele-x1000.dts b/arch/arm/boot/dts/rtd1195-mele-x1000.dts
>> new file mode 100644
>> index 000000000000..834b430e6250
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/rtd1195-mele-x1000.dts
>> @@ -0,0 +1,31 @@
>> +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
>> +/*
>> + * Copyright (c) 2017-2019 Andreas Färber
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "rtd1195.dtsi"
>> +
>> +/ {
>> +	compatible = "mele,x1000", "realtek,rtd1195";
>> +	model = "MeLE X1000";
>> +
>> +	aliases {
>> +		serial0 = &uart0;
>> +	};
>> +
>> +	chosen {
>> +		stdout-path = "serial0:115200n8";
>> +	};
>> +
>> +	memory@0 {
>> +		device_type = "memory";
>> +		reg = <0x0 0x18000000>,
>> +		      <0x19100000 0x26f00000>;
>> +	};
>> +};
>> +
>> +&uart0 {
>> +	status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi
>> new file mode 100644
>> index 000000000000..4e3866fe8f6e
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/rtd1195.dtsi
>> @@ -0,0 +1,127 @@
>> +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
>> +/*
>> + * Copyright (c) 2017-2019 Andreas Färber
>> + */
>> +
>> +/memreserve/ 0x00000000 0x0000a800; /* boot code */
>> +/memreserve/ 0x0000a800 0x000f5800;
>> +/memreserve/ 0x17fff000 0x00001000;
>> +
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +
>> +/ {
>> +	compatible = "realtek,rtd1195";
>> +	interrupt-parent = <&gic>;
>> +	#address-cells = <1>;
>> +	#size-cells = <1>;
>> +
>> +	cpus {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		cpu0: cpu@0 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a7";
>> +			reg = <0x0>;
>> +			clock-frequency = <1000000000>;
>> +		};
>> +
>> +		cpu1: cpu@1 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a7";
>> +			reg = <0x1>;
>> +			clock-frequency = <1000000000>;
>> +		};
>> +	};
>> +
>> +	reserved-memory {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		rpc_comm: rpc@b000 {
>> +			reg = <0x0000b000 0x1000>;
>> +		};
>> +
>> +		audio@1b00000 {
>> +			reg = <0x01b00000 0x400000>;
>> +		};
>> +
>> +		rpc_ringbuf: rpc@1ffe000 {
>> +			reg = <0x01ffe000 0x4000>;
>> +		};
>> +
>> +		secure@10000000 {
>> +			reg = <0x10000000 0x100000>;
>> +			no-map;
>> +		};
>> +	};
>> +
>> +	arm-pmu {
>> +		compatible = "arm,cortex-a7-pmu";
>> +		interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
>> +			     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
>> +		interrupt-affinity = <&cpu0>, <&cpu1>;
>> +	};
>> +
>> +	timer {
>> +		compatible = "arm,armv7-timer";
>> +		interrupts = <GIC_PPI 13
>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>> +			     <GIC_PPI 14
>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>> +			     <GIC_PPI 11
>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>> +			     <GIC_PPI 10
>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
>> +		clock-frequency = <27000000>;
> 
> This is 2019, and yet it feels like 2011. This should be setup in the
> bootloader, not in DT...

What exactly - the whole node, the GIC CPU mask, the clock-frequency?

Please compare previous submissions: It's a v2012.07 based downstream
U-Boot that I don't have GPL sources of. It doesn't even fill in the
/memory@0 node.

>> +	};
>> +
>> +	osc27M: osc {
>> +		compatible = "fixed-clock";
>> +		clock-frequency = <27000000>;
>> +		#clock-cells = <0>;
>> +		clock-output-names = "osc27M";
>> +	};
>> +
>> +	soc {
>> +		compatible = "simple-bus";
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges = <0x18000000 0x18000000 0x00070000>,
>> +		         <0x18100000 0x18100000 0x01000000>,
>> +		         <0x40000000 0x40000000 0xc0000000>;
>> +
>> +		wdt: watchdog@18007680 {
>> +			compatible = "realtek,rtd1295-watchdog";
>> +			reg = <0x18007680 0x100>;
>> +			clocks = <&osc27M>;
>> +		};
>> +
>> +		uart0: serial@18007800 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x18007800 0x400>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clock-frequency = <27000000>;
>> +			status = "disabled";
>> +		};
>> +
>> +		uart1: serial@1801b200 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x1801b200 0x100>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clock-frequency = <27000000>;
>> +			status = "disabled";
>> +		};
>> +
>> +		gic: interrupt-controller@ff011000 {
>> +			compatible = "arm,cortex-a7-gic";
>> +			reg = <0xff011000 0x1000>,
>> +			      <0xff012000 0x2000>;
>> +			interrupt-controller;
>> +			#interrupt-cells = <3>;
> 
> You know what I'm going to say: GICH and GI[C]V are missing, as well as
> the maintenance interrupt. This is all bog-standard HW (most probably a
> GIC400), so there is no reason for this information not to be present.

Yes, and if you look at my rtd1295-next branch referenced in the cover
letter, you will find that I do have follow-up patches adding GICH and
GICV, also a guess for the GICV interrupt, and in a different patch [1]
I have specifically reminded Realtek to review the v2 of this patch
please, which still hasn't happened yet...

I inquired for the RTD1619 patch, and James replied that for its GICv3
they supposedly do _not_ have the optional GICH and GICV [1].

Thus I am waiting on their input for whether they have it on RTD1195.
The U-Boot that I have on this device does not boot the kernel in HYP
mode, so I cannot test KVM myself. Same issue on the Horseradish EVB.

On the Buffalo LinkStation LS520 I still don't have a serial console
(probably my bad soldering skills), but I doubt it's any different.

Regards,
Andreas

[1] https://patchwork.kernel.org/patch/11227113/

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

Re: [PATCH v3 3/8] ARM: dts: Prepare Realtek RTD1195 and MeLE X1000

[Marc Zyngier]

On Sun, 17 Nov 2019 15:40:59 +0000,
Andreas Färber <afaerber@suse.de> wrote:
> 
> Hi Marc,
> 
> Am 17.11.19 um 11:47 schrieb Marc Zyngier:
> > On Sun, 17 Nov 2019 08:21:04 +0100
> > Andreas Färber <afaerber@suse.de> wrote:
> >> Add Device Trees for Realtek RTD1195 SoC and MeLE X1000 TV box.
> >>
> >> Reuse the existing RTD1295 watchdog compatible for now.
> >>
> >> Reviewed-by: Rob Herring <robh@kernel.org>
> >> [AF: Fixed r-bus size, fixed GIC CPU mask, updated memreserve]
> >> Signed-off-by: Andreas Färber <afaerber@suse.de>
> >> ---
> >>  v2 -> v3:
> >>  * Fixed r-bus size in /soc ranges from 0x1000000 to 0x70000 (James)
> >>  * Adjusted /memreserve/ to close gap from 0xa800 to 0xc000 for full 0x100000
> >>  * Changed arch timer from GIC_CPU_MASK_RAW(0xf) to GIC_CPU_MASK_SIMPLE(2)
> >>    squashed from RTD1395 v1 series
> >>  
> >>  v1 -> v2:
> >>  * Dropped /memreserve/ and reserved-memory nodes for peripherals and NOR (Rob)
> >>  * Carved them out from memory reg instead (Rob)
> >>  * Converted some /memreserve/s to reserved-memory nodes
> >>  
> >>  arch/arm/boot/dts/Makefile               |   2 +
> >>  arch/arm/boot/dts/rtd1195-mele-x1000.dts |  31 ++++++++
> >>  arch/arm/boot/dts/rtd1195.dtsi           | 127 +++++++++++++++++++++++++++++++
> >>  3 files changed, 160 insertions(+)
> >>  create mode 100644 arch/arm/boot/dts/rtd1195-mele-x1000.dts
> >>  create mode 100644 arch/arm/boot/dts/rtd1195.dtsi

[...]

> >> +	timer {
> >> +		compatible = "arm,armv7-timer";
> >> +		interrupts = <GIC_PPI 13
> >> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> >> +			     <GIC_PPI 14
> >> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> >> +			     <GIC_PPI 11
> >> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
> >> +			     <GIC_PPI 10
> >> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
> >> +		clock-frequency = <27000000>;
> > 
> > This is 2019, and yet it feels like 2011. This should be setup in the
> > bootloader, not in DT...
> 
> What exactly - the whole node, the GIC CPU mask, the
> clock-frequency?

The clock frequency. Having to rely on such hacks 8 years down the
line makes me feel like we've achieved nothing...
</depressed>

> Please compare previous submissions: It's a v2012.07 based downstream
> U-Boot that I don't have GPL sources of. It doesn't even fill in the
> /memory@0 node.

Qualeetee...

> >> +		gic: interrupt-controller@ff011000 {
> >> +			compatible = "arm,cortex-a7-gic";
> >> +			reg = <0xff011000 0x1000>,
> >> +			      <0xff012000 0x2000>;
> >> +			interrupt-controller;
> >> +			#interrupt-cells = <3>;
> > 
> > You know what I'm going to say: GICH and GI[C]V are missing, as well as
> > the maintenance interrupt. This is all bog-standard HW (most probably a
> > GIC400), so there is no reason for this information not to be present.
> 
> Yes, and if you look at my rtd1295-next branch referenced in the cover
> letter, you will find that I do have follow-up patches adding GICH and
> GICV, also a guess for the GICV interrupt, and in a different patch [1]
> I have specifically reminded Realtek to review the v2 of this patch
> please, which still hasn't happened yet...
> 
> I inquired for the RTD1619 patch, and James replied that for its GICv3
> they supposedly do _not_ have the optional GICH and GICV [1].

Which is expected. Cortex-A55 doesn't have a GICv2 CPU interface
built-in, and thus doesn't not have the compatibility interface when
coupled with a GICv3 implementation.

In your case, Cortex A7 has all the required HW, and the required
values can be derived from the public TRM.

> Thus I am waiting on their input for whether they have it on RTD1195.
> The U-Boot that I have on this device does not boot the kernel in HYP
> mode, so I cannot test KVM myself. Same issue on the Horseradish
> EVB.

Given the vintage of the bootloader, I'm pretty sure he system boots
in secure mode, so it'd just be a matter of switching to non-secure.
Just use the existing bootloader as something that initialises memory
for you and boot a modern u-boot from there.

	M.

-- 
Jazz is not dead, it just smells funny.

Re: [PATCH v3 8/8] ARM: realtek: Enable RTD1195 arch timer

[Andreas Färber]

Am 17.11.19 um 12:02 schrieb Marc Zyngier:
> On Sun, 17 Nov 2019 08:21:09 +0100
> Andreas Färber <afaerber@suse.de> wrote:
> 
>> Without this magic write the timer doesn't work and boot gets stuck.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>>  What is the name of the register 0xff018000?
>>  Is 0x1 a BIT(0) write, or how are the register bits defined?
>>  Is this a reset or a clock gate? How should we model it in DT?

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>  
>>  v2 -> v3: Unchanged
>>  
>>  v2: New
>>  
>>  arch/arm/mach-realtek/rtd1195.c | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/mach-realtek/rtd1195.c b/arch/arm/mach-realtek/rtd1195.c
>> index b31a4066be87..0532379c74f5 100644
>> --- a/arch/arm/mach-realtek/rtd1195.c
>> +++ b/arch/arm/mach-realtek/rtd1195.c
>> @@ -5,6 +5,9 @@
>>   * Copyright (c) 2017-2019 Andreas Färber
>>   */
>>  
>> +#include <linux/clk-provider.h>
>> +#include <linux/clocksource.h>
>> +#include <linux/io.h>
>>  #include <linux/memblock.h>
>>  #include <asm/mach/arch.h>
>>  
>> @@ -24,6 +27,18 @@ static void __init rtd1195_reserve(void)
>>  	rtd1195_memblock_remove(0x18100000, 0x01000000);
>>  }
>>  
>> +static void __init rtd1195_init_time(void)
>> +{
>> +	void __iomem *base;
>> +
>> +	base = ioremap(0xff018000, 4);
>> +	writel(0x1, base);
>> +	iounmap(base);
>> +
>> +	of_clk_init(NULL);
>> +	timer_probe();
>> +}
> 
> Gawd... Why isn't this set from the bootloader? By the time the kernel
> starts, everything should be up and running. What is it going to do
> when you kexec? Shouldn't this be a read/modify/write sequence?

Again, I can't comment on why their BSP bootloaders don't do things the
expected way. The list of issues is long, and the newest U-Boot I've
seen for RTD1395 was v2015.07 based, still downstream and pre-EBBR.
And before we get a .dts merged into the kernel with all needed nodes
(network, eMMC, etc.), there is zero chance of a mainline U-Boot anyway.

v2 did not get any review from Realtek, so for this v3 I explicitly
spelled out my register questions above, in case the term "magic" was
not enough to prompt an actual explanation of what this is doing...

Only change that I can apply right now will be to turn this writel()
into a writel_relaxed(). Tested OK.

Original one-line BSP code:
https://github.com/BPI-SINOVOIP/BPI-M4-bsp/blob/master/linux-rtk/arch/arm/mach-rtd119x/rtd119x.c#L105

In my testing, all I can tell is that on both X1000 and Horseradish the
register value is 0x0 before above BSP-inspired write of 0x1.
So BIT(0) might be a clock gate enable or a reset deassert, or it might
be a larger field meaning something else.

For now, my small Busybox initrd is not capable of testing kexec, but I
don't foresee a problem here, given the observed register values.
(Unlike RTD1295, RTD1195 does not have native AHCI support for rootfs.)

Given the odd location of this register right after GICV rather than on
their r-bus, can you rule out that this is some standard Arm register?

Note that this patch is intentionally separate and last in this series,
precisely due to this expected contentious discussion. :) But as there
seems no realistic chance of anyone implementing a new U-Boot anytime
soon, we'll have to live with some such ugly solution to unblock boot.


Slightly related to this .init_time hook, I am facing an issue for SMP
where my ioremap() fails in .smp_init_cpus if I don't implement a
.map_io hook here, providing an old-style fixed mapping for r-bus. Later
ioremap()s in actual drivers in that same r-bus space do succeed.

And for the record, RTD1295 and RTD1395 still don't have SMP in mainline
either because they're not implementing it via PSCI; RTD1619 appears to
be the first to do that in BL31. No public BL31 code [1] that we might
fix, nor any public documentation on how we might experimentally replace
BL31 with one written from scratch, so I'm carrying non-upstreamable
patches (marked "HACK:") hacking up arm64 spin-table to use different
addresses and widths to bring them up. :/

Regards,
Andreas

[1] https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

Re: [PATCH v3 3/8] ARM: dts: Prepare Realtek RTD1195 and MeLE X1000

[Andreas Färber]

Am 17.11.19 um 17:22 schrieb Marc Zyngier:
> On Sun, 17 Nov 2019 15:40:59 +0000,
> Andreas Färber <afaerber@suse.de> wrote:
>> Am 17.11.19 um 11:47 schrieb Marc Zyngier:
>>> On Sun, 17 Nov 2019 08:21:04 +0100
>>> Andreas Färber <afaerber@suse.de> wrote:
>>>> +	timer {
>>>> +		compatible = "arm,armv7-timer";
>>>> +		interrupts = <GIC_PPI 13
>>>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>>>> +			     <GIC_PPI 14
>>>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>>>> +			     <GIC_PPI 11
>>>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>>>> +			     <GIC_PPI 10
>>>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
>>>> +		clock-frequency = <27000000>;
>>>
>>> This is 2019, and yet it feels like 2011. This should be setup in the
>>> bootloader, not in DT...
>>
>> What exactly - the whole node, the GIC CPU mask, the
>> clock-frequency?
> 
> The clock frequency. Having to rely on such hacks 8 years down the
> line makes me feel like we've achieved nothing...
> </depressed>

Unfortunately I can confirm that without clock-frequency property I get:

[    0.000000] arch_timer: frequency not available
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at kernel/time/clockevents.c:38
cev_delta2ns+0x148/0x170
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.4.0-rc7-next-20191115+ #213
[    0.000000] Hardware name: Realtek RTD1195
[    0.000000] [<c022f304>] (unwind_backtrace) from [<c022c0d0>]
(show_stack+0x10/0x14)
[    0.000000] [<c022c0d0>] (show_stack) from [<c09113e4>]
(dump_stack+0x84/0x98)
[    0.000000] [<c09113e4>] (dump_stack) from [<c023c928>]
(__warn+0xbc/0xd8)
[    0.000000] [<c023c928>] (__warn) from [<c023c9a8>]
(warn_slowpath_fmt+0x64/0xc4)
[    0.000000] [<c023c9a8>] (warn_slowpath_fmt) from [<c02ab910>]
(cev_delta2ns+0x148/0x170)
[    0.000000] [<c02ab910>] (cev_delta2ns) from [<c02abf60>]
(clockevents_config.part.0+0x54/0x74)
[    0.000000] [<c02abf60>] (clockevents_config.part.0) from
[<c02abfa0>] (clockevents_config_and_register+0x20/0x2c)
[    0.000000] [<c02abfa0>] (clockevents_config_and_register) from
[<c0789904>] (arch_timer_starting_cpu+0xcc/0x208)
[    0.000000] [<c0789904>] (arch_timer_starting_cpu) from [<c023d7dc>]
(cpuhp_issue_call+0x110/0x130)
[    0.000000] [<c023d7dc>] (cpuhp_issue_call) from [<c023d984>]
(__cpuhp_setup_state_cpuslocked+0x10c/0x2b4)
[    0.000000] [<c023d984>] (__cpuhp_setup_state_cpuslocked) from
[<c023e180>] (__cpuhp_setup_state+0x98/0x14c)
[    0.000000] [<c023e180>] (__cpuhp_setup_state) from [<c0e1f224>]
(arch_timer_of_init+0x2a8/0x34c)
[    0.000000] [<c0e1f224>] (arch_timer_of_init) from [<c0e1ecb4>]
(timer_probe+0x74/0xec)
[    0.000000] [<c0e1ecb4>] (timer_probe) from [<c0e00c74>]
(start_kernel+0x310/0x488)
[    0.000000] [<c0e00c74>] (start_kernel) from [<00000000>] (0x0)
[    0.000000] ---[ end trace c2db367029c1ec1a ]---
[    0.000000] arch_timer: cp15 timer(s) running at 0.00MHz (virt).
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
 5.4.0-rc7-next-20191115+ #213
[    0.000000] Hardware name: Realtek RTD1195
[    0.000000] [<c022f304>] (unwind_backtrace) from [<c022c0d0>]
(show_stack+0x10/0x14)
[    0.000000] [<c022c0d0>] (show_stack) from [<c09113e4>]
(dump_stack+0x84/0x98)
[    0.000000] [<c09113e4>] (dump_stack) from [<c090eb2c>]
(Ldiv0_64+0x8/0x18)
[    0.000000] [<c090eb2c>] (Ldiv0_64) from [<c02a43dc>]
(clocks_calc_max_nsecs+0x24/0x80)
[    0.000000] [<c02a43dc>] (clocks_calc_max_nsecs) from [<c02a4568>]
(__clocksource_update_freq_scale+0x130/0x1ec)
[    0.000000] [<c02a4568>] (__clocksource_update_freq_scale) from
[<c02a4638>] (__clocksource_register_scale+0x14/0xc0)
[    0.000000] [<c02a4638>] (__clocksource_register_scale) from
[<c0e1ef30>] (arch_timer_common_init+0x198/0x1e4)
[    0.000000] [<c0e1ef30>] (arch_timer_common_init) from [<c0e1ecb4>]
(timer_probe+0x74/0xec)
[    0.000000] [<c0e1ecb4>] (timer_probe) from [<c0e00c74>]
(start_kernel+0x310/0x488)
[    0.000000] [<c0e00c74>] (start_kernel) from [<00000000>] (0x0)
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
max_cycles: 0x0, max_idle_ns: 0 ns
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
 5.4.0-rc7-next-20191115+ #213
[    0.000000] Hardware name: Realtek RTD1195
[    0.000000] [<c022f304>] (unwind_backtrace) from [<c022c0d0>]
(show_stack+0x10/0x14)
[    0.000000] [<c022c0d0>] (show_stack) from [<c09113e4>]
(dump_stack+0x84/0x98)
[    0.000000] [<c09113e4>] (dump_stack) from [<c090eb2c>]
(Ldiv0_64+0x8/0x18)
[    0.000000] [<c090eb2c>] (Ldiv0_64) from [<c02a418c>]
(clocks_calc_mult_shift+0xec/0x10c)
[    0.000000] [<c02a418c>] (clocks_calc_mult_shift) from [<c0e0bb74>]
(sched_clock_register+0x80/0x278)
[    0.000000] [<c0e0bb74>] (sched_clock_register) from [<c0e1ef68>]
(arch_timer_common_init+0x1d0/0x1e4)
[    0.000000] [<c0e1ef68>] (arch_timer_common_init) from [<c0e1ecb4>]
(timer_probe+0x74/0xec)
[    0.000000] [<c0e1ecb4>] (timer_probe) from [<c0e00c74>]
(start_kernel+0x310/0x488)
[    0.000000] [<c0e00c74>] (start_kernel) from [<00000000>] (0x0)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
 5.4.0-rc7-next-20191115+ #213
[    0.000000] Hardware name: Realtek RTD1195
[    0.000000] [<c022f304>] (unwind_backtrace) from [<c022c0d0>]
(show_stack+0x10/0x14)
[    0.000000] [<c022c0d0>] (show_stack) from [<c09113e4>]
(dump_stack+0x84/0x98)
[    0.000000] [<c09113e4>] (dump_stack) from [<c090eb2c>]
(Ldiv0_64+0x8/0x18)
[    0.000000] [<c090eb2c>] (Ldiv0_64) from [<c02a43dc>]
(clocks_calc_max_nsecs+0x24/0x80)
[    0.000000] [<c02a43dc>] (clocks_calc_max_nsecs) from [<c0e0bbb0>]
(sched_clock_register+0xbc/0x278)
[    0.000000] [<c0e0bbb0>] (sched_clock_register) from [<c0e1ef68>]
(arch_timer_common_init+0x1d0/0x1e4)
[    0.000000] [<c0e1ef68>] (arch_timer_common_init) from [<c0e1ecb4>]
(timer_probe+0x74/0xec)
[    0.000000] [<c0e1ecb4>] (timer_probe) from [<c0e00c74>]
(start_kernel+0x310/0x488)
[    0.000000] [<c0e00c74>] (start_kernel) from [<00000000>] (0x0)
[    0.000000] sched_clock: 56 bits at 0 Hz, resolution 0ns, wraps every 0ns
[    0.000000] Failed to initialize '/timer': -6
[    0.000000] timer_probe: no matching timers found

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

Re: [PATCH v3 3/8] ARM: dts: Prepare Realtek RTD1195 and MeLE X1000

[Marc Zyngier]

On 2019-11-18 01:24, Andreas Färber wrote:
> Am 17.11.19 um 17:22 schrieb Marc Zyngier:
>> On Sun, 17 Nov 2019 15:40:59 +0000,
>> Andreas Färber <afaerber@suse.de> wrote:
>>> Am 17.11.19 um 11:47 schrieb Marc Zyngier:
>>>> On Sun, 17 Nov 2019 08:21:04 +0100
>>>> Andreas Färber <afaerber@suse.de> wrote:
>>>>> +	timer {
>>>>> +		compatible = "arm,armv7-timer";
>>>>> +		interrupts = <GIC_PPI 13
>>>>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>>>>> +			     <GIC_PPI 14
>>>>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>>>>> +			     <GIC_PPI 11
>>>>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
>>>>> +			     <GIC_PPI 10
>>>>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
>>>>> +		clock-frequency = <27000000>;
>>>>
>>>> This is 2019, and yet it feels like 2011. This should be setup in 
>>>> the
>>>> bootloader, not in DT...
>>>
>>> What exactly - the whole node, the GIC CPU mask, the
>>> clock-frequency?
>>
>> The clock frequency. Having to rely on such hacks 8 years down the
>> line makes me feel like we've achieved nothing...
>> </depressed>
>
> Unfortunately I can confirm that without clock-frequency property I 
> get:

[trace showing how bad firmware can be]

I don't dispute that you need this for your broken bootloader.

But instead of adding hacks upon hacks to the kernel to support
subpar implementations, maybe you should consider putting efforts
in a u-boot port that doesn't suck.

         M.
-- 
Jazz is not dead. It just smells funny...

RE: [PATCH v3 6/8] ARM: dts: rtd1195: Add reset nodes

[James Tai]

Hi Andreas,

> +			reset1: reset-controller@0 {
> +				compatible = "snps,dw-low-reset";
> +				reg = <0x0 0x4>;
> +				#reset-cells = <1>;
> +			};
> +
> +			reset2: reset-controller@4 {
> +				compatible = "snps,dw-low-reset";
> +				reg = <0x4 0x4>;
> +				#reset-cells = <1>;
> +			};
> +
> +			reset3: reset-controller@8 {
> +				compatible = "snps,dw-low-reset";
> +				reg = <0x8 0x4>;
> +				#reset-cells = <1>;
> +			};
> +
> +			iso_reset: reset-controller@7088 {
> +				compatible = "snps,dw-low-reset";
> +				reg = <0x7088 0x4>;
> +				#reset-cells = <1>;
> +			};
> +

We don't use the DesignWare IP for the reset controller.


Regards,
James

Re: [PATCH v3 8/8] ARM: realtek: Enable RTD1195 arch timer

[Marc Zyngier]

On 2019-11-17 17:08, Andreas Färber wrote:
> Am 17.11.19 um 12:02 schrieb Marc Zyngier:
>> On Sun, 17 Nov 2019 08:21:09 +0100
>> Andreas Färber <afaerber@suse.de> wrote:
>>
>>> Without this magic write the timer doesn't work and boot gets 
>>> stuck.
>>>
>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>> ---
>>>  What is the name of the register 0xff018000?
>>>  Is 0x1 a BIT(0) write, or how are the register bits defined?
>>>  Is this a reset or a clock gate? How should we model it in DT?
>
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Sorry? Do you expect me to come up with answer to these questions?

>>>
>>>  v2 -> v3: Unchanged
>>>
>>>  v2: New
>>>
>>>  arch/arm/mach-realtek/rtd1195.c | 16 ++++++++++++++++
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-realtek/rtd1195.c 
>>> b/arch/arm/mach-realtek/rtd1195.c
>>> index b31a4066be87..0532379c74f5 100644
>>> --- a/arch/arm/mach-realtek/rtd1195.c
>>> +++ b/arch/arm/mach-realtek/rtd1195.c
>>> @@ -5,6 +5,9 @@
>>>   * Copyright (c) 2017-2019 Andreas Färber
>>>   */
>>>
>>> +#include <linux/clk-provider.h>
>>> +#include <linux/clocksource.h>
>>> +#include <linux/io.h>
>>>  #include <linux/memblock.h>
>>>  #include <asm/mach/arch.h>
>>>
>>> @@ -24,6 +27,18 @@ static void __init rtd1195_reserve(void)
>>>  	rtd1195_memblock_remove(0x18100000, 0x01000000);
>>>  }
>>>
>>> +static void __init rtd1195_init_time(void)
>>> +{
>>> +	void __iomem *base;
>>> +
>>> +	base = ioremap(0xff018000, 4);
>>> +	writel(0x1, base);
>>> +	iounmap(base);
>>> +
>>> +	of_clk_init(NULL);
>>> +	timer_probe();
>>> +}
>>
>> Gawd... Why isn't this set from the bootloader? By the time the 
>> kernel
>> starts, everything should be up and running. What is it going to do
>> when you kexec? Shouldn't this be a read/modify/write sequence?
>
> Again, I can't comment on why their BSP bootloaders don't do things 
> the
> expected way. The list of issues is long, and the newest U-Boot I've
> seen for RTD1395 was v2015.07 based, still downstream and pre-EBBR.
> And before we get a .dts merged into the kernel with all needed nodes
> (network, eMMC, etc.), there is zero chance of a mainline U-Boot 
> anyway.

[...]

I certainly dispute that. If you're able to support all of this in the
kernel, you're most probably able to do it in u-boot, and that's the 
right
place to do it (and that can be a pretty simple u-boot if you use the
original one as a first-stage loader).

I'm not trying to undermine your effort in supporting these platforms
in mainline. This is certainly commendable. But you're unfortunately
pushing in a direction that we've tried hard to move away from for
a good 8 years.

Look at what we did on the Allwinner front: we got a terrible piece of
crap, and turned it into one of the best supported platform, because
we've put the effort where it mattered. I personally wrote PSCI support
and HYP enablement in u-boot, addressing in one go most of the issues 
you
mention here. It didn't take that much time, and it is now there for 
you
to make use of.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v3 8/8] ARM: realtek: Enable RTD1195 arch timer

[Andreas Färber]

Hi Marc,

Am 18.11.19 um 10:27 schrieb Marc Zyngier:
> On 2019-11-17 17:08, Andreas Färber wrote:
>> Am 17.11.19 um 12:02 schrieb Marc Zyngier:
>>> On Sun, 17 Nov 2019 08:21:09 +0100
>>> Andreas Färber <afaerber@suse.de> wrote:
>>>
>>>> Without this magic write the timer doesn't work and boot gets stuck.
>>>>
>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>> ---
>>>>  What is the name of the register 0xff018000?
>>>>  Is 0x1 a BIT(0) write, or how are the register bits defined?
>>>>  Is this a reset or a clock gate? How should we model it in DT?
>>
>>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Sorry? Do you expect me to come up with answer to these questions?

No, I was pointing out that I myself had already asked pretty much the
same questions you just asked me. How did you expect me to have answers
to your "Shouldn't this be a read/modify/write sequence?" then? It
seemed like you missed my questions up there:

Without knowing how the register is structured, I can't implement a
read/modify/write sequence - for that we'd need to know whether it's a
single bit we can just set or a field that we would need to mask first
before writing into it.

And ideally we would be getting its address from DT, so we would need to
know whether it's just this one register or some contiguous IP block
such as "arm,armv7-timer-mem". Same issue whether we implement it in the
kernel or in U-Boot btw. If it's no standard Arm register, we'll need to
have a binding with a sensible compatible string, some REG_ constant to
replace the magic offset number and some meaningful constant for 0x1.

>>>> diff --git a/arch/arm/mach-realtek/rtd1195.c
>>>> b/arch/arm/mach-realtek/rtd1195.c
>>>> index b31a4066be87..0532379c74f5 100644
>>>> --- a/arch/arm/mach-realtek/rtd1195.c
>>>> +++ b/arch/arm/mach-realtek/rtd1195.c
[...]
>>>> @@ -24,6 +27,18 @@ static void __init rtd1195_reserve(void)
>>>>      rtd1195_memblock_remove(0x18100000, 0x01000000);
>>>>  }
>>>>
>>>> +static void __init rtd1195_init_time(void)
>>>> +{
>>>> +    void __iomem *base;
>>>> +
>>>> +    base = ioremap(0xff018000, 4);
>>>> +    writel(0x1, base);
>>>> +    iounmap(base);
>>>> +
>>>> +    of_clk_init(NULL);
>>>> +    timer_probe();
>>>> +}
>>>
>>> Gawd... Why isn't this set from the bootloader? By the time the kernel
>>> starts, everything should be up and running. What is it going to do
>>> when you kexec? Shouldn't this be a read/modify/write sequence?
>>
>> Again, I can't comment on why their BSP bootloaders don't do things the
>> expected way. The list of issues is long, and the newest U-Boot I've
>> seen for RTD1395 was v2015.07 based, still downstream and pre-EBBR.
>> And before we get a .dts merged into the kernel with all needed nodes
>> (network, eMMC, etc.), there is zero chance of a mainline U-Boot anyway.
> 
> [...]
> 
> I certainly dispute that. 

Dispute that with U-Boot maintainers then, please, and let me know the
outcome. I just had an argument with Neil that it's not okay to import
from linux-next.git and that it must be an -rc1 or other stable tag. (My
VIM3 patch submission before Plumbers was not accepted for that reason,
and I haven't found time for U-Boot since.)

> If you're able to support all of this in the
> kernel,

No, I'm not, that was my point! :( We do _not_ have all those drivers
needed for a useful U-Boot implemented for the mainline kernel yet. Like
I said, I'm using a Busybox initrd for testing RTD1195 (also RTD1293,
RTD1296 and RTD1395). And I've already amassed 140+ patches on top of
-next without those core drivers - I really need to get that queue down
for sensible collaboration with Realtek and others.

I need people to be able to help contribute those drivers to the kernel,
therefore I need to get the basics merged, so that Realtek and community
members can base patches on top, so that we get there over time.
If you're asking that someone do a new U-Boot before we can even get a
timer or GIC DT node merged, then we're doomed and I'm wasting my time
here. Rob did give a Reviewed-by for the DT, so I would've thought it
can't be that terrible!

As I pointed out above, we need to get the .dts[i] into some -rc1 kernel
release for U-Boot to pull them. If you're blocking to merge RTD1195
into v5.6-rc1 here, we're not gonna get even a driver-less mainline
U-Boot for it in about 8 weeks. Chicken-and-egg problem.

And my experience with U-Boot has been that if U-Boot patches don't get
merged immediately, other people will duplicate that work later without
crediting me, so that my time spent on U-Boot would be wasted. And the
same is happening with the kernel if we don't get my patches merged in
some form - you already witnessed Aleix doing his own irqchip driver
instead of collaborating on the one that went through three rounds of
review already (and now he's disappeared again without input for me, so
I'm preparing to send you a v4 tonight or tomorrow). STM32 was another
bad experience (and I still have two further v7-M ports to clean up).

With the GeekBox, that I'm the official U-Boot maintainer of, I managed
to shoot myself in the foot, unable to recover from a U-Boot I flashed.
So I am very hesitant to repeat that, especially with RTD1195 hardware
that's no longer sold (X1000).

> you're most probably able to do it in u-boot, and that's the right
> place to do it (and that can be a pretty simple u-boot if you use the
> original one as a first-stage loader).
> 
> I'm not trying to undermine your effort in supporting these platforms
> in mainline. This is certainly commendable. But you're unfortunately
> pushing in a direction that we've tried hard to move away from for
> a good 8 years.
> 
> Look at what we did on the Allwinner front: we got a terrible piece of
> crap, and turned it into one of the best supported platform, because
> we've put the effort where it mattered. I personally wrote PSCI support
> and HYP enablement in u-boot, addressing in one go most of the issues you
> mention here. It didn't take that much time, and it is now there for you
> to make use of.

And the work of the sunXi community - including Bootlin and Arm people -
is commendable and inspiring (e.g., meson-tools).

My time as single person is limited for this night-time project though,
so it's unrealistic to ask me to reverse-engineer a new BL31 without
sources, write a U-Boot implementation and port the kernel, all at once.
Especially when I don't know how to even test those other components.
Maybe that's clear to you - for me it isn't. The RTD1395, where I do
have U-Boot sources for BPi-M4 [2] and get it loaded as file from SD by
a previous bootloader, is not affected by this RTD1195 timer problem;
yet I don't see how from any given U-Boot (or LK) I would be able to
load a new BL31 on RTD1295/RTD1395, nor how to load a HYP capable U-Boot
on RTD1195. I thought it's impossible to escape to higher ELs? And for
ARMv7 I thought U-Boot was neither relocatable not reentrant?

Now, I can continue carrying this commit in my GitHub tree for myself,
like I do for spin-table, if Olof and Arnd agree with you that this 8/8
should not be merged, even if we clarify this register. But I just don't
see the time right now for doing alone what the sunxi community have
achieved together over the course of many years, with Realtek in my neck
for new kernel patches.

The context here is that most of the drivers seen on RTD1295 and later
originated in RTD1195, so for sane compatible strings (cf. watchdog [3],
rtc [4] discussions!) we need to be able to test RTD1195 and to base
patches, such as upcoming irqchip mux v4, on all four+ SoC families.
Realtek appears to be focused on the new RTD1619/RTD1319, and I would
really like to avoid merging drivers for those new chips only and caring
about bindings and compatibility with the three earlier SoC families as
afterthought, repeating the mistakes I made with RTD1295 vs. RTD1195 for
lack of hardware at the time.

I don't think that I'm pushing into a wrong direction; we just disagree
about the steps to get there. I would like people to be able to take a
mainline kernel and boot on RTD1195 without getting stuck; if they have
to use a GitHub tree to successfully boot, then it's not really mainline
yet. Booting with only one CPU up is much less severe by comparison, as
it allows to probe all drivers and to explore sysfs and debugfs.

Keep in mind that I started RTD1295 mainlining without having any BSP
sources at all, which is less than the sunxi folks had to go on.

The key on sunxi, I thought, was that you had the FEL tools to just load
bootloader binaries dynamically over USB. For Amlogic we at least had
binary blobs and binary tools integrated into U-Boot build process and
an idea where to place them on SD to boot them - here I have only what
is on eMMC/SPI, no docs. Also, I do recall a long time where sunxi had
GitHub repos with downstream BSP forks - I'd rather not get into that
business and immediately skip to making mainline more and more usable.

If of course Realtek or one of their OEMs or some other community member
wanted to work on providing a rebased U-Boot in a Git repo, that would
be great. Once we have it working, we could drop workarounds like these.

A quick git-grep finds 277 occurrences of .init_time in arch/arm/mach-*,
so hardly a callback about to get dropped.

Regards,
Andreas

[1] https://github.com/BPI-SINOVOIP/BPI-W2-bsp/tree/master/u-boot-rtk
[2] https://github.com/BPI-SINOVOIP/BPI-M4-bsp/tree/master/u-boot-rtk
[3] https://patchwork.kernel.org/patch/11200563/
[4] https://patchwork.kernel.org/patch/11200561/

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

Re: [PATCH v3 6/8] ARM: dts: rtd1195: Add reset nodes

[Andreas Färber]

Hi James,

Adding Philipp.

Am 18.11.19 um 10:22 schrieb James Tai:
>> +			reset1: reset-controller@0 {
>> +				compatible = "snps,dw-low-reset";
>> +				reg = <0x0 0x4>;
>> +				#reset-cells = <1>;
>> +			};
>> +
>> +			reset2: reset-controller@4 {
>> +				compatible = "snps,dw-low-reset";
>> +				reg = <0x4 0x4>;
>> +				#reset-cells = <1>;
>> +			};
>> +
>> +			reset3: reset-controller@8 {
>> +				compatible = "snps,dw-low-reset";
>> +				reg = <0x8 0x4>;
>> +				#reset-cells = <1>;
>> +			};
>> +
>> +			iso_reset: reset-controller@7088 {
>> +				compatible = "snps,dw-low-reset";
>> +				reg = <0x7088 0x4>;
>> +				#reset-cells = <1>;
>> +			};
>> +
> 
> We don't use the DesignWare IP for the reset controller.

Thanks for reviewing.

We already merged the equivalent nodes for RTD129x into arm-soc.git.
No Realtek review was received back when it was posted [1], sadly.

How does your reset controller differ from DesignWare, and how would you
prefer to handle it?

a) Do you want to send patches for a new Realtek-specific dt-binding [2]
and extend reset-simple driver to cover it as a copy&paste of the
DesignWare of_device_id?

b) Do you believe you need to submit a completely new reset driver?

An issue I had raised twice [4, 1] was that reset-simple only allows for
contiguous registers and thus couldn't handle the gap between reset3 and
reset4 on RTD1295, forcing me to use per-register nodes for consistency.
I am against modeling RTD1195 differently from RTD1295+, assuming
they're the equivalent IP, so we need a solution that works for both.
Philipp did indicate in [4] we could extend reset-simple for this gap
"if the implementation could be kept reasonably simple".

With v5.4-rc8 already tagged, please hurry if you want a different
binding in v5.5.

Regards,
Andreas

[1] https://patchwork.kernel.org/cover/11206255/
[2] https://patchwork.kernel.org/patch/9902665/
[3] https://patchwork.kernel.org/patch/9902673/
[4] https://patchwork.kernel.org/patch/9902675/
[5] https://patchwork.kernel.org/patch/9902671/
[6] https://patchwork.kernel.org/patch/9902663/

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

RE: [PATCH v3 6/8] ARM: dts: rtd1195: Add reset nodes

[James Tai]

Hi Andreas,

> >
> > We don't use the DesignWare IP for the reset controller.
> 
> Thanks for reviewing.
> 
> We already merged the equivalent nodes for RTD129x into arm-soc.git.
> No Realtek review was received back when it was posted [1], sadly.
> 
> How does your reset controller differ from DesignWare, and how would you
> prefer to handle it?
> 
> a) Do you want to send patches for a new Realtek-specific dt-binding [2] and
> extend reset-simple driver to cover it as a copy&paste of the DesignWare
> of_device_id?
> 
> b) Do you believe you need to submit a completely new reset driver?
> 

The RTD1195, RTD1295 and RTD1395 reset controller is compatible with the reset-simple driver.
I want to use plan a) for them.

Besides, I'll submit a completely new reset driver for the RTD1619 
because the reset controller not compatible with the reset-simple driver.

Regards,
James

RE: [PATCH v3 8/8] ARM: realtek: Enable RTD1195 arch timer

[James Tai [戴志峰]]

Hi Andreas,

> >>>>  What is the name of the register 0xff018000?
> >>>>  Is 0x1 a BIT(0) write, or how are the register bits defined?
> >>>>  Is this a reset or a clock gate? How should we model it in DT?
> 
> No, I was pointing out that I myself had already asked pretty much the same
> questions you just asked me. How did you expect me to have answers to your
> "Shouldn't this be a read/modify/write sequence?" then? It seemed like you
> missed my questions up there:
> 
> Without knowing how the register is structured, I can't implement a
> read/modify/write sequence - for that we'd need to know whether it's a single
> bit we can just set or a field that we would need to mask first before writing
> into it.

This register is counter control register of CoreSight timestamp generator. [1][2].
The CPU timer count input signal is inherited from the timestamp generator, so it must be enabled before CPU timer initial.

This register setting can move into boot code.

[1] https://developer.arm.com/docs/100806/0200/9-programmers-model/css600_tsgen/control-interface-register-descriptions
[2] https://developer.arm.com/docs/100806/0200/5-timestamp-components-functional-description/timestamp-generator


Thanks.

Regards,
James