[PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Magnus Damm]

mach-shmobile: Emma Mobile EV2 - first shot

[PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support
[PATCH 02/02] mach-shmobile: KZM9D board prototype support

This series adds experimental Emma Mobile EV2 support to
mach-shmobile. Yet another dual core Cortex-A9 SoC.

At this point only serial and timer is supported. Future work
includes GPIO, network device, SMP and DT support. If possible
it would be nice to use the common clocks on this platform.

To boot this on actual hardware you also need the following:
"[PATCH] serial8250-em: Emma Mobile UART driver V2"
"[PATCH] clocksource: em_sti: Emma Mobile STI driver"

Any reason to not put this in mach-shmobile?

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

 Does unfortunately not apply cleanly to the renesas
 git repository, so we need to figure out how to let
 this coexist with the new boards...
 
 arch/arm/mach-shmobile/Kconfig               |    9 +
 arch/arm/mach-shmobile/Makefile              |    2 
 arch/arm/mach-shmobile/board-kzm9d.c         |   44 +++++
 arch/arm/mach-shmobile/clock-emev2.c         |  206 ++++++++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/common.h |    6 
 arch/arm/mach-shmobile/intc-emev2.c          |   36 ++++
 arch/arm/mach-shmobile/setup-emev2.c         |  187 +++++++++++++++++++++++
 7 files changed, 490 insertions(+)

[PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Add base support for the Emma Mobile EV2 SoC
including UART0, UART1, UART2, UART3 and STI.

No pinmux or GPIO support is in place yet and
SMP needs more work as well.

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

 arch/arm/mach-shmobile/Kconfig               |    5 
 arch/arm/mach-shmobile/Makefile              |    1 
 arch/arm/mach-shmobile/clock-emev2.c         |  206 ++++++++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/common.h |    6 
 arch/arm/mach-shmobile/intc-emev2.c          |   36 ++++
 arch/arm/mach-shmobile/setup-emev2.c         |  187 +++++++++++++++++++++++
 6 files changed, 441 insertions(+)

--- 0010/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2012-05-03 20:45:56.000000000 +0900
@@ -41,6 +41,11 @@ config ARCH_R8A7779
 	select ARM_GIC
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 
+config ARCH_EMEV2
+	bool "Emma Mobile EV2"
+	select CPU_V7
+	select ARM_GIC
+
 comment "SH-Mobile Board Type"
 
 config MACH_G3EVM
--- 0001/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2012-05-03 20:45:56.000000000 +0900
@@ -12,6 +12,7 @@ obj-$(CONFIG_ARCH_SH7372)	+= setup-sh737
 obj-$(CONFIG_ARCH_SH73A0)	+= setup-sh73a0.o clock-sh73a0.o intc-sh73a0.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 intc-emev2.o
 
 # SMP objects
 smp-y				:= platsmp.o headsmp.o
--- /dev/null
+++ work/arch/arm/mach-shmobile/clock-emev2.c	2012-05-03 20:46:44.000000000 +0900
@@ -0,0 +1,206 @@
+/*
+ * Emma Mobile EV2 clock framework support
+ *
+ * Copyright (C) 2012  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>
+
+/* EMEV2 SMU registers */
+#define USIAU0_RSTCTRL 0xe0110094
+#define USIBU1_RSTCTRL 0xe01100ac
+#define USIBU2_RSTCTRL 0xe01100b0
+#define USIBU3_RSTCTRL 0xe01100b4
+#define STI_RSTCTRL 0xe0110124
+#define USIAU0GCLKCTRL 0xe01104a0
+#define USIBU1GCLKCTRL 0xe01104b8
+#define USIBU2GCLKCTRL 0xe01104bc
+#define USIBU3GCLKCTRL 0xe01104c0
+#define STIGCLKCTRL 0xe0110528
+#define USIAU0SCLKDIV 0xe011061c
+#define USIB2SCLKDIV 0xe011065c
+#define USIB3SCLKDIV 0xe0110660
+#define STI_CLKSEL 0xe0110688
+
+/* Fixed 32 KHz root clock from C32K pin */
+static struct clk c32k_clk = {
+	.rate           = 32768,
+};
+
+/* PLL3 multiplies C32K with 7000 */
+static unsigned long pll3_recalc(struct clk *clk)
+{
+	return clk->parent->rate * 7000;
+}
+
+static struct sh_clk_ops pll3_clk_ops = {
+	.recalc		= pll3_recalc,
+};
+
+static struct clk pll3_clk = {
+	.ops		= &pll3_clk_ops,
+	.parent		= &c32k_clk,
+};
+
+static struct clk *main_clks[] = {
+	&c32k_clk,
+	&pll3_clk,
+};
+
+enum { SCLKDIV_USIAU0, SCLKDIV_USIBU2, SCLKDIV_USIBU1, SCLKDIV_USIBU3,
+	SCLKDIV_NR };
+
+#define SCLKDIV(_reg, _shift)			\
+{								\
+	.parent		= &pll3_clk,				\
+	.enable_reg	= (void __iomem *)_reg,			\
+	.enable_bit	= _shift,				\
+}
+
+static struct clk sclkdiv_clks[SCLKDIV_NR] = {
+	[SCLKDIV_USIAU0] = SCLKDIV(USIAU0SCLKDIV, 0),
+	[SCLKDIV_USIBU2] = SCLKDIV(USIB2SCLKDIV, 16),
+	[SCLKDIV_USIBU1] = SCLKDIV(USIB2SCLKDIV, 0),
+	[SCLKDIV_USIBU3] = SCLKDIV(USIB3SCLKDIV, 0),
+};
+
+enum { GCLK_USIAU0_SCLK, GCLK_USIBU1_SCLK, GCLK_USIBU2_SCLK, GCLK_USIBU3_SCLK,
+	GCLK_STI_SCLK,
+	GCLK_NR };
+
+#define GCLK_SCLK(_parent, _reg) \
+{								\
+	.parent		= _parent,				\
+	.enable_reg	= (void __iomem *)_reg,			\
+	.enable_bit	= 1, /* SCLK_GCC */			\
+}
+
+static struct clk gclk_clks[GCLK_NR] = {
+	[GCLK_USIAU0_SCLK] = GCLK_SCLK(&sclkdiv_clks[SCLKDIV_USIAU0],
+				       USIAU0GCLKCTRL),
+	[GCLK_USIBU1_SCLK] = GCLK_SCLK(&sclkdiv_clks[SCLKDIV_USIBU1],
+				       USIBU1GCLKCTRL),
+	[GCLK_USIBU2_SCLK] = GCLK_SCLK(&sclkdiv_clks[SCLKDIV_USIBU2],
+				       USIBU2GCLKCTRL),
+	[GCLK_USIBU3_SCLK] = GCLK_SCLK(&sclkdiv_clks[SCLKDIV_USIBU3],
+				       USIBU3GCLKCTRL),
+	[GCLK_STI_SCLK] = GCLK_SCLK(&c32k_clk, STIGCLKCTRL),
+};
+
+static int emev2_gclk_enable(struct clk *clk)
+{
+	iowrite32(ioread32(clk->mapped_reg) | (1 << clk->enable_bit),
+		  clk->mapped_reg);
+	return 0;
+}
+
+static void emev2_gclk_disable(struct clk *clk)
+{
+	iowrite32(ioread32(clk->mapped_reg) & ~(1 << clk->enable_bit),
+		  clk->mapped_reg);
+}
+
+static struct sh_clk_ops emev2_gclk_clk_ops = {
+	.enable		= emev2_gclk_enable,
+	.disable	= emev2_gclk_disable,
+	.recalc		= followparent_recalc,
+};
+
+static int __init emev2_gclk_register(struct clk *clks, int nr)
+{
+	struct clk *clkp;
+	int ret = 0;
+	int k;
+
+	for (k = 0; !ret && (k < nr); k++) {
+		clkp = clks + k;
+		clkp->ops = &emev2_gclk_clk_ops;
+		ret |= clk_register(clkp);
+	}
+
+	return ret;
+}
+
+static unsigned long emev2_sclkdiv_recalc(struct clk *clk)
+{
+	unsigned int sclk_div;
+
+	sclk_div = (ioread32(clk->mapped_reg) >> clk->enable_bit) & 0xff;
+
+	return clk->parent->rate / (sclk_div + 1);
+}
+
+static struct sh_clk_ops emev2_sclkdiv_clk_ops = {
+	.recalc		= emev2_sclkdiv_recalc,
+};
+
+static int __init emev2_sclkdiv_register(struct clk *clks, int nr)
+{
+	struct clk *clkp;
+	int ret = 0;
+	int k;
+
+	for (k = 0; !ret && (k < nr); k++) {
+		clkp = clks + k;
+		clkp->ops = &emev2_sclkdiv_clk_ops;
+		ret |= clk_register(clkp);
+	}
+
+	return ret;
+}
+
+static struct clk_lookup lookups[] = {
+	CLKDEV_DEV_ID("serial8250-em.0", &gclk_clks[GCLK_USIAU0_SCLK]),
+	CLKDEV_DEV_ID("serial8250-em.1", &gclk_clks[GCLK_USIBU1_SCLK]),
+	CLKDEV_DEV_ID("serial8250-em.2", &gclk_clks[GCLK_USIBU2_SCLK]),
+	CLKDEV_DEV_ID("serial8250-em.3", &gclk_clks[GCLK_USIBU3_SCLK]),
+	CLKDEV_DEV_ID("em_sti.0", &gclk_clks[GCLK_STI_SCLK]),
+};
+
+void __init emev2_clock_init(void)
+{
+	int k, ret = 0;
+
+	/* setup STI timer to run on 37.768 kHz and deassert reset */
+	__raw_writel(0, STI_CLKSEL);
+	__raw_writel(1, STI_RSTCTRL);
+
+	/* deassert reset for UART0->UART3 */
+	__raw_writel(2, USIAU0_RSTCTRL);
+	__raw_writel(2, USIBU1_RSTCTRL);
+	__raw_writel(2, USIBU2_RSTCTRL);
+	__raw_writel(2, USIBU3_RSTCTRL);
+
+	for (k = 0; !ret && (k < ARRAY_SIZE(main_clks)); k++)
+		ret = clk_register(main_clks[k]);
+
+	if (!ret)
+		ret = emev2_sclkdiv_register(sclkdiv_clks, SCLKDIV_NR);
+
+	if (!ret)
+		ret = emev2_gclk_register(gclk_clks, GCLK_NR);
+
+	clkdev_add_table(lookups, ARRAY_SIZE(lookups));
+
+	if (!ret)
+		shmobile_clk_init();
+	else
+		panic("failed to setup emev2 clocks\n");
+}
--- 0003/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h	2012-05-03 20:45:56.000000000 +0900
@@ -85,4 +85,10 @@ extern void r8a7779_secondary_init(unsig
 extern int r8a7779_boot_secondary(unsigned int cpu);
 extern void r8a7779_smp_prepare_cpus(void);
 
+extern void emev2_init_irq(void);
+extern void emev2_map_io(void);
+extern void emev2_add_early_devices(void);
+extern void emev2_add_standard_devices(void);
+extern void emev2_clock_init(void);
+
 #endif /* __ARCH_MACH_COMMON_H */
--- /dev/null
+++ work/arch/arm/mach-shmobile/intc-emev2.c	2012-05-03 20:45:57.000000000 +0900
@@ -0,0 +1,36 @@
+/*
+ * Emma Mobile EV2 processor support - interrupts
+ *
+ * Copyright (C) 2012  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/init.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/io.h>
+#include <mach/common.h>
+#include <asm/hardware/gic.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+
+void __init emev2_init_irq(void)
+{
+	void __iomem *gic_dist_base = IOMEM(0xe0028000);
+	void __iomem *gic_cpu_base = IOMEM(0xe0020000);
+
+	/* use GIC to handle interrupts */
+	gic_init(0, 29, gic_dist_base, gic_cpu_base);
+}
--- /dev/null
+++ work/arch/arm/mach-shmobile/setup-emev2.c	2012-05-03 20:45:57.000000000 +0900
@@ -0,0 +1,187 @@
+/*
+ * Emma Mobile EV2 processor support
+ *
+ * Copyright (C) 2012  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/init.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/input.h>
+#include <linux/io.h>
+#include <mach/hardware.h>
+#include <mach/common.h>
+#include <mach/irqs.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/mach/time.h>
+
+static struct map_desc emev2_io_desc[] __initdata = {
+	/* 128K entity map for 0xe0020000 (GIC) */
+	{
+		.virtual	= 0xe0020000,
+		.pfn		= __phys_to_pfn(0xe0020000),
+		.length		= SZ_128K,
+		.type		= MT_UNCACHED
+	},
+	/* 128K entity map for 0xe0100000 (SMU) */
+	{
+		.virtual	= 0xe0100000,
+		.pfn		= __phys_to_pfn(0xe0100000),
+		.length		= SZ_128K,
+		.type		= MT_DEVICE
+	},
+};
+
+void __init emev2_map_io(void)
+{
+	iotable_init(emev2_io_desc, ARRAY_SIZE(emev2_io_desc));
+}
+
+/* UART */
+static struct resource uart0_resources[] = {
+	[0]	= {
+		.start	= 0xe1020000,
+		.end	= 0xe1020038 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1]	= {
+		.start	= 40,
+		.flags	= IORESOURCE_IRQ,
+	}
+};
+
+static struct platform_device uart0_device = {
+	.name		= "serial8250-em",
+	.id		= 0,
+	.num_resources	= ARRAY_SIZE(uart0_resources),
+	.resource	= uart0_resources,
+};
+
+static struct resource uart1_resources[] = {
+	[0]	= {
+		.start	= 0xe1030000,
+		.end	= 0xe1030038 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1]	= {
+		.start	= 41,
+		.flags	= IORESOURCE_IRQ,
+	}
+};
+
+static struct platform_device uart1_device = {
+	.name		= "serial8250-em",
+	.id		= 1,
+	.num_resources	= ARRAY_SIZE(uart1_resources),
+	.resource	= uart1_resources,
+};
+
+static struct resource uart2_resources[] = {
+	[0]	= {
+		.start	= 0xe1040000,
+		.end	= 0xe1040038 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1]	= {
+		.start	= 42,
+		.flags	= IORESOURCE_IRQ,
+	}
+};
+
+static struct platform_device uart2_device = {
+	.name		= "serial8250-em",
+	.id		= 2,
+	.num_resources	= ARRAY_SIZE(uart2_resources),
+	.resource	= uart2_resources,
+};
+
+static struct resource uart3_resources[] = {
+	[0]	= {
+		.start	= 0xe1050000,
+		.end	= 0xe1050038 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1]	= {
+		.start	= 43,
+		.flags	= IORESOURCE_IRQ,
+	}
+};
+
+static struct platform_device uart3_device = {
+	.name		= "serial8250-em",
+	.id		= 3,
+	.num_resources	= ARRAY_SIZE(uart3_resources),
+	.resource	= uart3_resources,
+};
+
+/* STI */
+static struct resource sti_resources[] = {
+	[0] = {
+		.name	= "STI",
+		.start	= 0xe0180000,
+		.end	= 0xe0180053,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= 157,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device sti_device = {
+	.name		= "em_sti",
+	.id		= 0,
+	.resource	= sti_resources,
+	.num_resources	= ARRAY_SIZE(sti_resources),
+};
+
+static struct platform_device *emev2_early_devices[] __initdata = {
+	&uart0_device,
+	&uart1_device,
+	&uart2_device,
+	&uart3_device,
+};
+
+static struct platform_device *emev2_late_devices[] __initdata = {
+	&sti_device,
+};
+
+void __init emev2_add_standard_devices(void)
+{
+	emev2_clock_init();
+
+	platform_add_devices(emev2_early_devices,
+			     ARRAY_SIZE(emev2_early_devices));
+
+	platform_add_devices(emev2_late_devices,
+			     ARRAY_SIZE(emev2_late_devices));
+}
+
+void __init emev2_add_early_devices(void)
+{
+	shmobile_setup_delay(533, 1, 3); /* Cortex-A9 @ 533MHz */
+
+	early_platform_add_devices(emev2_early_devices,
+				   ARRAY_SIZE(emev2_early_devices));
+
+	/* setup early console here as well */
+	shmobile_setup_console();
+}
+

[PATCH 02/02] mach-shmobile: KZM9D board prototype support

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Add experimental KZM9D board support that makes
use of the Emma Mobile EV2 SoC code.

Nothing except serial ports and timer are supported
at this point. On-board ethernet support can be
added after proper GPIO bindings are implemented.
Without GPIO we cannot make use of external IRQs.

Not-yet-signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/mach-shmobile/Kconfig       |    4 +++
 arch/arm/mach-shmobile/Makefile      |    1 
 arch/arm/mach-shmobile/board-kzm9d.c |   44 ++++++++++++++++++++++++++++++++++
 3 files changed, 49 insertions(+)

--- 0011/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2012-05-03 20:50:52.000000000 +0900
@@ -103,6 +103,10 @@ config MACH_MARZEN
 	depends on ARCH_R8A7779
 	select ARCH_REQUIRE_GPIOLIB
 
+config MACH_KZM9D
+	bool "KZM9D board"
+	depends on ARCH_EMEV2
+
 comment "SH-Mobile System Configuration"
 
 config CPU_HAS_INTEVT
--- 0011/arch/arm/mach-shmobile/Makefile
+++ work/arch/arm/mach-shmobile/Makefile	2012-05-03 20:50:52.000000000 +0900
@@ -50,6 +50,7 @@ obj-$(CONFIG_MACH_MACKEREL)	+= board-mac
 obj-$(CONFIG_MACH_KOTA2)	+= board-kota2.o
 obj-$(CONFIG_MACH_BONITO)	+= board-bonito.o
 obj-$(CONFIG_MACH_MARZEN)	+= board-marzen.o
+obj-$(CONFIG_MACH_KZM9D)	+= board-kzm9d.o
 
 # Framework support
 obj-$(CONFIG_SMP)		+= $(smp-y)
--- /dev/null
+++ work/arch/arm/mach-shmobile/board-kzm9d.c	2012-05-03 20:51:20.000000000 +0900
@@ -0,0 +1,44 @@
+/*
+ * kzm9d board support
+ *
+ * Copyright (C) 2012  Renesas Solutions Corp.
+ * Copyright (C) 2012  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/init.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <mach/hardware.h>
+#include <mach/common.h>
+#include <mach/irqs.h>
+#include <asm/mach-types.h>
+#include <asm/mach/map.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+#include <asm/hardware/gic.h>
+#include <asm/traps.h>
+
+MACHINE_START(KZM9D, "kzm9d")
+	.map_io		= emev2_map_io,
+	.init_early	= emev2_add_early_devices,
+	.nr_irqs	= NR_IRQS_LEGACY,
+	.init_irq	= emev2_init_irq,
+	.handle_irq	= gic_handle_irq,
+	.init_machine	= emev2_add_standard_devices,
+	.timer		= &shmobile_timer,
+MACHINE_END

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Rafael J. Wysocki]

On Thursday, May 03, 2012, Magnus Damm wrote:
> mach-shmobile: Emma Mobile EV2 - first shot
> 
> [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support
> [PATCH 02/02] mach-shmobile: KZM9D board prototype support
> 
> This series adds experimental Emma Mobile EV2 support to
> mach-shmobile. Yet another dual core Cortex-A9 SoC.
> 
> At this point only serial and timer is supported. Future work
> includes GPIO, network device, SMP and DT support. If possible
> it would be nice to use the common clocks on this platform.
> 
> To boot this on actual hardware you also need the following:
> "[PATCH] serial8250-em: Emma Mobile UART driver V2"
> "[PATCH] clocksource: em_sti: Emma Mobile STI driver"
> 
> Any reason to not put this in mach-shmobile?
> 
> Partially-signed-off-by: Magnus Damm <damm@opensource.se>
> ---
> 
>  Does unfortunately not apply cleanly to the renesas
>  git repository,

Well, this sounds like a reason.

>  so we need to figure out how to let
>  this coexist with the new boards...

Surely.

Thanks,
Rafael


>  arch/arm/mach-shmobile/Kconfig               |    9 +
>  arch/arm/mach-shmobile/Makefile              |    2 
>  arch/arm/mach-shmobile/board-kzm9d.c         |   44 +++++
>  arch/arm/mach-shmobile/clock-emev2.c         |  206 ++++++++++++++++++++++++++
>  arch/arm/mach-shmobile/include/mach/common.h |    6 
>  arch/arm/mach-shmobile/intc-emev2.c          |   36 ++++
>  arch/arm/mach-shmobile/setup-emev2.c         |  187 +++++++++++++++++++++++
>  7 files changed, 490 insertions(+)
> 
> 

Re: [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support

[Arnd Bergmann]

On Thursday 03 May 2012, Magnus Damm wrote:

> +
> +/* EMEV2 SMU registers */
> +#define USIAU0_RSTCTRL 0xe0110094
> +#define USIBU1_RSTCTRL 0xe01100ac
> +#define USIBU2_RSTCTRL 0xe01100b0
> +#define USIBU3_RSTCTRL 0xe01100b4
> +#define STI_RSTCTRL 0xe0110124
> +#define USIAU0GCLKCTRL 0xe01104a0
> +#define USIBU1GCLKCTRL 0xe01104b8
> +#define USIBU2GCLKCTRL 0xe01104bc
> +#define USIBU3GCLKCTRL 0xe01104c0
> +#define STIGCLKCTRL 0xe0110528
> +#define USIAU0SCLKDIV 0xe011061c
> +#define USIB2SCLKDIV 0xe011065c
> +#define USIB3SCLKDIV 0xe0110660
> +#define STI_CLKSEL 0xe0110688

Please cast to __iomem* here, e.g. using the IOMEM() macro, as these are
virtual addresses.

> +void __init emev2_clock_init(void)
> +{
> +	int k, ret = 0;
> +
> +	/* setup STI timer to run on 37.768 kHz and deassert reset */
> +	__raw_writel(0, STI_CLKSEL);
> +	__raw_writel(1, STI_RSTCTRL);
> +
> +	/* deassert reset for UART0->UART3 */
> +	__raw_writel(2, USIAU0_RSTCTRL);
> +	__raw_writel(2, USIBU1_RSTCTRL);
> +	__raw_writel(2, USIBU2_RSTCTRL);
> +	__raw_writel(2, USIBU3_RSTCTRL);

Better use iowrite32 or writel or writel_relaxed here, but not __raw_*.

> --- 0003/arch/arm/mach-shmobile/include/mach/common.h
> +++ work/arch/arm/mach-shmobile/include/mach/common.h	2012-05-03 20:45:56.000000000 +0900
> @@ -85,4 +85,10 @@ extern void r8a7779_secondary_init(unsig
>  extern int r8a7779_boot_secondary(unsigned int cpu);
>  extern void r8a7779_smp_prepare_cpus(void);
>  
> +extern void emev2_init_irq(void);
> +extern void emev2_map_io(void);
> +extern void emev2_add_early_devices(void);
> +extern void emev2_add_standard_devices(void);
> +extern void emev2_clock_init(void);
> +
>  #endif /* __ARCH_MACH_COMMON_H */

I would feel more comfortable with a separate header for this than putting
it into the same file as everything else, but it's not important to me.

> --- /dev/null
> +++ work/arch/arm/mach-shmobile/intc-emev2.c	2012-05-03 20:45:57.000000000 +0900

> +
> +void __init emev2_init_irq(void)
> +{
> +	void __iomem *gic_dist_base = IOMEM(0xe0028000);
> +	void __iomem *gic_cpu_base = IOMEM(0xe0020000);
> +
> +	/* use GIC to handle interrupts */
> +	gic_init(0, 29, gic_dist_base, gic_cpu_base);
> +}

This could just go into teh setup-emev2.c file, it doesn't actually do much,
and the other file is where the constants are coming from anyway. Then you
can put it right next to this code:

> +static struct map_desc emev2_io_desc[] __initdata = {
> +	/* 128K entity map for 0xe0020000 (GIC) */
> +	{
> +		.virtual	= 0xe0020000,
> +		.pfn		= __phys_to_pfn(0xe0020000),
> +		.length		= SZ_128K,
> +		.type		= MT_UNCACHED
> +	},
> +	/* 128K entity map for 0xe0100000 (SMU) */
> +	{
> +		.virtual	= 0xe0100000,
> +		.pfn		= __phys_to_pfn(0xe0100000),
> +		.length		= SZ_128K,
> +		.type		= MT_DEVICE
> +	},
> +};
> +
> +void __init emev2_map_io(void)
> +{
> +	iotable_init(emev2_io_desc, ARRAY_SIZE(emev2_io_desc));
> +}


	Arnd

Re: [PATCH 02/02] mach-shmobile: KZM9D board prototype support

[Arnd Bergmann]

On Thursday 03 May 2012, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
> 
> Add experimental KZM9D board support that makes
> use of the Emma Mobile EV2 SoC code.
> 
> Nothing except serial ports and timer are supported
> at this point. On-board ethernet support can be
> added after proper GPIO bindings are implemented.
> Without GPIO we cannot make use of external IRQs.
> 
> Not-yet-signed-off-by: Magnus Damm <damm@opensource.se>

Given that this doesn't do anything, I see no reason to leave this
machine based on ATAG rather than DT probing:

+MACHINE_START(KZM9D, "kzm9d")
+       .map_io         = emev2_map_io,
+       .init_early     = emev2_add_early_devices,
+       .nr_irqs        = NR_IRQS_LEGACY,
+       .init_irq       = emev2_init_irq,
+       .handle_irq     = gic_handle_irq,
+       .init_machine   = emev2_add_standard_devices,
+       .timer          = &shmobile_timer,
+MACHINE_END

Just make this DT_MACHINE_START and add a minimal .dts file for
it that has the right compatible value. That will already enable
people to add devices in their .dts files without touching
the platform code.

It would also be really easy to just add DT support for the three
devices you actually support (GIC, STI, uart), because two of
them already have bindings and the third one is a new driver.
When we discussed this new soc earlier, you said that using DT
based booting would be extra work, but given the set of devices
that you are putting into this, I don't think that argument holds
any more.

	Arnd

Re: [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support

[Arnd Bergmann]

On Friday 04 May 2012, Arnd Bergmann wrote:
> 
> On Thursday 03 May 2012, Magnus Damm wrote:
> 
> > +
> > +/* EMEV2 SMU registers */
> > +#define USIAU0_RSTCTRL 0xe0110094
> > +#define USIBU1_RSTCTRL 0xe01100ac
> > +#define USIBU2_RSTCTRL 0xe01100b0
> > +#define USIBU3_RSTCTRL 0xe01100b4
> > +#define STI_RSTCTRL 0xe0110124
> > +#define USIAU0GCLKCTRL 0xe01104a0
> > +#define USIBU1GCLKCTRL 0xe01104b8
> > +#define USIBU2GCLKCTRL 0xe01104bc
> > +#define USIBU3GCLKCTRL 0xe01104c0
> > +#define STIGCLKCTRL 0xe0110528
> > +#define USIAU0SCLKDIV 0xe011061c
> > +#define USIB2SCLKDIV 0xe011065c
> > +#define USIB3SCLKDIV 0xe0110660
> > +#define STI_CLKSEL 0xe0110688
> 
> Please cast to __iomem* here, e.g. using the IOMEM() macro, as these are
> virtual addresses.

I should revise that: there is no excuse to hardcode these virtual address
here at all. Just use call ioremap() on the physical address for the
clock registers (0xe0110000) and use the resulting pointer with an
offset that you define locally in this file.

It is safe to call ioremap when you get to emev2_clock_init()
and you will still get a large page mapping with the recent
code reworks for map_desc.

Regarding the iotable that is currently defined as

+static struct map_desc emev2_io_desc[] __initdata = {
+       /* 128K entity map for 0xe0020000 (GIC) */
+       {
+               .virtual        = 0xe0020000,
+               .pfn            = __phys_to_pfn(0xe0020000),
+               .length         = SZ_128K,
+               .type           = MT_UNCACHED
+       },
+       /* 128K entity map for 0xe0100000 (SMU) */
+       {
+               .virtual        = 0xe0100000,
+               .pfn            = __phys_to_pfn(0xe0100000),
+               .length         = SZ_128K,
+               .type           = MT_DEVICE
+       },
+};

I would recommend just mapping the entire 16MB page around this, or at least
2 MB, so you can benefit from the larger mappings. If you don't do that,
better remove the entire iotable registration and rely on ioremap, the
result will be the same and you can be prevent any hacks from creeping in
that rely on the virtual address being the same as the physical address.

	Arnd

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Arnd Bergmann]

On Thursday 03 May 2012, Magnus Damm wrote:
> mach-shmobile: Emma Mobile EV2 - first shot
> 
> [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support
> [PATCH 02/02] mach-shmobile: KZM9D board prototype support
> 
> This series adds experimental Emma Mobile EV2 support to
> mach-shmobile. Yet another dual core Cortex-A9 SoC.
> 
> At this point only serial and timer is supported. Future work
> includes GPIO, network device, SMP and DT support. If possible
> it would be nice to use the common clocks on this platform.
> 
> To boot this on actual hardware you also need the following:
> "[PATCH] serial8250-em: Emma Mobile UART driver V2"
> "[PATCH] clocksource: em_sti: Emma Mobile STI driver"
> 
> Any reason to not put this in mach-shmobile?

Well, from all I can tell it shares basically zero code with the
rest of mach-shmobile, so I would be more comfortable with creating
a new mach-emma directory for this.

Clearly you have an interest in building it into the same kernel
as the shmobile/rmobile platforms, but there seems to be little
technical reason to keep them together. Since we are still missing
a bit of infrastructure to actually build multiple platform
directories together, how about doing this similar to some of
the mach-s3c24* directories:?

You can have a single Kconfig entry for shmobile and emma, but
leave the code in separate directories, and just refer to the
arch/arm/mach-shmobile/include/mach/ directory for the global
headers (they are obviously identical right now). The additions
to mach/common.h can easily become a local header file instead
of getting listed in mach/*.h. I believe you don't actually need
the other headers you currently include (mach/hardware.h, mach/irqs.h),
so it would be completely standalone aside from the header files
that are required for building, and it can still be built
together with shmobile.

	Arnd

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Rafael J. Wysocki]

On Friday, May 04, 2012, Arnd Bergmann wrote:
> On Thursday 03 May 2012, Magnus Damm wrote:
> > mach-shmobile: Emma Mobile EV2 - first shot
> > 
> > [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support
> > [PATCH 02/02] mach-shmobile: KZM9D board prototype support
> > 
> > This series adds experimental Emma Mobile EV2 support to
> > mach-shmobile. Yet another dual core Cortex-A9 SoC.
> > 
> > At this point only serial and timer is supported. Future work
> > includes GPIO, network device, SMP and DT support. If possible
> > it would be nice to use the common clocks on this platform.
> > 
> > To boot this on actual hardware you also need the following:
> > "[PATCH] serial8250-em: Emma Mobile UART driver V2"
> > "[PATCH] clocksource: em_sti: Emma Mobile STI driver"
> > 
> > Any reason to not put this in mach-shmobile?
> 
> Well, from all I can tell it shares basically zero code with the
> rest of mach-shmobile, so I would be more comfortable with creating
> a new mach-emma directory for this.

I'm not sure if I understand your point correctly, so please let me clarify.

Do you think it's better to have a separate mach-emma directory for the
new hardware because technically it is a different platform and the fact
that it was developed by the same manufacturer as the mach-shmobile hardware
is less important?

Rafael

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Arnd Bergmann]

On Friday 04 May 2012, Rafael J. Wysocki wrote:
> I'm not sure if I understand your point correctly, so please let me clarify.
> 
> Do you think it's better to have a separate mach-emma directory for the
> new hardware because technically it is a different platform and the fact
> that it was developed by the same manufacturer as the mach-shmobile hardware
> is less important?

Yes, that was my point. Compare this to how we have omap and davinci for TI,
orion and pxa for Marvell, or mxs and imx for Freescale. These are all
for the most part independent developments that happened to end up being
owned by the same company.

We try to group code based on technical similarities, not on who makes them.
If you are able to share code between multiple completely independent socs
you work on, the result shouldn't be to put them into a directory you "own",
but to generalize the common parts so they can be shared with everyone else,
too.

	Arnd

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Rafael J. Wysocki]

On Saturday, May 05, 2012, Arnd Bergmann wrote:
> On Friday 04 May 2012, Rafael J. Wysocki wrote:
> > I'm not sure if I understand your point correctly, so please let me clarify.
> > 
> > Do you think it's better to have a separate mach-emma directory for the
> > new hardware because technically it is a different platform and the fact
> > that it was developed by the same manufacturer as the mach-shmobile hardware
> > is less important?
> 
> Yes, that was my point. Compare this to how we have omap and davinci for TI,
> orion and pxa for Marvell, or mxs and imx for Freescale. These are all
> for the most part independent developments that happened to end up being
> owned by the same company.
> 
> We try to group code based on technical similarities, not on who makes them.
> If you are able to share code between multiple completely independent socs
> you work on, the result shouldn't be to put them into a directory you "own",
> but to generalize the common parts so they can be shared with everyone else,
> too.

This works a slightly different way for the Renesas SoCs, though.  The
mach-shmobile code is (almost) entirely specific to the SoCs and boards and
everything else is already under drivers/ and elsewhere.  That's because
much of that code is shared between the ARM and SH architectures (since there
are SH CPU core in many of those systems along with the ARM CPU cores).
So we generalize the common parts by putting them out of arch/arm rather
than by putting them into a common place in there.

Now, if you insist on us having a separate mach- directory for every platform
(SoC), we can do that I think, but then we should start with splitting up the
existing mach-shmobile into a number of SoC-specific directories rather than
adding new mach- directories for random new parts, because that goes against
our development history to date, which is important too IMHO.

Thanks,
Rafael

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Arnd Bergmann]

On Saturday 05 May 2012, Rafael J. Wysocki wrote:
> Now, if you insist on us having a separate mach- directory for every platform
> (SoC), we can do that I think, but then we should start with splitting up the
> existing mach-shmobile into a number of SoC-specific directories rather than
> adding new mach- directories for random new parts, because that goes against
> our development history to date, which is important too IMHO.

All the chips in there so far share a common ancestry and they all use a
significant subset of the same drivers shared with arch/sh: i2c-sh_mobile,
sh-dma-engine, sh_cmt, sh-sci, sh_tmu, intc, pfc and sh_clk. AFAICT, this one
uses none of those and apparently was developed by NEC before the merger with
Renesas.

	Arnd

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Rafael J. Wysocki]

On Saturday, May 05, 2012, Arnd Bergmann wrote:
> On Saturday 05 May 2012, Rafael J. Wysocki wrote:
> > Now, if you insist on us having a separate mach- directory for every platform
> > (SoC), we can do that I think, but then we should start with splitting up the
> > existing mach-shmobile into a number of SoC-specific directories rather than
> > adding new mach- directories for random new parts, because that goes against
> > our development history to date, which is important too IMHO.
> 
> All the chips in there so far share a common ancestry and they all use a
> significant subset of the same drivers shared with arch/sh: i2c-sh_mobile,
> sh-dma-engine, sh_cmt, sh-sci, sh_tmu, intc, pfc and sh_clk. AFAICT, this one
> uses none of those and apparently was developed by NEC before the merger with
> Renesas.

I see.  So your opinion is that it may have more in common with the other
ARM-based platforms?

Rafael

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Arnd Bergmann]

On Saturday 05 May 2012, Rafael J. Wysocki wrote:
> > All the chips in there so far share a common ancestry and they all use a
> > significant subset of the same drivers shared with arch/sh: i2c-sh_mobile,
> > sh-dma-engine, sh_cmt, sh-sci, sh_tmu, intc, pfc and sh_clk. AFAICT, this one
> > uses none of those and apparently was developed by NEC before the merger with
> > Renesas.
> 
> I see.  So your opinion is that it may have more in common with the other
> ARM-based platforms?

Not with any one in particular, although there are a lot of similarities between
recent Cortex-A9 based designs. I just think it would be more logical to put the
files into a new mach-emma directory in the same way that every other family has
its own directory.

As I said, I don't mind if you share infrastructure with mach-shmobile, like
using the same mach/*.h header files, but if you end up sharing actual code,
it would be nicer to put it into some location where it can also be shared by
other platforms.

	Arnd

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Magnus Damm]

On Sun, May 6, 2012 at 4:21 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 05 May 2012, Rafael J. Wysocki wrote:
>> Now, if you insist on us having a separate mach- directory for every platform
>> (SoC), we can do that I think, but then we should start with splitting up the
>> existing mach-shmobile into a number of SoC-specific directories rather than
>> adding new mach- directories for random new parts, because that goes against
>> our development history to date, which is important too IMHO.
>
> All the chips in there so far share a common ancestry and they all use a
> significant subset of the same drivers shared with arch/sh: i2c-sh_mobile,
> sh-dma-engine, sh_cmt, sh-sci, sh_tmu, intc, pfc and sh_clk. AFAICT, this one
> uses none of those and apparently was developed by NEC before the merger with
> Renesas.

Please allow me to jump in here for a second.

You are right that none of the current in-tree SoCs were developed by
NEC, but exactly which bits that end up inside the SoC varies quite a
bit. The r8a7779 is for instance in the R-Car line which I believe for
some reason has more similarities with ex-NEC chips. The pinmux is not
that different from Emma mobile. Some timers and serial ports are
shared with other SoCs but many other IP blocks have nothing in common
with other mach-shmobile SoCs. But I sort of fail to see why this
matters since it's stuff kept outside of arch/arm anyways. As you
probably know the r8a7779 SoC is already merged in mach-shmobile but
we can of course move it out if that helps.

Also, the more the merrier. Apart from NEC the current set of SoCs
contain IP from Renesas which historically is a mix of Hitachi and
Mitsubishi. Plus the regular set of ARM and SGX IP of course, like
most vendors these days.

So if all these things are moved out of arch/arm (which I believe is
the right way forward) then what is the point of having mach
directories at all? In the end it's some random ARM IP with I/O
devices hanging off it. With that in mind i'd rather work on putting
the Emma Mobile stuff in a common arch/arm location than create yet
another separate directory for something that isn't really special at
all.

Cheers,

/ magnus

Re: [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support

[Magnus Damm]

On Fri, May 4, 2012 at 10:07 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 03 May 2012, Magnus Damm wrote:
>
>> +
>> +/* EMEV2 SMU registers */
>> +#define USIAU0_RSTCTRL 0xe0110094
>> +#define USIBU1_RSTCTRL 0xe01100ac
>> +#define USIBU2_RSTCTRL 0xe01100b0
>> +#define USIBU3_RSTCTRL 0xe01100b4
>> +#define STI_RSTCTRL 0xe0110124
>> +#define USIAU0GCLKCTRL 0xe01104a0
>> +#define USIBU1GCLKCTRL 0xe01104b8
>> +#define USIBU2GCLKCTRL 0xe01104bc
>> +#define USIBU3GCLKCTRL 0xe01104c0
>> +#define STIGCLKCTRL 0xe0110528
>> +#define USIAU0SCLKDIV 0xe011061c
>> +#define USIB2SCLKDIV 0xe011065c
>> +#define USIB3SCLKDIV 0xe0110660
>> +#define STI_CLKSEL 0xe0110688
>
> Please cast to __iomem* here, e.g. using the IOMEM() macro, as these are
> virtual addresses.

Sure, will do!

>> +void __init emev2_clock_init(void)
>> +{
>> +     int k, ret = 0;
>> +
>> +     /* setup STI timer to run on 37.768 kHz and deassert reset */
>> +     __raw_writel(0, STI_CLKSEL);
>> +     __raw_writel(1, STI_RSTCTRL);
>> +
>> +     /* deassert reset for UART0->UART3 */
>> +     __raw_writel(2, USIAU0_RSTCTRL);
>> +     __raw_writel(2, USIBU1_RSTCTRL);
>> +     __raw_writel(2, USIBU2_RSTCTRL);
>> +     __raw_writel(2, USIBU3_RSTCTRL);
>
> Better use iowrite32 or writel or writel_relaxed here, but not __raw_*.

Ok. Would you like us to convert exiting code for other SoCs as well?

>> --- 0003/arch/arm/mach-shmobile/include/mach/common.h
>> +++ work/arch/arm/mach-shmobile/include/mach/common.h 2012-05-03 20:45:56.000000000 +0900
>> @@ -85,4 +85,10 @@ extern void r8a7779_secondary_init(unsig
>>  extern int r8a7779_boot_secondary(unsigned int cpu);
>>  extern void r8a7779_smp_prepare_cpus(void);
>>
>> +extern void emev2_init_irq(void);
>> +extern void emev2_map_io(void);
>> +extern void emev2_add_early_devices(void);
>> +extern void emev2_add_standard_devices(void);
>> +extern void emev2_clock_init(void);
>> +
>>  #endif /* __ARCH_MACH_COMMON_H */
>
> I would feel more comfortable with a separate header for this than putting
> it into the same file as everything else, but it's not important to me.

I've been thinking about something along those lines myself too.

Perhaps I can also move the existing soc symbols in common.h into
separate per-soc header files, like for instance moving the sh7372
symbols to sh7372.h. Not sure if we have enough time for the upcoming
merge window though, when do you need the code?

>> --- /dev/null
>> +++ work/arch/arm/mach-shmobile/intc-emev2.c  2012-05-03 20:45:57.000000000 +0900
>
>> +
>> +void __init emev2_init_irq(void)
>> +{
>> +     void __iomem *gic_dist_base = IOMEM(0xe0028000);
>> +     void __iomem *gic_cpu_base = IOMEM(0xe0020000);
>> +
>> +     /* use GIC to handle interrupts */
>> +     gic_init(0, 29, gic_dist_base, gic_cpu_base);
>> +}
>
> This could just go into teh setup-emev2.c file, it doesn't actually do much,
> and the other file is where the constants are coming from anyway. Then you
> can put it right next to this code:

Sure, will do.

>> +static struct map_desc emev2_io_desc[] __initdata = {
>> +     /* 128K entity map for 0xe0020000 (GIC) */
>> +     {
>> +             .virtual        = 0xe0020000,
>> +             .pfn            = __phys_to_pfn(0xe0020000),
>> +             .length         = SZ_128K,
>> +             .type           = MT_UNCACHED
>> +     },
>> +     /* 128K entity map for 0xe0100000 (SMU) */
>> +     {
>> +             .virtual        = 0xe0100000,
>> +             .pfn            = __phys_to_pfn(0xe0100000),
>> +             .length         = SZ_128K,
>> +             .type           = MT_DEVICE
>> +     },
>> +};
>> +
>> +void __init emev2_map_io(void)
>> +{
>> +     iotable_init(emev2_io_desc, ARRAY_SIZE(emev2_io_desc));
>> +}

As you said, this iotable can most likely go away too. The only valid
use case I can think of (which is not included above) is our early
platform driver based console. Basically, it's the 8250_em driver
being probed as early as possible. This allows us to get console
output at MACHINE->init_early() timing. To get that working we rely on
having entity mappings in our iotable so ioremap() can give us those
early on. Something does however seem busted with the early ioremap()
- but I need to spend more time to investigate that. And this is
totally untested with DT, so it needs more work in general.

I intend to post some SMP support patch together with some DT support
tomorrow. I also have some GPIO code and some board-level network
support. Ideally I'd like to go DT-only, but I'm a bit unsure how to
tie in the SMP bits in a DT-only scenario. And we still have the
clocks.

If you have time, please let me know how you think my upcoming SMP
patches can be reworked to be more DT friendly. Also, please note that
those new patches will still be based on the old V1, but I'll rework
it all to fit whichever location you prefer.

Thanks for your help!

/ magnus

Re: [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support

[Arnd Bergmann]

On Tuesday 08 May 2012, Magnus Damm wrote:
> >> +void __init emev2_clock_init(void)
> >> +{
> >> +     int k, ret = 0;
> >> +
> >> +     /* setup STI timer to run on 37.768 kHz and deassert reset */
> >> +     __raw_writel(0, STI_CLKSEL);
> >> +     __raw_writel(1, STI_RSTCTRL);
> >> +
> >> +     /* deassert reset for UART0->UART3 */
> >> +     __raw_writel(2, USIAU0_RSTCTRL);
> >> +     __raw_writel(2, USIBU1_RSTCTRL);
> >> +     __raw_writel(2, USIBU2_RSTCTRL);
> >> +     __raw_writel(2, USIBU3_RSTCTRL);
> >
> > Better use iowrite32 or writel or writel_relaxed here, but not __raw_*.
> 
> Ok. Would you like us to convert exiting code for other SoCs as well?

In the long run yes, but there is no need to hurry. I just want to stop
more of this from getting added because at some point we might have to
change it all.

> >> --- 0003/arch/arm/mach-shmobile/include/mach/common.h
> >> +++ work/arch/arm/mach-shmobile/include/mach/common.h 2012-05-03 20:45:56.000000000 +0900
> >> @@ -85,4 +85,10 @@ extern void r8a7779_secondary_init(unsig
> >>  extern int r8a7779_boot_secondary(unsigned int cpu);
> >>  extern void r8a7779_smp_prepare_cpus(void);
> >>
> >> +extern void emev2_init_irq(void);
> >> +extern void emev2_map_io(void);
> >> +extern void emev2_add_early_devices(void);
> >> +extern void emev2_add_standard_devices(void);
> >> +extern void emev2_clock_init(void);
> >> +
> >>  #endif /* __ARCH_MACH_COMMON_H */
> >
> > I would feel more comfortable with a separate header for this than putting
> > it into the same file as everything else, but it's not important to me.
> 
> I've been thinking about something along those lines myself too.
> 
> Perhaps I can also move the existing soc symbols in common.h into
> separate per-soc header files, like for instance moving the sh7372
> symbols to sh7372.h. Not sure if we have enough time for the upcoming
> merge window though, when do you need the code?

Hard to say. Depends on whether there will be an -rc7. Sooner is better,
but again I care more about the new stuff here than about changing the
existing bits.

> >> +static struct map_desc emev2_io_desc[] __initdata = {
> >> +     /* 128K entity map for 0xe0020000 (GIC) */
> >> +     {
> >> +             .virtual        = 0xe0020000,
> >> +             .pfn            = __phys_to_pfn(0xe0020000),
> >> +             .length         = SZ_128K,
> >> +             .type           = MT_UNCACHED
> >> +     },
> >> +     /* 128K entity map for 0xe0100000 (SMU) */
> >> +     {
> >> +             .virtual        = 0xe0100000,
> >> +             .pfn            = __phys_to_pfn(0xe0100000),
> >> +             .length         = SZ_128K,
> >> +             .type           = MT_DEVICE
> >> +     },
> >> +};
> >> +
> >> +void __init emev2_map_io(void)
> >> +{
> >> +     iotable_init(emev2_io_desc, ARRAY_SIZE(emev2_io_desc));
> >> +}
> 
> As you said, this iotable can most likely go away too. The only valid
> use case I can think of (which is not included above) is our early
> platform driver based console. Basically, it's the 8250_em driver
> being probed as early as possible. This allows us to get console
> output at MACHINE->init_early() timing. To get that working we rely on
> having entity mappings in our iotable so ioremap() can give us those
> early on. Something does however seem busted with the early ioremap()
> - but I need to spend more time to investigate that. And this is
> totally untested with DT, so it needs more work in general.

Do you actually need to do anything at init_early() or map_io() time
that needs debugging these days?
We already have too many different ways of doing early console output,
but if you cannot use the drivers/tty/serial/8250/8250_early.c code,
maybe it makes sense to just move the map_io() call for your 8250
port into that driver.

> I intend to post some SMP support patch together with some DT support
> tomorrow. I also have some GPIO code and some board-level network
> support. Ideally I'd like to go DT-only, but I'm a bit unsure how to
> tie in the SMP bits in a DT-only scenario. And we still have the
> clocks.

Don't worry about SMP and clocks for now for moving to DT, just do
the easy bits that are directly connected to the SoC and that have
existing bindings or those that can be trivially added.

	Arnd

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Arnd Bergmann]

On Sunday 06 May 2012, Magnus Damm wrote:
> Please allow me to jump in here for a second.
> 
> You are right that none of the current in-tree SoCs were developed by
> NEC, but exactly which bits that end up inside the SoC varies quite a
> bit. The r8a7779 is for instance in the R-Car line which I believe for
> some reason has more similarities with ex-NEC chips. The pinmux is not
> that different from Emma mobile. Some timers and serial ports are
> shared with other SoCs but many other IP blocks have nothing in common
> with other mach-shmobile SoCs. But I sort of fail to see why this
> matters since it's stuff kept outside of arch/arm anyways. As you
> probably know the r8a7779 SoC is already merged in mach-shmobile but
> we can of course move it out if that helps.

I want the structure to make sense and be consistent so that anyone
who works with a lot of platforms knows where to find stuff and can
work on all the platforms. Simplicity sometimes trumps consistency,
but both are important.

The r8a7779 SoC is indeed an interesting case, it seems to fit
well into shmobile because you use some of the same devices (e.g.
sh-sci and the clock code). If you think there are lots of
commonalities with the new one, it's probably fair to put them
in the same directory even when that means we also have completely
unrelated stuff in there now. I would still prefer having separate
directories, but I'll leave it up to you as long as you put
an explanation about the history into the changeset comment.

One thing is I really don't like is when I get the impression that
people are trying to cheat and hide important facts from the upstream
maintainer in order to improve their chance of getting stuff included.
The best way to avoid giving that impression is to add as much
information as possible about why you do things in a certain way.

> So if all these things are moved out of arch/arm (which I believe is
> the right way forward) then what is the point of having mach
> directories at all? In the end it's some random ARM IP with I/O
> devices hanging off it. With that in mind i'd rather work on putting
> the Emma Mobile stuff in a common arch/arm location than create yet
> another separate directory for something that isn't really special at
> all.

We're heading that way for 64 bit ARM, but it needs more work. When
all drivers (irqchip, clock, pinctrl, ...) have been moved out of arch/arm,
I guess a lot of simple platforms become a single source file with just
one DT_MACHINE_START statement (or something even simpler), and then
we can put them into a common directory.

	Arnd

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Geert Uytterhoeven]

On Sat, May 5, 2012 at 9:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 05 May 2012, Rafael J. Wysocki wrote:
>> Now, if you insist on us having a separate mach- directory for every platform
>> (SoC), we can do that I think, but then we should start with splitting up the
>> existing mach-shmobile into a number of SoC-specific directories rather than
>> adding new mach- directories for random new parts, because that goes against
>> our development history to date, which is important too IMHO.
>
> All the chips in there so far share a common ancestry and they all use a
> significant subset of the same drivers shared with arch/sh: i2c-sh_mobile,
> sh-dma-engine, sh_cmt, sh-sci, sh_tmu, intc, pfc and sh_clk. AFAICT, this one
> uses none of those and apparently was developed by NEC before the merger with
> Renesas.

Ah, I didn't know NEC joined Renesas, but Wikipedia proves you're right.

So, any similarities with the MIPS-based NEC EMMA SOCs, i.e. more code to
share?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot

[Magnus Damm]

On Wed, May 9, 2012 at 4:57 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sat, May 5, 2012 at 9:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Saturday 05 May 2012, Rafael J. Wysocki wrote:
>>> Now, if you insist on us having a separate mach- directory for every platform
>>> (SoC), we can do that I think, but then we should start with splitting up the
>>> existing mach-shmobile into a number of SoC-specific directories rather than
>>> adding new mach- directories for random new parts, because that goes against
>>> our development history to date, which is important too IMHO.
>>
>> All the chips in there so far share a common ancestry and they all use a
>> significant subset of the same drivers shared with arch/sh: i2c-sh_mobile,
>> sh-dma-engine, sh_cmt, sh-sci, sh_tmu, intc, pfc and sh_clk. AFAICT, this one
>> uses none of those and apparently was developed by NEC before the merger with
>> Renesas.
>
> Ah, I didn't know NEC joined Renesas, but Wikipedia proves you're right.

Actually, for those of you who care about details - NEC Electronics
and Renesas merged into Renesas Electronics. Other parts of NEC are
still around as usual.

> So, any similarities with the MIPS-based NEC EMMA SOCs, i.e. more code to
> share?

That would be very interested to know. I've grepped the kernel tree
for existing code matching Uart, STI and GPIO but nothing so far. Does
anyone know where I can find docs for the MIPS based ones?

Good news is that documentation for Emma Mobile EV2 and Emma Mobile
1-S can be downloaded from renesas.com.

Cheers,

/ magnus