mach-shmobile: Emma Mobile EV2 - first shot

PATCH In review Magnus Damm 4 participants 20 messages May 3, 2012 – May 9, 2012

Subsystems (4)

Arm (32-bit) Arm sub-architectures SuperH Arm/RISC-V/Renesas architecture

lore

Share & tools

lore

Magnus Damm

author maintainer

2012-05-03 14:45 UTC #0 lore raw

cover mach-shmobile: Emma Mobile EV2 - first shot

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 <[email protected]>

---

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(+)

Magnus Damm

author maintainer

2012-05-03 14:46 UTC #1 lore raw

PATCH 1/2 mach-shmobile: Emma Mobile EV2 SoC base support

From: Magnus Damm <[email protected]>

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 <[email protected]>

---

 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(+)

arch/arm/mach-shmobile/Kconfig +5 -0

@@ -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

arch/arm/mach-shmobile/Makefile +1 -0

@@ -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

arch/arm/mach-shmobile/clock-emev2.c new file +206 -0

206 lines not on this page · raw message

arch/arm/mach-shmobile/include/mach/common.h +6 -0

@@ -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 */

arch/arm/mach-shmobile/intc-emev2.c new file +36 -0

@@ -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);
+}

arch/arm/mach-shmobile/setup-emev2.c new file +187 -0

187 lines not on this page · raw message

Arnd Bergmann

2012-05-04 19:47 UTC #3 lore raw

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

Quoted 14 lines · Arnd Bergmann

Quoted 11 lines · Magnus Damm

arch/arm/mach-shmobile/clock-emev2.c new file +11 -0

