[PATCH v3 0/3] arm64: Add Renesas R8A7796 SoC support

[PATCH v3 0/3] arm64: Add Renesas R8A7796 SoC support

[Simon Horman]

Hi,

this short series aims to add basic support for the
Gen 3 R-Car M3-W (r8a7796) SoC.

It has few bells and whistles but is sufficient to bring up
an r8a7795/salvator-x. I have provided a boot-log at the bottom
of this email in case it is of interest.


Dependency:

"[PATCH 0/4] clk: renesas: cpg-mssr: Add support for R-Car M3-W"


Availability:

In order to aid review this series, its dependency (above)
and the related patch "serial: sh-sci: Document SoC specific bindings for
r8a7796", which has been posted separately, are available at:

git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/r8a7796-v3

To be entirely clear, at the time of writing I have _not_ queued up this
series for mainline.


Changes between v2 and v3:
* Drop 0x from unit address of gic
* Use arm,psci-0.2
* Accumulate Reviewed-by tag

Changes between v1 and v2:
* Move L2_CA57 node under cpus node and include reg property
* Omit status = "disabled" from scif_clk node
* Accumulate Ack and Reviewed-by tags


Simon Horman (1):
  arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

Takeshi Kihara (2):
  arm64: dts: salvator-x: add Salvator-X board on R8A7796 SoC
  arm64: defconfig: enable Renesas R8A7796 SoC

 Documentation/devicetree/bindings/arm/shmobile.txt |   4 +
 arch/arm64/Kconfig.platforms                       |   6 ++
 arch/arm64/boot/dts/renesas/Makefile               |   1 +
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts |  45 ++++++++
 arch/arm64/boot/dts/renesas/r8a7796.dtsi           | 120 +++++++++++++++++++++
 arch/arm64/configs/defconfig                       |   1 +
 6 files changed, 177 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
 create mode 100644 arch/arm64/boot/dts/renesas/r8a7796.dtsi


Boot Log:

The following boot log was generated by booting this patch set,
in its form in the topic/r8a7796 branch. It was compiled using
the ARM64 defconfig with initrd enabled to provide a working userspace.


[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.6.0-rc1+ (horms at ayumi.isobedori.kobe.vergenet.net) (gcc version 4.8.5 (Linaro GCC 4.8-2015.06) ) #98 SMP PREEMPT Tue May 24 10:47:31 JST 2016
[    0.000000] Boot CPU: AArch64 Processor [411fd073]
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 16 MiB at 0x00000000bf000000
[    0.000000] On node 0 totalpages: 1015808
[    0.000000]   DMA zone: 7680 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 491520 pages, LIFO batch:31
[    0.000000]   Normal zone: 8192 pages used for memmap
[    0.000000]   Normal zone: 524288 pages, LIFO batch:31
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] percpu: Embedded 20 pages/cpu @ffffffc63ffad000 s43008 r8192 d30720 u81920
[    0.000000] pcpu-alloc: s43008 r8192 d30720 u81920 alloc=20*4096
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] Detected PIPT I-cache on CPU0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 999936
[    0.000000] Kernel command line: ignore_loglevel rw root=/dev/nfs ip=dhcp nfsroot=10.3.3.135:/srv/nfs/salvator-x-arm64
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.000000] software IO TLB [mem 0xbafff000-0xbefff000] (64MB) mapped at [ffffffc07afff000-ffffffc07effefff]
[    0.000000] Memory: 3896020K/4063232K available (6796K kernel code, 619K rwdata, 2880K rodata, 2256K init, 241K bss, 150828K reserved, 16384K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     modules : 0xffffff8000000000 - 0xffffff8008000000   (   128 MB)
[    0.000000]     vmalloc : 0xffffff8008000000 - 0xffffffbdbfff0000   (   246 GB)
[    0.000000]       .text : 0xffffff8008080000 - 0xffffff8008721000   (  6788 KB)
[    0.000000]     .rodata : 0xffffff8008721000 - 0xffffff80089f5000   (  2896 KB)
[    0.000000]       .init : 0xffffff80089f5000 - 0xffffff8008c29000   (  2256 KB)
[    0.000000]       .data : 0xffffff8008c29000 - 0xffffff8008cc3e00   (   620 KB)
[    0.000000]     vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
[    0.000000]               0xffffffbdc0200000 - 0xffffffbdd9000000   (   398 MB actual)
[    0.000000]     fixed   : 0xffffffbffe7fd000 - 0xffffffbffec00000   (  4108 KB)
[    0.000000]     PCI I/O : 0xffffffbffee00000 - 0xffffffbfffe00000   (    16 MB)
[    0.000000]     memory  : 0xffffffc008000000 - 0xffffffc640000000   ( 25472 MB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  Build-time adjustment of leaf fanout to 64.
[    0.000000]  RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=1.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1
[    0.000000] NR_IRQS:64 nr_irqs:64 0
[    0.000000] Architected cp15 timer(s) running at 8.33MHz (virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1ec02923e, max_idle_ns: 440795202125 ns
[    0.000003] sched_clock: 56 bits at 8MHz, resolution 120ns, wraps every 2199023255496ns
[    0.000078] Console: colour dummy device 80x25
[    0.000382] console [tty0] enabled
[    0.000402] Calibrating delay loop (skipped), value calculated using timer frequency.. 16.66 BogoMIPS (lpj=33333)
[    0.000419] pid_max: default: 32768 minimum: 301
[    0.000463] Security Framework initialized
[    0.000495] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
[    0.000505] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes)
[    0.001204] ASID allocator initialised with 65536 entries
[    0.001721] EFI services will not be available.
[    0.001826] Brought up 1 CPUs
[    0.001836] SMP: Total of 1 processors activated.
[    0.001850] CPU: All CPU(s) started at EL1
[    0.002615] devtmpfs: initialized
[    0.003177] DMI not present or invalid.
[    0.003369] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.003738] pinctrl core: initialized pinctrl subsystem
[    0.004515] NET: Registered protocol family 16
[    0.016065] cpuidle: using governor menu
[    0.016218] vdso: 2 pages (1 code @ ffffff8008727000, 1 data @ ffffff8008c30000)
[    0.016254] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.016750] DMA: preallocated 256 KiB pool for atomic allocations
[    0.016906] Serial: AMBA PL011 UART driver
[    0.040435] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    0.052844] vgaarb: loaded
[    0.053040] SCSI subsystem initialized
[    0.056288] libata version 3.00 loaded.
[    0.056470] usbcore: registered new interface driver usbfs
[    0.056509] usbcore: registered new interface driver hub
[    0.056541] usbcore: registered new device driver usb
[    0.056625] pps_core: LinuxPPS API ver. 1 registered
[    0.056634] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.056660] PTP clock support registered
[    0.056737] dmi: Firmware registration failed.
[    0.057028] Advanced Linux Sound Architecture Driver Initialized.
[    0.057989] clocksource: Switched to clocksource arch_sys_counter
[    0.058133] VFS: Disk quotas dquot_6.6.0
[    0.058179] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.068090] NET: Registered protocol family 2
[    0.068508] TCP established hash table entries: 32768 (order: 6, 262144 bytes)
[    0.068625] TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
[    0.069071] TCP: Hash tables configured (established 32768 bind 32768)
[    0.069176] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[    0.069209] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[    0.069373] NET: Registered protocol family 1
[    0.069706] RPC: Registered named UNIX socket transport module.
[    0.069725] RPC: Registered udp transport module.
[    0.069732] RPC: Registered tcp transport module.
[    0.069739] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.069765] PCI: CLS 0 bytes, default 128
[    0.116499] kvm [1]: HYP mode not available
[    0.118272] futex hash table entries: 256 (order: 3, 32768 bytes)
[    0.118353] audit: initializing netlink subsys (disabled)
[    0.118398] audit: type=2000 audit(0.115:1): initialized
[    0.119105] workingset: timestamp_bits=44 max_order=20 bucket_order=0
[    0.128905] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.129921] NFS: Registering the id_resolver key type
[    0.129976] Key type id_resolver registered
[    0.129984] Key type id_legacy registered
[    0.130194] fuse init (API version 7.24)
[    0.130623] 9p: Installing v9fs 9p2000 file system support
[    0.132356] io scheduler noop registered
[    0.132526] io scheduler cfq registered (default)
[    0.135682] xenfs: not registering filesystem on non-xen platform
[    0.140609] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.142028] SuperH (H)SCI(F) driver initialized
[    0.142217] e6e88000.serial: ttySC0 at MMIO 0xe6e88000 (irq = 6, base_baud = 0) is a scif
[    0.812036] console [ttySC0] enabled
[    0.815989] msm_serial: driver initialized
[    0.848254] loop: module loaded
[    0.852907] tun: Universal TUN/TAP device driver, 1.6
[    0.858608] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    0.865182] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    0.871284] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    0.877303] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k
[    0.884340] igb: Copyright (c) 2007-2014 Intel Corporation.
[    0.889981] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.2-k
[    0.897843] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    0.903823] sky2: driver version 1.30
[    0.907854] VFIO - User Level meta-driver version: 0.3
[    0.915399] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.922168] ehci-pci: EHCI PCI platform driver
[    0.926767] ehci-platform: EHCI generic platform driver
[    0.932151] ehci-msm: Qualcomm On-Chip EHCI Host Controller
[    0.937808] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.944041] ohci-pci: OHCI PCI platform driver
[    0.948553] ohci-platform: OHCI generic platform driver
[    0.954029] usbcore: registered new interface driver usb-storage
[    0.960813] mousedev: PS/2 mouse device common for all mice
[    0.967093] i2c /dev entries driver
[    0.971519] sdhci: Secure Digital Host Controller Interface driver
[    0.978118] sdhci: Copyright(c) Pierre Ossman
[    0.982619] Synopsys Designware Multimedia Card Interface Driver
[    0.988896] sdhci-pltfm: SDHCI platform and OF driver helper
[    0.994818] ledtrig-cpu: registered to indicate activity on CPUs
[    1.001589] usbcore: registered new interface driver usbhid
[    1.007437] usbhid: USB HID core driver
[    1.012433] NET: Registered protocol family 17
[    1.017379] 9pnet: Installing 9P2000 support
[    1.021779] Key type dns_resolver registered
[    1.026695] registered taskstats version 1
[    1.031222] hctosys: unable to open rtc device (rtc0)
[   13.081547] ALSA device list:
[   13.084527]   No soundcards found.
[   13.089430] Freeing unused kernel memory: 2256K (ffffff80089f5000 - ffffff8008c29000)


boot (Linux 4.6.0-rc1+, BusyBox v1.16.0.git, kexec-tools 2.0.1-git)
/ # cat /proc/interrupts 
           CPU0       
  3:        253     GIC-0  27 Edge      arch_timer
  6:         79     GIC-0 196 Level     e6e88000.serial:mux
IPI0:         0       Rescheduling interrupts
IPI1:         0       Function call interrupts
IPI2:         0       CPU stop interrupts
IPI3:         0       Timer broadcast interrupts
IPI4:         0       IRQ work interrupts
IPI5:         0       CPU wake-up interrupts
Err: 

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Simon Horman]

Basic support for the Gen 3 R-Car M3-W SoC.

Based on work for the r8a7795 and r8a7796 SoCs by
Takeshi Kihara, Dirk Behme and Geert Uytterhoeven.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v3
* As suggested by Geert Uytterhoeven:
  - Drop 0x from unit address of gic
* As suggested by Khiem Nguyen:
  - Use psci-0.2
* Added Reviewed-by tag from Geert Uytterhoeven

v2
* As suggested by Geert Uytterhoeven:
  - Move L2_CA57 node under cpus node and include reg property
  - Omit status = "disabled" from scif_clk node
---
 Documentation/devicetree/bindings/arm/shmobile.txt |   4 +
 arch/arm64/Kconfig.platforms                       |   6 ++
 arch/arm64/boot/dts/renesas/r8a7796.dtsi           | 120 +++++++++++++++++++++
 3 files changed, 130 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a7796.dtsi

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 9cf67e48f222..d5ed554830d7 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -29,6 +29,8 @@ SoCs:
     compatible = "renesas,r8a7794"
   - R-Car H3 (R8A77950)
     compatible = "renesas,r8a7795"
+  - R-Car M3-W (R8A77960)
+    compatible = "renesas,r8a7796"
 
 
 Boards:
