[PATCH 00/04] ARM: shmobile: r8a73a4 SoC and APE6EVM board support

[PATCH 00/04] ARM: shmobile: r8a73a4 SoC and APE6EVM board support

[Magnus Damm]

ARM: shmobile: r8a73a4 SoC and APE6EVM board support

[PATCH 01/04] ARM: shmobile: Initial r8a73a4 SoC support
[PATCH 02/04] ARM: shmobile: r8a73a4 SCIF support
[PATCH 03/04] ARM: shmobile: r8a73a4 IRQC support
[PATCH 04/04] ARM: shmobile: APE6EVM support

This series adds initial support for r8a73a4 and APE6EVM. The SoC
is known as r8a73a4 which is built around Cortex-A15 and makes use
of SCIF for serial and IRQC interrupt controller for external IRQs.

This initial SoC and board support is providing limited DT-only
support and a very basic C-version of board support. In the future
improved PINCTRL and clock framework support will be added, followed
by SMP support.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 Written against all+next in renesas.git.
 [PATCH 03/04] requires the IRQC driver to build

 arch/arm/boot/dts/Makefile                    |    1 
 arch/arm/boot/dts/r8a73a4-ape6evm.dts         |   26 ++
 arch/arm/boot/dts/r8a73a4.dtsi                |   87 ++++++++
 arch/arm/mach-shmobile/Kconfig                |   16 +
 arch/arm/mach-shmobile/Makefile               |    2 
 arch/arm/mach-shmobile/board-ape6evm.c        |   40 +++
 arch/arm/mach-shmobile/clock-r8a73a4.c        |  104 +++++++++
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |    7 
 arch/arm/mach-shmobile/setup-r8a73a4.c        |  268 +++++++++++++++++++++++++
 9 files changed, 549 insertions(+), 2 deletions(-)

[PATCH 01/04] ARM: shmobile: Initial r8a73a4 SoC support

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Add initial support for the r8a73a4 SoC including:
 - Single Cortex-A15 CPU Core
 - GIC
 - Architecture timer

No static virtual mappings are used, all the components
make use of ioremap().

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/boot/dts/r8a73a4.dtsi                |   55 +++++++++++++++
 arch/arm/mach-shmobile/Kconfig                |    7 +
 arch/arm/mach-shmobile/Makefile               |    1 
 arch/arm/mach-shmobile/clock-r8a73a4.c        |   89 +++++++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/r8a73a4.h |    7 +
 arch/arm/mach-shmobile/setup-r8a73a4.c        |   56 +++++++++++++++
 6 files changed, 215 insertions(+)

--- /dev/null
+++ work/arch/arm/boot/dts/r8a73a4.dtsi	2013-03-12 13:33:33.000000000 +0900
@@ -0,0 +1,55 @@
+/*
+ * Device Tree Source for the r8a73a4 SoC
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Magnus Damm
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+	compatible = "renesas,r8a73a4";
+	interrupt-parent = <&gic>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+			clock-frequency = <1500000000>;
+		};
+	};
+
+	gic: interrupt-controller at f1001000 {
+		compatible = "arm,cortex-a15-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0xf1001000 0x1000>,
+			<0xf1002000 0x1000>,
+			<0xf1004000 0x2000>,
+			<0xf1006000 0x2000>;
+		interrupts = <1 9 0xf04>;
+
+		gic-cpuif at 4 {
+			compatible = "arm,gic-cpuif";
+			cpuif-id = <4>;
+			cpu = <&cpu0>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 13 0xf08>,
+				<1 14 0xf08>,
+				<1 11 0xf08>,
+				<1 10 0xf08>;
+	};
+};
--- 0001/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-03-12 12:47:46.000000000 +0900
@@ -18,6 +18,13 @@ config ARCH_SH73A0
 	select SH_CLK_CPG
 	select RENESAS_INTC_IRQPIN
 
+config ARCH_R8A73A4
+	bool "R-Mobile APE6 (R8A73A40)"
+	select ARM_GIC
+	select CPU_V7
+	select ARM_ARCH_TIMER
+	select SH_CLK_CPG
+
 config ARCH_R8A7740
 	bool "R-Mobile A1 (R8A77400)"
 	select ARCH_WANT_OPTIONAL_GPIOLIB
--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-03-12 12:47:46.000000000 +0900
@@ -8,6 +8,7 @@ obj-y				:= timer.o console.o clock.o
 # CPU objects
 obj-$(CONFIG_ARCH_SH7372)	+= setup-sh7372.o clock-sh7372.o intc-sh7372.o
 obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o clock-sh73a0.o intc-sh73a0.o
+obj-$(CONFIG_ARCH_R8A73A4)	+= setup-r8a73a4.o clock-r8a73a4.o
 obj-$(CONFIG_ARCH_R8A7740)	+= setup-r8a7740.o clock-r8a7740.o intc-r8a7740.o
 obj-$(CONFIG_ARCH_R8A7779)	+= setup-r8a7779.o clock-r8a7779.o intc-r8a7779.o
 obj-$(CONFIG_ARCH_EMEV2)	+= setup-emev2.o clock-emev2.o
--- /dev/null
+++ work/arch/arm/mach-shmobile/clock-r8a73a4.c	2013-03-12 13:33:57.000000000 +0900
@@ -0,0 +1,89 @@
+/*
+ * r8a73a4 clock framework support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/sh_clk.h>
+#include <linux/clkdev.h>
+#include <mach/common.h>
+
+#define CPG_BASE 0xe6150000
+#define CPG_LEN 0x270
+
+#define MPCKCR 0xe6150080
+
+static struct clk_mapping cpg_mapping = {
+	.phys   = CPG_BASE,
+	.len    = CPG_LEN,
+};
+
+static struct clk extalr_clk = {
+	.rate	= 32768,
+};
+
+static struct clk extal1_clk = {
+	.rate	= 26000000,
+};
+
+static struct clk extal2_clk = {
+	.rate	= 48000000,
+	.mapping	= &cpg_mapping,
+};
+
+static struct clk *main_clks[] = {
+	&extalr_clk,
+	&extal1_clk,
+	&extal2_clk,
+};
+
+enum { MSTP_NR };
+static struct clk mstp_clks[MSTP_NR] = {
+};
+
+static struct clk_lookup lookups[] = {
+};
+
+void __init r8a73a4_clock_init(void)
+{
+	void __iomem *cpg_base, *reg;
+	int k, ret = 0;
+
+	/* fix MPCLK to EXTAL2 for now.
+	 * this is needed until more detailed clock topology is supported
+	 */
+	cpg_base = ioremap_nocache(CPG_BASE, CPG_LEN);
+	BUG_ON(!cpg_base);
+	reg = cpg_base + (MPCKCR - CPG_BASE);
+	iowrite32(ioread32(reg) | 1 << 7 | 0x0c, reg); /* set CKSEL */
+	iounmap(cpg_base);
+
+	for (k = 0; !ret && (k < ARRAY_SIZE(main_clks)); k++)
+		ret = clk_register(main_clks[k]);
+
+	if (!ret)
+		ret = sh_clk_mstp_register(mstp_clks, MSTP_NR);
+
+	clkdev_add_table(lookups, ARRAY_SIZE(lookups));
+
+	if (!ret)
+		shmobile_clk_init();
+	else
+		panic("failed to setup r8a73a4 clocks\n");
+}
--- /dev/null
+++ work/arch/arm/mach-shmobile/include/mach/r8a73a4.h	2013-03-12 12:47:47.000000000 +0900
@@ -0,0 +1,7 @@
+#ifndef __ASM_R8A73A4_H__
+#define __ASM_R8A73A4_H__
+
+void r8a73a4_add_standard_devices(void);
+void r8a73a4_clock_init(void);
+
+#endif /* __ASM_R8A73A4_H__ */
--- /dev/null
+++ work/arch/arm/mach-shmobile/setup-r8a73a4.c	2013-03-12 12:47:47.000000000 +0900
@@ -0,0 +1,56 @@
+/*
+ * r8a73a4 processor support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+#include <linux/kernel.h>
+#include <linux/irqchip.h>
+#include <linux/of_platform.h>
+#include <linux/irq.h>
+#include <mach/common.h>
+#include <mach/irqs.h>
+#include <mach/r8a73a4.h>
+#include <asm/mach/arch.h>
+
+static struct platform_device *r8a73a4_devices[] __initdata = {
+};
+
+void __init r8a73a4_add_standard_devices(void)
+{
+	r8a73a4_clock_init();
+
+	platform_add_devices(r8a73a4_devices, ARRAY_SIZE(r8a73a4_devices));
+}
+
+#ifdef CONFIG_USE_OF
+void __init r8a73a4_add_standard_devices_dt(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *r8a73a4_boards_compat_dt[] __initdata = {
+	"renesas,r8a73a4",
+	NULL,
+};
+
+DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
+	.init_irq	= irqchip_init,
+	.init_machine	= r8a73a4_add_standard_devices_dt,
+	.init_time	= shmobile_timer_init,
+	.dt_compat	= r8a73a4_boards_compat_dt,
+MACHINE_END
+#endif /* CONFIG_USE_OF */

