[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Gregory CLEMENT]

Arnd, Olof,

You'll find in this patch set the new version of the initial support for a
new family of ARMv7-compatible Marvell SoCs initially submitted by my
colleague Thomas Petazzoni. Following the conclusion of the discussion when
we submitted our first version we have chosen to add this support for this
SoC family in the to support in the arch/arm/mach-mvebu/ directory.

As for the previous release, both the Armada 370 and the Armada XP SoCs are
supported in this directory, and we are able to build a single kernel image
that boots on both SoCs. Both SoCs use the PJ4B processor, a
Marvell-developed ARM core that implements the ARMv7 instruction set. We are
currently using Marvell evaluation boards for both of those SoCs, and the
support for those boards is added in this patch set.

We remained focused on a limited preliminary support which only includes the
necessary code for timer and IRQ support, the serial controller is a
standard 16550-compatible one. The diffstat looks like:

 Documentation/devicetree/bindings/arm/armada_370_xp-mpic.txt  |   23 +
 Documentation/devicetree/bindings/arm/armada_370_xp-timer.txt |   11 +
 Documentation/devicetree/bindings/arm/armada_370_xp.txt       |   24 +
 MAINTAINERS                                                   |    8 +
 arch/arm/Kconfig                                              |   15 +
 arch/arm/Makefile                                             |    1 +
 arch/arm/boot/dts/armada-370-db.dts                           |   41 ++
 arch/arm/boot/dts/armada-370-xp.dtsi                          |   66 +++
 arch/arm/boot/dts/armada-370.dtsi                             |   29 +
 arch/arm/boot/dts/armada-xp-db.dts                            |   40 ++
 arch/arm/boot/dts/armada-xp.dtsi                              |   49 ++
 arch/arm/configs/mvebu_defconfig                              |   47 ++
 arch/arm/mach-mvebu/Kconfig                                   |   14 +
 arch/arm/mach-mvebu/Makefile                                  |    2 +
 arch/arm/mach-mvebu/Makefile.boot                             |    1 +
 arch/arm/mach-mvebu/armada-370-xp-dt.c                        |   65 +++
 arch/arm/mach-mvebu/common.c                                  |   36 ++
 arch/arm/mach-mvebu/common.h                                  |   24 +
 arch/arm/mach-mvebu/include/mach/armada-370-xp.h              |   22 +
 arch/arm/mach-mvebu/include/mach/debug-macro.S                |   24 +
 arch/arm/mach-mvebu/include/mach/mvebu.h                      |   22 +
 arch/arm/mach-mvebu/include/mach/timex.h                      |   13 +
 arch/arm/mach-mvebu/include/mach/uncompress.h                 |   41 ++
 arch/arm/mach-mvebu/irq-armada-370-xp.c                       |  133 +++++
 arch/arm/mach-mvebu/time-armada-370-xp.c                      |  244 +++++++++
 25 files changed, 995 insertions(+)

This patch set, and the support for those SoCs, started as a collaborative
effort from Marvell engineers (who have done the initial development work)
and Free Electrons engineers (who are reshaping the code for mainline
submission, adding device tree support, etc.). And for this new version we
got contributions from Ben Dooks from Codethink.

The patch set is based on your arm-soc/for-next branch (updated on Monday
11th June).

The main change between V1 and V2 is the use of a new mach-mvebu directory
as this directory is aimed to receive most of the Marvell SOC converted to
the device tree, we intended to make the code less specific. The other main
part was to remove all the unnecessary code or even files.

Here comes a pretty exhaustive list of the changes:

* Created a new mach- directory called mach-mvebu as suggested on the
 mainling-list. Converted most the "armada" word by the "mvebu", but as some
 code remains specific to the armada 370 and armada XP SOC, then created
 also the aramada_370_xp suffix for this part. This suffix was dedicated for
 the irq and timer part. It was also used for the register related to the
 reset part. And of course it was also used for the device tree part.

* Merged axp-dt.c and a370-dt.c files in one single armada_370_xp-dt.c file.

* Deleted most of the mapping address in include/mach/armada.h and split it
  in two headers file:

  - mvebu.h which contains the virtual and physical mapping for the internal
    registers of the mvebu SOC. This ones are mainly used for the early
    print during boot.

  - armada_370_xp which contains the registers offset and mask for resetting
    the CPU.

* Removed unused headers such as
  - hardware.h by directly including accurate header when needed
  - gpio.h by removing the dependencies to PLAT-ORION
  - io.h no more needed for CPI
  - irqs.h by using SPARSE_IRQ
  - system.h no more needed for new SOC

* Removed the PCI related code as it was not necessary for the initial
  submission

* Removed all the PLAT-ORION dependencies remaining

* Ensured property reading checks for error when getting data from device
  tree in the timer file. This was a patch from Ben Dooks with the following
  comments:

  "The call to of_property_read_u32() only checks for the value that the clk
   variable is set to being non-zero, and not the return value of the call
   itself.

   This caused a system without the clock-frequency attribute to fail to
   boot as it used a random value on the stack to setup the system timers
   and thus cause an interrupt storm.

   Also ensure clk is set to zero, to avoid warnings."

* Converted irq.c to use SPARSE_IRQ

* Added the following bug fixes and improvements in irq.c from Ben Dooks
  
  - MPIC: BUG_ON() if the of_iomap() fails: Ensure that if either resource
    is missing, we stop the kernel in a reasonably fatal way.

  - MPIC: Move main register base to base of MPIC registers: The current
    kernel driver had the MPIC base at the base of the block containing the
    MPIC and not the MPIC itself. Change this value in the driver and the
    .dtsi file

	Also change the register size in the .dtsi to be the size of the
	register range for the MIPC and not the block it is in.

  - MPIC: Move per-cpu register base: The current kernel driver had the MPIC
  	per-cpu register base at the base of the per-cpu register block and not
  	at the base of the specific per-cpu interrupt registers.

	Move the driver and .dtsi to use the correct base and size.

  - MPIC: number fetch should use irqd_to_hwirq(): The mask and unmask
  	routines are assuming that d->irq is a 1:1 mapping with the interrupt
  	hardware. Use the irqd_to_hwirq() call to map the irq_data to the
  	hardware irq number directly.

  - MPIC: read number of interrupts from control register: Read the number
   	of MPIC interrupts from the controller and only register that many.

Andrew Lunn asked for refactoring the _restart() function to being used by
any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers
mapping differs between the SOC and the bit mask too. A solution could be to
get this mapping through the device tree, but we are not sure it was a good
usage of the device tree.


Best regards,

Gregory Clement

[PATCH v2 1/8] arm: mach-mvebu: add header

[Gregory CLEMENT]

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
 arch/arm/mach-mvebu/include/mach/debug-macro.S |   24 ++++++++++++++
 arch/arm/mach-mvebu/include/mach/mvebu.h       |   22 +++++++++++++
 arch/arm/mach-mvebu/include/mach/timex.h       |   13 ++++++++
 arch/arm/mach-mvebu/include/mach/uncompress.h  |   41 ++++++++++++++++++++++++
 4 files changed, 100 insertions(+)
 create mode 100644 arch/arm/mach-mvebu/include/mach/debug-macro.S
 create mode 100644 arch/arm/mach-mvebu/include/mach/mvebu.h
 create mode 100644 arch/arm/mach-mvebu/include/mach/timex.h
 create mode 100644 arch/arm/mach-mvebu/include/mach/uncompress.h

diff --git a/arch/arm/mach-mvebu/include/mach/debug-macro.S b/arch/arm/mach-mvebu/include/mach/debug-macro.S
new file mode 100644
index 0000000..6da4fa1
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/debug-macro.S
@@ -0,0 +1,24 @@
+/*
+ * Early serial output macro for Marvell  SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory Clement <gregory.clement@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <mach/mvebu.h>
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =MVEBU_REGS_PHYS_BASE
+	ldr	\rv, =MVEBU_REGS_VIRT_BASE
+	orr	\rp, \rp, #0x00012000
+	orr	\rv, \rv, #0x00012000
+	.endm
+
+#define UART_SHIFT	2
+#include <asm/hardware/debug-8250.S>
diff --git a/arch/arm/mach-mvebu/include/mach/mvebu.h b/arch/arm/mach-mvebu/include/mach/mvebu.h
new file mode 100644
index 0000000..3496471
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/mvebu.h
@@ -0,0 +1,22 @@
+/*
+ * Generic definitions for Marvell SoCs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __MACH_MVEBU_H
+#define __MACH_MVEBU_H
+
+#define MVEBU_REGS_PHYS_BASE		0xd0000000
+#define MVEBU_REGS_VIRT_BASE		0xfeb00000
+#define MVEBU_REGS_SIZE		SZ_1M
+
+#endif /* __MACH_MVEBU_H */
diff --git a/arch/arm/mach-mvebu/include/mach/timex.h b/arch/arm/mach-mvebu/include/mach/timex.h
new file mode 100644
index 0000000..ab324a3
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/timex.h
@@ -0,0 +1,13 @@
+/*
+ * Marvell Armada SoC time definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define CLOCK_TICK_RATE		(100 * HZ)
diff --git a/arch/arm/mach-mvebu/include/mach/uncompress.h b/arch/arm/mach-mvebu/include/mach/uncompress.h
new file mode 100644
index 0000000..3642997
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/uncompress.h
@@ -0,0 +1,41 @@
+/*
+ * Marvell Armada SoC kernel uncompression UART routines
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <mach/mvebu.h>
+
+#define UART_THR ((volatile unsigned char *)(MVEBU_REGS_PHYS_BASE + 0x12000))
+#define UART_LSR ((volatile unsigned char *)(MVEBU_REGS_PHYS_BASE + 0x12014))
+
+#define LSR_THRE	0x20
+
+static void putc(const char c)
+{
+	int i;
+
+	for (i = 0; i < 0x1000; i++) {
+		/* Transmit fifo not full? */
+		if (*UART_LSR & LSR_THRE)
+			break;
+	}
+
+	*UART_THR = c;
+}
+
+static void flush(void)
+{
+}
+
+/*
+ * nothing to do
+ */
+#define arch_decomp_setup()
+#define arch_decomp_wdog()
-- 
1.7.9.5

[PATCH v2 2/8] arm: mach-mvebu: add source files