@@ -61,5 +63,7 @@ Boards:
     compatible = "renesas,porter", "renesas,r8a7791"
   - Salvator-X (RTP0RC7795SIPB0010S)
     compatible = "renesas,salvator-x", "renesas,r8a7795";
+  - Salvator-X
+    compatible = "renesas,salvator-x", "renesas,r8a7796";
   - SILK (RTP0RC7794LCB00011S)
     compatible = "renesas,silk", "renesas,r8a7794"
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index efa77c146415..16d8d26839ea 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -114,6 +114,12 @@ config ARCH_R8A7795
 	help
 	  This enables support for the Renesas R-Car H3 SoC.
 
+config ARCH_R8A7796
+	bool "Renesas R-Car M3-W SoC Platform"
+	depends on ARCH_RENESAS
+	help
+	  This enables support for the Renesas R-Car M3-W SoC.
+
 config ARCH_STRATIX10
 	bool "Altera's Stratix 10 SoCFPGA Family"
 	help
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
new file mode 100644
index 000000000000..178debf68318
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -0,0 +1,120 @@
+/*
+ * Device Tree Source for the r8a7796 SoC
+ *
+ * Copyright (C) 2016 Renesas Electronics Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/clock/r8a7796-cpg-mssr.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "renesas,r8a7796";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		/* 1 core only at this point */
+		a57_0: cpu at 0 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			reg = <0x0>;
+			device_type = "cpu";
+			next-level-cache = <&L2_CA57>;
+			enable-method = "psci";
+		};
+
+		L2_CA57: cache-controller at 0 {
+			compatible = "cache";
+			reg = <0>;
+			cache-unified;
+			cache-level = <2>;
+		};
+	};
+
+	extal_clk: extal {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		/* This value must be overridden by the board */
+		clock-frequency = <0>;
+	};
+
+	extalr_clk: extalr {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		/* This value must be overridden by the board */
+		clock-frequency = <0>;
+	};
+
+	/* External SCIF clock - to be overridden by boards that provide it */
+	scif_clk: scif {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <0>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		interrupt-parent = <&gic>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		gic: interrupt-controller at f1010000 {
+			compatible = "arm,gic-400";
+			#interrupt-cells = <3>;
+			#address-cells = <0>;
+			interrupt-controller;
+			reg = <0x0 0xf1010000 0 0x1000>,
+			      <0x0 0xf1020000 0 0x20000>,
+			      <0x0 0xf1040000 0 0x20000>,
+			      <0x0 0xf1060000 0 0x20000>;
+			interrupts = <GIC_PPI 9
+					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
+		};
+
+		timer {
+			compatible = "arm,armv8-timer";
+			interrupts = <GIC_PPI 13
+					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+				     <GIC_PPI 14
+					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+				     <GIC_PPI 11
+					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+				     <GIC_PPI 10
+					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>;
+		};
+
+		cpg: clock-controller at e6150000 {
+			compatible = "renesas,r8a7796-cpg-mssr";
+			reg = <0 0xe6150000 0 0x1000>;
+			clocks = <&extal_clk>, <&extalr_clk>;
+			clock-names = "extal", "extalr";
+			#clock-cells = <2>;
+			#power-domain-cells = <0>;
+		};
+
+		scif2: serial at e6e88000 {
+			compatible = "renesas,scif-r8a7796",
+				     "renesas,rcar-gen3-scif", "renesas,scif";
+			reg = <0 0xe6e88000 0 64>;
+			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 310>,
+				 <&cpg CPG_CORE R8A7796_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+	};
+};
-- 
2.1.4

[PATCH v3 2/3] arm64: dts: salvator-x: add Salvator-X board on R8A7796 SoC

[Simon Horman]

From: Takeshi Kihara <takeshi.kihara.df@renesas.com>

This patch adds initial board support for R8A7796 Salvator-X.

Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
--
v2 [Simon Horman]
* Added Reviewed-by tag from Geert Uytterhoeven

v1 [Simon Horman]
* Drop use of pfc, that can be added once pfc support is present in mainline
* Set size of memory (bank 0) to 2GiB instead of 1GiB
* Omit scif0
* Add scif_clk, from patch by Hiromitsu Yamasaki

v0 [Takeshi Kihara]
---
 arch/arm64/boot/dts/renesas/Makefile               |  1 +
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 45 ++++++++++++++++++++++
 2 files changed, 46 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts

diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index 9ce1890a650e..17139f7003a6 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb
+dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb
 
 always		:= $(dtb-y)
 clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
new file mode 100644
index 000000000000..9c52613fb88c
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -0,0 +1,45 @@
+/*
+ * Device Tree Source for the Salvator-X board
+ *
+ * Copyright (C) 2016 Renesas Electronics Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7796.dtsi"
+
+/ {
+	model = "Renesas Salvator-X board based on r8a7796";
+	compatible = "renesas,salvator-x", "renesas,r8a7796";
+
+	aliases {
+		serial0 = &scif2;
+	};
+
+	chosen {
+		bootargs = "ignore_loglevel";
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory at 48000000 {
+		device_type = "memory";
+		/* first 128MB is reserved for secure area. */
+		reg = <0x0 0x48000000 0x0 0x78000000>;
+	};
+};
+
+&extal_clk {
+	clock-frequency = <16666666>;
+};
+
+&scif2 {
+	status = "okay";
+};
+
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
-- 
2.1.4

[PATCH v3 3/3] arm64: defconfig: enable Renesas R8A7796 SoC

[Simon Horman]

From: Takeshi Kihara <takeshi.kihara.df@renesas.com>

This patch enables the Renesas R8A7796 SoC in the arm64 defconfig.

Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2 [Simon Horman]
* Added Acked-by tag from Geert Uytterhoeven
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f70505186820..0d37fa5a59aa 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -44,6 +44,7 @@ CONFIG_ARCH_ROCKCHIP=y
 CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_RENESAS=y
 CONFIG_ARCH_R8A7795=y
+CONFIG_ARCH_R8A7796=y
 CONFIG_ARCH_STRATIX10=y
 CONFIG_ARCH_TEGRA=y
 CONFIG_ARCH_SPRD=y
-- 
2.1.4

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Dirk Behme]

Hi Simon,

