Skip to contentSkip to conversation

arm: Add basic support for new Marvell Armada SoC family

PATCH New Thomas Petazzoni 15 participants 140 messages May 15, 2012 – May 24, 2012

Subsystems (16)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Arnd, Olof,

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

At the moment, 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.

This preliminary support 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-mpic.txt  |   23 +
 Documentation/devicetree/bindings/arm/armada-timer.txt |   11 
 Documentation/devicetree/bindings/arm/armada.txt       |   24 +
 MAINTAINERS                                            |    8 
 arch/arm/Kconfig                                       |   12 
 arch/arm/Makefile                                      |    1 
 arch/arm/boot/dts/a370-db.dts                          |   41 ++
 arch/arm/boot/dts/a370.dtsi                            |   23 +
 arch/arm/boot/dts/armada.dtsi                          |   67 ++++
 arch/arm/boot/dts/axp-db.dts                           |   40 ++
 arch/arm/boot/dts/axp.dtsi                             |   43 +++
 arch/arm/configs/armada_defconfig                      |   47 +++
 arch/arm/mach-armada/Kconfig                           |   19 +
 arch/arm/mach-armada/Makefile                          |    3 
 arch/arm/mach-armada/Makefile.boot                     |    1 
 arch/arm/mach-armada/a370-dt.c                         |   41 ++
 arch/arm/mach-armada/axp-dt.c                          |   41 ++
 arch/arm/mach-armada/common.c                          |   56 +++
 arch/arm/mach-armada/common.h                          |   27 +
 arch/arm/mach-armada/include/mach/armada.h             |  234 ++++++++++++++++
 arch/arm/mach-armada/include/mach/bridge-regs.h        |   28 +
 arch/arm/mach-armada/include/mach/debug-macro.S        |   23 +
 arch/arm/mach-armada/include/mach/gpio.h               |   13 
 arch/arm/mach-armada/include/mach/hardware.h           |   18 +
 arch/arm/mach-armada/include/mach/io.h                 |   24 +
 arch/arm/mach-armada/include/mach/irqs.h               |   96 ++++++
 arch/arm/mach-armada/include/mach/system.h             |   21 +
 arch/arm/mach-armada/include/mach/timex.h              |   13 
 arch/arm/mach-armada/include/mach/uncompress.h         |   41 ++
 arch/arm/mach-armada/irq.c                             |  116 ++++++++
 arch/arm/mach-armada/time.c                            |  243 +++++++++++++++++
 31 files changed, 1398 insertions(+)

This patch set, and the support for those SoCs, is at the moment 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.). Other contributors are expected to join this effort.

The patch set is based on your arm-soc/for-next branch.

We intend to quickly build on top of this initial support with the following elements:

* Usage of the clock framework

* Usage the pinctrl subsystem and GPIO subsystems for pin-muxing and GPIO support

* SMP support

* L2 cache support

* Integration with device drivers. Many of the IPs used in these Marvell SoCs are similar to the ones used in previous Marvell SoCs (for SATA, USB and more), but the drivers for those IPs will require modification to add a device tree binding.

Of course, we welcome all comments on this initial submission and are ready to quickly submit updated versions of the patch set to take into those comments.

Best regards,

Thomas Petazzoni

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#1 lore raw

PATCH 1/8 arm: mach-armada: add headers

From: Gregory CLEMENT <[email protected]>

This patch adds basic header files for Armada SoCs.

---
 arch/arm/mach-armada/include/mach/armada.h      |  234 +++++++++++++++++++++++
 arch/arm/mach-armada/include/mach/bridge-regs.h |   28 +++
 arch/arm/mach-armada/include/mach/debug-macro.S |   23 +++
 arch/arm/mach-armada/include/mach/gpio.h        |   13 ++
 arch/arm/mach-armada/include/mach/hardware.h    |   18 ++
 arch/arm/mach-armada/include/mach/io.h          |   24 +++
 arch/arm/mach-armada/include/mach/irqs.h        |   96 ++++++++++
 arch/arm/mach-armada/include/mach/system.h      |   21 ++
 arch/arm/mach-armada/include/mach/timex.h       |   13 ++
 arch/arm/mach-armada/include/mach/uncompress.h  |   41 ++++
 10 files changed, 511 insertions(+)
 create mode 100644 arch/arm/mach-armada/include/mach/armada.h
 create mode 100644 arch/arm/mach-armada/include/mach/bridge-regs.h
 create mode 100644 arch/arm/mach-armada/include/mach/debug-macro.S
 create mode 100644 arch/arm/mach-armada/include/mach/gpio.h
 create mode 100644 arch/arm/mach-armada/include/mach/hardware.h
 create mode 100644 arch/arm/mach-armada/include/mach/io.h
 create mode 100644 arch/arm/mach-armada/include/mach/irqs.h
 create mode 100644 arch/arm/mach-armada/include/mach/system.h
 create mode 100644 arch/arm/mach-armada/include/mach/timex.h
 create mode 100644 arch/arm/mach-armada/include/mach/uncompress.h
arch/arm/mach-armada/include/mach/armada.h new file +234 -0
new file mode 100644
index 0000000..be12667
@@ -0,0 +1,234 @@
+/*
+ * Generic definitions for Marvell Armada SoCs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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_H
+#define __MACH_ARMADA_H
+
+/*
+ * Marvell ARMADA address maps.
+ *
+ * phys		virt		size
+ * d0000000	feb00000	1M	internal registers
+ * d0100000	@runtime	1M	uart
+ * d0200000	fec00000	1M	PCIe-0 I/O (port 0.0)
+ * d0300000	fed00000	1M	PCIe-1 I/O (port 1.0)
+ * d0400000	fee00000	1M	PCIe-2 I/O (port 2.0)
+ * d0500000	fef00000	1M	PCIe-3 I/O (port 3.0)
+ * d0600000	@runtime	1M	cryptographic sram-0
+ * d0700000	@runtime	1M	cryptographic sram-1
+ * d0800000	reserved	8M	reserved for future
+ * d1000000	@runtime	16M	device bus cs-0
+ * d2000000	@runtime	16M	device bus cs-0
+ * d3000000	@runtime	16M	device bus cs-0
+ * d4000000	@runtime	16M	device bus cs-0
+ * d5000000	@runtime	16M	device bus boot cs
+ * d6000000	@runtime	16M	spi-0 flash
+ * d7000000	@runtime	16M	spi-1 flash
+ * d8000000	@runtime	64M	PCIe-0 Memory (port 0.0)
+ * dc000000	@runtime	64M	PCIe-1 Memory (port 1.0)
+ * e0000000	@runtime	64M	PCIe-2 Memory (port 2.0)
+ * e4000000	@runtime	64M	PCIe-3 Memory (port 3.0)
+ * fff00000	@runtime	1M	internal bootrom
+ */
+
+#define ARMADA_REGS_PHYS_BASE		0xd0000000
+#define ARMADA_REGS_VIRT_BASE		0xfeb00000
+#define ARMADA_REGS_SIZE		SZ_1M
+
+#define ARMADA_UART_REGS_BASE		0xd0100000
+#define ARMADA_UART_SIZE		_1M
+
+#define ARMADA_PCIE0_IO_PHYS_BASE	0xd0200000
+#define ARMADA_PCIE0_IO_VIRT_BASE	0xfec00000
+#define ARMADA_PCIE0_IO_BUS_BASE	0x00100000
+#define ARMADA_PCIE0_IO_SIZE		SZ_1M
+
+#define ARMADA_PCIE1_IO_PHYS_BASE	0xd0300000
+#define ARMADA_PCIE1_IO_VIRT_BASE	0xfed00000
+#define ARMADA_PCIE1_IO_BUS_BASE	0x00200000
+#define ARMADA_PCIE1_IO_SIZE		SZ_1M
+
+#define ARMADA_PCIE2_IO_PHYS_BASE	0xd0400000
+#define ARMADA_PCIE2_IO_VIRT_BASE	0xfee00000
+#define ARMADA_PCIE2_IO_BUS_BASE	0x00300000
+#define ARMADA_PCIE2_IO_SIZE		SZ_1M
+
+#define ARMADA_PCIE3_IO_PHYS_BASE	0xd0500000
+#define ARMADA_PCIE3_IO_VIRT_BASE	0xfef00000
+#define ARMADA_PCIE3_IO_BUS_BASE	0x00400000
+#define ARMADA_PCIE3_IO_SIZE		SZ_1M
+
+#define ARMADA_CESA0_PHYS_BASE		0xd0600000
+#define ARMADA_CESA0_SIZE		SZ_1M
+
+#define ARMADA_CESA1_PHYS_BASE		0xd0700000
+#define ARMADA_CESA1_SIZE		SZ_1M
+
+#define ARMADA_DEVICE_CS0_PHYS_BASE	0xd1000000
+#define ARMADA_DEVICE_CS0_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_CS1_PHYS_BASE	0xd2000000
+#define ARMADA_DEVICE_CS1_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_CS2_PHYS_BASE	0xd3000000
+#define ARMADA_DEVICE_CS2_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_CS3_PHYS_BASE	0xd4000000
+#define ARMADA_DEVICE_CS3_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_BOOT_CS_PHYS_BASE	0xd5000000
+#define ARMADA_DEVICE_BOOT_CS_SIZE	SZ_16M
+
+#define ARMADA_SPI0_CS0_PHYS_BASE	0xd6000000
+#define ARMADA_SPI0_CS0_SIZE		SZ_16M
+
+#define ARMADA_SPI1_CS0_PHYS_BASE	0xd7000000
+#define ARMADA_SPI1_CS0_SIZE		SZ_16M
+
+#define ARMADA_PCIE0_MEM_PHYS_BASE	0xd8000000
+#define ARMADA_PCIE0_MEM_SIZE		SZ_64M
+
+#define ARMADA_PCIE1_MEM_PHYS_BASE	0xdc000000
+#define ARMADA_PCIE1_MEM_SIZE		SZ_64M
+
+#define ARMADA_PCIE2_MEM_PHYS_BASE	0xe0000000
+#define ARMADA_PCIE2_MEM_SIZE		SZ_64M
+
+#define ARMADA_PCIE3_MEM_PHYS_BASE	0xe4000000
+#define ARMADA_PCIE3_MEM_SIZE		SZ_64M
+
+#define ARMADA_BOOTROM_PHYS_BASE	0xFFF00000
+#define ARMADA_BOOTROM_SIZE		SZ_1M
+
+/*
+ * Core Registers Map
+ */
+
+/* DRAM */
+#define ARMADA_DRAM_PHYS_BASE     (ARMADA_REGS_PHYS_BASE | 0x0)
+#define ARMADA_DRAM_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x0)
+
+/* L2 Cache */
+#define ARMADA_L2_CACHE_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x8000)
+#define ARMADA_L2_CACHE_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x8000)
+
+/* RTC */
+#define ARMADA_RTC_PHYS_BASE      (ARMADA_REGS_PHYS_BASE | 0x10300)
+#define ARMADA_RTC_VIRT_BASE      (ARMADA_REGS_VIRT_BASE | 0x10300)
+
+/* SPI */
+#define ARMADA_SPI0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x10600)
+#define ARMADA_SPI0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x10600)
+#define ARMADA_SPI1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x10680)
+#define ARMADA_SPI1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x10680)
+
+/* I2C */
+#define ARMADA_I2C0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x11000)
+#define ARMADA_I2C0_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x11000)
+#define ARMADA_I2C1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x11100)
+#define ARMADA_I2C1_VIRT_BASE	(ARMADA_REGS_PHYS_BASE | 0x11100)
+
+/* UART */
+#define ARMADA_UART0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x12000)
+#define ARMADA_UART0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x12000)
+#define ARMADA_UART1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x12100)
+#define ARMADA_UART1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x12100)
+
+/* MPP (pin muxing) */
+#define ARMADA_MPP_PHYS_BASE      (ARMADA_REGS_PHYS_BASE | 0x18000)
+#define ARMADA_MPP_VIRT_BASE      (ARMADA_REGS_VIRT_BASE | 0x18000)
+
+/* GPIO */
+#define ARMADA_GPIO_PHYS_BASE     (ARMADA_REGS_PHYS_BASE | 0x18100)
+#define ARMADA_GPIO_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x18100)
+
+/* Misc registers */
+#define ARMADA_SYSTEM_PHYS_BASE     (ARMADA_REGS_PHYS_BASE | 0x18200)
+#define ARMADA_SYSTEM_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x18200)
+
+/* CPU */
+#define ARMADA_CPU_PHYS_BASE      (ARMADA_REGS_PHYS_BASE | 0x20000)
+#define ARMADA_CPU_VIRT_BASE      (ARMADA_REGS_VIRT_BASE | 0x20000)
+
+/* Audio */
+#define ARMADA_AUDIO_PHYS_BASE    (ARMADA_REGS_PHYS_BASE | 0x30000)
+#define ARMADA_AUDIO_VIRT_BASE    (ARMADA_REGS_VIRT_BASE | 0x30000)
+
+/* PCIe */
+#define ARMADA_PCIE0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x40000)
+#define ARMADA_PCIE0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x40000)
+#define ARMADA_PCIE1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x80000)
+#define ARMADA_PCIE1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x80000)
+#define ARMADA_PCIE2_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x42000)
+#define ARMADA_PCIE2_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x42000)
+#define ARMADA_PCIE3_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x82000)
+#define ARMADA_PCIE3_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x82000)
+
+/* USB */
+#define ARMADA_USB0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x50000)
+#define ARMADA_USB0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x50000)
+#define ARMADA_USB1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x51000)
+#define ARMADA_USB1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x51000)
+
+/* XOR Engines */
+#define ARMADA_XOR0_PHYS_BASE        (ARMADA_REGS_PHYS_BASE | 0x60900)
+#define ARMADA_XOR0_HIGH_PHYS_BASE   (ARMADA_REGS_PHYS_BASE | 0x60B00)
+#define ARMADA_XOR1_PHYS_BASE        (ARMADA_REGS_PHYS_BASE | 0xF0900)
+#define ARMADA_XOR1_HIGH_PHYS_BASE   (ARMADA_REGS_PHYS_BASE | 0xF0B00)
+
+/* Cryptographic Engine */
+#define ARMADA_CRYPT_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x30000)
+
+/* Gigabit Ethernet */
+#define ARMADA_GE00_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x70000)
+#define ARMADA_GE01_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x74000)
+#define ARMADA_GE10_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x30000)
+#define ARMADA_GE11_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x34000)
+
+/* SDIO */
+#define ARMADA_SDIO0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x92000)
+
+/* SATA */
+#define ARMADA_SATA_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0xa0000)
+
+/* NAND Flash Controller */
+#define ARMADA_NFC_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0xd0000)
+
+/* MPP, GPIO, Reset Sampling */
+#define ARMADA_MPP_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18000)
+#define ARMADA_GPIO0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18100)
+#define ARMADA_GPIO1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18140)
+#define ARMADA_GPIO2_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18180)
+
+/* Power Management */
+#define ARMADA_PMU_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x1c000)
+
+/* Real Time Clock */
+#define ARMADA_RTC_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x10300)
+
+/* Memory Controller */
+#define ARMADA_MC_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x20180)
+
+/* Timers */
+#define ARMADA_TIMER_VIRT_BASE		(ARMADA_CPU_VIRT_BASE | 0x0300)
+#define  ARMADA_TIMERS_INT_TIMER1_CLR	(~0x0100)
+#define TIMER_VIRT_BASE                 ARMADA_TIMER_VIRT_BASE
+
+/* Main Interrupt Controller Control and Configuration */
+#define ARMADA_MAIN_INT_CNTL_BASE  (ARMADA_CPU_VIRT_BASE | 0x0)
+
+/* Per CPU Interrupt Controller Control and Configuration */
+#define ARMADA_PER_CPU_INT_CNTL_BASE  (ARMADA_CPU_VIRT_BASE | 0x1000)
+
+#endif /* __MACH_ARMADA_H */
arch/arm/mach-armada/include/mach/bridge-regs.h new file +28 -0
new file mode 100644
index 0000000..0eaefbd
@@ -0,0 +1,28 @@
+/*
+ * Mbus-L to Mbus Bridge Registers
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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 __ASM_ARCH_BRIDGE_REGS_H
+#define __ASM_ARCH_BRIDGE_REGS_H
+
+#include <mach/armada.h>
+
+#define RSTOUTn_MASK		(ARMADA_SYSTEM_VIRT_BASE | 0x60)
+#define  SOFT_RESET_OUT_EN	0x00000001
+
+#define SYSTEM_SOFT_RESET	(ARMADA_SYSTEM_VIRT_BASE | 0x64)
+#define  SOFT_RESET		0x00000001
+
+#define SOC_ID                  (ARMADA_MISC_VIRT_BASE | 0x3C)
+
+#endif
arch/arm/mach-armada/include/mach/debug-macro.S new file +23 -0
new file mode 100644
index 0000000..1c7c52f
@@ -0,0 +1,23 @@
+/*
+ * Early serial output macro for Marvell Armada SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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/armada.h>
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =ARMADA_REGS_PHYS_BASE
+	ldr	\rv, =ARMADA_REGS_VIRT_BASE
+	orr	\rp, \rp, #0x00012000
+	orr	\rv, \rv, #0x00012000
+	.endm
+
+#define UART_SHIFT	2
+#include <asm/hardware/debug-8250.S>
arch/arm/mach-armada/include/mach/gpio.h new file +13 -0
new file mode 100644
index 0000000..e62f38a
@@ -0,0 +1,13 @@
+/*
+ * Marvell Armada SoC GPIO definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 <plat/gpio.h>
arch/arm/mach-armada/include/mach/hardware.h new file +18 -0
new file mode 100644
index 0000000..829111b
@@ -0,0 +1,18 @@
+/*
+ * Marvell Armada SoC hardware definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 __ASM_ARCH_HARDWARE_H
+#define __ASM_ARCH_HARDWARE_H
+
+#include <mach/armada.h>
+
+#endif
arch/arm/mach-armada/include/mach/io.h new file +24 -0
new file mode 100644
index 0000000..48716c1
@@ -0,0 +1,24 @@
+/*
+ * Basic I/O macros
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 __ASM_ARCH_IO_H
+#define __ASM_ARCH_IO_H
+
+#include <mach/armada.h>
+
+#define IO_SPACE_LIMIT		0xffffffff
+
+#define __io(a)		((void __iomem *)(((a) - ARMADA_PCIE0_IO_BUS_BASE) + \
+						 ARMADA_PCIE0_IO_VIRT_BASE))
+#define __mem_pci(a)	(a)
+
+#endif
arch/arm/mach-armada/include/mach/irqs.h new file +96 -0

96 lines not on this page · raw message

arch/arm/mach-armada/include/mach/system.h new file +21 -0
new file mode 100644
index 0000000..f920ef0
@@ -0,0 +1,21 @@
+/*
+ * Marvell Armada SoC system defines
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 __ASM_ARCH_SYSTEM_H
+#define __ASM_ARCH_SYSTEM_H
+
+static inline void arch_idle(void)
+{
+	cpu_do_idle();
+}
+
+#endif
arch/arm/mach-armada/include/mach/timex.h new file +13 -0
new file mode 100644
index 0000000..ab324a3
@@ -0,0 +1,13 @@
+/*
+ * Marvell Armada SoC time definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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)
arch/arm/mach-armada/include/mach/uncompress.h new file +41 -0

41 lines not on this page · raw message

Signature · 1 line
1.7.9.5
#2 lore raw

PATCH 1/8 arm: mach-armada: add headers

Quoted 247 lines · Thomas Petazzoni

From: Gregory CLEMENT <[email protected]>

This patch adds basic header files for Armada SoCs.

---
 arch/arm/mach-armada/include/mach/armada.h      |  234 +++++++++++++++++++++++
 arch/arm/mach-armada/include/mach/bridge-regs.h |   28 +++
 arch/arm/mach-armada/include/mach/debug-macro.S |   23 +++
 arch/arm/mach-armada/include/mach/gpio.h        |   13 ++
 arch/arm/mach-armada/include/mach/hardware.h    |   18 ++
 arch/arm/mach-armada/include/mach/io.h          |   24 +++
 arch/arm/mach-armada/include/mach/irqs.h        |   96 ++++++++++
 arch/arm/mach-armada/include/mach/system.h      |   21 ++
 arch/arm/mach-armada/include/mach/timex.h       |   13 ++
 arch/arm/mach-armada/include/mach/uncompress.h  |   41 ++++
 10 files changed, 511 insertions(+)
 create mode 100644 arch/arm/mach-armada/include/mach/armada.h
 create mode 100644 arch/arm/mach-armada/include/mach/bridge-regs.h
 create mode 100644 arch/arm/mach-armada/include/mach/debug-macro.S
 create mode 100644 arch/arm/mach-armada/include/mach/gpio.h
 create mode 100644 arch/arm/mach-armada/include/mach/hardware.h
 create mode 100644 arch/arm/mach-armada/include/mach/io.h
 create mode 100644 arch/arm/mach-armada/include/mach/irqs.h
 create mode 100644 arch/arm/mach-armada/include/mach/system.h
 create mode 100644 arch/arm/mach-armada/include/mach/timex.h
 create mode 100644 arch/arm/mach-armada/include/mach/uncompress.h
arch/arm/mach-armada/include/mach/armada.h new file +211 -0
new file mode 100644
index 0000000..be12667
@@ -0,0 +1,234 @@
+/*
+ * Generic definitions for Marvell Armada SoCs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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_H
+#define __MACH_ARMADA_H
+
+/*
+ * Marvell ARMADA address maps.
+ *
+ * phys		virt		size
+ * d0000000	feb00000	1M	internal registers
+ * d0100000	@runtime	1M	uart
+ * d0200000	fec00000	1M	PCIe-0 I/O (port 0.0)
+ * d0300000	fed00000	1M	PCIe-1 I/O (port 1.0)
+ * d0400000	fee00000	1M	PCIe-2 I/O (port 2.0)
+ * d0500000	fef00000	1M	PCIe-3 I/O (port 3.0)
+ * d0600000	@runtime	1M	cryptographic sram-0
+ * d0700000	@runtime	1M	cryptographic sram-1
+ * d0800000	reserved	8M	reserved for future
+ * d1000000	@runtime	16M	device bus cs-0
+ * d2000000	@runtime	16M	device bus cs-0
+ * d3000000	@runtime	16M	device bus cs-0
+ * d4000000	@runtime	16M	device bus cs-0
+ * d5000000	@runtime	16M	device bus boot cs
+ * d6000000	@runtime	16M	spi-0 flash
+ * d7000000	@runtime	16M	spi-1 flash
+ * d8000000	@runtime	64M	PCIe-0 Memory (port 0.0)
+ * dc000000	@runtime	64M	PCIe-1 Memory (port 1.0)
+ * e0000000	@runtime	64M	PCIe-2 Memory (port 2.0)
+ * e4000000	@runtime	64M	PCIe-3 Memory (port 3.0)
+ * fff00000	@runtime	1M	internal bootrom
+ */
+
+#define ARMADA_REGS_PHYS_BASE		0xd0000000
+#define ARMADA_REGS_VIRT_BASE		0xfeb00000
+#define ARMADA_REGS_SIZE		SZ_1M
+
+#define ARMADA_UART_REGS_BASE		0xd0100000
+#define ARMADA_UART_SIZE		_1M
+
+#define ARMADA_PCIE0_IO_PHYS_BASE	0xd0200000
+#define ARMADA_PCIE0_IO_VIRT_BASE	0xfec00000
+#define ARMADA_PCIE0_IO_BUS_BASE	0x00100000
+#define ARMADA_PCIE0_IO_SIZE		SZ_1M
+
+#define ARMADA_PCIE1_IO_PHYS_BASE	0xd0300000
+#define ARMADA_PCIE1_IO_VIRT_BASE	0xfed00000
+#define ARMADA_PCIE1_IO_BUS_BASE	0x00200000
+#define ARMADA_PCIE1_IO_SIZE		SZ_1M
+
+#define ARMADA_PCIE2_IO_PHYS_BASE	0xd0400000
+#define ARMADA_PCIE2_IO_VIRT_BASE	0xfee00000
+#define ARMADA_PCIE2_IO_BUS_BASE	0x00300000
+#define ARMADA_PCIE2_IO_SIZE		SZ_1M
+
+#define ARMADA_PCIE3_IO_PHYS_BASE	0xd0500000
+#define ARMADA_PCIE3_IO_VIRT_BASE	0xfef00000
+#define ARMADA_PCIE3_IO_BUS_BASE	0x00400000
+#define ARMADA_PCIE3_IO_SIZE		SZ_1M
+
+#define ARMADA_CESA0_PHYS_BASE		0xd0600000
+#define ARMADA_CESA0_SIZE		SZ_1M
+
+#define ARMADA_CESA1_PHYS_BASE		0xd0700000
+#define ARMADA_CESA1_SIZE		SZ_1M
+
+#define ARMADA_DEVICE_CS0_PHYS_BASE	0xd1000000
+#define ARMADA_DEVICE_CS0_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_CS1_PHYS_BASE	0xd2000000
+#define ARMADA_DEVICE_CS1_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_CS2_PHYS_BASE	0xd3000000
+#define ARMADA_DEVICE_CS2_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_CS3_PHYS_BASE	0xd4000000
+#define ARMADA_DEVICE_CS3_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_BOOT_CS_PHYS_BASE	0xd5000000
+#define ARMADA_DEVICE_BOOT_CS_SIZE	SZ_16M
+
+#define ARMADA_SPI0_CS0_PHYS_BASE	0xd6000000
+#define ARMADA_SPI0_CS0_SIZE		SZ_16M
+
+#define ARMADA_SPI1_CS0_PHYS_BASE	0xd7000000
+#define ARMADA_SPI1_CS0_SIZE		SZ_16M
+
+#define ARMADA_PCIE0_MEM_PHYS_BASE	0xd8000000
+#define ARMADA_PCIE0_MEM_SIZE		SZ_64M
+
+#define ARMADA_PCIE1_MEM_PHYS_BASE	0xdc000000
+#define ARMADA_PCIE1_MEM_SIZE		SZ_64M
+
+#define ARMADA_PCIE2_MEM_PHYS_BASE	0xe0000000
+#define ARMADA_PCIE2_MEM_SIZE		SZ_64M
+
+#define ARMADA_PCIE3_MEM_PHYS_BASE	0xe4000000
+#define ARMADA_PCIE3_MEM_SIZE		SZ_64M
+
+#define ARMADA_BOOTROM_PHYS_BASE	0xFFF00000
+#define ARMADA_BOOTROM_SIZE		SZ_1M
+
+/*
+ * Core Registers Map
+ */
+
+/* DRAM */
+#define ARMADA_DRAM_PHYS_BASE     (ARMADA_REGS_PHYS_BASE | 0x0)
+#define ARMADA_DRAM_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x0)
+
+/* L2 Cache */
+#define ARMADA_L2_CACHE_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x8000)
+#define ARMADA_L2_CACHE_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x8000)
+
+/* RTC */
+#define ARMADA_RTC_PHYS_BASE      (ARMADA_REGS_PHYS_BASE | 0x10300)
+#define ARMADA_RTC_VIRT_BASE      (ARMADA_REGS_VIRT_BASE | 0x10300)
+
+/* SPI */
+#define ARMADA_SPI0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x10600)
+#define ARMADA_SPI0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x10600)
+#define ARMADA_SPI1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x10680)
+#define ARMADA_SPI1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x10680)
+
+/* I2C */
+#define ARMADA_I2C0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x11000)
+#define ARMADA_I2C0_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x11000)
+#define ARMADA_I2C1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x11100)
+#define ARMADA_I2C1_VIRT_BASE	(ARMADA_REGS_PHYS_BASE | 0x11100)
+
+/* UART */
+#define ARMADA_UART0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x12000)
+#define ARMADA_UART0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x12000)
+#define ARMADA_UART1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x12100)
+#define ARMADA_UART1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x12100)
+
+/* MPP (pin muxing) */
+#define ARMADA_MPP_PHYS_BASE      (ARMADA_REGS_PHYS_BASE | 0x18000)
+#define ARMADA_MPP_VIRT_BASE      (ARMADA_REGS_VIRT_BASE | 0x18000)
+
+/* GPIO */
+#define ARMADA_GPIO_PHYS_BASE     (ARMADA_REGS_PHYS_BASE | 0x18100)
+#define ARMADA_GPIO_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x18100)
+
+/* Misc registers */
+#define ARMADA_SYSTEM_PHYS_BASE     (ARMADA_REGS_PHYS_BASE | 0x18200)
+#define ARMADA_SYSTEM_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x18200)
+
+/* CPU */
+#define ARMADA_CPU_PHYS_BASE      (ARMADA_REGS_PHYS_BASE | 0x20000)
+#define ARMADA_CPU_VIRT_BASE      (ARMADA_REGS_VIRT_BASE | 0x20000)
+
+/* Audio */
+#define ARMADA_AUDIO_PHYS_BASE    (ARMADA_REGS_PHYS_BASE | 0x30000)
+#define ARMADA_AUDIO_VIRT_BASE    (ARMADA_REGS_VIRT_BASE | 0x30000)
+
+/* PCIe */
+#define ARMADA_PCIE0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x40000)
+#define ARMADA_PCIE0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x40000)
+#define ARMADA_PCIE1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x80000)
+#define ARMADA_PCIE1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x80000)
+#define ARMADA_PCIE2_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x42000)
+#define ARMADA_PCIE2_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x42000)
+#define ARMADA_PCIE3_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x82000)
+#define ARMADA_PCIE3_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x82000)
+
+/* USB */
+#define ARMADA_USB0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x50000)
+#define ARMADA_USB0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x50000)
+#define ARMADA_USB1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x51000)
+#define ARMADA_USB1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x51000)
+
+/* XOR Engines */
+#define ARMADA_XOR0_PHYS_BASE        (ARMADA_REGS_PHYS_BASE | 0x60900)
+#define ARMADA_XOR0_HIGH_PHYS_BASE   (ARMADA_REGS_PHYS_BASE | 0x60B00)
+#define ARMADA_XOR1_PHYS_BASE        (ARMADA_REGS_PHYS_BASE | 0xF0900)
+#define ARMADA_XOR1_HIGH_PHYS_BASE   (ARMADA_REGS_PHYS_BASE | 0xF0B00)
+
+/* Cryptographic Engine */
+#define ARMADA_CRYPT_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x30000)
+
+/* Gigabit Ethernet */
+#define ARMADA_GE00_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x70000)
+#define ARMADA_GE01_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x74000)
+#define ARMADA_GE10_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x30000)
+#define ARMADA_GE11_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x34000)
+
+/* SDIO */
+#define ARMADA_SDIO0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x92000)
+
+/* SATA */
+#define ARMADA_SATA_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0xa0000)
+
+/* NAND Flash Controller */
+#define ARMADA_NFC_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0xd0000)
+
+/* MPP, GPIO, Reset Sampling */
+#define ARMADA_MPP_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18000)
+#define ARMADA_GPIO0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18100)
+#define ARMADA_GPIO1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18140)

arch/arm/mach-armada/include/mach/armada.h line 221

Quoted 10 lines
arch/arm/mach-armada/include/mach/armada.h new file +10 -0
+#define ARMADA_GPIO2_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18180)
+
+/* Power Management */
+#define ARMADA_PMU_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x1c000)
+
+/* Real Time Clock */
+#define ARMADA_RTC_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x10300)
+
+/* Memory Controller */
+#define ARMADA_MC_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x20180)

I would just delete most of these, either they'll come from the fdt or they won't be needed. There's far more here than is necessary to get the core up and my view is that these should be removed.

Quoted 49 lines
arch/arm/mach-armada/include/mach/bridge-regs.h new file +28 -0
new file mode 100644
index 0000000..0eaefbd
@@ -0,0 +1,28 @@
+/*
+ * Mbus-L to Mbus Bridge Registers
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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 __ASM_ARCH_BRIDGE_REGS_H
+#define __ASM_ARCH_BRIDGE_REGS_H
+
+#include <mach/armada.h>
+
+#define RSTOUTn_MASK		(ARMADA_SYSTEM_VIRT_BASE | 0x60)
+#define  SOFT_RESET_OUT_EN	0x00000001
+
+#define SYSTEM_SOFT_RESET	(ARMADA_SYSTEM_VIRT_BASE | 0x64)
+#define  SOFT_RESET		0x00000001
+
+#define SOC_ID                  (ARMADA_MISC_VIRT_BASE | 0x3C)
+
+#endif
arch/arm/mach-armada/include/mach/debug-macro.S new file +9 -0
new file mode 100644
index 0000000..1c7c52f
@@ -0,0 +1,23 @@
+/*
+ * Early serial output macro for Marvell Armada SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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

arch/arm/mach-armada/include/mach/debug-macro.S line 19

Quoted 10 lines
arch/arm/mach-armada/include/mach/debug-macro.S new file +10 -0
+ * published by the Free Software Foundation.
+*/
+
+#include <mach/armada.h>
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =ARMADA_REGS_PHYS_BASE
+	ldr	\rv, =ARMADA_REGS_VIRT_BASE
+	orr	\rp, \rp, #0x00012000
+	orr	\rv, \rv, #0x00012000

you could do \rp, =(ARMADA_REGS_PHYS_BASE | 0x00012000) and remove the second orr.

Quoted 37 lines
arch/arm/mach-armada/include/mach/debug-macro.S new file +4 -0
+	.endm
+
+#define UART_SHIFT	2
+#include <asm/hardware/debug-8250.S>
arch/arm/mach-armada/include/mach/gpio.h new file +13 -0
new file mode 100644
index 0000000..e62f38a
@@ -0,0 +1,13 @@
+/*
+ * Marvell Armada SoC GPIO definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 <plat/gpio.h>
arch/arm/mach-armada/include/mach/hardware.h new file +8 -0
new file mode 100644
index 0000000..829111b
@@ -0,0 +1,18 @@
+/*
+ * Marvell Armada SoC hardware definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * This file is licensed under the terms of the GNU General Public

arch/arm/mach-armada/include/mach/hardware.h line 18

Quoted 10 lines
arch/arm/mach-armada/include/mach/hardware.h new file +10 -0
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __ASM_ARCH_HARDWARE_H
+#define __ASM_ARCH_HARDWARE_H
+
+#include <mach/armada.h>
+
+#endif

thought this was going away.

Quoted 122 lines
arch/arm/mach-armada/include/mach/io.h new file +24 -0
new file mode 100644
index 0000000..48716c1
@@ -0,0 +1,24 @@
+/*
+ * Basic I/O macros
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 __ASM_ARCH_IO_H
+#define __ASM_ARCH_IO_H
+
+#include <mach/armada.h>
+
+#define IO_SPACE_LIMIT		0xffffffff
+
+#define __io(a)		((void __iomem *)(((a) - ARMADA_PCIE0_IO_BUS_BASE) + \
+						 ARMADA_PCIE0_IO_VIRT_BASE))
+#define __mem_pci(a)	(a)
+
+#endif
arch/arm/mach-armada/include/mach/irqs.h new file +86 -0
new file mode 100644
index 0000000..48844a4
@@ -0,0 +1,96 @@
+/*
+ * IRQ definitions for Marvell Armada SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 __ASM_ARCH_IRQS_H
+#define __ASM_ARCH_IRQS_H
+
+/*
+ * Per-cpu Interrupts
+ */
+#define IRQ_ARMADA_DRBL_LOW	0
+#define IRQ_ARMADA_DRBL_HI	1
+#define IRQ_ARMADA_DRBL_SUM	2
+#define IRQ_ARMADA_FABRIC	3
+#define IRQ_ARMADA_SOC_ERR	4
+#define IRQ_ARMADA_LCL_TIMER0	5
+#define IRQ_ARMADA_LCL_TIMER1	6
+#define IRQ_ARMADA_LCL_WD	7
+#define IRQ_ARMADA_GE0_TH_RXTX	8
+#define IRQ_ARMADA_GE0_RXTX	9
+#define IRQ_ARMADA_GE1_TH_RXTX	10
+#define IRQ_ARMADA_GE1_RXTX	11
+#define IRQ_ARMADA_GE2_TH_RXTX	12
+#define IRQ_ARMADA_GE2_RXTX	13
+#define IRQ_ARMADA_GE3_TH_RXTX	14
+#define IRQ_ARMADA_GE3_RXTX	15
+
+/*
+ * Global interrupts
+ */
+#define IRQ_ARMADA_LCD		29
+#define IRQ_ARMADA_SPI0		30
+#define IRQ_ARMADA_I2C0		31
+#define IRQ_ARMADA_I2C1		32
+#define IRQ_ARMADA_GLBL_TIMER0	37
+#define IRQ_ARMADA_GLBL_TIMER1	38
+#define IRQ_ARMADA_GLBL_TIMER2	39
+#define IRQ_ARMADA_GLBL_TIMER3	40
+#define IRQ_ARMADA_UART0	41
+#define IRQ_ARMADA_UART1	42
+#define IRQ_ARMADA_UART2	43
+#define IRQ_ARMADA_UART3	44
+#define IRQ_ARMADA_USB0		45
+#define IRQ_ARMADA_USB1		46
+#define IRQ_ARMADA_USB2		47
+#define IRQ_ARMADA_CESA0	48
+#define IRQ_ARMADA_CESA1	49
+#define IRQ_ARMADA_RTC		50
+#define IRQ_ARMADA_XOR0_CH0	51
+#define IRQ_ARMADA_XOR0_CH1	52
+#define IRQ_ARMADA_SDIO		54
+#define IRQ_ARMADA_SATA0	55
+#define IRQ_ARMADA_TDM		56
+#define IRQ_ARMADA_SATA1	57
+#define IRQ_ARMADA_PCIE0	61
+#define IRQ_ARMADA_PCIE1	62
+#define IRQ_ARMADA_GPIO_0_7	82
+#define IRQ_ARMADA_GPIO_8_15	83
+#define IRQ_ARMADA_GPIO_16_23	84
+#define IRQ_ARMADA_GPIO_24_31	85
+#define IRQ_ARMADA_GPIO_32_39	87
+#define IRQ_ARMADA_GPIO_40_47	88
+#define IRQ_ARMADA_GPIO_48_55	89
+#define IRQ_ARMADA_GPIO_56_63	90
+#define IRQ_ARMADA_GPIO_64_66	91
+#define IRQ_ARMADA_SPI1		92
+#define IRQ_ARMADA_WD		93
+#define IRQ_ARMADA_XOR1_CH0	94
+#define IRQ_ARMADA_XOR1_CH1	95
+#define IRQ_ARMADA_PCIE2	99
+#define IRQ_ARMADA_PCIE3	103
+#define IRQ_ARMADA_DRAM		108
+#define IRQ_ARMADA_GE0_WKUP	109
+#define IRQ_ARMADA_GE1_WKUP	110
+#define IRQ_ARMADA_GE2_WKUP	111
+#define IRQ_ARMADA_GE3_WKUP	112
+#define IRQ_ARMADA_NFC		113
+

arch/arm/mach-armada/include/mach/irqs.h line 96

Quoted 10 lines
arch/arm/mach-armada/include/mach/irqs.h new file +10 -0
+/*
+ * ARMADA General Purpose Pins
+ */
+#define IRQ_ARMADA_GPIO_START	82
+#define NR_GPIO_IRQS		64
+
+#define NR_IRQS			(115)
+
+
+#endif

I'm going to go with the same comment as before, why do we have all these defines sitting here when I expect they'll never be used.

arch/arm/mach-armad

Quoted 1 line
arch/arm/mach-armad renamed from arch/arm/mach-armada/include/mach/system.h +0 -0

a/include/mach/system.h

Quoted 57 lines

new file mode 100644
index 0000000..f920ef0

arch/arm/mach-armada/include/mach/system.h new file +21 -0
@@ -0,0 +1,21 @@
+/*
+ * Marvell Armada SoC system defines
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 __ASM_ARCH_SYSTEM_H
+#define __ASM_ARCH_SYSTEM_H
+
+static inline void arch_idle(void)
+{
+	cpu_do_idle();
+}
+
+#endif
arch/arm/mach-armada/include/mach/timex.h new file +13 -0
new file mode 100644
index 0000000..ab324a3
@@ -0,0 +1,13 @@
+/*
+ * Marvell Armada SoC time definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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)
arch/arm/mach-armada/include/mach/uncompress.h new file +6 -0
new file mode 100644
index 0000000..611ebf3
@@ -0,0 +1,41 @@
+/*
+ * Marvell Armada SoC kernel uncompression UART routines
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>

arch/arm/mach-armada/include/mach/uncompress.h line 16

Quoted 10 lines
arch/arm/mach-armada/include/mach/uncompress.h new file +10 -0
+ *
+ * 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/armada.h>
+
+#define UART_THR ((volatile unsigned char *)(ARMADA_UART0_PHYS_BASE + 0x0))
+#define UART_LSR ((volatile unsigned char *)(ARMADA_UART0_PHYS_BASE + 0x14))

you've used a different set of addresses for your debug-macro.S

arch/arm/mach-armada/include/mach/uncompress.h line 18

Quoted 1 line
arch/arm/mach-armada/include/mach/uncompress.h new file +1 -0
+#define LSR_THRE	0x20

you could pull the <linux/serial_regs.h> in for these.

arch/arm/mach-armada/include/mach/uncompress.h line 28

Quoted 10 lines
arch/arm/mach-armada/include/mach/uncompress.h new file +10 -0
+
+static void putc(const char c)
+{
+	int i;
+
+	for (i = 0; i < 0x1000; i++) {
+		/* Transmit fifo not full? */
+		if (*UART_LSR & LSR_THRE)
+			break;
+	}

is that really long enough to wait for a fast core like the AXP?

Quoted 16 lines
arch/arm/mach-armada/include/mach/uncompress.h new file +13 -0
+
+	*UART_THR = c;
+}
+
+static void flush(void)
+{
+}
+
+/*
+ * nothing to do
+ */
+#define arch_decomp_setup()
+#define arch_decomp_wdog()
Signature · 1 line
1.7.9.5
Signature · 3 lines
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.
#3 lore raw

PATCH 1/8 arm: mach-armada: add headers

Quoted 72 lines · Ben Dooks
Quoted 71 lines · Thomas Petazzoni

From: Gregory CLEMENT<[email protected]>

This patch adds basic header files for Armada SoCs.

---
  arch/arm/mach-armada/include/mach/armada.h      |  234 +++++++++++++++++++++++
  arch/arm/mach-armada/include/mach/bridge-regs.h |   28 +++
  arch/arm/mach-armada/include/mach/debug-macro.S |   23 +++
  arch/arm/mach-armada/include/mach/gpio.h        |   13 ++
  arch/arm/mach-armada/include/mach/hardware.h    |   18 ++
  arch/arm/mach-armada/include/mach/io.h          |   24 +++
  arch/arm/mach-armada/include/mach/irqs.h        |   96 ++++++++++
  arch/arm/mach-armada/include/mach/system.h      |   21 ++
  arch/arm/mach-armada/include/mach/timex.h       |   13 ++
  arch/arm/mach-armada/include/mach/uncompress.h  |   41 ++++
  10 files changed, 511 insertions(+)

create mode 100644 arch/arm/mach-armada/include/mach/armada.h create mode 100644 arch/arm/mach-armada/include/mach/bridge-regs.h create mode 100644 arch/arm/mach-armada/include/mach/debug-macro.S create mode 100644 arch/arm/mach-armada/include/mach/gpio.h create mode 100644 arch/arm/mach-armada/include/mach/hardware.h create mode 100644 arch/arm/mach-armada/include/mach/io.h create mode 100644 arch/arm/mach-armada/include/mach/irqs.h create mode 100644 arch/arm/mach-armada/include/mach/system.h create mode 100644 arch/arm/mach-armada/include/mach/timex.h create mode 100644 arch/arm/mach-armada/include/mach/uncompress.h

arch/arm/mach-armada/include/mach/armada.h new file +35 -0
new file mode 100644
index 0000000..be12667
@@ -0,0 +1,234 @@
+/*
+ * Generic definitions for Marvell Armada SoCs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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_H
+#define __MACH_ARMADA_H
+
+/*
+ * Marvell ARMADA address maps.
+ *
+ * phys		virt		size
+ * d0000000	feb00000	1M	internal registers
+ * d0100000	@runtime	1M	uart
+ * d0200000	fec00000	1M	PCIe-0 I/O (port 0.0)
+ * d0300000	fed00000	1M	PCIe-1 I/O (port 1.0)
+ * d0400000	fee00000	1M	PCIe-2 I/O (port 2.0)
+ * d0500000	fef00000	1M	PCIe-3 I/O (port 3.0)
+ * d0600000	@runtime	1M	cryptographic sram-0
+ * d0700000	@runtime	1M	cryptographic sram-1
+ * d0800000	reserved	8M	reserved for future
+ * d1000000	@runtime	16M	device bus cs-0
+ * d2000000	@runtime	16M	device bus cs-0
+ * d3000000	@runtime	16M	device bus cs-0
+ * d4000000	@runtime	16M	device bus cs-0
+ * d5000000	@runtime	16M	device bus boot cs
Quoted 8 lines

arch/arm/mach-armada/include/mach/armada.h line 43

Quoted 8 lines
arch/arm/mach-armada/include/mach/armada.h new file +8 -0
+ * d6000000	@runtime	16M	spi-0 flash
+ * d7000000	@runtime	16M	spi-1 flash
+ * d8000000	@runtime	64M	PCIe-0 Memory (port 0.0)
+ * dc000000	@runtime	64M	PCIe-1 Memory (port 1.0)
+ * e0000000	@runtime	64M	PCIe-2 Memory (port 2.0)
+ * e4000000	@runtime	64M	PCIe-3 Memory (port 3.0)
+ * fff00000	@runtime	1M	internal bootrom
+ */

I think these mappings are mostly un-necessary at initialisation time and secondly the support merged so far does not need most of these. I would say that the PCIe and SPI should be dynamically mapped when they are instantiated from the device tree.

Second comment, why do we have two sets of UART mappings, one from the internal registers and the second from its own phys space?

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#4 lore raw

PATCH 1/8 arm: mach-armada: add headers

In reply to Thomas Petazzoni
Quoted 3 lines · Thomas Petazzoni

From: Gregory CLEMENT <[email protected]>

This patch adds basic header files for Armada SoCs.

The split of patch 1 and 2 doesn't really make sense.

Quoted 256 lines
---
 arch/arm/mach-armada/include/mach/armada.h      |  234 +++++++++++++++++++++++
 arch/arm/mach-armada/include/mach/bridge-regs.h |   28 +++
 arch/arm/mach-armada/include/mach/debug-macro.S |   23 +++
 arch/arm/mach-armada/include/mach/gpio.h        |   13 ++
 arch/arm/mach-armada/include/mach/hardware.h    |   18 ++
 arch/arm/mach-armada/include/mach/io.h          |   24 +++
 arch/arm/mach-armada/include/mach/irqs.h        |   96 ++++++++++
 arch/arm/mach-armada/include/mach/system.h      |   21 ++
 arch/arm/mach-armada/include/mach/timex.h       |   13 ++
 arch/arm/mach-armada/include/mach/uncompress.h  |   41 ++++
 10 files changed, 511 insertions(+)
 create mode 100644 arch/arm/mach-armada/include/mach/armada.h
 create mode 100644 arch/arm/mach-armada/include/mach/bridge-regs.h
 create mode 100644 arch/arm/mach-armada/include/mach/debug-macro.S
 create mode 100644 arch/arm/mach-armada/include/mach/gpio.h
 create mode 100644 arch/arm/mach-armada/include/mach/hardware.h
 create mode 100644 arch/arm/mach-armada/include/mach/io.h
 create mode 100644 arch/arm/mach-armada/include/mach/irqs.h
 create mode 100644 arch/arm/mach-armada/include/mach/system.h
 create mode 100644 arch/arm/mach-armada/include/mach/timex.h
 create mode 100644 arch/arm/mach-armada/include/mach/uncompress.h
arch/arm/mach-armada/include/mach/armada.h new file +223 -0
new file mode 100644
index 0000000..be12667
@@ -0,0 +1,234 @@
+/*
+ * Generic definitions for Marvell Armada SoCs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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_H
+#define __MACH_ARMADA_H
+
+/*
+ * Marvell ARMADA address maps.
+ *
+ * phys		virt		size
+ * d0000000	feb00000	1M	internal registers
+ * d0100000	@runtime	1M	uart
+ * d0200000	fec00000	1M	PCIe-0 I/O (port 0.0)
+ * d0300000	fed00000	1M	PCIe-1 I/O (port 1.0)
+ * d0400000	fee00000	1M	PCIe-2 I/O (port 2.0)
+ * d0500000	fef00000	1M	PCIe-3 I/O (port 3.0)
+ * d0600000	@runtime	1M	cryptographic sram-0
+ * d0700000	@runtime	1M	cryptographic sram-1
+ * d0800000	reserved	8M	reserved for future
+ * d1000000	@runtime	16M	device bus cs-0
+ * d2000000	@runtime	16M	device bus cs-0
+ * d3000000	@runtime	16M	device bus cs-0
+ * d4000000	@runtime	16M	device bus cs-0
+ * d5000000	@runtime	16M	device bus boot cs
+ * d6000000	@runtime	16M	spi-0 flash
+ * d7000000	@runtime	16M	spi-1 flash
+ * d8000000	@runtime	64M	PCIe-0 Memory (port 0.0)
+ * dc000000	@runtime	64M	PCIe-1 Memory (port 1.0)
+ * e0000000	@runtime	64M	PCIe-2 Memory (port 2.0)
+ * e4000000	@runtime	64M	PCIe-3 Memory (port 3.0)
+ * fff00000	@runtime	1M	internal bootrom
+ */
+
+#define ARMADA_REGS_PHYS_BASE		0xd0000000
+#define ARMADA_REGS_VIRT_BASE		0xfeb00000
+#define ARMADA_REGS_SIZE		SZ_1M
+
+#define ARMADA_UART_REGS_BASE		0xd0100000
+#define ARMADA_UART_SIZE		_1M
+
+#define ARMADA_PCIE0_IO_PHYS_BASE	0xd0200000
+#define ARMADA_PCIE0_IO_VIRT_BASE	0xfec00000
+#define ARMADA_PCIE0_IO_BUS_BASE	0x00100000
+#define ARMADA_PCIE0_IO_SIZE		SZ_1M
+
+#define ARMADA_PCIE1_IO_PHYS_BASE	0xd0300000
+#define ARMADA_PCIE1_IO_VIRT_BASE	0xfed00000
+#define ARMADA_PCIE1_IO_BUS_BASE	0x00200000
+#define ARMADA_PCIE1_IO_SIZE		SZ_1M
+
+#define ARMADA_PCIE2_IO_PHYS_BASE	0xd0400000
+#define ARMADA_PCIE2_IO_VIRT_BASE	0xfee00000
+#define ARMADA_PCIE2_IO_BUS_BASE	0x00300000
+#define ARMADA_PCIE2_IO_SIZE		SZ_1M
+
+#define ARMADA_PCIE3_IO_PHYS_BASE	0xd0500000
+#define ARMADA_PCIE3_IO_VIRT_BASE	0xfef00000
+#define ARMADA_PCIE3_IO_BUS_BASE	0x00400000
+#define ARMADA_PCIE3_IO_SIZE		SZ_1M
+
+#define ARMADA_CESA0_PHYS_BASE		0xd0600000
+#define ARMADA_CESA0_SIZE		SZ_1M
+
+#define ARMADA_CESA1_PHYS_BASE		0xd0700000
+#define ARMADA_CESA1_SIZE		SZ_1M
+
+#define ARMADA_DEVICE_CS0_PHYS_BASE	0xd1000000
+#define ARMADA_DEVICE_CS0_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_CS1_PHYS_BASE	0xd2000000
+#define ARMADA_DEVICE_CS1_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_CS2_PHYS_BASE	0xd3000000
+#define ARMADA_DEVICE_CS2_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_CS3_PHYS_BASE	0xd4000000
+#define ARMADA_DEVICE_CS3_SIZE		SZ_16M
+
+#define ARMADA_DEVICE_BOOT_CS_PHYS_BASE	0xd5000000
+#define ARMADA_DEVICE_BOOT_CS_SIZE	SZ_16M
+
+#define ARMADA_SPI0_CS0_PHYS_BASE	0xd6000000
+#define ARMADA_SPI0_CS0_SIZE		SZ_16M
+
+#define ARMADA_SPI1_CS0_PHYS_BASE	0xd7000000
+#define ARMADA_SPI1_CS0_SIZE		SZ_16M
+
+#define ARMADA_PCIE0_MEM_PHYS_BASE	0xd8000000
+#define ARMADA_PCIE0_MEM_SIZE		SZ_64M
+
+#define ARMADA_PCIE1_MEM_PHYS_BASE	0xdc000000
+#define ARMADA_PCIE1_MEM_SIZE		SZ_64M
+
+#define ARMADA_PCIE2_MEM_PHYS_BASE	0xe0000000
+#define ARMADA_PCIE2_MEM_SIZE		SZ_64M
+
+#define ARMADA_PCIE3_MEM_PHYS_BASE	0xe4000000
+#define ARMADA_PCIE3_MEM_SIZE		SZ_64M
+
+#define ARMADA_BOOTROM_PHYS_BASE	0xFFF00000
+#define ARMADA_BOOTROM_SIZE		SZ_1M
+
+/*
+ * Core Registers Map
+ */
+
+/* DRAM */
+#define ARMADA_DRAM_PHYS_BASE     (ARMADA_REGS_PHYS_BASE | 0x0)
+#define ARMADA_DRAM_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x0)
+
+/* L2 Cache */
+#define ARMADA_L2_CACHE_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x8000)
+#define ARMADA_L2_CACHE_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x8000)
+
+/* RTC */
+#define ARMADA_RTC_PHYS_BASE      (ARMADA_REGS_PHYS_BASE | 0x10300)
+#define ARMADA_RTC_VIRT_BASE      (ARMADA_REGS_VIRT_BASE | 0x10300)
+
+/* SPI */
+#define ARMADA_SPI0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x10600)
+#define ARMADA_SPI0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x10600)
+#define ARMADA_SPI1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x10680)
+#define ARMADA_SPI1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x10680)
+
+/* I2C */
+#define ARMADA_I2C0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x11000)
+#define ARMADA_I2C0_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x11000)
+#define ARMADA_I2C1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x11100)
+#define ARMADA_I2C1_VIRT_BASE	(ARMADA_REGS_PHYS_BASE | 0x11100)
+
+/* UART */
+#define ARMADA_UART0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x12000)
+#define ARMADA_UART0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x12000)
+#define ARMADA_UART1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x12100)
+#define ARMADA_UART1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x12100)
+
+/* MPP (pin muxing) */
+#define ARMADA_MPP_PHYS_BASE      (ARMADA_REGS_PHYS_BASE | 0x18000)
+#define ARMADA_MPP_VIRT_BASE      (ARMADA_REGS_VIRT_BASE | 0x18000)
+
+/* GPIO */
+#define ARMADA_GPIO_PHYS_BASE     (ARMADA_REGS_PHYS_BASE | 0x18100)
+#define ARMADA_GPIO_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x18100)
+
+/* Misc registers */
+#define ARMADA_SYSTEM_PHYS_BASE     (ARMADA_REGS_PHYS_BASE | 0x18200)
+#define ARMADA_SYSTEM_VIRT_BASE     (ARMADA_REGS_VIRT_BASE | 0x18200)
+
+/* CPU */
+#define ARMADA_CPU_PHYS_BASE      (ARMADA_REGS_PHYS_BASE | 0x20000)
+#define ARMADA_CPU_VIRT_BASE      (ARMADA_REGS_VIRT_BASE | 0x20000)
+
+/* Audio */
+#define ARMADA_AUDIO_PHYS_BASE    (ARMADA_REGS_PHYS_BASE | 0x30000)
+#define ARMADA_AUDIO_VIRT_BASE    (ARMADA_REGS_VIRT_BASE | 0x30000)
+
+/* PCIe */
+#define ARMADA_PCIE0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x40000)
+#define ARMADA_PCIE0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x40000)
+#define ARMADA_PCIE1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x80000)
+#define ARMADA_PCIE1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x80000)
+#define ARMADA_PCIE2_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x42000)
+#define ARMADA_PCIE2_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x42000)
+#define ARMADA_PCIE3_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x82000)
+#define ARMADA_PCIE3_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x82000)
+
+/* USB */
+#define ARMADA_USB0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x50000)
+#define ARMADA_USB0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x50000)
+#define ARMADA_USB1_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x51000)
+#define ARMADA_USB1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x51000)
+
+/* XOR Engines */
+#define ARMADA_XOR0_PHYS_BASE        (ARMADA_REGS_PHYS_BASE | 0x60900)
+#define ARMADA_XOR0_HIGH_PHYS_BASE   (ARMADA_REGS_PHYS_BASE | 0x60B00)
+#define ARMADA_XOR1_PHYS_BASE        (ARMADA_REGS_PHYS_BASE | 0xF0900)
+#define ARMADA_XOR1_HIGH_PHYS_BASE   (ARMADA_REGS_PHYS_BASE | 0xF0B00)
+
+/* Cryptographic Engine */
+#define ARMADA_CRYPT_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x30000)
+
+/* Gigabit Ethernet */
+#define ARMADA_GE00_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x70000)
+#define ARMADA_GE01_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x74000)
+#define ARMADA_GE10_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x30000)
+#define ARMADA_GE11_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x34000)
+
+/* SDIO */
+#define ARMADA_SDIO0_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x92000)
+
+/* SATA */
+#define ARMADA_SATA_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0xa0000)
+
+/* NAND Flash Controller */
+#define ARMADA_NFC_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0xd0000)
+
+/* MPP, GPIO, Reset Sampling */
+#define ARMADA_MPP_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18000)
+#define ARMADA_GPIO0_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18100)
+#define ARMADA_GPIO1_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18140)
+#define ARMADA_GPIO2_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x18180)
+
+/* Power Management */
+#define ARMADA_PMU_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x1c000)
+
+/* Real Time Clock */
+#define ARMADA_RTC_PHYS_BASE	(ARMADA_REGS_PHYS_BASE | 0x10300)
+
+/* Memory Controller */
+#define ARMADA_MC_VIRT_BASE	(ARMADA_REGS_VIRT_BASE | 0x20180)
+
+/* Timers */

arch/arm/mach-armada/include/mach/armada.h line 233

Quoted 10 lines
arch/arm/mach-armada/include/mach/armada.h new file +10 -0
+#define ARMADA_TIMER_VIRT_BASE		(ARMADA_CPU_VIRT_BASE | 0x0300)
+#define  ARMADA_TIMERS_INT_TIMER1_CLR	(~0x0100)
+#define TIMER_VIRT_BASE                 ARMADA_TIMER_VIRT_BASE
+
+/* Main Interrupt Controller Control and Configuration */
+#define ARMADA_MAIN_INT_CNTL_BASE  (ARMADA_CPU_VIRT_BASE | 0x0)
+
+/* Per CPU Interrupt Controller Control and Configuration */
+#define ARMADA_PER_CPU_INT_CNTL_BASE  (ARMADA_CPU_VIRT_BASE | 0x1000)
+

As Ben pointed out, all this should come from DT.

Quoted 73 lines
arch/arm/mach-armada/include/mach/armada.h new file +1 -0
+#endif /* __MACH_ARMADA_H */
arch/arm/mach-armada/include/mach/bridge-regs.h new file +28 -0
new file mode 100644
index 0000000..0eaefbd
@@ -0,0 +1,28 @@
+/*
+ * Mbus-L to Mbus Bridge Registers
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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 __ASM_ARCH_BRIDGE_REGS_H
+#define __ASM_ARCH_BRIDGE_REGS_H
+
+#include <mach/armada.h>
+
+#define RSTOUTn_MASK		(ARMADA_SYSTEM_VIRT_BASE | 0x60)
+#define  SOFT_RESET_OUT_EN	0x00000001
+
+#define SYSTEM_SOFT_RESET	(ARMADA_SYSTEM_VIRT_BASE | 0x64)
+#define  SOFT_RESET		0x00000001
+
+#define SOC_ID                  (ARMADA_MISC_VIRT_BASE | 0x3C)
+
+#endif
arch/arm/mach-armada/include/mach/debug-macro.S new file +23 -0
new file mode 100644
index 0000000..1c7c52f
@@ -0,0 +1,23 @@
+/*
+ * Early serial output macro for Marvell Armada SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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/armada.h>
+
+	.macro	addruart, rp, rv, tmp
+	ldr	\rp, =ARMADA_REGS_PHYS_BASE
+	ldr	\rv, =ARMADA_REGS_VIRT_BASE
+	orr	\rp, \rp, #0x00012000
+	orr	\rv, \rv, #0x00012000
+	.endm
+
+#define UART_SHIFT	2
+#include <asm/hardware/debug-8250.S>
arch/arm/mach-armada/include/mach/gpio.h new file +3 -0
new file mode 100644
index 0000000..e62f38a
@@ -0,0 +1,13 @@
+/*
+ * Marvell Armada SoC GPIO definitions
+ *

arch/arm/mach-armada/include/mach/gpio.h line 13

Quoted 10 lines
arch/arm/mach-armada/include/mach/gpio.h new file +10 -0
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 <plat/gpio.h>

New platforms should probably have empty gpio.h.

arch/arm/mach-armada/include/mach/hardware.h

Quoted 5 lines
arch/arm/mach-armada/include/mach/hardware.h new file +0 -0
new file mode 100644
index 0000000..829111b

You should not have a hardware.h. Include armada.h directly or ideally remove the need for it.

Quoted 33 lines
arch/arm/mach-armada/include/mach/hardware.h new file +18 -0
@@ -0,0 +1,18 @@
+/*
+ * Marvell Armada SoC hardware definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 __ASM_ARCH_HARDWARE_H
+#define __ASM_ARCH_HARDWARE_H
+
+#include <mach/armada.h>
+
+#endif
arch/arm/mach-armada/include/mach/io.h new file +8 -0
new file mode 100644
index 0000000..48716c1
@@ -0,0 +1,24 @@
+/*
+ * Basic I/O macros
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * This file is licensed under the terms of the GNU General Public

arch/arm/mach-armada/include/mach/io.h line 18

Quoted 10 lines
arch/arm/mach-armada/include/mach/io.h new file +10 -0
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __ASM_ARCH_IO_H
+#define __ASM_ARCH_IO_H
+
+#include <mach/armada.h>
+
+#define IO_SPACE_LIMIT		0xffffffff

Your i/o window should really not be full 32-bit address space.

arch/arm/mach-armada/include/mach/io.h line 21

Quoted 3 lines
arch/arm/mach-armada/include/mach/io.h new file +3 -0
+
+#define __io(a)		((void __iomem *)(((a) - ARMADA_PCIE0_IO_BUS_BASE) + \
+						 ARMADA_PCIE0_IO_VIRT_BASE))

Are you including PCI in initial patches? This is not needed.

arch/arm/mach-armada/include/mach/io.h line 22

Quoted 1 line
arch/arm/mach-armada/include/mach/io.h new file +1 -0
+#define __mem_pci(a)	(a)

Not needed.

In other words, remove io.h. It's no longer needed except for a few cases like PCI and that will be fixed soon (hopefully).

Quoted 92 lines
arch/arm/mach-armada/include/mach/io.h new file +2 -0
+
+#endif
arch/arm/mach-armada/include/mach/irqs.h new file +84 -0
new file mode 100644
index 0000000..48844a4
@@ -0,0 +1,96 @@
+/*
+ * IRQ definitions for Marvell Armada SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 __ASM_ARCH_IRQS_H
+#define __ASM_ARCH_IRQS_H
+
+/*
+ * Per-cpu Interrupts
+ */
+#define IRQ_ARMADA_DRBL_LOW	0
+#define IRQ_ARMADA_DRBL_HI	1
+#define IRQ_ARMADA_DRBL_SUM	2
+#define IRQ_ARMADA_FABRIC	3
+#define IRQ_ARMADA_SOC_ERR	4
+#define IRQ_ARMADA_LCL_TIMER0	5
+#define IRQ_ARMADA_LCL_TIMER1	6
+#define IRQ_ARMADA_LCL_WD	7
+#define IRQ_ARMADA_GE0_TH_RXTX	8
+#define IRQ_ARMADA_GE0_RXTX	9
+#define IRQ_ARMADA_GE1_TH_RXTX	10
+#define IRQ_ARMADA_GE1_RXTX	11
+#define IRQ_ARMADA_GE2_TH_RXTX	12
+#define IRQ_ARMADA_GE2_RXTX	13
+#define IRQ_ARMADA_GE3_TH_RXTX	14
+#define IRQ_ARMADA_GE3_RXTX	15
+
+/*
+ * Global interrupts
+ */
+#define IRQ_ARMADA_LCD		29
+#define IRQ_ARMADA_SPI0		30
+#define IRQ_ARMADA_I2C0		31
+#define IRQ_ARMADA_I2C1		32
+#define IRQ_ARMADA_GLBL_TIMER0	37
+#define IRQ_ARMADA_GLBL_TIMER1	38
+#define IRQ_ARMADA_GLBL_TIMER2	39
+#define IRQ_ARMADA_GLBL_TIMER3	40
+#define IRQ_ARMADA_UART0	41
+#define IRQ_ARMADA_UART1	42
+#define IRQ_ARMADA_UART2	43
+#define IRQ_ARMADA_UART3	44
+#define IRQ_ARMADA_USB0		45
+#define IRQ_ARMADA_USB1		46
+#define IRQ_ARMADA_USB2		47
+#define IRQ_ARMADA_CESA0	48
+#define IRQ_ARMADA_CESA1	49
+#define IRQ_ARMADA_RTC		50
+#define IRQ_ARMADA_XOR0_CH0	51
+#define IRQ_ARMADA_XOR0_CH1	52
+#define IRQ_ARMADA_SDIO		54
+#define IRQ_ARMADA_SATA0	55
+#define IRQ_ARMADA_TDM		56
+#define IRQ_ARMADA_SATA1	57
+#define IRQ_ARMADA_PCIE0	61
+#define IRQ_ARMADA_PCIE1	62
+#define IRQ_ARMADA_GPIO_0_7	82
+#define IRQ_ARMADA_GPIO_8_15	83
+#define IRQ_ARMADA_GPIO_16_23	84
+#define IRQ_ARMADA_GPIO_24_31	85
+#define IRQ_ARMADA_GPIO_32_39	87
+#define IRQ_ARMADA_GPIO_40_47	88
+#define IRQ_ARMADA_GPIO_48_55	89
+#define IRQ_ARMADA_GPIO_56_63	90
+#define IRQ_ARMADA_GPIO_64_66	91
+#define IRQ_ARMADA_SPI1		92
+#define IRQ_ARMADA_WD		93
+#define IRQ_ARMADA_XOR1_CH0	94
+#define IRQ_ARMADA_XOR1_CH1	95
+#define IRQ_ARMADA_PCIE2	99
+#define IRQ_ARMADA_PCIE3	103
+#define IRQ_ARMADA_DRAM		108
+#define IRQ_ARMADA_GE0_WKUP	109
+#define IRQ_ARMADA_GE1_WKUP	110
+#define IRQ_ARMADA_GE2_WKUP	111
+#define IRQ_ARMADA_GE3_WKUP	112

arch/arm/mach-armada/include/mach/irqs.h line 94

Quoted 10 lines
arch/arm/mach-armada/include/mach/irqs.h new file +10 -0
+#define IRQ_ARMADA_NFC		113
+
+/*
+ * ARMADA General Purpose Pins
+ */
+#define IRQ_ARMADA_GPIO_START	82
+#define NR_GPIO_IRQS		64
+
+#define NR_IRQS			(115)
+

All this should come from DT. Enable SPARSE_IRQ.

arch/arm/mach-armada/include/mach/system.h

Quoted 7 lines
arch/arm/mach-armada/include/mach/irqs.h new file +2 -0
+
+#endif
arch/arm/mach-armada/include/mach/system.h new file +0 -0
new file mode 100644
index 0000000..f920ef0

This header is gone now. You don't need anything if you just use the default cpu_do_idle.

Quoted 88 lines
arch/arm/mach-armada/include/mach/system.h new file +21 -0
@@ -0,0 +1,21 @@
+/*
+ * Marvell Armada SoC system defines
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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 __ASM_ARCH_SYSTEM_H
+#define __ASM_ARCH_SYSTEM_H
+
+static inline void arch_idle(void)
+{
+	cpu_do_idle();
+}
+
+#endif
arch/arm/mach-armada/include/mach/timex.h new file +13 -0
new file mode 100644
index 0000000..ab324a3
@@ -0,0 +1,13 @@
+/*
+ * Marvell Armada SoC time definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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)
arch/arm/mach-armada/include/mach/uncompress.h new file +41 -0
new file mode 100644
index 0000000..611ebf3
@@ -0,0 +1,41 @@
+/*
+ * Marvell Armada SoC kernel uncompression UART routines
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ *
+ * 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/armada.h>
+
+#define UART_THR ((volatile unsigned char *)(ARMADA_UART0_PHYS_BASE + 0x0))
+#define UART_LSR ((volatile unsigned char *)(ARMADA_UART0_PHYS_BASE + 0x14))
+
+#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()
maintainer
#5 lore raw

PATCH 1/8 arm: mach-armada: add headers

In reply to Thomas Petazzoni
Quoted 3 lines · Thomas Petazzoni

From: Gregory CLEMENT <[email protected]>

This patch adds basic header files for Armada SoCs.

Some of those files, such as system.h, have been made obsolete in mainline lately. Please remove them.

Nicolas

#6 lore raw

PATCH 2/8 arm: mach-armada: add source files

In reply to Thomas Petazzoni

This patch adds basic source files for Marvell Armada SoCs.

---
 arch/arm/boot/dts/a370.dtsi        |   23 ++++
 arch/arm/boot/dts/armada.dtsi      |   67 ++++++++++
 arch/arm/boot/dts/axp.dtsi         |   43 +++++++
 arch/arm/mach-armada/Kconfig       |    5 +
 arch/arm/mach-armada/Makefile      |    2 +
 arch/arm/mach-armada/Makefile.boot |    1 +
 arch/arm/mach-armada/common.c      |   56 +++++++++
 arch/arm/mach-armada/common.h      |   27 ++++
 arch/arm/mach-armada/irq.c         |  116 +++++++++++++++++
 arch/arm/mach-armada/time.c        |  243 ++++++++++++++++++++++++++++++++++++
 10 files changed, 583 insertions(+)
 create mode 100644 arch/arm/boot/dts/a370.dtsi
 create mode 100644 arch/arm/boot/dts/armada.dtsi
 create mode 100644 arch/arm/boot/dts/axp.dtsi
 create mode 100644 arch/arm/mach-armada/Kconfig
 create mode 100644 arch/arm/mach-armada/Makefile
 create mode 100644 arch/arm/mach-armada/Makefile.boot
 create mode 100644 arch/arm/mach-armada/common.c
 create mode 100644 arch/arm/mach-armada/common.h
 create mode 100644 arch/arm/mach-armada/irq.c
 create mode 100644 arch/arm/mach-armada/time.c
arch/arm/boot/dts/a370.dtsi new file +23 -0
new file mode 100644
index 0000000..f11e56a
@@ -0,0 +1,23 @@
+/*
+ * Device Tree Include file for Marvell Armada 370 family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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.dtsi"
+
+/ {
+	model = "Marvell Armada 370 family SoC";
+	compatible = "marvell,armada370", "marvell,armada";
+ };
arch/arm/boot/dts/armada.dtsi new file +67 -0

67 lines not on this page · raw message

arch/arm/boot/dts/axp.dtsi new file +43 -0

43 lines not on this page · raw message

arch/arm/mach-armada/Kconfig new file +5 -0
new file mode 100644
index 0000000..010a6a3
@@ -0,0 +1,5 @@
+if ARCH_ARMADA
+
+menu "Marvell Armada Implementations"
+
+endif
arch/arm/mach-armada/Makefile new file +2 -0
new file mode 100644
index 0000000..6765961
@@ -0,0 +1,2 @@
+obj-y += common.o irq.o time.o
+
arch/arm/mach-armada/Makefile.boot new file +1 -0
new file mode 100644
index 0000000..b327175
@@ -0,0 +1 @@
+zreladdr-y := 0x00008000
arch/arm/mach-armada/common.c new file +56 -0

56 lines not on this page · raw message

arch/arm/mach-armada/common.h new file +27 -0
new file mode 100644
index 0000000..e453161
@@ -0,0 +1,27 @@
+/*
+ * Core functions for Marvell Armada System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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
+
+#include <asm/exception.h>
+
+extern struct sys_timer armada_timer;
+
+void armada_map_io(void);
+void armada_init_irq(void);
+void armada_restart(char, const char *);
+asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs);
+
+#endif
arch/arm/mach-armada/irq.c new file +116 -0

116 lines not on this page · raw message

arch/arm/mach-armada/time.c new file +243 -0

243 lines not on this page · raw message

Signature · 1 line
1.7.9.5
maintainer
#7 lore raw

PATCH 2/8 arm: mach-armada: add source files

Quoted 46 lines · Thomas Petazzoni

This patch adds basic source files for Marvell Armada SoCs.

---
 arch/arm/boot/dts/a370.dtsi        |   23 ++++
 arch/arm/boot/dts/armada.dtsi      |   67 ++++++++++
 arch/arm/boot/dts/axp.dtsi         |   43 +++++++
 arch/arm/mach-armada/Kconfig       |    5 +
 arch/arm/mach-armada/Makefile      |    2 +
 arch/arm/mach-armada/Makefile.boot |    1 +
 arch/arm/mach-armada/common.c      |   56 +++++++++
 arch/arm/mach-armada/common.h      |   27 ++++
 arch/arm/mach-armada/irq.c         |  116 +++++++++++++++++
 arch/arm/mach-armada/time.c        |  243 ++++++++++++++++++++++++++++++++++++
 10 files changed, 583 insertions(+)
 create mode 100644 arch/arm/boot/dts/a370.dtsi
 create mode 100644 arch/arm/boot/dts/armada.dtsi
 create mode 100644 arch/arm/boot/dts/axp.dtsi
 create mode 100644 arch/arm/mach-armada/Kconfig
 create mode 100644 arch/arm/mach-armada/Makefile
 create mode 100644 arch/arm/mach-armada/Makefile.boot
 create mode 100644 arch/arm/mach-armada/common.c
 create mode 100644 arch/arm/mach-armada/common.h
 create mode 100644 arch/arm/mach-armada/irq.c
 create mode 100644 arch/arm/mach-armada/time.c
arch/arm/boot/dts/a370.dtsi new file +12 -0
new file mode 100644
index 0000000..f11e56a
@@ -0,0 +1,23 @@
+/*
+ * Device Tree Include file for Marvell Armada 370 family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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.

arch/arm/boot/dts/a370.dtsi line 22

Quoted 10 lines
arch/arm/boot/dts/a370.dtsi new file +10 -0
+ *
+ * Contains definitions specific to the Armada 370 SoC that are not
+ * common to all Armada SoCs.
+ */
+
+/include/ "armada.dtsi"
+
+/ {
+	model = "Marvell Armada 370 family SoC";
+	compatible = "marvell,armada370", "marvell,armada";

It should be mrvl, not marvell, in all the compatibility strings.

Also, we need to be careful with armada. kirkwood is an armada for example. It maybe be better to not actually use armada without postfix.

Quoted 4 lines
arch/arm/boot/dts/a370.dtsi new file +4 -0
+void armada_restart(char mode, const char *cmd)
+{
+	/*
+	 * Enable soft reset to assert RSTOUTn.

arch/arm/boot/dts/a370.dtsi

Quoted 10 lines
arch/arm/boot/dts/a370.dtsi new file +10 -0
+	 */
+	writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK);
+
+	/*
+	 * Assert soft reset.
+	 */
+	writel(SOFT_RESET, SYSTEM_SOFT_RESET);
+	while (1)
+		;
+}

This chunk of code comes up multiple times in various orion devices. Could it be refactored into plat-orion?

Thanks
Andrew

#8 lore raw

PATCH 2/8 arm: mach-armada: add source files

Hello Andrew,

Thanks for the quick feedback!

Le Tue, 15 May 2012 11:12:18 +0200,
Andrew Lunn <[email protected]> a ?crit :

Quoted 7 lines

arch/arm/boot/dts/a370.dtsi line 22

Quoted 5 lines
arch/arm/boot/dts/a370.dtsi new file +5 -0
+/include/ "armada.dtsi"
+
+/ {
+	model = "Marvell Armada 370 family SoC";
+	compatible = "marvell,armada370", "marvell,armada";

It should be mrvl, not marvell, in all the compatibility strings.

Ok, we will change that.

Quoted 3 lines

Also, we need to be careful with armada. kirkwood is an armada for example. It maybe be better to not actually use armada without postfix.

Do you have a recommendation for this? We support both Armada 370 and Armada XP, so the obvious common prefix for these two platforms is "armada". Since kirkwood are ARMv5 and those new Armada are ARMv7, would armadav7 be a better prefix? Then we could have armadav7-370 and armadav7-xp? Other suggestions?

Quoted 2 lines

This chunk of code comes up multiple times in various orion devices. Could it be refactored into plat-orion?

Probably yes. However, the register definitions are different between the different devices.

Best regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#9 lore raw

PATCH 2/8 arm: mach-armada: add source files

Quoted 21 lines · Thomas Petazzoni

Hello Andrew,

Thanks for the quick feedback!

Le Tue, 15 May 2012 11:12:18 +0200,
Andrew Lunn<[email protected]> a ?crit :

Quoted 7 lines

arch/arm/boot/dts/a370.dtsi line 22

Quoted 5 lines
arch/arm/boot/dts/a370.dtsi new file +5 -0
+/include/ "armada.dtsi"
+
+/ {
+	model = "Marvell Armada 370 family SoC";
+	compatible = "marvell,armada370", "marvell,armada";

It should be mrvl, not marvell, in all the compatibility strings.

Ok, we will change that.

Quoted 3 lines

Also, we need to be careful with armada. kirkwood is an armada for example. It maybe be better to not actually use armada without postfix.

Quoted 5 lines

Do you have a recommendation for this? We support both Armada 370 and Armada XP, so the obvious common prefix for these two platforms is "armada". Since kirkwood are ARMv5 and those new Armada are ARMv7, would armadav7 be a better prefix? Then we could have armadav7-370 and armadav7-xp? Other suggestions?

You might want to talk to Marvell about that. I went with armadaxp or a shortened axp (although that might have bad connections back to the old Alphas)

[snip]

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#10 lore raw

PATCH 2/8 arm: mach-armada: add source files

In reply to Thomas Petazzoni

Thomas Petazzoni <[email protected]> writes:

Hi,

Quoted 21 lines

Hello Andrew,

Thanks for the quick feedback!

Le Tue, 15 May 2012 11:12:18 +0200,
Andrew Lunn <[email protected]> a ?crit :

Quoted 7 lines

arch/arm/boot/dts/a370.dtsi line 22

Quoted 5 lines
arch/arm/boot/dts/a370.dtsi new file +5 -0
+/include/ "armada.dtsi"
+
+/ {
+	model = "Marvell Armada 370 family SoC";
+	compatible = "marvell,armada370", "marvell,armada";

It should be mrvl, not marvell, in all the compatibility strings.

Ok, we will change that.

Quoted 3 lines

Also, we need to be careful with armada. kirkwood is an armada for example. It maybe be better to not actually use armada without postfix.

Quoted 5 lines

Do you have a recommendation for this? We support both Armada 370 and Armada XP, so the obvious common prefix for these two platforms is "armada". Since kirkwood are ARMv5 and those new Armada are ARMv7, would armadav7 be a better prefix? Then we could have armadav7-370 and armadav7-xp? Other suggestions?

Please be carefull with what you'll choose. There's also Dove SoCs which are v7 too (88AP510 / armada 510 in Marvell namings). I would be tempted to use "mrvl,dove" like was what was used for kirkwood so this won't conflict but still, can be quite confusing.

Regards,
Arnaud

#11 lore raw

PATCH 2/8 arm: mach-armada: add source files

Quoted 30 lines · Arnaud Patard (Rtp)

Thomas Petazzoni<[email protected]> writes:

Hi,

Quoted 21 lines

Hello Andrew,

Thanks for the quick feedback!

Le Tue, 15 May 2012 11:12:18 +0200,
Andrew Lunn<[email protected]> a ?crit :

Quoted 7 lines

arch/arm/boot/dts/a370.dtsi line 22

Quoted 5 lines
arch/arm/boot/dts/a370.dtsi new file +5 -0
+/include/ "armada.dtsi"
+
+/ {
+	model = "Marvell Armada 370 family SoC";
+	compatible = "marvell,armada370", "marvell,armada";

It should be mrvl, not marvell, in all the compatibility strings.

Ok, we will change that.

Quoted 3 lines

Also, we need to be careful with armada. kirkwood is an armada for example. It maybe be better to not actually use armada without postfix.

Quoted 5 lines

Do you have a recommendation for this? We support both Armada 370 and Armada XP, so the obvious common prefix for these two platforms is "armada". Since kirkwood are ARMv5 and those new Armada are ARMv7, would armadav7 be a better prefix? Then we could have armadav7-370 and armadav7-xp? Other suggestions?

Quoted 4 lines

Please be carefull with what you'll choose. There's also Dove SoCs which are v7 too (88AP510 / armada 510 in Marvell namings). I would be tempted to use "mrvl,dove" like was what was used for kirkwood so this won't conflict but still, can be quite confusing.

For the device tree naming, I would go for the device's manufacturing code simply to ensure that there is no confusion about what is being supported.

For further compatibility fields, I'm not sure on how good it would be to put things that are not at-least sub-sets of what is being supported in the compatibilty line... We'd like to avoid changing the kernel too much, but adding an extra line or two to selected drivers is not difficult.

The actuall CPU core shouldn't really come in to it, as that is taken care of elsewhere in the kernel initialisation sequence.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
maintainer
#12 lore raw

PATCH 2/8 arm: mach-armada: add source files

In reply to Thomas Petazzoni
Quoted 44 lines
arch/arm/mach-armada/irq.c new file +37 -0
new file mode 100644
index 0000000..7006429
@@ -0,0 +1,116 @@
+/*
+ * Marvall Armada SoC IRQ handling
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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/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_INT_SET_MASK_OFFS             (0xBC)
+#define ARMADA_INT_CLEAR_MASK_OFFS           (0xB8)
+
+#define ARMADA_INT_SET_ENABLE_OFFS           (0xA30)
+#define ARMADA_INT_CLEAR_ENABLE_OFFS         (0xA34)
+
+#define ARMADA_CPU_INTACK_OFFS               (0xB4)
+
+static void __iomem *per_cpu_int_base;
+static void __iomem *main_int_base;
+static struct irq_domain *armada_mpic_domain;

arch/arm/mach-armada/irq.c line 47

Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10 -0
+
+static void armada_irq_mask(struct irq_data *d)
+{
+	writel(d->irq, per_cpu_int_base + ARMADA_INT_CLEAR_MASK_OFFS);
+}
+
+static void armada_irq_unmask(struct irq_data *d)
+{
+	writel(d->irq, per_cpu_int_base + ARMADA_INT_SET_MASK_OFFS);
+}

All the other orion's use the generic-chip interrupt routines. Can this device also use it? It would also allow you to use the generic DT bindings.

Andrew

#13 lore raw

PATCH 2/8 arm: mach-armada: add source files

Quoted 50 lines · Andrew Lunn
Quoted 50 lines
arch/arm/mach-armada/irq.c new file +43 -0
new file mode 100644
index 0000000..7006429
@@ -0,0 +1,116 @@
+/*
+ * Marvall Armada SoC IRQ handling
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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/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_INT_SET_MASK_OFFS             (0xBC)
+#define ARMADA_INT_CLEAR_MASK_OFFS           (0xB8)
+
+#define ARMADA_INT_SET_ENABLE_OFFS           (0xA30)
+#define ARMADA_INT_CLEAR_ENABLE_OFFS         (0xA34)
+
+#define ARMADA_CPU_INTACK_OFFS               (0xB4)
+
+static void __iomem *per_cpu_int_base;
+static void __iomem *main_int_base;
+static struct irq_domain *armada_mpic_domain;
+
+static void armada_irq_mask(struct irq_data *d)
+{
+	writel(d->irq, per_cpu_int_base + ARMADA_INT_CLEAR_MASK_OFFS);
+}
+
Quoted 8 lines

arch/arm/mach-armada/irq.c line 47

Quoted 4 lines
arch/arm/mach-armada/irq.c new file +4 -0
+static void armada_irq_unmask(struct irq_data *d)
+{
+	writel(d->irq, per_cpu_int_base + ARMADA_INT_SET_MASK_OFFS);
+}

All the other orion's use the generic-chip interrupt routines. Can this device also use it? It would also allow you to use the generic DT bindings.

Possibly, but there'll need to be support for setting interrupt affinity added at some point, as this is used on multi-core systems.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#14 lore raw

PATCH 2/8 arm: mach-armada: add source files

Quoted 60 lines

-----Original Message-----
From: Ben Dooks [mailto:ben.dooks at codethink.co.uk]
Sent: Tuesday, May 15, 2012 12:54 PM
To: Thomas Petazzoni; Arnd Bergmann; Olof Johansson; Ben Dooks; Jason Cooper; Andrew Lunn; Nicolas Pitre; Lior Amsalem; Maen Suleiman; linux- arm-kernel at lists.infradead.org; Gregory CLEMENT
Subject: Re: [PATCH 2/8] arm: mach-armada: add source files

Quoted 37 lines · Andrew Lunn
Quoted 37 lines
arch/arm/mach-armada/irq.c new file +31 -0
new file mode 100644 index 0000000..7006429
@@ -0,0 +1,116 @@
+/*
+ * Marvall Armada SoC IRQ handling
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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/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_INT_SET_MASK_OFFS             (0xBC)
+#define ARMADA_INT_CLEAR_MASK_OFFS           (0xB8)
+
+#define ARMADA_INT_SET_ENABLE_OFFS           (0xA30)
+#define ARMADA_INT_CLEAR_ENABLE_OFFS         (0xA34)
Quoted 8 lines

arch/arm/mach-armada/irq.c

Quoted 8 lines
arch/arm/mach-armada/irq.c new file +8 -0
+
+#define ARMADA_CPU_INTACK_OFFS               (0xB4)
+
+static void __iomem *per_cpu_int_base; static void __iomem
+*main_int_base; static struct irq_domain *armada_mpic_domain;
+
+static void armada_irq_mask(struct irq_data *d) {
+	writel(d->irq, per_cpu_int_base +

ARMADA_INT_CLEAR_MASK_OFFS); }

Quoted 3 lines

arch/arm/mach-armada/irq.c line 46

Quoted 3 lines
arch/arm/mach-armada/irq.c new file +3 -0
+
+static void armada_irq_unmask(struct irq_data *d) {
+	writel(d->irq, per_cpu_int_base + ARMADA_INT_SET_MASK_OFFS);

}

Quoted 1 line
Quoted 6 lines
Quoted 3 lines

All the other orion's use the generic-chip interrupt routines. Can this device also use it? It would also allow you to use the generic DT bindings.

Possibly, but there'll need to be support for setting interrupt affinity added at some point, as this is used on multi-core systems.

Exactly, also:
1. we're working on SMP implementation,
the interrupt code will also include SMP related changes and additions (affinity and raise_softirq)
2. The generic-chip uses locking in mask/unmask when system is configured for SMP.
We can avoid it with our HW design, so why not.
3. I've also tried to look into the gic implementation but it seems too far off our HW design.

Quoted 4 lines

--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius

Lior Amsalem

#15 lore raw

PATCH 2/8 arm: mach-armada: add source files

In reply to Thomas Petazzoni
Quoted 42 lines · Thomas Petazzoni

This patch adds basic source files for Marvell Armada SoCs.

---
  arch/arm/boot/dts/a370.dtsi        |   23 ++++
  arch/arm/boot/dts/armada.dtsi      |   67 ++++++++++
  arch/arm/boot/dts/axp.dtsi         |   43 +++++++
  arch/arm/mach-armada/Kconfig       |    5 +
  arch/arm/mach-armada/Makefile      |    2 +
  arch/arm/mach-armada/Makefile.boot |    1 +
  arch/arm/mach-armada/common.c      |   56 +++++++++
  arch/arm/mach-armada/common.h      |   27 ++++
  arch/arm/mach-armada/irq.c         |  116 +++++++++++++++++
  arch/arm/mach-armada/time.c        |  243 ++++++++++++++++++++++++++++++++++++
  10 files changed, 583 insertions(+)

create mode 100644 arch/arm/boot/dts/a370.dtsi create mode 100644 arch/arm/boot/dts/armada.dtsi create mode 100644 arch/arm/boot/dts/axp.dtsi create mode 100644 arch/arm/mach-armada/Kconfig create mode 100644 arch/arm/mach-armada/Makefile create mode 100644 arch/arm/mach-armada/Makefile.boot create mode 100644 arch/arm/mach-armada/common.c create mode 100644 arch/arm/mach-armada/common.h create mode 100644 arch/arm/mach-armada/irq.c create mode 100644 arch/arm/mach-armada/time.c

arch/arm/boot/dts/a370.dtsi new file +8 -0
new file mode 100644
index 0000000..f11e56a
@@ -0,0 +1,23 @@
+/*
+ * Device Tree Include file for Marvell Armada 370 family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>

arch/arm/boot/dts/a370.dtsi line 18

Quoted 10 lines
arch/arm/boot/dts/a370.dtsi new file +10 -0
+ *
+ * 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.dtsi"

I would use armada_xp.dtsi at the least, we've no way of knowing what further Armada devices are going to be produced and whether they will be compatible with.

arch/arm/boot/dts/a370.dtsi line 23

Quoted 4 lines
arch/arm/boot/dts/a370.dtsi new file +4 -0
+/ {
+	model = "Marvell Armada 370 family SoC";
+	compatible = "marvell,armada370", "marvell,armada";
+ };

Firstly, it is mrvl, not marvell everywhere else in the kernel (see MIPS and device tree documentation).

Secondly, I would strongly advise against using the generic marketing name for these devices in the compatible list, "marvell,armada" as we have no way of knowing what new devices will come along in the future and if they'll be compatible.

Quoted 11 lines
arch/arm/boot/dts/armada.dtsi new file +5 -0
new file mode 100644
index 0000000..3c99c30
@@ -0,0 +1,67 @@
+/*
+ * Device Tree Include file for Marvell Armada family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *

arch/arm/boot/dts/armada.dtsi line 15

Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10 -0
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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.

I really do not want to see these files in the kernel, we where suppose to remove any specific manchine dependency by moving to device tree and not push the problem from a board.c to a .dts file.

Given these really should be part of the bootloader, I am not sure if a GPLv2 compliant license is really appropriate for these files. At best some form of dual-licensing to allow them to be moved out into a devtree repository elsewhere would be useful.

(Feedback from Grant here would be useful)

PS, given the amount of devtree related stuff, CC'ing Grant Likely may have been useful./

Quoted 6 lines
arch/arm/boot/dts/armada.dtsi new file +6 -0
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "Marvell Armada family SoC";

arch/arm/boot/dts/armada.dtsi line 31

Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10 -0
+	compatible = "marvell,armada";
+
+	cpus {
+		cpu at 0 {
+			compatible = "marvell,sheeva-v7";
+		};
+	};
+
+	mpic: interrupt-controller at d0020000 {
+	      compatible = "marvell,mpic";

Should this be "mrvl,axp_mpic" ?

Quoted 7 lines
arch/arm/boot/dts/armada.dtsi new file +7 -0
+	      #interrupt-cells =<1>;
+	      #address-cells =<1>;
+	      #size-cells =<1>;
+	      interrupt-controller;
+	      reg =<0xd0020000 0x1000>,
+		<0xd0021000 0x1000>;
+	};

arch/arm/boot/dts/armada.dtsi line 48

Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10 -0
+
+	soc {
+		#address-cells =<1>;
+		#size-cells =<1>;
+		compatible = "simple-bus";
+		interrupt-parent =<&mpic>;
+		ranges;
+
+		serial at d0012000 {
+				compatible = "ns16550";

thought these where more akin to the designware uart blocks?

arch/arm/boot/dts/armada.dtsi line 61

Quoted 13 lines
arch/arm/boot/dts/armada.dtsi new file +13 -0
+				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";

Is this really a generic marvell timer block?

arch/arm/boot/dts/axp.dtsi

Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +6 -0
+			       reg =<0xd0020300 0x30>;
+			       interrupts =<37>,<38>,<39>,<40>;
+		};
+	};
+};
+
arch/arm/boot/dts/axp.dtsi new file +0 -1
new file mode 100644
index 0000000..6427268
--- /dev/null

[snip, pretty much the same comments here.

Quoted 49 lines
arch/arm/mach-armada/Kconfig new file +5 -0
new file mode 100644
index 0000000..010a6a3
@@ -0,0 +1,5 @@
+if ARCH_ARMADA
+
+menu "Marvell Armada Implementations"
+
+endif
arch/arm/mach-armada/Makefile new file +2 -0
new file mode 100644
index 0000000..6765961
@@ -0,0 +1,2 @@
+obj-y += common.o irq.o time.o
+
arch/arm/mach-armada/Makefile.boot new file +1 -0
new file mode 100644
index 0000000..b327175
@@ -0,0 +1 @@
+zreladdr-y := 0x00008000
arch/arm/mach-armada/common.c new file +17 -0
new file mode 100644
index 0000000..92d9ec2
@@ -0,0 +1,56 @@
+/*
+ * Core functions for Marvell Armada System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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/delay.h>
+#include<linux/init.h>

arch/arm/mach-armada/common.c line 27

Quoted 10 lines
arch/arm/mach-armada/common.c new file +10 -0
+#include<linux/platform_device.h>
+#include<linux/irq.h>
+#include<linux/timex.h>
+#include<asm/page.h>
+#include<asm/setup.h>
+#include<asm/mach/map.h>
+#include<plat/addr-map.h>
+#include<mach/armada.h>
+#include<mach/bridge-regs.h>
+#include "common.h"

for some reason there are no spaces between #include and the rest of the code?

Quoted 91 lines
arch/arm/mach-armada/common.c new file +29 -0
+
+static struct map_desc armada_io_desc[] __initdata = {
+	{
+		.virtual	= ARMADA_REGS_VIRT_BASE,
+		.pfn		= __phys_to_pfn(ARMADA_REGS_PHYS_BASE),
+		.length		= ARMADA_REGS_SIZE,
+		.type		= MT_DEVICE,
+	},
+};
+
+void __init armada_map_io(void)
+{
+	iotable_init(armada_io_desc, ARRAY_SIZE(armada_io_desc));
+}
+
+void armada_restart(char mode, const char *cmd)
+{
+	/*
+	 * Enable soft reset to assert RSTOUTn.
+	 */
+	writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK);
+
+	/*
+	 * Assert soft reset.
+	 */
+	writel(SOFT_RESET, SYSTEM_SOFT_RESET);
+	while (1)
+		;
+}
arch/arm/mach-armada/common.h new file +27 -0
new file mode 100644
index 0000000..e453161
@@ -0,0 +1,27 @@
+/*
+ * Core functions for Marvell Armada System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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
+
+#include<asm/exception.h>
+
+extern struct sys_timer armada_timer;
+
+void armada_map_io(void);
+void armada_init_irq(void);
+void armada_restart(char, const char *);
+asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs);
+
+#endif
arch/arm/mach-armada/irq.c new file +23 -0
new file mode 100644
index 0000000..7006429
@@ -0,0 +1,116 @@
+/*
+ * Marvall Armada SoC IRQ handling
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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/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>

arch/arm/mach-armada/irq.c line 33

Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10 -0
+#include<asm/exception.h>
+
+/* Interrupt Controller Registers Map */
+#define ARMADA_INT_SET_MASK_OFFS             (0xBC)
+#define ARMADA_INT_CLEAR_MASK_OFFS           (0xB8)
+
+#define ARMADA_INT_SET_ENABLE_OFFS           (0xA30)
+#define ARMADA_INT_CLEAR_ENABLE_OFFS         (0xA34)
+
+#define ARMADA_CPU_INTACK_OFFS               (0xB4)

MPIC_ since you indicated earlier that it is pretty generic.

Quoted 24 lines
arch/arm/mach-armada/irq.c new file +24 -0
+
+static void __iomem *per_cpu_int_base;
+static void __iomem *main_int_base;
+static struct irq_domain *armada_mpic_domain;
+
+static void armada_irq_mask(struct irq_data *d)
+{
+	writel(d->irq, per_cpu_int_base + ARMADA_INT_CLEAR_MASK_OFFS);
+}
+
+static void armada_irq_unmask(struct irq_data *d)
+{
+	writel(d->irq, per_cpu_int_base + ARMADA_INT_SET_MASK_OFFS);
+}
+
+static struct irq_chip armada_irq_chip = {
+	.name		= "armada_irq",
+	.irq_mask       = armada_irq_mask,
+	.irq_mask_ack   = armada_irq_mask,
+	.irq_unmask     = armada_irq_unmask,
+};
+
+static int armada_mpic_irq_map(struct irq_domain *h,
+			       unsigned int virq,

arch/arm/mach-armada/irq.c line 67

Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10 -0
+			       irq_hw_number_t hw)
+{
+	armada_irq_mask(irq_get_irq_data(virq));
+	writel(virq, main_int_base + ARMADA_INT_SET_ENABLE_OFFS);
+
+	irq_set_chip_and_handler(virq,&armada_irq_chip,
+				 handle_level_irq);
+	irq_set_status_flags(virq, IRQ_LEVEL);
+	set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+	return 0;

you could have used the per-irq driver private data to keep things like the base of controller in.

arch/arm/mach-armada/irq.c line 79

Quoted 12 lines
arch/arm/mach-armada/irq.c new file +12 -0
+}
+
+static struct irq_domain_ops armada_mpic_irq_ops = {
+	.map = armada_mpic_irq_map,
+	.xlate = irq_domain_xlate_onecell,
+};
+
+static void __init armada_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);

Please verify the return values.

Quoted 16 lines
arch/arm/mach-armada/irq.c new file +16 -0
+
+	armada_mpic_domain = irq_domain_add_linear(node, NR_IRQS,
+						&armada_mpic_irq_ops, NULL);
+	if (!armada_mpic_domain)
+		panic("Unable to add Armada MPIC irq domain (DT)\n");
+
+	irq_set_default_host(armada_mpic_domain);
+}
+
+asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs)
+{
+	u32 irqstat, irqnr;
+
+	do {
+		irqstat = readl_relaxed(per_cpu_int_base +
+					ARMADA_CPU_INTACK_OFFS);

arch/arm/mach-armada/irq.c line 105

Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10 -0
+		irqnr = irqstat&  0x3FF;
+
+		if (irqnr<  1023) {
+			irqnr = irq_find_mapping(armada_mpic_domain, irqnr);
+			handle_IRQ(irqnr, regs);
+			continue;
+		}
+
+		break;
+	} while (1);

no timeout to get out of handling many IRQs?

Quoted 34 lines
arch/arm/mach-armada/irq.c new file +11 -0
+}
+
+static const struct of_device_id mpic_of_match[] __initconst = {
+	{ .compatible = "marvell,mpic", .data = armada_mpic_of_init },
+	{},
+};
+
+void __init armada_init_irq(void)
+{
+	of_irq_init(mpic_of_match);
+}
arch/arm/mach-armada/time.c new file +17 -0
new file mode 100644
index 0000000..73817ea
@@ -0,0 +1,243 @@
+/*
+ * Marvell Armada SoC timer handling.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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.
+ */
+

arch/arm/mach-armada/time.c line 27

Quoted 10 lines
arch/arm/mach-armada/time.c new file +10 -0
+#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>

Style issue again.

Quoted 67 lines
arch/arm/mach-armada/time.c new file +67 -0
+
+/*
+ * 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_read_sched_clock(void)
+{
+	return ~readl(timer_base + TIMER0_VAL_OFF);
+}
+
+/*
+ * Clockevent handling.
+ */
+static int
+armada_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);
+
+	/*

arch/arm/mach-armada/time.c line 104

Quoted 10 lines
arch/arm/mach-armada/time.c new file +10 -0
+	 * 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;

you could have halved the length by just using single line comments.

Quoted 28 lines
arch/arm/mach-armada/time.c new file +28 -0
+}
+
+static void
+armada_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 at 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.
+		 */

arch/arm/mach-armada/time.c line 142

Quoted 10 lines
arch/arm/mach-armada/time.c new file +10 -0
+		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);
+
+	}

How about handling the one-shot case that you advertise below?

Quoted 15 lines
arch/arm/mach-armada/time.c new file +15 -0
+static void __init armada_time_init(void)
+{
+	u32 u;
+	struct device_node *np;
+	unsigned int timer_clk;
+
+	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);

arch/arm/mach-armada/time.c line 197

Quoted 10 lines
arch/arm/mach-armada/time.c new file +10 -0
+		timer_clk = 25000000;
+	} else {
+		u32 clk;
+		of_property_read_u32(np, "clock-frequency",&clk);
+		WARN_ON(!clk);
+		u = readl(timer_base + TIMER_CTRL_OFF);
+		writel(u&  ~(TIMER0_25MHZ | TIMER1_25MHZ),
+		       timer_base + TIMER_CTRL_OFF);
+		timer_clk = clk / TIMER_DIVIDER;
+	}

Give we've not got clk_() support yet, should you just force 25M operation until clk_get_rate() is supported?

[snip]

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#16 lore raw

PATCH 2/8 arm: mach-armada: add source files

Quoted 543 lines · Ben Dooks
Quoted 42 lines · Thomas Petazzoni

This patch adds basic source files for Marvell Armada SoCs.

---
  arch/arm/boot/dts/a370.dtsi        |   23 ++++
  arch/arm/boot/dts/armada.dtsi      |   67 ++++++++++
  arch/arm/boot/dts/axp.dtsi         |   43 +++++++
  arch/arm/mach-armada/Kconfig       |    5 +
  arch/arm/mach-armada/Makefile      |    2 +
  arch/arm/mach-armada/Makefile.boot |    1 +
  arch/arm/mach-armada/common.c      |   56 +++++++++
  arch/arm/mach-armada/common.h      |   27 ++++
  arch/arm/mach-armada/irq.c         |  116 +++++++++++++++++
  arch/arm/mach-armada/time.c        |  243 ++++++++++++++++++++++++++++++++++++
  10 files changed, 583 insertions(+)

create mode 100644 arch/arm/boot/dts/a370.dtsi create mode 100644 arch/arm/boot/dts/armada.dtsi create mode 100644 arch/arm/boot/dts/axp.dtsi create mode 100644 arch/arm/mach-armada/Kconfig create mode 100644 arch/arm/mach-armada/Makefile create mode 100644 arch/arm/mach-armada/Makefile.boot create mode 100644 arch/arm/mach-armada/common.c create mode 100644 arch/arm/mach-armada/common.h create mode 100644 arch/arm/mach-armada/irq.c create mode 100644 arch/arm/mach-armada/time.c

arch/arm/boot/dts/a370.dtsi new file +8 -0
new file mode 100644
index 0000000..f11e56a
@@ -0,0 +1,23 @@
+/*
+ * Device Tree Include file for Marvell Armada 370 family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>

arch/arm/boot/dts/a370.dtsi line 18

Quoted 10 lines
arch/arm/boot/dts/a370.dtsi new file +10 -0
+ *
+ * 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.dtsi"

I would use armada_xp.dtsi at the least, we've no way of knowing what further Armada devices are going to be produced and whether they will be compatible with.

arch/arm/boot/dts/a370.dtsi line 23

Quoted 4 lines
arch/arm/boot/dts/a370.dtsi new file +4 -0
+/ {
+	model = "Marvell Armada 370 family SoC";
+	compatible = "marvell,armada370", "marvell,armada";
+ };

Firstly, it is mrvl, not marvell everywhere else in the kernel (see MIPS and device tree documentation).

Secondly, I would strongly advise against using the generic marketing name for these devices in the compatible list, "marvell,armada" as we have no way of knowing what new devices will come along in the future and if they'll be compatible.

Quoted 11 lines
arch/arm/boot/dts/armada.dtsi new file +5 -0
new file mode 100644
index 0000000..3c99c30
@@ -0,0 +1,67 @@
+/*
+ * Device Tree Include file for Marvell Armada family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *

arch/arm/boot/dts/armada.dtsi line 15

Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10 -0
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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.

I really do not want to see these files in the kernel, we where suppose to remove any specific manchine dependency by moving to device tree and not push the problem from a board.c to a .dts file.

Given these really should be part of the bootloader, I am not sure if a GPLv2 compliant license is really appropriate for these files. At best some form of dual-licensing to allow them to be moved out into a devtree repository elsewhere would be useful.

(Feedback from Grant here would be useful)

PS, given the amount of devtree related stuff, CC'ing Grant Likely may have been useful./

Quoted 6 lines
arch/arm/boot/dts/armada.dtsi new file +6 -0
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "Marvell Armada family SoC";

arch/arm/boot/dts/armada.dtsi line 31

Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10 -0
+	compatible = "marvell,armada";
+
+	cpus {
+		cpu at 0 {
+			compatible = "marvell,sheeva-v7";
+		};
+	};
+
+	mpic: interrupt-controller at d0020000 {
+	      compatible = "marvell,mpic";

Should this be "mrvl,axp_mpic" ?

Quoted 7 lines
arch/arm/boot/dts/armada.dtsi new file +7 -0
+	      #interrupt-cells =<1>;
+	      #address-cells =<1>;
+	      #size-cells =<1>;
+	      interrupt-controller;
+	      reg =<0xd0020000 0x1000>,
+		<0xd0021000 0x1000>;
+	};

arch/arm/boot/dts/armada.dtsi line 48

Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10 -0
+
+	soc {
+		#address-cells =<1>;
+		#size-cells =<1>;
+		compatible = "simple-bus";
+		interrupt-parent =<&mpic>;
+		ranges;
+
+		serial at d0012000 {
+				compatible = "ns16550";

thought these where more akin to the designware uart blocks?

arch/arm/boot/dts/armada.dtsi line 61

Quoted 13 lines
arch/arm/boot/dts/armada.dtsi new file +13 -0
+				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";

Is this really a generic marvell timer block?

arch/arm/boot/dts/axp.dtsi

Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +6 -0
+			       reg =<0xd0020300 0x30>;
+			       interrupts =<37>,<38>,<39>,<40>;
+		};
+	};
+};
+
arch/arm/boot/dts/axp.dtsi new file +0 -1
new file mode 100644
index 0000000..6427268
--- /dev/null

[snip, pretty much the same comments here.

Quoted 49 lines
arch/arm/mach-armada/Kconfig new file +5 -0
new file mode 100644
index 0000000..010a6a3
@@ -0,0 +1,5 @@
+if ARCH_ARMADA
+
+menu "Marvell Armada Implementations"
+
+endif
arch/arm/mach-armada/Makefile new file +2 -0
new file mode 100644
index 0000000..6765961
@@ -0,0 +1,2 @@
+obj-y += common.o irq.o time.o
+
arch/arm/mach-armada/Makefile.boot new file +1 -0
new file mode 100644
index 0000000..b327175
@@ -0,0 +1 @@
+zreladdr-y := 0x00008000
arch/arm/mach-armada/common.c new file +17 -0
new file mode 100644
index 0000000..92d9ec2
@@ -0,0 +1,56 @@
+/*
+ * Core functions for Marvell Armada System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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/delay.h>
+#include<linux/init.h>

arch/arm/mach-armada/common.c line 27

Quoted 10 lines
arch/arm/mach-armada/common.c new file +10 -0
+#include<linux/platform_device.h>
+#include<linux/irq.h>
+#include<linux/timex.h>
+#include<asm/page.h>
+#include<asm/setup.h>
+#include<asm/mach/map.h>
+#include<plat/addr-map.h>
+#include<mach/armada.h>
+#include<mach/bridge-regs.h>
+#include "common.h"

for some reason there are no spaces between #include and the rest of the code?

Quoted 91 lines
arch/arm/mach-armada/common.c new file +29 -0
+
+static struct map_desc armada_io_desc[] __initdata = {
+	{
+		.virtual	= ARMADA_REGS_VIRT_BASE,
+		.pfn		= __phys_to_pfn(ARMADA_REGS_PHYS_BASE),
+		.length		= ARMADA_REGS_SIZE,
+		.type		= MT_DEVICE,
+	},
+};
+
+void __init armada_map_io(void)
+{
+	iotable_init(armada_io_desc, ARRAY_SIZE(armada_io_desc));
+}
+
+void armada_restart(char mode, const char *cmd)
+{
+	/*
+	 * Enable soft reset to assert RSTOUTn.
+	 */
+	writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK);
+
+	/*
+	 * Assert soft reset.
+	 */
+	writel(SOFT_RESET, SYSTEM_SOFT_RESET);
+	while (1)
+		;
+}
arch/arm/mach-armada/common.h new file +27 -0
new file mode 100644
index 0000000..e453161
@@ -0,0 +1,27 @@
+/*
+ * Core functions for Marvell Armada System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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
+
+#include<asm/exception.h>
+
+extern struct sys_timer armada_timer;
+
+void armada_map_io(void);
+void armada_init_irq(void);
+void armada_restart(char, const char *);
+asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs);
+
+#endif
arch/arm/mach-armada/irq.c new file +23 -0
new file mode 100644
index 0000000..7006429
@@ -0,0 +1,116 @@
+/*
+ * Marvall Armada SoC IRQ handling
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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/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>

arch/arm/mach-armada/irq.c line 33

Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10 -0
+#include<asm/exception.h>
+
+/* Interrupt Controller Registers Map */
+#define ARMADA_INT_SET_MASK_OFFS             (0xBC)
+#define ARMADA_INT_CLEAR_MASK_OFFS           (0xB8)
+
+#define ARMADA_INT_SET_ENABLE_OFFS           (0xA30)
+#define ARMADA_INT_CLEAR_ENABLE_OFFS         (0xA34)
+
+#define ARMADA_CPU_INTACK_OFFS               (0xB4)

MPIC_ since you indicated earlier that it is pretty generic.

Quoted 24 lines
arch/arm/mach-armada/irq.c new file +24 -0
+
+static void __iomem *per_cpu_int_base;
+static void __iomem *main_int_base;
+static struct irq_domain *armada_mpic_domain;
+
+static void armada_irq_mask(struct irq_data *d)
+{
+	writel(d->irq, per_cpu_int_base + ARMADA_INT_CLEAR_MASK_OFFS);
+}
+
+static void armada_irq_unmask(struct irq_data *d)
+{
+	writel(d->irq, per_cpu_int_base + ARMADA_INT_SET_MASK_OFFS);
+}
+
+static struct irq_chip armada_irq_chip = {
+	.name		= "armada_irq",
+	.irq_mask       = armada_irq_mask,
+	.irq_mask_ack   = armada_irq_mask,
+	.irq_unmask     = armada_irq_unmask,
+};
+
+static int armada_mpic_irq_map(struct irq_domain *h,
+			       unsigned int virq,

arch/arm/mach-armada/irq.c line 67

Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10 -0
+			       irq_hw_number_t hw)
+{
+	armada_irq_mask(irq_get_irq_data(virq));
+	writel(virq, main_int_base + ARMADA_INT_SET_ENABLE_OFFS);
+
+	irq_set_chip_and_handler(virq,&armada_irq_chip,
+				 handle_level_irq);
+	irq_set_status_flags(virq, IRQ_LEVEL);
+	set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+	return 0;

you could have used the per-irq driver private data to keep things like the base of controller in.

arch/arm/mach-armada/irq.c line 79

Quoted 12 lines
arch/arm/mach-armada/irq.c new file +12 -0
+}
+
+static struct irq_domain_ops armada_mpic_irq_ops = {
+	.map = armada_mpic_irq_map,
+	.xlate = irq_domain_xlate_onecell,
+};
+
+static void __init armada_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);

Please verify the return values.

Quoted 16 lines
arch/arm/mach-armada/irq.c new file +16 -0
+
+	armada_mpic_domain = irq_domain_add_linear(node, NR_IRQS,
+						&armada_mpic_irq_ops, NULL);
+	if (!armada_mpic_domain)
+		panic("Unable to add Armada MPIC irq domain (DT)\n");
+
+	irq_set_default_host(armada_mpic_domain);
+}
+
+asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs)
+{
+	u32 irqstat, irqnr;
+
+	do {
+		irqstat = readl_relaxed(per_cpu_int_base +
+					ARMADA_CPU_INTACK_OFFS);

arch/arm/mach-armada/irq.c line 105

Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10 -0
+		irqnr = irqstat&  0x3FF;
+
+		if (irqnr<  1023) {
+			irqnr = irq_find_mapping(armada_mpic_domain, irqnr);
+			handle_IRQ(irqnr, regs);
+			continue;
+		}
+
+		break;
+	} while (1);

no timeout to get out of handling many IRQs?

Quoted 34 lines
arch/arm/mach-armada/irq.c new file +11 -0
+}
+
+static const struct of_device_id mpic_of_match[] __initconst = {
+	{ .compatible = "marvell,mpic", .data = armada_mpic_of_init },
+	{},
+};
+
+void __init armada_init_irq(void)
+{
+	of_irq_init(mpic_of_match);
+}
arch/arm/mach-armada/time.c new file +17 -0
new file mode 100644
index 0000000..73817ea
@@ -0,0 +1,243 @@
+/*
+ * Marvell Armada SoC timer handling.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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.
+ */
+

arch/arm/mach-armada/time.c line 27

Quoted 10 lines
arch/arm/mach-armada/time.c new file +10 -0
+#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>

Style issue again.

Quoted 72 lines
arch/arm/mach-armada/time.c new file +72 -0
+
+/*
+ * 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_read_sched_clock(void)
+{
+	return ~readl(timer_base + TIMER0_VAL_OFF);
+}
+
+/*
+ * Clockevent handling.
+ */
+static int
+armada_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));
Quoted 8 lines

arch/arm/mach-armada/time.c line 104

Quoted 5 lines
arch/arm/mach-armada/time.c new file +5 -0
+	writel(u, timer_base + TIMER_CTRL_OFF);
+
+	local_irq_restore(flags);
+
+	return 0;

you could have halved the length by just using single line comments.

Right

Quoted 62 lines
Quoted 29 lines
arch/arm/mach-armada/time.c new file +28 -0
+}
+
+static void
+armada_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 at 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.
+		 */

arch/arm/mach-armada/time.c line 142

Quoted 10 lines
arch/arm/mach-armada/time.c new file +10 -0
+		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);
+
+	}

How about handling the one-shot case that you advertise below?

Quoted 20 lines
arch/arm/mach-armada/time.c new file +20 -0
+static void __init armada_time_init(void)
+{
+	u32 u;
+	struct device_node *np;
+	unsigned int timer_clk;
+
+	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;
+		of_property_read_u32(np, "clock-frequency",&clk);
+		WARN_ON(!clk);
Quoted 9 lines

arch/arm/mach-armada/time.c line 197

Quoted 5 lines
arch/arm/mach-armada/time.c new file +5 -0
+		u = readl(timer_base + TIMER_CTRL_OFF);
+		writel(u&  ~(TIMER0_25MHZ | TIMER1_25MHZ),
+		       timer_base + TIMER_CTRL_OFF);
+		timer_clk = clk / TIMER_DIVIDER;
+	}

Give we've not got clk_() support yet, should you just force 25M operation until clk_get_rate() is supported?

This code support Aramade XP _and_ Armada 370, and for Armada 370 there is not such feature available.

Quoted 3 lines

[snip]

Signature · 5 lines
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044
maintainer
#17 lore raw

PATCH 2/8 arm: mach-armada: add source files

In reply to Ben Dooks
Quoted 4 lines

arch/arm/boot/dts/armada.dtsi line 61

Quoted 2 lines
arch/arm/boot/dts/armada.dtsi new file +2 -0
+		timer at d0020300 {
+			       compatible = "marvell,timer";

Is this really a generic marvell timer block?

Looking at the code below, its very similar to plat-orion timer.

I've not look at all the details, but i suspect it should not have its own timer implementation, it should just be using plat-orion functions.

Andrew

#18 lore raw

PATCH 2/8 arm: mach-armada: add source files

In reply to Ben Dooks
Quoted 97 lines · Ben Dooks
Quoted 42 lines · Thomas Petazzoni

This patch adds basic source files for Marvell Armada SoCs.

---
  arch/arm/boot/dts/a370.dtsi        |   23 ++++
  arch/arm/boot/dts/armada.dtsi      |   67 ++++++++++
  arch/arm/boot/dts/axp.dtsi         |   43 +++++++
  arch/arm/mach-armada/Kconfig       |    5 +
  arch/arm/mach-armada/Makefile      |    2 +
  arch/arm/mach-armada/Makefile.boot |    1 +
  arch/arm/mach-armada/common.c      |   56 +++++++++
  arch/arm/mach-armada/common.h      |   27 ++++
  arch/arm/mach-armada/irq.c         |  116 +++++++++++++++++
  arch/arm/mach-armada/time.c        |  243 ++++++++++++++++++++++++++++++++++++
  10 files changed, 583 insertions(+)

create mode 100644 arch/arm/boot/dts/a370.dtsi create mode 100644 arch/arm/boot/dts/armada.dtsi create mode 100644 arch/arm/boot/dts/axp.dtsi create mode 100644 arch/arm/mach-armada/Kconfig create mode 100644 arch/arm/mach-armada/Makefile create mode 100644 arch/arm/mach-armada/Makefile.boot create mode 100644 arch/arm/mach-armada/common.c create mode 100644 arch/arm/mach-armada/common.h create mode 100644 arch/arm/mach-armada/irq.c create mode 100644 arch/arm/mach-armada/time.c

arch/arm/boot/dts/a370.dtsi new file +8 -0
new file mode 100644
index 0000000..f11e56a
@@ -0,0 +1,23 @@
+/*
+ * Device Tree Include file for Marvell Armada 370 family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>

arch/arm/boot/dts/a370.dtsi line 18

Quoted 10 lines
arch/arm/boot/dts/a370.dtsi new file +10 -0
+ *
+ * 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.dtsi"

I would use armada_xp.dtsi at the least, we've no way of knowing what further Armada devices are going to be produced and whether they will be compatible with.

arch/arm/boot/dts/a370.dtsi line 23

Quoted 4 lines
arch/arm/boot/dts/a370.dtsi new file +4 -0
+/ {
+	model = "Marvell Armada 370 family SoC";
+	compatible = "marvell,armada370", "marvell,armada";
+ };

Firstly, it is mrvl, not marvell everywhere else in the kernel (see MIPS and device tree documentation).

Secondly, I would strongly advise against using the generic marketing name for these devices in the compatible list, "marvell,armada" as we have no way of knowing what new devices will come along in the future and if they'll be compatible.

Quoted 11 lines
arch/arm/boot/dts/armada.dtsi new file +5 -0
new file mode 100644
index 0000000..3c99c30
@@ -0,0 +1,67 @@
+/*
+ * Device Tree Include file for Marvell Armada family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *

arch/arm/boot/dts/armada.dtsi line 15

Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10 -0
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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.

I really do not want to see these files in the kernel, we where suppose to remove any specific manchine dependency by moving to device tree and not push the problem from a board.c to a .dts file.

Quoted 6 lines

Given these really should be part of the bootloader, I am not sure if a GPLv2 compliant license is really appropriate for these files. At best some form of dual-licensing to allow them to be moved out into a devtree repository elsewhere would be useful.

(Feedback from Grant here would be useful)

Without another repository the kernel tree is the correct place to put these files. I certainly don't want them considered as part of the boot loader either since there needs to be the base expectation that this data may need to change. Please do keep them in arch/arm/boot/dts for now.

g.

#19 lore raw

PATCH 2/8 arm: mach-armada: add source files

In reply to Thomas Petazzoni
Quoted 23 lines · Thomas Petazzoni
arch/arm/mach-armada/common.h new file +17 -0
new file mode 100644
index 0000000..e453161
@@ -0,0 +1,27 @@
+/*
+ * Core functions for Marvell Armada System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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
+

arch/arm/mach-armada/common.h line 27

Quoted 10 lines
arch/arm/mach-armada/common.h new file +10 -0
+#include<asm/exception.h>
+
+extern struct sys_timer armada_timer;
+
+void armada_map_io(void);
+void armada_init_irq(void);
+void armada_restart(char, const char *);
+asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs);
+
+#endif

you should have extern before all these function declarations.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#20 lore raw

PATCH 2/8 arm: mach-armada: add source files

In reply to Thomas Petazzoni
Quoted 23 lines · Thomas Petazzoni
arch/arm/mach-armada/common.h new file +17 -0
new file mode 100644
index 0000000..e453161
@@ -0,0 +1,27 @@
+/*
+ * Core functions for Marvell Armada System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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
+

arch/arm/mach-armada/common.h line 27

Quoted 10 lines
arch/arm/mach-armada/common.h new file +10 -0
+#include<asm/exception.h>
+
+extern struct sys_timer armada_timer;
+
+void armada_map_io(void);
+void armada_init_irq(void);
+void armada_restart(char, const char *);
+asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs);
+
+#endif

As a note, I don't think you need the __exception_irq_entry or the asmlinkage on the declaration of armada_handle_irq, so you could probably drop the include of <asm/exception.h> too.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#21 lore raw

PATCH 3/8 arm: mach-armada: add documentation for new device tree bindings

In reply to Thomas Petazzoni
---
 .../devicetree/bindings/arm/armada-mpic.txt        |   23 +++++++++++++++++++
 .../devicetree/bindings/arm/armada-timer.txt       |   11 +++++++++
 Documentation/devicetree/bindings/arm/armada.txt   |   24 ++++++++++++++++++++
 3 files changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/armada-mpic.txt
 create mode 100644 Documentation/devicetree/bindings/arm/armada-timer.txt
 create mode 100644 Documentation/devicetree/bindings/arm/armada.txt
Documentation/devicetree/bindings/arm/armada-mpic.txt new file +23 -0
new file mode 100644
index 0000000..3571f44
@@ -0,0 +1,23 @@
+Marvell Armada 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>;
+        };
Documentation/devicetree/bindings/arm/armada-timer.txt new file +11 -0
new file mode 100644
index 0000000..6bed565
@@ -0,0 +1,11 @@
+Marvell Armada 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)
Documentation/devicetree/bindings/arm/armada.txt new file +24 -0
new file mode 100644
index 0000000..9724178
@@ -0,0 +1,24 @@
+Marvell Armada Platforms Device Tree Bindings
+---------------------------------------------
+
+Boards with a SoC of the Marvell Armada family shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armada"
+
+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"
+
Signature · 1 line
1.7.9.5
#22 lore raw

PATCH 3/8 arm: mach-armada: add documentation for new device tree bindings

Quoted 17 lines · Thomas Petazzoni
---
  .../devicetree/bindings/arm/armada-mpic.txt        |   23 +++++++++++++++++++
  .../devicetree/bindings/arm/armada-timer.txt       |   11 +++++++++
  Documentation/devicetree/bindings/arm/armada.txt   |   24 ++++++++++++++++++++
  3 files changed, 58 insertions(+)

create mode 100644 Documentation/devicetree/bindings/arm/armada-mpic.txt create mode 100644 Documentation/devicetree/bindings/arm/armada-timer.txt create mode 100644 Documentation/devicetree/bindings/arm/armada.txt

Documentation/devicetree/bindings/arm/armada-mpic.txt new file +0 -0
new file mode 100644
index 0000000..3571f44

Documentation/devicetree/bindings/arm/armada-mpic.txt line 5

Quoted 5 lines
Documentation/devicetree/bindings/arm/armada-mpic.txt new file +5 -0
@@ -0,0 +1,23 @@
+Marvell Armada Interrupt Controller
+-----------------------------------
+
+Required properties:
+- compatible: Should be "marvell,mpic"

see notes on mrvl, and the usage of very generic names. Maybe find a better name than the generic 'mpic'?

Documentation/devicetree/bindings/arm/armada-mpic.txt line 11

Quoted 6 lines
Documentation/devicetree/bindings/arm/armada-mpic.txt new file +6 -0
+- 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

you mis-spelled MPIC as PMIC.

Documentation/devicetree/bindings/arm/armada-timer.txt line 7

Quoted 13 lines
Documentation/devicetree/bindings/arm/armada-timer.txt new file +7 -0
new file mode 100644
index 0000000..6bed565
@@ -0,0 +1,11 @@
+Marvell Armada 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

I'd say that given you already have a clock-frequency field, just use that and detect == 25MHz.

Personally, I would have added a static clock to give to the timer something to reference.

Documentation/devicetree/bindings/arm/armada-timer.txt line 11

Quoted 3 lines
Documentation/devicetree/bindings/arm/armada-timer.txt new file +3 -0
+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)

See above comment.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#23 lore raw

PATCH 4/8 arm: mach-armada: add compilation/configuration changes

In reply to Thomas Petazzoni

From: Gregory CLEMENT <[email protected]>

---
 arch/arm/Kconfig  |   12 ++++++++++++
 arch/arm/Makefile |    1 +
 2 files changed, 13 insertions(+)
arch/arm/Kconfig +12 -0
index d595bd3..8c8987b 100644
@@ -545,6 +545,16 @@ config ARCH_IXP4XX
 	help
 	  Support for Intel's IXP4XX (XScale) family of processors.
 
+config ARCH_ARMADA
+	bool "Marvell Armada"
+	select CPU_V7
+	select ARCH_REQUIRE_GPIOLIB
+	select GENERIC_CLOCKEVENTS
+	select PLAT_ORION
+	select MULTI_IRQ_HANDLER
+	help
+	  Support for the Marvell Armada SoC Family
+
 config ARCH_DOVE
 	bool "Marvell Dove"
 	select CPU_V7
@@ -999,6 +1009,8 @@ endchoice
 # Kconfigs may be included either alphabetically (according to the
 # plat- suffix) or along side the corresponding mach-* source.
 #
+source "arch/arm/mach-armada/Kconfig"
+
 source "arch/arm/mach-at91/Kconfig"
 
 source "arch/arm/mach-bcmring/Kconfig"
arch/arm/Makefile +1 -0
index 8c4dac4..eaf84fa 100644
@@ -195,6 +195,7 @@ machine-$(CONFIG_MACH_SPEAR310)		:= spear3xx
 machine-$(CONFIG_MACH_SPEAR320)		:= spear3xx
 machine-$(CONFIG_MACH_SPEAR600)		:= spear6xx
 machine-$(CONFIG_ARCH_ZYNQ)		:= zynq
+machine-$(CONFIG_ARCH_ARMADA)		:= armada
 
 # Platform directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
Signature · 1 line
1.7.9.5
#24 lore raw

PATCH 5/8 arm: mach-armada: add support for Armada 370 board with device tree

In reply to Thomas Petazzoni

From: Gregory CLEMENT <[email protected]>

---
 arch/arm/boot/dts/a370-db.dts  |   41 ++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-armada/Kconfig   |    8 ++++++++
 arch/arm/mach-armada/Makefile  |    1 +
 arch/arm/mach-armada/a370-dt.c |   41 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 91 insertions(+)
 create mode 100644 arch/arm/boot/dts/a370-db.dts
 create mode 100644 arch/arm/mach-armada/a370-dt.c
arch/arm/boot/dts/a370-db.dts new file +41 -0
new file mode 100644
index 0000000..7bf747e
@@ -0,0 +1,41 @@
+/*
+ * Device Tree file for Marvell Armada 370 evaluation board
+ * (DB-88F6710-BP-DDR3)
+ *
+ *  Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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/ "a370.dtsi"
+
+/ {
+	model = "Marvell Armada 370 Evaluation Board";
+	compatible = "marvell,a370-db", "marvell,armada370", "marvell,armada";
+
+	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>;
+
+		};
+	};
+};
arch/arm/mach-armada/Kconfig +8 -0
index 010a6a3..7995813 100644
@@ -2,4 +2,12 @@ if ARCH_ARMADA
 
 menu "Marvell Armada Implementations"
 
+config MACH_ARMADA_370_DT
+	bool "Marvell Armada 370 boards with device-tree support"
+	help
+	  Say 'Y' here if you want your kernel to support
+	  boards based on Marvell Armada 370 with device tree.
+
+endmenu
+
 endif
arch/arm/mach-armada/Makefile +1 -0
index 6765961..ac39fae 100644
@@ -1,2 +1,3 @@
 obj-y += common.o irq.o time.o
+obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o
 
arch/arm/mach-armada/a370-dt.c new file +41 -0

41 lines not on this page · raw message

Signature · 1 line
1.7.9.5
#25 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Thomas Petazzoni

From: Gregory CLEMENT <[email protected]>

---
 arch/arm/boot/dts/axp-db.dts  |   40 ++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-armada/Kconfig  |    6 ++++++
 arch/arm/mach-armada/Makefile |    2 +-
 arch/arm/mach-armada/axp-dt.c |   41 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/axp-db.dts
 create mode 100644 arch/arm/mach-armada/axp-dt.c
arch/arm/boot/dts/axp-db.dts new file +40 -0
new file mode 100644
index 0000000..916be09
@@ -0,0 +1,40 @@
+/*
+ * Device Tree file for Marvell Armada XP evaluation board
+ * (DB-78460-BP)
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <[email protected]>
+ * Gregory CLEMENT <[email protected]>
+ * Thomas Petazzoni <[email protected]>
+ *
+ * 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/ "axp.dtsi"
+
+/ {
+	model = "Marvell Armada XP Evaluation Board";
+	compatible = "marvell,axp-db", "marvell,armadaxp", "marvell,armada";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x20000000>; /* 512 MB */
+	};
+
+	soc {
+		serial at d0012000 {
+			clock-frequency = <250000000>;
+		};
+		serial at d0012100 {
+			clock-frequency = <250000000>;
+		};
+	};
+};
arch/arm/mach-armada/Kconfig +6 -0
index 7995813..2903096 100644
@@ -8,6 +8,12 @@ config MACH_ARMADA_370_DT
 	  Say 'Y' here if you want your kernel to support
 	  boards based on Marvell Armada 370 with device tree.
 
+config MACH_ARMADA_XP_DT
+	bool "Marvell Armada XP boards with device-tree support"
+	help
+	  Say 'Y' here if you want your kernel to support
+	  boards based on Marvell Armada XP with device tree.
+
 endmenu
 
 endif
arch/arm/mach-armada/Makefile +1 -1
index ac39fae..7a3c438 100644
@@ -1,3 +1,3 @@
 obj-y += common.o irq.o time.o
 obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o
-
+obj-$(CONFIG_MACH_ARMADA_XP_DT)	 += axp-dt.o
arch/arm/mach-armada/axp-dt.c new file +41 -0

41 lines not on this page · raw message

Signature · 1 line
1.7.9.5
#26 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

arch/arm/boot/dts/axp-db.dts

Quoted 19 lines · Thomas Petazzoni

From: Gregory CLEMENT<[email protected]>

---
  arch/arm/boot/dts/axp-db.dts  |   40 ++++++++++++++++++++++++++++++++++++++++
  arch/arm/mach-armada/Kconfig  |    6 ++++++
  arch/arm/mach-armada/Makefile |    2 +-
  arch/arm/mach-armada/axp-dt.c |   41 +++++++++++++++++++++++++++++++++++++++++
  4 files changed, 88 insertions(+), 1 deletion(-)

create mode 100644 arch/arm/boot/dts/axp-db.dts create mode 100644 arch/arm/mach-armada/axp-dt.c

arch/arm/boot/dts/axp-db.dts new file +0 -0
new file mode 100644
index 0000000..916be09

see previous comments.

Quoted 52 lines
arch/arm/mach-armada/Kconfig +6 -0
index 7995813..2903096 100644
@@ -8,6 +8,12 @@ config MACH_ARMADA_370_DT
  	  Say 'Y' here if you want your kernel to support
  	  boards based on Marvell Armada 370 with device tree.
 
+config MACH_ARMADA_XP_DT
+	bool "Marvell Armada XP boards with device-tree support"
+	help
+	  Say 'Y' here if you want your kernel to support
+	  boards based on Marvell Armada XP with device tree.
+
  endmenu
 
  endif
arch/arm/mach-armada/Makefile +1 -1
index ac39fae..7a3c438 100644
@@ -1,3 +1,3 @@
  obj-y += common.o irq.o time.o
  obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o
-
+obj-$(CONFIG_MACH_ARMADA_XP_DT)	 += axp-dt.o
arch/arm/mach-armada/axp-dt.c new file +20 -0
new file mode 100644
index 0000000..2c13d4e
@@ -0,0 +1,41 @@
+/*
+ * Device Tree support for Armada XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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<asm/mach-types.h>
+#include<asm/mach/arch.h>
+#include<mach/armada.h>

arch/arm/mach-armada/axp-dt.c line 30

Quoted 10 lines
arch/arm/mach-armada/axp-dt.c new file +10 -0
+#include "common.h"
+
+static void __init axp_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char * const axp_dt_board_dt_compat[] = {
+	"marvell,axp-db",
+	NULL,

This is where the device support becomes confusing.

I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.

Also, given how close they are, do we really need separate machine support files?

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#27 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 101 lines

-----Original Message-----
From: Ben Dooks [mailto:ben.dooks at codethink.co.uk]
Sent: Tuesday, May 15, 2012 12:58 PM
To: Thomas Petazzoni
Cc: Arnd Bergmann; Olof Johansson; Lior Amsalem; Andrew Lunn; Jason Cooper; Nicolas Pitre; Maen Suleiman; Ben Dooks; Gregory CLEMENT; linux- arm-kernel at lists.infradead.org
Subject: Re: [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree

Quoted 7 lines · Thomas Petazzoni

From: Gregory CLEMENT<[email protected]>

---
  arch/arm/boot/dts/axp-db.dts  |   40

++++++++++++++++++++++++++++++++++++++++

Quoted 3 lines
  arch/arm/mach-armada/Kconfig  |    6 ++++++
  arch/arm/mach-armada/Makefile |    2 +-
  arch/arm/mach-armada/axp-dt.c |   41

+++++++++++++++++++++++++++++++++++++++++

arch/arm/boot/dts/axp-db.dts

Quoted 9 lines
  4 files changed, 88 insertions(+), 1 deletion(-)

create mode 100644 arch/arm/boot/dts/axp-db.dts create mode 100644 arch/arm/mach-armada/axp-dt.c

(quoted diff) +0 -0

b/arch/arm/boot/dts/axp-db.dts new file mode 100644 index 0000000..916be09

arch/arm/boot/dts/axp-db.dts new file +0 -0

see previous comments.

Quoted 47 lines
(quoted diff) +0 -0

b/arch/arm/mach-armada/Kconfig index 7995813..2903096 100644

arch/arm/mach-armada/Kconfig +6 -0
@@ -8,6 +8,12 @@ config MACH_ARMADA_370_DT
  	  Say 'Y' here if you want your kernel to support
  	  boards based on Marvell Armada 370 with device tree.
 
+config MACH_ARMADA_XP_DT
+	bool "Marvell Armada XP boards with device-tree support"
+	help
+	  Say 'Y' here if you want your kernel to support
+	  boards based on Marvell Armada XP with device tree.
+
  endmenu
 
  endif
(quoted diff) +0 -0

b/arch/arm/mach-armada/Makefile index ac39fae..7a3c438 100644

arch/arm/mach-armada/Makefile +1 -1
@@ -1,3 +1,3 @@
  obj-y += common.o irq.o time.o
  obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o
-
+obj-$(CONFIG_MACH_ARMADA_XP_DT)	 += axp-dt.o
(quoted diff) +0 -0

b/arch/arm/mach-armada/axp-dt.c new file mode 100644 index 0000000..2c13d4e

arch/arm/mach-armada/axp-dt.c new file +15 -0
@@ -0,0 +1,41 @@
+/*
+ * Device Tree support for Armada XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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>

arch/arm/mach-armada/axp-dt.c line 25

Quoted 10 lines
arch/arm/mach-armada/axp-dt.c new file +10 -0
+#include<linux/init.h>
+#include<linux/of_platform.h>
+#include<asm/mach-types.h>
+#include<asm/mach/arch.h>
+#include<mach/armada.h>
+#include "common.h"
+
+static void __init axp_dt_init(void)
+{
+	of_platform_populate(NULL, of_default_bus_match_table, NULL,

NULL);

arch/arm/mach-armada/axp-dt.c line 30

Quoted 5 lines
arch/arm/mach-armada/axp-dt.c new file +5 -0
+}
+
+static const char * const axp_dt_board_dt_compat[] = {
+	"marvell,axp-db",
+	NULL,

This is where the device support becomes confusing.

Quoted 5 lines

I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.

Also, given how close they are, do we really need separate machine support files?

The problem with 78230 is that it's only one flavor of the AXP family which includes 78230, 78260 and 78460 resulting different core count, L2 size, DRAM bandwidth, etc.

Quoted 4 lines

--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius

Lior Amsalem

maintainer
#28 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 7 lines
Quoted 5 lines

I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.

Also, given how close they are, do we really need separate machine support files?

The problem with 78230 is that it's only one flavor of the AXP family which includes 78230, 78260 and 78460 resulting different core count, L2 size, DRAM bandwidth, etc.

Can you explain the naming scheme and mapping to device numbers? Please don't limit it to these new devices, but also include the existing supported devices. From that we might be able to figure out and appropriate naming scheme.

Thanks
Andrew

#29 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 5 lines · Andrew Lunn
Quoted 5 lines
Quoted 5 lines

I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.

Also, given how close they are, do we really need separate machine support files?

Quoted 7 lines
Quoted 2 lines

The problem with 78230 is that it's only one flavor of the AXP family which includes 78230, 78260 and 78460 resulting different core count, L2 size, DRAM bandwidth, etc.

Can you explain the naming scheme and mapping to device numbers? Please don't limit it to these new devices, but also include the existing supported devices. From that we might be able to figure out and appropriate naming scheme.

The names and numbers are already extremely confusing in the code we have. Maybe we can use the addition of the new code as an excuse to clean up what we have ;-)

I agree that "armada" is a rather bad choice, because chips under that name include both the pxa/mmp family and the orion/kirkwood/mv78xx0/dove family which AFAICT don't have much in common at all besides the CPU cores.

One option would be to move all DT-enabled board files under plat-orion once they are fully done, and leave just the non-DT board files in the individual directories until they have all been converted. We can start with the platform code that's being discussed here and move over the kirkwood and orion5x board-dt.c files once they don't depend on anything else in those directories any more.

Arnd

maintainer
#30 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 3 lines · Arnd Bergmann

I agree that "armada" is a rather bad choice, because chips under that name include both the pxa/mmp family and the orion/kirkwood/mv78xx0/dove family which AFAICT don't have much in common at all besides the CPU cores.

Oh, right. I remember now. Scrap my earlier suggestion then. Armada came out of Marvell's marketing dept, not the engineering dept.

Maybe we should just go with mach-mrvl_ebu and eventually move orion5x, kirkwood, dove, and friends in there. Why "ebu"? Because that's the internal Marvell name for the division that produced all those SOCs, hence their similarities, whereas PXA/MMP SOCs came from Intel initially.

Nicolas

#31 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Arnd Bergmann
Quoted 10 lines · Arnd Bergmann
Quoted 9 lines · Andrew Lunn
Quoted 8 lines
Quoted 5 lines

I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.

Also, given how close they are, do we really need separate machine support files?

The problem with 78230 is that it's only one flavor of the AXP family which includes 78230, 78260 and 78460 resulting different core count, L2 size, DRAM bandwidth, etc.

Quoted 8 lines
Quoted 4 lines

Can you explain the naming scheme and mapping to device numbers? Please don't limit it to these new devices, but also include the existing supported devices. From that we might be able to figure out and appropriate naming scheme.

The names and numbers are already extremely confusing in the code we have. Maybe we can use the addition of the new code as an excuse to clean up what we have ;-)

Agreed.

Quoted 10 lines

I agree that "armada" is a rather bad choice, because chips under that name include both the pxa/mmp family and the orion/kirkwood/mv78xx0/dove family which AFAICT don't have much in common at all besides the CPU cores.

One option would be to move all DT-enabled board files under plat-orion once they are fully done, and leave just the non-DT board files in the individual directories until they have all been converted. We can start with the platform code that's being discussed here and move over the kirkwood and orion5x board-dt.c files once they don't depend on anything else in those directories any more.

I wish we had thought of this a few months ago... ;-)

thx,

Jason.

#32 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Lior Amsalem
Quoted 8 lines · Lior Amsalem
Quoted 8 lines

arch/arm/mach-armada/axp-dt.c line 30

Quoted 5 lines
arch/arm/mach-armada/axp-dt.c new file +5 -0
+}
+
+static const char * const axp_dt_board_dt_compat[] = {
+	"marvell,axp-db",
+	NULL,

This is where the device support becomes confusing.

Quoted 7 lines
Quoted 5 lines

I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.

Also, given how close they are, do we really need separate machine support files?

The problem with 78230 is that it's only one flavor of the AXP family which includes 78230, 78260 and 78460 resulting different core count, L2 size, DRAM bandwidth, etc.

The number of cores is discoverable from the cpu scu and the rest should either be encoded into the device-tree as either specific device names or node properties.

I would try and involve the _minimum_ number of additions to get the system up and running.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#33 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Ben Dooks
Quoted 92 lines · Ben Dooks

arch/arm/boot/dts/axp-db.dts

Quoted 21 lines · Thomas Petazzoni

From: Gregory CLEMENT<[email protected]>

---
  arch/arm/boot/dts/axp-db.dts  |   40
++++++++++++++++++++++++++++++++++++++++
  arch/arm/mach-armada/Kconfig  |    6 ++++++
  arch/arm/mach-armada/Makefile |    2 +-
  arch/arm/mach-armada/axp-dt.c |   41
+++++++++++++++++++++++++++++++++++++++++
  4 files changed, 88 insertions(+), 1 deletion(-)

create mode 100644 arch/arm/boot/dts/axp-db.dts create mode 100644 arch/arm/mach-armada/axp-dt.c

arch/arm/boot/dts/axp-db.dts new file +0 -0
new file mode 100644
index 0000000..916be09

see previous comments.

Quoted 54 lines
arch/arm/mach-armada/Kconfig +6 -0
index 7995813..2903096 100644
@@ -8,6 +8,12 @@ config MACH_ARMADA_370_DT
        Say 'Y' here if you want your kernel to support
        boards based on Marvell Armada 370 with device tree.
 
+config MACH_ARMADA_XP_DT
+    bool "Marvell Armada XP boards with device-tree support"
+    help
+      Say 'Y' here if you want your kernel to support
+      boards based on Marvell Armada XP with device tree.
+
  endmenu
 
  endif
arch/arm/mach-armada/Makefile +1 -1
index ac39fae..7a3c438 100644
@@ -1,3 +1,3 @@
  obj-y += common.o irq.o time.o
  obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o
-
+obj-$(CONFIG_MACH_ARMADA_XP_DT)     += axp-dt.o
arch/arm/mach-armada/axp-dt.c new file +20 -0
new file mode 100644
index 0000000..2c13d4e
@@ -0,0 +1,41 @@
+/*
+ * Device Tree support for Armada XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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<asm/mach-types.h>
+#include<asm/mach/arch.h>
+#include<mach/armada.h>

arch/arm/mach-armada/axp-dt.c line 30

Quoted 10 lines
arch/arm/mach-armada/axp-dt.c new file +10 -0
+#include "common.h"
+
+static void __init axp_dt_init(void)
+{
+    of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char * const axp_dt_board_dt_compat[] = {
+    "marvell,axp-db",
+    NULL,

This is where the device support becomes confusing.

Quoted 3 lines

I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.

The name here should uniquely identify the board, not the chip. If you additionally want to have the chip name, then that should be after the board name. However, "marvell,armada" is too generic to be useful.

marvell is the documented vendor string, not mrvl.

Quoted 2 lines

Also, given how close they are, do we really need separate machine support files?

There does need to be justification why they need to be separate.

Rob

#34 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 97 lines · Rob Herring
Quoted 92 lines · Ben Dooks

arch/arm/boot/dts/axp-db.dts

Quoted 21 lines · Thomas Petazzoni

From: Gregory CLEMENT<[email protected]>

---
   arch/arm/boot/dts/axp-db.dts  |   40
++++++++++++++++++++++++++++++++++++++++
   arch/arm/mach-armada/Kconfig  |    6 ++++++
   arch/arm/mach-armada/Makefile |    2 +-
   arch/arm/mach-armada/axp-dt.c |   41
+++++++++++++++++++++++++++++++++++++++++
   4 files changed, 88 insertions(+), 1 deletion(-)

create mode 100644 arch/arm/boot/dts/axp-db.dts create mode 100644 arch/arm/mach-armada/axp-dt.c

arch/arm/boot/dts/axp-db.dts new file +0 -0
new file mode 100644
index 0000000..916be09

see previous comments.

Quoted 54 lines
arch/arm/mach-armada/Kconfig +6 -0
index 7995813..2903096 100644
@@ -8,6 +8,12 @@ config MACH_ARMADA_370_DT
         Say 'Y' here if you want your kernel to support
         boards based on Marvell Armada 370 with device tree.
 
+config MACH_ARMADA_XP_DT
+    bool "Marvell Armada XP boards with device-tree support"
+    help
+      Say 'Y' here if you want your kernel to support
+      boards based on Marvell Armada XP with device tree.
+
   endmenu
 
   endif
arch/arm/mach-armada/Makefile +1 -1
index ac39fae..7a3c438 100644
@@ -1,3 +1,3 @@
   obj-y += common.o irq.o time.o
   obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o
-
+obj-$(CONFIG_MACH_ARMADA_XP_DT)     += axp-dt.o
arch/arm/mach-armada/axp-dt.c new file +20 -0
new file mode 100644
index 0000000..2c13d4e
@@ -0,0 +1,41 @@
+/*
+ * Device Tree support for Armada XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem<[email protected]>
+ * Gregory CLEMENT<[email protected]>
+ * Thomas Petazzoni<[email protected]>
+ *
+ * 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<asm/mach-types.h>
+#include<asm/mach/arch.h>
+#include<mach/armada.h>

arch/arm/mach-armada/axp-dt.c line 30

Quoted 10 lines
arch/arm/mach-armada/axp-dt.c new file +10 -0
+#include "common.h"
+
+static void __init axp_dt_init(void)
+{
+    of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char * const axp_dt_board_dt_compat[] = {
+    "marvell,axp-db",
+    NULL,

This is where the device support becomes confusing.

Quoted 3 lines

I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.

Quoted 5 lines

The name here should uniquely identify the board, not the chip. If you additionally want to have the chip name, then that should be after the board name. However, "marvell,armada" is too generic to be useful.

marvell is the documented vendor string, not mrvl.

I could swear I read it as mrvl in the documentation for device-tree

Quoted 4 lines
Quoted 2 lines

Also, given how close they are, do we really need separate machine support files?

There does need to be justification why they need to be separate.

I'd say for the "core" support that they could all be handled by this case catching the "marvell,mv...." and initialising all the core bits such as timer, io, irq, etc.

Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#35 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks <[email protected]> a ?crit :

Quoted 3 lines

Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.

The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:

* Maybe those mappings can be done using a normal ioremap() rather than in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)

* We probably shouldn't have anticipated this too much, and keep only one file for this initial submission.

We'll rework this for our v2.

Thanks for the comments!

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#36 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 7 lines · Thomas Petazzoni

Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks <[email protected]> a ?crit :

Quoted 3 lines

Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.

Quoted 8 lines

The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:

* Maybe those mappings can be done using a normal ioremap() rather than in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)

I'm pretty sure we can use ioremap for new PCI implementations now. Also, you can scan the device tree in map_io() if necesary, to see which PCIe ports are enabled.

Arnd

#37 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Le Tue, 15 May 2012 14:25:30 +0000,
Arnd Bergmann <[email protected]> a ?crit :

Quoted 3 lines

I'm pretty sure we can use ioremap for new PCI implementations now. Also, you can scan the device tree in map_io() if necesary, to see which PCIe ports are enabled.

Great. We'll work on that before submitting the PCIe bits.

Thanks,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#38 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Arnd Bergmann
Quoted 12 lines · Arnd Bergmann
Quoted 11 lines · Thomas Petazzoni

Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks<[email protected]> a ?crit :

Quoted 3 lines

Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.

The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:

Quoted 8 lines
Quoted 4 lines

* Maybe those mappings can be done using a normal ioremap() rather

    than in ->map_io(), according to DT informations (but most other ARM
    SoC support at the moment seem to do PCI mappings using static
    mappings in ->map_io)

I'm pretty sure we can use ioremap for new PCI implementations now. Also, you can scan the device tree in map_io() if necesary, to see which PCIe ports are enabled.

To be honest, if you need it, then it'd be a good idea to fix anyway.

And at worst you can always construct map_desc entries on the stack and call iotable_init()

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#39 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Arnd Bergmann
Quoted 12 lines · Arnd Bergmann
Quoted 11 lines · Thomas Petazzoni

Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks <[email protected]> a ?crit :

Quoted 3 lines

Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.

The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:

Quoted 8 lines
Quoted 4 lines

* Maybe those mappings can be done using a normal ioremap() rather than in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)

I'm pretty sure we can use ioremap for new PCI implementations now. Also, you can scan the device tree in map_io() if necesary, to see which PCIe ports are enabled.

For the i/o windows, they should be static because we want a fixed virtual address across platforms. 0xfef00000 is the planned address. Memory windows should be ioremap.

Rob

#40 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 18 lines · Rob Herring
Quoted 17 lines · Arnd Bergmann
Quoted 15 lines · Thomas Petazzoni

Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks<[email protected]> a ?crit :

Quoted 3 lines

Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.

The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:

* Maybe those mappings can be done using a normal ioremap() rather

    than in ->map_io(), according to DT informations (but most other ARM
    SoC support at the moment seem to do PCI mappings using static
    mappings in ->map_io)
Quoted 7 lines
Quoted 3 lines

I'm pretty sure we can use ioremap for new PCI implementations now. Also, you can scan the device tree in map_io() if necesary, to see which PCIe ports are enabled.

For the i/o windows, they should be static because we want a fixed virtual address across platforms. 0xfef00000 is the planned address. Memory windows should be ioremap.

It might be worth looking at changing ioremap() to work nicely with large page entries if it hasn't already been done.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#41 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 2 lines · Ben Dooks

It might be worth looking at changing ioremap() to work nicely with large page entries if it hasn't already been done.

It's already been done, but not for SMP systems. There's issues there which make that racy and horrible.

#42 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Thomas Petazzoni
Quoted 10 lines · Thomas Petazzoni

Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks<[email protected]> a ?crit :

Quoted 3 lines

Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.

The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:

Yes, the number of times I've viewed the kernel and seen very similar code replicated multiple times tends to make me burst into tears.

Quoted 4 lines

* Maybe those mappings can be done using a normal ioremap() rather

    than in ->map_io(), according to DT informations (but most other ARM
    SoC support at the moment seem to do PCI mappings using static
    mappings in ->map_io)

That's a very old way of doing it. I'm pretty sure there's no reason to get these allocated so early.

I believe you can probably leave the PCI/PCIe bindings until you have enough kernel state to do ioremap() or similar and then associate the necessary mappings with the bus creation.

Quoted 2 lines

* We probably shouldn't have anticipated this too much, and keep only one file for this initial submission.

Yes, the less we need to review the better.

Quoted 1 line

We'll rework this for our v2.

Great.

Quoted 1 line

Thanks for the comments!

I'll get to testing this kernel soon, and report back

Quoted 1 line

Thomas

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#43 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 6 lines · Ben Dooks
Quoted 4 lines

* Maybe those mappings can be done using a normal ioremap() rather

    than in ->map_io(), according to DT informations (but most other ARM
    SoC support at the moment seem to do PCI mappings using static
    mappings in ->map_io)

That's a very old way of doing it. I'm pretty sure there's no reason to get these allocated so early.

Well, you might actually still want to use static mappings for any large areas that are accessed a lot in the kernel, because that lets you use larger page TLB entries, which ioremap by itself cannot. The host driver should however still use ioremap, it will now just get the area that was set up with map_io.

Quoted 3 lines

I believe you can probably leave the PCI/PCIe bindings until you have enough kernel state to do ioremap() or similar and then associate the necessary mappings with the bus creation.

I think it was Stephen Warrent who told me that he can actually do a PCI host driver as a loadable module now, with only a few changes in the ARM core code.

Arnd

#44 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 14 lines · Arnd Bergmann
Quoted 6 lines · Ben Dooks
Quoted 4 lines

* Maybe those mappings can be done using a normal ioremap() rather

    than in ->map_io(), according to DT informations (but most other ARM
    SoC support at the moment seem to do PCI mappings using static
    mappings in ->map_io)

That's a very old way of doing it. I'm pretty sure there's no reason to get these allocated so early.

Well, you might actually still want to use static mappings for any large areas that are accessed a lot in the kernel, because that lets you use larger page TLB entries, which ioremap by itself cannot. The host driver should however still use ioremap, it will now just get the area that was set up with map_io.

Quoted 7 lines
Quoted 3 lines

I believe you can probably leave the PCI/PCIe bindings until you have enough kernel state to do ioremap() or similar and then associate the necessary mappings with the bus creation.

I think it was Stephen Warrent who told me that he can actually do a PCI host driver as a loadable module now, with only a few changes in the ARM core code.

Thierry Redding was working on this (actually, perhaps PCIe as a platform driver rather than as a module, but I'm not sure) in the context of the Tegra PCIe driver. See some of the patches at
http://patchwork.ozlabs.org/project/linux-tegra/list/, e.g. "PCI: Keep pci_fixup_irqs() around after init" and "ARM: pci: Keep pci_common_init() around after init" IIRC.

#45 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 6 lines · Stephen Warren

Thierry Redding was working on this (actually, perhaps PCIe as a platform driver rather than as a module, but I'm not sure) in the context of the Tegra PCIe driver. See some of the patches at
http://patchwork.ozlabs.org/project/linux-tegra/list/, e.g. "PCI: Keep pci_fixup_irqs() around after init" and "ARM: pci: Keep pci_common_init() around after init" IIRC.

Ah, right. Thanks for the clarification.

Arnd

#46 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Ben Dooks

Le Tue, 15 May 2012 15:32:36 +0100,
Ben Dooks <[email protected]> a ?crit :

Quoted 8 lines

Yes, the number of times I've viewed the kernel and seen very similar code replicated multiple times tends to make me burst into tears.

Quoted 4 lines

* Maybe those mappings can be done using a normal ioremap() rather

    than in ->map_io(), according to DT informations (but most

other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)

Quoted 6 lines

That's a very old way of doing it. I'm pretty sure there's no reason to get these allocated so early.

I believe you can probably leave the PCI/PCIe bindings until you have enough kernel state to do ioremap() or similar and then associate the necessary mappings with the bus creation.

Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?

Quoted 4 lines
Quoted 2 lines

* We probably shouldn't have anticipated this too much, and keep
only one file for this initial submission.

Yes, the less we need to review the better.

We've tried to minimize as much as possible the amount of code for this initial submission. We already have some code for PCI, L2 cache support, network driver, etc, but we wanted to limit ourselves to the strict minimum to get a kernel booting with an initramfs based root filesystem.

Quoted 3 lines
Quoted 1 line

Thanks for the comments!

I'll get to testing this kernel soon, and report back

Excellent, thanks!

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#47 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 14 lines · Thomas Petazzoni

Le Tue, 15 May 2012 15:32:36 +0100,
Ben Dooks<[email protected]> a ?crit :

Quoted 11 lines

Yes, the number of times I've viewed the kernel and seen very similar code replicated multiple times tends to make me burst into tears.

Quoted 4 lines

* Maybe those mappings can be done using a normal ioremap() rather

     than in ->map_io(), according to DT informations (but most

other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)

That's a very old way of doing it. I'm pretty sure there's no reason to get these allocated so early.

Quoted 7 lines
Quoted 3 lines

I believe you can probably leave the PCI/PCIe bindings until you have enough kernel state to do ioremap() or similar and then associate the necessary mappings with the bus creation.

Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?

I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#48 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 9 lines · Ben Dooks
Quoted 4 lines

Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?

I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.

No, as Rob pointed out, we might not need them early, but we definitely want a fixed address for the PIO window, which ioremap does not provide.

Arnd

#49 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Le Tue, 15 May 2012 15:32:20 +0000,
Arnd Bergmann <[email protected]> a ?crit :

Quoted 11 lines
Quoted 7 lines
Quoted 3 lines

Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?

I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.

No, as Rob pointed out, we might not need them early, but we definitely want a fixed address for the PIO window, which ioremap does not provide.

A fixed address for the PIO window of the PCI registers? Or a fixed address for the PIO window used to access UART registers?

I would understand why a fixed address is needed for the latter, but not really for the former.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#50 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 15 lines · Thomas Petazzoni

Le Tue, 15 May 2012 15:32:20 +0000,
Arnd Bergmann <[email protected]> a ?crit :

Quoted 11 lines
Quoted 7 lines
Quoted 3 lines

Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?

I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.

No, as Rob pointed out, we might not need them early, but we definitely want a fixed address for the PIO window, which ioremap does not provide.

Quoted 6 lines

A fixed address for the PIO window of the PCI registers? Or a fixed address for the PIO window used to access UART registers?

I would understand why a fixed address is needed for the latter, but not really for the former.

I'm not sure which PCI registers you mean, but we're talking about PCI I/O space. The i/o space should be a fixed virtual address so that the __io() is a constant base for ALL arm platforms. This isn't in place yet, but that is the plan. Although current macros are constant base.

Rob

#51 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Arnd Bergmann
Quoted 6 lines · Arnd Bergmann
Quoted 5 lines · Ben Dooks
Quoted 4 lines

Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?

Quoted 8 lines
Quoted 4 lines

I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.

No, as Rob pointed out, we might not need them early, but we definitely want a fixed address for the PIO window, which ioremap does not provide.

Yes, I can see a not a lot of fun with multiple PCIe busses and the need for a single IO space. You'll probably have to reserve a VM area for people to use for legacy-IO accesses.

With PCIe, there should be less old-style IO as PCIe devices are encouraged to go 32bit MMIO.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#52 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 3 lines · Ben Dooks

Yes, I can see a not a lot of fun with multiple PCIe busses and the need for a single IO space. You'll probably have to reserve a VM area for people to use for legacy-IO accesses.

Yes, that is the plan, across all platforms in the long run actually.

Quoted 2 lines

With PCIe, there should be less old-style IO as PCIe devices are encouraged to go 32bit MMIO.

It should work nonetheless.

arnd

#53 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Ben Dooks
Quoted 3 lines · Ben Dooks

I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.

No. PCI needs nothing other than access to the configuration space, and the PCI IO window. There has _never_ been any hard requirement to map PCI memory in map_io() because that is _always_ done by drivers calling ioremap().

There is one exception to this: if you have a VGA card in a PCI slot, it appears by default as an ISA peripheral with the VGA memory appearing at around PCI_MEM_BASE + 640K or so. Linux expects that to already be mapped.

If you're not supporting VGA cards in text mode, that detail doesn't concern you.

#54 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 9 lines · Russell King - ARM Linux
Quoted 3 lines · Ben Dooks

I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.

No. PCI needs nothing other than access to the configuration space, and the PCI IO window. There has _never_ been any hard requirement to map PCI memory in map_io() because that is _always_ done by drivers calling ioremap().

What about inb, outb and their related functions?

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#55 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 6 lines · Ben Dooks
Quoted 5 lines · Russell King - ARM Linux
Quoted 3 lines · Ben Dooks

I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.

Quoted 6 lines
Quoted 4 lines

No. PCI needs nothing other than access to the configuration space, and the PCI IO window. There has _never_ been any hard requirement to map PCI memory in map_io() because that is _always_ done by drivers calling ioremap().

What about inb, outb and their related functions?

I said:
| No. PCI needs nothing other than access to the configuration space, and

       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

| the PCI IO window.
^^^^^^^^^^^^^^^^^^

And, as everyone should know, inb(), outb() etc are the PCI/ISA IO accessors. So... if you have the PCI IO window mapped, then inb() et.al. use _that_ window and there isn't a problem.

#56 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

In reply to Rob Herring
Quoted 1 line · Rob Herring

marvell is the documented vendor string, not mrvl.

When Arnd and I were adding the initial kirkwood support for devicetree, the common wisdom was to use the stock ticker symbol when available. Hence, mrvl, iom, and dlink (only on taiwanese exchange, which uses numbers)...

thx,

Jason.

#57 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 7 lines · Jason Cooper
Quoted 1 line · Rob Herring

marvell is the documented vendor string, not mrvl.

When Arnd and I were adding the initial kirkwood support for devicetree, the common wisdom was to use the stock ticker symbol when available. Hence, mrvl, iom, and dlink (only on taiwanese exchange, which uses numbers)...

Yes, that's true. But consistency is more important. If we have cases of both, then one needs to be deprecated.

Rob

#58 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 11 lines · Rob Herring
Quoted 7 lines · Jason Cooper
Quoted 1 line · Rob Herring

marvell is the documented vendor string, not mrvl.

When Arnd and I were adding the initial kirkwood support for devicetree, the common wisdom was to use the stock ticker symbol when available. Hence, mrvl, iom, and dlink (only on taiwanese exchange, which uses numbers)...

Yes, that's true. But consistency is more important. If we have cases of both, then one needs to be deprecated.

I'd go for "should" instead of "needs". I would say it would be nice to settle on marvell.

There are already instances of "mrvl" in the kernel, see

	drivers/i2c/busses/i2c-pxa.c
	drivers/tty/serial/pxa.c
	drivers/rtc/rtc-mv.c
	drivers/rtc/rtc-sa1100.c

Do people mind if the original compatibilities are left in to avoid having to rename .dts file contents, or are we happy to go with just "marvell"?

Also, it seems that some of the marvell bluetooth firmware is defined to be mrvl prefixed.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#59 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 10 lines · Ben Dooks
Quoted 9 lines · Rob Herring
Quoted 7 lines · Jason Cooper
Quoted 1 line · Rob Herring

marvell is the documented vendor string, not mrvl.

When Arnd and I were adding the initial kirkwood support for devicetree, the common wisdom was to use the stock ticker symbol when available. Hence, mrvl, iom, and dlink (only on taiwanese exchange, which uses numbers)...

Quoted 5 lines
Quoted 2 lines

Yes, that's true. But consistency is more important. If we have cases of both, then one needs to be deprecated.

I'd go for "should" instead of "needs". I would say it would be nice to settle on marvell.

Looking back on it, when Arnd and I were discussing this, I should have voiced my concerns. Stock ticker symbols are concise, unique, and generally recognizable. However, not all companies are publicly traded, nor do all stock exchanges use english contractions/abbreviations. The taiwanese stock exchange, for example, uses numerical identifiers.

Quoted 6 lines

There are already instances of "mrvl" in the kernel, see

	drivers/i2c/busses/i2c-pxa.c
	drivers/tty/serial/pxa.c
	drivers/rtc/rtc-mv.c
	drivers/rtc/rtc-sa1100.c

drivers with dt bindings are easy to maintain reverse compatibility:

drivers/rtc/rtc-mv.c +0 -0
index b2185f4..de7b231 100644
@@ -298,6 +298,7 @@ static int __exit mv_rtc_remove(struct

platform_device *pdev)
#ifdef CONFIG_OF

 static struct of_device_id rtc_mv_of_match_table[] = {
        { .compatible = "mrvl,orion-rtc", },
+       { .compatible = "marvell,orion-rtc", },
        {}

};
#endif

If that ends up being necessary.

Quoted 3 lines

Do people mind if the original compatibilities are left in to avoid having to rename .dts file contents, or are we happy to go with just "marvell"?

The kirkwood DT support is young enough, I think, that everyone using it is also compiling/hacking/tweaking on it. So, if we are going to change it, now's the time.

Quoted 2 lines

Also, it seems that some of the marvell bluetooth firmware is defined to be mrvl prefixed.

It would seem you are finding a lot of evidence for "mrvl" to be preferred. So, I started digging. There's quite a bit where "marvell" is preferred:

$ git grep -l [^@]marvell,
	Documentation/devicetree/bindings/marvell.txt
	Documentation/devicetree/bindings/net/mdio-mux-gpio.txt
	Documentation/devicetree/bindings/net/mdio-mux.txt
	arch/powerpc/boot/cuboot-c2k.c
	arch/powerpc/boot/dts/c2k.dts
	arch/powerpc/boot/dts/prpmc2800.dts
	arch/powerpc/boot/mv64x60.c
	arch/powerpc/boot/mv64x60_i2c.c
	arch/powerpc/boot/prpmc2800.c
	arch/powerpc/boot/serial.c
	arch/powerpc/platforms/embedded6xx/c2k.c
	arch/powerpc/platforms/embedded6xx/prpmc2800.c
	arch/powerpc/sysdev/mv64x60_dev.c
	arch/powerpc/sysdev/mv64x60_pci.c
	arch/powerpc/sysdev/mv64x60_pic.c
	arch/powerpc/sysdev/mv64x60_udbg.c
	drivers/net/phy/marvell.c

And, just to compare apples to apples:

$ git grep -l [^@]mrvl,
	Documentation/devicetree/bindings/arm/mrvl.txt
	Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
	Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
	Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
	Documentation/devicetree/bindings/serial/mrvl-serial.txt
	arch/arm/boot/dts/kirkwood-dreamplug.dts
	arch/arm/boot/dts/kirkwood.dtsi
	arch/arm/boot/dts/pxa168-aspenite.dts
	arch/arm/boot/dts/pxa168.dtsi
	arch/arm/mach-mmp/mmp-dt.c
	drivers/i2c/busses/i2c-pxa.c
	drivers/rtc/rtc-mv.c
	drivers/rtc/rtc-sa1100.c
	drivers/tty/serial/pxa.c

So, basically, the powerpc folks have been using "marvell", and now we're trying to change it to "mrvl".

I can't think of a technical reason to prefer one over the other. So, based purely on compatibility and uniformity, I'd say stick with "marvell". Grant, Arnd, is there something we're missing?

thx,

Jason.

#60 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 17 lines · Jason Cooper
$ git grep -l [^@]mrvl,
        Documentation/devicetree/bindings/arm/mrvl.txt
        Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
        Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
        Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
        Documentation/devicetree/bindings/serial/mrvl-serial.txt
        arch/arm/boot/dts/kirkwood-dreamplug.dts
        arch/arm/boot/dts/kirkwood.dtsi
        arch/arm/boot/dts/pxa168-aspenite.dts
        arch/arm/boot/dts/pxa168.dtsi
        arch/arm/mach-mmp/mmp-dt.c
        drivers/i2c/busses/i2c-pxa.c
        drivers/rtc/rtc-mv.c
        drivers/rtc/rtc-sa1100.c
        drivers/tty/serial/pxa.c
Quoted 7 lines

So, basically, the powerpc folks have been using "marvell", and now we're trying to change it to "mrvl".

I can't think of a technical reason to prefer one over the other. So, based purely on compatibility and uniformity, I'd say stick with "marvell". Grant, Arnd, is there something we're missing?

A few are now getting merged into v3.5:

$ git grep -l [^@]mrvl,
Documentation/devicetree/bindings/arm/mrvl/intc.txt
Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
Documentation/devicetree/bindings/arm/mrvl/timer.txt
Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
Documentation/devicetree/bindings/mtd/orion-nand.txt
Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
Documentation/devicetree/bindings/serial/mrvl-serial.txt
arch/arm/boot/dts/kirkwood-dns320.dts
arch/arm/boot/dts/kirkwood-dns325.dts
arch/arm/boot/dts/kirkwood-dreamplug.dts
arch/arm/boot/dts/kirkwood-ib62x0.dts
arch/arm/boot/dts/kirkwood-iconnect.dts
arch/arm/boot/dts/kirkwood.dtsi
arch/arm/boot/dts/mmp2-brownstone.dts
arch/arm/boot/dts/mmp2.dtsi
arch/arm/boot/dts/pxa168-aspenite.dts
arch/arm/boot/dts/pxa168.dtsi
arch/arm/boot/dts/pxa910-dkb.dts
arch/arm/boot/dts/pxa910.dtsi
arch/arm/mach-mmp/irq.c
arch/arm/mach-mmp/mmp-dt.c
arch/arm/mach-mmp/mmp2-dt.c
arch/arm/mach-mmp/time.c
drivers/gpio/gpio-pxa.c
drivers/i2c/busses/i2c-pxa.c
drivers/mtd/nand/orion_nand.c
drivers/rtc/rtc-mv.c
drivers/rtc/rtc-sa1100.c
drivers/tty/serial/pxa.c

I'm fine with changing all of them from mrvl to marvell, if one of you makes a patch, I think we can send that after all the other stuff is merged.

This also needs an Ack from Haojian Zhuang, who has submitted the pxa/mmp related patches adding more "mrvl," prefixes.

Arnd

#61 lore raw

PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree

Quoted 60 lines · Arnd Bergmann
Quoted 17 lines · Jason Cooper
$ git grep -l [^@]mrvl,

? ? ? ? Documentation/devicetree/bindings/arm/mrvl.txt ? ? ? ? Documentation/devicetree/bindings/gpio/mrvl-gpio.txt ? ? ? ? Documentation/devicetree/bindings/i2c/mrvl-i2c.txt ? ? ? ? Documentation/devicetree/bindings/rtc/sa1100-rtc.txt ? ? ? ? Documentation/devicetree/bindings/serial/mrvl-serial.txt ? ? ? ? arch/arm/boot/dts/kirkwood-dreamplug.dts
? ? ? ? arch/arm/boot/dts/kirkwood.dtsi
? ? ? ? arch/arm/boot/dts/pxa168-aspenite.dts
? ? ? ? arch/arm/boot/dts/pxa168.dtsi
? ? ? ? arch/arm/mach-mmp/mmp-dt.c
? ? ? ? drivers/i2c/busses/i2c-pxa.c
? ? ? ? drivers/rtc/rtc-mv.c
? ? ? ? drivers/rtc/rtc-sa1100.c
? ? ? ? drivers/tty/serial/pxa.c

Quoted 7 lines

So, basically, the powerpc folks have been using "marvell", and now we're trying to change it to "mrvl".

I can't think of a technical reason to prefer one over the other. ?So, based purely on compatibility and uniformity, I'd say stick with "marvell". ?Grant, Arnd, is there something we're missing?

A few are now getting merged into v3.5:

$ git grep -l [^@]mrvl,
Documentation/devicetree/bindings/arm/mrvl/intc.txt
Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
Documentation/devicetree/bindings/arm/mrvl/timer.txt
Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
Documentation/devicetree/bindings/mtd/orion-nand.txt
Documentation/devicetree/bindings/rtc/sa1100-rtc.txt
Documentation/devicetree/bindings/serial/mrvl-serial.txt
arch/arm/boot/dts/kirkwood-dns320.dts
arch/arm/boot/dts/kirkwood-dns325.dts
arch/arm/boot/dts/kirkwood-dreamplug.dts
arch/arm/boot/dts/kirkwood-ib62x0.dts
arch/arm/boot/dts/kirkwood-iconnect.dts
arch/arm/boot/dts/kirkwood.dtsi
arch/arm/boot/dts/mmp2-brownstone.dts
arch/arm/boot/dts/mmp2.dtsi
arch/arm/boot/dts/pxa168-aspenite.dts
arch/arm/boot/dts/pxa168.dtsi
arch/arm/boot/dts/pxa910-dkb.dts
arch/arm/boot/dts/pxa910.dtsi
arch/arm/mach-mmp/irq.c
arch/arm/mach-mmp/mmp-dt.c
arch/arm/mach-mmp/mmp2-dt.c
arch/arm/mach-mmp/time.c
drivers/gpio/gpio-pxa.c
drivers/i2c/busses/i2c-pxa.c
drivers/mtd/nand/orion_nand.c
drivers/rtc/rtc-mv.c
drivers/rtc/rtc-sa1100.c
drivers/tty/serial/pxa.c
Quoted 9 lines

I'm fine with changing all of them from mrvl to marvell, if one of you makes a patch, I think we can send that after all the other stuff is merged.

This also needs an Ack from Haojian Zhuang, who has submitted the pxa/mmp related patches adding more "mrvl," prefixes.

? ? ? ?Arnd

#62 lore raw

PATCH 7/8 arm: mach-armada: add defconfig

In reply to Thomas Petazzoni

From: Gregory CLEMENT <[email protected]>

---
 arch/arm/configs/armada_defconfig |   47 +++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 arch/arm/configs/armada_defconfig
arch/arm/configs/armada_defconfig new file +47 -0
new file mode 100644
index 0000000..3ead861
@@ -0,0 +1,47 @@
+CONFIG_EXPERIMENTAL=y
+CONFIG_SYSVIPC=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_ARMADA=y
+CONFIG_MACH_ARMADA_370_DT=y
+CONFIG_MACH_ARMADA_XP_DT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_AEABI=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
Signature · 1 line
1.7.9.5
#63 lore raw

PATCH 7/8 arm: mach-armada: add defconfig

arch/arm/configs/armada_defconfig

Quoted 12 lines · Thomas Petazzoni

From: Gregory CLEMENT<[email protected]>

---
  arch/arm/configs/armada_defconfig |   47 +++++++++++++++++++++++++++++++++++++
  1 file changed, 47 insertions(+)

create mode 100644 arch/arm/configs/armada_defconfig

arch/arm/configs/armada_defconfig new file +0 -0
new file mode 100644

personally, I'd go for armadaxp_defconfig.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#64 lore raw

PATCH 7/8 arm: mach-armada: add defconfig

Le Tue, 15 May 2012 10:58:39 +0100,
Ben Dooks <[email protected]> a ?crit :

Quoted 4 lines
Quoted 2 lines
(quoted diff) +0 -0

b/arch/arm/configs/armada_defconfig new file mode 100644

personally, I'd go for armadaxp_defconfig.

Unfortunately, this would be very confusing: we support both Armada XP and Armada 370 here.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#65 lore raw

PATCH 8/8 arm: mach-armada: add entry to MAINTAINERS

In reply to Thomas Petazzoni

From: Gregory CLEMENT <[email protected]>

---
 MAINTAINERS |    8 ++++++++
 1 file changed, 8 insertions(+)
MAINTAINERS +8 -0
index ca8d7f9..2cd4235 100644
@@ -894,6 +894,14 @@ ARM/MAGICIAN MACHINE SUPPORT
 M:	Philipp Zabel <[email protected]>
 S:	Maintained
 
+ARM/Marvell Armada SOC support
+M:	Gregory Clement <[email protected]>
+M:	Thomas Petazzoni <[email protected]>
+M:	Lior Amsalem <[email protected]>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+F:	arch/arm/mach-armada/
+
 ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support
 M:	Jason Cooper <[email protected]>
 M:	Andrew Lunn <[email protected]>
Signature · 1 line
1.7.9.5
maintainer
#66 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Thomas Petazzoni
Quoted 18 lines · Thomas Petazzoni

Arnd, Olof,

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

At the moment, 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.

This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:

Quoted 14 lines
 Documentation/devicetree/bindings/arm/armada-mpic.txt  |   23 +
 Documentation/devicetree/bindings/arm/armada-timer.txt |   11 
 Documentation/devicetree/bindings/arm/armada.txt       |   24 +
 MAINTAINERS                                            |    8 
 arch/arm/Kconfig                                       |   12 
 arch/arm/Makefile                                      |    1 
 arch/arm/boot/dts/a370-db.dts                          |   41 ++
 arch/arm/boot/dts/a370.dtsi                            |   23 +
 arch/arm/boot/dts/armada.dtsi                          |   67 ++++
 arch/arm/boot/dts/axp-db.dts                           |   40 ++
 arch/arm/boot/dts/axp.dtsi                             |   43 +++
 arch/arm/configs/armada_defconfig                      |   47 +++
 arch/arm/mach-armada/Kconfig                           |   19 +
 arch/arm/mach-armada/Makefile                          |    3 

Hi Thomas

Is mach-armada a good idea? What are many different armada chipsets families:

Armada 100, 300, 500, 600, 1000, 15000, XP.

You only seem to support 300 and XP. Where would the others go? 300 is actually mach-dove, etc.

Andrew

#67 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Le Tue, 15 May 2012 11:18:38 +0200,
Andrew Lunn <[email protected]> a ?crit :

Quoted 7 lines

Is mach-armada a good idea? What are many different armada chipsets families:

Armada 100, 300, 500, 600, 1000, 15000, XP.

You only seem to support 300 and XP. Where would the others go? 300 is actually mach-dove, etc.

We support 370 and XP in this new mach directory, and we've chosen to support them in an unique directory in order to easily validate the fact that we are able to build and run a single binary kernel image that works on both SoCs.

We are definitely open to suggestions regarding the naming of the directory, or even combining with existing Marvell SoCs support if it makes sense. What would be your suggestion on this?

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#68 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Andrew Lunn
Quoted 6 lines · Andrew Lunn
Quoted 5 lines · Thomas Petazzoni

Arnd, Olof,

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

I went for the arch/arm/mach-mv-armadaxp as it kept the marvell socs together (ignoring kirkwood and dove for the moment).

I'm not sure how important the naming is as long as it is clear in the Kconfig what machines are being supported by the system.

I'd say you can put the core support for multiple difference SoCs into the same directory without too much trouble, since there is now no need for multiple board files to go in there with it. Shared peripherals can either go into the relevant drivers/ directory, or in to some form of common directory such as arch/arm/common.

[snip]

Quoted 8 lines

Hi Thomas

Is mach-armada a good idea? What are many different armada chipsets families:

Armada 100, 300, 500, 600, 1000, 15000, XP.

You only seem to support 300 and XP. Where would the others go? 300 is actually mach-dove, etc.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#69 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Le Tue, 15 May 2012 10:51:35 +0100,
Ben Dooks <[email protected]> a ?crit :

Quoted 6 lines
Quoted 3 lines
Quoted 3 lines

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

I went for the arch/arm/mach-mv-armadaxp as it kept the marvell socs together (ignoring kirkwood and dove for the moment).

mach-mv-armadaxp would be a good name if we supported only the Armada XP SoC, but we also support the Armada 370 SoC within the same directory. This makes it easy to build a single binary kernel image that boots and runs on both SoCs.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
maintainer
#70 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 7 lines · Thomas Petazzoni

Le Tue, 15 May 2012 10:51:35 +0100,
Ben Dooks <[email protected]> a ??crit :

Quoted 4 lines
Quoted 3 lines
Quoted 3 lines

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

Quoted 6 lines
Quoted 2 lines

I went for the arch/arm/mach-mv-armadaxp as it kept the marvell socs together (ignoring kirkwood and dove for the moment).

mach-mv-armadaxp would be a good name if we supported only the Armada XP SoC, but we also support the Armada 370 SoC within the same directory.

Do these devices have alternative names. We currently have dove, orion5x, kirkwood, and mv78xx0. In the past there was also loki.

Are there any names like these for these devices?

Thanks
Andrew

#71 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Thomas Petazzoni
Quoted 7 lines · Thomas Petazzoni

Le Tue, 15 May 2012 10:51:35 +0100,
Ben Dooks <[email protected]> a ?crit :

Quoted 4 lines
Quoted 3 lines
Quoted 3 lines

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

Quoted 8 lines
Quoted 2 lines

I went for the arch/arm/mach-mv-armadaxp as it kept the marvell socs together (ignoring kirkwood and dove for the moment).

mach-mv-armadaxp would be a good name if we supported only the Armada XP SoC, but we also support the Armada 370 SoC within the same directory. This makes it easy to build a single binary kernel image that boots and runs on both SoCs.

Directory location doesn't really have anything to do with what can be in a single kernel binary. We will soon be building single images across mach directories. With some hacks and limitations, Arnd has built (not run) omap2+, u8500, imx and one other in a single kernel. If there's overlap with dove or other platforms, then they should probably all be combined into a single mach directory. One option would be make the new mach directory somewhat generic and then later move dove or others into the new directory.

Rob

#72 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Le Tue, 15 May 2012 09:35:55 -0500,
Rob Herring <[email protected]> a ?crit :

Quoted 3 lines

Directory location doesn't really have anything to do with what can be in a single kernel binary. We will soon be building single images across mach directories.

Agreed, but it's not the case right now, and we wanted to submit today a kernel that boots on both of those SoCs.

The 370 and XP both use the PJ4B core, which is a Marvell implementation of an ARMv7 compatible core. The 370 has one PJ4B, and the various XP variants have a choice of 2 or 4 PJ4Bs, and various other differences. To us, it makes a lot of sense to be able to support those SoCs together in the same kernel image and in the same directory, even if both concepts are not directly tied together.

Quoted 6 lines

With some hacks and limitations, Arnd has
built (not run) omap2+, u8500, imx and one other in a single kernel. If there's overlap with dove or other platforms, then they should probably all be combined into a single mach directory. One option would be make the new mach directory somewhat generic and then later move dove or others into the new directory.

This would be one solution.

On the naming side, we are really open to what the community prefers. We knew there would be quite a bit of discussion around this, because there's a lot quite a few Marvell SoCs supported in various places, and it's not obvious what's the right place and name for a new SoC family.

What about making it mach-marvell, which would contain the DT-enabled SoC support for Marvell SoCs? We can start with 370 and XP today, and gradually add future SoCs, or even port previous SoCs as they are moved to support the device tree.

Again we're really open on the solution. Lior from Marvell can give all the necessary input to explain how the SoC family is organized.

Best regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#73 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 5 lines · Thomas Petazzoni

On the naming side, we are really open to what the community prefers. We knew there would be quite a bit of discussion around this, because there's a lot quite a few Marvell SoCs supported in various places, and it's not obvious what's the right place and name for a new SoC family.

Quoted 7 lines

What about making it mach-marvell, which would contain the DT-enabled SoC support for Marvell SoCs? We can start with 370 and XP today, and gradually add future SoCs, or even port previous SoCs as they are moved to support the device tree.

Again we're really open on the solution. Lior from Marvell can give all the necessary input to explain how the SoC family is organized.

The problem with mach-marvell is that it would be confusing in the presence of pxa/mmp which I would probably still leave out of that directory, since they are rather different inside.

I think we can just start with the existing plat-orion directory until someone comes up with a better place.

Arnd

#74 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Le Tue, 15 May 2012 15:27:00 +0000,
Arnd Bergmann <[email protected]> a ?crit :

Quoted 3 lines

The problem with mach-marvell is that it would be confusing in the presence of pxa/mmp which I would probably still leave out of that directory, since they are rather different inside.

Sure.

Quoted 2 lines

I think we can just start with the existing plat-orion directory until someone comes up with a better place.

So you want us to put all this new source code that typically belongs to a mach-* directory into plat-orion/ ?

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#75 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 5 lines · Thomas Petazzoni
Quoted 2 lines

I think we can just start with the existing plat-orion directory until someone comes up with a better place.

So you want us to put all this new source code that typically belongs to a mach-* directory into plat-orion/ ?

Well, it's just an idea, since it would make sense to move dove/kirkwood/mv78xx0/orion5x closer together anyway, the logical choice is to use the plat-orion directory for that.

So the stages would be

1. add new platform code into plat-orion
2. move DT-based parts of dove/kirkwood/mv78xx0/orion5x into plat-orion
3. over time phase out the other directories as they fall into disuse
4. rename plat-orion to mach-orion

As you point out, the ugly part of this is that we'd end up having code in a plat-* directory that doesn't really belong there.

Another way would be to reorganize those directories upfront:

plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.h

and then go from there. The differences between the headers are fairly small already, so that should be manageable.

Arnd

#76 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 8 lines · Arnd Bergmann

Another way would be to reorganize those directories upfront:

plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.h

and then go from there. The differences between the headers are fairly small already, so that should be manageable.

Actually we could do a trivial move of all files into one directory at any time, e.g. at the end of the merge window, to minimize conflicts with other patches.

This is a semi-automated move of all plat-orion based machines into a single mach-orion directory, and we could of course add the new stuff in there as well. I've specifically tried to keep this move simple, even if that means a lot of the easy cleanups for code that are mostly identical are not done here. Cleanups after this could come one at a time to reduce this duplication and simplify the platform.

Obvious next steps are to merge the various Makefile and Kconfig files as well as all the headers, and to actually allow building stuff together.

 arch/arm/mach-dove/Makefile.boot                 |    3 --
 arch/arm/mach-dove/include/mach/gpio.h           |    9 -------
 arch/arm/mach-dove/include/mach/hardware.h       |   19 ----------------
 arch/arm/mach-kirkwood/include/mach/gpio.h       |    9 -------
 arch/arm/mach-kirkwood/include/mach/hardware.h   |   14 ------------
 arch/arm/mach-kirkwood/include/mach/timex.h      |   10 --------
 arch/arm/mach-mv78xx0/Makefile.boot              |    3 --
 arch/arm/mach-mv78xx0/include/mach/gpio.h        |    9 -------
 arch/arm/mach-mv78xx0/include/mach/hardware.h    |   14 ------------
 arch/arm/mach-mv78xx0/include/mach/timex.h       |    9 -------
 arch/arm/mach-orion5x/Makefile.boot              |    3 --
 arch/arm/mach-orion5x/include/mach/gpio.h        |    9 -------
 arch/arm/mach-orion5x/include/mach/hardware.h    |   14 ------------
 arch/arm/mach-orion5x/include/mach/timex.h       |   11 ---------
 arch/arm/plat-orion/Makefile                     |   10 --------
 b/arch/arm/Kconfig                               |    8 -------
 b/arch/arm/Makefile                              |    9 +++----
 b/arch/arm/mach-orion/Kconfig                    |    7 ++++++
 b/arch/arm/mach-orion/Makefile                   |   26 +++++++++++++++++++++++
 b/arch/arm/mach-orion/Makefile.dove              |    2 -
 b/arch/arm/mach-orion/Makefile.kirkwood          |    2 -
 b/arch/arm/mach-orion/Makefile.mv78xx0           |    2 -
 b/arch/arm/mach-orion/Makefile.orion5x           |    2 -
 b/arch/arm/mach-orion/addr-map-dove.c            |    4 +--
 b/arch/arm/mach-orion/addr-map-kirkwood.c        |    4 +--
 b/arch/arm/mach-orion/addr-map-mv78xx0.c         |    4 +--
 b/arch/arm/mach-orion/addr-map-orion5x.c         |    4 +--
 b/arch/arm/mach-orion/addr-map.c                 |    2 -
 b/arch/arm/mach-orion/board-dnskw.c              |    4 +--
 b/arch/arm/mach-orion/board-dreamplug.c          |    6 ++---
 b/arch/arm/mach-orion/board-dt.c                 |    2 -
 b/arch/arm/mach-orion/board-ib62x0.c             |    4 +--
 b/arch/arm/mach-orion/board-iconnect.c           |    4 +--
 b/arch/arm/mach-orion/buffalo-wxl-setup.c        |    4 +--
 b/arch/arm/mach-orion/cm-a510.c                  |    2 -
 b/arch/arm/mach-orion/common.c                   |    6 ++---
 b/arch/arm/mach-orion/d2net-setup.c              |    4 +--
 b/arch/arm/mach-orion/d2net_v2-setup.c           |    4 +--
 b/arch/arm/mach-orion/db78x00-bp-setup.c         |    2 -
 b/arch/arm/mach-orion/db88f5281-setup.c          |    6 ++---
 b/arch/arm/mach-orion/db88f6281-bp-setup.c       |    6 ++---
 b/arch/arm/mach-orion/dns323-setup.c             |    4 +--
 b/arch/arm/mach-orion/dockstar-setup.c           |    6 ++---
 b/arch/arm/mach-orion/dove-db-setup.c            |    2 -
 b/arch/arm/mach-orion/dove.c                     |   10 ++++----
 b/arch/arm/mach-orion/edmini_v2-setup.c          |    4 +--
 b/arch/arm/mach-orion/guruplug-setup.c           |    6 ++---
 b/arch/arm/mach-orion/include/mach/bridge-regs.h |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/debug-macro.S |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/entry-macro.S |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/hardware.h    |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/io.h          |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/irqs.h        |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/uncompress.h  |   12 ++++++++++
 b/arch/arm/mach-orion/irq-dove.c                 |    4 +--
 b/arch/arm/mach-orion/irq-kirkwood.c             |    4 +--
 b/arch/arm/mach-orion/irq-mv78xx0.c              |    4 +--
 b/arch/arm/mach-orion/irq-orion5x.c              |    4 +--
 b/arch/arm/mach-orion/irq.c                      |    2 -
 b/arch/arm/mach-orion/kirkwood.c                 |   18 +++++++--------
 b/arch/arm/mach-orion/kurobox_pro-setup.c        |    6 ++---
 b/arch/arm/mach-orion/lacie_v2-common.c          |    4 +--
 b/arch/arm/mach-orion/ls-chl-setup.c             |    4 +--
 b/arch/arm/mach-orion/ls_hgl-setup.c             |    4 +--
 b/arch/arm/mach-orion/lsmini-setup.c             |    4 +--
 b/arch/arm/mach-orion/mpp-dove.c                 |    4 +--
 b/arch/arm/mach-orion/mpp-kirkwood.c             |    6 ++---
 b/arch/arm/mach-orion/mpp-mv78xx0.c              |    6 ++---
 b/arch/arm/mach-orion/mpp-orion5x.c              |    6 ++---
 b/arch/arm/mach-orion/mpp.c                      |    2 -
 b/arch/arm/mach-orion/mss2-setup.c               |    4 +--
 b/arch/arm/mach-orion/mv2120-setup.c             |    4 +--
 b/arch/arm/mach-orion/mv78xx0.c                  |   14 ++++++------
 b/arch/arm/mach-orion/mv88f6281gtw_ge-setup.c    |    4 +--
 b/arch/arm/mach-orion/net2big-setup.c            |    4 +--
 b/arch/arm/mach-orion/netspace_v2-setup.c        |    4 +--
 b/arch/arm/mach-orion/netxbig_v2-setup.c         |    4 +--
 b/arch/arm/mach-orion/openrd-setup.c             |    6 ++---
 b/arch/arm/mach-orion/orion5x.c                  |   12 +++++-----
 b/arch/arm/mach-orion/pci-orion5x.c              |    6 ++---
 b/arch/arm/mach-orion/pcie-dove.c                |    6 ++---
 b/arch/arm/mach-orion/pcie-kirkwood.c            |    6 ++---
 b/arch/arm/mach-orion/pcie-mv78xx0.c             |    6 ++---
 b/arch/arm/mach-orion/pcie.c                     |    4 +--
 b/arch/arm/mach-orion/rd78x00-masa-setup.c       |    2 -
 b/arch/arm/mach-orion/rd88f5181l-fxo-setup.c     |    4 +--
 b/arch/arm/mach-orion/rd88f5181l-ge-setup.c      |    4 +--
 b/arch/arm/mach-orion/rd88f5182-setup.c          |    4 +--
 b/arch/arm/mach-orion/rd88f6183ap-ge-setup.c     |    2 -
 b/arch/arm/mach-orion/rd88f6192-nas-setup.c      |    2 -
 b/arch/arm/mach-orion/rd88f6281-setup.c          |    6 ++---
 b/arch/arm/mach-orion/sheevaplug-setup.c         |    6 ++---
 b/arch/arm/mach-orion/t5325-setup.c              |    4 +--
 b/arch/arm/mach-orion/terastation_pro2-setup.c   |    4 +--
 b/arch/arm/mach-orion/ts209-setup.c              |    4 +--
 b/arch/arm/mach-orion/ts219-setup.c              |    4 +--
 b/arch/arm/mach-orion/ts409-setup.c              |    4 +--
 b/arch/arm/mach-orion/ts41x-setup.c              |    6 ++---
 b/arch/arm/mach-orion/ts78xx-setup.c             |    4 +--
 b/arch/arm/mach-orion/tsx09-common.c             |    2 -
 b/arch/arm/mach-orion/tsx1x-common.c             |    2 -
 b/arch/arm/mach-orion/wnr854t-setup.c            |    4 +--
 b/arch/arm/mach-orion/wrt350n-v2-setup.c         |    4 +--
 b/arch/arm/mm/cache-feroceon-l2.c                |    2 -
 b/drivers/dma/mv_xor.c                           |    2 -
 b/drivers/mmc/host/mvsdio.c                      |    2 -
 b/drivers/mtd/nand/orion_nand.c                  |    2 -
 b/drivers/usb/host/ehci-orion.c                  |    2 -
 b/drivers/watchdog/orion_wdt.c                   |    2 -
 b/sound/soc/kirkwood/kirkwood-i2s.c              |    2 -
 b/sound/soc/kirkwood/kirkwood-openrd.c           |    2 -
 b/sound/soc/kirkwood/kirkwood-t5325.c            |    2 -
 112 files changed, 306 insertions(+), 342 deletions(-)
arch/arm/Kconfig +1 -7
index 852b12b..196dfbf 100644
@@ -1013,8 +1013,6 @@ source "arch/arm/mach-cns3xxx/Kconfig"
 
 source "arch/arm/mach-davinci/Kconfig"
 
-source "arch/arm/mach-dove/Kconfig"
-
 source "arch/arm/mach-ep93xx/Kconfig"
 
 source "arch/arm/mach-footbridge/Kconfig"
@@ -1033,16 +1031,12 @@ source "arch/arm/mach-iop13xx/Kconfig"
 
 source "arch/arm/mach-ixp4xx/Kconfig"
 
-source "arch/arm/mach-kirkwood/Kconfig"
-
 source "arch/arm/mach-ks8695/Kconfig"
 
 source "arch/arm/mach-lpc32xx/Kconfig"
 
 source "arch/arm/mach-msm/Kconfig"
 
-source "arch/arm/mach-mv78xx0/Kconfig"
-
 source "arch/arm/plat-mxc/Kconfig"
 
 source "arch/arm/mach-mxs/Kconfig"
@@ -1058,7 +1052,7 @@ source "arch/arm/mach-omap1/Kconfig"
 
 source "arch/arm/mach-omap2/Kconfig"
 
-source "arch/arm/mach-orion5x/Kconfig"
+source "arch/arm/mach-orion/Kconfig"
 
 source "arch/arm/mach-pxa/Kconfig"
 source "arch/arm/plat-pxa/Kconfig"
arch/arm/Makefile +4 -5
index b3eb01a..ec55498 100644
@@ -139,7 +139,7 @@ machine-$(CONFIG_ARCH_BCMRING)		:= bcmring
 machine-$(CONFIG_ARCH_CLPS711X)		:= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		:= cns3xxx
 machine-$(CONFIG_ARCH_DAVINCI)		:= davinci
-machine-$(CONFIG_ARCH_DOVE)		:= dove
+machine-$(CONFIG_ARCH_DOVE)		:= orion
 machine-$(CONFIG_ARCH_EBSA110)		:= ebsa110
 machine-$(CONFIG_ARCH_EP93XX)		:= ep93xx
 machine-$(CONFIG_ARCH_GEMINI)		:= gemini
@@ -150,12 +150,12 @@ machine-$(CONFIG_ARCH_IOP13XX)		:= iop13xx
 machine-$(CONFIG_ARCH_IOP32X)		:= iop32x
 machine-$(CONFIG_ARCH_IOP33X)		:= iop33x
 machine-$(CONFIG_ARCH_IXP4XX)		:= ixp4xx
-machine-$(CONFIG_ARCH_KIRKWOOD)		:= kirkwood
+machine-$(CONFIG_ARCH_KIRKWOOD)		:= orion
 machine-$(CONFIG_ARCH_KS8695)		:= ks8695
 machine-$(CONFIG_ARCH_LPC32XX)		:= lpc32xx
 machine-$(CONFIG_ARCH_MMP)		:= mmp
 machine-$(CONFIG_ARCH_MSM)		:= msm
-machine-$(CONFIG_ARCH_MV78XX0)		:= mv78xx0
+machine-$(CONFIG_ARCH_MV78XX0)		:= orion
 machine-$(CONFIG_ARCH_IMX_V4_V5)	:= imx
 machine-$(CONFIG_ARCH_IMX_V6_V7)	:= imx
 machine-$(CONFIG_ARCH_MXS)		:= mxs
@@ -163,7 +163,7 @@ machine-$(CONFIG_ARCH_NETX)		:= netx
 machine-$(CONFIG_ARCH_NOMADIK)		:= nomadik
 machine-$(CONFIG_ARCH_OMAP1)		:= omap1
 machine-$(CONFIG_ARCH_OMAP2PLUS)	:= omap2
-machine-$(CONFIG_ARCH_ORION5X)		:= orion5x
+machine-$(CONFIG_ARCH_ORION5X)		:= orion
 machine-$(CONFIG_ARCH_PICOXCELL)	:= picoxcell
 machine-$(CONFIG_ARCH_PNX4008)		:= pnx4008
 machine-$(CONFIG_ARCH_PRIMA2)		:= prima2
@@ -204,7 +204,6 @@ plat-$(CONFIG_ARCH_S3C64XX)	:= samsung
 plat-$(CONFIG_ARCH_ZYNQ)	:= versatile
 plat-$(CONFIG_PLAT_IOP)		:= iop
 plat-$(CONFIG_PLAT_NOMADIK)	:= nomadik
-plat-$(CONFIG_PLAT_ORION)	:= orion
 plat-$(CONFIG_PLAT_PXA)		:= pxa
 plat-$(CONFIG_PLAT_S3C24XX)	:= s3c24xx samsung
 plat-$(CONFIG_PLAT_S5P)		:= samsung
arch/arm/mach-dove/Makefile.boot deleted +0 -3
deleted file mode 100644
index 760a0ef..0000000
@@ -1,3 +0,0 @@
-   zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00800000
arch/arm/mach-dove/include/mach/gpio.h deleted +0 -9
deleted file mode 100644
index e7e5101..0000000
@@ -1,9 +0,0 @@
-/*
- * arch/arm/mach-dove/include/mach/gpio.h
- *
- * 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 <plat/gpio.h>
arch/arm/mach-dove/include/mach/hardware.h deleted +0 -19
deleted file mode 100644
index f1368b9..0000000
@@ -1,19 +0,0 @@
-/*
- * arch/arm/mach-dove/include/mach/hardware.h
- *
- * 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 __ASM_ARCH_HARDWARE_H
-#define __ASM_ARCH_HARDWARE_H
-
-#include "dove.h"
-
-/* Macros below are required for compatibility with PXA AC'97 driver.	*/
-#define __REG(x)	(*((volatile u32 *)((x) - DOVE_SB_REGS_PHYS_BASE + \
-				DOVE_SB_REGS_VIRT_BASE)))
-#define __PREG(x)	(((u32)&(x)) - DOVE_SB_REGS_VIRT_BASE + \
-		DOVE_SB_REGS_PHYS_BASE)
-#endif
arch/arm/mach-kirkwood/include/mach/gpio.h deleted +0 -9
deleted file mode 100644
index 84f340b..0000000
@@ -1,9 +0,0 @@
-/*
- * arch/asm-arm/mach-kirkwood/include/mach/gpio.h
- *
- * 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 <plat/gpio.h>
arch/arm/mach-kirkwood/include/mach/hardware.h deleted +0 -14
deleted file mode 100644
index 742b74f..0000000
@@ -1,14 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/include/mach/hardware.h
- *
- * 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.
- */
-
-#ifndef __ASM_ARCH_HARDWARE_H
-#define __ASM_ARCH_HARDWARE_H
-
-#include "kirkwood.h"
-
-#endif
arch/arm/mach-kirkwood/include/mach/timex.h deleted +0 -10
deleted file mode 100644
index c923cd1..0000000
@@ -1,10 +0,0 @@
-/*
- * arch/arm/mach-kirkwood/include/mach/timex.h
- *
- * 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)
-
arch/arm/mach-mv78xx0/Makefile.boot deleted +0 -3
deleted file mode 100644
index 760a0ef..0000000
@@ -1,3 +0,0 @@
-   zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00800000
arch/arm/mach-mv78xx0/include/mach/gpio.h deleted +0 -9
deleted file mode 100644
index 77e1b84..0000000
@@ -1,9 +0,0 @@
-/*
- * arch/asm-arm/mach-mv78xx0/include/mach/gpio.h
- *
- * 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 <plat/gpio.h>
arch/arm/mach-mv78xx0/include/mach/hardware.h deleted +0 -14
deleted file mode 100644
index 67cab0a..0000000
@@ -1,14 +0,0 @@
-/*
- * arch/arm/mach-mv78xx0/include/mach/hardware.h
- *
- * 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 __ASM_ARCH_HARDWARE_H
-#define __ASM_ARCH_HARDWARE_H
-
-#include "mv78xx0.h"
-
-#endif
arch/arm/mach-mv78xx0/include/mach/timex.h deleted +0 -9
deleted file mode 100644
index 0e8c443..0000000
@@ -1,9 +0,0 @@
-/*
- * arch/arm/mach-mv78xx0/include/mach/timex.h
- *
- * 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)
arch/arm/mach-orion/Kconfig new file +7 -0
new file mode 100644
index 0000000..769908f
@@ -0,0 +1,7 @@
+source "arch/arm/mach-orion/Kconfig.dove"
+
+source "arch/arm/mach-orion/Kconfig.kirkwood"
+
+source "arch/arm/mach-orion/Kconfig.mv78xx0"
+
+source "arch/arm/mach-orion/Kconfig.orion5x"
arch/arm/mach-orion/Kconfig.dove renamed from arch/arm/mach-dove/Kconfig +0 -0
similarity index 100%
rename from arch/arm/mach-dove/Kconfig
rename to arch/arm/mach-orion/Kconfig.dove
arch/arm/mach-orion/Kconfig.kirkwood renamed from arch/arm/mach-kirkwood/Kconfig +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/Kconfig
rename to arch/arm/mach-orion/Kconfig.kirkwood
arch/arm/mach-orion/Kconfig.mv78xx0 renamed from arch/arm/mach-mv78xx0/Kconfig +0 -0
similarity index 100%
rename from arch/arm/mach-mv78xx0/Kconfig
rename to arch/arm/mach-orion/Kconfig.mv78xx0
arch/arm/mach-orion/Kconfig.orion5x renamed from arch/arm/mach-orion5x/Kconfig +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/Kconfig
rename to arch/arm/mach-orion/Kconfig.orion5x
arch/arm/mach-orion/Makefile new file +26 -0
new file mode 100644
index 0000000..d91869d
@@ -0,0 +1,26 @@
+#
+# Makefile for the linux kernel.
+#
+
+obj-y	:= irq.o pcie.o time.o common.o mpp.o addr-map.o
+obj-m	:=
+obj-n	:=
+obj-	:=
+
+obj-$(CONFIG_GENERIC_GPIO) += gpio.o
+
+ifdef CONFIG_ARCH_DOVE
+include arch/arm/mach-orion/Makefile.dove
+endif
+
+ifdef CONFIG_ARCH_KIRKWOOD
+include arch/arm/mach-orion/Makefile.kirkwood
+endif
+
+ifdef CONFIG_ARCH_MV78xx0
+include arch/arm/mach-orion/Makefile.mv78xx0
+endif
+
+ifdef CONFIG_ARCH_ORION5X
+include arch/arm/mach-orion/Makefile.orion5x
+endif
arch/arm/mach-orion/Makefile.boot renamed from arch/arm/mach-kirkwood/Makefile.boot +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/Makefile.boot
rename to arch/arm/mach-orion/Makefile.boot
arch/arm/mach-orion/Makefile.dove renamed from arch/arm/mach-dove/Makefile +1 -1
similarity index 55%
rename from arch/arm/mach-dove/Makefile
rename to arch/arm/mach-orion/Makefile.dove
index fa0f018..0625023 100644
@@ -1,4 +1,4 @@
-obj-y				+= common.o addr-map.o irq.o pcie.o mpp.o
+obj-y				+= dove.o addr-map-dove.o irq-dove.o pcie-dove.o mpp-dove.o
 
 obj-$(CONFIG_MACH_DOVE_DB)	+= dove-db-setup.o
 obj-$(CONFIG_MACH_CM_A510)	+= cm-a510.o
arch/arm/mach-orion/Makefile.kirkwood renamed from arch/arm/mach-kirkwood/Makefile +1 -1
similarity index 93%
rename from arch/arm/mach-kirkwood/Makefile
rename to arch/arm/mach-orion/Makefile.kirkwood
index d2b0590..223d581 100644
@@ -1,4 +1,4 @@
-obj-y				+= common.o addr-map.o irq.o pcie.o mpp.o
+obj-y				+= kirkwood.o addr-map-kirkwood.o irq-kirkwood.o pcie-kirkwood.o mpp-kirkwood.o
 
 obj-$(CONFIG_MACH_DB88F6281_BP)		+= db88f6281-bp-setup.o
 obj-$(CONFIG_MACH_RD88F6192_NAS)	+= rd88f6192-nas-setup.o
arch/arm/mach-orion/Makefile.mv78xx0 renamed from arch/arm/mach-mv78xx0/Makefile +1 -1
similarity index 66%
rename from arch/arm/mach-mv78xx0/Makefile
rename to arch/arm/mach-orion/Makefile.mv78xx0
index 67a13f9..29032eb 100644
@@ -1,4 +1,4 @@
-obj-y				+= common.o addr-map.o mpp.o irq.o pcie.o
+obj-y				+= mv78xx0.o addr-map-mv78xx0.o mpp-mv78xx0.o irq-mv78xx0.o pcie-mv78xx0.o
 obj-$(CONFIG_MACH_DB78X00_BP)	+= db78x00-bp-setup.o
 obj-$(CONFIG_MACH_RD78X00_MASA)	+= rd78x00-masa-setup.o
 obj-$(CONFIG_MACH_TERASTATION_WXL) += buffalo-wxl-setup.o
arch/arm/mach-orion/Makefile.orion5x renamed from arch/arm/mach-orion5x/Makefile +1 -1
similarity index 93%
rename from arch/arm/mach-orion5x/Makefile
rename to arch/arm/mach-orion/Makefile.orion5x
index 7f18cda..7eb9c7b 100644
@@ -1,4 +1,4 @@
-obj-y				+= common.o addr-map.o pci.o irq.o mpp.o
+obj-y				+= orion5x.o addr-map-orion5x.o pci-orion5x.o irq-orion5x.o mpp-orion5x.o
 obj-$(CONFIG_MACH_DB88F5281)	+= db88f5281-setup.o
 obj-$(CONFIG_MACH_RD88F5182)	+= rd88f5182-setup.o
 obj-$(CONFIG_MACH_KUROBOX_PRO)	+= kurobox_pro-setup.o
arch/arm/mach-orion/addr-map-dove.c renamed from arch/arm/mach-dove/addr-map.c +2 -2
similarity index 98%
rename from arch/arm/mach-dove/addr-map.c
rename to arch/arm/mach-orion/addr-map-dove.c
index 2a06c01..32e68ff 100644
@@ -15,8 +15,8 @@
 #include <asm/mach/arch.h>
 #include <asm/setup.h>
 #include <mach/dove.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/addr-map.h>
+#include "dove.h"
 
 /*
  * Generic Address Decode Windows bit settings
arch/arm/mach-orion/addr-map-kirkwood.c renamed from arch/arm/mach-kirkwood/addr-map.c +2 -2
similarity index 97%
rename from arch/arm/mach-kirkwood/addr-map.c
rename to arch/arm/mach-orion/addr-map-kirkwood.c
index e9a7180..63e1932 100644
@@ -13,8 +13,8 @@
 #include <linux/mbus.h>
 #include <linux/io.h>
 #include <mach/hardware.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/addr-map.h>
+#include "kirkwood.h"
 
 /*
  * Generic Address Decode Windows bit settings
arch/arm/mach-orion/addr-map-mv78xx0.c renamed from arch/arm/mach-mv78xx0/addr-map.c +2 -2
similarity index 98%
rename from arch/arm/mach-mv78xx0/addr-map.c
rename to arch/arm/mach-orion/addr-map-mv78xx0.c
index 62b53d7..99da1bb 100644
@@ -12,8 +12,8 @@
 #include <linux/init.h>
 #include <linux/mbus.h>
 #include <linux/io.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/addr-map.h>
+#include "mv78xx0.h"
 
 /*
  * Generic Address Decode Windows bit settings
arch/arm/mach-orion/addr-map-orion5x.c renamed from arch/arm/mach-orion5x/addr-map.c +2 -2
similarity index 98%
rename from arch/arm/mach-orion5x/addr-map.c
rename to arch/arm/mach-orion/addr-map-orion5x.c
index eaac83d..582362d 100644
@@ -15,8 +15,8 @@
 #include <linux/mbus.h>
 #include <linux/io.h>
 #include <mach/hardware.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/addr-map.h>
+#include "orion5x.h"
 
 /*
  * The Orion has fully programmable address map. There's a separate address
arch/arm/mach-orion/addr-map.c renamed from arch/arm/plat-orion/addr-map.c +1 -1
similarity index 99%
rename from arch/arm/plat-orion/addr-map.c
rename to arch/arm/mach-orion/addr-map.c
index 367ca89..cd53710 100644
@@ -13,7 +13,7 @@
 #include <linux/init.h>
 #include <linux/mbus.h>
 #include <linux/io.h>
-#include <plat/addr-map.h>
+#include <mach/addr-map.h>
 
 struct mbus_dram_target_info orion_mbus_dram_info;
 
arch/arm/mach-orion/board-dnskw.c renamed from arch/arm/mach-kirkwood/board-dnskw.c +2 -2
similarity index 99%
rename from arch/arm/mach-kirkwood/board-dnskw.c
rename to arch/arm/mach-orion/board-dnskw.c
index 58c2d68..c61858c 100644
@@ -28,8 +28,8 @@
 #include <asm/mach/map.h>
 #include <mach/kirkwood.h>
 #include <mach/bridge-regs.h>
-#include "common.h"
-#include "mpp.h"
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 static struct mv643xx_eth_platform_data dnskw_ge00_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
arch/arm/mach-orion/board-dreamplug.c renamed from arch/arm/mach-kirkwood/board-dreamplug.c +3 -3
similarity index 97%
rename from arch/arm/mach-kirkwood/board-dreamplug.c
rename to arch/arm/mach-orion/board-dreamplug.c
index 9854539..eab6db6 100644
@@ -33,9 +33,9 @@
 #include <asm/mach/map.h>
 #include <mach/kirkwood.h>
 #include <mach/bridge-regs.h>
-#include <plat/mvsdio.h>
-#include "common.h"
-#include "mpp.h"
+#include <mach/mvsdio.h>
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 struct mtd_partition dreamplug_partitions[] = {
 	{
arch/arm/mach-orion/board-dt.c renamed from arch/arm/mach-kirkwood/board-dt.c +1 -1
similarity index 99%
rename from arch/arm/mach-kirkwood/board-dt.c
rename to arch/arm/mach-orion/board-dt.c
index 10d1969..6ecdcf9 100644
@@ -18,7 +18,7 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <mach/bridge-regs.h>
-#include "common.h"
+#include "kirkwood.h"
 
 static struct of_device_id kirkwood_dt_match_table[] __initdata = {
 	{ .compatible = "simple-bus", },
arch/arm/mach-orion/board-ib62x0.c renamed from arch/arm/mach-kirkwood/board-ib62x0.c +2 -2
similarity index 98%
rename from arch/arm/mach-kirkwood/board-ib62x0.c
rename to arch/arm/mach-orion/board-ib62x0.c
index eddf1df..5c8fa27 100644
@@ -24,8 +24,8 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include "common.h"
-#include "mpp.h"
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 #define IB62X0_GPIO_POWER_OFF	24
 
arch/arm/mach-orion/board-iconnect.c renamed from arch/arm/mach-kirkwood/board-iconnect.c +2 -2
similarity index 98%
rename from arch/arm/mach-kirkwood/board-iconnect.c
rename to arch/arm/mach-orion/board-iconnect.c
index 2222c57..6c1c647 100644
@@ -28,8 +28,8 @@
 #include <linux/gpio_keys.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include "common.h"
-#include "mpp.h"
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 static struct mv643xx_eth_platform_data iconnect_ge00_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR(11),
arch/arm/mach-orion/buffalo-wxl-setup.c renamed from arch/arm/mach-mv78xx0/buffalo-wxl-setup.c +2 -2
similarity index 98%
rename from arch/arm/mach-mv78xx0/buffalo-wxl-setup.c
rename to arch/arm/mach-orion/buffalo-wxl-setup.c
index ee74ec9..1d602ae 100644
@@ -20,8 +20,8 @@
 #include <mach/mv78xx0.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
-#include "common.h"
-#include "mpp.h"
+#include "mv78xx0.h"
+#include "mpp-mv78xx0.h"
 
 
 /* This arch has 2 Giga Ethernet */
arch/arm/mach-orion/cm-a510.c renamed from arch/arm/mach-dove/cm-a510.c +1 -1
similarity index 99%
rename from arch/arm/mach-dove/cm-a510.c
rename to arch/arm/mach-orion/cm-a510.c
index 792b4e2..c011f15 100644
@@ -24,7 +24,7 @@
 
 #include <mach/dove.h>
 
-#include "common.h"
+#include "dove.h"
 
 static struct mv643xx_eth_platform_data cm_a510_ge00_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR_DEFAULT,
arch/arm/mach-orion/common.c renamed from arch/arm/plat-orion/common.c +3 -3
similarity index 99%
rename from arch/arm/plat-orion/common.c
rename to arch/arm/mach-orion/common.c
index 74daf5e..90afe40 100644
@@ -18,9 +18,9 @@
 #include <linux/mv643xx_i2c.h>
 #include <net/dsa.h>
 #include <linux/spi/orion_spi.h>
-#include <plat/orion_wdt.h>
-#include <plat/mv_xor.h>
-#include <plat/ehci-orion.h>
+#include <mach/orion_wdt.h>
+#include <mach/mv_xor.h>
+#include <mach/ehci-orion.h>
 #include <mach/bridge-regs.h>
 
 /* Fill in the resources structure and link it into the platform
arch/arm/mach-orion/cpuidle.c renamed from arch/arm/mach-kirkwood/cpuidle.c +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/cpuidle.c
rename to arch/arm/mach-orion/cpuidle.c
arch/arm/mach-orion/d2net-setup.c renamed from arch/arm/mach-orion5x/d2net-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/d2net-setup.c
rename to arch/arm/mach-orion/d2net-setup.c
index d75dcfa..272b55c 100644
@@ -27,8 +27,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * LaCie d2 Network Info
arch/arm/mach-orion/d2net_v2-setup.c renamed from arch/arm/mach-kirkwood/d2net_v2-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-kirkwood/d2net_v2-setup.c
rename to arch/arm/mach-orion/d2net_v2-setup.c
index 6e1bac9..dc1c879 100644
@@ -33,8 +33,8 @@
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
 #include <mach/leds-ns2.h>
-#include "common.h"
-#include "mpp.h"
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 #include "lacie_v2-common.h"
 
 /*****************************************************************************
arch/arm/mach-orion/db78x00-bp-setup.c renamed from arch/arm/mach-mv78xx0/db78x00-bp-setup.c +1 -1
similarity index 99%
rename from arch/arm/mach-mv78xx0/db78x00-bp-setup.c
rename to arch/arm/mach-orion/db78x00-bp-setup.c
index 4d6d48b..b82889d 100644
@@ -18,7 +18,7 @@
 #include <mach/mv78xx0.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
-#include "common.h"
+#include "mv78xx0.h"
 
 static struct mv643xx_eth_platform_data db78x00_ge00_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
arch/arm/mach-orion/db88f5281-setup.c renamed from arch/arm/mach-orion5x/db88f5281-setup.c +3 -3
similarity index 99%
rename from arch/arm/mach-orion5x/db88f5281-setup.c
rename to arch/arm/mach-orion/db88f5281-setup.c
index e52108c..030b643 100644
@@ -24,9 +24,9 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include <plat/orion_nand.h>
-#include "common.h"
-#include "mpp.h"
+#include <mach/orion_nand.h>
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * DB-88F5281 on board devices
arch/arm/mach-orion/db88f6281-bp-setup.c renamed from arch/arm/mach-kirkwood/db88f6281-bp-setup.c +3 -3
similarity index 97%
rename from arch/arm/mach-kirkwood/db88f6281-bp-setup.c
rename to arch/arm/mach-orion/db88f6281-bp-setup.c
index d933593..43b01c9 100644
@@ -17,9 +17,9 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include <plat/mvsdio.h>
-#include "common.h"
-#include "mpp.h"
+#include <mach/mvsdio.h>
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 static struct mtd_partition db88f6281_nand_parts[] = {
 	{
arch/arm/mach-orion/dns323-setup.c renamed from arch/arm/mach-orion5x/dns323-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/dns323-setup.c
rename to arch/arm/mach-orion/dns323-setup.c
index 13d2bec..6ddb272 100644
@@ -34,8 +34,8 @@
 #include <asm/mach/pci.h>
 #include <asm/system_info.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /* Rev A1 and B1 */
 #define DNS323_GPIO_LED_RIGHT_AMBER	1
arch/arm/mach-orion/dockstar-setup.c renamed from arch/arm/mach-kirkwood/dockstar-setup.c +3 -3
similarity index 97%
rename from arch/arm/mach-kirkwood/dockstar-setup.c
rename to arch/arm/mach-orion/dockstar-setup.c
index 61d9a55..6fb0e83 100644
@@ -19,9 +19,9 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include <plat/mvsdio.h>
-#include "common.h"
-#include "mpp.h"
+#include <mach/mvsdio.h>
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 static struct mtd_partition dockstar_nand_parts[] = {
 	{
arch/arm/mach-orion/dove-db-setup.c renamed from arch/arm/mach-dove/dove-db-setup.c +1 -1
similarity index 99%
rename from arch/arm/mach-dove/dove-db-setup.c
rename to arch/arm/mach-orion/dove-db-setup.c
index ea77ae4..2aca495 100644
@@ -26,7 +26,7 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/dove.h>
-#include "common.h"
+#include "dove.h"
 
 static struct mv643xx_eth_platform_data dove_db_ge00_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR_DEFAULT,
arch/arm/mach-orion/dove.c renamed from arch/arm/mach-dove/common.c +5 -5
similarity index 98%
rename from arch/arm/mach-dove/common.c
rename to arch/arm/mach-orion/dove.c
index 42ab1e7..e008c60 100644
@@ -27,11 +27,11 @@
 #include <mach/bridge-regs.h>
 #include <asm/mach/arch.h>
 #include <linux/irq.h>
-#include <plat/time.h>
-#include <plat/ehci-orion.h>
-#include <plat/common.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/time.h>
+#include <mach/ehci-orion.h>
+#include <mach/common.h>
+#include <mach/addr-map.h>
+#include "dove.h"
 
 static int get_tclk(void);
 
arch/arm/mach-orion/dove.h renamed from arch/arm/mach-dove/common.h +0 -0
similarity index 100%
rename from arch/arm/mach-dove/common.h
rename to arch/arm/mach-orion/dove.h
arch/arm/mach-orion/edmini_v2-setup.c renamed from arch/arm/mach-orion5x/edmini_v2-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/edmini_v2-setup.c
rename to arch/arm/mach-orion/edmini_v2-setup.c
index 355e962..7adbb5c 100644
@@ -35,8 +35,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * EDMINI_V2 Info
arch/arm/mach-orion/gpio.c renamed from arch/arm/plat-orion/gpio.c +0 -0
similarity index 100%
rename from arch/arm/plat-orion/gpio.c
rename to arch/arm/mach-orion/gpio.c
arch/arm/mach-orion/guruplug-setup.c renamed from arch/arm/mach-kirkwood/guruplug-setup.c +3 -3
similarity index 97%
rename from arch/arm/mach-kirkwood/guruplug-setup.c
rename to arch/arm/mach-orion/guruplug-setup.c
index bdaed38..8901101 100644
@@ -19,9 +19,9 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include <plat/mvsdio.h>
-#include "common.h"
-#include "mpp.h"
+#include <mach/mvsdio.h>
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 static struct mtd_partition guruplug_nand_parts[] = {
 	{
arch/arm/mach-orion/include/mach/addr-map.h renamed from arch/arm/plat-orion/include/plat/addr-map.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/addr-map.h
rename to arch/arm/mach-orion/include/mach/addr-map.h
arch/arm/mach-orion/include/mach/audio.h renamed from arch/arm/plat-orion/include/plat/audio.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/audio.h
rename to arch/arm/mach-orion/include/mach/audio.h
arch/arm/mach-orion/include/mach/bridge-regs-dove.h renamed from arch/arm/mach-dove/include/mach/bridge-regs.h +0 -0
similarity index 100%
rename from arch/arm/mach-dove/include/mach/bridge-regs.h
rename to arch/arm/mach-orion/include/mach/bridge-regs-dove.h
arch/arm/mach-orion/include/mach/bridge-regs-kirkwood.h renamed from arch/arm/mach-kirkwood/include/mach/bridge-regs.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/bridge-regs.h
rename to arch/arm/mach-orion/include/mach/bridge-regs-kirkwood.h
arch/arm/mach-orion/include/mach/bridge-regs-mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/bridge-regs.h +0 -0
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/bridge-regs.h
rename to arch/arm/mach-orion/include/mach/bridge-regs-mv78xx0.h
arch/arm/mach-orion/include/mach/bridge-regs-orion5x.h renamed from arch/arm/mach-orion5x/include/mach/bridge-regs.h +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/include/mach/bridge-regs.h
rename to arch/arm/mach-orion/include/mach/bridge-regs-orion5x.h
arch/arm/mach-orion/include/mach/bridge-regs.h new file +12 -0
new file mode 100644
index 0000000..29cfc01
@@ -0,0 +1,12 @@
+#ifdef CONFIG_ARCH_DOVE
+#include <mach/bridge-regs-dove.h>
+#endif
+#ifdef CONFIG_ARCH_KIRKWOOD
+#include <mach/bridge-regs-kirkwood.h>
+#endif
+#ifdef CONFIG_ARCH_MV78XX0
+#include <mach/bridge-regs-mv78xx0.h>
+#endif
+#ifdef CONFIG_ARCH_ORION5X
+#include <mach/bridge-regs-orion5x.h>
+#endif
arch/arm/mach-orion/include/mach/cache-feroceon-l2.h renamed from arch/arm/plat-orion/include/plat/cache-feroceon-l2.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/cache-feroceon-l2.h
rename to arch/arm/mach-orion/include/mach/cache-feroceon-l2.h
arch/arm/mach-orion/include/mach/common.h renamed from arch/arm/plat-orion/include/plat/common.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/common.h
rename to arch/arm/mach-orion/include/mach/common.h
arch/arm/mach-orion/include/mach/debug-macro-dove.S renamed from arch/arm/mach-dove/include/mach/debug-macro.S +0 -0
similarity index 100%
rename from arch/arm/mach-dove/include/mach/debug-macro.S
rename to arch/arm/mach-orion/include/mach/debug-macro-dove.S
arch/arm/mach-orion/include/mach/debug-macro-kirkwood.S renamed from arch/arm/mach-kirkwood/include/mach/debug-macro.S +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/debug-macro.S
rename to arch/arm/mach-orion/include/mach/debug-macro-kirkwood.S
arch/arm/mach-orion/include/mach/debug-macro-mv78xx0.S renamed from arch/arm/mach-mv78xx0/include/mach/debug-macro.S +0 -0
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/debug-macro.S
rename to arch/arm/mach-orion/include/mach/debug-macro-mv78xx0.S
arch/arm/mach-orion/include/mach/debug-macro-orion5x.S renamed from arch/arm/mach-orion5x/include/mach/debug-macro.S +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/include/mach/debug-macro.S
rename to arch/arm/mach-orion/include/mach/debug-macro-orion5x.S
arch/arm/mach-orion/include/mach/debug-macro.S new file +12 -0
new file mode 100644
index 0000000..9f1118e
@@ -0,0 +1,12 @@
+#ifdef CONFIG_ARCH_DOVE
+#include <mach/debug-macro-dove.S>
+#endif
+#ifdef CONFIG_ARCH_KIRKWOOD
+#include <mach/debug-macro-kirkwood.S>
+#endif
+#ifdef CONFIG_ARCH_MV78XX0
+#include <mach/debug-macro-mv78xx0.S>
+#endif
+#ifdef CONFIG_ARCH_ORION5X
+#include <mach/debug-macro-orion5x.S>
+#endif
arch/arm/mach-orion/include/mach/dove.h renamed from arch/arm/mach-dove/include/mach/dove.h +0 -0
similarity index 100%
rename from arch/arm/mach-dove/include/mach/dove.h
rename to arch/arm/mach-orion/include/mach/dove.h
arch/arm/mach-orion/include/mach/ehci-orion.h renamed from arch/arm/plat-orion/include/plat/ehci-orion.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/ehci-orion.h
rename to arch/arm/mach-orion/include/mach/ehci-orion.h
arch/arm/mach-orion/include/mach/entry-macro-dove.S renamed from arch/arm/mach-dove/include/mach/entry-macro.S +0 -0
similarity index 100%
rename from arch/arm/mach-dove/include/mach/entry-macro.S
rename to arch/arm/mach-orion/include/mach/entry-macro-dove.S
arch/arm/mach-orion/include/mach/entry-macro-kirkwood.S renamed from arch/arm/mach-kirkwood/include/mach/entry-macro.S +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/entry-macro.S
rename to arch/arm/mach-orion/include/mach/entry-macro-kirkwood.S
arch/arm/mach-orion/include/mach/entry-macro-mv78xx0.S renamed from arch/arm/mach-mv78xx0/include/mach/entry-macro.S +0 -0
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/entry-macro.S
rename to arch/arm/mach-orion/include/mach/entry-macro-mv78xx0.S
arch/arm/mach-orion/include/mach/entry-macro-orion5x.S renamed from arch/arm/mach-orion5x/include/mach/entry-macro.S +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/include/mach/entry-macro.S
rename to arch/arm/mach-orion/include/mach/entry-macro-orion5x.S
arch/arm/mach-orion/include/mach/entry-macro.S new file +12 -0
new file mode 100644
index 0000000..c30bac5
@@ -0,0 +1,12 @@
+#ifdef CONFIG_ARCH_DOVE
+#include <mach/entry-macro-dove.S>
+#endif
+#ifdef CONFIG_ARCH_KIRKWOOD
+#include <mach/entry-macro-kirkwood.S>
+#endif
+#ifdef CONFIG_ARCH_MV78XX0
+#include <mach/entry-macro-mv78xx0.S>
+#endif
+#ifdef CONFIG_ARCH_ORION5X
+#include <mach/entry-macro-orion5x.S>
+#endif
arch/arm/mach-orion/include/mach/gpio.h renamed from arch/arm/plat-orion/include/plat/gpio.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/gpio.h
rename to arch/arm/mach-orion/include/mach/gpio.h
arch/arm/mach-orion/include/mach/hardware.h new file +12 -0
new file mode 100644
index 0000000..c3eb636
@@ -0,0 +1,12 @@
+#ifdef CONFIG_ARCH_DOVE
+#include <mach/dove.h>
+#endif
+#ifdef CONFIG_ARCH_KIRKWOOD
+#include <mach/kirkwood.h>
+#endif
+#ifdef CONFIG_ARCH_MV78XX0
+#include <mach/mv78xx0.h>
+#endif
+#ifdef CONFIG_ARCH_ORION5X
+#include <mach/orion5x.h>
+#endif
arch/arm/mach-orion/include/mach/io-dove.h renamed from arch/arm/mach-dove/include/mach/io.h +0 -0
similarity index 100%
rename from arch/arm/mach-dove/include/mach/io.h
rename to arch/arm/mach-orion/include/mach/io-dove.h
arch/arm/mach-orion/include/mach/io-kirkwood.h renamed from arch/arm/mach-kirkwood/include/mach/io.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/io.h
rename to arch/arm/mach-orion/include/mach/io-kirkwood.h
arch/arm/mach-orion/include/mach/io-mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/io.h +0 -0
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/io.h
rename to arch/arm/mach-orion/include/mach/io-mv78xx0.h
arch/arm/mach-orion/include/mach/io.h new file +12 -0
new file mode 100644
index 0000000..044956d
@@ -0,0 +1,12 @@
+#ifdef CONFIG_ARCH_DOVE
+#include <mach/io-dove.h>
+#endif
+#ifdef CONFIG_ARCH_KIRKWOOD
+#include <mach/io-kirkwood.h>
+#endif
+#ifdef CONFIG_ARCH_MV78XX0
+#include <mach/io-mv78xx0.h>
+#endif
+#ifdef CONFIG_ARCH_ORION5X
+#include <mach/io-orion5x.h>
+#endif
arch/arm/mach-orion/include/mach/irq.h renamed from arch/arm/plat-orion/include/plat/irq.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/irq.h
rename to arch/arm/mach-orion/include/mach/irq.h
arch/arm/mach-orion/include/mach/irqs-dove.h renamed from arch/arm/mach-dove/include/mach/irqs.h +0 -0
similarity index 100%
rename from arch/arm/mach-dove/include/mach/irqs.h
rename to arch/arm/mach-orion/include/mach/irqs-dove.h
arch/arm/mach-orion/include/mach/irqs-kirkwood.h renamed from arch/arm/mach-kirkwood/include/mach/irqs.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/irqs.h
rename to arch/arm/mach-orion/include/mach/irqs-kirkwood.h
arch/arm/mach-orion/include/mach/irqs-mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/irqs.h +0 -0
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/irqs.h
rename to arch/arm/mach-orion/include/mach/irqs-mv78xx0.h
arch/arm/mach-orion/include/mach/irqs-orion5x.h renamed from arch/arm/mach-orion5x/include/mach/irqs.h +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/include/mach/irqs.h
rename to arch/arm/mach-orion/include/mach/irqs-orion5x.h
arch/arm/mach-orion/include/mach/irqs.h new file +12 -0
new file mode 100644
index 0000000..2f06667
@@ -0,0 +1,12 @@
+#ifdef CONFIG_ARCH_DOVE
+#include <mach/irqs-dove.h>
+#endif
+#ifdef CONFIG_ARCH_KIRKWOOD
+#include <mach/irqs-kirkwood.h>
+#endif
+#ifdef CONFIG_ARCH_MV78XX0
+#include <mach/irqs-mv78xx0.h>
+#endif
+#ifdef CONFIG_ARCH_ORION5X
+#include <mach/irqs-orion5x.h>
+#endif
arch/arm/mach-orion/include/mach/kirkwood.h renamed from arch/arm/mach-kirkwood/include/mach/kirkwood.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/kirkwood.h
rename to arch/arm/mach-orion/include/mach/kirkwood.h
arch/arm/mach-orion/include/mach/leds-netxbig.h renamed from arch/arm/mach-kirkwood/include/mach/leds-netxbig.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/leds-netxbig.h
rename to arch/arm/mach-orion/include/mach/leds-netxbig.h
arch/arm/mach-orion/include/mach/leds-ns2.h renamed from arch/arm/mach-kirkwood/include/mach/leds-ns2.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/leds-ns2.h
rename to arch/arm/mach-orion/include/mach/leds-ns2.h
arch/arm/mach-orion/include/mach/mpp.h renamed from arch/arm/plat-orion/include/plat/mpp.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/mpp.h
rename to arch/arm/mach-orion/include/mach/mpp.h
arch/arm/mach-orion/include/mach/mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/mv78xx0.h +0 -0
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/mv78xx0.h
rename to arch/arm/mach-orion/include/mach/mv78xx0.h
arch/arm/mach-orion/include/mach/mv_xor.h renamed from arch/arm/plat-orion/include/plat/mv_xor.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/mv_xor.h
rename to arch/arm/mach-orion/include/mach/mv_xor.h
arch/arm/mach-orion/include/mach/mvsdio.h renamed from arch/arm/plat-orion/include/plat/mvsdio.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/mvsdio.h
rename to arch/arm/mach-orion/include/mach/mvsdio.h
arch/arm/mach-orion/include/mach/orion5x.h renamed from arch/arm/mach-orion5x/include/mach/orion5x.h +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/include/mach/orion5x.h
rename to arch/arm/mach-orion/include/mach/orion5x.h
arch/arm/mach-orion/include/mach/orion_nand.h renamed from arch/arm/plat-orion/include/plat/orion_nand.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/orion_nand.h
rename to arch/arm/mach-orion/include/mach/orion_nand.h
arch/arm/mach-orion/include/mach/orion_wdt.h renamed from arch/arm/plat-orion/include/plat/orion_wdt.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/orion_wdt.h
rename to arch/arm/mach-orion/include/mach/orion_wdt.h
arch/arm/mach-orion/include/mach/pcie.h renamed from arch/arm/plat-orion/include/plat/pcie.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/pcie.h
rename to arch/arm/mach-orion/include/mach/pcie.h
arch/arm/mach-orion/include/mach/pm.h renamed from arch/arm/mach-dove/include/mach/pm.h +0 -0
similarity index 100%
rename from arch/arm/mach-dove/include/mach/pm.h
rename to arch/arm/mach-orion/include/mach/pm.h
arch/arm/mach-orion/include/mach/time.h renamed from arch/arm/plat-orion/include/plat/time.h +0 -0
similarity index 100%
rename from arch/arm/plat-orion/include/plat/time.h
rename to arch/arm/mach-orion/include/mach/time.h
arch/arm/mach-orion/include/mach/timex.h renamed from arch/arm/mach-dove/include/mach/timex.h +0 -0
similarity index 100%
rename from arch/arm/mach-dove/include/mach/timex.h
rename to arch/arm/mach-orion/include/mach/timex.h
arch/arm/mach-orion/include/mach/uncompress-dove.h renamed from arch/arm/mach-dove/include/mach/uncompress.h +0 -0
similarity index 100%
rename from arch/arm/mach-dove/include/mach/uncompress.h
rename to arch/arm/mach-orion/include/mach/uncompress-dove.h
arch/arm/mach-orion/include/mach/uncompress-kirkwood.h renamed from arch/arm/mach-kirkwood/include/mach/uncompress.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/uncompress.h
rename to arch/arm/mach-orion/include/mach/uncompress-kirkwood.h
arch/arm/mach-orion/include/mach/uncompress-mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/uncompress.h +0 -0
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/uncompress.h
rename to arch/arm/mach-orion/include/mach/uncompress-mv78xx0.h
arch/arm/mach-orion/include/mach/uncompress-orion5x.h renamed from arch/arm/mach-orion5x/include/mach/uncompress.h +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/include/mach/uncompress.h
rename to arch/arm/mach-orion/include/mach/uncompress-orion5x.h
arch/arm/mach-orion/include/mach/uncompress.h new file +12 -0
new file mode 100644
index 0000000..fa1ba53
@@ -0,0 +1,12 @@
+#ifdef CONFIG_ARCH_DOVE
+#include <mach/uncompress-dove.h>
+#endif
+#ifdef CONFIG_ARCH_KIRKWOOD
+#include <mach/uncompress-kirkwood.h>
+#endif
+#ifdef CONFIG_ARCH_MV78XX0
+#include <mach/uncompress-mv78xx0.h>
+#endif
+#ifdef CONFIG_ARCH_ORION5X
+#include <mach/uncompress-orion5x.h>
+#endif
arch/arm/mach-orion/irq-dove.c renamed from arch/arm/mach-dove/irq.c +2 -2
similarity index 98%
rename from arch/arm/mach-dove/irq.c
rename to arch/arm/mach-orion/irq-dove.c
index f07fd16..1a78639 100644
@@ -14,11 +14,11 @@
 #include <linux/gpio.h>
 #include <linux/io.h>
 #include <asm/mach/arch.h>
-#include <plat/irq.h>
+#include <mach/irq.h>
 #include <asm/mach/irq.h>
 #include <mach/pm.h>
 #include <mach/bridge-regs.h>
-#include "common.h"
+#include "dove.h"
 
 static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 {
arch/arm/mach-orion/irq-kirkwood.c renamed from arch/arm/mach-kirkwood/irq.c +2 -2
similarity index 97%
rename from arch/arm/mach-kirkwood/irq.c
rename to arch/arm/mach-orion/irq-kirkwood.c
index c4c68e5..75e124f 100644
@@ -13,8 +13,8 @@
 #include <linux/irq.h>
 #include <linux/io.h>
 #include <mach/bridge-regs.h>
-#include <plat/irq.h>
-#include "common.h"
+#include <mach/irq.h>
+#include "kirkwood.h"
 
 static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 {
arch/arm/mach-orion/irq-mv78xx0.c renamed from arch/arm/mach-mv78xx0/irq.c +2 -2
similarity index 97%
rename from arch/arm/mach-mv78xx0/irq.c
rename to arch/arm/mach-orion/irq-mv78xx0.c
index e421b70..695ae9b 100644
@@ -13,8 +13,8 @@
 #include <linux/pci.h>
 #include <linux/irq.h>
 #include <mach/bridge-regs.h>
-#include <plat/irq.h>
-#include "common.h"
+#include <mach/irq.h>
+#include "mv78xx0.h"
 
 static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 {
arch/arm/mach-orion/irq-orion5x.c renamed from arch/arm/mach-orion5x/irq.c +2 -2
similarity index 96%
rename from arch/arm/mach-orion5x/irq.c
rename to arch/arm/mach-orion/irq-orion5x.c
index b1b45ff..6d1f1f7 100644
@@ -15,8 +15,8 @@
 #include <linux/irq.h>
 #include <linux/io.h>
 #include <mach/bridge-regs.h>
-#include <plat/irq.h>
-#include "common.h"
+#include <mach/irq.h>
+#include "orion5x.h"
 
 static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 {
arch/arm/mach-orion/irq.c renamed from arch/arm/plat-orion/irq.c +1 -1
similarity index 97%
rename from arch/arm/plat-orion/irq.c
rename to arch/arm/mach-orion/irq.c
index 2d5b9c1..b108805 100644
@@ -12,7 +12,7 @@
 #include <linux/init.h>
 #include <linux/irq.h>
 #include <linux/io.h>
-#include <plat/irq.h>
+#include <mach/irq.h>
 
 void __init orion_irq_init(unsigned int irq_start, void __iomem *maskaddr)
 {
arch/arm/mach-orion/kirkwood.c renamed from arch/arm/mach-kirkwood/common.c +9 -9
similarity index 98%
rename from arch/arm/mach-kirkwood/common.c
rename to arch/arm/mach-orion/kirkwood.c
index 3ad0373..3dd3b3f 100644
@@ -24,15 +24,15 @@
 #include <asm/mach/time.h>
 #include <mach/kirkwood.h>
 #include <mach/bridge-regs.h>
-#include <plat/audio.h>
-#include <plat/cache-feroceon-l2.h>
-#include <plat/mvsdio.h>
-#include <plat/orion_nand.h>
-#include <plat/ehci-orion.h>
-#include <plat/common.h>
-#include <plat/time.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/audio.h>
+#include <mach/cache-feroceon-l2.h>
+#include <mach/mvsdio.h>
+#include <mach/orion_nand.h>
+#include <mach/ehci-orion.h>
+#include <mach/common.h>
+#include <mach/time.h>
+#include <mach/addr-map.h>
+#include "kirkwood.h"
 
 /*****************************************************************************
  * I/O Address Mapping
arch/arm/mach-orion/kirkwood.h renamed from arch/arm/mach-kirkwood/common.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/common.h
rename to arch/arm/mach-orion/kirkwood.h
arch/arm/mach-orion/kurobox_pro-setup.c renamed from arch/arm/mach-orion5x/kurobox_pro-setup.c +3 -3
similarity index 99%
rename from arch/arm/mach-orion5x/kurobox_pro-setup.c
rename to arch/arm/mach-orion/kurobox_pro-setup.c
index 47587b8..827d446 100644
@@ -24,9 +24,9 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include <plat/orion_nand.h>
-#include "common.h"
-#include "mpp.h"
+#include <mach/orion_nand.h>
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * KUROBOX-PRO Info
arch/arm/mach-orion/lacie_v2-common.c renamed from arch/arm/mach-kirkwood/lacie_v2-common.c +2 -2
similarity index 98%
rename from arch/arm/mach-kirkwood/lacie_v2-common.c
rename to arch/arm/mach-orion/lacie_v2-common.c
index 285edab..21aca25 100644
@@ -17,8 +17,8 @@
 #include <asm/mach/time.h>
 #include <mach/kirkwood.h>
 #include <mach/irqs.h>
-#include <plat/time.h>
-#include "common.h"
+#include <mach/time.h>
+#include "kirkwood.h"
 
 /*****************************************************************************
  * 512KB SPI Flash on Boot Device (MACRONIX MX25L4005)
arch/arm/mach-orion/lacie_v2-common.h renamed from arch/arm/mach-kirkwood/lacie_v2-common.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/lacie_v2-common.h
rename to arch/arm/mach-orion/lacie_v2-common.h
arch/arm/mach-orion/ls-chl-setup.c renamed from arch/arm/mach-orion5x/ls-chl-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/ls-chl-setup.c
rename to arch/arm/mach-orion/ls-chl-setup.c
index 0c9e413..48f0c39 100644
@@ -23,8 +23,8 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * Linkstation LS-CHL Info
arch/arm/mach-orion/ls_hgl-setup.c renamed from arch/arm/mach-orion5x/ls_hgl-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/ls_hgl-setup.c
rename to arch/arm/mach-orion/ls_hgl-setup.c
index c1b5d8a..af617d8 100644
@@ -22,8 +22,8 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * Linkstation LS-HGL Info
arch/arm/mach-orion/lsmini-setup.c renamed from arch/arm/mach-orion5x/lsmini-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/lsmini-setup.c
rename to arch/arm/mach-orion/lsmini-setup.c
index 949eaa8..52b2f9d 100644
@@ -22,8 +22,8 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * Linkstation Mini Info
arch/arm/mach-orion/mpp-dove.c renamed from arch/arm/mach-dove/mpp.c +2 -2
similarity index 98%
rename from arch/arm/mach-dove/mpp.c
rename to arch/arm/mach-orion/mpp-dove.c
index 7f70afc..fa36a48 100644
@@ -11,9 +11,9 @@
 #include <linux/kernel.h>
 #include <linux/gpio.h>
 #include <linux/io.h>
-#include <plat/mpp.h>
+#include <mach/mpp.h>
 #include <mach/dove.h>
-#include "mpp.h"
+#include "mpp-dove.h"
 
 struct dove_mpp_grp {
 	int start;
arch/arm/mach-orion/mpp-dove.h renamed from arch/arm/mach-dove/mpp.h +0 -0
similarity index 100%
rename from arch/arm/mach-dove/mpp.h
rename to arch/arm/mach-orion/mpp-dove.h
arch/arm/mach-orion/mpp-kirkwood.c renamed from arch/arm/mach-kirkwood/mpp.c +3 -3
similarity index 93%
rename from arch/arm/mach-kirkwood/mpp.c
rename to arch/arm/mach-orion/mpp-kirkwood.c
index 0c6ad63..da21b1b 100644
@@ -12,9 +12,9 @@
 #include <linux/init.h>
 #include <linux/io.h>
 #include <mach/hardware.h>
-#include <plat/mpp.h>
-#include "common.h"
-#include "mpp.h"
+#include <mach/mpp.h>
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 static unsigned int __init kirkwood_variant(void)
 {
arch/arm/mach-orion/mpp-kirkwood.h renamed from arch/arm/mach-kirkwood/mpp.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/mpp.h
rename to arch/arm/mach-orion/mpp-kirkwood.h
arch/arm/mach-orion/mpp-mv78xx0.c renamed from arch/arm/mach-mv78xx0/mpp.c +3 -3
similarity index 92%
rename from arch/arm/mach-mv78xx0/mpp.c
rename to arch/arm/mach-orion/mpp-mv78xx0.c
index df50342..9d785d3 100644
@@ -11,10 +11,10 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
-#include <plat/mpp.h>
+#include <mach/mpp.h>
 #include <mach/hardware.h>
-#include "common.h"
-#include "mpp.h"
+#include "mv78xx0.h"
+#include "mpp-mv78xx0.h"
 
 static unsigned int __init mv78xx0_variant(void)
 {
arch/arm/mach-orion/mpp-mv78xx0.h renamed from arch/arm/mach-mv78xx0/mpp.h +0 -0
similarity index 100%
rename from arch/arm/mach-mv78xx0/mpp.h
rename to arch/arm/mach-orion/mpp-mv78xx0.h
arch/arm/mach-orion/mpp-orion5x.c renamed from arch/arm/mach-orion5x/mpp.c +3 -3
similarity index 93%
rename from arch/arm/mach-orion5x/mpp.c
rename to arch/arm/mach-orion/mpp-orion5x.c
index 5b70026..2706cfc 100644
@@ -12,9 +12,9 @@
 #include <linux/init.h>
 #include <linux/io.h>
 #include <mach/hardware.h>
-#include <plat/mpp.h>
-#include "mpp.h"
-#include "common.h"
+#include <mach/mpp.h>
+#include "mpp-orion5x.h"
+#include "orion5x.h"
 
 static unsigned int __init orion5x_variant(void)
 {
arch/arm/mach-orion/mpp-orion5x.h renamed from arch/arm/mach-orion5x/mpp.h +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/mpp.h
rename to arch/arm/mach-orion/mpp-orion5x.h
arch/arm/mach-orion/mpp.c renamed from arch/arm/plat-orion/mpp.c +1 -1
similarity index 98%
rename from arch/arm/plat-orion/mpp.c
rename to arch/arm/mach-orion/mpp.c
index 3b1e17b..137c622 100644
@@ -14,7 +14,7 @@
 #include <linux/io.h>
 #include <linux/gpio.h>
 #include <mach/hardware.h>
-#include <plat/mpp.h>
+#include <mach/mpp.h>
 
 /* Address of the ith MPP control register */
 static __init unsigned long mpp_ctrl_addr(unsigned int i,
arch/arm/mach-orion/mss2-setup.c renamed from arch/arm/mach-orion5x/mss2-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/mss2-setup.c
rename to arch/arm/mach-orion/mss2-setup.c
index 65faaa3..529f745 100644
@@ -27,8 +27,8 @@
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
 #include <mach/bridge-regs.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 #define MSS2_NOR_BOOT_BASE	0xff800000
 #define MSS2_NOR_BOOT_SIZE	SZ_256K
arch/arm/mach-orion/mv2120-setup.c renamed from arch/arm/mach-orion5x/mv2120-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/mv2120-setup.c
rename to arch/arm/mach-orion/mv2120-setup.c
index c87fde4..89e29de 100644
@@ -22,8 +22,8 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 #define MV2120_NOR_BOOT_BASE	0xf4000000
 #define MV2120_NOR_BOOT_SIZE	SZ_512K
arch/arm/mach-orion/mv78xx0.c renamed from arch/arm/mach-mv78xx0/common.c +7 -7
similarity index 98%
rename from arch/arm/mach-mv78xx0/common.c
rename to arch/arm/mach-orion/mv78xx0.c
index a5dcf766..a4bfa12 100644
@@ -18,13 +18,13 @@
 #include <asm/mach/time.h>
 #include <mach/mv78xx0.h>
 #include <mach/bridge-regs.h>
-#include <plat/cache-feroceon-l2.h>
-#include <plat/ehci-orion.h>
-#include <plat/orion_nand.h>
-#include <plat/time.h>
-#include <plat/common.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/cache-feroceon-l2.h>
+#include <mach/ehci-orion.h>
+#include <mach/orion_nand.h>
+#include <mach/time.h>
+#include <mach/common.h>
+#include <mach/addr-map.h>
+#include "mv78xx0.h"
 
 static int get_tclk(void);
 
arch/arm/mach-orion/mv78xx0.h renamed from arch/arm/mach-mv78xx0/common.h +0 -0
similarity index 100%
rename from arch/arm/mach-mv78xx0/common.h
rename to arch/arm/mach-orion/mv78xx0.h
arch/arm/mach-orion/mv88f6281gtw_ge-setup.c renamed from arch/arm/mach-kirkwood/mv88f6281gtw_ge-setup.c +2 -2
similarity index 98%
rename from arch/arm/mach-kirkwood/mv88f6281gtw_ge-setup.c
rename to arch/arm/mach-orion/mv88f6281gtw_ge-setup.c
index 85f6169..ec3a7b3 100644
@@ -29,8 +29,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/kirkwood.h>
-#include "common.h"
-#include "mpp.h"
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 static struct mv643xx_eth_platform_data mv88f6281gtw_ge_ge00_data = {
 	.phy_addr	= MV643XX_ETH_PHY_NONE,
arch/arm/mach-orion/net2big-setup.c renamed from arch/arm/mach-orion5x/net2big-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/net2big-setup.c
rename to arch/arm/mach-orion/net2big-setup.c
index 0180c39..c56e1c4 100644
@@ -25,8 +25,8 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * LaCie 2Big Network Info
arch/arm/mach-orion/netspace_v2-setup.c renamed from arch/arm/mach-kirkwood/netspace_v2-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-kirkwood/netspace_v2-setup.c
rename to arch/arm/mach-orion/netspace_v2-setup.c
index e6bba01..3c5d210 100644
@@ -35,8 +35,8 @@
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
 #include <mach/leds-ns2.h>
-#include "common.h"
-#include "mpp.h"
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 #include "lacie_v2-common.h"
 
 /*****************************************************************************
arch/arm/mach-orion/netxbig_v2-setup.c renamed from arch/arm/mach-kirkwood/netxbig_v2-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-kirkwood/netxbig_v2-setup.c
rename to arch/arm/mach-orion/netxbig_v2-setup.c
index 31ae8de..a5e443e 100644
@@ -33,8 +33,8 @@
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
 #include <mach/leds-netxbig.h>
-#include "common.h"
-#include "mpp.h"
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 #include "lacie_v2-common.h"
 
 /*****************************************************************************
arch/arm/mach-orion/openrd-setup.c renamed from arch/arm/mach-kirkwood/openrd-setup.c +3 -3
similarity index 98%
rename from arch/arm/mach-kirkwood/openrd-setup.c
rename to arch/arm/mach-orion/openrd-setup.c
index 7e99c3f..229b266 100644
@@ -20,9 +20,9 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include <plat/mvsdio.h>
-#include "common.h"
-#include "mpp.h"
+#include <mach/mvsdio.h>
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 static struct mtd_partition openrd_nand_parts[] = {
 	{
arch/arm/mach-orion/orion5x.c renamed from arch/arm/mach-orion5x/common.c +6 -6
similarity index 98%
rename from arch/arm/mach-orion5x/common.c
rename to arch/arm/mach-orion/orion5x.c
index e2e9db4..8e0c16b 100644
@@ -29,12 +29,12 @@
 #include <mach/bridge-regs.h>
 #include <mach/hardware.h>
 #include <mach/orion5x.h>
-#include <plat/orion_nand.h>
-#include <plat/ehci-orion.h>
-#include <plat/time.h>
-#include <plat/common.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/orion_nand.h>
+#include <mach/ehci-orion.h>
+#include <mach/time.h>
+#include <mach/common.h>
+#include <mach/addr-map.h>
+#include "orion5x.h"
 
 /*****************************************************************************
  * I/O Address Mapping
arch/arm/mach-orion/orion5x.h renamed from arch/arm/mach-orion5x/common.h +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/common.h
rename to arch/arm/mach-orion/orion5x.h
arch/arm/mach-orion/pci-orion5x.c renamed from arch/arm/mach-orion5x/pci.c +3 -3
similarity index 99%
rename from arch/arm/mach-orion5x/pci.c
rename to arch/arm/mach-orion/pci-orion5x.c
index cb19e16..a545ae0 100644
@@ -17,10 +17,10 @@
 #include <video/vga.h>
 #include <asm/irq.h>
 #include <asm/mach/pci.h>
-#include <plat/pcie.h>
-#include <plat/addr-map.h>
+#include <mach/pcie.h>
+#include <mach/addr-map.h>
 #include <mach/orion5x.h>
-#include "common.h"
+#include "orion5x.h"
 
 /*****************************************************************************
  * Orion has one PCIe controller and one PCI controller.
arch/arm/mach-orion/pcie-dove.c renamed from arch/arm/mach-dove/pcie.c +3 -3
similarity index 98%
rename from arch/arm/mach-dove/pcie.c
rename to arch/arm/mach-orion/pcie-dove.c
index 48a0320..57134be 100644
@@ -15,11 +15,11 @@
 #include <asm/mach/arch.h>
 #include <asm/setup.h>
 #include <asm/delay.h>
-#include <plat/pcie.h>
+#include <mach/pcie.h>
 #include <mach/irqs.h>
 #include <mach/bridge-regs.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/addr-map.h>
+#include "dove.h"
 
 struct pcie_port {
 	u8			index;
arch/arm/mach-orion/pcie-kirkwood.c renamed from arch/arm/mach-kirkwood/pcie.c +3 -3
similarity index 98%
rename from arch/arm/mach-kirkwood/pcie.c
rename to arch/arm/mach-orion/pcie-kirkwood.c
index f56a011..2b65cb4 100644
@@ -14,10 +14,10 @@
 #include <video/vga.h>
 #include <asm/irq.h>
 #include <asm/mach/pci.h>
-#include <plat/pcie.h>
+#include <mach/pcie.h>
 #include <mach/bridge-regs.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/addr-map.h>
+#include "kirkwood.h"
 
 void kirkwood_enable_pcie(void)
 {
arch/arm/mach-orion/pcie-mv78xx0.c renamed from arch/arm/mach-mv78xx0/pcie.c +3 -3
similarity index 99%
rename from arch/arm/mach-mv78xx0/pcie.c
rename to arch/arm/mach-orion/pcie-mv78xx0.c
index df3e380..c9616bf 100644
@@ -13,9 +13,9 @@
 #include <video/vga.h>
 #include <asm/irq.h>
 #include <asm/mach/pci.h>
-#include <plat/pcie.h>
-#include <plat/addr-map.h>
-#include "common.h"
+#include <mach/pcie.h>
+#include <mach/addr-map.h>
+#include "mv78xx0.h"
 
 struct pcie_port {
 	u8			maj;
arch/arm/mach-orion/pcie.c renamed from arch/arm/plat-orion/pcie.c +2 -2
similarity index 99%
rename from arch/arm/plat-orion/pcie.c
rename to arch/arm/mach-orion/pcie.c
index 86dbb5b..921333a 100644
@@ -12,8 +12,8 @@
 #include <linux/pci.h>
 #include <linux/mbus.h>
 #include <asm/mach/pci.h>
-#include <plat/pcie.h>
-#include <plat/addr-map.h>
+#include <mach/pcie.h>
+#include <mach/addr-map.h>
 #include <linux/delay.h>
 
 /*
arch/arm/mach-orion/rd78x00-masa-setup.c renamed from arch/arm/mach-mv78xx0/rd78x00-masa-setup.c +1 -1
similarity index 99%
rename from arch/arm/mach-mv78xx0/rd78x00-masa-setup.c
rename to arch/arm/mach-orion/rd78x00-masa-setup.c
index 9a88270..1e53e29 100644
@@ -17,7 +17,7 @@
 #include <mach/mv78xx0.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
-#include "common.h"
+#include "mv78xx0.h"
 
 static struct mv643xx_eth_platform_data rd78x00_masa_ge00_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR(8),
arch/arm/mach-orion/rd88f5181l-fxo-setup.c renamed from arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
rename to arch/arm/mach-orion/rd88f5181l-fxo-setup.c
index 292038f..b5a5c8a 100644
@@ -22,8 +22,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * RD-88F5181L FXO Info
arch/arm/mach-orion/rd88f5181l-ge-setup.c renamed from arch/arm/mach-orion5x/rd88f5181l-ge-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
rename to arch/arm/mach-orion/rd88f5181l-ge-setup.c
index c44eaba..9802382 100644
@@ -23,8 +23,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * RD-88F5181L GE Info
arch/arm/mach-orion/rd88f5182-setup.c renamed from arch/arm/mach-orion5x/rd88f5182-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/rd88f5182-setup.c
rename to arch/arm/mach-orion/rd88f5182-setup.c
index e3ce617..ac2fcaa 100644
@@ -24,8 +24,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * RD-88F5182 Info
arch/arm/mach-orion/rd88f6183ap-ge-setup.c renamed from arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c +1 -1
similarity index 99%
rename from arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
rename to arch/arm/mach-orion/rd88f6183ap-ge-setup.c
index 2c5fab0..25e5727 100644
@@ -25,7 +25,7 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
+#include "orion5x.h"
 
 static struct mv643xx_eth_platform_data rd88f6183ap_ge_eth_data = {
 	.phy_addr	= -1,
arch/arm/mach-orion/rd88f6192-nas-setup.c renamed from arch/arm/mach-kirkwood/rd88f6192-nas-setup.c +1 -1
similarity index 99%
rename from arch/arm/mach-kirkwood/rd88f6192-nas-setup.c
rename to arch/arm/mach-orion/rd88f6192-nas-setup.c
index fd2c9c8..8f37693 100644
@@ -20,7 +20,7 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include "common.h"
+#include "kirkwood.h"
 
 #define RD88F6192_GPIO_USB_VBUS		10
 
arch/arm/mach-orion/rd88f6281-setup.c renamed from arch/arm/mach-kirkwood/rd88f6281-setup.c +3 -3
similarity index 97%
rename from arch/arm/mach-kirkwood/rd88f6281-setup.c
rename to arch/arm/mach-orion/rd88f6281-setup.c
index ef92207..5dbdec9 100644
@@ -20,9 +20,9 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include <plat/mvsdio.h>
-#include "common.h"
-#include "mpp.h"
+#include <mach/mvsdio.h>
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 static struct mtd_partition rd88f6281_nand_parts[] = {
 	{
arch/arm/mach-orion/sheevaplug-setup.c renamed from arch/arm/mach-kirkwood/sheevaplug-setup.c +3 -3
similarity index 98%
rename from arch/arm/mach-kirkwood/sheevaplug-setup.c
rename to arch/arm/mach-orion/sheevaplug-setup.c
index 4ea70e5f..5c128fa 100644
@@ -19,9 +19,9 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include <plat/mvsdio.h>
-#include "common.h"
-#include "mpp.h"
+#include <mach/mvsdio.h>
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 static struct mtd_partition sheevaplug_nand_parts[] = {
 	{
arch/arm/mach-orion/t5325-setup.c renamed from arch/arm/mach-kirkwood/t5325-setup.c +2 -2
similarity index 98%
rename from arch/arm/mach-kirkwood/t5325-setup.c
rename to arch/arm/mach-orion/t5325-setup.c
index f9d2a11..7d7f5a0 100644
@@ -27,8 +27,8 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include "common.h"
-#include "mpp.h"
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 
 struct mtd_partition hp_t5325_partitions[] = {
 	{
arch/arm/mach-orion/terastation_pro2-setup.c renamed from arch/arm/mach-orion5x/terastation_pro2-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/terastation_pro2-setup.c
rename to arch/arm/mach-orion/terastation_pro2-setup.c
index 632a861..7dcb50e 100644
@@ -23,8 +23,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*****************************************************************************
  * Terastation Pro 2/Live Info
arch/arm/mach-orion/time.c renamed from arch/arm/plat-orion/time.c +0 -0
similarity index 100%
rename from arch/arm/plat-orion/time.c
rename to arch/arm/mach-orion/time.c
arch/arm/mach-orion/ts209-setup.c renamed from arch/arm/mach-orion5x/ts209-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/ts209-setup.c
rename to arch/arm/mach-orion/ts209-setup.c
index 5d64087..3686739 100644
@@ -26,8 +26,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 #include "tsx09-common.h"
 
 #define QNAP_TS209_NOR_BOOT_BASE 0xf4000000
arch/arm/mach-orion/ts219-setup.c renamed from arch/arm/mach-kirkwood/ts219-setup.c +2 -2
similarity index 98%
rename from arch/arm/mach-kirkwood/ts219-setup.c
rename to arch/arm/mach-orion/ts219-setup.c
index 73e2b6c..32b118d 100644
@@ -22,8 +22,8 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include "common.h"
-#include "mpp.h"
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 #include "tsx1x-common.h"
 
 static struct i2c_board_info __initdata qnap_ts219_i2c_rtc = {
arch/arm/mach-orion/ts409-setup.c renamed from arch/arm/mach-orion5x/ts409-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/ts409-setup.c
rename to arch/arm/mach-orion/ts409-setup.c
index 4e6ff75..de31108 100644
@@ -28,8 +28,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 #include "tsx09-common.h"
 
 /*****************************************************************************
arch/arm/mach-orion/ts41x-setup.c renamed from arch/arm/mach-kirkwood/ts41x-setup.c +3 -3
similarity index 98%
rename from arch/arm/mach-kirkwood/ts41x-setup.c
rename to arch/arm/mach-orion/ts41x-setup.c
index 5bbca26..d121b63 100644
@@ -23,12 +23,12 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include "common.h"
-#include "mpp.h"
+#include "kirkwood.h"
+#include "mpp-kirkwood.h"
 #include "tsx1x-common.h"
 
 /* for the PCIe reset workaround */
-#include <plat/pcie.h>
+#include <mach/pcie.h>
 
 
 #define QNAP_TS41X_JUMPER_JP1	45
arch/arm/mach-orion/ts78xx-fpga.h renamed from arch/arm/mach-orion5x/ts78xx-fpga.h +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/ts78xx-fpga.h
rename to arch/arm/mach-orion/ts78xx-fpga.h
arch/arm/mach-orion/ts78xx-setup.c renamed from arch/arm/mach-orion5x/ts78xx-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/ts78xx-setup.c
rename to arch/arm/mach-orion/ts78xx-setup.c
index a74f3cf..4040a76 100644
@@ -24,8 +24,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 #include "ts78xx-fpga.h"
 
 /*****************************************************************************
arch/arm/mach-orion/tsx09-common.c renamed from arch/arm/mach-orion5x/tsx09-common.c +1 -1
similarity index 99%
rename from arch/arm/mach-orion5x/tsx09-common.c
rename to arch/arm/mach-orion/tsx09-common.c
index 7189827..ee3aaec 100644
@@ -17,7 +17,7 @@
 #include <linux/serial_reg.h>
 #include <mach/orion5x.h>
 #include "tsx09-common.h"
-#include "common.h"
+#include "orion5x.h"
 
 /*****************************************************************************
  * QNAP TS-x09 specific power off method via UART1-attached PIC
arch/arm/mach-orion/tsx09-common.h renamed from arch/arm/mach-orion5x/tsx09-common.h +0 -0
similarity index 100%
rename from arch/arm/mach-orion5x/tsx09-common.h
rename to arch/arm/mach-orion/tsx09-common.h
arch/arm/mach-orion/tsx1x-common.c renamed from arch/arm/mach-kirkwood/tsx1x-common.c +1 -1
similarity index 99%
rename from arch/arm/mach-kirkwood/tsx1x-common.c
rename to arch/arm/mach-orion/tsx1x-common.c
index 24294b2..49c1d16 100644
@@ -7,7 +7,7 @@
 #include <linux/spi/orion_spi.h>
 #include <linux/serial_reg.h>
 #include <mach/kirkwood.h>
-#include "common.h"
+#include "kirkwood.h"
 
 /*
  * QNAP TS-x1x Boards flash
arch/arm/mach-orion/tsx1x-common.h renamed from arch/arm/mach-kirkwood/tsx1x-common.h +0 -0
similarity index 100%
rename from arch/arm/mach-kirkwood/tsx1x-common.h
rename to arch/arm/mach-orion/tsx1x-common.h
arch/arm/mach-orion/wnr854t-setup.c renamed from arch/arm/mach-orion5x/wnr854t-setup.c +2 -2
similarity index 98%
rename from arch/arm/mach-orion5x/wnr854t-setup.c
rename to arch/arm/mach-orion/wnr854t-setup.c
index 078c03f..cf11e60 100644
@@ -20,8 +20,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 static unsigned int wnr854t_mpp_modes[] __initdata = {
 	MPP0_GPIO,		/* Power LED green (0=on) */
arch/arm/mach-orion/wrt350n-v2-setup.c renamed from arch/arm/mach-orion5x/wrt350n-v2-setup.c +2 -2
similarity index 99%
rename from arch/arm/mach-orion5x/wrt350n-v2-setup.c
rename to arch/arm/mach-orion/wrt350n-v2-setup.c
index 46a9778..a435be2 100644
@@ -23,8 +23,8 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/pci.h>
 #include <mach/orion5x.h>
-#include "common.h"
-#include "mpp.h"
+#include "orion5x.h"
+#include "mpp-orion5x.h"
 
 /*
  * LEDs attached to GPIO
arch/arm/mach-orion5x/Makefile.boot deleted +0 -3
deleted file mode 100644
index 760a0ef..0000000
@@ -1,3 +0,0 @@
-   zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00800000
arch/arm/mach-orion5x/include/mach/gpio.h deleted +0 -9
deleted file mode 100644
index a1d0b78..0000000
@@ -1,9 +0,0 @@
-/*
- * arch/arm/mach-orion5x/include/mach/gpio.h
- *
- * 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 <plat/gpio.h>
arch/arm/mach-orion5x/include/mach/hardware.h deleted +0 -14
deleted file mode 100644
index 3957354..0000000
@@ -1,14 +0,0 @@
-/*
- * arch/arm/mach-orion5x/include/mach/hardware.h
- *
- * 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.
- */
-
-#ifndef __ASM_ARCH_HARDWARE_H
-#define __ASM_ARCH_HARDWARE_H
-
-#include "orion5x.h"
-
-#endif
arch/arm/mach-orion5x/include/mach/timex.h deleted +0 -11
deleted file mode 100644
index 4c69820..0000000
@@ -1,11 +0,0 @@
-/*
- * arch/arm/mach-orion5x/include/mach/timex.h
- *
- * Tzachi Perelstein <[email protected]>
- *
- * 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)
arch/arm/mm/cache-feroceon-l2.c +1 -1
index dd3d591..2ace351 100644
@@ -16,7 +16,7 @@
 #include <linux/highmem.h>
 #include <asm/cacheflush.h>
 #include <asm/cp15.h>
-#include <plat/cache-feroceon-l2.h>
+#include <mach/cache-feroceon-l2.h>
 
 /*
  * Low-level cache maintenance operations.
arch/arm/plat-orion/Makefile deleted +0 -10
deleted file mode 100644
index c20ce0f..0000000
@@ -1,10 +0,0 @@
-#
-# Makefile for the linux kernel.
-#
-
-obj-y	:= irq.o pcie.o time.o common.o mpp.o addr-map.o
-obj-m	:=
-obj-n	:=
-obj-	:=
-
-obj-$(CONFIG_GENERIC_GPIO) += gpio.o
drivers/dma/mv_xor.c +1 -1
index fa5d55f..425e972 100644
@@ -25,7 +25,7 @@
 #include <linux/interrupt.h>
 #include <linux/platform_device.h>
 #include <linux/memory.h>
-#include <plat/mv_xor.h>
+#include <mach/mv_xor.h>
 
 #include "dmaengine.h"
 #include "mv_xor.h"
drivers/mmc/host/mvsdio.c +1 -1
index eeb8cd1..7d2daff 100644
@@ -24,7 +24,7 @@
 
 #include <asm/sizes.h>
 #include <asm/unaligned.h>
-#include <plat/mvsdio.h>
+#include <mach/mvsdio.h>
 
 #include "mvsdio.h"
 
drivers/mtd/nand/orion_nand.c +1 -1
index 0f50ef3..407f43d 100644
@@ -20,7 +20,7 @@
 #include <asm/io.h>
 #include <asm/sizes.h>
 #include <mach/hardware.h>
-#include <plat/orion_nand.h>
+#include <mach/orion_nand.h>
 
 static void orion_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
drivers/usb/host/ehci-orion.c +1 -1
index 6c6a5a3..7b6eccb 100644
@@ -12,7 +12,7 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/mbus.h>
-#include <plat/ehci-orion.h>
+#include <mach/ehci-orion.h>
 
 #define rdl(off)	__raw_readl(hcd->regs + (off))
 #define wrl(off, val)	__raw_writel((val), hcd->regs + (off))
drivers/watchdog/orion_wdt.c +1 -1
index 788aa15..a26bbb5 100644
@@ -25,7 +25,7 @@
 #include <linux/io.h>
 #include <linux/spinlock.h>
 #include <mach/bridge-regs.h>
-#include <plat/orion_wdt.h>
+#include <mach/orion_wdt.h>
 
 /*
  * Watchdog timer block registers.
sound/soc/kirkwood/kirkwood-i2s.c +1 -1
index 3cb9aa4..49db36c 100644
@@ -20,7 +20,7 @@
 #include <sound/pcm.h>
 #include <sound/pcm_params.h>
 #include <sound/soc.h>
-#include <plat/audio.h>
+#include <mach/audio.h>
 #include "kirkwood.h"
 
 #define DRV_NAME	"kirkwood-i2s"
sound/soc/kirkwood/kirkwood-openrd.c +1 -1
index 80bd59c..778b1dd 100644
@@ -17,7 +17,7 @@
 #include <linux/slab.h>
 #include <sound/soc.h>
 #include <mach/kirkwood.h>
-#include <plat/audio.h>
+#include <mach/audio.h>
 #include <asm/mach-types.h>
 #include "../codecs/cs42l51.h"
 
sound/soc/kirkwood/kirkwood-t5325.c +1 -1
index f898363..e3c7b32 100644
@@ -16,7 +16,7 @@
 #include <linux/slab.h>
 #include <sound/soc.h>
 #include <mach/kirkwood.h>
-#include <plat/audio.h>
+#include <mach/audio.h>
 #include <asm/mach-types.h>
 #include "../codecs/alc5623.h"
 
maintainer
#77 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 22 lines · Arnd Bergmann
Quoted 8 lines · Arnd Bergmann

Another way would be to reorganize those directories upfront:

plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.h

and then go from there. The differences between the headers are fairly small already, so that should be manageable.

Actually we could do a trivial move of all files into one directory at any time, e.g. at the end of the merge window, to minimize conflicts with other patches.

This is a semi-automated move of all plat-orion based machines into a single mach-orion directory, and we could of course add the new stuff in there as well. I've specifically tried to keep this move simple, even if that means a lot of the easy cleanups for code that are mostly identical are not done here. Cleanups after this could come one at a time to reduce this duplication and simplify the platform.

Quoted 4 lines

Obvious next steps are to merge the various Makefile and Kconfig files as well as all the headers, and to actually allow building stuff together.

The problematic Armada naming issue simply goes away.

Quoted 113 lines
 arch/arm/mach-dove/Makefile.boot                 |    3 --
 arch/arm/mach-dove/include/mach/gpio.h           |    9 -------
 arch/arm/mach-dove/include/mach/hardware.h       |   19 ----------------
 arch/arm/mach-kirkwood/include/mach/gpio.h       |    9 -------
 arch/arm/mach-kirkwood/include/mach/hardware.h   |   14 ------------
 arch/arm/mach-kirkwood/include/mach/timex.h      |   10 --------
 arch/arm/mach-mv78xx0/Makefile.boot              |    3 --
 arch/arm/mach-mv78xx0/include/mach/gpio.h        |    9 -------
 arch/arm/mach-mv78xx0/include/mach/hardware.h    |   14 ------------
 arch/arm/mach-mv78xx0/include/mach/timex.h       |    9 -------
 arch/arm/mach-orion5x/Makefile.boot              |    3 --
 arch/arm/mach-orion5x/include/mach/gpio.h        |    9 -------
 arch/arm/mach-orion5x/include/mach/hardware.h    |   14 ------------
 arch/arm/mach-orion5x/include/mach/timex.h       |   11 ---------
 arch/arm/plat-orion/Makefile                     |   10 --------
 b/arch/arm/Kconfig                               |    8 -------
 b/arch/arm/Makefile                              |    9 +++----
 b/arch/arm/mach-orion/Kconfig                    |    7 ++++++
 b/arch/arm/mach-orion/Makefile                   |   26 +++++++++++++++++++++++
 b/arch/arm/mach-orion/Makefile.dove              |    2 -
 b/arch/arm/mach-orion/Makefile.kirkwood          |    2 -
 b/arch/arm/mach-orion/Makefile.mv78xx0           |    2 -
 b/arch/arm/mach-orion/Makefile.orion5x           |    2 -
 b/arch/arm/mach-orion/addr-map-dove.c            |    4 +--
 b/arch/arm/mach-orion/addr-map-kirkwood.c        |    4 +--
 b/arch/arm/mach-orion/addr-map-mv78xx0.c         |    4 +--
 b/arch/arm/mach-orion/addr-map-orion5x.c         |    4 +--
 b/arch/arm/mach-orion/addr-map.c                 |    2 -
 b/arch/arm/mach-orion/board-dnskw.c              |    4 +--
 b/arch/arm/mach-orion/board-dreamplug.c          |    6 ++---
 b/arch/arm/mach-orion/board-dt.c                 |    2 -
 b/arch/arm/mach-orion/board-ib62x0.c             |    4 +--
 b/arch/arm/mach-orion/board-iconnect.c           |    4 +--
 b/arch/arm/mach-orion/buffalo-wxl-setup.c        |    4 +--
 b/arch/arm/mach-orion/cm-a510.c                  |    2 -
 b/arch/arm/mach-orion/common.c                   |    6 ++---
 b/arch/arm/mach-orion/d2net-setup.c              |    4 +--
 b/arch/arm/mach-orion/d2net_v2-setup.c           |    4 +--
 b/arch/arm/mach-orion/db78x00-bp-setup.c         |    2 -
 b/arch/arm/mach-orion/db88f5281-setup.c          |    6 ++---
 b/arch/arm/mach-orion/db88f6281-bp-setup.c       |    6 ++---
 b/arch/arm/mach-orion/dns323-setup.c             |    4 +--
 b/arch/arm/mach-orion/dockstar-setup.c           |    6 ++---
 b/arch/arm/mach-orion/dove-db-setup.c            |    2 -
 b/arch/arm/mach-orion/dove.c                     |   10 ++++----
 b/arch/arm/mach-orion/edmini_v2-setup.c          |    4 +--
 b/arch/arm/mach-orion/guruplug-setup.c           |    6 ++---
 b/arch/arm/mach-orion/include/mach/bridge-regs.h |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/debug-macro.S |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/entry-macro.S |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/hardware.h    |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/io.h          |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/irqs.h        |   12 ++++++++++
 b/arch/arm/mach-orion/include/mach/uncompress.h  |   12 ++++++++++
 b/arch/arm/mach-orion/irq-dove.c                 |    4 +--
 b/arch/arm/mach-orion/irq-kirkwood.c             |    4 +--
 b/arch/arm/mach-orion/irq-mv78xx0.c              |    4 +--
 b/arch/arm/mach-orion/irq-orion5x.c              |    4 +--
 b/arch/arm/mach-orion/irq.c                      |    2 -
 b/arch/arm/mach-orion/kirkwood.c                 |   18 +++++++--------
 b/arch/arm/mach-orion/kurobox_pro-setup.c        |    6 ++---
 b/arch/arm/mach-orion/lacie_v2-common.c          |    4 +--
 b/arch/arm/mach-orion/ls-chl-setup.c             |    4 +--
 b/arch/arm/mach-orion/ls_hgl-setup.c             |    4 +--
 b/arch/arm/mach-orion/lsmini-setup.c             |    4 +--
 b/arch/arm/mach-orion/mpp-dove.c                 |    4 +--
 b/arch/arm/mach-orion/mpp-kirkwood.c             |    6 ++---
 b/arch/arm/mach-orion/mpp-mv78xx0.c              |    6 ++---
 b/arch/arm/mach-orion/mpp-orion5x.c              |    6 ++---
 b/arch/arm/mach-orion/mpp.c                      |    2 -
 b/arch/arm/mach-orion/mss2-setup.c               |    4 +--
 b/arch/arm/mach-orion/mv2120-setup.c             |    4 +--
 b/arch/arm/mach-orion/mv78xx0.c                  |   14 ++++++------
 b/arch/arm/mach-orion/mv88f6281gtw_ge-setup.c    |    4 +--
 b/arch/arm/mach-orion/net2big-setup.c            |    4 +--
 b/arch/arm/mach-orion/netspace_v2-setup.c        |    4 +--
 b/arch/arm/mach-orion/netxbig_v2-setup.c         |    4 +--
 b/arch/arm/mach-orion/openrd-setup.c             |    6 ++---
 b/arch/arm/mach-orion/orion5x.c                  |   12 +++++-----
 b/arch/arm/mach-orion/pci-orion5x.c              |    6 ++---
 b/arch/arm/mach-orion/pcie-dove.c                |    6 ++---
 b/arch/arm/mach-orion/pcie-kirkwood.c            |    6 ++---
 b/arch/arm/mach-orion/pcie-mv78xx0.c             |    6 ++---
 b/arch/arm/mach-orion/pcie.c                     |    4 +--
 b/arch/arm/mach-orion/rd78x00-masa-setup.c       |    2 -
 b/arch/arm/mach-orion/rd88f5181l-fxo-setup.c     |    4 +--
 b/arch/arm/mach-orion/rd88f5181l-ge-setup.c      |    4 +--
 b/arch/arm/mach-orion/rd88f5182-setup.c          |    4 +--
 b/arch/arm/mach-orion/rd88f6183ap-ge-setup.c     |    2 -
 b/arch/arm/mach-orion/rd88f6192-nas-setup.c      |    2 -
 b/arch/arm/mach-orion/rd88f6281-setup.c          |    6 ++---
 b/arch/arm/mach-orion/sheevaplug-setup.c         |    6 ++---
 b/arch/arm/mach-orion/t5325-setup.c              |    4 +--
 b/arch/arm/mach-orion/terastation_pro2-setup.c   |    4 +--
 b/arch/arm/mach-orion/ts209-setup.c              |    4 +--
 b/arch/arm/mach-orion/ts219-setup.c              |    4 +--
 b/arch/arm/mach-orion/ts409-setup.c              |    4 +--
 b/arch/arm/mach-orion/ts41x-setup.c              |    6 ++---
 b/arch/arm/mach-orion/ts78xx-setup.c             |    4 +--
 b/arch/arm/mach-orion/tsx09-common.c             |    2 -
 b/arch/arm/mach-orion/tsx1x-common.c             |    2 -
 b/arch/arm/mach-orion/wnr854t-setup.c            |    4 +--
 b/arch/arm/mach-orion/wrt350n-v2-setup.c         |    4 +--
 b/arch/arm/mm/cache-feroceon-l2.c                |    2 -
 b/drivers/dma/mv_xor.c                           |    2 -
 b/drivers/mmc/host/mvsdio.c                      |    2 -
 b/drivers/mtd/nand/orion_nand.c                  |    2 -
 b/drivers/usb/host/ehci-orion.c                  |    2 -
 b/drivers/watchdog/orion_wdt.c                   |    2 -
 b/sound/soc/kirkwood/kirkwood-i2s.c              |    2 -
 b/sound/soc/kirkwood/kirkwood-openrd.c           |    2 -
 b/sound/soc/kirkwood/kirkwood-t5325.c            |    2 -
 112 files changed, 306 insertions(+), 342 deletions(-)
maintainer
#78 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Arnd Bergmann
Quoted 22 lines · Arnd Bergmann
Quoted 8 lines · Arnd Bergmann

Another way would be to reorganize those directories upfront:

plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.h

and then go from there. The differences between the headers are fairly small already, so that should be manageable.

Actually we could do a trivial move of all files into one directory at any time, e.g. at the end of the merge window, to minimize conflicts with other patches.

This is a semi-automated move of all plat-orion based machines into a single mach-orion directory, and we could of course add the new stuff in there as well. I've specifically tried to keep this move simple, even if that means a lot of the easy cleanups for code that are mostly identical are not done here. Cleanups after this could come one at a time to reduce this duplication and simplify the platform.

Quoted 4 lines

Obvious next steps are to merge the various Makefile and Kconfig files as well as all the headers, and to actually allow building stuff together.

Has this been tested in any way? If it boots on a few different boards, i would say yes, lets do it.

If this is for the end of the merge window, we have about two weeks for testing. Seems reasonable.

Andrew

#79 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 9 lines · Andrew Lunn
Quoted 2 lines

Has this been tested in any way? If it boots on a few different boards, i would say yes, lets do it.

If this is for the end of the merge window, we have about two weeks for testing. Seems reasonable.

No testing in any way other than building the four defconfigs, but I've been rather careful in coming up with a way that would be least invasive. I agree it needs real testing anyway.

Arnd

#80 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Arnd Bergmann
Quoted 11 lines · Arnd Bergmann
Quoted 8 lines · Arnd Bergmann

Another way would be to reorganize those directories upfront:

plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.h

and then go from there. The differences between the headers are fairly small already, so that should be manageable.

Quoted 7 lines

Actually we could do a trivial move of all files into one directory at any time, e.g. at the end of the merge window, to minimize conflicts with other patches.

This is a semi-automated move of all plat-orion based machines into a single mach-orion directory, and we could of course add the new stuff in there as well.

mach-orion is better than mach-armada. Armada is just a Logo, not a silicon family.
Silicons with ARMv5/v6/v7 core are all marked with Armada Logo.

By the way, silicons in mach-pxa and mach-mmp are also named Armada.

Regards
Haojian

maintainer
#81 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Arnd Bergmann
Quoted 22 lines · Arnd Bergmann
Quoted 8 lines · Arnd Bergmann

Another way would be to reorganize those directories upfront:

plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.h

and then go from there. The differences between the headers are fairly small already, so that should be manageable.

Actually we could do a trivial move of all files into one directory at any time, e.g. at the end of the merge window, to minimize conflicts with other patches.

This is a semi-automated move of all plat-orion based machines into a single mach-orion directory, and we could of course add the new stuff in there as well. I've specifically tried to keep this move simple, even if that means a lot of the easy cleanups for code that are mostly identical are not done here. Cleanups after this could come one at a time to reduce this duplication and simplify the platform.

Quoted 4 lines

Obvious next steps are to merge the various Makefile and Kconfig files as well as all the headers, and to actually allow building stuff together.

It boots on my kirkwood QNAP TS109P+ and all the devices seem present and correct.

Andrew

maintainer
#82 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Arnd Bergmann
Quoted 14 lines · Arnd Bergmann
Quoted 5 lines · Thomas Petazzoni

On the naming side, we are really open to what the community prefers. We knew there would be quite a bit of discussion around this, because there's a lot quite a few Marvell SoCs supported in various places, and it's not obvious what's the right place and name for a new SoC family.

Quoted 7 lines

What about making it mach-marvell, which would contain the DT-enabled SoC support for Marvell SoCs? We can start with 370 and XP today, and gradually add future SoCs, or even port previous SoCs as they are moved to support the device tree.

Again we're really open on the solution. Lior from Marvell can give all the necessary input to explain how the SoC family is organized.

Quoted 6 lines

The problem with mach-marvell is that it would be confusing in the presence of pxa/mmp which I would probably still leave out of that directory, since they are rather different inside.

I think we can just start with the existing plat-orion directory until someone comes up with a better place.

plat-orion for the common bits totally makes sense.

I wouldn't use that for SOC specific stuff though. The proposed mach-armada is probably a good choice.

mach-marvell, mach-mrvl or any other derivatives based on the company name is a really bad choice. Marvell is a large company and it has several SOC families with totally disjoint history.

Nicolas

maintainer
#83 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Thomas Petazzoni
Quoted 11 lines · Thomas Petazzoni

Le Tue, 15 May 2012 09:35:55 -0500,
Rob Herring <[email protected]> a ??crit :

Quoted 3 lines

Directory location doesn't really have anything to do with what can be in a single kernel binary. We will soon be building single images across mach directories.

Agreed, but it's not the case right now, and we wanted to submit today a kernel that boots on both of those SoCs.

The 370 and XP both use the PJ4B core

Could mach-pj4b be an option?

Andrew

#84 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 8 lines · Andrew Lunn
Quoted 7 lines · Thomas Petazzoni

Le Tue, 15 May 2012 09:35:55 -0500,
Rob Herring<[email protected]> a ??crit :

Quoted 3 lines

Directory location doesn't really have anything to do with what can be in a single kernel binary. We will soon be building single images across mach directories.

Quoted 6 lines
Quoted 4 lines

Agreed, but it's not the case right now, and we wanted to submit today a kernel that boots on both of those SoCs.

The 370 and XP both use the PJ4B core

Could mach-pj4b be an option?

Not really, that's the CPU core and will probably get re-used for a number of products.

I'm personally happy with any of mach-marvell, mach-mv, mach-mv-axp or similar.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
maintainer
#85 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

The 370 and XP both use the PJ4B core

Could mach-pj4b be an option?

Not really, that's the CPU core and will probably get re-used for a number of products.

However, if everything is DT based, does that matter? All these products end up in here.

Andrew

#86 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 9 lines · Andrew Lunn
Quoted 6 lines
Quoted 3 lines
Quoted 1 line

The 370 and XP both use the PJ4B core

Could mach-pj4b be an option?

Not really, that's the CPU core and will probably get re-used for a number of products.

However, if everything is DT based, does that matter? All these products end up in here.

I'd prefer a slightly more segregated directory structure, you'd end up with masses of files in one directory if you went of cpu-arch as most people use the v5/v6/v7 ARM cores.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#87 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Thomas Petazzoni
Quoted 41 lines

-----Original Message-----
From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
Sent: Tuesday, May 15, 2012 5:45 PM
To: Rob Herring
Cc: Ben Dooks; Lior Amsalem; Andrew Lunn; Jason Cooper; Arnd Bergmann; Nicolas Pitre; Maen Suleiman; Ben Dooks; Olof Johansson; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH] arm: Add basic support for new Marvell Armada SoC family

Le Tue, 15 May 2012 09:35:55 -0500,
Rob Herring <[email protected]> a ?crit :

Quoted 3 lines

Directory location doesn't really have anything to do with what can be in a single kernel binary. We will soon be building single images across mach directories.

Agreed, but it's not the case right now, and we wanted to submit today a kernel that boots on both of those SoCs.

The 370 and XP both use the PJ4B core, which is a Marvell implementation of an ARMv7 compatible core. The 370 has one PJ4B, and the various XP variants have a choice of 2 or 4 PJ4Bs, and various other differences. To us, it makes a lot of sense to be able to support those SoCs together in the same kernel image and in the same directory, even if both concepts are not directly tied together.

Quoted 6 lines

With some hacks and limitations, Arnd has built (not run) omap2+, u8500, imx and one other in a single kernel.
If there's overlap with dove or other platforms, then they should probably all be combined into a single mach directory. One option would be make the new mach directory somewhat generic and then later move dove or others into the new directory.

This would be one solution.

On the naming side, we are really open to what the community prefers. We knew there would be quite a bit of discussion around this, because there's a lot quite a few Marvell SoCs supported in various places, and it's not obvious what's the right place and name for a new SoC family.

Quoted 7 lines

What about making it mach-marvell, which would contain the DT-enabled SoC support for Marvell SoCs? We can start with 370 and XP today, and gradually add future SoCs, or even port previous SoCs as they are moved to support the device tree.

Again we're really open on the solution. Lior from Marvell can give all the necessary input to explain how the SoC family is organized.

I'll try to arrange our SoCs (EBU):

Orion family:
Flavors:
5082, 5181, 5181L, 5281, 6183, ...
Core: ARMv5 compatible (Feroceon and Jolteon)
Process: 90nm
Directory: mach-orion5x

Kirkwood family:
Flavors:
6190, 6192, ...
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-kirkwood

6282 a.k.a Kirkwood 55, Armada 300
6283 a.k.a Kirkwood 55, Armada 310
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: not in mainline, future plan

6710 a.k.a Kirkwood 40, Armada 370
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new code

Discovery family:
Flavors:
78100/78200 a.k.a DiscoDuo
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-mv78xx0

78230/78260/78460 a.k.a DiscoSMP, Armada XP
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new code

Avanta family: (a.k.a Kirkwood 2)
Flavors:
6560/60, 6530P, 6510
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: no code in mainline yet, future plan

Dove: (application processor)
Flavors:
ap510 a.k.a Armada 510
Core: ARMv7 compatible (PJ4)
Process: 65nm
Directory: mach-dove

plat-orion holds code shared between the SoCs.
There are more SoCs called Armada which are developed in other business units in Marvell (mmp, pxa) but I'm not that familier with it.

I hope it helps mapping the different SoCs.

Quoted 9 lines

Best regards,

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

Lior Amsalem

maintainer
#88 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Hi Lior

Thanks for the list.

Quoted 8 lines

I'll try to arrange our SoCs (EBU):

Orion family:
Flavors:
5082, 5181, 5181L, 5281, 6183, ...
Core: ARMv5 compatible (Feroceon and Jolteon)
Process: 90nm
Directory: mach-orion5x

mach-orion5x also supports 5182, which is not on your list.

Quoted 7 lines

Kirkwood family:
Flavors:
6190, 6192, ...
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-kirkwood

Quoted 5 lines

6282 a.k.a Kirkwood 55, Armada 300
6283 a.k.a Kirkwood 55, Armada 310
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: not in mainline, future plan

mach-kirkwood supports 6180 6190 6192 6281 6282

6180 and 6281 are not on your list.

Quoted 25 lines

6710 a.k.a Kirkwood 40, Armada 370
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new code

Discovery family:
Flavors:
78100/78200 a.k.a DiscoDuo
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-mv78xx0

78230/78260/78460 a.k.a DiscoSMP, Armada XP
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new code

Avanta family: (a.k.a Kirkwood 2)
Flavors:
6560/60, 6530P, 6510
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: no code in mainline yet, future plan

Quoted 6 lines

Dove: (application processor)
Flavors:
ap510 a.k.a Armada 510
Core: ARMv7 compatible (PJ4)
Process: 65nm
Directory: mach-dove

Is there any logic to the names/numbers?

Thanks
Andrew

#89 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Lior Amsalem
Quoted 56 lines · Lior Amsalem
Quoted 2 lines

Again we're really open on the solution. Lior from Marvell can give all the necessary input to explain how the SoC family is organized.

I'll try to arrange our SoCs (EBU):

Orion family:
Flavors:
5082, 5181, 5181L, 5281, 6183, ...
Core: ARMv5 compatible (Feroceon and Jolteon)
Process: 90nm
Directory: mach-orion5x

Kirkwood family:
Flavors:
6190, 6192, ...
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-kirkwood

6282 a.k.a Kirkwood 55, Armada 300
6283 a.k.a Kirkwood 55, Armada 310
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: not in mainline, future plan

6710 a.k.a Kirkwood 40, Armada 370
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new code

Discovery family:
Flavors:
78100/78200 a.k.a DiscoDuo
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-mv78xx0

78230/78260/78460 a.k.a DiscoSMP, Armada XP
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new code

Avanta family: (a.k.a Kirkwood 2)
Flavors:
6560/60, 6530P, 6510
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: no code in mainline yet, future plan

Dove: (application processor)
Flavors:
ap510 a.k.a Armada 510
Core: ARMv7 compatible (PJ4)
Process: 65nm
Directory: mach-dove

Quoted 5 lines

plat-orion holds code shared between the SoCs.
There are more SoCs called Armada which are developed in other business units in Marvell (mmp, pxa) but I'm not that familier with it.

I hope it helps mapping the different SoCs.

Thanks for the list, very helpful!

So do you think it makes sense to put all of these into mach-orion?

Where does the Armada 1000/1500 (88DE3010/88DE3100) fit in here. Is it related to the EBU family above or the PXA/MMP family, or is it something entirely different?

Also, I've seen dove (Armada 510) being referred to as PXA510. Is that also an official designation or just a mistake made by people who were confused by the marketing names?

Arnd

#90 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 10 lines

-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Wednesday, May 16, 2012 3:01 PM
To: Lior Amsalem
Cc: Thomas Petazzoni; Rob Herring; Ben Dooks; Andrew Lunn; Jason Cooper; Nicolas Pitre; Maen Suleiman; Ben Dooks; Olof Johansson; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH] arm: Add basic support for new Marvell Armada SoC family

[snip]

Quoted 5 lines

Thanks for the list, very helpful!

So do you think it makes sense to put all of these into mach-orion?

Well, Orion is old and seems like not the best name for a directory to include all the new platforms.
We are discussing it internally as well and I'll update with our suggestion.

Quoted 5 lines

Where does the Armada 1000/1500 (88DE3010/88DE3100) fit in here. Is it related to the EBU family above or the PXA/MMP family, or is it something entirely different?

I only know general info, no more than what can be found in Marvell's site:
http://www.marvell.com/digital-entertainment/

Quoted 3 lines

Also, I've seen dove (Armada 510) being referred to as PXA510. Is that also an official designation or just a mistake made by people who were confused by the marketing names?

It was the SoC name at some point, the official name is Armada 510.

Quoted 2 lines

Arnd

Lior Amsalem

maintainer
#91 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 12 lines · Lior Amsalem
Quoted 10 lines

-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Wednesday, May 16, 2012 3:01 PM
To: Lior Amsalem
Cc: Thomas Petazzoni; Rob Herring; Ben Dooks; Andrew Lunn; Jason Cooper; Nicolas Pitre; Maen Suleiman; Ben Dooks; Olof Johansson; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH] arm: Add basic support for new Marvell Armada SoC family

[snip]

Quoted 1 line
Quoted 7 lines
Quoted 4 lines

Thanks for the list, very helpful!

So do you think it makes sense to put all of these into mach-orion?

Well, Orion is old and seems like not the best name for a directory to include all the new platforms.
We are discussing it internally as well and I'll update with our suggestion.

My suggestion is: mach-mrvl-ebu or plat-mrvl-ebu

Rational: any marketing name is going to be unsuitable for structuring common code in the kernel, especially as Marvell has a tendency to reuse the same marketing name for different things, as well as different names for similar things. 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.

Nicolas

#92 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Lior Amsalem
Quoted 8 lines · Lior Amsalem
Quoted 5 lines

Thanks for the list, very helpful!

So do you think it makes sense to put all of these into mach-orion?

Well, Orion is old and seems like not the best name for a directory to include all the new platforms.
We are discussing it internally as well and I'll update with our suggestion.

The name has the advantage that we have a bunch of drivers using it already:

arch/arm/plat-orion/gpio.c
arch/arm/plat-orion/irq.c
arch/arm/plat-orion/mpp.c
arch/arm/plat-orion/pcie.c
arch/arm/plat-orion/time.c
drivers/mtd/nand/orion_nand.c
drivers/spi/spi-orion.c
drivers/usb/host/ehci-orion.c
drivers/watchdog/orion_wdt.c

AFAICT, those are shared between most of those socs, and I would not want to change the code in them to the new name. If we change the directory name to something completely different, it no longer matches the driver names.

Arnd

maintainer
#93 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 22 lines · Arnd Bergmann
Quoted 8 lines · Lior Amsalem
Quoted 5 lines

Thanks for the list, very helpful!

So do you think it makes sense to put all of these into mach-orion?

Well, Orion is old and seems like not the best name for a directory to include all the new platforms.
We are discussing it internally as well and I'll update with our suggestion.

The name has the advantage that we have a bunch of drivers using it already:

arch/arm/plat-orion/gpio.c
arch/arm/plat-orion/irq.c
arch/arm/plat-orion/mpp.c
arch/arm/plat-orion/pcie.c
arch/arm/plat-orion/time.c
drivers/mtd/nand/orion_nand.c
drivers/spi/spi-orion.c
drivers/usb/host/ehci-orion.c
drivers/watchdog/orion_wdt.c

Quoted 2 lines

AFAICT, those are shared between most of those socs, and I would not want to change the code in them to the new name.

Why not? Module aliases can be used if that is a concern.

Quoted 3 lines

If we change the directory
name to something completely different, it no longer matches the driver names.

I wouldn't consider this as a major concern. For example, the ethernet driver that all those SOCs use is not called "orion".

Nicolas

#94 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 4 lines · Nicolas Pitre
Quoted 3 lines

AFAICT, those are shared between most of those socs, and I would not want to change the code in them to the new name.

Quoted 8 lines

Why not? Module aliases can be used if that is a concern.

Quoted 3 lines

If we change the directory
name to something completely different, it no longer matches the driver names.

I wouldn't consider this as a major concern. For example, the ethernet driver that all those SOCs use is not called "orion".

It's not a big thing, I just feel that leaving the drivers alone makes it a bit easier to port patches between kernel versions. Another argument for orion is that it's nicer to read as a function name prefix than mrvl_ebu_* as you suggested. The main counterargument to keeping orion_ as I understand it is that it's actually only the name for the oldest members of this family, right? This is a good point, but we also have a lot of other cases in the kernel where code is named after the first thing that used it, e.g. arch/x86 was called arch/i386 for a long time and we still have tons of references to that.

Arnd

maintainer
#95 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · Nicolas Pitre
Quoted 3 lines

AFAICT, those are shared between most of those socs, and I would not want to change the code in them to the new name.

Why not? Module aliases can be used if that is a concern.

Quoted 3 lines

If we change the directory
name to something completely different, it no longer matches the driver names.

Quoted 5 lines
Quoted 2 lines

I wouldn't consider this as a major concern. For example, the ethernet driver that all those SOCs use is not called "orion".

It's not a big thing, I just feel that leaving the drivers alone makes it a bit easier to port patches between kernel versions.

Sure. My point is that we can rename the SOC directory and leave drivers alone if we wish to minimize churn. Drivers can be renamed at a later time if that is seen as useful.

Quoted 8 lines

Another argument
for orion is that it's nicer to read as a function name prefix than mrvl_ebu_* as you suggested. The main counterargument to keeping orion_ as I understand it is that it's actually only the name for the oldest members of this family, right? This is a good point, but we also have a lot of other cases in the kernel where code is named after the first thing that used it, e.g. arch/x86 was called arch/i386 for a long time and we still have tons of references to that.

Indeed. "sa1100" is another example of that and I didn't want to rename it to sa11x0 at the time.

But in the sa1100 or i386 cases, the alternatives are close enough not to cause too much confusion.

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, _especially_ if we're going to cause churn by moving things around already.

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

Since this is code not marketing, we don't have to have something flashy either, as long as it doesn't create more confusion than "orion" does. The various Kconfig help texts are good places to put all the marketing names du jour.

Nicolas

#96 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 12 lines · Nicolas Pitre

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

Quoted 4 lines

Since this is code not marketing, we don't have to have something flashy either, as long as it doesn't create more confusion than "orion" does. The various Kconfig help texts are good places to put all the marketing names du jour.

mvebu sounds reasonable to me, it's definitely unique and it's almost a word ;-)

Arnd

#97 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 13 lines · Arnd Bergmann
Quoted 12 lines · Nicolas Pitre

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

Quoted 7 lines
Quoted 4 lines

Since this is code not marketing, we don't have to have something flashy either, as long as it doesn't create more confusion than "orion" does. The various Kconfig help texts are good places to put all the marketing names du jour.

mvebu sounds reasonable to me, it's definitely unique and it's almost a word ;-)

mvebuntu? *ducks*

;-P

Jason.

#98 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 19 lines · Jason Cooper
Quoted 18 lines · Arnd Bergmann
Quoted 16 lines · Nicolas Pitre

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

Since this is code not marketing, we don't have to have something flashy either, as long as it doesn't create more confusion than "orion" does. The various Kconfig help texts are good places to put all the marketing names du jour.

Quoted 4 lines
Quoted 2 lines

mvebu sounds reasonable to me, it's definitely unique and it's almost a word ;-)

mvebuntu? *ducks*

you, sir, are clearly quackers.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#99 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Nicolas Pitre
Quoted 45 lines · Nicolas Pitre
Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · Nicolas Pitre
Quoted 3 lines

AFAICT, those are shared between most of those socs, and I would not want to change the code in them to the new name.

Why not? Module aliases can be used if that is a concern.

Quoted 3 lines

If we change the directory
name to something completely different, it no longer matches the driver names.

Quoted 5 lines
Quoted 2 lines

I wouldn't consider this as a major concern. For example, the ethernet driver that all those SOCs use is not called "orion".

It's not a big thing, I just feel that leaving the drivers alone makes it a bit easier to port patches between kernel versions.

Sure. My point is that we can rename the SOC directory and leave drivers alone if we wish to minimize churn. Drivers can be renamed at a later time if that is seen as useful.

Quoted 8 lines

Another argument
for orion is that it's nicer to read as a function name prefix than mrvl_ebu_* as you suggested. The main counterargument to keeping orion_ as I understand it is that it's actually only the name for the oldest members of this family, right? This is a good point, but we also have a lot of other cases in the kernel where code is named after the first thing that used it, e.g. arch/x86 was called arch/i386 for a long time and we still have tons of references to that.

Indeed. "sa1100" is another example of that and I didn't want to rename it to sa11x0 at the time.

But in the sa1100 or i386 cases, the alternatives are close enough not to cause too much confusion.

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, _especially_ if we're going to cause churn by moving things around already.

Quoted 4 lines

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

I prefer mvebu_* ... nice and concise.

thx,

Jason.

#100 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 8 lines · Jason Cooper
Quoted 8 lines

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.

Quoted 7 lines
Quoted 4 lines

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

I prefer mvebu_* ... nice and concise.

On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to arch/arm/mach-mvebu/board/*.c instead of arch/arm/mach-mvebu/*-setup.c

The reasons I think this would help are that the directory is getting a bit crowded when we move five or more of the current platforms in there, and that I hope we can start ignoring them for most practical purposes as some point in the future when all boards have been made to work with DT, and at an even later point we can just delete that directory. The main disadvantage that this approach would bring is that it's not consistent with what any of the other platforms do.

Arnd

maintainer
#101 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 22 lines · Arnd Bergmann
Quoted 8 lines · Jason Cooper
Quoted 8 lines

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.

Quoted 7 lines
Quoted 4 lines

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

I prefer mvebu_* ... nice and concise.

On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to arch/arm/mach-mvebu/board/*.c instead of arch/arm/mach-mvebu/*-setup.c

Quoted 7 lines

The reasons I think this would help are that the directory is getting a bit crowded when we move five or more of the current platforms in there, and that I hope we can start ignoring them for most practical purposes as some point in the future when all boards have been made to work with DT, and at an even later point we can just delete that directory. The main disadvantage that this approach would bring is that it's not consistent with what any of the other platforms do.

Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.

Nicolas

#102 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 32 lines · Nicolas Pitre
Quoted 22 lines · Arnd Bergmann
Quoted 8 lines · Jason Cooper
Quoted 8 lines

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.

Quoted 7 lines
Quoted 4 lines

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

I prefer mvebu_* ... nice and concise.

On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to arch/arm/mach-mvebu/board/*.c instead of arch/arm/mach-mvebu/*-setup.c

Quoted 7 lines

The reasons I think this would help are that the directory is getting a bit crowded when we move five or more of the current platforms in there, and that I hope we can start ignoring them for most practical purposes as some point in the future when all boards have been made to work with DT, and at an even later point we can just delete that directory. The main disadvantage that this approach would bring is that it's not consistent with what any of the other platforms do.

Quoted 2 lines

Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.

Took the words right out of my mouth. Once DT conversions are complete, mach-*/ would either go away, or hold legacy non-DT boards.

On a side note, I also like this because it would make converting old board files like sheevaplug and guruplug to DT easier. The legacy implementation would be in mach-mvebu/ and the DT implementation would be in plat-mvebu/. Newcomers to the code would see a clearly defined separation.

thx,

Jason.

#103 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 11 lines · Jason Cooper
Quoted 2 lines

Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.

Took the words right out of my mouth. Once DT conversions are complete, mach-*/ would either go away, or hold legacy non-DT boards.

On a side note, I also like this because it would make converting old board files like sheevaplug and guruplug to DT easier. The legacy implementation would be in mach-mvebu/ and the DT implementation would be in plat-mvebu/. Newcomers to the code would see a clearly defined separation.

With that layout, where do the mach/* headers go?

Arnd

maintainer
#104 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 7 lines · Arnd Bergmann
Quoted 6 lines · Jason Cooper
Quoted 2 lines

Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.

Took the words right out of my mouth. Once DT conversions are complete, mach-*/ would either go away, or hold legacy non-DT boards.

Quoted 7 lines
Quoted 5 lines

On a side note, I also like this because it would make converting old board files like sheevaplug and guruplug to DT easier. The legacy implementation would be in mach-mvebu/ and the DT implementation would be in plat-mvebu/. Newcomers to the code would see a clearly defined separation.

With that layout, where do the mach/* headers go?

I think arch/arm/plat-mvvebu/include/mach/* could work.

Nicolas

#105 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 15 lines · Nicolas Pitre
Quoted 13 lines · Arnd Bergmann
Quoted 11 lines · Jason Cooper
Quoted 2 lines

Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.

Took the words right out of my mouth. Once DT conversions are complete, mach-*/ would either go away, or hold legacy non-DT boards.

On a side note, I also like this because it would make converting old board files like sheevaplug and guruplug to DT easier. The legacy implementation would be in mach-mvebu/ and the DT implementation would be in plat-mvebu/. Newcomers to the code would see a clearly defined separation.

Quoted 3 lines
Quoted 1 line

With that layout, where do the mach/* headers go?

I think arch/arm/plat-mvvebu/include/mach/* could work.

And try to avoid putting anything in the include/mach/ directory which isn't needed by any code outside of arch/arm/{plat,mach}-* directory.

In other words, headers needed only for code in arch/arm/plat-mvvebu/ should be in that very same directory.

#106 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 18 lines · Russell King - ARM Linux
Quoted 17 lines · Nicolas Pitre
Quoted 14 lines · Arnd Bergmann
Quoted 11 lines · Jason Cooper
Quoted 2 lines

Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.

Took the words right out of my mouth. Once DT conversions are complete, mach-*/ would either go away, or hold legacy non-DT boards.

On a side note, I also like this because it would make converting old board files like sheevaplug and guruplug to DT easier. The legacy implementation would be in mach-mvebu/ and the DT implementation would be in plat-mvebu/. Newcomers to the code would see a clearly defined separation.

With that layout, where do the mach/* headers go?

Quoted 7 lines
Quoted 1 line

I think arch/arm/plat-mvvebu/include/mach/* could work.

And try to avoid putting anything in the include/mach/ directory which isn't needed by any code outside of arch/arm/{plat,mach}-* directory.

In other words, headers needed only for code in arch/arm/plat-mvvebu/ should be in that very same directory.

Ok, so let me make sure I got it all right:

* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/mach
* headers used to inteface between the first two go to plat-mvebu/include/plat (?)

Arnd

#107 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 7 lines · Arnd Bergmann
Quoted 5 lines · Russell King - ARM Linux

And try to avoid putting anything in the include/mach/ directory which isn't needed by any code outside of arch/arm/{plat,mach}-* directory.

In other words, headers needed only for code in arch/arm/plat-mvvebu/ should be in that very same directory.

Quoted 8 lines

Ok, so let me make sure I got it all right:

* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/mach
* headers used to inteface between the first two go to plat-mvebu/include/plat (?)

That sounds reasonable. The only eyebrow raising thing is having an include/mach inside a plat-* directory... that seems an odd way to do things as mach/ includes normally come from the mach-* directory.

So I wonder whether Nicolas' idea of "dt-only stuff in arch/arm/plat-*" is the right idea. It just makes plat-* the same as a mach-* but with a different name, whereas it is _supposed_ to be for stuff shared between a bunch of mach-* directories.

#108 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Arnd Bergmann
Quoted 5 lines · Russell King - ARM Linux

And try to avoid putting anything in the include/mach/ directory which isn't needed by any code outside of arch/arm/{plat,mach}-* directory.

In other words, headers needed only for code in arch/arm/plat-mvvebu/ should be in that very same directory.

Quoted 6 lines
Quoted 6 lines

Ok, so let me make sure I got it all right:

* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/mach

plat-mvebu/include/plat ?

Quoted 2 lines
Quoted 2 lines

* headers used to inteface between the first two go to plat-mvebu/include/plat (?)

plat-mvebu/include ?

Quoted 9 lines

That sounds reasonable. The only eyebrow raising thing is having an include/mach inside a plat-* directory... that seems an odd way to do things as mach/ includes normally come from the mach-* directory.

So I wonder whether Nicolas' idea of "dt-only stuff in arch/arm/plat-*" is the right idea. It just makes plat-* the same as a mach-* but with a different name, whereas it is _supposed_ to be for stuff shared between a bunch of mach-* directories.

In an ideal (dt) world, plat-*/ would hold all the dt source files, and arch/arm/boot/dts/ would become the new mach-*/. mach-*/ is kept around for the few legacy, unconverted boards.

Or, am I barking up the wrong tree?

thx,

Jason.

#109 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 6 lines · Jason Cooper
Quoted 4 lines
Quoted 4 lines

* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/mach

plat-mvebu/include/plat ?

Doesn't work because of the handful of places that #include <mach/*> with a common name, like irqs.h or debug-macro.S.

Quoted 4 lines
Quoted 2 lines
Quoted 2 lines

* headers used to inteface between the first two go to plat-mvebu/include/plat (?)

plat-mvebu/include ?

That would still put them into a globally visible location since we do gcc -I arch/arm/plat-${PLAT}/include.

Quoted 9 lines
Quoted 8 lines

That sounds reasonable. The only eyebrow raising thing is having an include/mach inside a plat-* directory... that seems an odd way to do things as mach/ includes normally come from the mach-* directory.

So I wonder whether Nicolas' idea of "dt-only stuff in arch/arm/plat-*" is the right idea. It just makes plat-* the same as a mach-* but with a different name, whereas it is supposed to be for stuff shared between a bunch of mach-* directories.

Quoted 5 lines

In an ideal (dt) world, plat-*/ would hold all the dt source files, and arch/arm/boot/dts/ would become the new mach-*/. mach-*/ is kept around for the few legacy, unconverted boards.

Or, am I barking up the wrong tree?

I think we're not likely to get there any time soon. Most platforms in fact only have a mach-* directory at the moment and no plat-* directory.

Arnd

#110 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Jason Cooper
Quoted 9 lines · Jason Cooper
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Arnd Bergmann
Quoted 5 lines · Russell King - ARM Linux

And try to avoid putting anything in the include/mach/ directory which isn't needed by any code outside of arch/arm/{plat,mach}-* directory.

In other words, headers needed only for code in arch/arm/plat-mvvebu/ should be in that very same directory.

Quoted 8 lines
Quoted 6 lines
Quoted 6 lines

Ok, so let me make sure I got it all right:

* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/mach

plat-mvebu/include/plat ?

Better.

Quoted 4 lines
Quoted 2 lines
Quoted 2 lines

* headers used to inteface between the first two go to plat-mvebu/include/plat (?)

plat-mvebu/include ?

No, we don't put include files in that directory, always a subdirectory. But note - any header file used _only_ by files in plat-mvebu should be in plat-mvebu itself and not some subdirectory. Locality of reference is the key idea there.

Quoted 4 lines
Quoted 4 lines

That sounds reasonable. The only eyebrow raising thing is having an include/mach inside a plat-* directory... that seems an odd way to do things as mach/ includes normally come from the mach-* directory.

Quoted 8 lines
Quoted 4 lines

So I wonder whether Nicolas' idea of "dt-only stuff in arch/arm/plat-*" is the right idea. It just makes plat-* the same as a mach-* but with a different name, whereas it is _supposed_ to be for stuff shared between a bunch of mach-* directories.

In an ideal (dt) world, plat-*/ would hold all the dt source files, and arch/arm/boot/dts/ would become the new mach-*/. mach-*/ is kept around for the few legacy, unconverted boards.

At that point I'd suggest the plat-* is renamed to mach-* ;)

plat-* was only invented to allow SoC folk to have some place to put common code shared between a set of mach-*, and nothing more.

#111 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 24 lines · Russell King - ARM Linux
Quoted 9 lines · Jason Cooper
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Arnd Bergmann
Quoted 5 lines · Russell King - ARM Linux

And try to avoid putting anything in the include/mach/ directory which isn't needed by any code outside of arch/arm/{plat,mach}-* directory.

In other words, headers needed only for code in arch/arm/plat-mvvebu/ should be in that very same directory.

Quoted 8 lines
Quoted 6 lines
Quoted 6 lines

Ok, so let me make sure I got it all right:

* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/mach

plat-mvebu/include/plat ?

Better.

Quoted 3 lines
Quoted 2 lines
Quoted 2 lines

* headers used to inteface between the first two go to plat-mvebu/include/plat (?)

Quoted 6 lines
Quoted 1 line

plat-mvebu/include ?

No, we don't put include files in that directory, always a subdirectory. But note - any header file used _only_ by files in plat-mvebu should be in plat-mvebu itself and not some subdirectory. Locality of reference is the key idea there.

Got it, thanks for the clarification.

Quoted 9 lines
Quoted 9 lines
Quoted 8 lines

That sounds reasonable. The only eyebrow raising thing is having an include/mach inside a plat-* directory... that seems an odd way to do things as mach/ includes normally come from the mach-* directory.

So I wonder whether Nicolas' idea of "dt-only stuff in arch/arm/plat-*" is the right idea. It just makes plat-* the same as a mach-* but with a different name, whereas it is _supposed_ to be for stuff shared between a bunch of mach-* directories.

Quoted 8 lines
Quoted 3 lines

In an ideal (dt) world, plat-*/ would hold all the dt source files, and arch/arm/boot/dts/ would become the new mach-*/. mach-*/ is kept around for the few legacy, unconverted boards.

At that point I'd suggest the plat-* is renamed to mach-* ;)

plat-* was only invented to allow SoC folk to have some place to put common code shared between a set of mach-*, and nothing more.

So lets follow that to it's logical end. How about we rename plat-orion/ to mach-mvebu/, put all dt-compatible code in mach-mvebu/, and empty the remaining mach-*/'s as they get converted?

mach-mvebu/'s directory tree structure could be:
include/ # no headers
include/mach/ # headers used by drivers, etc
include/board/ # common headers used by legacy board files
board/ # common source code for legacy board files

The end goal being to empty and remove the board/'s and remove the other mach-*/ directories.

Alternatively, in this scenario we could name 'board' -> 'legacy' to make it more obvious.

thx,

Jason.

#112 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 8 lines · Jason Cooper

mach-mvebu/'s directory tree structure could be:
include/ # no headers
include/mach/ # headers used by drivers, etc
include/board/ # common headers used by legacy board files
board/ # common source code for legacy board files

The end goal being to empty and remove the board/'s and remove the other mach-*/ directories.

Looking at what's in dove, kirkwood, mv78xx0 and orion5x directories, I don't see many board specific files. The only two I can see are leds-*.h, which are shared with platform drivers in drivers/leds.

We have a place for this already - include/linux/platform_data.

So I don't think we need include/board/ at all.

I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them board-foo.c.

#113 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 10 lines · Russell King - ARM Linux
Quoted 8 lines · Jason Cooper

mach-mvebu/'s directory tree structure could be:
include/ # no headers
include/mach/ # headers used by drivers, etc
include/board/ # common headers used by legacy board files
board/ # common source code for legacy board files

The end goal being to empty and remove the board/'s and remove the other mach-*/ directories.

Quoted 7 lines

Looking at what's in dove, kirkwood, mv78xx0 and orion5x directories, I don't see many board specific files. The only two I can see are leds-*.h, which are shared with platform drivers in drivers/leds.

We have a place for this already - include/linux/platform_data.

So I don't think we need include/board/ at all.

Fair enough, we can move that.

Quoted 2 lines

I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them board-foo.c.

This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is board-dt.c, and board-dreamplug.c. board-dt.c is the DT code, while board-dreamplug.c is board specific init code that hasn't been converted to DT yet. Once converted, board-dreamplug.c will disappear. This follows what tegra is doing.

We can leave the legacy, unconverted boards where they are (mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c, pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...

Of course, we could leave everything alone (keep plat-orion/ as is), and create mach-mvebu/ for all devicetree boards under the mvebu umbrella. As boards are converted/moved to mach-mvebu/, they are deleted from their original mach-*/ All new boards would also go into mach-mvebu/

thx,

Jason.

#114 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 13 lines · Jason Cooper
Quoted 4 lines · Russell King - ARM Linux

On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:

I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them board-foo.c.

This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is board-dt.c, and board-dreamplug.c. board-dt.c is the DT code, while board-dreamplug.c is board specific init code that hasn't been converted to DT yet. Once converted, board-dreamplug.c will disappear. This follows what tegra is doing.

Quoted 4 lines

We can leave the legacy, unconverted boards where they are (mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c, pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...

I like the idea of leaving the *-setup.c board files where they are, while moving all the other files (headers and the platform-wide .c files) to mach-mvebu.

However, given that we still don't have consensus on where things should really be and the merge window is already open, I would suggest don't try to do it all now for v3.5 but rather plan it for v3.6 once we agreed on one approach, and then do some of the next consolidation steps as well.

Arnd

maintainer
#115 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 23 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 4 lines · Russell King - ARM Linux

On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:

I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them board-foo.c.

This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is board-dt.c, and board-dreamplug.c. board-dt.c is the DT code, while board-dreamplug.c is board specific init code that hasn't been converted to DT yet. Once converted, board-dreamplug.c will disappear. This follows what tegra is doing.

Quoted 4 lines

We can leave the legacy, unconverted boards where they are (mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c, pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...

I like the idea of leaving the *-setup.c board files where they are, while moving all the other files (headers and the platform-wide .c files) to mach-mvebu.

Quoted 5 lines

However, given that we still don't have consensus on where things should really be and the merge window is already open, I would suggest don't try to do it all now for v3.5 but rather plan it for v3.6 once we agreed on one approach, and then do some of the next consolidation steps as well.

I'd suggest that mach-mvebu be created earlier for the new EBU ARmada SOC support though.

Nicolas

#116 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 25 lines · Nicolas Pitre
Quoted 23 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 4 lines · Russell King - ARM Linux

On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:

I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them board-foo.c.

This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is board-dt.c, and board-dreamplug.c. board-dt.c is the DT code, while board-dreamplug.c is board specific init code that hasn't been converted to DT yet. Once converted, board-dreamplug.c will disappear. This follows what tegra is doing.

Quoted 4 lines

We can leave the legacy, unconverted boards where they are (mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c, pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...

I like the idea of leaving the *-setup.c board files where they are, while moving all the other files (headers and the platform-wide .c files) to mach-mvebu.

Quoted 8 lines
Quoted 5 lines

However, given that we still don't have consensus on where things should really be and the merge window is already open, I would suggest don't try to do it all now for v3.5 but rather plan it for v3.6 once we agreed on one approach, and then do some of the next consolidation steps as well.

I'd suggest that mach-mvebu be created earlier for the new EBU ARmada SOC support though.

I'd like to second that, and suggest moving mach-kirkwood/board-*.c to it. Basically, make it the one location for marvell SoC dt boards.

I'm looking at the scope of it now.

thx,

Jason.

#117 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 32 lines · Jason Cooper
Quoted 31 lines · Nicolas Pitre
Quoted 28 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 4 lines · Russell King - ARM Linux

On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:

I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them board-foo.c.

This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is board-dt.c, and board-dreamplug.c. board-dt.c is the DT code, while board-dreamplug.c is board specific init code that hasn't been converted to DT yet. Once converted, board-dreamplug.c will disappear. This follows what tegra is doing.

Quoted 4 lines

We can leave the legacy, unconverted boards where they are (mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c, pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...

I like the idea of leaving the *-setup.c board files where they are, while moving all the other files (headers and the platform-wide .c files) to mach-mvebu.

However, given that we still don't have consensus on where things should really be and the merge window is already open, I would suggest don't try to do it all now for v3.5 but rather plan it for v3.6 once we agreed on one approach, and then do some of the next consolidation steps as well.

Quoted 7 lines
Quoted 2 lines

I'd suggest that mach-mvebu be created earlier for the new EBU ARmada SOC support though.

I'd like to second that, and suggest moving mach-kirkwood/board-*.c to it. Basically, make it the one location for marvell SoC dt boards.

I'm looking at the scope of it now.

I'm going to say let's leave these alone for the moment. The kernel per-version diff is large enough as it is and moving stuff around for the sake of it is just going to make it larger and thus draw more unwanted attention to arch/arm.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#118 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 39 lines · Ben Dooks
Quoted 38 lines · Jason Cooper
Quoted 25 lines · Nicolas Pitre
Quoted 23 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 4 lines · Russell King - ARM Linux

On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:

I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them board-foo.c.

This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is board-dt.c, and board-dreamplug.c. board-dt.c is the DT code, while board-dreamplug.c is board specific init code that hasn't been converted to DT yet. Once converted, board-dreamplug.c will disappear. This follows what tegra is doing.

Quoted 4 lines

We can leave the legacy, unconverted boards where they are (mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c, pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...

I like the idea of leaving the *-setup.c board files where they are, while moving all the other files (headers and the platform-wide .c files) to mach-mvebu.

Quoted 8 lines
Quoted 5 lines

However, given that we still don't have consensus on where things should really be and the merge window is already open, I would suggest don't try to do it all now for v3.5 but rather plan it for v3.6 once we agreed on one approach, and then do some of the next consolidation steps as well.

I'd suggest that mach-mvebu be created earlier for the new EBU ARmada SOC support though.

I'd like to second that, and suggest moving mach-kirkwood/board-*.c to it. Basically, make it the one location for marvell SoC dt boards.

Quoted 6 lines
Quoted 1 line

I'm looking at the scope of it now.

I'm going to say let's leave these alone for the moment. The kernel per-version diff is large enough as it is and moving stuff around for the sake of it is just going to make it larger and thus draw more unwanted attention to arch/arm.

Fair enough.

thx,

Jason.

#119 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Ben Dooks
Quoted 1 line · Ben Dooks

On 22/05/12 17:03, Jason Cooper wrote:

[snip]

Quoted 4 lines

I'm going to say let's leave these alone for the moment. The kernel per-version diff is large enough as it is and moving stuff around for the sake of it is just going to make it larger and thus draw more unwanted attention to arch/arm.

We can re-visit this once we've had a chance to move the items out of plat-orion which can go under drivers/

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#120 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Jason Cooper
Quoted 8 lines · Jason Cooper
Quoted 4 lines · Nicolas Pitre

On Mon, 21 May 2012, Arnd Bergmann wrote:

I'd suggest that mach-mvebu be created earlier for the new EBU ARmada SOC support though.

I'd like to second that, and suggest moving mach-kirkwood/board-*.c to it. Basically, make it the one location for marvell SoC dt boards.

Yes, that was what I meant when I said we move everything but the *-setup.c files.

Arnd

#121 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Arnd Bergmann
Quoted 14 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 12 lines

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

Quoted 7 lines
Quoted 2 lines

I prefer mvebu_* ... nice and concise.

On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to arch/arm/mach-mvebu/board/*.c instead of arch/arm/mach-mvebu/*-setup.c

What board files?

As I see it there are no current users and all additional kernel support should simply use devicetree.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
maintainer
#122 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 23 lines · Ben Dooks
Quoted 14 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 12 lines

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

Quoted 7 lines
Quoted 2 lines

I prefer mvebu_* ... nice and concise.

On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to arch/arm/mach-mvebu/board/*.c instead of arch/arm/mach-mvebu/*-setup.c

Quoted 4 lines

What board files?

As I see it there are no current users and all additional kernel support should simply use devicetree.

There are currently 14 kirkwood boards, 21 orion5x, 2 dove and 5 mv78xx0 boards. All would end up in the same directory as part of this rename/merge.

Andrewy

#123 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 24 lines · Andrew Lunn
Quoted 23 lines · Ben Dooks
Quoted 21 lines · Arnd Bergmann
Quoted 8 lines · Jason Cooper
Quoted 8 lines

In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.

Quoted 7 lines
Quoted 4 lines

I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.

I prefer mvebu_* ... nice and concise.

On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to arch/arm/mach-mvebu/board/*.c instead of arch/arm/mach-mvebu/*-setup.c

Quoted 8 lines
Quoted 4 lines

What board files?

As I see it there are no current users and all additional kernel support should simply use devicetree.

There are currently 14 kirkwood boards, 21 orion5x, 2 dove and 5 mv78xx0 boards. All would end up in the same directory as part of this rename/merge.

Personally, my view is leave it alone and just add a new machine directory.

Pushing items around doesn't really help the amount of code in the kernel, the organisation does not add more than a line or two to the Makefiles.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
maintainer
#124 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 6 lines

Personally, my view is leave it alone and just add a new machine directory.

Pushing items around doesn't really help the amount of code in the kernel, the organisation does not add more than a line or two to the Makefiles.

It does however make it easier to see where the same code has been cut/paste. There is some stuff in the various Orion mach- directories which is repeated 4 times. The Armada XP port wanted to add a 5th copy. All this repeated code needs to be put into plat-orion.

Andrew

#125 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 2 lines · Andrew Lunn
Quoted 2 lines

Personally, my view is leave it alone and just add a new machine directory.

I agree, see my response to Russell.

Quoted 8 lines
Quoted 3 lines

Pushing items around doesn't really help the amount of code in the kernel, the organisation does not add more than a line or two to the Makefiles.

It does however make it easier to see where the same code has been cut/paste. There is some stuff in the various Orion mach- directories which is repeated 4 times. The Armada XP port wanted to add a 5th copy. All this repeated code needs to be put into plat-orion.

Does my suggested layout/migration path cover your concerns?

thx,

Jason.

maintainer
#126 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 10 lines · Jason Cooper
Quoted 2 lines · Andrew Lunn
Quoted 2 lines

Personally, my view is leave it alone and just add a new machine directory.

I agree, see my response to Russell.

Quoted 4 lines
Quoted 3 lines

Pushing items around doesn't really help the amount of code in the kernel, the organisation does not add more than a line or two to the Makefiles.

Quoted 6 lines
Quoted 4 lines

It does however make it easier to see where the same code has been cut/paste. There is some stuff in the various Orion mach- directories which is repeated 4 times. The Armada XP port wanted to add a 5th copy. All this repeated code needs to be put into plat-orion.

Does my suggested layout/migration path cover your concerns?

I actually like Arnd patch of putting everything into one directory. I've been building on that patch removing duplicate code, modifying the address map to make it as similar as possible, removing defines which are the same on all SoCs etc. I think actually having everything spread out is what has contributed to the X copies and needless incompatibilities.

My vote is to commit Arnd patch as is.

Andrew

#127 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Thomas Petazzoni
Quoted 12 lines · Thomas Petazzoni

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

At the moment, 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.

Quoted 3 lines

This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:

Hi Thomas,

The code looks reasonable overall, but I fear your timing is unfortunate and we can't expect to complete the review before the merge window opens. Things would have been much easier if you had posted preliminary versions a few weeks earlier, but my feeling is that this should be treated as v3.6 material.

Arnd

#128 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Hello Arnd,

Le Tue, 15 May 2012 11:06:46 +0000,
Arnd Bergmann <[email protected]> a ?crit :

Quoted 5 lines

The code looks reasonable overall, but I fear your timing is unfortunate and we can't expect to complete the review before the merge window opens. Things would have been much easier if you had posted preliminary versions a few weeks earlier, but my feeling is that this should be treated as v3.6 material.

We do not expect this to be treated as v3.5 material. From the very beginning, with a posting at this time, we have been targeting v3.6 for a potential inclusion.

Quoted 1 line

From our point of view, these are kind of the preliminary versions:

there are many comments that we'll have to take into account before getting to the version that can be merged.

Thanks,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#129 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Arnd Bergmann
Quoted 17 lines · Arnd Bergmann
Quoted 12 lines · Thomas Petazzoni

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

At the moment, 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.

Quoted 3 lines

This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:

Quoted 7 lines

Hi Thomas,

The code looks reasonable overall, but I fear your timing is unfortunate and we can't expect to complete the review before the merge window opens. Things would have been much easier if you had posted preliminary versions a few weeks earlier, but my feeling is that this should be treated as v3.6 material.

I'm happy for this to go in once v3.5 is out as long as the issues with the device-tree binding is sorted out and the few issues that have cropped up in testing are fixed.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#130 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Thomas Petazzoni
Quoted 51 lines · Thomas Petazzoni

Arnd, Olof,

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

At the moment, 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.

This preliminary support 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-mpic.txt  |   23 +
  Documentation/devicetree/bindings/arm/armada-timer.txt |   11
  Documentation/devicetree/bindings/arm/armada.txt       |   24 +
  MAINTAINERS                                            |    8
  arch/arm/Kconfig                                       |   12
  arch/arm/Makefile                                      |    1
  arch/arm/boot/dts/a370-db.dts                          |   41 ++
  arch/arm/boot/dts/a370.dtsi                            |   23 +
  arch/arm/boot/dts/armada.dtsi                          |   67 ++++
  arch/arm/boot/dts/axp-db.dts                           |   40 ++
  arch/arm/boot/dts/axp.dtsi                             |   43 +++
  arch/arm/configs/armada_defconfig                      |   47 +++
  arch/arm/mach-armada/Kconfig                           |   19 +
  arch/arm/mach-armada/Makefile                          |    3
  arch/arm/mach-armada/Makefile.boot                     |    1
  arch/arm/mach-armada/a370-dt.c                         |   41 ++
  arch/arm/mach-armada/axp-dt.c                          |   41 ++
  arch/arm/mach-armada/common.c                          |   56 +++
  arch/arm/mach-armada/common.h                          |   27 +
  arch/arm/mach-armada/include/mach/armada.h             |  234 ++++++++++++++++
  arch/arm/mach-armada/include/mach/bridge-regs.h        |   28 +
  arch/arm/mach-armada/include/mach/debug-macro.S        |   23 +
  arch/arm/mach-armada/include/mach/gpio.h               |   13
  arch/arm/mach-armada/include/mach/hardware.h           |   18 +
  arch/arm/mach-armada/include/mach/io.h                 |   24 +
  arch/arm/mach-armada/include/mach/irqs.h               |   96 ++++++
  arch/arm/mach-armada/include/mach/system.h             |   21 +
  arch/arm/mach-armada/include/mach/timex.h              |   13
  arch/arm/mach-armada/include/mach/uncompress.h         |   41 ++
  arch/arm/mach-armada/irq.c                             |  116 ++++++++
  arch/arm/mach-armada/time.c                            |  243 +++++++++++++++++
  31 files changed, 1398 insertions(+)
Quoted 7 lines

This patch set, and the support for those SoCs, is at the moment 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.). Other contributors are expected to join this effort.

The patch set is based on your arm-soc/for-next branch.

Is there a git tree that can be pulled from?

Quoted 4 lines

We intend to quickly build on top of this initial support with the following elements:

* Usage of the clock framework

I'd say that was a pretty important part even if it just a couple of static clocks for the tclk and fabric clock.

Quoted 19 lines

* Usage the pinctrl subsystem and GPIO subsystems for pin-muxing and GPIO support

* SMP support

* L2 cache support

* Integration with device drivers. Many of the IPs used in these Marvell SoCs are similar to the ones used in previous Marvell SoCs (for SATA, USB and more), but the drivers for those IPs will require modification to add a device tree binding.

Of course, we welcome all comments on this initial submission and are ready to quickly submit updated versions of the patch set to take into those comments.

Best regards,

Thomas Petazzoni

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#131 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 11 lines

-----Original Message-----
From: Ben Dooks [mailto:ben.dooks at codethink.co.uk]
Sent: Tuesday, May 15, 2012 2:19 PM
To: Thomas Petazzoni
Cc: Arnd Bergmann; Olof Johansson; Lior Amsalem; Andrew Lunn; Jason Cooper; Nicolas Pitre; Maen Suleiman; Ben Dooks; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH] arm: Add basic support for new Marvell Armada SoC family

On 15/05/12 09:54, Thomas Petazzoni wrote:

[snip]

Quoted 4 lines
Quoted 2 lines

The patch set is based on your arm-soc/for-next branch.

Is there a git tree that can be pulled from?

https://github.com/Marvell-Semi/EBU_mainline_public/tree/for-next

Quoted 9 lines
Quoted 5 lines

We intend to quickly build on top of this initial support with the following elements:

* Usage of the clock framework

I'd say that was a pretty important part even if it just a couple of static clocks for the tclk and fabric clock.

It's one of our tasks list, should be ready soon.

Quoted 9 lines
Quoted 4 lines

Best regards,

Thomas Petazzoni

--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius

Lior Amsalem

#132 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Ben Dooks

Le Tue, 15 May 2012 12:18:55 +0100,
Ben Dooks <[email protected]> a ?crit :

Quoted 3 lines
Quoted 1 line

The patch set is based on your arm-soc/for-next branch.

Is there a git tree that can be pulled from?

Yes: https://github.com/Marvell-Semi/EBU_mainline_public/tree/for-next.

Note that of course we will be constantly rebasing this branch.

Quoted 7 lines
Quoted 4 lines

We intend to quickly build on top of this initial support with the following elements:

* Usage of the clock framework

I'd say that was a pretty important part even if it just a couple of static clocks for the tclk and fabric clock.

As Lior said, it's on the TODO-list. It's true that adding the few static clocks to tclk and the fabric clock can probably be done in this initial submission, as the amount of work needed is fairly small.

Thanks,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#133 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Thomas Petazzoni
Quoted 5 lines · Thomas Petazzoni

Arnd, Olof,

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

[snip]

Out of interest, what about the Marvell Sheeva-V7 core specific errata that the Marvell kernel has?

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#134 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 13 lines

-----Original Message-----
From: Ben Dooks [mailto:ben.dooks at codethink.co.uk]
Sent: Tuesday, May 15, 2012 2:21 PM
To: Thomas Petazzoni
Cc: Arnd Bergmann; Olof Johansson; Lior Amsalem; Andrew Lunn; Jason Cooper; Nicolas Pitre; Maen Suleiman; Ben Dooks; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH] arm: Add basic support for new Marvell Armada SoC family

Quoted 2 lines · Thomas Petazzoni

Arnd, Olof,

Quoted 8 lines
Quoted 3 lines

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

[snip]

Out of interest, what about the Marvell Sheeva-V7 core specific errata that the Marvell kernel has?

Work in progress. As well as SMP support.

Quoted 4 lines

--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius

Lior Amsalem

#135 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Thomas Petazzoni
Quoted 14 lines · Thomas Petazzoni

Arnd, Olof,

You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.

At the moment, 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.

Quoted 3 lines

This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:

FYI, built and tested on our system here and it gets to printing the sched_clock line and getting no further.

I will have a debug.

The only comment so far other than the review issues is that we needed to enable CONFIG_HIGMEM to get >780MiB of memory as this system comes with 2048MiB as standard.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#136 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Le Tue, 15 May 2012 15:55:07 +0100,
Ben Dooks <[email protected]> a ?crit :

Quoted 8 lines
Quoted 3 lines

This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:

FYI, built and tested on our system here and it gets to printing the sched_clock line and getting no further.

I will have a debug.

Hum, strange. On which platform exactly?

I've built from scratch a kernel image this morning and boot tested it on both the DB-78460-BP (Armada XP) and DB-88F6710-BP (Armada 370) this morning, and it was working.

Quoted 3 lines

The only comment so far other than the review issues is that we needed to enable CONFIG_HIGMEM to get >780MiB of memory as this system comes with 2048MiB as standard.

Good point. Will do.

Thanks!

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#137 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Quoted 7 lines · Thomas Petazzoni

Le Tue, 15 May 2012 15:55:07 +0100,
Ben Dooks<[email protected]> a ?crit :

Quoted 4 lines
Quoted 3 lines

This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:

Quoted 6 lines
Quoted 4 lines

FYI, built and tested on our system here and it gets to printing the sched_clock line and getting no further.

I will have a debug.

Hum, strange. On which platform exactly?

Cogent CS1726, using MV78460 (A0)

Quoted 9 lines

I've built from scratch a kernel image this morning and boot tested it on both the DB-78460-BP (Armada XP) and DB-88F6710-BP (Armada 370) this morning, and it was working.

Quoted 3 lines

The only comment so far other than the review issues is that we needed to enable CONFIG_HIGMEM to get>780MiB of memory as this system comes with 2048MiB as standard.

Good point. Will do.

I'm guessing it'll be a useful default, but not a necessity.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#138 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

In reply to Thomas Petazzoni
Quoted 7 lines · Thomas Petazzoni

Le Tue, 15 May 2012 15:55:07 +0100,
Ben Dooks<[email protected]> a ?crit :

Quoted 4 lines
Quoted 3 lines

This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:

Quoted 6 lines
Quoted 4 lines

FYI, built and tested on our system here and it gets to printing the sched_clock line and getting no further.

I will have a debug.

Hum, strange. On which platform exactly?

I've tracked this down to the following:
arch/arm/mach-armada/time.c

    190          } else {
    191                  u32 clk;
    192                  of_property_read_u32(np, "clock-frequency", &clk);
    193                  WARN_ON(!clk);

The problem is the 'clk' variable is un-initialised and therefore the fact my device-tree is missing a clock-frequency property is causing the system to use what was in 'clk' which was around 16000 from the stack.

I suggest that any property that is necessary to a unit operation should check that there was something to read. WARN_ON() is fine, but they you should not carry on and initialise the unit anyway.

I have now gone and fixed my .dts file and the system now gets to the point to try and mount an initrd.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#139 lore raw

PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family

Le Tue, 15 May 2012 16:36:03 +0100,
Ben Dooks <[email protected]> a ?crit :

Quoted 13 lines

I've tracked this down to the following:
arch/arm/mach-armada/time.c

    190          } else {
    191                  u32 clk;
    192                  of_property_read_u32(np, "clock-frequency",

&clk); 193 WARN_ON(!clk);

The problem is the 'clk' variable is un-initialised and therefore the fact my device-tree is missing a clock-frequency property is causing the system to use what was in 'clk' which was around 16000 from the stack.

Quoted 6 lines

I suggest that any property that is necessary to a unit operation should check that there was something to read. WARN_ON() is fine, but they you should not carry on and initialise the unit anyway.

I have now gone and fixed my .dts file and the system now gets to the point to try and mount an initrd.

Thanks for your report and investigation, you're obviously correct. We'll fix that.

Thomas

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