[Gregory CLEMENT]

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
 arch/arm/mach-mvebu/Kconfig       |    7 +++++++
 arch/arm/mach-mvebu/Makefile      |    1 +
 arch/arm/mach-mvebu/Makefile.boot |    1 +
 arch/arm/mach-mvebu/common.c      |   36 ++++++++++++++++++++++++++++++++++++
 arch/arm/mach-mvebu/common.h      |   20 ++++++++++++++++++++
 5 files changed, 65 insertions(+)
 create mode 100644 arch/arm/mach-mvebu/Kconfig
 create mode 100644 arch/arm/mach-mvebu/Makefile
 create mode 100644 arch/arm/mach-mvebu/Makefile.boot
 create mode 100644 arch/arm/mach-mvebu/common.c
 create mode 100644 arch/arm/mach-mvebu/common.h

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
new file mode 100644
index 0000000..72d39e5
--- /dev/null
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -0,0 +1,7 @@
+if ARCH_MVEBU
+
+menu "Marvell SOC with device tree"
+
+endmenu
+
+endif
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
new file mode 100644
index 0000000..f95691b
--- /dev/null
+++ b/arch/arm/mach-mvebu/Makefile
@@ -0,0 +1 @@
+obj-y += common.o
diff --git a/arch/arm/mach-mvebu/Makefile.boot b/arch/arm/mach-mvebu/Makefile.boot
new file mode 100644
index 0000000..b327175
--- /dev/null
+++ b/arch/arm/mach-mvebu/Makefile.boot
@@ -0,0 +1 @@
+zreladdr-y := 0x00008000
diff --git a/arch/arm/mach-mvebu/common.c b/arch/arm/mach-mvebu/common.c
new file mode 100644
index 0000000..b48cecd
--- /dev/null
+++ b/arch/arm/mach-mvebu/common.c
@@ -0,0 +1,36 @@
+/*
+ * Core functions for Marvell System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <asm/page.h>
+#include <asm/setup.h>
+#include <asm/mach/map.h>
+#include <mach/mvebu.h>
+#include "common.h"
+
+static struct map_desc mvebu_io_desc[] __initdata = {
+	{
+		.virtual	= MVEBU_REGS_VIRT_BASE,
+		.pfn		= __phys_to_pfn(MVEBU_REGS_PHYS_BASE),
+		.length		= MVEBU_REGS_SIZE,
+		.type		= MT_DEVICE,
+	},
+};
+
+void __init mvebu_map_io(void)
+{
+	iotable_init(mvebu_io_desc, ARRAY_SIZE(mvebu_io_desc));
+}
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
new file mode 100644
index 0000000..7bf0879
--- /dev/null
+++ b/arch/arm/mach-mvebu/common.h
@@ -0,0 +1,20 @@
+/*
+ * Core functions for Marvell Armada System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __ARCH_ARMADA_COMMON_H
+#define __ARCH_ARMADA_COMMON_H
+
+void mvebu_map_io(void);
+
+#endif
-- 
1.7.9.5

[PATCH v2 3/8] arm: mach-mvebu: add compilation/configuration change

[Gregory CLEMENT]

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
 arch/arm/Kconfig  |   15 +++++++++++++++
 arch/arm/Makefile |    1 +
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 23289d2..2ff9f40 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -533,6 +533,19 @@ config ARCH_IXP4XX
 	help
 	  Support for Intel's IXP4XX (XScale) family of processors.
 
+config ARCH_MVEBU
+	bool "Marvell SOCs with Device Tree support"
+	select CPU_V7
+	select GENERIC_CLOCKEVENTS
+	select MULTI_IRQ_HANDLER
+	select SPARSE_IRQ
+	select CLKSRC_MMIO
+	select GENERIC_IRQ_CHIP
+	select IRQ_DOMAIN
+	select COMMON_CLK
+	help
+	  Support for the Marvell SoC Family with device tree support
+
 config ARCH_DOVE
 	bool "Marvell Dove"
 	select CPU_V7
@@ -986,6 +999,8 @@ endchoice
 # Kconfigs may be included either alphabetically (according to the
 # plat- suffix) or along side the corresponding mach-* source.
 #
+source "arch/arm/mach-mvebu/Kconfig"
+
 source "arch/arm/mach-at91/Kconfig"
 
 source "arch/arm/mach-bcmring/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 0298b00..f1a1a71 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -157,6 +157,7 @@ machine-$(CONFIG_ARCH_MV78XX0)		:= mv78xx0
 machine-$(CONFIG_ARCH_IMX_V4_V5)	:= imx
 machine-$(CONFIG_ARCH_IMX_V6_V7)	:= imx
 machine-$(CONFIG_ARCH_MXS)		:= mxs
+machine-$(CONFIG_ARCH_MVEBU)		:= mvebu
 machine-$(CONFIG_ARCH_NETX)		:= netx
 machine-$(CONFIG_ARCH_NOMADIK)		:= nomadik
 machine-$(CONFIG_ARCH_OMAP1)		:= omap1
-- 
1.7.9.5

[PATCH v2 4/8] arm: mach-mvebu: add support for Armada 370 and Armada XP with DT

[Gregory CLEMENT]

[ben.dooks at codethink.co.uk: ensure error check on of_property_read_u32]
[ben.dooks at codethink.co.uk: use mpic address instead of bus-unit's ]
[ben.dooks at codethink.co.uk: BUG_ON() if the of_iomap() fails for mpic]
[ben.dooks at codethink.co.uk: move mpic per-cpu register base ]
[ben.dooks at codethink.co.uk: number fetch should use irqd_to_hwirq()]

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 arch/arm/boot/dts/armada-370-db.dts              |   41 ++++
 arch/arm/boot/dts/armada-370-xp.dtsi             |   66 ++++++
 arch/arm/boot/dts/armada-370.dtsi                |   29 +++
 arch/arm/boot/dts/armada-xp-db.dts               |   40 ++++
 arch/arm/boot/dts/armada-xp.dtsi                 |   49 +++++
 arch/arm/mach-mvebu/Kconfig                      |    7 +
 arch/arm/mach-mvebu/Makefile                     |    1 +
 arch/arm/mach-mvebu/armada-370-xp-dt.c           |   65 ++++++
 arch/arm/mach-mvebu/common.h                     |    4 +
 arch/arm/mach-mvebu/include/mach/armada-370-xp.h |   22 ++
 arch/arm/mach-mvebu/irq-armada-370-xp.c          |  130 ++++++++++++
 arch/arm/mach-mvebu/time-armada-370-xp.c         |  244 ++++++++++++++++++++++
 12 files changed, 698 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-370-db.dts
 create mode 100644 arch/arm/boot/dts/armada-370-xp.dtsi
 create mode 100644 arch/arm/boot/dts/armada-370.dtsi
 create mode 100644 arch/arm/boot/dts/armada-xp-db.dts
 create mode 100644 arch/arm/boot/dts/armada-xp.dtsi
 create mode 100644 arch/arm/mach-mvebu/armada-370-xp-dt.c
 create mode 100644 arch/arm/mach-mvebu/include/mach/armada-370-xp.h
 create mode 100644 arch/arm/mach-mvebu/irq-armada-370-xp.c
 create mode 100644 arch/arm/mach-mvebu/time-armada-370-xp.c

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
new file mode 100644
index 0000000..f3cc991
--- /dev/null
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -0,0 +1,41 @@
+/*
+ * Device Tree file for Marvell Armada 370 evaluation board
+ * (DB-88F6710-BP-DDR3)
+ *
+ *  Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-370.dtsi"
+
+/ {
+	model = "Marvell Armada 370 Evaluation Board";
+	compatible = "marvell,a370-db", "marvell,armada370", "marvell,armada_370_xp";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x20000000>; /* 512 MB */
+	};
+
+	soc {
+		serial at d0012000 {
+			clock-frequency = <200000000>;
+		};
+		timer at d0020300 {
+			clock-frequency = <600000000>;
+
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
new file mode 100644
index 0000000..649ada1
--- /dev/null
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -0,0 +1,66 @@
+/*
+ * Device Tree Include file for Marvell Armada 370 and Armada XP SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ * Ben Dooks <ben.dooks@codethink.co.uk>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * This file contains the definitions that are common to the Armada
+ * 370 and Armada XP SoC.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "Marvell Armada 370 and XP SoC";
+	compatible = "marvell,armada_370_xp";
+
+	cpus {
+		cpu at 0 {
+			compatible = "marvell,sheeva-v7";
+		};
+	};
+
+	mpic: interrupt-controller at d0020000 {
+	      compatible = "marvell,mpic";
+	      #interrupt-cells = <1>;
+	      #address-cells = <1>;
+	      #size-cells = <1>;
+	      interrupt-controller;
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		interrupt-parent = <&mpic>;
+		ranges;
+
+		serial at d0012000 {
+				compatible = "ns16550";
+				reg = <0xd0012000 0x100>;
+				reg-shift = <2>;
+				interrupts = <41>;
+		};
+		serial at d0012100 {
+				compatible = "ns16550";
+				reg = <0xd0012100 0x100>;
+				reg-shift = <2>;
+				interrupts = <42>;
+		};
+
+		timer at d0020300 {
+			       compatible = "marvell,timer";
+			       reg = <0xd0020300 0x30>;
+			       interrupts = <37>, <38>, <39>, <40>;
+		};
+	};
+};
+
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
new file mode 100644
index 0000000..aefd345
--- /dev/null
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -0,0 +1,29 @@
+/*
+ * Device Tree Include file for Marvell Armada 370 family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Contains definitions specific to the Armada 370 SoC that are not
+ * common to all Armada SoCs.
+ */
+
+/include/ "armada-370-xp.dtsi"
+
+/ {
+	model = "Marvell Armada 370 family SoC";
+	compatible = "marvell,armada370", "marvell,armada";
+
+	mpic: interrupt-controller at d0020000 {
+	      reg = <0xd0020a00 0x1d0>,
+		    <0xd0021870 0x58>;
+	};
+
+ };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
new file mode 100644
index 0000000..7db3de2
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -0,0 +1,40 @@
+/*
+ * Device Tree file for Marvell Armada XP evaluation board
+ * (DB-78460-BP)
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-xp.dtsi"
+
+/ {
+	model = "Marvell Armada XP Evaluation Board";
+	compatible = "marvell,axp-db", "marvell,armadaxp", "marvell,armada_370_xp";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000>; /* 2 GB */
+	};
+
+	soc {
+		serial at d0012000 {
+			clock-frequency = <250000000>;
+		};
+		serial at d0012100 {
+			clock-frequency = <250000000>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
new file mode 100644
index 0000000..ea624e0
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -0,0 +1,49 @@
+/*
+ * Device Tree Include file for Marvell Armada XP family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ * Ben Dooks <ben.dooks@codethink.co.uk>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Contains definitions specific to the Armada 370 SoC that are not
+ * common to all Armada SoCs.
+ */
+
+/include/ "armada-370-xp.dtsi"
+
+/ {
+	model = "Marvell Armada XP family SoC";
+	compatible = "marvell,armadaxp", "marvell,armada_370_xp";
+
+	mpic: interrupt-controller at d0020000 {
+	      reg = <0xd0020a00 0x1d0>,
+		    <0xd0021870 0x58>;
+	};
+
+	soc {
+		serial at d0012200 {
+				compatible = "ns16550";
+				reg = <0xd0012200 0x100>;
+				reg-shift = <2>;
+				interrupts = <43>;
+		};
+		serial at d0012300 {
+				compatible = "ns16550";
+				reg = <0xd0012300 0x100>;
+				reg-shift = <2>;
+				interrupts = <44>;
+		};
+
+		timer at d0020300 {
+				marvell,timer-25Mhz;
+		};
+	};
+ };
+
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 72d39e5..ad2faa2 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -2,6 +2,13 @@ if ARCH_MVEBU
 
 menu "Marvell SOC with device tree"
 
+config MACH_ARMADA_370_XP_DT
+	bool "Marvell Armada 370 and Aramada XP boards with device-tree support"
+	help
+
+	  Say 'Y' here if you want your kernel to support boards based on
+	  Marvell Armada 370 or Armada XP with device tree.
+
 endmenu
 
 endif
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index f95691b..f01b2c6 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -1 +1,2 @@
 obj-y += common.o
+obj-$(CONFIG_MACH_ARMADA_370_XP_DT) += armada-370-xp-dt.o irq-armada-370-xp.o time-armada-370-xp.o
diff --git a/arch/arm/mach-mvebu/armada-370-xp-dt.c b/arch/arm/mach-mvebu/armada-370-xp-dt.c
new file mode 100644
index 0000000..71b0cca
--- /dev/null
+++ b/arch/arm/mach-mvebu/armada-370-xp-dt.c
@@ -0,0 +1,65 @@
+/*
+ * Device Tree support for Armada XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of_platform.h>
+#include <linux/io.h>
+#include <asm/mach/arch.h>
+#include <mach/mvebu.h>
+#include <mach/armada-370-xp.h>
+#include "common.h"
+
+#define SOFT_RESET_OUT_EN	0x1
+#define RSTOUTN_MASK_ADDR	(MVEBU_REGS_VIRT_BASE | \
+					ARMADA_370_XP_RSTOUTN_MASK_OFFSET)
+#define SOFT_RESET		0x1
+#define SYSTEM_SOFT_RESET_ADDR	(MVEBU_REGS_VIRT_BASE| \
+					ARMADA_370_XP_SYSTEM_SOFT_RESET_OFFSET)
+
+static void armada_370_xp_restart(char mode, const char *cmd)
+{
+	/*
+	* Enable soft reset to assert RSTOUTn.
+	*/
+	writel(SOFT_RESET_OUT_EN, RSTOUTN_MASK_ADDR);
+	/*
+	* Assert soft reset.
+	*/
+	writel(SOFT_RESET, SYSTEM_SOFT_RESET_ADDR);
+	while (1)
+		;
+}
+
+static void __init armada_370_xp_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char * const armada_370_xp_dt_board_dt_compat[] = {
+	"marvell,a370-db",
+	"marvell,axp-db",
+	NULL,
+};
+
+DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
+	.init_machine	= armada_370_xp_dt_init,
+	.map_io		= mvebu_map_io,
+	.init_irq	= armada_370_xp_init_irq,
+	.handle_irq     = armada_370_xp_handle_irq,
+	.timer		= &armada_370_xp_timer,
+	.restart	= armada_370_xp_restart,
+	.dt_compat	= armada_370_xp_dt_board_dt_compat,
+MACHINE_END
+
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 7bf0879..7917ab4 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -15,6 +15,10 @@
 #ifndef __ARCH_ARMADA_COMMON_H
 #define __ARCH_ARMADA_COMMON_H
 
+extern struct sys_timer armada_370_xp_timer;
+
 void mvebu_map_io(void);
+void armada_370_xp_init_irq(void);
+asmlinkage void  armada_370_xp_handle_irq(struct pt_regs *regs);
 
 #endif
diff --git a/arch/arm/mach-mvebu/include/mach/armada-370-xp.h b/arch/arm/mach-mvebu/include/mach/armada-370-xp.h
new file mode 100644
index 0000000..e4fc9d4
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/armada-370-xp.h
@@ -0,0 +1,22 @@
+/*
+ * Generic definitions for Marvell Armada_370_Xp SoCs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __MACH_ARMADA_370_XP_H
+#define __MACH_ARMADA_370_XP_H
+
+/* Misc registers */
+#define ARMADA_370_XP_RSTOUTN_MASK_OFFSET	0x18260
+#define ARMADA_370_XP_SYSTEM_SOFT_RESET_OFFSET	0x18264
+
+#endif /* __MACH_ARMADA_370_XP_H */
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/arch/arm/mach-mvebu/irq-armada-370-xp.c
new file mode 100644
index 0000000..06604e3
--- /dev/null
+++ b/arch/arm/mach-mvebu/irq-armada-370-xp.c
@@ -0,0 +1,130 @@
+/*
+ * Marvall Armada 370 and Armada XP SoC IRQ handling
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ * Ben Dooks <ben.dooks@codethink.co.uk>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/irqdomain.h>
+#include <asm/mach/arch.h>
+#include <asm/exception.h>
+
+/* Interrupt Controller Registers Map */
+#define ARMADA_370_XP_INT_SET_MASK_OFFS		(0x48)
+#define ARMADA_370_XP_INT_CLEAR_MASK_OFFS	(0x4C)
+
+#define ARMADA_370_XP_INT_SET_ENABLE_OFFS	(0x30)
+#define ARMADA_370_XP_INT_CLEAR_ENABLE_OFFS	(0x34)
+
+#define ARMADA_370_XP_CPU_INTACK_OFFS		(0x44)
+
+#define ARMADA_370_XP_NR_IRQS			(115)
+
+static void __iomem *per_cpu_int_base;
+static void __iomem *main_int_base;
+static struct irq_domain *armada_370_xp_mpic_domain;
+
+static void armada_370_xp_irq_mask(struct irq_data *d)
+{
+	writel(irqd_to_hwirq(d),
+	       per_cpu_int_base + ARMADA_370_XP_INT_SET_MASK_OFFS);
+}
+
+static void armada_370_xp_irq_unmask(struct irq_data *d)
+{
+	writel(irqd_to_hwirq(d),
+	       per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+}
+
+static struct irq_chip armada_370_xp_irq_chip = {
+	.name		= "armada_370_xp_irq",
+	.irq_mask       = armada_370_xp_irq_mask,
+	.irq_mask_ack   = armada_370_xp_irq_mask,
+	.irq_unmask     = armada_370_xp_irq_unmask,
+};
+
+static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
+				      unsigned int virq, irq_hw_number_t hw)
+{
+	armada_370_xp_irq_mask(irq_get_irq_data(virq));
+	writel(hw, main_int_base + ARMADA_370_XP_INT_SET_ENABLE_OFFS);
+
+	irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
+				 handle_level_irq);
+	irq_set_status_flags(virq, IRQ_LEVEL);
+	set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+
+	return 0;
+}
+
+static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
+	.map = armada_370_xp_mpic_irq_map,
+	.xlate = irq_domain_xlate_onecell,
+};
+
+static int __init armada_370_xp_mpic_of_init(struct device_node *node,
+					     struct device_node *parent)
+{
+	main_int_base = of_iomap(node, 0);
+	per_cpu_int_base = of_iomap(node, 1);
+
+	BUG_ON(!main_int_base);
+	BUG_ON(!per_cpu_int_base);
+
+	armada_370_xp_mpic_domain =
+	    irq_domain_add_linear(node, ARMADA_370_XP_NR_IRQS,
+				  &armada_370_xp_mpic_irq_ops, NULL);
+
+	if (!armada_370_xp_mpic_domain)
+		panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
+
+	irq_set_default_host(armada_370_xp_mpic_domain);
+	return 0;
+}
+
+asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
+							       *regs)
+{
+	u32 irqstat, irqnr;
+
+	do {
+		irqstat = readl_relaxed(per_cpu_int_base +
+					ARMADA_370_XP_CPU_INTACK_OFFS);
+		irqnr = irqstat & 0x3FF;
+
+		if (irqnr < 1023) {
+			irqnr =
+			    irq_find_mapping(armada_370_xp_mpic_domain, irqnr);
+			handle_IRQ(irqnr, regs);
+			continue;
+		}
+
+		break;
+	} while (1);
+}
+
+static const struct of_device_id mpic_of_match[] __initconst = {
+	{.compatible = "marvell,mpic", .data = armada_370_xp_mpic_of_init},
+	{},
+};
+
+void __init armada_370_xp_init_irq(void)
+{
+	of_irq_init(mpic_of_match);
+}
diff --git a/arch/arm/mach-mvebu/time-armada-370-xp.c b/arch/arm/mach-mvebu/time-armada-370-xp.c
new file mode 100644
index 0000000..104b88a
--- /dev/null
+++ b/arch/arm/mach-mvebu/time-armada-370-xp.c
@@ -0,0 +1,244 @@
+/*
+ * Marvell Armada SoC timer handling.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Timer 0 is used as free-running clocksource, while timer 1 is
+ * used as clock_event_device.
+ */
+
+#include <linux/kernel.h>
+#include <linux/timer.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/irq.h>
+#include <asm/sched_clock.h>
+#include <asm/mach/time.h>
+
+/*
+ * Timer block registers.
+ */
+#define TIMER_CTRL_OFF		0x0000
+#define  TIMER0_EN		 0x0001
+#define  TIMER0_RELOAD_EN	 0x0002
+#define  TIMER0_25MHZ            0x0800
+#define  TIMER0_DIV(div)         ((div) << 19)
+#define  TIMER1_EN		 0x0004
+#define  TIMER1_RELOAD_EN	 0x0008
+#define  TIMER1_25MHZ            0x1000
+#define  TIMER1_DIV(div)         ((div) << 22)
+#define TIMER_EVENTS_STATUS	0x0004
+#define  TIMER0_CLR_MASK         (~0x1)
+#define  TIMER1_CLR_MASK         (~0x100)
+#define TIMER0_RELOAD_OFF	0x0010
+#define TIMER0_VAL_OFF		0x0014
+#define TIMER1_RELOAD_OFF	0x0018
+#define TIMER1_VAL_OFF		0x001c
+
+/* Global timers are connected to the coherency fabric clock, and the
+   below divider reduces their incrementing frequency. */
+#define TIMER_DIVIDER_SHIFT     5
+#define TIMER_DIVIDER           (1 << TIMER_DIVIDER_SHIFT)
+
+/*
+ * SoC-specific data.
+ */
+static void __iomem *timer_base;
+static int timer_irq;
+
+/*
+ * Number of timer ticks per jiffy.
+ */
+static u32 ticks_per_jiffy;
+
+static u32 notrace armada_370_xp_read_sched_clock(void)
+{
+	return ~readl(timer_base + TIMER0_VAL_OFF);
+}
+
+/*
+ * Clockevent handling.
+ */
+static int
+armada_370_xp_clkevt_next_event(unsigned long delta,
+				struct clock_event_device *dev)
+{
+	unsigned long flags;
+	u32 u;
+
+	if (delta == 0)
+		return -ETIME;
+
+	local_irq_save(flags);
+
+	/*
+	 * Clear clockevent timer interrupt.
+	 */
+	writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
+
+	/*
+	 * Setup new clockevent timer value.
+	 */
+	writel(delta, timer_base + TIMER1_VAL_OFF);
+
+	/*
+	 * Enable the timer.
+	 */
+	u = readl(timer_base + TIMER_CTRL_OFF);
+	u = ((u & ~TIMER1_RELOAD_EN) | TIMER1_EN |
+	     TIMER1_DIV(TIMER_DIVIDER_SHIFT));
+	writel(u, timer_base + TIMER_CTRL_OFF);
+
+	local_irq_restore(flags);
+
+	return 0;
+}
+
+static void
+armada_370_xp_clkevt_mode(enum clock_event_mode mode,
+			  struct clock_event_device *dev)
+{
+	unsigned long flags;
+	u32 u;
+
+	local_irq_save(flags);
+	if (mode == CLOCK_EVT_MODE_PERIODIC) {
+		/*
+		 * Setup timer to fire@1/HZ intervals.
+		 */
+		writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD_OFF);
+		writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL_OFF);
+
+		/*
+		 * Enable timer.
+		 */
+		u = readl(timer_base + TIMER_CTRL_OFF);
+
+		writel((u | TIMER1_EN | TIMER1_RELOAD_EN |
+			TIMER1_DIV(TIMER_DIVIDER_SHIFT)),
+		       timer_base + TIMER_CTRL_OFF);
+	} else {
+		/*
+		 * Disable timer.
+		 */
+		u = readl(timer_base + TIMER_CTRL_OFF);
+		writel(u & ~TIMER1_EN, timer_base + TIMER_CTRL_OFF);
+
+		/*
+		 * ACK pending timer interrupt.
+		 */
+		writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
+
+	}
+	local_irq_restore(flags);
+}
+
+static struct clock_event_device armada_370_xp_clkevt = {
+	.name		= "armada_370_xp_tick",
+	.features	= CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
+	.shift		= 32,
+	.rating		= 300,
+	.set_next_event	= armada_370_xp_clkevt_next_event,
+	.set_mode	= armada_370_xp_clkevt_mode,
+};
+
+static irqreturn_t armada_370_xp_timer_interrupt(int irq, void *dev_id)
+{
+	/*
+	 * ACK timer interrupt and call event handler.
+	 */
+
+	writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
+	armada_370_xp_clkevt.event_handler(&armada_370_xp_clkevt);
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction armada_370_xp_timer_irq = {
+	.name		= "armada_370_xp_tick",
+	.flags		= IRQF_DISABLED | IRQF_TIMER,
+	.handler	= armada_370_xp_timer_interrupt
+};
+
+static void __init armada_370_xp_time_init(void)
+{
+	u32 u;
+	struct device_node *np;
+	unsigned int timer_clk;
+	int ret;
+
+	np = of_find_compatible_node(NULL, NULL, "marvell,timer");
+	timer_base = of_iomap(np, 0);
+	WARN_ON(!timer_base);
+
+	if (of_find_property(np, "marvell,timer-25Mhz", NULL)) {
+		/* The fixed 25MHz timer is available so let's use it */
+		u = readl(timer_base + TIMER_CTRL_OFF);
+		writel(u | TIMER0_25MHZ | TIMER1_25MHZ,
+		       timer_base + TIMER_CTRL_OFF);
+		timer_clk = 25000000;
+	} else {
+		u32 clk = 0;
+		ret = of_property_read_u32(np, "clock-frequency", &clk);
+		WARN_ON(!clk || ret < 0);
+		u = readl(timer_base + TIMER_CTRL_OFF);
+		writel(u & ~(TIMER0_25MHZ | TIMER1_25MHZ),
+		       timer_base + TIMER_CTRL_OFF);
+		timer_clk = clk / TIMER_DIVIDER;
+	}
+
+	/* We use timer 0 as clocksource, and timer 1 for
+	   clockevents */
+	timer_irq = irq_of_parse_and_map(np, 1);
+
+	ticks_per_jiffy = (timer_clk + HZ / 2) / HZ;
+
+	/*
+	 * Set scale and timer for sched_clock.
+	 */
+	setup_sched_clock(armada_370_xp_read_sched_clock, 32, timer_clk);
+
+	/*
+	 * Setup free-running clocksource timer (interrupts
+	 * disabled).
+	 */
+	writel(0xffffffff, timer_base + TIMER0_VAL_OFF);
+	writel(0xffffffff, timer_base + TIMER0_RELOAD_OFF);
+
+	u = readl(timer_base + TIMER_CTRL_OFF);
+
+	writel((u | TIMER0_EN | TIMER0_RELOAD_EN |
+		TIMER0_DIV(TIMER_DIVIDER_SHIFT)), timer_base + TIMER_CTRL_OFF);
+
+	clocksource_mmio_init(timer_base + TIMER0_VAL_OFF,
+			      "armada_370_xp_clocksource",
+			      timer_clk, 300, 32, clocksource_mmio_readl_down);
+
+	/*
+	 * Setup clockevent timer (interrupt-driven).
+	 */
+	setup_irq(timer_irq, &armada_370_xp_timer_irq);
+	armada_370_xp_clkevt.mult = div_sc(timer_clk, NSEC_PER_SEC,
+					   armada_370_xp_clkevt.shift);
+	armada_370_xp_clkevt.max_delta_ns = clockevent_delta2ns(0xfffffffe,
+							&armada_370_xp_clkevt);
+	armada_370_xp_clkevt.min_delta_ns =
+	    clockevent_delta2ns(1, &armada_370_xp_clkevt);
+	armada_370_xp_clkevt.cpumask = cpumask_of(0);
+	clockevents_register_device(&armada_370_xp_clkevt);
+}
+
+struct sys_timer armada_370_xp_timer = {
+	.init = armada_370_xp_time_init,
+};
-- 
1.7.9.5

[PATCH v2 5/8] arm: mach-mvebu: add documentation for new device tree bindings

[Gregory CLEMENT]

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
 .../devicetree/bindings/arm/armada_370_xp-mpic.txt |   23 +++++++++++++++++++
 .../bindings/arm/armada_370_xp-timer.txt           |   11 +++++++++
 .../devicetree/bindings/arm/armada_370_xp.txt      |   24 ++++++++++++++++++++
 3 files changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/armada_370_xp-mpic.txt
 create mode 100644 Documentation/devicetree/bindings/arm/armada_370_xp-timer.txt
 create mode 100644 Documentation/devicetree/bindings/arm/armada_370_xp.txt

diff --git a/Documentation/devicetree/bindings/arm/armada_370_xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada_370_xp-mpic.txt
new file mode 100644
index 0000000..70c0dc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada_370_xp-mpic.txt
@@ -0,0 +1,23 @@
+Marvell Armada 370 and Armada XP Interrupt Controller
+-----------------------------------------------------
+
+Required properties:
+- compatible: Should be "marvell,mpic"
+- interrupt-controller: Identifies the node as an interrupt controller.
+- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
+  The cell is the IRQ number
+- reg: Should contain PMIC registers location and length. First pair
+  for the main interrupt registers, second pair for the per-CPU
+  interrupt registers
+
+Example:
+
+        mpic: interrupt-controller at d0020000 {
+              compatible = "marvell,mpic";
+              #interrupt-cells = <1>;
+              #address-cells = <1>;
+              #size-cells = <1>;
+              interrupt-controller;
+              reg = <0xd0020000 0x1000>,
+                    <0xd0021000 0x1000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/armada_370_xp-timer.txt b/Documentation/devicetree/bindings/arm/armada_370_xp-timer.txt
new file mode 100644
index 0000000..d14dc7f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada_370_xp-timer.txt
@@ -0,0 +1,11 @@
+Marvell Armada 370 and Armada XP Global Timers
+----------------------------------------------
+
+Required properties:
+- compatible: Should be "marvell,timer"
+- interrupts: Should contain the list of Global Timer interrupts
+- reg: Should contain the base address of the Global Timer registers
+
+Optional properties:
+- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
+  Mhz fixed mode (available on Armada XP and not on Armada 370)
diff --git a/Documentation/devicetree/bindings/arm/armada_370_xp.txt b/Documentation/devicetree/bindings/arm/armada_370_xp.txt
new file mode 100644
index 0000000..3cdd793
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada_370_xp.txt
@@ -0,0 +1,24 @@
+Marvell Armada 370 and Armada XP Platforms Device Tree Bindings
+---------------------------------------------------------------
+
+Boards with a SoC of the Marvell Armada 370 and Armada XP families
+shall have the following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armada_370_xp"
+
+In addition, boards using the Marvell Armada 370 SoC shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armada370"
+
+In addition, boards using the Marvell Armada XP SoC shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armadaxp"
+
-- 
1.7.9.5

[PATCH v2 6/8] arm: mach-mvebu: add defconfig

[Gregory CLEMENT]

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
 arch/arm/configs/mvebu_defconfig |   47 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 arch/arm/configs/mvebu_defconfig

diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
new file mode 100644
index 0000000..92203b87
--- /dev/null
+++ b/arch/arm/configs/mvebu_defconfig
@@ -0,0 +1,47 @@
+CONFIG_EXPERIMENTAL=y
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EXPERT=y
+CONFIG_SLAB=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_ARCH_MVEBU=y
+CONFIG_MACH_ARMADA_370_XP_DT=y
+CONFIG_AEABI=y
+CONFIG_HIGHMEM=y
+CONFIG_USE_OF=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_VFP=y
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_RUNTIME_UARTS=2
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_FS_XATTR is not set
+CONFIG_ISO9660_FS=y
+CONFIG_JOLIET=y
+CONFIG_UDF_FS=m
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_850=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_ISO8859_2=y
+CONFIG_NLS_UTF8=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_FS=y
+# CONFIG_SCHED_DEBUG is not set
+CONFIG_TIMER_STATS=y
+# CONFIG_DEBUG_BUGVERBOSE is not set
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_USER=y
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
-- 
1.7.9.5

[PATCH v2 7/8] arm: mach-mvebu: add entry to MAINTAINERS

[Gregory CLEMENT]

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
 MAINTAINERS |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 55f0fda..afd1673f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -894,6 +894,14 @@ ARM/MAGICIAN MACHINE SUPPORT
 M:	Philipp Zabel <philipp.zabel@gmail.com>
 S:	Maintained
 
+ARM/Marvell Armada 370 and Armada XP SOC support
+M:	Gregory Clement <gregory.clement@free-electrons.com>
+M:	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+M:	Lior Amsalem <alior@marvell.com>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+F:	arch/arm/mach-mvebu/
+
 ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support
 M:	Jason Cooper <jason@lakedaemon.net>
 M:	Andrew Lunn <andrew@lunn.ch>
-- 
1.7.9.5

[PATCH v2 8/8] ARM: mvebu: MPIC: read number of interrupts from control register

[Gregory CLEMENT]

From: Ben Dooks <ben.dooks@codethink.co.uk>

Read the number of MPIC interrupts from the controller and only register
that many.

[gregory.clement at free-electrons.com: rename armada symbol name to fit
with new name: armada_370_xp]

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
 arch/arm/mach-mvebu/irq-armada-370-xp.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/arch/arm/mach-mvebu/irq-armada-370-xp.c
index 06604e3..19498f8 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/arch/arm/mach-mvebu/irq-armada-370-xp.c
@@ -29,13 +29,12 @@
 #define ARMADA_370_XP_INT_SET_MASK_OFFS		(0x48)
 #define ARMADA_370_XP_INT_CLEAR_MASK_OFFS	(0x4C)
 
+#define ARMADA_370_XP_INT_CONTROL		(0x00)
 #define ARMADA_370_XP_INT_SET_ENABLE_OFFS	(0x30)
 #define ARMADA_370_XP_INT_CLEAR_ENABLE_OFFS	(0x34)
 
 #define ARMADA_370_XP_CPU_INTACK_OFFS		(0x44)
 
-#define ARMADA_370_XP_NR_IRQS			(115)
-
 static void __iomem *per_cpu_int_base;
 static void __iomem *main_int_base;
 static struct irq_domain *armada_370_xp_mpic_domain;
@@ -81,14 +80,18 @@ static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
 static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 					     struct device_node *parent)
 {
+	u32 control;
+
 	main_int_base = of_iomap(node, 0);
 	per_cpu_int_base = of_iomap(node, 1);
 
 	BUG_ON(!main_int_base);
 	BUG_ON(!per_cpu_int_base);
 
+	control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
+
 	armada_370_xp_mpic_domain =
-	    irq_domain_add_linear(node, ARMADA_370_XP_NR_IRQS,
+	    irq_domain_add_linear(node, (control >> 2) & 0x3ff,
 				  &armada_370_xp_mpic_irq_ops, NULL);
 
 	if (!armada_370_xp_mpic_domain)
-- 
1.7.9.5

[PATCH v2 1/8] arm: mach-mvebu: add header

[Andrew Lunn]

> diff --git a/arch/arm/mach-mvebu/include/mach/uncompress.h b/arch/arm/mach-mvebu/include/mach/uncompress.h
> new file mode 100644
> index 0000000..3642997
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/include/mach/uncompress.h
> @@ -0,0 +1,41 @@
> +/*
> + * Marvell Armada SoC kernel uncompression UART routines
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <mach/mvebu.h>
> +
> +#define UART_THR ((volatile unsigned char *)(MVEBU_REGS_PHYS_BASE + 0x12000))
> +#define UART_LSR ((volatile unsigned char *)(MVEBU_REGS_PHYS_BASE + 0x12014))

All Orion's place the UART at the same physical address. So i've got
this on my TODO list, to have one implementation in plat-orion.

However, you have moved away from plat-orion, so i wounder were would
be a good place to have this?

   Andrew

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[David Marlin]

I noticed that you are using mach-mvebu in these patches.  I have seen 
these machines referred to as 'armada', 'axp', 'armadaxp', etc.  Will 
'mvebu' be the official machine name to use for these systems?  I'm 
looking for a 'name' to identify the common kernel for these systems. 
For reference, the names of the ARM kernels we are currently building in 
Fedora include: 'highbank', 'imx', 'kirkwood', 'omap', and 'tegra'.


Thank you,

d.marlin
===========


Gregory CLEMENT wrote:
> Arnd, Olof,
> 
> You'll find in this patch set the new version of the initial support for a
> new family of ARMv7-compatible Marvell SoCs initially submitted by my
> colleague Thomas Petazzoni. Following the conclusion of the discussion when
> we submitted our first version we have chosen to add this support for this
> SoC family in the to support in the arch/arm/mach-mvebu/ directory.
> 
> As for the previous release, both the Armada 370 and the Armada XP SoCs are
> supported in this directory, and we are able to build a single kernel image
> that boots on both SoCs. Both SoCs use the PJ4B processor, a
> Marvell-developed ARM core that implements the ARMv7 instruction set. We are
> currently using Marvell evaluation boards for both of those SoCs, and the
> support for those boards is added in this patch set.
> 
> We remained focused on a limited preliminary support which only includes the
> necessary code for timer and IRQ support, the serial controller is a
> standard 16550-compatible one. The diffstat looks like:
> 
>  Documentation/devicetree/bindings/arm/armada_370_xp-mpic.txt  |   23 +
>  Documentation/devicetree/bindings/arm/armada_370_xp-timer.txt |   11 +
>  Documentation/devicetree/bindings/arm/armada_370_xp.txt       |   24 +
>  MAINTAINERS                                                   |    8 +
>  arch/arm/Kconfig                                              |   15 +
>  arch/arm/Makefile                                             |    1 +
>  arch/arm/boot/dts/armada-370-db.dts                           |   41 ++
>  arch/arm/boot/dts/armada-370-xp.dtsi                          |   66 +++
>  arch/arm/boot/dts/armada-370.dtsi                             |   29 +
>  arch/arm/boot/dts/armada-xp-db.dts                            |   40 ++
>  arch/arm/boot/dts/armada-xp.dtsi                              |   49 ++
>  arch/arm/configs/mvebu_defconfig                              |   47 ++
>  arch/arm/mach-mvebu/Kconfig                                   |   14 +
>  arch/arm/mach-mvebu/Makefile                                  |    2 +
>  arch/arm/mach-mvebu/Makefile.boot                             |    1 +
>  arch/arm/mach-mvebu/armada-370-xp-dt.c                        |   65 +++
>  arch/arm/mach-mvebu/common.c                                  |   36 ++
>  arch/arm/mach-mvebu/common.h                                  |   24 +
>  arch/arm/mach-mvebu/include/mach/armada-370-xp.h              |   22 +
>  arch/arm/mach-mvebu/include/mach/debug-macro.S                |   24 +
>  arch/arm/mach-mvebu/include/mach/mvebu.h                      |   22 +
>  arch/arm/mach-mvebu/include/mach/timex.h                      |   13 +
>  arch/arm/mach-mvebu/include/mach/uncompress.h                 |   41 ++
>  arch/arm/mach-mvebu/irq-armada-370-xp.c                       |  133 +++++
>  arch/arm/mach-mvebu/time-armada-370-xp.c                      |  244 +++++++++
>  25 files changed, 995 insertions(+)
> 
> This patch set, and the support for those SoCs, started as a collaborative
> effort from Marvell engineers (who have done the initial development work)
> and Free Electrons engineers (who are reshaping the code for mainline
> submission, adding device tree support, etc.). And for this new version we
> got contributions from Ben Dooks from Codethink.
> 
> The patch set is based on your arm-soc/for-next branch (updated on Monday
> 11th June).
> 
> The main change between V1 and V2 is the use of a new mach-mvebu directory
> as this directory is aimed to receive most of the Marvell SOC converted to
> the device tree, we intended to make the code less specific. The other main
> part was to remove all the unnecessary code or even files.
> 
> Here comes a pretty exhaustive list of the changes:
> 
> * Created a new mach- directory called mach-mvebu as suggested on the
>  mainling-list. Converted most the "armada" word by the "mvebu", but as some
>  code remains specific to the armada 370 and armada XP SOC, then created
>  also the aramada_370_xp suffix for this part. This suffix was dedicated for
>  the irq and timer part. It was also used for the register related to the
>  reset part. And of course it was also used for the device tree part.
> 
> * Merged axp-dt.c and a370-dt.c files in one single armada_370_xp-dt.c file.
> 
> * Deleted most of the mapping address in include/mach/armada.h and split it
>   in two headers file:
> 
>   - mvebu.h which contains the virtual and physical mapping for the internal
>     registers of the mvebu SOC. This ones are mainly used for the early
>     print during boot.
> 
>   - armada_370_xp which contains the registers offset and mask for resetting
>     the CPU.
> 
> * Removed unused headers such as
>   - hardware.h by directly including accurate header when needed
>   - gpio.h by removing the dependencies to PLAT-ORION
>   - io.h no more needed for CPI
>   - irqs.h by using SPARSE_IRQ
>   - system.h no more needed for new SOC
> 
> * Removed the PCI related code as it was not necessary for the initial
>   submission
> 
> * Removed all the PLAT-ORION dependencies remaining
> 
> * Ensured property reading checks for error when getting data from device
>   tree in the timer file. This was a patch from Ben Dooks with the following
>   comments:
> 
>   "The call to of_property_read_u32() only checks for the value that the clk
>    variable is set to being non-zero, and not the return value of the call
>    itself.
> 
>    This caused a system without the clock-frequency attribute to fail to
>    boot as it used a random value on the stack to setup the system timers
>    and thus cause an interrupt storm.
> 
>    Also ensure clk is set to zero, to avoid warnings."
> 
> * Converted irq.c to use SPARSE_IRQ
> 
> * Added the following bug fixes and improvements in irq.c from Ben Dooks
>   
>   - MPIC: BUG_ON() if the of_iomap() fails: Ensure that if either resource
>     is missing, we stop the kernel in a reasonably fatal way.
> 
>   - MPIC: Move main register base to base of MPIC registers: The current
>     kernel driver had the MPIC base at the base of the block containing the
>     MPIC and not the MPIC itself. Change this value in the driver and the
>     .dtsi file
> 
> 	Also change the register size in the .dtsi to be the size of the
> 	register range for the MIPC and not the block it is in.
> 
>   - MPIC: Move per-cpu register base: The current kernel driver had the MPIC
>   	per-cpu register base at the base of the per-cpu register block and not
>   	at the base of the specific per-cpu interrupt registers.
> 
> 	Move the driver and .dtsi to use the correct base and size.
> 
>   - MPIC: number fetch should use irqd_to_hwirq(): The mask and unmask
>   	routines are assuming that d->irq is a 1:1 mapping with the interrupt
>   	hardware. Use the irqd_to_hwirq() call to map the irq_data to the
>   	hardware irq number directly.
> 
>   - MPIC: read number of interrupts from control register: Read the number
>    	of MPIC interrupts from the controller and only register that many.
> 
> Andrew Lunn asked for refactoring the _restart() function to being used by
> any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers
> mapping differs between the SOC and the bit mask too. A solution could be to
> get this mapping through the device tree, but we are not sure it was a good
> usage of the device tree.
> 
> 
> Best regards,
> 
> Gregory Clement

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Gregory CLEMENT]

On 06/11/2012 10:44 PM, David Marlin wrote:
> 
> I noticed that you are using mach-mvebu in these patches.  I have seen 
> these machines referred to as 'armada', 'axp', 'armadaxp', etc.  Will 
> 'mvebu' be the official machine name to use for these systems?  I'm 
> looking for a 'name' to identify the common kernel for these systems. 
> For reference, the names of the ARM kernels we are currently building in 
> Fedora include: 'highbank', 'imx', 'kirkwood', 'omap', and 'tegra'.
> 
> 
> Thank you,
> 
> d.marlin
> ===========
> 

Hello David,

Mvebu is aimed to be the official name for the all the SOC with device tree
support coming out of Marvell's EBU division. As stated Nicolas Pitre: "One
thing that is common to Orion/Kirkwood/Dove/(insert some Armada flavours
here)/etc though is that they came out of Marvell's EBU division."

For the beginning only Armada XP and Armada 370 are in this directory but as
son as the other Marvell architectures will be converted to device tree they
will be moved to mach-mvebu.

For extensive explanation see the thread starting at this point
http://thread.gmane.org/gmane.linux.ports.arm.kernel/167744/focus=167782.


> 
> Gregory CLEMENT wrote:
>> Arnd, Olof,
>>
>> You'll find in this patch set the new version of the initial support for a
>> new family of ARMv7-compatible Marvell SoCs initially submitted by my
>> colleague Thomas Petazzoni. Following the conclusion of the discussion when
>> we submitted our first version we have chosen to add this support for this
>> SoC family in the to support in the arch/arm/mach-mvebu/ directory.
-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Andrew Lunn]

On Tue, Jun 12, 2012 at 09:35:58AM +0200, Gregory CLEMENT wrote:
> On 06/11/2012 10:44 PM, David Marlin wrote:
> > 
> > I noticed that you are using mach-mvebu in these patches.  I have seen 
> > these machines referred to as 'armada', 'axp', 'armadaxp', etc.  Will 
> > 'mvebu' be the official machine name to use for these systems?  I'm 
> > looking for a 'name' to identify the common kernel for these systems. 
> > For reference, the names of the ARM kernels we are currently building in 
> > Fedora include: 'highbank', 'imx', 'kirkwood', 'omap', and 'tegra'.
> > 
> > 
> > Thank you,
> > 
> > d.marlin
> > ===========
> > 
> 
> Hello David,
> 
> Mvebu is aimed to be the official name for the all the SOC with device tree
> support coming out of Marvell's EBU division. As stated Nicolas Pitre: "One
> thing that is common to Orion/Kirkwood/Dove/(insert some Armada flavours
> here)/etc though is that they came out of Marvell's EBU division."
> 
> For the beginning only Armada XP and Armada 370 are in this directory but as
> son as the other Marvell architectures will be converted to device tree they
> will be moved to mach-mvebu.

So it still seems like we have a naming issue. We have given a usable
name to the directory. But what do we call the kernel? This is what
David wants to know. When we have moved the DT enabled architectures
into mach-mvebu, they are still likely to build a ARMv5 kernel for
Kirkwood and Orion5x, and a ARMv7 kernel for Dove plus these two new
SoCs. But what do we call this new kernel?

      Andrew

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Arnd Bergmann]

On Monday 11 June 2012, David Marlin wrote:
> I noticed that you are using mach-mvebu in these patches.  I have seen 
> these machines referred to as 'armada', 'axp', 'armadaxp', etc.  Will 
> 'mvebu' be the official machine name to use for these systems?  I'm 
> looking for a 'name' to identify the common kernel for these systems. 
> For reference, the names of the ARM kernels we are currently building in 
> Fedora include: 'highbank', 'imx', 'kirkwood', 'omap', and 'tegra'.

The 'mvebu' family will include the 'kirkwood' parts you are already building
for along with the 'orion' and 'mv78xx0' when building for ARMv5, and
will include the existing 'dove' soc in addition to the new Armada 370 and
Armada XP when building for ARMv7.

All the other ones you are currently building are ARMv6 or ARMv7 based, so
I'd hope that in the long run (maybe the end of the year), we can get to
the point of building them into a common kernel.

	Arnd

[PATCH v2 3/8] arm: mach-mvebu: add compilation/configuration change

[Arnd Bergmann]

On Monday 11 June 2012, Gregory CLEMENT wrote:
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Lior Amsalem <alior@marvell.com>

Please always keep this patch last in the series, as soon as it is applied,
one can build a kernel for mvebu, which ends up not working. Each step
in a patch series needs to provide a working, incremental improvement
over the previous one, so when adding a new feature in parts, you can
only enable it once you have something that actually builds.

	Arnd

[PATCH v2 2/8] arm: mach-mvebu: add source files

[Arnd Bergmann]

On Monday 11 June 2012, Gregory CLEMENT wrote:
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> new file mode 100644
> index 0000000..72d39e5
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -0,0 +1,7 @@
> +if ARCH_MVEBU
> +
> +menu "Marvell SOC with device tree"
> +
> +endmenu
> +
> +endif

The "with device tree" part is implied here, so you should not need to
mention it, but it would be good if you could say which SOC this
relates to, i.e. not the pxa/mmp series but the other line, in whatever
way you want to name it.

> +static struct map_desc mvebu_io_desc[] __initdata = {
> +	{
> +		.virtual	= MVEBU_REGS_VIRT_BASE,
> +		.pfn		= __phys_to_pfn(MVEBU_REGS_PHYS_BASE),
> +		.length		= MVEBU_REGS_SIZE,
> +		.type		= MT_DEVICE,
> +	},
> +};
> +
> +void __init mvebu_map_io(void)
> +{
> +	iotable_init(mvebu_io_desc, ARRAY_SIZE(mvebu_io_desc));
> +}

It looks like MVEBU_REGS_PHYS_BASE is common between Armada XP and
Armada 370, but is different for the other ones we want to support
here (kirkwood, orion5x, mv78xx0, dove), so the name seems to be
inappropriate. I would recommend dropping the entire file and just
leaving the map_desc in the individual soc specific files, even
thouth that means you have two identical calls here.

	Arnd

[PATCH v2 2/8] arm: mach-mvebu: add source files

[Gregory CLEMENT]

On 06/12/2012 10:45 AM, Arnd Bergmann wrote:
> On Monday 11 June 2012, Gregory CLEMENT wrote:
>> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
>> new file mode 100644
>> index 0000000..72d39e5
>> --- /dev/null
>> +++ b/arch/arm/mach-mvebu/Kconfig
>> @@ -0,0 +1,7 @@
>> +if ARCH_MVEBU
>> +
>> +menu "Marvell SOC with device tree"
>> +
>> +endmenu
>> +
>> +endif
>
> The "with device tree" part is implied here, so you should not need to
> mention it, but it would be good if you could say which SOC this
> relates to, i.e. not the pxa/mmp series but the other line, in whatever
> way you want to name it.

Do you mean to name all the SOC aimed to be supported ?
and write something like that:

menu "Marvell SOC from EBU division (Orion, Kirkwood, Dove, MV78xx0,
Armada 370/XP, ...)"

Or for now just the currently supported SOC ? :
menu "Marvell SOC from EBU division (Armada 370, Armada XP, ...)"


>
>> +static struct map_desc mvebu_io_desc[] __initdata = {
>> +	{
>> +		.virtual	= MVEBU_REGS_VIRT_BASE,
>> +		.pfn		= __phys_to_pfn(MVEBU_REGS_PHYS_BASE),
>> +		.length		= MVEBU_REGS_SIZE,
>> +		.type		= MT_DEVICE,
>> +	},
>> +};
>> +
>> +void __init mvebu_map_io(void)
>> +{
>> +	iotable_init(mvebu_io_desc, ARRAY_SIZE(mvebu_io_desc));
>> +}
>
> It looks like MVEBU_REGS_PHYS_BASE is common between Armada XP and
> Armada 370, but is different for the other ones we want to support
> here (kirkwood, orion5x, mv78xx0, dove), so the name seems to be
> inappropriate. I would recommend dropping the entire file and just
> leaving the map_desc in the individual soc specific files, even
> thouth that means you have two identical calls here.

OK I will drop common.* files. We will see later to introduce them
again when we find common features with the other SOC.

>
> 	Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044

[PATCH v2 3/8] arm: mach-mvebu: add compilation/configuration change

[Gregory CLEMENT]

On 06/12/2012 10:39 AM, Arnd Bergmann wrote:
> On Monday 11 June 2012, Gregory CLEMENT wrote:
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Signed-off-by: Lior Amsalem <alior@marvell.com>
> 
> Please always keep this patch last in the series, as soon as it is applied,
> one can build a kernel for mvebu, which ends up not working. Each step
> in a patch series needs to provide a working, incremental improvement
> over the previous one, so when adding a new feature in parts, you can
> only enable it once you have something that actually builds.
> 

Ok I will move this patch at the end of the serie for the next version.


> 	Arnd
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044

[PATCH v2 4/8] arm: mach-mvebu: add support for Armada 370 and Armada XP with DT

[Arnd Bergmann]

On Monday 11 June 2012, Gregory CLEMENT wrote:
> +	soc {
> +		serial at d0012000 {
> +			clock-frequency = <200000000>;
> +		};
> +		timer at d0020300 {
> +			clock-frequency = <600000000>;
> +
> +		};
> +	};
> +};

In most platforms, we mark the "serial" device and anything else that
might not be connected as "disabled" in the .dtsi file, and enable the
ones that are actually used in the board specific .dts file. I think it
makes sense to also do that here.

> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index 72d39e5..ad2faa2 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -2,6 +2,13 @@ if ARCH_MVEBU
>  
>  menu "Marvell SOC with device tree"
>  
> +config MACH_ARMADA_370_XP_DT
> +	bool "Marvell Armada 370 and Aramada XP boards with device-tree support"
> +	help
> +
> +	  Say 'Y' here if you want your kernel to support boards based on
> +	  Marvell Armada 370 or Armada XP with device tree.
> +
>  endmenu
>  
>  endif
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/armada-370-xp-dt.c

Please dtop the _dt postfix everywhere here.

> @@ -0,0 +1,65 @@
> +/*
> + * Device Tree support for Armada XP platforms.
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/of_platform.h>
> +#include <linux/io.h>
> +#include <asm/mach/arch.h>
> +#include <mach/mvebu.h>
> +#include <mach/armada-370-xp.h>
> +#include "common.h"
> +
> +#define SOFT_RESET_OUT_EN	0x1
> +#define RSTOUTN_MASK_ADDR	(MVEBU_REGS_VIRT_BASE | \
> +					ARMADA_370_XP_RSTOUTN_MASK_OFFSET)
> +#define SOFT_RESET		0x1
> +#define SYSTEM_SOFT_RESET_ADDR	(MVEBU_REGS_VIRT_BASE| \
> +					ARMADA_370_XP_SYSTEM_SOFT_RESET_OFFSET)

We should not be hardcoding addresses like this any more IMHO:

> +static void armada_370_xp_restart(char mode, const char *cmd)
> +{
> +	/*
> +	* Enable soft reset to assert RSTOUTn.
> +	*/
> +	writel(SOFT_RESET_OUT_EN, RSTOUTN_MASK_ADDR);
> +	/*
> +	* Assert soft reset.
> +	*/
> +	writel(SOFT_RESET, SYSTEM_SOFT_RESET_ADDR);
> +	while (1)
> +		;
> +}

This function is the same one that's used for the existing mvebu platforms,
just with a different offset. I think it would be nice to put it into a
reset.c file along with some code that looks for the location.

For instance, you can look for the device that holds the "bridge regs"
and then either add the 0x108 or the 0x18260 offset, depending on its
compatible property.

> diff --git a/arch/arm/mach-mvebu/time-armada-370-xp.c b/arch/arm/mach-mvebu/time-armada-370-xp.c
> new file mode 100644
> index 0000000..104b88a
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/time-armada-370-xp.c

I think this file should go into drivers/clocksource instead of the arch directory.

	Arnd

[PATCH v2 2/8] arm: mach-mvebu: add source files

[Arnd Bergmann]

On Tuesday 12 June 2012, Gregory CLEMENT wrote:
> On 06/12/2012 10:45 AM, Arnd Bergmann wrote:
> > On Monday 11 June 2012, Gregory CLEMENT wrote:
> >> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> >> new file mode 100644
> >> index 0000000..72d39e5
> >> --- /dev/null
> >> +++ b/arch/arm/mach-mvebu/Kconfig
> >> @@ -0,0 +1,7 @@
> >> +if ARCH_MVEBU
> >> +
> >> +menu "Marvell SOC with device tree"
> >> +
> >> +endmenu
> >> +
> >> +endif
> >
> > The "with device tree" part is implied here, so you should not need to
> > mention it, but it would be good if you could say which SOC this
> > relates to, i.e. not the pxa/mmp series but the other line, in whatever
> > way you want to name it.
> 
> Do you mean to name all the SOC aimed to be supported ?
> and write something like that:
> 
> menu "Marvell SOC from EBU division (Orion, Kirkwood, Dove, MV78xx0,
> Armada 370/XP, ...)"
> 
> Or for now just the currently supported SOC ? :
> menu "Marvell SOC from EBU division (Armada 370, Armada XP, ...)"

Either way is fine for me.

> OK I will drop common.* files. We will see later to introduce them
> again when we find common features with the other SOC.

Ok. We might just name them after the specific feature that gets
implemented then.

	Arnd

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Arnd Bergmann]