+
+/* 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

Quoted 8 lines

arch/arm/mach-shmobile/clock-emev2.c line 40
Quoted 5 lines
arch/arm/mach-shmobile/clock-emev2.c new file +5 -0
+#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

Magnus Damm

author maintainer

2012-05-08 16:56 UTC #4 lore raw

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

In reply to Arnd Bergmann

Quoted 13 lines · Arnd Bergmann

Quoted 11 lines · Magnus Damm

arch/arm/mach-shmobile/clock-emev2.c new file +11 -0

+
+/* 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

Quoted 8 lines

arch/arm/mach-shmobile/clock-emev2.c line 40
Quoted 5 lines
arch/arm/mach-shmobile/clock-emev2.c new file +5 -0
+#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!

Quoted 7 lines

(quoted diff) +7 -0

+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);

Quoted 8 lines

Quoted 6 lines
+
+ ? ? /* 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?

Quoted 6 lines

Quoted 6 lines
arch/arm/mach-shmobile/include/mach/common.h 2012-05-03 20:45:56.000000000 +0900 renamed from arch/arm/mach-shmobile/include/mach/common.h +0 -0
@@ -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);
 

Quoted 10 lines

Quoted 7 lines
arch/arm/mach-shmobile/include/mach/common.h 2012-05-03 20:45:56.000000000 +0900 renamed from arch/arm/mach-shmobile/include/mach/common.h +6 -0
+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?

Quoted 16 lines

arch/arm/mach-shmobile/intc-emev2.c ?2012-05-03 20:45:57.000000000 +0900
Quoted 12 lines
arch/arm/mach-shmobile/intc-emev2.c ?2012-05-03 20:45:57.000000000 +0900 new file +9 -0
 
+
+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.

Quoted 13 lines

Quoted 13 lines
+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,

Quoted 8 lines

arch/arm/mach-shmobile/intc-emev2.c ?2012-05-03 20:45:57.000000000 +0900
Quoted 8 lines
+ ? ? ? ? ? ? .type ? ? ? ? ? = MT_DEVICE
+ ? ? },
arch/arm/mach-shmobile/intc-emev2.c ?2012-05-03 20:45:57.000000000 +0900 new file +6 -0
+};
+
+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

Arnd Bergmann

2012-05-08 19:35 UTC #5 lore raw

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

Quoted 16 lines · Magnus Damm

Quoted 7 lines
Quoted 7 lines
arch/arm/mach-shmobile/clock-emev2.c new file +7 -0
+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);
Quoted 8 lines
arch/arm/mach-shmobile/clock-emev2.c line 189
Quoted 6 lines
arch/arm/mach-shmobile/clock-emev2.c new file +6 -0
+
+     /* 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_*.

Quoted 1 line

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.

Quoted 17 lines

Quoted 6 lines
Quoted 6 lines
arch/arm/mach-shmobile/include/mach/common.h 2012-05-03 20:45:56.000000000 +0900 renamed from arch/arm/mach-shmobile/include/mach/common.h +0 -0
@@ -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);
 
Quoted 10 lines
arch/arm/mach-shmobile/include/mach/common.h 2012-05-03 20:45:56.000000000 +0900 extern void r8a7779_secondary_init(unsig · line 94
Quoted 7 lines
arch/arm/mach-shmobile/include/mach/common.h 2012-05-03 20:45:56.000000000 +0900 renamed from arch/arm/mach-shmobile/include/mach/common.h +6 -0
+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.

Quoted 6 lines

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.

Quoted 23 lines

Quoted 13 lines
Quoted 13 lines
arch/arm/mach-shmobile/include/mach/common.h 2012-05-03 20:45:56.000000000 +0900 renamed from arch/arm/mach-shmobile/include/mach/common.h +13 -0
+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,
Quoted 8 lines
arch/arm/mach-shmobile/include/mach/common.h 2012-05-03 20:45:56.000000000 +0900
Quoted 8 lines
arch/arm/mach-shmobile/include/mach/common.h 2012-05-03 20:45:56.000000000 +0900 renamed from arch/arm/mach-shmobile/include/mach/common.h +8 -0
+             .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

Quoted 8 lines

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.

Quoted 5 lines

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

Magnus Damm

author maintainer

2012-05-03 14:46 UTC #6 lore raw

PATCH 2/2 mach-shmobile: KZM9D board prototype support

In reply to Magnus Damm

From: Magnus Damm <[email protected]>

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 <[email protected]>

---

 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(+)

arch/arm/mach-shmobile/Kconfig +4 -0

@@ -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

arch/arm/mach-shmobile/Makefile +1 -0

@@ -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)

arch/arm/mach-shmobile/board-kzm9d.c new file +44 -0

44 lines not on this page · raw message

Arnd Bergmann

2012-05-04 13:14 UTC #7 lore raw

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

Quoted 11 lines · Magnus Damm

From: Magnus Damm <[email protected]>
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 <[email protected]>

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

Rafael J. Wysocki

2012-05-03 19:19 UTC #8 lore raw

In reply to Magnus Damm

Quoted 16 lines · 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"

Quoted 7 lines

Any reason to not put this in mach-shmobile?
Partially-signed-off-by Magnus Damm <[email protected]>
---
Does unfortunately not apply cleanly to the renesas git repository,

Well, this sounds like a reason.

Quoted 2 lines

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

Surely.

Thanks,
Rafael

Quoted 10 lines

 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(+)

Arnd Bergmann

2012-05-04 19:57 UTC #9 lore raw

In reply to Magnus Damm

Quoted 12 lines · 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.

Quoted 5 lines

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

Rafael J. Wysocki

2012-05-04 21:12 UTC #10 lore raw

Quoted 17 lines · Arnd Bergmann

Quoted 16 lines · 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"

Quoted 5 lines

Quoted 1 line
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

Arnd Bergmann

2012-05-05 07:22 UTC #11 lore raw

Quoted 6 lines · Rafael J. Wysocki

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

Rafael J. Wysocki

2012-05-05 19:03 UTC #12 lore raw

Quoted 13 lines · Arnd Bergmann

Quoted 6 lines · Rafael J. Wysocki
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.

Quoted 5 lines

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

Arnd Bergmann

2012-05-05 19:21 UTC #13 lore raw

Quoted 5 lines · Rafael J. Wysocki

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

Rafael J. Wysocki

2012-05-05 19:25 UTC #14 lore raw

Quoted 7 lines · Arnd Bergmann

Quoted 5 lines · Rafael J. Wysocki
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.

Quoted 5 lines

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

Arnd Bergmann

2012-05-05 19:50 UTC #15 lore raw

Quoted 8 lines · Rafael J. Wysocki

Quoted 5 lines
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

Magnus Damm

author maintainer

2012-05-06 14:23 UTC #16 lore raw

In reply to Arnd Bergmann

Quoted 7 lines · Arnd Bergmann

Quoted 5 lines · Rafael J. Wysocki
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.

Quoted 5 lines

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

Arnd Bergmann

2012-05-08 20:12 UTC #17 lore raw

Quoted 12 lines · Magnus Damm

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.

Quoted 7 lines

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

Geert Uytterhoeven

2012-05-09 07:57 UTC #18 lore raw

In reply to Arnd Bergmann

Quoted 7 lines · Arnd Bergmann

Quoted 5 lines · Rafael J. Wysocki
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.

Quoted 5 lines

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 at linux-m68k.org

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

Magnus Damm

author maintainer

2012-05-09 08:12 UTC #19 lore raw

Quoted 8 lines · Geert Uytterhoeven

Quoted 7 lines · Arnd Bergmann
Quoted 5 lines · Rafael J. Wysocki
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.

Quoted 7 lines

Quoted 5 lines
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.

Quoted 2 lines

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