On 24.05.2016 03:54, Simon Horman wrote:
> Basic support for the Gen 3 R-Car M3-W SoC.
>
> Based on work for the r8a7795 and r8a7796 SoCs by
> Takeshi Kihara, Dirk Behme and Geert Uytterhoeven.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v3
> * As suggested by Geert Uytterhoeven:
>   - Drop 0x from unit address of gic
> * As suggested by Khiem Nguyen:
>   - Use psci-0.2
> * Added Reviewed-by tag from Geert Uytterhoeven
>
> v2
> * As suggested by Geert Uytterhoeven:
>   - Move L2_CA57 node under cpus node and include reg property
>   - Omit status = "disabled" from scif_clk node
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt |   4 +
>  arch/arm64/Kconfig.platforms                       |   6 ++
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi           | 120 +++++++++++++++++++++
>  3 files changed, 130 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/renesas/r8a7796.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
> index 9cf67e48f222..d5ed554830d7 100644
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -29,6 +29,8 @@ SoCs:
>      compatible = "renesas,r8a7794"
>    - R-Car H3 (R8A77950)
>      compatible = "renesas,r8a7795"
> +  - R-Car M3-W (R8A77960)
> +    compatible = "renesas,r8a7796"
>
>
>  Boards:
> @@ -61,5 +63,7 @@ Boards:
>      compatible = "renesas,porter", "renesas,r8a7791"
>    - Salvator-X (RTP0RC7795SIPB0010S)
>      compatible = "renesas,salvator-x", "renesas,r8a7795";
> +  - Salvator-X
> +    compatible = "renesas,salvator-x", "renesas,r8a7796";
>    - SILK (RTP0RC7794LCB00011S)
>      compatible = "renesas,silk", "renesas,r8a7794"
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index efa77c146415..16d8d26839ea 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -114,6 +114,12 @@ config ARCH_R8A7795
>  	help
>  	  This enables support for the Renesas R-Car H3 SoC.
>
> +config ARCH_R8A7796
> +	bool "Renesas R-Car M3-W SoC Platform"
> +	depends on ARCH_RENESAS
> +	help
> +	  This enables support for the Renesas R-Car M3-W SoC.
> +
>  config ARCH_STRATIX10
>  	bool "Altera's Stratix 10 SoCFPGA Family"
>  	help
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> new file mode 100644
> index 000000000000..178debf68318
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -0,0 +1,120 @@
> +/*
> + * Device Tree Source for the r8a7796 SoC
> + *
> + * Copyright (C) 2016 Renesas Electronics Corp.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include <dt-bindings/clock/r8a7796-cpg-mssr.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>


With Renesas R-Car3 we will get a whole family of SoCs. I.e. different 
computing power (e.g. different number of Cores) with more or less 
similar peripherals.

I would think that we want to reflect this in the device tree, too. 
Therefore I think what we want is a hierarchy of device trees. Similar 
what's done with other SoC families (compare e.g. i.MX6).

E.g. we want an initial rcar3.dtsi, which contains all common parts of 
all R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc.

Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and 
extends it for SoC specific parts. Which then will be included by the 
board device trees, as already done, now.

Or in other words: As soon as you have similar parts in the 
r8a779x.dtsi's, it's time to think about moving the parts one hierarchy 
level up into the rcar3.dtsi. Else you will end up in a maintenance hell 
once you have to change/fix anything.

Best regards

Dirk

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Simon Horman]

Hi Dirk,

On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote:
> Hi Simon,

[...]

> With Renesas R-Car3 we will get a whole family of SoCs. I.e. different
> computing power (e.g. different number of Cores) with more or less similar
> peripherals.
> 
> I would think that we want to reflect this in the device tree, too.
> Therefore I think what we want is a hierarchy of device trees. Similar
> what's done with other SoC families (compare e.g. i.MX6).
> 
> E.g. we want an initial rcar3.dtsi, which contains all common parts of all
> R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc.
> 
> Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and
> extends it for SoC specific parts. Which then will be included by the board
> device trees, as already done, now.
> 
> Or in other words: As soon as you have similar parts in the r8a779x.dtsi's,
> it's time to think about moving the parts one hierarchy level up into the
> rcar3.dtsi. Else you will end up in a maintenance hell once you have to
> change/fix anything.

Thanks for raising this issue.

I agree entirely that we should work towards a situation where maintenance
is as easy as it can be. However, due to the per-SoC binding scheme that
we are using for IP related to Renesas SoCs I suspect that very few DT nodes
can be shared between SoCs verbatim.

Probably some sort of scheme can be cooked up using preprocessor macros.
And probably there are other ways to resolve this problem. But I would
prefer if we worked towards resolving this maintenance problem in parallel
with rather than as a dependency of merging r8a7796 support into mainline.

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Dirk Behme]

Hi Simon,

On 25.05.2016 02:48, Simon Horman wrote:
> Hi Dirk,
>
> On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote:
>> Hi Simon,
>
> [...]
>
>> With Renesas R-Car3 we will get a whole family of SoCs. I.e. different
>> computing power (e.g. different number of Cores) with more or less similar
>> peripherals.
>>
>> I would think that we want to reflect this in the device tree, too.
>> Therefore I think what we want is a hierarchy of device trees. Similar
>> what's done with other SoC families (compare e.g. i.MX6).
>>
>> E.g. we want an initial rcar3.dtsi, which contains all common parts of all
>> R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc.
>>
>> Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and
>> extends it for SoC specific parts. Which then will be included by the board
>> device trees, as already done, now.
>>
>> Or in other words: As soon as you have similar parts in the r8a779x.dtsi's,
>> it's time to think about moving the parts one hierarchy level up into the
>> rcar3.dtsi. Else you will end up in a maintenance hell once you have to
>> change/fix anything.
>
> Thanks for raising this issue.
>
> I agree entirely that we should work towards a situation where maintenance
> is as easy as it can be. However, due to the per-SoC binding scheme that
> we are using for IP related to Renesas SoCs I suspect that very few DT nodes
> can be shared between SoCs verbatim.


Could you kindly share an example for this? Looking into the H3 and the 
M3-W manual, it looks to me that ~90% (?) of the peripherals are the same.


> Probably some sort of scheme can be cooked up using preprocessor macros.
> And probably there are other ways to resolve this problem. But I would
> prefer if we worked towards resolving this maintenance problem in parallel
> with rather than as a dependency of merging r8a7796 support into mainline.


I'd propose to do it correct from the beginning.

Doing it later would either be more work or forgotten, and never be 
done, then.

For a starting point, I'd propose to put the r8a7795.dtsi and 
r8a7796.dtsi into a graphical diff tool and move all common parts to a 
rcar3.dtsi (I'd be happy to discuss the name, though)

Best regards

Dirk

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Dirk Behme]

On 25.05.2016 07:10, Dirk Behme wrote:
> Hi Simon,
>
> On 25.05.2016 02:48, Simon Horman wrote:
>> Hi Dirk,
>>
>> On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote:
>>> Hi Simon,
>>
>> [...]
>>
>>> With Renesas R-Car3 we will get a whole family of SoCs. I.e. different
>>> computing power (e.g. different number of Cores) with more or less
>>> similar
>>> peripherals.
>>>
>>> I would think that we want to reflect this in the device tree, too.
>>> Therefore I think what we want is a hierarchy of device trees. Similar
>>> what's done with other SoC families (compare e.g. i.MX6).
>>>
>>> E.g. we want an initial rcar3.dtsi, which contains all common parts
>>> of all
>>> R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc.
>>>
>>> Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and
>>> extends it for SoC specific parts. Which then will be included by the
>>> board
>>> device trees, as already done, now.
>>>
>>> Or in other words: As soon as you have similar parts in the
>>> r8a779x.dtsi's,
>>> it's time to think about moving the parts one hierarchy level up into
>>> the
>>> rcar3.dtsi. Else you will end up in a maintenance hell once you have to
>>> change/fix anything.
>>
>> Thanks for raising this issue.
>>
>> I agree entirely that we should work towards a situation where
>> maintenance
>> is as easy as it can be. However, due to the per-SoC binding scheme that
>> we are using for IP related to Renesas SoCs I suspect that very few DT
>> nodes
>> can be shared between SoCs verbatim.
>
>
> Could you kindly share an example for this? Looking into the H3 and the
> M3-W manual, it looks to me that ~90% (?) of the peripherals are the same.
>
>
>> Probably some sort of scheme can be cooked up using preprocessor macros.
>> And probably there are other ways to resolve this problem. But I would
>> prefer if we worked towards resolving this maintenance problem in
>> parallel
>> with rather than as a dependency of merging r8a7796 support into
>> mainline.
>
>
> I'd propose to do it correct from the beginning.
>
> Doing it later would either be more work or forgotten, and never be
> done, then.
>
> For a starting point, I'd propose to put the r8a7795.dtsi and
> r8a7796.dtsi into a graphical diff tool and move all common parts to a
> rcar3.dtsi (I'd be happy to discuss the name, though)


To give an example what I'm talking about kindly have a look to the 
attached (draft) patch.

Best regards

Dirk

P.S.: This also results in the question why we need similar 
r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" 
for the same clocks. Can't we use the same numbers on all SoCs, with 
just having wholes in the list where the clocks don't exist on a SoC? I 
haven't looked into the manual if these numbers are given by the 
hardware, though.

-------------- next part --------------
>From 08078bf12780176ab116fe5f39a378f5ee374ae3 Mon Sep 17 00:00:00 2001
From: Dirk Behme <dirk.behme@de.bosch.com>
Date: Wed, 25 May 2016 09:23:58 +0200
Subject: [PATCH] arm64: dts: Renesas R-Car3: Introduce common rcar3.dtsi

The R-Car3 SoC family will contain several similar SoCs, sharing
several peripherals.

Introduce a common rcar3.dtsi containing the common parts of all
R-Car3 family SoCs.

Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 109 ++----------------------------
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 109 ++----------------------------
 arch/arm64/boot/dts/renesas/rcar3.dtsi   | 112 +++++++++++++++++++++++++++++++
 3 files changed, 125 insertions(+), 205 deletions(-)
 create mode 100644 arch/arm64/boot/dts/renesas/rcar3.dtsi

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a7315eb..0737ed2 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -10,11 +10,10 @@
 
 #include <dt-bindings/clock/r8a7795-cpg-mssr.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "rcar3.dtsi"
 
 / {
 	compatible = "renesas,r8a7795";
-	#address-cells = <2>;
-	#size-cells = <2>;
 
 	aliases {
 		i2c0 = &i2c0;
@@ -26,23 +25,7 @@
 		i2c6 = &i2c6;
 	};
 
-	psci {
-		compatible = "arm,psci-0.2";
-		method = "smc";
-	};
-
 	cpus {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		a57_0: cpu at 0 {
-			compatible = "arm,cortex-a57", "arm,armv8";
-			reg = <0x0>;
-			device_type = "cpu";
-			next-level-cache = <&L2_CA57>;
-			enable-method = "psci";
-		};
-
 		a57_1: cpu at 1 {
 			compatible = "arm,cortex-a57","arm,armv8";
 			reg = <0x1>;
@@ -66,32 +49,12 @@
 		};
 	};
 
-	L2_CA57: cache-controller at 0 {
-		compatible = "cache";
-		cache-unified;
-		cache-level = <2>;
-	};
-
 	L2_CA53: cache-controller at 1 {
 		compatible = "cache";
 		cache-unified;
 		cache-level = <2>;
 	};
 
-	extal_clk: extal {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		/* This value must be overridden by the board */
-		clock-frequency = <0>;
-	};
-
-	extalr_clk: extalr {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		/* This value must be overridden by the board */
-		clock-frequency = <0>;
-	};
-
 	/*
 	 * The external audio clocks are configured as 0 Hz fixed frequency
 	 * clocks by default.
@@ -115,35 +78,7 @@
 		clock-frequency = <0>;
 	};
 
-	/* External SCIF clock - to be overridden by boards that provide it */
-	scif_clk: scif {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		clock-frequency = <0>;
-		status = "disabled";
-	};
-
 	soc {
-		compatible = "simple-bus";
-		interrupt-parent = <&gic>;
-
-		#address-cells = <2>;
-		#size-cells = <2>;
-		ranges;
-
-		gic: interrupt-controller at 0xf1010000 {
-			compatible = "arm,gic-400";
-			#interrupt-cells = <3>;
-			#address-cells = <0>;
-			interrupt-controller;
-			reg = <0x0 0xf1010000 0 0x1000>,
-			      <0x0 0xf1020000 0 0x2000>,
-			      <0x0 0xf1040000 0 0x20000>,
-			      <0x0 0xf1060000 0 0x2000>;
-			interrupts = <GIC_PPI 9
-					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
-		};
-
 		gpio0: gpio at e6050000 {
 			compatible = "renesas,gpio-r8a7795",
 				     "renesas,gpio-rcar";
@@ -268,27 +203,6 @@
 					     <&a57_3>;
 		};
 
-		timer {
-			compatible = "arm,armv8-timer";
-			interrupts = <GIC_PPI 13
-					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-				     <GIC_PPI 14
-					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-				     <GIC_PPI 11
-					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-				     <GIC_PPI 10
-					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
-		};
-
-		cpg: clock-controller at e6150000 {
-			compatible = "renesas,r8a7795-cpg-mssr";
-			reg = <0 0xe6150000 0 0x1000>;
-			clocks = <&extal_clk>, <&extalr_clk>;
-			clock-names = "extal", "extalr";
-			#clock-cells = <2>;
-			#power-domain-cells = <0>;
-		};
-
 		audma0: dma-controller at ec700000 {
 			compatible = "renesas,rcar-dmac";
 			reg = <0 0xec700000 0 0x10000>;
@@ -625,21 +539,6 @@
 			status = "disabled";
 		};
 
-		scif2: serial at e6e88000 {
-			compatible = "renesas,scif-r8a7795",
-				     "renesas,rcar-gen3-scif", "renesas,scif";
-			reg = <0 0xe6e88000 0 64>;
-			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 310>,
-				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
-				 <&scif_clk>;
-			clock-names = "fck", "brg_int", "scif_clk";
-			dmas = <&dmac1 0x13>, <&dmac1 0x12>;
-			dma-names = "tx", "rx";
-			power-domains = <&cpg>;
-			status = "disabled";
-		};
-
 		scif3: serial at e6c50000 {
 			compatible = "renesas,scif-r8a7795",
 				     "renesas,rcar-gen3-scif", "renesas,scif";
@@ -1120,3 +1019,9 @@
 		};
 	};
 };
+
+&scif2 {
+	clocks = <&cpg CPG_MOD 310>,
+		 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+		 <&scif_clk>;
+};
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 178debf..3e480d9 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -10,111 +10,14 @@
 
 #include <dt-bindings/clock/r8a7796-cpg-mssr.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "rcar3.dtsi"
 
 / {
 	compatible = "renesas,r8a7796";
-	#address-cells = <2>;
-	#size-cells = <2>;
-
-	psci {
-		compatible = "arm,psci-0.2";
-		method = "smc";
-	};
-
-	cpus {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		/* 1 core only at this point */
-		a57_0: cpu at 0 {
-			compatible = "arm,cortex-a57", "arm,armv8";
-			reg = <0x0>;
-			device_type = "cpu";
-			next-level-cache = <&L2_CA57>;
-			enable-method = "psci";
-		};
-
-		L2_CA57: cache-controller at 0 {
-			compatible = "cache";
-			reg = <0>;
-			cache-unified;
-			cache-level = <2>;
-		};
-	};
-
-	extal_clk: extal {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		/* This value must be overridden by the board */
-		clock-frequency = <0>;
-	};
-
-	extalr_clk: extalr {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		/* This value must be overridden by the board */
-		clock-frequency = <0>;
-	};
-
-	/* External SCIF clock - to be overridden by boards that provide it */
-	scif_clk: scif {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		clock-frequency = <0>;
-	};
-
-	soc {
-		compatible = "simple-bus";
-		interrupt-parent = <&gic>;
-		#address-cells = <2>;
-		#size-cells = <2>;
-		ranges;
-
-		gic: interrupt-controller at f1010000 {
-			compatible = "arm,gic-400";
-			#interrupt-cells = <3>;
-			#address-cells = <0>;
-			interrupt-controller;
-			reg = <0x0 0xf1010000 0 0x1000>,
-			      <0x0 0xf1020000 0 0x20000>,
-			      <0x0 0xf1040000 0 0x20000>,
-			      <0x0 0xf1060000 0 0x20000>;
-			interrupts = <GIC_PPI 9
-					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
-		};
-
-		timer {
-			compatible = "arm,armv8-timer";
-			interrupts = <GIC_PPI 13
-					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
-				     <GIC_PPI 14
-					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
-				     <GIC_PPI 11
-					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
-				     <GIC_PPI 10
-					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>;
-		};
-
-		cpg: clock-controller at e6150000 {
-			compatible = "renesas,r8a7796-cpg-mssr";
-			reg = <0 0xe6150000 0 0x1000>;
-			clocks = <&extal_clk>, <&extalr_clk>;
-			clock-names = "extal", "extalr";
-			#clock-cells = <2>;
-			#power-domain-cells = <0>;
-		};
+};
 
-		scif2: serial at e6e88000 {
-			compatible = "renesas,scif-r8a7796",
-				     "renesas,rcar-gen3-scif", "renesas,scif";
-			reg = <0 0xe6e88000 0 64>;
-			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 310>,
-				 <&cpg CPG_CORE R8A7796_CLK_S3D1>,
-				 <&scif_clk>;
-			clock-names = "fck", "brg_int", "scif_clk";
-			power-domains = <&cpg>;
-			status = "disabled";
-		};
-	};
+&scif2 {
+	clocks = <&cpg CPG_MOD 310>,
+		 <&cpg CPG_CORE R8A7796_CLK_S3D1>,
+		 <&scif_clk>;
 };
