* [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot
@ 2012-05-03 14:46 Magnus Damm
2012-05-03 14:46 ` [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support Magnus Damm
` (3 more replies)
0 siblings, 4 replies; 20+ messages in thread
From: Magnus Damm @ 2012-05-03 14:46 UTC (permalink / raw)
To: linux-arm-kernel
Cc: horms, linux, arnd, linux-sh, linux-kernel, rjw, lethal, olof,
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(+)
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support 2012-05-03 14:46 [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot Magnus Damm @ 2012-05-03 14:46 ` Magnus Damm 2012-05-04 13:07 ` Arnd Bergmann 2012-05-03 14:47 ` [PATCH 02/02] mach-shmobile: KZM9D board prototype support Magnus Damm ` (2 subsequent siblings) 3 siblings, 1 reply; 20+ messages in thread From: Magnus Damm @ 2012-05-03 14:46 UTC (permalink / raw) To: linux-arm-kernel Cc: linux, arnd, linux-sh, lethal, linux-kernel, rjw, horms, olof, 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(); +} + ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support 2012-05-03 14:46 ` [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support Magnus Damm @ 2012-05-04 13:07 ` Arnd Bergmann 2012-05-04 19:47 ` Arnd Bergmann 2012-05-08 16:56 ` Magnus Damm 0 siblings, 2 replies; 20+ messages in thread From: Arnd Bergmann @ 2012-05-04 13:07 UTC (permalink / raw) To: Magnus Damm Cc: linux-arm-kernel, linux, linux-sh, lethal, linux-kernel, rjw, horms, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support 2012-05-04 13:07 ` Arnd Bergmann @ 2012-05-04 19:47 ` Arnd Bergmann 2012-05-08 16:56 ` Magnus Damm 1 sibling, 0 replies; 20+ messages in thread From: Arnd Bergmann @ 2012-05-04 19:47 UTC (permalink / raw) To: Magnus Damm Cc: linux-arm-kernel, linux, linux-sh, lethal, linux-kernel, rjw, horms, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support 2012-05-04 13:07 ` Arnd Bergmann 2012-05-04 19:47 ` Arnd Bergmann @ 2012-05-08 16:56 ` Magnus Damm 2012-05-08 19:35 ` Arnd Bergmann 1 sibling, 1 reply; 20+ messages in thread From: Magnus Damm @ 2012-05-08 16:56 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, linux, linux-sh, lethal, linux-kernel, rjw, horms, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support 2012-05-08 16:56 ` Magnus Damm @ 2012-05-08 19:35 ` Arnd Bergmann 0 siblings, 0 replies; 20+ messages in thread From: Arnd Bergmann @ 2012-05-08 19:35 UTC (permalink / raw) To: Magnus Damm Cc: linux-arm-kernel, linux, linux-sh, lethal, linux-kernel, rjw, horms, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 02/02] mach-shmobile: KZM9D board prototype support 2012-05-03 14:46 [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot Magnus Damm 2012-05-03 14:46 ` [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support Magnus Damm @ 2012-05-03 14:47 ` Magnus Damm 2012-05-04 13:14 ` Arnd Bergmann 2012-05-03 19:23 ` [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot Rafael J. Wysocki 2012-05-04 19:57 ` Arnd Bergmann 3 siblings, 1 reply; 20+ messages in thread From: Magnus Damm @ 2012-05-03 14:47 UTC (permalink / raw) To: linux-arm-kernel Cc: horms, linux, arnd, linux-sh, linux-kernel, rjw, lethal, olof, 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 02/02] mach-shmobile: KZM9D board prototype support 2012-05-03 14:47 ` [PATCH 02/02] mach-shmobile: KZM9D board prototype support Magnus Damm @ 2012-05-04 13:14 ` Arnd Bergmann 0 siblings, 0 replies; 20+ messages in thread From: Arnd Bergmann @ 2012-05-04 13:14 UTC (permalink / raw) To: Magnus Damm Cc: linux-arm-kernel, horms, linux, linux-sh, linux-kernel, rjw, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-03 14:46 [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot Magnus Damm 2012-05-03 14:46 ` [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support Magnus Damm 2012-05-03 14:47 ` [PATCH 02/02] mach-shmobile: KZM9D board prototype support Magnus Damm @ 2012-05-03 19:23 ` Rafael J. Wysocki 2012-05-04 19:57 ` Arnd Bergmann 3 siblings, 0 replies; 20+ messages in thread From: Rafael J. Wysocki @ 2012-05-03 19:23 UTC (permalink / raw) To: Magnus Damm Cc: linux-arm-kernel, horms, linux, arnd, linux-sh, linux-kernel, lethal, olof 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(+) > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-03 14:46 [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot Magnus Damm ` (2 preceding siblings ...) 2012-05-03 19:23 ` [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot Rafael J. Wysocki @ 2012-05-04 19:57 ` Arnd Bergmann 2012-05-04 21:16 ` Rafael J. Wysocki 3 siblings, 1 reply; 20+ messages in thread From: Arnd Bergmann @ 2012-05-04 19:57 UTC (permalink / raw) To: Magnus Damm Cc: linux-arm-kernel, horms, linux, linux-sh, linux-kernel, rjw, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-04 19:57 ` Arnd Bergmann @ 2012-05-04 21:16 ` Rafael J. Wysocki 2012-05-05 7:22 ` Arnd Bergmann 0 siblings, 1 reply; 20+ messages in thread From: Rafael J. Wysocki @ 2012-05-04 21:16 UTC (permalink / raw) To: Arnd Bergmann Cc: Magnus Damm, linux-arm-kernel, horms, linux, linux-sh, linux-kernel, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-04 21:16 ` Rafael J. Wysocki @ 2012-05-05 7:22 ` Arnd Bergmann 2012-05-05 19:08 ` Rafael J. Wysocki 0 siblings, 1 reply; 20+ messages in thread From: Arnd Bergmann @ 2012-05-05 7:22 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Magnus Damm, linux-arm-kernel, horms, linux, linux-sh, linux-kernel, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-05 7:22 ` Arnd Bergmann @ 2012-05-05 19:08 ` Rafael J. Wysocki 2012-05-05 19:21 ` Arnd Bergmann 0 siblings, 1 reply; 20+ messages in thread From: Rafael J. Wysocki @ 2012-05-05 19:08 UTC (permalink / raw) To: Arnd Bergmann Cc: Magnus Damm, linux-arm-kernel, horms, linux, linux-sh, linux-kernel, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-05 19:08 ` Rafael J. Wysocki @ 2012-05-05 19:21 ` Arnd Bergmann 2012-05-05 19:30 ` Rafael J. Wysocki ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Arnd Bergmann @ 2012-05-05 19:21 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Magnus Damm, linux-arm-kernel, horms, linux, linux-sh, linux-kernel, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-05 19:21 ` Arnd Bergmann @ 2012-05-05 19:30 ` Rafael J. Wysocki 2012-05-05 19:50 ` Arnd Bergmann 2012-05-06 14:23 ` Magnus Damm 2012-05-09 7:57 ` Geert Uytterhoeven 2 siblings, 1 reply; 20+ messages in thread From: Rafael J. Wysocki @ 2012-05-05 19:30 UTC (permalink / raw) To: Arnd Bergmann Cc: Magnus Damm, linux-arm-kernel, horms, linux, linux-sh, linux-kernel, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-05 19:30 ` Rafael J. Wysocki @ 2012-05-05 19:50 ` Arnd Bergmann 0 siblings, 0 replies; 20+ messages in thread From: Arnd Bergmann @ 2012-05-05 19:50 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Magnus Damm, linux-arm-kernel, horms, linux, linux-sh, linux-kernel, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-05 19:21 ` Arnd Bergmann 2012-05-05 19:30 ` Rafael J. Wysocki @ 2012-05-06 14:23 ` Magnus Damm 2012-05-08 20:12 ` Arnd Bergmann 2012-05-09 7:57 ` Geert Uytterhoeven 2 siblings, 1 reply; 20+ messages in thread From: Magnus Damm @ 2012-05-06 14:23 UTC (permalink / raw) To: Arnd Bergmann Cc: Rafael J. Wysocki, linux-arm-kernel, horms, linux, linux-sh, linux-kernel, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-06 14:23 ` Magnus Damm @ 2012-05-08 20:12 ` Arnd Bergmann 0 siblings, 0 replies; 20+ messages in thread From: Arnd Bergmann @ 2012-05-08 20:12 UTC (permalink / raw) To: Magnus Damm Cc: Rafael J. Wysocki, linux-arm-kernel, horms, linux, linux-sh, linux-kernel, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-05 19:21 ` Arnd Bergmann 2012-05-05 19:30 ` Rafael J. Wysocki 2012-05-06 14:23 ` Magnus Damm @ 2012-05-09 7:57 ` Geert Uytterhoeven 2012-05-09 8:12 ` Magnus Damm 2 siblings, 1 reply; 20+ messages in thread From: Geert Uytterhoeven @ 2012-05-09 7:57 UTC (permalink / raw) To: Arnd Bergmann Cc: Rafael J. Wysocki, Magnus Damm, linux-arm-kernel, horms, linux, linux-sh, linux-kernel, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot 2012-05-09 7:57 ` Geert Uytterhoeven @ 2012-05-09 8:12 ` Magnus Damm 0 siblings, 0 replies; 20+ messages in thread From: Magnus Damm @ 2012-05-09 8:12 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Arnd Bergmann, Rafael J. Wysocki, linux-arm-kernel, horms, linux, linux-sh, linux-kernel, lethal, olof 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-05-09 8:12 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-05-03 14:46 [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot Magnus Damm 2012-05-03 14:46 ` [PATCH 01/02] mach-shmobile: Emma Mobile EV2 SoC base support Magnus Damm 2012-05-04 13:07 ` Arnd Bergmann 2012-05-04 19:47 ` Arnd Bergmann 2012-05-08 16:56 ` Magnus Damm 2012-05-08 19:35 ` Arnd Bergmann 2012-05-03 14:47 ` [PATCH 02/02] mach-shmobile: KZM9D board prototype support Magnus Damm 2012-05-04 13:14 ` Arnd Bergmann 2012-05-03 19:23 ` [PATCH 00/02] mach-shmobile: Emma Mobile EV2 - first shot Rafael J. Wysocki 2012-05-04 19:57 ` Arnd Bergmann 2012-05-04 21:16 ` Rafael J. Wysocki 2012-05-05 7:22 ` Arnd Bergmann 2012-05-05 19:08 ` Rafael J. Wysocki 2012-05-05 19:21 ` Arnd Bergmann 2012-05-05 19:30 ` Rafael J. Wysocki 2012-05-05 19:50 ` Arnd Bergmann 2012-05-06 14:23 ` Magnus Damm 2012-05-08 20:12 ` Arnd Bergmann 2012-05-09 7:57 ` Geert Uytterhoeven 2012-05-09 8:12 ` Magnus Damm
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).