[PATCH 02/04] ARM: shmobile: r8a73a4 SCIF support

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Add SCIF serial port support to the r8a73a4 SoC by
adding platform devices for SCIFA0 -> SCIFA1 as well
as SCIFB0 -> SCIFB3 together with clock bindings. DT
device description is excluded at this point since
such bindings are still under development.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/mach-shmobile/clock-r8a73a4.c |   15 +++-
 arch/arm/mach-shmobile/setup-r8a73a4.c |  115 ++++++++++++++++++++++++++++++++
 2 files changed, 129 insertions(+), 1 deletion(-)

--- 0002/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ work/arch/arm/mach-shmobile/clock-r8a73a4.c	2013-03-12 12:49:35.000000000 +0900
@@ -28,6 +28,7 @@
 #define CPG_LEN 0x270
 
 #define MPCKCR 0xe6150080
+#define SMSTPCR2 0xe6150138
 
 static struct clk_mapping cpg_mapping = {
 	.phys   = CPG_BASE,
@@ -53,11 +54,23 @@ static struct clk *main_clks[] = {
 	&extal2_clk,
 };
 
-enum { MSTP_NR };
+enum { MSTP217, MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP_NR };
 static struct clk mstp_clks[MSTP_NR] = {
+	[MSTP204] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 4, 1), /* SCIFA0 */
+	[MSTP203] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 3, 1), /* SCIFA1 */
+	[MSTP206] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 6, 1), /* SCIFB0 */
+	[MSTP207] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 7, 1), /* SCIFB1 */
+	[MSTP216] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 16, 1), /* SCIFB2 */
+	[MSTP217] = SH_CLK_MSTP32(&extal2_clk, SMSTPCR2, 17, 1), /* SCIFB3 */
 };
 
 static struct clk_lookup lookups[] = {
+	CLKDEV_DEV_ID("sh-sci.0", &mstp_clks[MSTP204]),
+	CLKDEV_DEV_ID("sh-sci.1", &mstp_clks[MSTP203]),
+	CLKDEV_DEV_ID("sh-sci.2", &mstp_clks[MSTP206]),
+	CLKDEV_DEV_ID("sh-sci.3", &mstp_clks[MSTP207]),
+	CLKDEV_DEV_ID("sh-sci.4", &mstp_clks[MSTP216]),
+	CLKDEV_DEV_ID("sh-sci.5", &mstp_clks[MSTP217]),
 };
 
 void __init r8a73a4_clock_init(void)
--- 0002/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ work/arch/arm/mach-shmobile/setup-r8a73a4.c	2013-03-12 12:49:46.000000000 +0900
@@ -21,12 +21,127 @@
 #include <linux/irqchip.h>
 #include <linux/of_platform.h>
 #include <linux/irq.h>
+#include <linux/serial_sci.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a73a4.h>
 #include <asm/mach/arch.h>
 
+/* SCIFA0 */
+static struct plat_sci_port scif0_platform_data = {
+	.mapbase	= 0xe6c40000,
+	.flags		= UPF_BOOT_AUTOCONF | UPF_IOREMAP,
+	.scscr		= SCSCR_RE | SCSCR_TE | SCSCR_CKE0,
+	.scbrr_algo_id	= SCBRR_ALGO_4,
+	.type		= PORT_SCIFA,
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(144)),
+};
+
+static struct platform_device scif0_device = {
+	.name		= "sh-sci",
+	.id		= 0,
+	.dev		= {
+		.platform_data  = &scif0_platform_data,
+	},
+};
+
+/* SCIFA1 */
+static struct plat_sci_port scif1_platform_data = {
+	.mapbase	= 0xe6c50000,
+	.flags		= UPF_BOOT_AUTOCONF | UPF_IOREMAP,
+	.scscr		= SCSCR_RE | SCSCR_TE | SCSCR_CKE0,
+	.scbrr_algo_id	= SCBRR_ALGO_4,
+	.type		= PORT_SCIFA,
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(145)),
+};
+
+static struct platform_device scif1_device = {
+	.name		= "sh-sci",
+	.id		= 1,
+	.dev		= {
+		.platform_data  = &scif1_platform_data,
+	},
+};
+
+/* SCIFB0 */
+static struct plat_sci_port scif2_platform_data = {
+	.mapbase	= 0xe6c20000,
+	.flags		= UPF_BOOT_AUTOCONF | UPF_IOREMAP,
+	.scscr		= SCSCR_RE | SCSCR_TE,
+	.scbrr_algo_id	= SCBRR_ALGO_4,
+	.type		= PORT_SCIFB,
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(148)),
+};
+
+static struct platform_device scif2_device = {
+	.name		= "sh-sci",
+	.id		= 2,
+	.dev		= {
+		.platform_data  = &scif2_platform_data,
+	},
+};
+
+/* SCIFB1 */
+static struct plat_sci_port scif3_platform_data = {
+	.mapbase	= 0xe6c30000,
+	.flags		= UPF_BOOT_AUTOCONF | UPF_IOREMAP,
+	.scscr		= SCSCR_RE | SCSCR_TE,
+	.scbrr_algo_id	= SCBRR_ALGO_4,
+	.type		= PORT_SCIFB,
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(149)),
+};
+
+static struct platform_device scif3_device = {
+	.name		= "sh-sci",
+	.id		= 3,
+	.dev		= {
+		.platform_data  = &scif3_platform_data,
+	},
+};
+
+/* SCIFB2 */
+static struct plat_sci_port scif4_platform_data = {
+	.mapbase	= 0xe6ce0000,
+	.flags		= UPF_BOOT_AUTOCONF | UPF_IOREMAP,
+	.scscr		= SCSCR_RE | SCSCR_TE,
+	.scbrr_algo_id	= SCBRR_ALGO_4,
+	.type		= PORT_SCIFB,
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(150)),
+};
+
+static struct platform_device scif4_device = {
+	.name		= "sh-sci",
+	.id		= 4,
+	.dev		= {
+		.platform_data  = &scif4_platform_data,
+	},
+};
+
+/* SCIFB3 */
+static struct plat_sci_port scif5_platform_data = {
+	.mapbase	= 0xe6cf0000,
+	.flags		= UPF_BOOT_AUTOCONF | UPF_IOREMAP,
+	.scscr		= SCSCR_RE | SCSCR_TE,
+	.scbrr_algo_id	= SCBRR_ALGO_4,
+	.type		= PORT_SCIFB,
+	.irqs		= SCIx_IRQ_MUXED(gic_spi(151)),
+};
+
+static struct platform_device scif5_device = {
+	.name		= "sh-sci",
+	.id		= 5,
+	.dev		= {
+		.platform_data  = &scif5_platform_data,
+	},
+};
+
 static struct platform_device *r8a73a4_devices[] __initdata = {
+	&scif0_device,
+	&scif1_device,
+	&scif2_device,
+	&scif3_device,
+	&scif4_device,
+	&scif5_device,
 };
 
 void __init r8a73a4_add_standard_devices(void)

[PATCH 03/04] ARM: shmobile: r8a73a4 IRQC support

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Add IRQC interrupt controller support to r8a73a4 by
hooking up two IRQC instances to handle 58 external
IRQ signals. There IRQC controllers are tied to SPIs
of the GIC. On r8a73a4 exact IRQ pin routing is handled
by the PFC which is excluded from this patch.

Both platform devices and DT devices are added in this
patch. The platform device versions are used to provide
a static interrupt map configuration for board code
written in C.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 Depends on:
 [PATCH] irqchip: Renesas IRQC driver
 [PATCH] irqchip: irqc: Add DT support

 arch/arm/boot/dts/r8a73a4.dtsi         |   32 ++++++++++
 arch/arm/mach-shmobile/Kconfig         |    1 
 arch/arm/mach-shmobile/setup-r8a73a4.c |   97 ++++++++++++++++++++++++++++++++
 3 files changed, 130 insertions(+)