diff --git a/arch/arm64/boot/dts/renesas/rcar3.dtsi b/arch/arm64/boot/dts/renesas/rcar3.dtsi
new file mode 100644
index 0000000..c02c8e4
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/rcar3.dtsi
@@ -0,0 +1,112 @@
+/*
+ * Device Tree Source for the R-Car3 SoC family
+ *
+ * Copyright (C) 2015-2016 Renesas Electronics Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		a57_0: cpu at 0 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			reg = <0x0>;
+			device_type = "cpu";
+			next-level-cache = <&L2_CA57>;
+			enable-method = "psci";
+		};
+	};
+
+	L2_CA57: cache-controller at 0 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	extal_clk: extal {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		/* This value must be overridden by the board */
+		clock-frequency = <0>;
+	};
+
+	extalr_clk: extalr {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		/* This value must be overridden by the board */
+		clock-frequency = <0>;
+	};
+
+	/* External SCIF clock - to be overridden by boards that provide it */
+	scif_clk: scif {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <0>;
+		status = "disabled";
+	};
+
+	soc {
+		compatible = "simple-bus";
+		interrupt-parent = <&gic>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		gic: interrupt-controller at f1010000 {
+			compatible = "arm,gic-400";
+			#interrupt-cells = <3>;
+			#address-cells = <0>;
+			interrupt-controller;
+			reg = <0x0 0xf1010000 0 0x1000>,
+			      <0x0 0xf1020000 0 0x20000>,
+			      <0x0 0xf1040000 0 0x20000>,
+			      <0x0 0xf1060000 0 0x20000>;
+			interrupts = <GIC_PPI 9
+					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
+		};
+
+		timer {
+			compatible = "arm,armv8-timer";
+			interrupts = <GIC_PPI 13
+					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+				     <GIC_PPI 14
+					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+				     <GIC_PPI 11
+					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>,
+				     <GIC_PPI 10
+					(GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>;
+		};
+
+		cpg: clock-controller at e6150000 {
+			compatible = "renesas,r8a7795-cpg-mssr", "renesas,r8a7796-cpg-mssr";
+			reg = <0 0xe6150000 0 0x1000>;
+			clocks = <&extal_clk>, <&extalr_clk>;
+			clock-names = "extal", "extalr";
+			#clock-cells = <2>;
+			#power-domain-cells = <0>;
+		};
+
+		scif2: serial at e6e88000 {
+			compatible = "renesas,scif-r8a7795", "renesas,scif-r8a7796",
+				     "renesas,rcar-gen3-scif", "renesas,scif";
+			reg = <0 0xe6e88000 0 64>;
+			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "fck", "brg_int", "scif_clk";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+	};
+};
-- 
2.8.0

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Dirk Behme]

On 24.05.2016 03:54, Simon Horman wrote:
> Basic support for the Gen 3 R-Car M3-W SoC.
>
> Based on work for the r8a7795 and r8a7796 SoCs by
> Takeshi Kihara, Dirk Behme and Geert Uytterhoeven.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v3
> * As suggested by Geert Uytterhoeven:
>   - Drop 0x from unit address of gic
> * As suggested by Khiem Nguyen:
>   - Use psci-0.2
> * Added Reviewed-by tag from Geert Uytterhoeven
>
> v2
> * As suggested by Geert Uytterhoeven:
>   - Move L2_CA57 node under cpus node and include reg property
>   - Omit status = "disabled" from scif_clk node
> ---
>  Documentation/devicetree/bindings/arm/shmobile.txt |   4 +
>  arch/arm64/Kconfig.platforms                       |   6 ++
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi           | 120 +++++++++++++++++++++
>  3 files changed, 130 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/renesas/r8a7796.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
> index 9cf67e48f222..d5ed554830d7 100644
> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -29,6 +29,8 @@ SoCs:
>      compatible = "renesas,r8a7794"
>    - R-Car H3 (R8A77950)
>      compatible = "renesas,r8a7795"
> +  - R-Car M3-W (R8A77960)
> +    compatible = "renesas,r8a7796"
>
>
>  Boards:
> @@ -61,5 +63,7 @@ Boards:
>      compatible = "renesas,porter", "renesas,r8a7791"
>    - Salvator-X (RTP0RC7795SIPB0010S)
>      compatible = "renesas,salvator-x", "renesas,r8a7795";
> +  - Salvator-X
> +    compatible = "renesas,salvator-x", "renesas,r8a7796";
>    - SILK (RTP0RC7794LCB00011S)
>      compatible = "renesas,silk", "renesas,r8a7794"
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index efa77c146415..16d8d26839ea 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -114,6 +114,12 @@ config ARCH_R8A7795
>  	help
>  	  This enables support for the Renesas R-Car H3 SoC.
>
> +config ARCH_R8A7796
> +	bool "Renesas R-Car M3-W SoC Platform"
> +	depends on ARCH_RENESAS
> +	help
> +	  This enables support for the Renesas R-Car M3-W SoC.
> +
>  config ARCH_STRATIX10
>  	bool "Altera's Stratix 10 SoCFPGA Family"
>  	help
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> new file mode 100644
> index 000000000000..178debf68318
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -0,0 +1,120 @@
> +/*
> + * Device Tree Source for the r8a7796 SoC
> + *
> + * Copyright (C) 2016 Renesas Electronics Corp.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include <dt-bindings/clock/r8a7796-cpg-mssr.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	compatible = "renesas,r8a7796";
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	psci {
> +		compatible = "arm,psci-0.2";
> +		method = "smc";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		/* 1 core only at this point */
> +		a57_0: cpu at 0 {
> +			compatible = "arm,cortex-a57", "arm,armv8";
> +			reg = <0x0>;
> +			device_type = "cpu";
> +			next-level-cache = <&L2_CA57>;
> +			enable-method = "psci";
> +		};
> +
> +		L2_CA57: cache-controller at 0 {
> +			compatible = "cache";
> +			reg = <0>;
> +			cache-unified;
> +			cache-level = <2>;
> +		};
> +	};


It looks to me that in the r8a7795.dtsi the cache-controller node is 
outside the cpus node? I'd think that we should keep is consistent.

Best regards

Dirk

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Simon Horman]

Hi Dirk,

On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote:
> Hi Simon,
> 
> On 25.05.2016 02:48, Simon Horman wrote:
> >Hi Dirk,
> >
> >On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote:
> >>Hi Simon,
> >
> >[...]
> >
> >>With Renesas R-Car3 we will get a whole family of SoCs. I.e. different
> >>computing power (e.g. different number of Cores) with more or less similar
> >>peripherals.
> >>
> >>I would think that we want to reflect this in the device tree, too.
> >>Therefore I think what we want is a hierarchy of device trees. Similar
> >>what's done with other SoC families (compare e.g. i.MX6).
> >>
> >>E.g. we want an initial rcar3.dtsi, which contains all common parts of all
> >>R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc.
> >>
> >>Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and
> >>extends it for SoC specific parts. Which then will be included by the board
> >>device trees, as already done, now.
> >>
> >>Or in other words: As soon as you have similar parts in the r8a779x.dtsi's,
> >>it's time to think about moving the parts one hierarchy level up into the
> >>rcar3.dtsi. Else you will end up in a maintenance hell once you have to
> >>change/fix anything.
> >
> >Thanks for raising this issue.
> >
> >I agree entirely that we should work towards a situation where maintenance
> >is as easy as it can be. However, due to the per-SoC binding scheme that
> >we are using for IP related to Renesas SoCs I suspect that very few DT nodes
> >can be shared between SoCs verbatim.
> 
> 
> Could you kindly share an example for this? Looking into the H3 and the M3-W
> manual, it looks to me that ~90% (?) of the peripherals are the same.

The background is that this is a conversation that has been going around
for years. The basic thinking is that at this point we have documentation
that indicates that many hardware blocks on the H3 and M3-W are the same.
But we do not have insight into the internal versioning of the IP blocks
nor if they are really the same. And furthermore even if they are currently
the same we don't really know if that will continue to be the case.

Probably it is. Maybe it isn't. The response has been to take a
conservative approach to DT bindings to give us the flexibility to update
the driver implementation to reflect any differences that subsequently
surface. And by providing per-SoC bindings these driver changes can be
activated on a per-SoC basis without updating DTB files (which may be
burned into ROMs).

There is of course scope to take a different approach. But getting
consensus on this is frankly difficult. And at the very least I would
expect it to take time.

> >Probably some sort of scheme can be cooked up using preprocessor macros.
> >And probably there are other ways to resolve this problem. But I would
> >prefer if we worked towards resolving this maintenance problem in parallel
> >with rather than as a dependency of merging r8a7796 support into mainline.
> 
> 
> I'd propose to do it correct from the beginning.
> 
> Doing it later would either be more work or forgotten, and never be done,
> then.

I'm sorry but I don't agree. I think that having r8a7796 support
in mainline is a higher priority than sorting this out.

> For a starting point, I'd propose to put the r8a7795.dtsi and r8a7796.dtsi
> into a graphical diff tool and move all common parts to a rcar3.dtsi (I'd be
> happy to discuss the name, though)

I'm not opposed to that. But being consistent with my statement above
I would prefer it to be done as follow-up work.

My suspicion is that right now much of the proposed r8a7796.dtsi can be
moved into a hypothetical rcar3.dtsi. But that this is because the proposed
r8a7796.dtsi is very small. I would not expect nearly such a large
proportion of r8a7795.dtsi to be able to be moved into rcar3.dtsi because
it enables more hardware blocks and they typically have (or should have in
keeping with the prevailing policy as described above) per-SoC bindings.

I believe that there is also a another issue which is that we wish
to control enabling features on different SoCs once they are known to work.
Of course things slip through the cracks. But blindly assuming all
IP blocks enabled for one SoC work on another, even if based on the
documentation, seems to be asking for trouble to me. For one thing
it implies that the level of firmware support is the same.

As for a name, I suggest rcar-gen3.dtsi.

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Simon Horman]

On Wed, May 25, 2016 at 09:38:23AM +0200, Dirk Behme wrote:
> On 24.05.2016 03:54, Simon Horman wrote:
> >Basic support for the Gen 3 R-Car M3-W SoC.
> >
> >Based on work for the r8a7795 and r8a7796 SoCs by
> >Takeshi Kihara, Dirk Behme and Geert Uytterhoeven.
> >
> >Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> >Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >---
> >v3
> >* As suggested by Geert Uytterhoeven:
> >  - Drop 0x from unit address of gic
> >* As suggested by Khiem Nguyen:
> >  - Use psci-0.2
> >* Added Reviewed-by tag from Geert Uytterhoeven
> >
> >v2
> >* As suggested by Geert Uytterhoeven:
> >  - Move L2_CA57 node under cpus node and include reg property
> >  - Omit status = "disabled" from scif_clk node
> >---
> > Documentation/devicetree/bindings/arm/shmobile.txt |   4 +
> > arch/arm64/Kconfig.platforms                       |   6 ++
> > arch/arm64/boot/dts/renesas/r8a7796.dtsi           | 120 +++++++++++++++++++++
> > 3 files changed, 130 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/renesas/r8a7796.dtsi
> >
> >diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
> >index 9cf67e48f222..d5ed554830d7 100644
> >--- a/Documentation/devicetree/bindings/arm/shmobile.txt
> >+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
> >@@ -29,6 +29,8 @@ SoCs:
> >     compatible = "renesas,r8a7794"
> >   - R-Car H3 (R8A77950)
> >     compatible = "renesas,r8a7795"
> >+  - R-Car M3-W (R8A77960)
> >+    compatible = "renesas,r8a7796"
> >
> >
> > Boards:
> >@@ -61,5 +63,7 @@ Boards:
> >     compatible = "renesas,porter", "renesas,r8a7791"
> >   - Salvator-X (RTP0RC7795SIPB0010S)
> >     compatible = "renesas,salvator-x", "renesas,r8a7795";
> >+  - Salvator-X
> >+    compatible = "renesas,salvator-x", "renesas,r8a7796";
> >   - SILK (RTP0RC7794LCB00011S)
> >     compatible = "renesas,silk", "renesas,r8a7794"
> >diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >index efa77c146415..16d8d26839ea 100644
> >--- a/arch/arm64/Kconfig.platforms
> >+++ b/arch/arm64/Kconfig.platforms
> >@@ -114,6 +114,12 @@ config ARCH_R8A7795
> > 	help
> > 	  This enables support for the Renesas R-Car H3 SoC.
> >
> >+config ARCH_R8A7796
> >+	bool "Renesas R-Car M3-W SoC Platform"
> >+	depends on ARCH_RENESAS
> >+	help
> >+	  This enables support for the Renesas R-Car M3-W SoC.
> >+
> > config ARCH_STRATIX10
> > 	bool "Altera's Stratix 10 SoCFPGA Family"
> > 	help
> >diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> >new file mode 100644
> >index 000000000000..178debf68318
> >--- /dev/null
> >+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> >@@ -0,0 +1,120 @@
> >+/*
> >+ * Device Tree Source for the r8a7796 SoC
> >+ *
> >+ * Copyright (C) 2016 Renesas Electronics Corp.
> >+ *
> >+ * This file is licensed under the terms of the GNU General Public License
> >+ * version 2.  This program is licensed "as is" without any warranty of any
> >+ * kind, whether express or implied.
> >+ */
> >+
> >+#include <dt-bindings/clock/r8a7796-cpg-mssr.h>
> >+#include <dt-bindings/interrupt-controller/arm-gic.h>
> >+
> >+/ {
> >+	compatible = "renesas,r8a7796";
> >+	#address-cells = <2>;
> >+	#size-cells = <2>;
> >+
> >+	psci {
> >+		compatible = "arm,psci-0.2";
> >+		method = "smc";
> >+	};
> >+
> >+	cpus {
> >+		#address-cells = <1>;
> >+		#size-cells = <0>;
> >+
> >+		/* 1 core only at this point */
> >+		a57_0: cpu at 0 {
> >+			compatible = "arm,cortex-a57", "arm,armv8";
> >+			reg = <0x0>;
> >+			device_type = "cpu";
> >+			next-level-cache = <&L2_CA57>;
> >+			enable-method = "psci";
> >+		};
> >+
> >+		L2_CA57: cache-controller at 0 {
> >+			compatible = "cache";
> >+			reg = <0>;
> >+			cache-unified;
> >+			cache-level = <2>;
> >+		};
> >+	};
> 
> 
> It looks to me that in the r8a7795.dtsi the cache-controller node is outside
> the cpus node? I'd think that we should keep is consistent.

As of c10cdf93a119 ("arm64: dts: r8a7795: Fix W=1 dtc warnings"),
which was recently added to the devel branch of the renesas tree,
the cache-controller is inside the cpu node on the r8a7795.dtsi.

This patch aims to be consistent with that change.

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Geert Uytterhoeven]