On Monday 11 June 2012, Gregory CLEMENT wrote:
> You'll find in this patch set the new version of the initial support for a
> new family of ARMv7-compatible Marvell SoCs initially submitted by my
> colleague Thomas Petazzoni. Following the conclusion of the discussion when
> we submitted our first version we have chosen to add this support for this
> SoC family in the to support in the arch/arm/mach-mvebu/ directory.
> 
> As for the previous release, both the Armada 370 and the Armada XP SoCs are
> supported in this directory, and we are able to build a single kernel image
> that boots on both SoCs. Both SoCs use the PJ4B processor, a
> Marvell-developed ARM core that implements the ARMv7 instruction set. We are
> currently using Marvell evaluation boards for both of those SoCs, and the
> support for those boards is added in this patch set.

Ok, very good.

> Andrew Lunn asked for refactoring the _restart() function to being used by
> any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers
> mapping differs between the SOC and the bit mask too. A solution could be to
> get this mapping through the device tree, but we are not sure it was a good
> usage of the device tree.

As I suggested in my reply to patch 4/8, I think this can be encapsulated
in one file that acts as a driver for the generic ("bridge regs") registers
and provides functions for that based on the "compatible" property.

On a more general note, I'd prefer to have the patches renaming the existing
files first for the mach-mvebu directory first, and then adding your patches
on top.