--- 0002/arch/arm/boot/dts/r8a73a4.dtsi
+++ work/arch/arm/boot/dts/r8a73a4.dtsi	2013-03-12 00:42:47.000000000 +0900
@@ -51,4 +51,36 @@
 				<1 11 0xf08>,
 				<1 10 0xf08>;
 	};
+
+	irqc0: interrupt-controller at e61c0000 {
+		compatible = "renesas,irqc";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0xe61c0000 0x200>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 0 4>, <0 1 4>, <0 2 4>,	<0 3 4>,
+				<0 4 4>, <0 5 4>, <0 6 4>, <0 7 4>,
+				<0 8 4>, <0 9 4>, <0 10 4>, <0 11 4>,
+				<0 12 4>, <0 13 4>, <0 14 4>, <0 15 4>,
+				<0 16 4>, <0 17 4>, <0 18 4>, <0 19 4>,
+				<0 20 4>, <0 21 4>, <0 22 4>, <0 23 4>,
+				<0 24 4>, <0 25 4>, <0 26 4>, <0 27 4>,
+				<0 28 4>, <0 29 4>, <0 30 4>, <0 31 4>;
+	};
+
+	irqc1: interrupt-controller at e61c0200 {
+		compatible = "renesas,irqc";
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		reg = <0xe61c0200 0x200>;
+		interrupt-parent = <&gic>;
+		interrupts = <0 32 4>, <0 33 4>, <0 34 4>, <0 35 4>,
+				<0 36 4>, <0 37 4>, <0 38 4>, <0 39 4>,
+				<0 40 4>, <0 41 4>, <0 42 4>, <0 43 4>,
+				<0 44 4>, <0 45 4>, <0 46 4>, <0 47 4>,
+				<0 48 4>, <0 49 4>, <0 50 4>, <0 51 4>,
+				<0 52 4>, <0 53 4>, <0 54 4>, <0 55 4>,
+				<0 56 4>, <0 57 4>;
+	};
+
 };
--- 0003/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-03-12 00:42:47.000000000 +0900
@@ -24,6 +24,7 @@ config ARCH_R8A73A4
 	select CPU_V7
 	select ARM_ARCH_TIMER
 	select SH_CLK_CPG
+	select RENESAS_IRQC
 
 config ARCH_R8A7740
 	bool "R-Mobile A1 (R8A77400)"
--- 0002/arch/arm/mach-shmobile/setup-r8a73a4.c
+++ work/arch/arm/mach-shmobile/setup-r8a73a4.c	2013-03-12 00:43:25.000000000 +0900
@@ -22,6 +22,7 @@
 #include <linux/of_platform.h>
 #include <linux/irq.h>
 #include <linux/serial_sci.h>
+#include <linux/platform_data/irq-renesas-irqc.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a73a4.h>
@@ -135,6 +136,100 @@ static struct platform_device scif5_devi
 	},
 };
 
+static struct renesas_irqc_config irqc0_platform_data = {
+	.irq_base = irq_pin(0), /* IRQ0 -> IRQ31 */
+};
+
+static struct resource irqc0_resources[] = {
+	DEFINE_RES_MEM(0xe61c0000, 0x200), /* IRQC Event Detector Block_0 */
+	DEFINE_RES_IRQ(gic_spi(0)), /* IRQ0 */
+	DEFINE_RES_IRQ(gic_spi(1)), /* IRQ1 */
+	DEFINE_RES_IRQ(gic_spi(2)), /* IRQ2 */
+	DEFINE_RES_IRQ(gic_spi(3)), /* IRQ3 */
+	DEFINE_RES_IRQ(gic_spi(4)), /* IRQ4 */
+	DEFINE_RES_IRQ(gic_spi(5)), /* IRQ5 */
+	DEFINE_RES_IRQ(gic_spi(6)), /* IRQ6 */
+	DEFINE_RES_IRQ(gic_spi(7)), /* IRQ7 */
+	DEFINE_RES_IRQ(gic_spi(8)), /* IRQ8 */
+	DEFINE_RES_IRQ(gic_spi(9)), /* IRQ9 */
+	DEFINE_RES_IRQ(gic_spi(10)), /* IRQ10 */
+	DEFINE_RES_IRQ(gic_spi(11)), /* IRQ11 */
+	DEFINE_RES_IRQ(gic_spi(12)), /* IRQ12 */
+	DEFINE_RES_IRQ(gic_spi(13)), /* IRQ13 */
+	DEFINE_RES_IRQ(gic_spi(14)), /* IRQ14 */
+	DEFINE_RES_IRQ(gic_spi(15)), /* IRQ15 */
+	DEFINE_RES_IRQ(gic_spi(16)), /* IRQ16 */
+	DEFINE_RES_IRQ(gic_spi(17)), /* IRQ17 */
+	DEFINE_RES_IRQ(gic_spi(18)), /* IRQ18 */
+	DEFINE_RES_IRQ(gic_spi(19)), /* IRQ19 */
+	DEFINE_RES_IRQ(gic_spi(20)), /* IRQ20 */
+	DEFINE_RES_IRQ(gic_spi(21)), /* IRQ21 */
+	DEFINE_RES_IRQ(gic_spi(22)), /* IRQ22 */
+	DEFINE_RES_IRQ(gic_spi(23)), /* IRQ23 */
+	DEFINE_RES_IRQ(gic_spi(24)), /* IRQ24 */
+	DEFINE_RES_IRQ(gic_spi(25)), /* IRQ25 */
+	DEFINE_RES_IRQ(gic_spi(26)), /* IRQ26 */
+	DEFINE_RES_IRQ(gic_spi(27)), /* IRQ27 */
+	DEFINE_RES_IRQ(gic_spi(28)), /* IRQ28 */
+	DEFINE_RES_IRQ(gic_spi(29)), /* IRQ29 */
+	DEFINE_RES_IRQ(gic_spi(30)), /* IRQ30 */
+	DEFINE_RES_IRQ(gic_spi(31)), /* IRQ31 */
+};
+
+static struct platform_device irqc0_device = {
+	.name		= "renesas_irqc",
+	.id		= 0,
+	.resource	= irqc0_resources,
+	.num_resources	= ARRAY_SIZE(irqc0_resources),
+	.dev		= {
+		.platform_data  = &irqc0_platform_data,
+	},
+};
+
+static struct renesas_irqc_config irqc1_platform_data = {
+	.irq_base = irq_pin(32), /* IRQ32 -> IRQ57 */
+};
+
+static struct resource irqc1_resources[] = {
+	DEFINE_RES_MEM(0xe61c0200, 0x200), /* IRQC Event Detector Block_1 */
+	DEFINE_RES_IRQ(gic_spi(32)), /* IRQ32 */
+	DEFINE_RES_IRQ(gic_spi(33)), /* IRQ33 */
+	DEFINE_RES_IRQ(gic_spi(34)), /* IRQ34 */
+	DEFINE_RES_IRQ(gic_spi(35)), /* IRQ35 */
+	DEFINE_RES_IRQ(gic_spi(36)), /* IRQ36 */
+	DEFINE_RES_IRQ(gic_spi(37)), /* IRQ37 */
+	DEFINE_RES_IRQ(gic_spi(38)), /* IRQ38 */
+	DEFINE_RES_IRQ(gic_spi(39)), /* IRQ39 */
+	DEFINE_RES_IRQ(gic_spi(40)), /* IRQ40 */
+	DEFINE_RES_IRQ(gic_spi(41)), /* IRQ41 */
+	DEFINE_RES_IRQ(gic_spi(42)), /* IRQ42 */
+	DEFINE_RES_IRQ(gic_spi(43)), /* IRQ43 */
+	DEFINE_RES_IRQ(gic_spi(44)), /* IRQ44 */
+	DEFINE_RES_IRQ(gic_spi(45)), /* IRQ45 */
+	DEFINE_RES_IRQ(gic_spi(46)), /* IRQ46 */
+	DEFINE_RES_IRQ(gic_spi(47)), /* IRQ47 */
+	DEFINE_RES_IRQ(gic_spi(48)), /* IRQ48 */
+	DEFINE_RES_IRQ(gic_spi(49)), /* IRQ49 */
+	DEFINE_RES_IRQ(gic_spi(50)), /* IRQ50 */
+	DEFINE_RES_IRQ(gic_spi(51)), /* IRQ51 */
+	DEFINE_RES_IRQ(gic_spi(52)), /* IRQ52 */
+	DEFINE_RES_IRQ(gic_spi(53)), /* IRQ53 */
+	DEFINE_RES_IRQ(gic_spi(54)), /* IRQ54 */
+	DEFINE_RES_IRQ(gic_spi(55)), /* IRQ55 */
+	DEFINE_RES_IRQ(gic_spi(56)), /* IRQ56 */
+	DEFINE_RES_IRQ(gic_spi(57)), /* IRQ57 */
+};
+
+static struct platform_device irqc1_device = {
+	.name		= "renesas_irqc",
+	.id		= 1,
+	.resource	= irqc1_resources,
+	.num_resources	= ARRAY_SIZE(irqc1_resources),
+	.dev		= {
+		.platform_data  = &irqc1_platform_data,
+	},
+};
+
 static struct platform_device *r8a73a4_devices[] __initdata = {
 	&scif0_device,
 	&scif1_device,
@@ -142,6 +237,8 @@ static struct platform_device *r8a73a4_d
 	&scif3_device,
 	&scif4_device,
 	&scif5_device,
+	&irqc0_device,
+	&irqc1_device,
 };
 
 void __init r8a73a4_add_standard_devices(void)