Hi Dirk,

On Wed, May 25, 2016 at 9:32 AM, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> P.S.: This also results in the question why we need similar
> r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" for
> the same clocks. Can't we use the same numbers on all SoCs, with just having
> wholes in the list where the clocks don't exist on a SoC? I haven't looked

The CPG and MSSR block are the IP blocks that differ most among SoCs of the
same family. Some clocks are present on H3 only, others on M3-W only.

Having a shared driver core, but different defines, is a compromise between
reusability and avoiding mistakes in DTSes (e.g. pointing to a nonexisting
clock due to copy and paste from another SoC).

> into the manual if these numbers are given by the hardware, though.

The actual numbers don't map to numbers in the datasheet, just to an unordered
list in a table. The list of number is considered part of the DT bindings, and
thus append-only (to be considered in case the datasheet is updated).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Dirk Behme]

Hi Simon,

On 26.05.2016 04:28, Simon Horman wrote:
> Hi Dirk,
>
> On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote:
>> Hi Simon,
>>
>> On 25.05.2016 02:48, Simon Horman wrote:
>>> Hi Dirk,
>>>
>>> On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote:
>>>> Hi Simon,
>>>
>>> [...]
>>>
>>>> With Renesas R-Car3 we will get a whole family of SoCs. I.e. different
>>>> computing power (e.g. different number of Cores) with more or less similar
>>>> peripherals.
>>>>
>>>> I would think that we want to reflect this in the device tree, too.
>>>> Therefore I think what we want is a hierarchy of device trees. Similar
>>>> what's done with other SoC families (compare e.g. i.MX6).
>>>>
>>>> E.g. we want an initial rcar3.dtsi, which contains all common parts of all
>>>> R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc.
>>>>
>>>> Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and
>>>> extends it for SoC specific parts. Which then will be included by the board
>>>> device trees, as already done, now.
>>>>
>>>> Or in other words: As soon as you have similar parts in the r8a779x.dtsi's,
>>>> it's time to think about moving the parts one hierarchy level up into the
>>>> rcar3.dtsi. Else you will end up in a maintenance hell once you have to
>>>> change/fix anything.
>>>
>>> Thanks for raising this issue.
>>>
>>> I agree entirely that we should work towards a situation where maintenance
>>> is as easy as it can be. However, due to the per-SoC binding scheme that
>>> we are using for IP related to Renesas SoCs I suspect that very few DT nodes
>>> can be shared between SoCs verbatim.
>>
>>
>> Could you kindly share an example for this? Looking into the H3 and the M3-W
>> manual, it looks to me that ~90% (?) of the peripherals are the same.
>
> The background is that this is a conversation that has been going around
> for years. The basic thinking is that at this point we have documentation
> that indicates that many hardware blocks on the H3 and M3-W are the same.
> But we do not have insight into the internal versioning of the IP blocks
> nor if they are really the same. And furthermore even if they are currently
> the same we don't really know if that will continue to be the case.
>
> Probably it is. Maybe it isn't. The response has been to take a
> conservative approach to DT bindings to give us the flexibility to update
> the driver implementation to reflect any differences that subsequently
> surface. And by providing per-SoC bindings these driver changes can be
> activated on a per-SoC basis without updating DTB files (which may be
> burned into ROMs).


Sorry, but I don't think that these are good arguments for this kind of 
discussion ;)

The discussion has to be based on facts. And not on "maybe" or 
"probably". The fact is that the documentation tells us that the IPs are 
the same. And the documentation tells us where this isn't the case. This 
is what we can reflect in the code and the device trees.

Or the other way around: I don't ask to not have any SoC specific device 
trees (r8a7795.dtsi, r8a7796.dtsi etc). So we *always* have the option 
to move anything to them, once there might be any difference found or 
documented. But maintaining x (x > 5?) quite similar device trees just 
because there *might* be the possibility that one or two device *might* 
be different doesn't sound like a good argument to me.

Or again, an other way: If I understood correctly, you are working 
already since some time on R-Car, e.g. R-Car Gen2. How many examples do 
you have from the Gen2 family where the IP blocks are different that 
they need to be distinguished in the device tree?


>>> Probably some sort of scheme can be cooked up using preprocessor macros.
>>> And probably there are other ways to resolve this problem. But I would
>>> prefer if we worked towards resolving this maintenance problem in parallel
>>> with rather than as a dependency of merging r8a7796 support into mainline.
>>
>>
>> I'd propose to do it correct from the beginning.
>>
>> Doing it later would either be more work or forgotten, and never be done,
>> then.
>
> I'm sorry but I don't agree. I think that having r8a7796 support
> in mainline is a higher priority than sorting this out.


Looking at the example I gave in

http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013

which took me < 1h to create, I'm not sure what would block us from 
mainlining the r8a7796 *including* this.


>> For a starting point, I'd propose to put the r8a7795.dtsi and r8a7796.dtsi
>> into a graphical diff tool and move all common parts to a rcar3.dtsi (I'd be
>> happy to discuss the name, though)
>
> I'm not opposed to that. But being consistent with my statement above
> I would prefer it to be done as follow-up work.
>
> My suspicion is that right now much of the proposed r8a7796.dtsi can be
> moved into a hypothetical rcar3.dtsi. But that this is because the proposed
> r8a7796.dtsi is very small. I would not expect nearly such a large
> proportion of r8a7795.dtsi to be able to be moved into rcar3.dtsi because
> it enables more hardware blocks and they typically have (or should have in
> keeping with the prevailing policy as described above) per-SoC bindings.


What doesn't prevent us to use a rcar3.dtsi like given in

http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013


Having a rcar3.dtsi gives us *both* options. It doesn't force us to use 
the one or the other. I.e. we have for each IP block the *option* to 
declare it as common (put it onto rcar3.dtsi) *or* SoC specific (put it 
into r8a779x.dtsi).

Without having a common rcar3.dtsi we don't have this option at all.

So I think the conclusion is: Let's have all options (by adding a 
rcar3.dtsi) and then decide for each IP block individually where to 
place it best. Or move it later from the common dtsi to the individual 
dtsi once there is an issue found (what I really doubt that it will 
happen that often, but this is an other topic ;) )


> I believe that there is also a another issue which is that we wish
> to control enabling features on different SoCs once they are known to work.
> Of course things slip through the cracks. But blindly assuming all
> IP blocks enabled for one SoC work on another, even if based on the
> documentation, seems to be asking for trouble to me. For one thing
> it implies that the level of firmware support is the same.
>
> As for a name, I suggest rcar-gen3.dtsi.


Sounds good to me :)


Best regards

Dirk

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Dirk Behme]

On 26.05.2016 09:03, Geert Uytterhoeven wrote:
> Hi Dirk,
>
> On Wed, May 25, 2016 at 9:32 AM, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>> P.S.: This also results in the question why we need similar
>> r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" for
>> the same clocks. Can't we use the same numbers on all SoCs, with just having
>> wholes in the list where the clocks don't exist on a SoC? I haven't looked
>
> The CPG and MSSR block are the IP blocks that differ most among SoCs of the
> same family. Some clocks are present on H3 only, others on M3-W only.


Yes, this is my understanding as well. Is the H3 a superset? And the 
M3-W drops some clocks? Or are there really clocks which are on M3-W 
only and not on H3?


> Having a shared driver core, but different defines, is a compromise between
> reusability and avoiding mistakes in DTSes (e.g. pointing to a nonexisting
> clock due to copy and paste from another SoC).


Sounds like this is a nice additional argument to don't do all this copy 
& paste and have a common rcar3.dtsi, instead :)


>> into the manual if these numbers are given by the hardware, though.
>
> The actual numbers don't map to numbers in the datasheet, just to an unordered
> list in a table. The list of number is considered part of the DT bindings, and
> thus append-only (to be considered in case the datasheet is updated).


Ok, then there should be the option to find a clever way to define the 
clocks common on all SoCs only once. And the clocks which are different 
somehow on top, then.

To take the example from

http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013

this

&scif2 {
	clocks = <&cpg CPG_MOD 310>,
		 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
		 <&scif_clk>;
};

&scif2 {
	clocks = <&cpg CPG_MOD 310>,
		 <&cpg CPG_CORE R8A7796_CLK_S3D1>,
		 <&scif_clk>;
};

should be done better.

Best regards

Dirk

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Geert Uytterhoeven]

Hi Dirk,

On Thu, May 26, 2016 at 9:32 AM, Dirk Behme <dirk.behme@de.bosch.com> wrote:
> On 26.05.2016 09:03, Geert Uytterhoeven wrote:
>> On Wed, May 25, 2016 at 9:32 AM, Dirk Behme <dirk.behme@de.bosch.com>
>> wrote:
>>> P.S.: This also results in the question why we need similar
>>> r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers"
>>> for
>>> the same clocks. Can't we use the same numbers on all SoCs, with just
>>> having
>>> wholes in the list where the clocks don't exist on a SoC? I haven't
>>> looked
>>
>> The CPG and MSSR block are the IP blocks that differ most among SoCs of
>> the
>> same family. Some clocks are present on H3 only, others on M3-W only.
>
> Yes, this is my understanding as well. Is the H3 a superset? And the M3-W
> drops some clocks? Or are there really clocks which are on M3-W only and not
> on H3?

H3 is not a superset.
M3-W e.g. has more S0Dx clocks (for x = 2, 3, 6, 8, 12).

> this
>
> &scif2 {
>         clocks = <&cpg CPG_MOD 310>,
>                  <&cpg CPG_CORE R8A7795_CLK_S3D1>,
>                  <&scif_clk>;
> };
>
> &scif2 {
>         clocks = <&cpg CPG_MOD 310>,
>                  <&cpg CPG_CORE R8A7796_CLK_S3D1>,
>                  <&scif_clk>;
> };
>
> should be done better.

That's a bad example, as both SoCs use S3D1 ;-)

Now look at e.g. i2c:
  - On H3, the parent of the i2c module clock is S3D2,
  - On M3-W, the parent of the i2c module clock is S3D2 for i2c0/1/2,
    and S0D6 for i2c3/4/5/6.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Dirk Behme]

Hi Geert,