I can provide a new version of the patch I did once we have agreement on what
goes where. I've put some more thought into it and the best I could come up
with is now.

arch/arm/mach-{orion5x,dove,kirkwood,mv78xx0}/include/mach/*
	-> arch/arm/mach-mvebu/include/mach/
arch/arm/plat-orion/include/plat/*
	-> arch/arm/mach-mvebu/include/mach/
arch/arm/plat-orion/*
	-> arch/arm/mach-mvebu/
arch/arm/mach-{orion5x,dove,kirkwood,mv78xx0}/{add-map,common,irq,mpp,pci}.*
	-> arch/arm/mach-mvebu/
arch/arm/mach-kirkwood/board-* (DT files)
	-> arch/arm/mach-mvebu/

This is basically the same as the patch I sent out before, but with the
new machine name, and leaving all the *-setup.c files in their existing
locations, where they can either get removed after being converted to DT
or after being assumed dead.

	Arnd

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Gregory CLEMENT]

On 06/12/2012 03:49 PM, Arnd Bergmann wrote:
> On Monday 11 June 2012, Gregory CLEMENT wrote:
>> You'll find in this patch set the new version of the initial support for a
>> new family of ARMv7-compatible Marvell SoCs initially submitted by my
>> colleague Thomas Petazzoni. Following the conclusion of the discussion when
>> we submitted our first version we have chosen to add this support for this
>> SoC family in the to support in the arch/arm/mach-mvebu/ directory.
>>
>> As for the previous release, both the Armada 370 and the Armada XP SoCs are
>> supported in this directory, and we are able to build a single kernel image
>> that boots on both SoCs. Both SoCs use the PJ4B processor, a
>> Marvell-developed ARM core that implements the ARMv7 instruction set. We are
>> currently using Marvell evaluation boards for both of those SoCs, and the
>> support for those boards is added in this patch set.
> 
> Ok, very good.
> 
>> Andrew Lunn asked for refactoring the _restart() function to being used by
>> any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers
>> mapping differs between the SOC and the bit mask too. A solution could be to
>> get this mapping through the device tree, but we are not sure it was a good
>> usage of the device tree.
> 
> As I suggested in my reply to patch 4/8, I think this can be encapsulated
> in one file that acts as a driver for the generic ("bridge regs") registers
> and provides functions for that based on the "compatible" property.
> 
> On a more general note, I'd prefer to have the patches renaming the existing
> files first for the mach-mvebu directory first, and then adding your patches
> on top.
> 
> I can provide a new version of the patch I did once we have agreement on what
> goes where. I've put some more thought into it and the best I could come up
> with is now.

OK we wait for your new version of this patch to rebase our work on top of it.

> 
> arch/arm/mach-{orion5x,dove,kirkwood,mv78xx0}/include/mach/*
> 	-> arch/arm/mach-mvebu/include/mach/
> arch/arm/plat-orion/include/plat/*
> 	-> arch/arm/mach-mvebu/include/mach/
> arch/arm/plat-orion/*
> 	-> arch/arm/mach-mvebu/
> arch/arm/mach-{orion5x,dove,kirkwood,mv78xx0}/{add-map,common,irq,mpp,pci}.*
> 	-> arch/arm/mach-mvebu/
> arch/arm/mach-kirkwood/board-* (DT files)
> 	-> arch/arm/mach-mvebu/
> 
> This is basically the same as the patch I sent out before, but with the
> new machine name, and leaving all the *-setup.c files in their existing
> locations, where they can either get removed after being converted to DT
> or after being assumed dead.
> 
> 	Arnd


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Andrew Lunn]

> arch/arm/mach-kirkwood/board-* (DT files)
> 	-> arch/arm/mach-mvebu/

I know of work being done to make orion5x and dove also support DT.
Should we consider some sort of prefix or midfix indicating which SoC
a board file is for? It will not be easy to mentally keep track of
board-ts209.c is an orion5x and board-ts219.c is kirkwood etc.

      Andrew

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Jason Cooper]

On Tue, Jun 12, 2012 at 04:06:16PM +0200, Andrew Lunn wrote:
> > arch/arm/mach-kirkwood/board-* (DT files)
> > 	-> arch/arm/mach-mvebu/
> 
> I know of work being done to make orion5x and dove also support DT.
> Should we consider some sort of prefix or midfix indicating which SoC
> a board file is for? It will not be easy to mentally keep track of
> board-ts209.c is an orion5x and board-ts219.c is kirkwood etc.

The board-BOARD.c files are transitional files, and will disappear once
the DT conversion is done.  All that will remain is board-dt.c.  So,
there is no long-term issue.  Since it's a short term issue, and we're
moving/renaming anyway, how about kirkwood-dreamplug.c, orion5x-ts209.c,
etc?

I personally don't think it's needed, but I have no strong opinion on
it.

thx,

Jason.

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Arnd Bergmann]

On Tuesday 12 June 2012, Jason Cooper wrote:
> On Tue, Jun 12, 2012 at 04:06:16PM +0200, Andrew Lunn wrote:
> > > arch/arm/mach-kirkwood/board-* (DT files)
> > >     -> arch/arm/mach-mvebu/
> > 
> > I know of work being done to make orion5x and dove also support DT.
> > Should we consider some sort of prefix or midfix indicating which SoC
> > a board file is for? It will not be easy to mentally keep track of
> > board-ts209.c is an orion5x and board-ts219.c is kirkwood etc.
> 
> The board-BOARD.c files are transitional files, and will disappear once
> the DT conversion is done.  All that will remain is board-dt.c.  So,
> there is no long-term issue.  Since it's a short term issue, and we're
> moving/renaming anyway, how about kirkwood-dreamplug.c, orion5x-ts209.c,
> etc?

I was going to suggest the same.

FWIW, the board-dt.c from mach-kirkwood should just become kirkwood.c
and we might want to merge it with the kirkwood common.c file in the long
run, if any contents from that file remain for the dt version.

	Arnd

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Jason Cooper]

On Tue, Jun 12, 2012 at 02:59:13PM +0000, Arnd Bergmann wrote:
> On Tuesday 12 June 2012, Jason Cooper wrote:
> > On Tue, Jun 12, 2012 at 04:06:16PM +0200, Andrew Lunn wrote:
> > > > arch/arm/mach-kirkwood/board-* (DT files)
> > > >     -> arch/arm/mach-mvebu/
> > > 
> > > I know of work being done to make orion5x and dove also support DT.
> > > Should we consider some sort of prefix or midfix indicating which SoC
> > > a board file is for? It will not be easy to mentally keep track of
> > > board-ts209.c is an orion5x and board-ts219.c is kirkwood etc.
> > 
> > The board-BOARD.c files are transitional files, and will disappear once
> > the DT conversion is done.  All that will remain is board-dt.c.  So,
> > there is no long-term issue.  Since it's a short term issue, and we're
> > moving/renaming anyway, how about kirkwood-dreamplug.c, orion5x-ts209.c,
> > etc?
> 
> FWIW, the board-dt.c from mach-kirkwood should just become kirkwood.c
> and we might want to merge it with the kirkwood common.c file in the long
> run, if any contents from that file remain for the dt version.

So, there would be an orion5x.c, dove.c as well?  Or, should it be
mvebu.c to encompass all of them?

thx,

Jason.

[PATCH v2 2/8] arm: mach-mvebu: add source files

[Nicolas Pitre]

On Tue, 12 Jun 2012, Gregory CLEMENT wrote:

> On 06/12/2012 10:45 AM, Arnd Bergmann wrote:
> > On Monday 11 June 2012, Gregory CLEMENT wrote:
> >> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> >> new file mode 100644
> >> index 0000000..72d39e5
> >> --- /dev/null
> >> +++ b/arch/arm/mach-mvebu/Kconfig
> >> @@ -0,0 +1,7 @@
> >> +if ARCH_MVEBU
> >> +
> >> +menu "Marvell SOC with device tree"
> >> +
> >> +endmenu
> >> +
> >> +endif
> >
> > The "with device tree" part is implied here, so you should not need to
> > mention it, but it would be good if you could say which SOC this
> > relates to, i.e. not the pxa/mmp series but the other line, in whatever
> > way you want to name it.
> 
> Do you mean to name all the SOC aimed to be supported ?
> and write something like that:
> 
> menu "Marvell SOC from EBU division (Orion, Kirkwood, Dove, MV78xx0,
> Armada 370/XP, ...)"
> 
> Or for now just the currently supported SOC ? :
> menu "Marvell SOC from EBU division (Armada 370, Armada XP, ...)"

Naming SOCs that are not supported yet is bad.

Constantly modifying this title is also unwieldy when it gets long.

Having a comprehensive list of supported SOCs is very useful though, but 
I think this should go in the help text not in the menu title.


Nicolas

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Arnd Bergmann]

On Tuesday 12 June 2012, Jason Cooper wrote:
> > 
> > FWIW, the board-dt.c from mach-kirkwood should just become kirkwood.c
> > and we might want to merge it with the kirkwood common.c file in the long
> > run, if any contents from that file remain for the dt version.
> 
> So, there would be an orion5x.c, dove.c as well?  Or, should it be
> mvebu.c to encompass all of them?

Yes, I think we should have one of those files contain the DT_MACHINE
definition for that soc type, unless they are unified to the point where
we only need one.

	Arnd

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Jon Masters]

On 06/11/2012 12:52 PM, Gregory CLEMENT wrote:

> You'll find in this patch set the new version of the initial support for a
> new family of ARMv7-compatible Marvell SoCs initially submitted by my
> colleague Thomas Petazzoni. Following the conclusion of the discussion when
> we submitted our first version we have chosen to add this support for this
> SoC family in the to support in the arch/arm/mach-mvebu/ directory.

Pardon my silly question. I know that there's an effort to reconcile the
two different SoCs so you're picking a neutral name, but what does
"mvebu" mean, and will you be persistently keeping this name? Our guys
want to know what this new platform will entail for Fedora support in
terms of the platform name being used in various non-kernel places.

Jon.

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Gregory CLEMENT]

On 06/13/2012 05:06 PM, Jon Masters wrote:
> On 06/11/2012 12:52 PM, Gregory CLEMENT wrote:
> 
>> You'll find in this patch set the new version of the initial support for a
>> new family of ARMv7-compatible Marvell SoCs initially submitted by my
>> colleague Thomas Petazzoni. Following the conclusion of the discussion when
>> we submitted our first version we have chosen to add this support for this
>> SoC family in the to support in the arch/arm/mach-mvebu/ directory.
> 
> Pardon my silly question. I know that there's an effort to reconcile the
> two different SoCs so you're picking a neutral name, but what does
> "mvebu" mean, and will you be persistently keeping this name? Our guys
> want to know what this new platform will entail for Fedora support in
> terms of the platform name being used in various non-kernel places.

Hello Jon,

As I explained to Martin
"Mvebu is aimed to be the official name for the all the SOC with device tree
support coming out of Marvell's EBU division. As stated Nicolas Pitre: "One
thing that is common to Orion/Kirkwood/Dove/(insert some Armada flavours
here)/etc though is that they came out of Marvell's EBU division."

[...]

For extensive explanation see the thread starting at this point
http://thread.gmane.org/gmane.linux.ports.arm.kernel/167744/focus=167782.
"

So MVEBU is not only for Armada XP and Armada 370 but also for other
Marvell SOCs such as Kirkwood or Orion for example.


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Arnd Bergmann]

On Wednesday 13 June 2012, Jon Masters wrote:
> On 06/11/2012 12:52 PM, Gregory CLEMENT wrote:
> 
> > You'll find in this patch set the new version of the initial support for a
> > new family of ARMv7-compatible Marvell SoCs initially submitted by my
> > colleague Thomas Petazzoni. Following the conclusion of the discussion when
> > we submitted our first version we have chosen to add this support for this
> > SoC family in the to support in the arch/arm/mach-mvebu/ directory.
> 
> Pardon my silly question. I know that there's an effort to reconcile the
> two different SoCs so you're picking a neutral name, but what does
> "mvebu" mean, and will you be persistently keeping this name? Our guys
> want to know what this new platform will entail for Fedora support in
> terms of the platform name being used in various non-kernel places.

We've had an extended discussion about the name when the patches
were posted for the first time. It was just the best thing that anyone
suggested so far given the alternatives.

"EBU" is the business unit that makes all the SoCs in this family
(orion, kirkwood, armadaxp, dove, ...) and no other name that was
suggested covers all of these but not also at least some of the other
Marvell SoCs (pxa, mmp, armada1000, ...).

Just "ebu" would not be very clear, and other variations (mv-ebu,
mrvl-ebu) were considered to be too long.

	Arnd

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Jason Cooper]

On Wed, Jun 13, 2012 at 11:06:06AM -0400, Jon Masters wrote:
> On 06/11/2012 12:52 PM, Gregory CLEMENT wrote:
> 
> > You'll find in this patch set the new version of the initial support for a
> > new family of ARMv7-compatible Marvell SoCs initially submitted by my
> > colleague Thomas Petazzoni. Following the conclusion of the discussion when
> > we submitted our first version we have chosen to add this support for this
> > SoC family in the to support in the arch/arm/mach-mvebu/ directory.
> 
> Pardon my silly question. I know that there's an effort to reconcile the
> two different SoCs so you're picking a neutral name, but what does
> "mvebu" mean, and will you be persistently keeping this name? 

As persistent as anything else is in life ;-P  It covers all the SoCs that
have come out of Marvell's EBU division.  This includes orion5x,
kirkwood, dove, mv78xxx, the new armada xp, etc.

We're placing all boards under that umbrella with DT support into
mach-mvebu/.  Eventually, once DT conversion is complete, the other
directories will empty out and mach-mvebu/ will hold all support for
those SoCs.

Currently, the only boards with DT support are in mach-kirkwood/: the
dreamplug, iconnect, and a few others.  Before it gets too out of hand,
Arnd has a patch series which consolidates it all into mach-mvebu/.

> Our guys want to know what this new platform will entail for Fedora
> support in terms of the platform name being used in various non-kernel
> places.

I'm not familiar with how Fedora does it, but debian has five different
armel kernels, each supporting a range of boards.

linux-image-iop32x
linux-image-ixp4xx
linux-image-kirkwood
linux-image-orion5x
linux-image-versatile

At the very least, they will be able to consolidate -kirkwood and
-orion5x into linux-image-mvebu if they choose.


hth,

Jason.

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Nicolas Pitre]

On Wed, 13 Jun 2012, Jon Masters wrote:

> On 06/11/2012 12:52 PM, Gregory CLEMENT wrote:
> 
> > You'll find in this patch set the new version of the initial support for a
> > new family of ARMv7-compatible Marvell SoCs initially submitted by my
> > colleague Thomas Petazzoni. Following the conclusion of the discussion when
> > we submitted our first version we have chosen to add this support for this
> > SoC family in the to support in the arch/arm/mach-mvebu/ directory.
> 
> Pardon my silly question. I know that there's an effort to reconcile the
> two different SoCs so you're picking a neutral name, but what does
> "mvebu" mean, and will you be persistently keeping this name? Our guys
> want to know what this new platform will entail for Fedora support in
> terms of the platform name being used in various non-kernel places.

Marvell like to create different names for similar things and also reuse 
the same name for totally different things.  While this might look good 
for marketing purposes, we kernel developers prefer to gather things 
together according to shared support code.

Within Marvell there are actually 2 distinct SOC families: the one 
acquired from Intel with the XScale/PXA origin, and Marvell's own design 
that produced Orion, Kirkwood, Dove, etc.

The former is found under mach-pxa and mach-mmp. The later is getting 
way too scattered, currently using mach-dove, mach-kirkwood, 
mach-mv78xx0, mach-orion5x, and two more were proposed for the new SOCs.

Since all SOCs in the later family came from the EBU division within 
Marvell, and because they share a significant amount of code despite 
their wildly different names, we settled on "mvebu" to gather them 
together in the future.

This is therefore a name for kernel engineering/maintenance purpose 
only. I'd strongly suggest not to use this name in non-kernel places.


Nicolas

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Arnaud Patard (Rtp)]

Jason Cooper <jason@lakedaemon.net> writes:

> On Wed, Jun 13, 2012 at 11:06:06AM -0400, Jon Masters wrote:
>> On 06/11/2012 12:52 PM, Gregory CLEMENT wrote:
>> 
>> > You'll find in this patch set the new version of the initial support for a
>> > new family of ARMv7-compatible Marvell SoCs initially submitted by my
>> > colleague Thomas Petazzoni. Following the conclusion of the discussion when
>> > we submitted our first version we have chosen to add this support for this
>> > SoC family in the to support in the arch/arm/mach-mvebu/ directory.
>> 
>> Pardon my silly question. I know that there's an effort to reconcile the
>> two different SoCs so you're picking a neutral name, but what does
>> "mvebu" mean, and will you be persistently keeping this name? 
>
> As persistent as anything else is in life ;-P  It covers all the SoCs that
> have come out of Marvell's EBU division.  This includes orion5x,
> kirkwood, dove, mv78xxx, the new armada xp, etc.
>
> We're placing all boards under that umbrella with DT support into
> mach-mvebu/.  Eventually, once DT conversion is complete, the other
> directories will empty out and mach-mvebu/ will hold all support for
> those SoCs.
>
> Currently, the only boards with DT support are in mach-kirkwood/: the
> dreamplug, iconnect, and a few others.  Before it gets too out of hand,
> Arnd has a patch series which consolidates it all into mach-mvebu/.
>
>> Our guys want to know what this new platform will entail for Fedora
>> support in terms of the platform name being used in various non-kernel
>> places.
>
> I'm not familiar with how Fedora does it, but debian has five
> different

nitpick: 6 different

> armel kernels, each supporting a range of boards.
>
> linux-image-iop32x
> linux-image-ixp4xx
> linux-image-kirkwood
> linux-image-orion5x
> linux-image-versatile

there's also linux-image-mv78xx0.

Regards,
Arnaud

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Thomas Petazzoni]

Hello Arnd,

Le Tue, 12 Jun 2012 13:49:27 +0000,
Arnd Bergmann <arnd@arndb.de> a ?crit :

> > Andrew Lunn asked for refactoring the _restart() function to being used by
> > any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers
> > mapping differs between the SOC and the bit mask too. A solution could be to
> > get this mapping through the device tree, but we are not sure it was a good
> > usage of the device tree.
> 
> As I suggested in my reply to patch 4/8, I think this can be encapsulated
> in one file that acts as a driver for the generic ("bridge regs") registers
> and provides functions for that based on the "compatible" property.

The problem here is that those registers are part of a random set of
registers, that do not really constitute a sort of coherent "device",
as we have for other IP blocks (SATA controllers, SPI controllers,
etc.). First of all, the "bridge regs" name was unfortunate and a
left-over from early versions of the code, the datasheet does not refer
to them as "bridge registers" in any location.

On the Armada 370, the registers needed to restart the machine are part
of a "Miscellaneous Registers" section in the list of register
sections. This Miscellaneous Registers are 32 bits registers organized
as follows:

 * SoC Control Register
 * SoC Device Mux Register
 * Power Management Memory Power Down 2 Register
 * Power Management Memory Power Down 3 Register
 * Power Management Memory Power Down 4 Register
 * Power Management Memory Power Down 5 Register
 * Power Management Clock Gating Control Register
 * Power Management Memory Power Down 6 Register
 * Sample at Reset Register
 * Sample at Register High Register
 * Device ID Register
 * CPU SoC ID Register 
 * SYSRSTn Length Counter Register
 * RSTOUTn Mask Register -- this one needed for restart
 * System Soft Reset Register -- this one needed for restart
 * Shared SERDES 063 selectors Register
 * Boot ROM Routine and Error Code Register
 * PCI Express Boot Address Register

This registers are more or less contiguous, from offset 0x18204 to
0x182D4. As you can see, the purpose of those registers are very
different from one register to another, so it's kind of odd to create a
"driver" that would span those registers.

On the Armada XP, we have a "System Registers" area, subdivided by the
datasheet in "Configuration and Control", "QSGMII Control and Status",
"SERDES", "Power Management and Memory Power Down", "Thermal Manager",
"BootROM", "Interrupt, "Design for Testability". But from an
offset/address perspective, some registers of the "Power Management and
Memory Power Down" subsection are in the middle of the registers of the
"Configuration and Control" registers.

For the restart problem on Armada XP, the two registers of interest are
within the "Configuration and Control" subsection.

Our biggest problem is that all those registers do not really match
very well with a device/driver representation, so we don't know how to
nicely represent them in the device tree. How would you recommend to
handle these?

If further details are needed on the registers organization in order to
find the best solution, I'll be happy to provide them.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v2] arm: Add basic support for new Marvell Armada 370 and Armada XP SoC

[Arnd Bergmann]

On Wednesday 13 June 2012, Thomas Petazzoni wrote:
> Hello Arnd,
> 
> Le Tue, 12 Jun 2012 13:49:27 +0000,
> Arnd Bergmann <arnd@arndb.de> a ?crit :
> 
> > > Andrew Lunn asked for refactoring the _restart() function to being used by
> > > any MVEBU SOC, but we didn't find a nice way to do it. Indeed the registers
> > > mapping differs between the SOC and the bit mask too. A solution could be to
> > > get this mapping through the device tree, but we are not sure it was a good
> > > usage of the device tree.
> > 
> > As I suggested in my reply to patch 4/8, I think this can be encapsulated
> > in one file that acts as a driver for the generic ("bridge regs") registers
> > and provides functions for that based on the "compatible" property.
> 
> The problem here is that those registers are part of a random set of
> registers, that do not really constitute a sort of coherent "device",
> as we have for other IP blocks (SATA controllers, SPI controllers,
> etc.). First of all, the "bridge regs" name was unfortunate and a
> left-over from early versions of the code, the datasheet does not refer
> to them as "bridge registers" in any location.
> 
> On the Armada 370, the registers needed to restart the machine are part
> of a "Miscellaneous Registers" section in the list of register
> sections. This Miscellaneous Registers are 32 bits registers organized
> as follows:
> 
>  * SoC Control Register
>  * SoC Device Mux Register
>  * Power Management Memory Power Down 2 Register
>  * Power Management Memory Power Down 3 Register
>  * Power Management Memory Power Down 4 Register
>  * Power Management Memory Power Down 5 Register
>  * Power Management Clock Gating Control Register
>  * Power Management Memory Power Down 6 Register
>  * Sample at Reset Register
>  * Sample at Register High Register
>  * Device ID Register
>  * CPU SoC ID Register 
>  * SYSRSTn Length Counter Register
>  * RSTOUTn Mask Register -- this one needed for restart
>  * System Soft Reset Register -- this one needed for restart
>  * Shared SERDES 063 selectors Register
>  * Boot ROM Routine and Error Code Register
>  * PCI Express Boot Address Register
> 
> This registers are more or less contiguous, from offset 0x18204 to
> 0x182D4. As you can see, the purpose of those registers are very
> different from one register to another, so it's kind of odd to create a
> "driver" that would span those registers.

We have the same problem on other platforms as well.

> On the Armada XP, we have a "System Registers" area, subdivided by the
> datasheet in "Configuration and Control", "QSGMII Control and Status",
> "SERDES", "Power Management and Memory Power Down", "Thermal Manager",
> "BootROM", "Interrupt, "Design for Testability". But from an
> offset/address perspective, some registers of the "Power Management and
> Memory Power Down" subsection are in the middle of the registers of the
> "Configuration and Control" registers.
> 
> For the restart problem on Armada XP, the two registers of interest are
> within the "Configuration and Control" subsection.
> 
> Our biggest problem is that all those registers do not really match
> very well with a device/driver representation, so we don't know how to
> nicely represent them in the device tree. How would you recommend to
> handle these?

I think there should be a "system controller" device that takes care of
all of those registers in the device tree, and a file to provide accessor
functions for the individual registers. It should be fairly straightforward
to implement this, but there are multiple ways of how to get there,
depending on how these register areas differ between the various SOCs
in the mvebu family:

1. If the layout is identical or very similar for all of these, I would
just do one driver that provides high-level accessors for each
register, such as the "restart" function. Small differences can be
handled by looking up a part number, e.g. the PCI access functions 
could return an error on parts that have no PCI.

2. If the individual registers are all the same but their location
differs, you might want to represent each set of registers as an
individual device node and then look up the location when probing
for the system controller device. You would however not make that
a "simple_bus", so you don't get a platform_device for each of them.

3. If they are very different, you can just export a "regmap" from
the main driver, and use different offsets in drivers using that,
depending on the specific SOC.

	Arnd