[PATCH 04/04] ARM: shmobile: APE6EVM support

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Add APE6EVM board support making use of 1 GiB of memory,
the SCIFA0 serial port and the Architecture timer.

More devices will be added on top of this patch after
PICNTRL and clock framework are in better shape.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/boot/dts/Makefile             |    1 
 arch/arm/boot/dts/r8a73a4-ape6evm.dts  |   26 ++++++++++++++++++++
 arch/arm/mach-shmobile/Kconfig         |    8 +++++-
 arch/arm/mach-shmobile/Makefile        |    1 
 arch/arm/mach-shmobile/board-ape6evm.c |   40 ++++++++++++++++++++++++++++++++
 5 files changed, 75 insertions(+), 1 deletion(-)

--- 0001/arch/arm/boot/dts/Makefile
+++ work/arch/arm/boot/dts/Makefile	2013-03-11 23:05:33.000000000 +0900
@@ -125,6 +125,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm
 	r8a7779-marzen-reference.dtb \
 	sh73a0-kzm9g.dtb \
 	sh73a0-kzm9g-reference.dtb \
+	r8a73a4-ape6evm.dtb \
 	sh7372-mackerel.dtb
 dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
 	spear1340-evb.dtb
--- /dev/null
+++ work/arch/arm/boot/dts/r8a73a4-ape6evm.dts	2013-03-11 23:06:38.000000000 +0900
@@ -0,0 +1,26 @@
+/*
+ * Device Tree Source for the APE6EVM board
+ *
+ * Copyright (C) 2013 Renesas Solutions 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/ "r8a73a4.dtsi"
+
+/ {
+	model = "APE6EVM";
+	compatible = "renesas,ape6evm", "renesas,r8a73a4";
+
+	chosen {
+		bootargs = "console=ttySC0,115200 ignore_loglevel";
+	};
+
+	memory at 40000000 {
+		device_type = "memory";
+		reg = <0x40000000 0x40000000>;
+	};
+};
--- 0002/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-03-11 23:07:50.000000000 +0900
@@ -76,6 +76,11 @@ config MACH_AG5EVM
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SH_LCD_MIPI_DSI
 
+config MACH_APE6EVM
+	bool "APE6EVM board"
+	depends on ARCH_R8A73A4
+	select USE_OF
+
 config MACH_MACKEREL
 	bool "mackerel board"
 	depends on ARCH_SH7372
@@ -163,7 +168,7 @@ config MEMORY_START
 	hex "Physical memory start address"
 	default "0x40000000" if MACH_AP4EVB || MACH_AG5EVM || \
 				MACH_MACKEREL || MACH_BONITO || \
-				MACH_ARMADILLO800EVA
+				MACH_ARMADILLO800EVA || MACH_APE6EVM
 	default "0x41000000" if MACH_KOTA2
 	default "0x00000000"
 	---help---
@@ -173,6 +178,7 @@ config MEMORY_START
 
 config MEMORY_SIZE
 	hex "Physical memory size"
+	default "0x40000000" if MACH_APE6EVM
 	default "0x20000000" if MACH_AG5EVM || MACH_BONITO || \
 				MACH_ARMADILLO800EVA
 	default "0x1e000000" if MACH_KOTA2
--- 0002/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2013-03-11 23:05:33.000000000 +0900
@@ -35,6 +35,7 @@ obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 # Board objects
 obj-$(CONFIG_MACH_AP4EVB)	+= board-ap4evb.o
 obj-$(CONFIG_MACH_AG5EVM)	+= board-ag5evm.o
+obj-$(CONFIG_MACH_APE6EVM)	+= board-ape6evm.o
 obj-$(CONFIG_MACH_MACKEREL)	+= board-mackerel.o
 obj-$(CONFIG_MACH_KOTA2)	+= board-kota2.o
 obj-$(CONFIG_MACH_BONITO)	+= board-bonito.o
--- /dev/null
+++ work/arch/arm/mach-shmobile/board-ape6evm.c	2013-03-11 23:05:34.000000000 +0900
@@ -0,0 +1,40 @@
+/*
+ * APE6EVM board support
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Magnus Damm
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/irqchip.h>
+#include <mach/common.h>
+#include <mach/r8a73a4.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+static const char *ape6evm_boards_compat_dt[] __initdata = {
+	"renesas,ape6evm",
+	NULL,
+};
+
+DT_MACHINE_START(APE6EVM_DT, "ape6evm")
+	.init_irq	= irqchip_init,
+	.init_time	= shmobile_timer_init,
+	.init_machine	= r8a73a4_add_standard_devices,
+	.dt_compat	= ape6evm_boards_compat_dt,
+MACHINE_END

[PATCH 00/04] ARM: shmobile: r8a73a4 SoC and APE6EVM board support

[Kuninori Morimoto]

Hi

> ARM: shmobile: r8a73a4 SoC and APE6EVM board support
> 
> [PATCH 01/04] ARM: shmobile: Initial r8a73a4 SoC support
> [PATCH 02/04] ARM: shmobile: r8a73a4 SCIF support
> [PATCH 03/04] ARM: shmobile: r8a73a4 IRQC support
> [PATCH 04/04] ARM: shmobile: APE6EVM support
> 
> This series adds initial support for r8a73a4 and APE6EVM. The SoC
> is known as r8a73a4 which is built around Cortex-A15 and makes use
> of SCIF for serial and IRQC interrupt controller for external IRQs.
> 
> This initial SoC and board support is providing limited DT-only
> support and a very basic C-version of board support. In the future
> improved PINCTRL and clock framework support will be added, followed
> by SMP support.
> 
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
> 
>  Written against all+next in renesas.git.
>  [PATCH 03/04] requires the IRQC driver to build
> 
>  arch/arm/boot/dts/Makefile                    |    1 
>  arch/arm/boot/dts/r8a73a4-ape6evm.dts         |   26 ++
>  arch/arm/boot/dts/r8a73a4.dtsi                |   87 ++++++++
>  arch/arm/mach-shmobile/Kconfig                |   16 +
>  arch/arm/mach-shmobile/Makefile               |    2 
>  arch/arm/mach-shmobile/board-ape6evm.c        |   40 +++
>  arch/arm/mach-shmobile/clock-r8a73a4.c        |  104 +++++++++
>  arch/arm/mach-shmobile/include/mach/r8a73a4.h |    7 
>  arch/arm/mach-shmobile/setup-r8a73a4.c        |  268 +++++++++++++++++++++++++
>  9 files changed, 549 insertions(+), 2 deletions(-)

For all patches

Reviewed-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Best regards
---
Kuninori Morimoto

[PATCH 04/04] ARM: shmobile: APE6EVM support

[Kuninori Morimoto]

Hi Magnus

I already sent Reviewed-by, but...

> @@ -0,0 +1,40 @@
> +/*
> + * APE6EVM board support
> + *
> + * Copyright (C) 2013  Renesas Solutions Corp.
> + * Copyright (C) 2013  Magnus Damm
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/interrupt.h>
> +#include <linux/platform_device.h>
> +#include <linux/irqchip.h>
> +#include <mach/common.h>
> +#include <mach/r8a73a4.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>

There are too many include here,
and not in alphabetical order :)

Best regards
---
Kuninori Morimoto

[PATCH 04/04] ARM: shmobile: APE6EVM support

[Magnus Damm]

On Tue, Mar 12, 2013 at 4:51 PM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
> Hi Magnus
>
> I already sent Reviewed-by, but...
>
>> @@ -0,0 +1,40 @@
>> +/*
>> + * APE6EVM board support
>> + *
>> + * Copyright (C) 2013  Renesas Solutions Corp.
>> + * Copyright (C) 2013  Magnus Damm
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; version 2 of the License.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/irqchip.h>
>> +#include <mach/common.h>
>> +#include <mach/r8a73a4.h>
>> +#include <asm/mach-types.h>
>> +#include <asm/mach/arch.h>
>
> There are too many include here,
> and not in alphabetical order :)

Yes. And what's next? Do I need to encode using Shift-JIS? =)

/ magnus

[PATCH 04/04] ARM: shmobile: APE6EVM support

[Arnd Bergmann]

On Tuesday 12 March 2013, Magnus Damm wrote:
> +
> +static const char *ape6evm_boards_compat_dt[] __initdata = {
> +       "renesas,ape6evm",
> +       NULL,
> +};
> +
> +DT_MACHINE_START(APE6EVM_DT, "ape6evm")
> +       .init_irq       = irqchip_init,
> +       .init_time      = shmobile_timer_init,
> +       .init_machine   = r8a73a4_add_standard_devices,
> +       .dt_compat      = ape6evm_boards_compat_dt,
> +MACHINE_END

Do you plan to add board-specific contents here in a follow-up patch soon?

If not, it seems the setup-r8a73a4.c already handles this board with its
defaults.

	Arnd

[PATCH 01/04] ARM: shmobile: Initial r8a73a4 SoC support

[Arnd Bergmann]

On Tuesday 12 March 2013, Magnus Damm wrote:
> +static struct platform_device *r8a73a4_devices[] __initdata = {
> +};
> +
> +void __init r8a73a4_add_standard_devices(void)
> +{
> +       r8a73a4_clock_init();
> +
> +       platform_add_devices(r8a73a4_devices, ARRAY_SIZE(r8a73a4_devices));
> +}

I would suggest doing the platform_add_devices() only when you actually
add devices to the array, unless you have a number of conflicting patches
that each want to add their own devices.

> +#ifdef CONFIG_USE_OF
> +void __init r8a73a4_add_standard_devices_dt(void)
> +{
> +       of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}

I have a patch that will make this function definition the default, so you
no longer have to provide an init_machine callback if you don't do anything
special. It's ok to leave it in for now, but we might want to do a follow
up patch to remove it once both patches are merged.

> +static const char *r8a73a4_boards_compat_dt[] __initdata = {
> +       "renesas,r8a73a4",
> +       NULL,
> +};
> +
> +DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
> +       .init_irq       = irqchip_init,

Same thing for the default irqchip_init.

> +       .init_machine   = r8a73a4_add_standard_devices_dt,
> +       .init_time      = shmobile_timer_init,
> +       .dt_compat      = r8a73a4_boards_compat_dt,

Have you looked into using clocksource_of_init() here? Since you are using
the ARM architected timers, I would expect that they soon will get probed
using that function, which means we have to be careful crossing patches
if someone wants to convert over all the existing users and you add a new one
here.

	Arnd

[PATCH 00/04] ARM: shmobile: r8a73a4 SoC and APE6EVM board support

[Arnd Bergmann]

On Tuesday 12 March 2013, Magnus Damm wrote:
> ARM: shmobile: r8a73a4 SoC and APE6EVM board support
> 
> [PATCH 01/04] ARM: shmobile: Initial r8a73a4 SoC support
> [PATCH 02/04] ARM: shmobile: r8a73a4 SCIF support
> [PATCH 03/04] ARM: shmobile: r8a73a4 IRQC support
> [PATCH 04/04] ARM: shmobile: APE6EVM support
> 
> This series adds initial support for r8a73a4 and APE6EVM. The SoC
> is known as r8a73a4 which is built around Cortex-A15 and makes use
> of SCIF for serial and IRQC interrupt controller for external IRQs.
> 
> This initial SoC and board support is providing limited DT-only
> support and a very basic C-version of board support. In the future
> improved PINCTRL and clock framework support will be added, followed
> by SMP support.
> 
> Signed-off-by: Magnus Damm <damm@opensource.se>

Patches look good so far. I assume you have made them in a way that lets
you easily keep around non-DT support internally, right?

	Arnd

[PATCH 03/04] ARM: shmobile: r8a73a4 IRQC support

[Arnd Bergmann]

On Tuesday 12 March 2013, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
> 
> Add IRQC interrupt controller support to r8a73a4 by
> hooking up two IRQC instances to handle 58 external
> IRQ signals. There IRQC controllers are tied to SPIs
> of the GIC. On r8a73a4 exact IRQ pin routing is handled
> by the PFC which is excluded from this patch.
> 
> Both platform devices and DT devices are added in this
> patch. The platform device versions are used to provide
> a static interrupt map configuration for board code
> written in C.
> 
> Signed-off-by: Magnus Damm <damm@opensource.se>

What is the status of the IRQC DT support? I remember that I wasn't
happy with a prior version, but I did not follow up on some of the
questions that came up, sorry about that.

Did the patches end up getting merged anyway, or should we resume the
discussion about those patches? I understand that lack of INTC bindings
would make new SoC support particularly hard, and I don't want to
be responsible for holding you up here.

	Arnd

[PATCH 03/04] ARM: shmobile: r8a73a4 IRQC support

[Magnus Damm]

Hi Arnd,

Thanks for your feedback, please see below for my reply.

On Tue, Mar 12, 2013 at 9:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 12 March 2013, Magnus Damm wrote:
>> From: Magnus Damm <damm@opensource.se>
>>
>> Add IRQC interrupt controller support to r8a73a4 by
>> hooking up two IRQC instances to handle 58 external
>> IRQ signals. There IRQC controllers are tied to SPIs
>> of the GIC. On r8a73a4 exact IRQ pin routing is handled
>> by the PFC which is excluded from this patch.
>>
>> Both platform devices and DT devices are added in this
>> patch. The platform device versions are used to provide
>> a static interrupt map configuration for board code
>> written in C.
>>
>> Signed-off-by: Magnus Damm <damm@opensource.se>
>
> What is the status of the IRQC DT support? I remember that I wasn't
> happy with a prior version, but I did not follow up on some of the
> questions that came up, sorry about that.

Uhm, perhaps I misunderstand, but I wonder if you refer to INTC instead of IRQC?

This particular driver is for the IRQC hardware block. It is not
compatible with INTC. A while ago I posted an incremental DT support
patch for IRQC -  "[PATCH] irqchip: irqc: Add DT support", please see
https://lkml.org/lkml/2013/3/6/50

> Did the patches end up getting merged anyway, or should we resume the
> discussion about those patches? I understand that lack of INTC bindings
> would make new SoC support particularly hard, and I don't want to
> be responsible for holding you up here.

Thanks. I don't think the INTC patches went anywhere.

To zoom out a bit let me list different interrupt controllers:

A) INTC (drivers/sh/intc) [no DT yet]
B) GIC (drivers/irqchip/irq-gic.c) [DT]
C) INTC External IRQ Pin (drivers/irqchip/irq-renesas-intc-irqpin.c) [DT]
D) IRQC (drivers/irqchip/irq-renesas-irqc.c) [DT]

Simple use cases are:
- Legacy SH SoCs or ARM SoCs with Cortex-A8 or older make use of A).
- More recent ARM SoCs with Cortex-A9 or newer use B) and C) or B) and D).

On top of this we now and then have GPIO controllers that have
built-in interrupt controllers.

Hope this helps,

/ magnus

[PATCH 04/04] ARM: shmobile: APE6EVM support

[Magnus Damm]

Hi Arnd,

On Tue, Mar 12, 2013 at 9:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 12 March 2013, Magnus Damm wrote:
>> +
>> +static const char *ape6evm_boards_compat_dt[] __initdata = {
>> +       "renesas,ape6evm",
>> +       NULL,
>> +};
>> +
>> +DT_MACHINE_START(APE6EVM_DT, "ape6evm")
>> +       .init_irq       = irqchip_init,
>> +       .init_time      = shmobile_timer_init,
>> +       .init_machine   = r8a73a4_add_standard_devices,
>> +       .dt_compat      = ape6evm_boards_compat_dt,
>> +MACHINE_END
>
> Do you plan to add board-specific contents here in a follow-up patch soon?

Yes, correct. At this point we cannot configure the pin controller from DT.

> If not, it seems the setup-r8a73a4.c already handles this board with its
> defaults.

Right, this portion is only made as a ground work for incremental patches.

Thanks,

/ magnus

[PATCH 00/04] ARM: shmobile: r8a73a4 SoC and APE6EVM board support

[Magnus Damm]

On Tue, Mar 12, 2013 at 9:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 12 March 2013, Magnus Damm wrote:
>> ARM: shmobile: r8a73a4 SoC and APE6EVM board support
>>
>> [PATCH 01/04] ARM: shmobile: Initial r8a73a4 SoC support
>> [PATCH 02/04] ARM: shmobile: r8a73a4 SCIF support
>> [PATCH 03/04] ARM: shmobile: r8a73a4 IRQC support
>> [PATCH 04/04] ARM: shmobile: APE6EVM support
>>
>> This series adds initial support for r8a73a4 and APE6EVM. The SoC
>> is known as r8a73a4 which is built around Cortex-A15 and makes use
>> of SCIF for serial and IRQC interrupt controller for external IRQs.
>>
>> This initial SoC and board support is providing limited DT-only
>> support and a very basic C-version of board support. In the future
>> improved PINCTRL and clock framework support will be added, followed
>> by SMP support.
>>
>> Signed-off-by: Magnus Damm <damm@opensource.se>
>
> Patches look good so far. I assume you have made them in a way that lets
> you easily keep around non-DT support internally, right?

Thanks. Regarding your question, please allow me try to answer a
rather simple question in a complicated way. =)

I have some perhaps naive hope of not having to force people to write
out of tree code. I believe it is possible to use upstream to deliver
something short term and at the same time work with upstream towards
long term goals. So I hope we won't be forced to keep non-DT support
around internally.

For short term, in some cases where we don't have complete DT bindings
(like clocks and pinctrl at the moment) we still have to use board
code written in C to configure the hardware. Using DT only at this
point would result in a non-working kernel without support for
mandatory components like pinmux, clock support and power domains, so
for short term that doesn't fly.

As I know you've seen, we are actively working on improving our DT
coverage. Our approach to DT so far is to work our way towards more
complete support in the -reference DT board support code. We keep the
C version around as feature complete implementation and when the
-reference DT version of the board code is good enough then we kill
the C version and use DT only.

These patches for new SoCs and boards use a mix of DT and C. In
practice that means that I plan on using platform devices and DT in
parallel. These platform devices can easily go away upon your request,
if so a new version of the patch will be submitted with the offensive
hunks removed. The old version may however still be used for back
porting.

So if there are some portions of the code that you would like me to
rework then please let me know and I will do my best to follow your
guidance. I am also open to clean up various portions of the code if
you have some particular place that you feel needs extra attention.

Thanks for your help,

/ magnus

[PATCH 01/04] ARM: shmobile: Initial r8a73a4 SoC support

[Magnus Damm]

Hi Arnd,

On Tue, Mar 12, 2013 at 9:25 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 12 March 2013, Magnus Damm wrote:
>> +static struct platform_device *r8a73a4_devices[] __initdata = {
>> +};
>> +
>> +void __init r8a73a4_add_standard_devices(void)
>> +{
>> +       r8a73a4_clock_init();
>> +
>> +       platform_add_devices(r8a73a4_devices, ARRAY_SIZE(r8a73a4_devices));
>> +}
>
> I would suggest doing the platform_add_devices() only when you actually
> add devices to the array, unless you have a number of conflicting patches
> that each want to add their own devices.

So you would prefer that I fold this portion into a patch later in the series?

>> +#ifdef CONFIG_USE_OF
>> +void __init r8a73a4_add_standard_devices_dt(void)
>> +{
>> +       of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>> +}
>
> I have a patch that will make this function definition the default, so you
> no longer have to provide an init_machine callback if you don't do anything
> special. It's ok to leave it in for now, but we might want to do a follow
> up patch to remove it once both patches are merged.

That's very nice! I am happy to hear that. Is that patch targeting v3.10?

>> +static const char *r8a73a4_boards_compat_dt[] __initdata = {
>> +       "renesas,r8a73a4",
>> +       NULL,
>> +};
>> +
>> +DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
>> +       .init_irq       = irqchip_init,
>
> Same thing for the default irqchip_init.

Excellent! I believe the easiest is to leave it as-is for now and have
a clean-up series that can be merged late in the cycle after your
patch is in. I am not sure if that fits with your way of dealing with
the pull requests. At least that's how we used to do it for SH. If you
have any suggestion when to remove it please let me know.

>> +       .init_machine   = r8a73a4_add_standard_devices_dt,
>> +       .init_time      = shmobile_timer_init,
>> +       .dt_compat      = r8a73a4_boards_compat_dt,
>
> Have you looked into using clocksource_of_init() here? Since you are using
> the ARM architected timers, I would expect that they soon will get probed
> using that function, which means we have to be careful crossing patches
> if someone wants to convert over all the existing users and you add a new one
> here.

Thanks for this suggestion. Right now we call shmobile_timer_init()
that includes these calls:
	arch_timer_of_register();
	arch_timer_sched_clock_init();

For SH and mach-shmobile we have our own timers in drivers/clocksource
as platform regular devices. They export clock source and clock event
interfaces. Today we simply use the regular driver model together with
SoC code to register platform devices during SoC setup - this
including timers but excluding the arch timer.

I agree we need to find some way to make them work together with the
ARM architected timer.

Thanks,

/ magnus

[PATCH 00/04] ARM: shmobile: r8a73a4 SoC and APE6EVM board support

[Arnd Bergmann]

On Thursday 14 March 2013, Magnus Damm wrote:

> These patches for new SoCs and boards use a mix of DT and C. In
> practice that means that I plan on using platform devices and DT in
> parallel. These platform devices can easily go away upon your request,
> if so a new version of the patch will be submitted with the offensive
> hunks removed. The old version may however still be used for back
> porting.

Yes, that sounds like a good plan.

> So if there are some portions of the code that you would like me to
> rework then please let me know and I will do my best to follow your
> guidance. I am also open to clean up various portions of the code if
> you have some particular place that you feel needs extra attention.

The only part that confused me was the use of "#ifdef CONFIG_USE_OF"
in the setup-r8a73a4.c file. If the plan is to use a combination of
DT with static platform_data (or platform_devices, more on that below),
you always need that conditional code, and I think it would be more
logical to remove the #ifdef. I understand that having the #ifdef
in place makes your life easier for backporting to kernels that
don't have enough DT support yet, but I think you are going to run
into larger issues tha this the more those divert from current
mainline over time.

Regarding how to best mix platform devices and DT, my recommendation
is to use AUXDATA for the platform_data and device names while getting
the IRQ and MMIO resources from DT for devices that have no binding
yet, rather than creating the complete device in platform code. In
particular, this should make it easier to deal with IRQ domains, and
with devices that are disabled on some boards, but again it will make
you backporting more work.

Regarding how platform devices are created, Greg KH has been trying
to stop people from statically declaring the devices in platform code
for many years, the recommended way to do it (if you have to) is calling
one of platform_device_register_{full,resndata,data,simple}. We still
have a large number of static platform devices in ARM, and I'm not
asking anyone to actively convert the existing ones, but I should
probably be a little stricter about using the proper interfaces in
new code.

To summarize, the many ways to create platform devices from most
preferred to least are:

1. DT without auxdata
2. DT with auxdata
3. platform_device_register_*
4. static definition with platform_device_register

	Arnd

[PATCH 01/04] ARM: shmobile: Initial r8a73a4 SoC support

[Arnd Bergmann]

On Thursday 14 March 2013, Magnus Damm wrote:
> On Tue, Mar 12, 2013 at 9:25 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 12 March 2013, Magnus Damm wrote:
> >> +static struct platform_device *r8a73a4_devices[] __initdata = {
> >> +};
> >> +
> >> +void __init r8a73a4_add_standard_devices(void)
> >> +{
> >> +       r8a73a4_clock_init();
> >> +
> >> +       platform_add_devices(r8a73a4_devices, ARRAY_SIZE(r8a73a4_devices));
> >> +}
> >
> > I would suggest doing the platform_add_devices() only when you actually
> > add devices to the array, unless you have a number of conflicting patches
> > that each want to add their own devices.
> 
> So you would prefer that I fold this portion into a patch later in the series?

If you are adding the devices in a later patch of the same series, it's
probably better to leave it like it is. I would just like to avoid having
dead code in a release if you don't get around to also add the devices.

> >> +#ifdef CONFIG_USE_OF
> >> +void __init r8a73a4_add_standard_devices_dt(void)
> >> +{
> >> +       of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> >> +}
> >
> > I have a patch that will make this function definition the default, so you
> > no longer have to provide an init_machine callback if you don't do anything
> > special. It's ok to leave it in for now, but we might want to do a follow
> > up patch to remove it once both patches are merged.
> 
> That's very nice! I am happy to hear that. Is that patch targeting v3.10?

Yes, I just need to produce a new version based on 3.9-rc.

> >> +static const char *r8a73a4_boards_compat_dt[] __initdata = {
> >> +       "renesas,r8a73a4",
> >> +       NULL,
> >> +};
> >> +
> >> +DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
> >> +       .init_irq       = irqchip_init,
> >
> > Same thing for the default irqchip_init.
> 
> Excellent! I believe the easiest is to leave it as-is for now and have
> a clean-up series that can be merged late in the cycle after your
> patch is in. I am not sure if that fits with your way of dealing with
> the pull requests. At least that's how we used to do it for SH. If you
> have any suggestion when to remove it please let me know.

I don't want to get new patches during the merge window, but we can
arrange a branch in the arm-soc tree that has both changes merged
and the cleanup on top. We always send out pull requests for 10 to
15 branches in the merge window, and the later branches can be based
on the earlier ones to deal with dependencies like this.

In this particular case, it would also not hurt to do the cleanup
in 3.11, since the patch is only cosmetic.

	Arnd

[PATCH 03/04] ARM: shmobile: r8a73a4 IRQC support

[Arnd Bergmann]

On Thursday 14 March 2013, Magnus Damm wrote:
> Hi Arnd,
> 
> Thanks for your feedback, please see below for my reply.
> 
> On Tue, Mar 12, 2013 at 9:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 12 March 2013, Magnus Damm wrote:
> >> From: Magnus Damm <damm@opensource.se>
> >>
> >> Add IRQC interrupt controller support to r8a73a4 by
> >> hooking up two IRQC instances to handle 58 external
> >> IRQ signals. There IRQC controllers are tied to SPIs
> >> of the GIC. On r8a73a4 exact IRQ pin routing is handled
> >> by the PFC which is excluded from this patch.
> >>
> >> Both platform devices and DT devices are added in this
> >> patch. The platform device versions are used to provide
> >> a static interrupt map configuration for board code
> >> written in C.
> >>
> >> Signed-off-by: Magnus Damm <damm@opensource.se>
> >
> > What is the status of the IRQC DT support? I remember that I wasn't
> > happy with a prior version, but I did not follow up on some of the
> > questions that came up, sorry about that.
> 
> Uhm, perhaps I misunderstand, but I wonder if you refer to INTC instead of IRQC?

Yes, you are right.

> This particular driver is for the IRQC hardware block. It is not
> compatible with INTC. A while ago I posted an incremental DT support
> patch for IRQC -  "[PATCH] irqchip: irqc: Add DT support", please see
> https://lkml.org/lkml/2013/3/6/50

Ok, I had missed that, but the driver certainly looks good to me.

> > Did the patches end up getting merged anyway, or should we resume the
> > discussion about those patches? I understand that lack of INTC bindings
> > would make new SoC support particularly hard, and I don't want to
> > be responsible for holding you up here.
> 
> Thanks. I don't think the INTC patches went anywhere.
> 
> To zoom out a bit let me list different interrupt controllers:
> 
> A) INTC (drivers/sh/intc) [no DT yet]
> B) GIC (drivers/irqchip/irq-gic.c) [DT]
> C) INTC External IRQ Pin (drivers/irqchip/irq-renesas-intc-irqpin.c) [DT]
> D) IRQC (drivers/irqchip/irq-renesas-irqc.c) [DT]
> 
> Simple use cases are:
> - Legacy SH SoCs or ARM SoCs with Cortex-A8 or older make use of A).
> - More recent ARM SoCs with Cortex-A9 or newer use B) and C) or B) and D).

Ok. And I guess the EMMA EV2 uses only GIC but not IRQC or INTC, right?

> On top of this we now and then have GPIO controllers that have
> built-in interrupt controllers.

Yes, obviously.

Coming back to INTC, are you planning to use the same binding for A and C?
Which of them the binding you posted earlier for?

When I looked at the existing code, I had the impression that doing a
binding for just the SH-Mobile SoCs that have an ARM core in them 
(including those that also have an SH core) would be much easier than
doing a binding that also covers the older SH SoCs, since those are
much less uniform.

	Arnd

[PATCH 03/04] ARM: shmobile: r8a73a4 IRQC support

[Magnus Damm]

On Thu, Mar 14, 2013 at 10:43 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 14 March 2013, Magnus Damm wrote:
>> Hi Arnd,
>>
>> Thanks for your feedback, please see below for my reply.
>>
>> On Tue, Mar 12, 2013 at 9:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tuesday 12 March 2013, Magnus Damm wrote:
>> >> From: Magnus Damm <damm@opensource.se>
>> >>
>> >> Add IRQC interrupt controller support to r8a73a4 by
>> >> hooking up two IRQC instances to handle 58 external
>> >> IRQ signals. There IRQC controllers are tied to SPIs
>> >> of the GIC. On r8a73a4 exact IRQ pin routing is handled
>> >> by the PFC which is excluded from this patch.
>> >>
>> >> Both platform devices and DT devices are added in this
>> >> patch. The platform device versions are used to provide
>> >> a static interrupt map configuration for board code
>> >> written in C.
>> >>
>> >> Signed-off-by: Magnus Damm <damm@opensource.se>
>> >
>> > What is the status of the IRQC DT support? I remember that I wasn't
>> > happy with a prior version, but I did not follow up on some of the
>> > questions that came up, sorry about that.
>>
>> Uhm, perhaps I misunderstand, but I wonder if you refer to INTC instead of IRQC?
>
> Yes, you are right.

I don't blame you for the misunderstanding - as you see there are a
couple of interrupt controllers just from Renesas SoC division, and
you probably get to see similar situations with every SoC vendor.
Quite a few different interrupt controllers to keep track of! =)

>> This particular driver is for the IRQC hardware block. It is not
>> compatible with INTC. A while ago I posted an incremental DT support
>> patch for IRQC -  "[PATCH] irqchip: irqc: Add DT support", please see
>> https://lkml.org/lkml/2013/3/6/50
>
> Ok, I had missed that, but the driver certainly looks good to me.

Thanks.

>> > Did the patches end up getting merged anyway, or should we resume the
>> > discussion about those patches? I understand that lack of INTC bindings
>> > would make new SoC support particularly hard, and I don't want to
>> > be responsible for holding you up here.
>>
>> Thanks. I don't think the INTC patches went anywhere.
>>
>> To zoom out a bit let me list different interrupt controllers:
>>
>> A) INTC (drivers/sh/intc) [no DT yet]
>> B) GIC (drivers/irqchip/irq-gic.c) [DT]
>> C) INTC External IRQ Pin (drivers/irqchip/irq-renesas-intc-irqpin.c) [DT]
>> D) IRQC (drivers/irqchip/irq-renesas-irqc.c) [DT]
>>
>> Simple use cases are:
>> - Legacy SH SoCs or ARM SoCs with Cortex-A8 or older make use of A).
>> - More recent ARM SoCs with Cortex-A9 or newer use B) and C) or B) and D).
>
> Ok. And I guess the EMMA EV2 uses only GIC but not IRQC or INTC, right?

Yes, correct. GIC and per-GPIO interrupts provided by gpio-em.c.

>> On top of this we now and then have GPIO controllers that have
>> built-in interrupt controllers.
>
> Yes, obviously.

What may not be so obvious is the GPIO interface provided by the PFC
code that is now located in drivers/pinctrl/sh-pfc/. There used to be
a function-only GPIOs in the PFC code but we're now moving over to
PINCTRL thanks to great effort by Laurent. So besides the old
function-only GPIOs provided by PFC there are also regular GPIOs
exported by the PFC code. Those regular GPIOs exported by the PFC do
not have any built-in interrupt controller - instead the external IRQs
handled by C) and D) above are used.

Other GPIO blocks like gpio-em.c and gpio-rcar.c have built-in
interrupt controllers and can do per-GPIO interrupts.

> Coming back to INTC, are you planning to use the same binding for A and C?

I was not planning on that, no. To be honest, at this point I am not
sure which way forward is best for A).

> Which of them the binding you posted earlier for?

Regarding A), I wrote some local DT prototype patches for INTC a year
or two ago, showing how things could be done and how we can start
using DT. Then I handed the job over to other people. However, from
there my advice of incremental development was ignored and instead
more complete bindings were developed directly without much review. So
I wouldn't say that I posted the bindings myself. Right now I'm very
hands-off in that area.

As for C), those DT bindings were done by me. They are however not
compatible with A). The hardware is different. C) is basically a
special case subset of A).

> When I looked at the existing code, I had the impression that doing a
> binding for just the SH-Mobile SoCs that have an ARM core in them
> (including those that also have an SH core) would be much easier than
> doing a binding that also covers the older SH SoCs, since those are
> much less uniform.

I agree that in some cases it may make sense to split the SH bits from
ARM, but I wonder how much we would win for the INTC.

Right now I'm considering converting r8a7740 to use B) and C) (if
possible), and if so then the only ARM SoC using A) for main interrupt
controller left is sh7372.

For sh7372 we could simply try to use C) for board-level interrupts
(and board level DT) but keep the SoC portion in C with A) until the
SoC is being phased out. Or we could have a simple compatible
"renesas,intc-sh7372" with tables in C using irq domain to support DT,
but that would be exactly as my first incremental development task
that wasn't followed...

What would you do?

Thanks for your help,

/ magnus

[PATCH 01/04] ARM: shmobile: Initial r8a73a4 SoC support

[Magnus Damm]

On Thu, Mar 14, 2013 at 6:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 14 March 2013, Magnus Damm wrote:
>> On Tue, Mar 12, 2013 at 9:25 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tuesday 12 March 2013, Magnus Damm wrote:
>> >> +static struct platform_device *r8a73a4_devices[] __initdata = {
>> >> +};
>> >> +
>> >> +void __init r8a73a4_add_standard_devices(void)
>> >> +{
>> >> +       r8a73a4_clock_init();
>> >> +
>> >> +       platform_add_devices(r8a73a4_devices, ARRAY_SIZE(r8a73a4_devices));
>> >> +}
>> >
>> > I would suggest doing the platform_add_devices() only when you actually
>> > add devices to the array, unless you have a number of conflicting patches
>> > that each want to add their own devices.
>>
>> So you would prefer that I fold this portion into a patch later in the series?
>
> If you are adding the devices in a later patch of the same series, it's
> probably better to leave it like it is. I would just like to avoid having
> dead code in a release if you don't get around to also add the devices.

Sure. As you may have seen, I ended up moving away from static
platform devices in V2. So this portion of the code is gone there.

>> >> +#ifdef CONFIG_USE_OF
>> >> +void __init r8a73a4_add_standard_devices_dt(void)
>> >> +{
>> >> +       of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>> >> +}
>> >
>> > I have a patch that will make this function definition the default, so you
>> > no longer have to provide an init_machine callback if you don't do anything
>> > special. It's ok to leave it in for now, but we might want to do a follow
>> > up patch to remove it once both patches are merged.
>>
>> That's very nice! I am happy to hear that. Is that patch targeting v3.10?
>
> Yes, I just need to produce a new version based on 3.9-rc.

That is fine, but as you suggest below, perhaps it is easier to wait
until post-v3.10?

>> >> +static const char *r8a73a4_boards_compat_dt[] __initdata = {
>> >> +       "renesas,r8a73a4",
>> >> +       NULL,
>> >> +};
>> >> +
>> >> +DT_MACHINE_START(R8A73A4_DT, "Generic R8A73A4 (Flattened Device Tree)")
>> >> +       .init_irq       = irqchip_init,
>> >
>> > Same thing for the default irqchip_init.
>>
>> Excellent! I believe the easiest is to leave it as-is for now and have
>> a clean-up series that can be merged late in the cycle after your
>> patch is in. I am not sure if that fits with your way of dealing with
>> the pull requests. At least that's how we used to do it for SH. If you
>> have any suggestion when to remove it please let me know.
>
> I don't want to get new patches during the merge window, but we can
> arrange a branch in the arm-soc tree that has both changes merged
> and the cleanup on top. We always send out pull requests for 10 to
> 15 branches in the merge window, and the later branches can be based
> on the earlier ones to deal with dependencies like this.
>
> In this particular case, it would also not hurt to do the cleanup
> in 3.11, since the patch is only cosmetic.

I agree that targeting v3.11 for this cleanup makes most sense. So I
kept the functions in V2.

Thanks,

/ magnus

[PATCH 03/04] ARM: shmobile: r8a73a4 IRQC support

[Arnd Bergmann]

On Friday 15 March 2013, Magnus Damm wrote:
> On Thu, Mar 14, 2013 at 10:43 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 14 March 2013, Magnus Damm wrote:

> > Coming back to INTC, are you planning to use the same binding for A and C?
> 
> I was not planning on that, no. To be honest, at this point I am not
> sure which way forward is best for A).
> 
> > Which of them the binding you posted earlier for?
> 
> Regarding A), I wrote some local DT prototype patches for INTC a year
> or two ago, showing how things could be done and how we can start
> using DT. Then I handed the job over to other people. However, from
> there my advice of incremental development was ignored and instead
> more complete bindings were developed directly without much review. So
> I wouldn't say that I posted the bindings myself. Right now I'm very
> hands-off in that area.

Ok.

> As for C), those DT bindings were done by me. They are however not
> compatible with A). The hardware is different. C) is basically a
> special case subset of A).

Makes sense.

> > When I looked at the existing code, I had the impression that doing a
> > binding for just the SH-Mobile SoCs that have an ARM core in them
> > (including those that also have an SH core) would be much easier than
> > doing a binding that also covers the older SH SoCs, since those are
> > much less uniform.
> 
> I agree that in some cases it may make sense to split the SH bits from
> ARM, but I wonder how much we would win for the INTC.
> 
> Right now I'm considering converting r8a7740 to use B) and C) (if
> possible), and if so then the only ARM SoC using A) for main interrupt
> controller left is sh7372.
> 
> For sh7372 we could simply try to use C) for board-level interrupts
> (and board level DT) but keep the SoC portion in C with A) until the
> SoC is being phased out. Or we could have a simple compatible
> "renesas,intc-sh7372" with tables in C using irq domain to support DT,
> but that would be exactly as my first incremental development task
> that wasn't followed...
> 
> What would you do?

Both of htese approaches sound fine. If there is only a single odd
one out, it makes sense to have a hardwired implementation for that
one. I rejected that approach originally because I wanted something
more generic, and it seems you have done exactly that with the
irq-renesas-intc-irqpin driver.

	Arnd

[PATCH 01/04] ARM: shmobile: Initial r8a73a4 SoC support

[Arnd Bergmann]

On Tuesday 19 March 2013, Magnus Damm wrote:

> >> >> +#ifdef CONFIG_USE_OF
> >> >> +void __init r8a73a4_add_standard_devices_dt(void)
> >> >> +{
> >> >> +       of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> >> >> +}
> >> >
> >> > I have a patch that will make this function definition the default, so you
> >> > no longer have to provide an init_machine callback if you don't do anything
> >> > special. It's ok to leave it in for now, but we might want to do a follow
> >> > up patch to remove it once both patches are merged.
> >>
> >> That's very nice! I am happy to hear that. Is that patch targeting v3.10?
> >
> > Yes, I just need to produce a new version based on 3.9-rc.
> 
> That is fine, but as you suggest below, perhaps it is easier to wait
> until post-v3.10?

I'll try to do a cleanup of all the remaining machine_desc callbacks
in arch/arm/mach-*/ as the final step of the 3.10 pull requests. Anything
that I miss can be left for 3.11, so don't worry about it.

	Arnd