On 26.05.2016 10:05, Geert Uytterhoeven wrote:
> Hi Dirk,
>
> On Thu, May 26, 2016 at 9:32 AM, Dirk Behme <dirk.behme@de.bosch.com> wrote:
>> On 26.05.2016 09:03, Geert Uytterhoeven wrote:
>>> On Wed, May 25, 2016 at 9:32 AM, Dirk Behme <dirk.behme@de.bosch.com>
>>> wrote:
>>>> P.S.: This also results in the question why we need similar
>>>> r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers"
>>>> for
>>>> the same clocks. Can't we use the same numbers on all SoCs, with just
>>>> having
>>>> wholes in the list where the clocks don't exist on a SoC? I haven't
>>>> looked
>>>
>>> The CPG and MSSR block are the IP blocks that differ most among SoCs of
>>> the
>>> same family. Some clocks are present on H3 only, others on M3-W only.
>>
>> Yes, this is my understanding as well. Is the H3 a superset? And the M3-W
>> drops some clocks? Or are there really clocks which are on M3-W only and not
>> on H3?
>
> H3 is not a superset.
> M3-W e.g. has more S0Dx clocks (for x = 2, 3, 6, 8, 12).


Ok, thanks!


>> this
>>
>> &scif2 {
>>         clocks = <&cpg CPG_MOD 310>,
>>                  <&cpg CPG_CORE R8A7795_CLK_S3D1>,
>>                  <&scif_clk>;
>> };
>>
>> &scif2 {
>>         clocks = <&cpg CPG_MOD 310>,
>>                  <&cpg CPG_CORE R8A7796_CLK_S3D1>,
>>                  <&scif_clk>;
>> };
>>
>> should be done better.
>
> That's a bad example, as both SoCs use S3D1 ;-)


Then, I'd propose to find a clever way to put the common parts into a 
rcar-gen3.dtsi and ...


> Now look at e.g. i2c:
>   - On H3, the parent of the i2c module clock is S3D2,
>   - On M3-W, the parent of the i2c module clock is S3D2 for i2c0/1/2,
>     and S0D6 for i2c3/4/5/6.


... to keep the differences in the r8a7795.dtsi, r8a7796.dtsi etc.


Best regards

Dirk

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Simon Horman]

On Thu, May 26, 2016 at 09:14:16AM +0200, Dirk Behme wrote:
> Hi Simon,
> 
> On 26.05.2016 04:28, Simon Horman wrote:
> >Hi Dirk,
> >
> >On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote:
> >>Hi Simon,
> >>
> >>On 25.05.2016 02:48, Simon Horman wrote:
> >>>Hi Dirk,
> >>>
> >>>On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote:
> >>>>Hi Simon,
> >>>
> >>>[...]
> >>>
> >>>>With Renesas R-Car3 we will get a whole family of SoCs. I.e. different
> >>>>computing power (e.g. different number of Cores) with more or less similar
> >>>>peripherals.
> >>>>
> >>>>I would think that we want to reflect this in the device tree, too.
> >>>>Therefore I think what we want is a hierarchy of device trees. Similar
> >>>>what's done with other SoC families (compare e.g. i.MX6).
> >>>>
> >>>>E.g. we want an initial rcar3.dtsi, which contains all common parts of all
> >>>>R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc.
> >>>>
> >>>>Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and
> >>>>extends it for SoC specific parts. Which then will be included by the board
> >>>>device trees, as already done, now.
> >>>>
> >>>>Or in other words: As soon as you have similar parts in the r8a779x.dtsi's,
> >>>>it's time to think about moving the parts one hierarchy level up into the
> >>>>rcar3.dtsi. Else you will end up in a maintenance hell once you have to
> >>>>change/fix anything.
> >>>
> >>>Thanks for raising this issue.
> >>>
> >>>I agree entirely that we should work towards a situation where maintenance
> >>>is as easy as it can be. However, due to the per-SoC binding scheme that
> >>>we are using for IP related to Renesas SoCs I suspect that very few DT nodes
> >>>can be shared between SoCs verbatim.
> >>
> >>
> >>Could you kindly share an example for this? Looking into the H3 and the M3-W
> >>manual, it looks to me that ~90% (?) of the peripherals are the same.
> >
> >The background is that this is a conversation that has been going around
> >for years. The basic thinking is that at this point we have documentation
> >that indicates that many hardware blocks on the H3 and M3-W are the same.
> >But we do not have insight into the internal versioning of the IP blocks
> >nor if they are really the same. And furthermore even if they are currently
> >the same we don't really know if that will continue to be the case.
> >
> >Probably it is. Maybe it isn't. The response has been to take a
> >conservative approach to DT bindings to give us the flexibility to update
> >the driver implementation to reflect any differences that subsequently
> >surface. And by providing per-SoC bindings these driver changes can be
> >activated on a per-SoC basis without updating DTB files (which may be
> >burned into ROMs).
> 
> 
> Sorry, but I don't think that these are good arguments for this kind of
> discussion ;)

>From my point of view this is the central point. It is my believe that we
simply do not have enough information to conclude that the IP blocks will
be the same in perpetuity.

> The discussion has to be based on facts. And not on "maybe" or "probably".
> The fact is that the documentation tells us that the IPs are the same. And
> the documentation tells us where this isn't the case. This is what we can
> reflect in the code and the device trees.
> 
> Or the other way around: I don't ask to not have any SoC specific device
> trees (r8a7795.dtsi, r8a7796.dtsi etc). So we *always* have the option to
> move anything to them, once there might be any difference found or
> documented. But maintaining x (x > 5?) quite similar device trees just
> because there *might* be the possibility that one or two device *might* be
> different doesn't sound like a good argument to me.
> 
> Or again, an other way: If I understood correctly, you are working already
> since some time on R-Car, e.g. R-Car Gen2. How many examples do you have
> from the Gen2 family where the IP blocks are different that they need to be
> distinguished in the device tree?

I think the question is different. The question is, if a difference comes
up, how do we handle it?

So far we have a solution. Not an ideal one, but a solution none the less.
I do agree entirely that replicated DTs leads to significant maintenance
overhead. But lets not throw the baby out with the bath water.

> >>>Probably some sort of scheme can be cooked up using preprocessor macros.
> >>>And probably there are other ways to resolve this problem. But I would
> >>>prefer if we worked towards resolving this maintenance problem in parallel
> >>>with rather than as a dependency of merging r8a7796 support into mainline.
> >>
> >>
> >>I'd propose to do it correct from the beginning.
> >>
> >>Doing it later would either be more work or forgotten, and never be done,
> >>then.
> >
> >I'm sorry but I don't agree. I think that having r8a7796 support
> >in mainline is a higher priority than sorting this out.
> 
> 
> Looking at the example I gave in
> 
> http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013
> 
> which took me < 1h to create, I'm not sure what would block us from
> mainlining the r8a7796 *including* this.

Point taken. Lets discuss the change on its merits.

> >>For a starting point, I'd propose to put the r8a7795.dtsi and r8a7796.dtsi
> >>into a graphical diff tool and move all common parts to a rcar3.dtsi (I'd be
> >>happy to discuss the name, though)
> >
> >I'm not opposed to that. But being consistent with my statement above
> >I would prefer it to be done as follow-up work.
> >
> >My suspicion is that right now much of the proposed r8a7796.dtsi can be
> >moved into a hypothetical rcar3.dtsi. But that this is because the proposed
> >r8a7796.dtsi is very small. I would not expect nearly such a large
> >proportion of r8a7795.dtsi to be able to be moved into rcar3.dtsi because
> >it enables more hardware blocks and they typically have (or should have in
> >keeping with the prevailing policy as described above) per-SoC bindings.
> 
> 
> What doesn't prevent us to use a rcar3.dtsi like given in
> 
> http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013
> 
> 
> Having a rcar3.dtsi gives us *both* options. It doesn't force us to use the
> one or the other. I.e. we have for each IP block the *option* to declare it
> as common (put it onto rcar3.dtsi) *or* SoC specific (put it into
> r8a779x.dtsi).
> 
> Without having a common rcar3.dtsi we don't have this option at all.
> 
> So I think the conclusion is: Let's have all options (by adding a
> rcar3.dtsi) and then decide for each IP block individually where to place it
> best. Or move it later from the common dtsi to the individual dtsi once
> there is an issue found (what I really doubt that it will happen that often,
> but this is an other topic ;) )

I think that most of the nodes you have moved into the common dtsi file
make sense. But there are some I am less sure about:

* cpus

  Probably there are some central aspects of cpus that are shared
  between the r8a7795 and r8a7796. And I think that your patch captures
  that. But I also think that there will be non-shared aspects and
  perhaps the complexity of splitting the cpus node between per-SoC
  and common dtsi files isn't worth it.

  I don't feel strongly about this at this point.

  I am also particularly sensitive about enabling CPU features across
  multiple SoCs. But I think that the scheme you propose allows for
  per-SoC control of features in per-SoC dtsi files. So I think
  I am ok about that at this point.

  Lastly, shouldn't the cache-controller go inside the cpu node
  in the common dtsi file to reflect the change recently made
  upstream to r8a7795.dtsi and the structure of r8a7796.dtsi in
  the current patchset (v3).

* cpg, scif2

  This is the compatibility string issue.

  Could we at least agree to defer this part of the discussion
  and thus omit these nodes from the common dtsi file at this time?

  I understand that you are concerned that if we don't handle this
  now it will be forgotten. FWIW I strongly doubt this particular
  problem will be forgotten.

> >I believe that there is also a another issue which is that we wish
> >to control enabling features on different SoCs once they are known to work.
> >Of course things slip through the cracks. But blindly assuming all
> >IP blocks enabled for one SoC work on another, even if based on the
> >documentation, seems to be asking for trouble to me. For one thing
> >it implies that the level of firmware support is the same.
> >
> >As for a name, I suggest rcar-gen3.dtsi.
> 
> 
> Sounds good to me :)
> 
> 
> Best regards
> 
> Dirk
> 
> 
> 
> 

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Geert Uytterhoeven]

On Fri, May 27, 2016 at 2:42 AM, Simon Horman <horms@verge.net.au> wrote:
>   Probably there are some central aspects of cpus that are shared
>   between the r8a7795 and r8a7796. And I think that your patch captures
>   that. But I also think that there will be non-shared aspects and
>   perhaps the complexity of splitting the cpus node between per-SoC
>   and common dtsi files isn't worth it.

R8a7795 and r8a7796 have different numbers of CPU cores, and different
maximum frequencies, thus needing different operating-point properties.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Dirk Behme]

Hi Simon,

On 27.05.2016 02:42, Simon Horman wrote:
> On Thu, May 26, 2016 at 09:14:16AM +0200, Dirk Behme wrote:
>> Hi Simon,
>>
>> On 26.05.2016 04:28, Simon Horman wrote:
>>> Hi Dirk,
>>>
>>> On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote:
>>>> Hi Simon,
>>>>
>>>> On 25.05.2016 02:48, Simon Horman wrote:
>>>>> Hi Dirk,
>>>>>
>>>>> On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote:
>>>>>> Hi Simon,
>>>>>
>>>>> [...]
>>>>>
>>>>>> With Renesas R-Car3 we will get a whole family of SoCs. I.e. different
>>>>>> computing power (e.g. different number of Cores) with more or less similar
>>>>>> peripherals.
>>>>>>
>>>>>> I would think that we want to reflect this in the device tree, too.
>>>>>> Therefore I think what we want is a hierarchy of device trees. Similar
>>>>>> what's done with other SoC families (compare e.g. i.MX6).
>>>>>>
>>>>>> E.g. we want an initial rcar3.dtsi, which contains all common parts of all
>>>>>> R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc.
>>>>>>
>>>>>> Then you will have the r8a779x.dtsi which includes the rcar3.dtsi and
>>>>>> extends it for SoC specific parts. Which then will be included by the board
>>>>>> device trees, as already done, now.
>>>>>>
>>>>>> Or in other words: As soon as you have similar parts in the r8a779x.dtsi's,
>>>>>> it's time to think about moving the parts one hierarchy level up into the
>>>>>> rcar3.dtsi. Else you will end up in a maintenance hell once you have to
>>>>>> change/fix anything.
>>>>>
>>>>> Thanks for raising this issue.
>>>>>
>>>>> I agree entirely that we should work towards a situation where maintenance
>>>>> is as easy as it can be. However, due to the per-SoC binding scheme that
>>>>> we are using for IP related to Renesas SoCs I suspect that very few DT nodes
>>>>> can be shared between SoCs verbatim.
>>>>
>>>>
>>>> Could you kindly share an example for this? Looking into the H3 and the M3-W
>>>> manual, it looks to me that ~90% (?) of the peripherals are the same.
>>>
>>> The background is that this is a conversation that has been going around
>>> for years. The basic thinking is that at this point we have documentation
>>> that indicates that many hardware blocks on the H3 and M3-W are the same.
>>> But we do not have insight into the internal versioning of the IP blocks
>>> nor if they are really the same. And furthermore even if they are currently
>>> the same we don't really know if that will continue to be the case.
>>>
>>> Probably it is. Maybe it isn't. The response has been to take a
>>> conservative approach to DT bindings to give us the flexibility to update
>>> the driver implementation to reflect any differences that subsequently
>>> surface. And by providing per-SoC bindings these driver changes can be
>>> activated on a per-SoC basis without updating DTB files (which may be
>>> burned into ROMs).
>>
>>
>> Sorry, but I don't think that these are good arguments for this kind of
>> discussion ;)
>
>>From my point of view this is the central point. It is my believe that we
> simply do not have enough information to conclude that the IP blocks will
> be the same in perpetuity.
>
>> The discussion has to be based on facts. And not on "maybe" or "probably".
>> The fact is that the documentation tells us that the IPs are the same. And
>> the documentation tells us where this isn't the case. This is what we can
>> reflect in the code and the device trees.
>>
>> Or the other way around: I don't ask to not have any SoC specific device
>> trees (r8a7795.dtsi, r8a7796.dtsi etc). So we *always* have the option to
>> move anything to them, once there might be any difference found or
>> documented. But maintaining x (x > 5?) quite similar device trees just
>> because there *might* be the possibility that one or two device *might* be
>> different doesn't sound like a good argument to me.
>>
>> Or again, an other way: If I understood correctly, you are working already
>> since some time on R-Car, e.g. R-Car Gen2. How many examples do you have
>> from the Gen2 family where the IP blocks are different that they need to be
>> distinguished in the device tree?
>
> I think the question is different. The question is, if a difference comes
> up, how do we handle it?
>
> So far we have a solution. Not an ideal one, but a solution none the less.
> I do agree entirely that replicated DTs leads to significant maintenance
> overhead. But lets not throw the baby out with the bath water.


Well, we could continue this kind of discussion infinite ;)

But I agree to your below point "Lets discuss the change on its merits" 
and therefore stop here and continue with the technical aspects below ....


>>>>> Probably some sort of scheme can be cooked up using preprocessor macros.
>>>>> And probably there are other ways to resolve this problem. But I would
>>>>> prefer if we worked towards resolving this maintenance problem in parallel
>>>>> with rather than as a dependency of merging r8a7796 support into mainline.
>>>>
>>>>
>>>> I'd propose to do it correct from the beginning.
>>>>
>>>> Doing it later would either be more work or forgotten, and never be done,
>>>> then.
>>>
>>> I'm sorry but I don't agree. I think that having r8a7796 support
>>> in mainline is a higher priority than sorting this out.
>>
>>
>> Looking at the example I gave in
>>
>> http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013
>>
>> which took me < 1h to create, I'm not sure what would block us from
>> mainlining the r8a7796 *including* this.
>
> Point taken. Lets discuss the change on its merits.


I totally agree, thanks! Let's continue below ...


>>>> For a starting point, I'd propose to put the r8a7795.dtsi and r8a7796.dtsi
>>>> into a graphical diff tool and move all common parts to a rcar3.dtsi (I'd be
>>>> happy to discuss the name, though)
>>>
>>> I'm not opposed to that. But being consistent with my statement above
>>> I would prefer it to be done as follow-up work.
>>>
>>> My suspicion is that right now much of the proposed r8a7796.dtsi can be
>>> moved into a hypothetical rcar3.dtsi. But that this is because the proposed
>>> r8a7796.dtsi is very small. I would not expect nearly such a large
>>> proportion of r8a7795.dtsi to be able to be moved into rcar3.dtsi because
>>> it enables more hardware blocks and they typically have (or should have in
>>> keeping with the prevailing policy as described above) per-SoC bindings.
>>
>>
>> What doesn't prevent us to use a rcar3.dtsi like given in
>>
>> http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013
>>
>>
>> Having a rcar3.dtsi gives us *both* options. It doesn't force us to use the
>> one or the other. I.e. we have for each IP block the *option* to declare it
>> as common (put it onto rcar3.dtsi) *or* SoC specific (put it into
>> r8a779x.dtsi).
>>
>> Without having a common rcar3.dtsi we don't have this option at all.
>>
>> So I think the conclusion is: Let's have all options (by adding a
>> rcar3.dtsi) and then decide for each IP block individually where to place it
>> best. Or move it later from the common dtsi to the individual dtsi once
>> there is an issue found (what I really doubt that it will happen that often,
>> but this is an other topic ;) )
>
> I think that most of the nodes you have moved into the common dtsi file
> make sense. But there are some I am less sure about:
>
> * cpus
>
>   Probably there are some central aspects of cpus that are shared
>   between the r8a7795 and r8a7796. And I think that your patch captures
>   that. But I also think that there will be non-shared aspects and
>   perhaps the complexity of splitting the cpus node between per-SoC
>   and common dtsi files isn't worth it.
>
>   I don't feel strongly about this at this point.
>
>   I am also particularly sensitive about enabling CPU features across
>   multiple SoCs. But I think that the scheme you propose allows for
>   per-SoC control of features in per-SoC dtsi files. So I think
>   I am ok about that at this point.
>
>   Lastly, shouldn't the cache-controller go inside the cpu node
>   in the common dtsi file to reflect the change recently made
>   upstream to r8a7795.dtsi and the structure of r8a7796.dtsi in
>   the current patchset (v3).


We already talked about that in an other thread, and I think I missed 
that change you mentioned. So I'm fine with your proposal. I just saw 
that it's different between r8a7795 and r8a7796 and wanted to highlight 
that it should be the same.


> * cpg, scif2
>
>   This is the compatibility string issue.
>
>   Could we at least agree to defer this part of the discussion
>   and thus omit these nodes from the common dtsi file at this time?


Fine with me :)


>   I understand that you are concerned that if we don't handle this
>   now it will be forgotten. FWIW I strongly doubt this particular
>   problem will be forgotten.


Ok.

Thanks!


Best regards

Dirk

[PATCH v3 0/3] arm64: Add Renesas R8A7796 SoC support

[Simon Horman]

On Tue, May 24, 2016 at 10:54:37AM +0900, Simon Horman wrote:
> Hi,
> 
> this short series aims to add basic support for the
> Gen 3 R-Car M3-W (r8a7796) SoC.
> 
> It has few bells and whistles but is sufficient to bring up
> an r8a7795/salvator-x. I have provided a boot-log at the bottom
> of this email in case it is of interest.
> 
> 
> Dependency:
> 
> "[PATCH 0/4] clk: renesas: cpg-mssr: Add support for R-Car M3-W"
> 
> 
> Availability:
> 
> In order to aid review this series, its dependency (above)
> and the related patch "serial: sh-sci: Document SoC specific bindings for
> r8a7796", which has been posted separately, are available at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/r8a7796-v3
> 
> To be entirely clear, at the time of writing I have _not_ queued up this
> series for mainline.

I have queued this up for v4.8.


I acknowledge that there has been some discussion of sharing DT between
the r8a7795 and r8a7796. However it is my considered opinion that the level
of duplication in the approach taken by this patchset is in keeping with
the practice already used in the tree. And that material benefits in terms
of ease of maintenance can only be realised with a solution that goes
beyond breaking common nodes into a shared dtsi file.

It is my request that my decision as co-maintainer of the files
in question be respected.

[PATCH v3 0/3] arm64: Add Renesas R8A7796 SoC support

[Simon Horman]

On Mon, Jun 06, 2016 at 10:33:45AM +0900, Simon Horman wrote:
> On Tue, May 24, 2016 at 10:54:37AM +0900, Simon Horman wrote:
> > Hi,
> > 
> > this short series aims to add basic support for the
> > Gen 3 R-Car M3-W (r8a7796) SoC.
> > 
> > It has few bells and whistles but is sufficient to bring up
> > an r8a7795/salvator-x. I have provided a boot-log at the bottom
> > of this email in case it is of interest.
> > 
> > 
> > Dependency:
> > 
> > "[PATCH 0/4] clk: renesas: cpg-mssr: Add support for R-Car M3-W"
> > 
> > 
> > Availability:
> > 
> > In order to aid review this series, its dependency (above)
> > and the related patch "serial: sh-sci: Document SoC specific bindings for
> > r8a7796", which has been posted separately, are available at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/r8a7796-v3
> > 
> > To be entirely clear, at the time of writing I have _not_ queued up this
> > series for mainline.
> 
> I have queued this up for v4.8.
> 
> 
> I acknowledge that there has been some discussion of sharing DT between
> the r8a7795 and r8a7796. However it is my considered opinion that the level
> of duplication in the approach taken by this patchset is in keeping with
> the practice already used in the tree. And that material benefits in terms
> of ease of maintenance can only be realised with a solution that goes
> beyond breaking common nodes into a shared dtsi file.
> 
> It is my request that my decision as co-maintainer of the files
> in question be respected.

Bother, I spoke to soon.

There is a compile-time dependency on 8a7796-cpg-mssr.h
so "[PATCH 0/4] clk: renesas: cpg-mssr: Add support for R-Car M3-W"
needs to be present. I have deferred these patches pending that.

[PATCH v3 0/3] arm64: Add Renesas R8A7796 SoC support

[Simon Horman]

On Mon, Jun 06, 2016 at 10:52:01AM +0900, Simon Horman wrote:
> On Mon, Jun 06, 2016 at 10:33:45AM +0900, Simon Horman wrote:
> > On Tue, May 24, 2016 at 10:54:37AM +0900, Simon Horman wrote:
> > > Hi,
> > > 
> > > this short series aims to add basic support for the
> > > Gen 3 R-Car M3-W (r8a7796) SoC.
> > > 
> > > It has few bells and whistles but is sufficient to bring up
> > > an r8a7795/salvator-x. I have provided a boot-log at the bottom
> > > of this email in case it is of interest.
> > > 
> > > 
> > > Dependency:
> > > 
> > > "[PATCH 0/4] clk: renesas: cpg-mssr: Add support for R-Car M3-W"
> > > 
> > > 
> > > Availability:
> > > 
> > > In order to aid review this series, its dependency (above)
> > > and the related patch "serial: sh-sci: Document SoC specific bindings for
> > > r8a7796", which has been posted separately, are available at:
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/r8a7796-v3
> > > 
> > > To be entirely clear, at the time of writing I have _not_ queued up this
> > > series for mainline.
> > 
> > I have queued this up for v4.8.
> > 
> > 
> > I acknowledge that there has been some discussion of sharing DT between
> > the r8a7795 and r8a7796. However it is my considered opinion that the level
> > of duplication in the approach taken by this patchset is in keeping with
> > the practice already used in the tree. And that material benefits in terms
> > of ease of maintenance can only be realised with a solution that goes
> > beyond breaking common nodes into a shared dtsi file.
> > 
> > It is my request that my decision as co-maintainer of the files
> > in question be respected.
> 
> Bother, I spoke to soon.
> 
> There is a compile-time dependency on 8a7796-cpg-mssr.h
> so "[PATCH 0/4] clk: renesas: cpg-mssr: Add support for R-Car M3-W"
> needs to be present. I have deferred these patches pending that.

I have requeued this on top of
"clk: renesas: Add r8a7796 CPG Core Clock Definitions"

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Dirk Behme]

Hi Simon,

On 27.05.2016 09:32, Dirk Behme wrote:
> Hi Simon,
>
> On 27.05.2016 02:42, Simon Horman wrote:
>> On Thu, May 26, 2016 at 09:14:16AM +0200, Dirk Behme wrote:
>>> Hi Simon,
>>>
>>> On 26.05.2016 04:28, Simon Horman wrote:
>>>> Hi Dirk,
>>>>
>>>> On Wed, May 25, 2016 at 07:10:26AM +0200, Dirk Behme wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On 25.05.2016 02:48, Simon Horman wrote:
>>>>>> Hi Dirk,
>>>>>>
>>>>>> On Tue, May 24, 2016 at 07:30:17AM +0200, Dirk Behme wrote:
>>>>>>> Hi Simon,
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> With Renesas R-Car3 we will get a whole family of SoCs. I.e.
>>>>>>> different
>>>>>>> computing power (e.g. different number of Cores) with more or
>>>>>>> less similar
>>>>>>> peripherals.
>>>>>>>
>>>>>>> I would think that we want to reflect this in the device tree, too.
>>>>>>> Therefore I think what we want is a hierarchy of device trees.
>>>>>>> Similar
>>>>>>> what's done with other SoC families (compare e.g. i.MX6).
>>>>>>>
>>>>>>> E.g. we want an initial rcar3.dtsi, which contains all common
>>>>>>> parts of all
>>>>>>> R-Car3 SoCs. E.g. one CA57 core, the SCIF where its common etc.
>>>>>>>
>>>>>>> Then you will have the r8a779x.dtsi which includes the rcar3.dtsi
>>>>>>> and
>>>>>>> extends it for SoC specific parts. Which then will be included by
>>>>>>> the board
>>>>>>> device trees, as already done, now.
>>>>>>>
>>>>>>> Or in other words: As soon as you have similar parts in the
>>>>>>> r8a779x.dtsi's,
>>>>>>> it's time to think about moving the parts one hierarchy level up
>>>>>>> into the
>>>>>>> rcar3.dtsi. Else you will end up in a maintenance hell once you
>>>>>>> have to
>>>>>>> change/fix anything.
>>>>>>
>>>>>> Thanks for raising this issue.
>>>>>>
>>>>>> I agree entirely that we should work towards a situation where
>>>>>> maintenance
>>>>>> is as easy as it can be. However, due to the per-SoC binding
>>>>>> scheme that
>>>>>> we are using for IP related to Renesas SoCs I suspect that very
>>>>>> few DT nodes
>>>>>> can be shared between SoCs verbatim.
>>>>>
>>>>>
>>>>> Could you kindly share an example for this? Looking into the H3 and
>>>>> the M3-W
>>>>> manual, it looks to me that ~90% (?) of the peripherals are the same.
>>>>
>>>> The background is that this is a conversation that has been going
>>>> around
>>>> for years. The basic thinking is that at this point we have
>>>> documentation
>>>> that indicates that many hardware blocks on the H3 and M3-W are the
>>>> same.
>>>> But we do not have insight into the internal versioning of the IP
>>>> blocks
>>>> nor if they are really the same. And furthermore even if they are
>>>> currently
>>>> the same we don't really know if that will continue to be the case.
>>>>
>>>> Probably it is. Maybe it isn't. The response has been to take a
>>>> conservative approach to DT bindings to give us the flexibility to
>>>> update
>>>> the driver implementation to reflect any differences that subsequently
>>>> surface. And by providing per-SoC bindings these driver changes can be
>>>> activated on a per-SoC basis without updating DTB files (which may be
>>>> burned into ROMs).
>>>
>>>
>>> Sorry, but I don't think that these are good arguments for this kind of
>>> discussion ;)
>>
>>> From my point of view this is the central point. It is my believe
>>> that we
>> simply do not have enough information to conclude that the IP blocks will
>> be the same in perpetuity.
>>
>>> The discussion has to be based on facts. And not on "maybe" or
>>> "probably".
>>> The fact is that the documentation tells us that the IPs are the
>>> same. And
>>> the documentation tells us where this isn't the case. This is what we
>>> can
>>> reflect in the code and the device trees.
>>>
>>> Or the other way around: I don't ask to not have any SoC specific device
>>> trees (r8a7795.dtsi, r8a7796.dtsi etc). So we *always* have the
>>> option to
>>> move anything to them, once there might be any difference found or
>>> documented. But maintaining x (x > 5?) quite similar device trees just
>>> because there *might* be the possibility that one or two device
>>> *might* be
>>> different doesn't sound like a good argument to me.
>>>
>>> Or again, an other way: If I understood correctly, you are working
>>> already
>>> since some time on R-Car, e.g. R-Car Gen2. How many examples do you have
>>> from the Gen2 family where the IP blocks are different that they need
>>> to be
>>> distinguished in the device tree?
>>
>> I think the question is different. The question is, if a difference comes
>> up, how do we handle it?
>>
>> So far we have a solution. Not an ideal one, but a solution none the
>> less.
>> I do agree entirely that replicated DTs leads to significant maintenance
>> overhead. But lets not throw the baby out with the bath water.
>
>
> Well, we could continue this kind of discussion infinite ;)
>
> But I agree to your below point "Lets discuss the change on its merits"
> and therefore stop here and continue with the technical aspects below ....
>
>
>>>>>> Probably some sort of scheme can be cooked up using preprocessor
>>>>>> macros.
>>>>>> And probably there are other ways to resolve this problem. But I
>>>>>> would
>>>>>> prefer if we worked towards resolving this maintenance problem in
>>>>>> parallel
>>>>>> with rather than as a dependency of merging r8a7796 support into
>>>>>> mainline.
>>>>>
>>>>>
>>>>> I'd propose to do it correct from the beginning.
>>>>>
>>>>> Doing it later would either be more work or forgotten, and never be
>>>>> done,
>>>>> then.
>>>>
>>>> I'm sorry but I don't agree. I think that having r8a7796 support
>>>> in mainline is a higher priority than sorting this out.
>>>
>>>
>>> Looking at the example I gave in
>>>
>>> http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013
>>>
>>> which took me < 1h to create, I'm not sure what would block us from
>>> mainlining the r8a7796 *including* this.
>>
>> Point taken. Lets discuss the change on its merits.
>
>
> I totally agree, thanks! Let's continue below ...
>
>
>>>>> For a starting point, I'd propose to put the r8a7795.dtsi and
>>>>> r8a7796.dtsi
>>>>> into a graphical diff tool and move all common parts to a
>>>>> rcar3.dtsi (I'd be
>>>>> happy to discuss the name, though)
>>>>
>>>> I'm not opposed to that. But being consistent with my statement above
>>>> I would prefer it to be done as follow-up work.
>>>>
>>>> My suspicion is that right now much of the proposed r8a7796.dtsi can be
>>>> moved into a hypothetical rcar3.dtsi. But that this is because the
>>>> proposed
>>>> r8a7796.dtsi is very small. I would not expect nearly such a large
>>>> proportion of r8a7795.dtsi to be able to be moved into rcar3.dtsi
>>>> because
>>>> it enables more hardware blocks and they typically have (or should
>>>> have in
>>>> keeping with the prevailing policy as described above) per-SoC
>>>> bindings.
>>>
>>>
>>> What doesn't prevent us to use a rcar3.dtsi like given in
>>>
>>> http://article.gmane.org/gmane.linux.kernel.renesas-soc/4013
>>>
>>>
>>> Having a rcar3.dtsi gives us *both* options. It doesn't force us to
>>> use the
>>> one or the other. I.e. we have for each IP block the *option* to
>>> declare it
>>> as common (put it onto rcar3.dtsi) *or* SoC specific (put it into
>>> r8a779x.dtsi).
>>>
>>> Without having a common rcar3.dtsi we don't have this option at all.
>>>
>>> So I think the conclusion is: Let's have all options (by adding a
>>> rcar3.dtsi) and then decide for each IP block individually where to
>>> place it
>>> best. Or move it later from the common dtsi to the individual dtsi once
>>> there is an issue found (what I really doubt that it will happen that
>>> often,
>>> but this is an other topic ;) )
>>
>> I think that most of the nodes you have moved into the common dtsi file
>> make sense. But there are some I am less sure about:
>>
>> * cpus
>>
>>   Probably there are some central aspects of cpus that are shared
>>   between the r8a7795 and r8a7796. And I think that your patch captures
>>   that. But I also think that there will be non-shared aspects and
>>   perhaps the complexity of splitting the cpus node between per-SoC
>>   and common dtsi files isn't worth it.
>>
>>   I don't feel strongly about this at this point.
>>
>>   I am also particularly sensitive about enabling CPU features across
>>   multiple SoCs. But I think that the scheme you propose allows for
>>   per-SoC control of features in per-SoC dtsi files. So I think
>>   I am ok about that at this point.
>>
>>   Lastly, shouldn't the cache-controller go inside the cpu node
>>   in the common dtsi file to reflect the change recently made
>>   upstream to r8a7795.dtsi and the structure of r8a7796.dtsi in
>>   the current patchset (v3).
>
>
> We already talked about that in an other thread, and I think I missed
> that change you mentioned. So I'm fine with your proposal. I just saw
> that it's different between r8a7795 and r8a7796 and wanted to highlight
> that it should be the same.
>
>
>> * cpg, scif2
>>
>>   This is the compatibility string issue.
>>
>>   Could we at least agree to defer this part of the discussion
>>   and thus omit these nodes from the common dtsi file at this time?
>
>
> Fine with me :)
>
>
>>   I understand that you are concerned that if we don't handle this
>>   now it will be forgotten. FWIW I strongly doubt this particular
>>   problem will be forgotten.
>
>
> Ok.
>
> Thanks!


Hmm, could you kindly help me to remember what's the recent status of 
your discussion above regarding a hierarchical structure of the RCar3 
device trees?


Best regards

Dirk

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Simon Horman]

On Wed, Jun 29, 2016 at 10:15:27AM +0200, Dirk Behme wrote:
> Hi Simon,

...

> Hmm, could you kindly help me to remember what's the recent status of your
> discussion above regarding a hierarchical structure of the RCar3 device
> trees?

Hi Dirk,

>From my point of view the most promising avenue at this time is work that
Geert has been doing to explore making things more flexible by updating the
DT automatically at run time. He can expand on this but the idea is to add
per-soc compat strings and otherwise update the DT into a per-SoC version.
This ought to allow significant portions of the DT to be common between
SoCs in the same R-Car generation for at lest Gen 2 and Gen 3.

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Dirk Behme]

Hi Simon,

On 21.07.2016 01:51, Simon Horman wrote:
> On Wed, Jun 29, 2016 at 10:15:27AM +0200, Dirk Behme wrote:
>> Hi Simon,
>
> ...
>
>> Hmm, could you kindly help me to remember what's the recent status of your
>> discussion above regarding a hierarchical structure of the RCar3 device
>> trees?
>
> Hi Dirk,
>
>>From my point of view the most promising avenue at this time is work that
> Geert has been doing to explore making things more flexible by updating the
> DT automatically at run time. He can expand on this but the idea is to add
> per-soc compat strings and otherwise update the DT into a per-SoC version.
> This ought to allow significant portions of the DT to be common between
> SoCs in the same R-Car generation for at lest Gen 2 and Gen 3.


There are two topics:

a) Hierarchical static structure of devices trees and clock definitions 
for RCar3 SoCs
b) Detecting of RCar3 SoC type and engineering sample revisions at runtime

About which topic do you talk here? I think we shouldn't mix them.

Best regards

Dirk

P.S.: If you like, we could have a chat in #renesas-soc, too :)

[PATCH v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support

[Simon Horman]

Hi Dirk,

On Thu, Jul 21, 2016 at 07:20:30AM +0200, Dirk Behme wrote:
> Hi Simon,
> 
> On 21.07.2016 01:51, Simon Horman wrote:
> >On Wed, Jun 29, 2016 at 10:15:27AM +0200, Dirk Behme wrote:
> >>Hi Simon,
> >
> >...
> >
> >>Hmm, could you kindly help me to remember what's the recent status of your
> >>discussion above regarding a hierarchical structure of the RCar3 device
> >>trees?
> >
> >Hi Dirk,
> >
> >>From my point of view the most promising avenue at this time is work that
> >Geert has been doing to explore making things more flexible by updating the
> >DT automatically at run time. He can expand on this but the idea is to add
> >per-soc compat strings and otherwise update the DT into a per-SoC version.
> >This ought to allow significant portions of the DT to be common between
> >SoCs in the same R-Car generation for at lest Gen 2 and Gen 3.
> 
> 
> There are two topics:
> 
> a) Hierarchical static structure of devices trees and clock definitions for
> RCar3 SoCs
> b) Detecting of RCar3 SoC type and engineering sample revisions at runtime
> 
> About which topic do you talk here? I think we shouldn't mix them.

I was referring to topic a) which I would describe as consolidation of
static DT descriptions.  However, I believe that the same or a similar
approach to DT fixups can also be used for problem b). I agree
we should discuss these topics separately.

> Best regards
> 
> Dirk
> 
> P.S.: If you like, we could have a chat in #renesas-soc, too :)

Sure. In general I am there when I am at my desk and not completely
consumed by work at hand.