* [PATCH] arm: Add basic support for new Marvell Armada SoC family
@ 2012-05-15 8:54 Thomas Petazzoni
2012-05-15 8:54 ` [PATCH 1/8] arm: mach-armada: add headers Thomas Petazzoni
` (12 more replies)
0 siblings, 13 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 8:54 UTC (permalink / raw)
To: linux-arm-kernel
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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 1/8] arm: mach-armada: add headers
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
@ 2012-05-15 8:54 ` Thomas Petazzoni
2012-05-15 9:16 ` Ben Dooks
` (2 more replies)
2012-05-15 8:54 ` [PATCH 2/8] arm: mach-armada: add source files Thomas Petazzoni
` (11 subsequent siblings)
12 siblings, 3 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 8:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
This patch adds basic header files for Armada SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
arch/arm/mach-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
diff --git a/arch/arm/mach-armada/include/mach/armada.h b/arch/arm/mach-armada/include/mach/armada.h
new file mode 100644
index 0000000..be12667
--- /dev/null
+++ b/arch/arm/mach-armada/include/mach/armada.h
@@ -0,0 +1,234 @@
+/*
+ * Generic definitions for Marvell Armada SoCs
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __MACH_ARMADA_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 */
diff --git a/arch/arm/mach-armada/include/mach/bridge-regs.h b/arch/arm/mach-armada/include/mach/bridge-regs.h
new file mode 100644
index 0000000..0eaefbd
--- /dev/null
+++ b/arch/arm/mach-armada/include/mach/bridge-regs.h
@@ -0,0 +1,28 @@
+/*
+ * Mbus-L to Mbus Bridge Registers
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __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
diff --git a/arch/arm/mach-armada/include/mach/debug-macro.S b/arch/arm/mach-armada/include/mach/debug-macro.S
new file mode 100644
index 0000000..1c7c52f
--- /dev/null
+++ b/arch/arm/mach-armada/include/mach/debug-macro.S
@@ -0,0 +1,23 @@
+/*
+ * Early serial output macro for Marvell Armada SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <mach/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>
diff --git a/arch/arm/mach-armada/include/mach/gpio.h b/arch/arm/mach-armada/include/mach/gpio.h
new file mode 100644
index 0000000..e62f38a
--- /dev/null
+++ b/arch/arm/mach-armada/include/mach/gpio.h
@@ -0,0 +1,13 @@
+/*
+ * Marvell Armada SoC GPIO definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <plat/gpio.h>
diff --git a/arch/arm/mach-armada/include/mach/hardware.h b/arch/arm/mach-armada/include/mach/hardware.h
new file mode 100644
index 0000000..829111b
--- /dev/null
+++ b/arch/arm/mach-armada/include/mach/hardware.h
@@ -0,0 +1,18 @@
+/*
+ * Marvell Armada SoC hardware definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __ASM_ARCH_HARDWARE_H
+#define __ASM_ARCH_HARDWARE_H
+
+#include <mach/armada.h>
+
+#endif
diff --git a/arch/arm/mach-armada/include/mach/io.h b/arch/arm/mach-armada/include/mach/io.h
new file mode 100644
index 0000000..48716c1
--- /dev/null
+++ b/arch/arm/mach-armada/include/mach/io.h
@@ -0,0 +1,24 @@
+/*
+ * Basic I/O macros
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#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
diff --git a/arch/arm/mach-armada/include/mach/irqs.h b/arch/arm/mach-armada/include/mach/irqs.h
new file mode 100644
index 0000000..48844a4
--- /dev/null
+++ b/arch/arm/mach-armada/include/mach/irqs.h
@@ -0,0 +1,96 @@
+/*
+ * IRQ definitions for Marvell Armada SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#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
+
+/*
+ * ARMADA General Purpose Pins
+ */
+#define IRQ_ARMADA_GPIO_START 82
+#define NR_GPIO_IRQS 64
+
+#define NR_IRQS (115)
+
+
+#endif
diff --git a/arch/arm/mach-armada/include/mach/system.h b/arch/arm/mach-armada/include/mach/system.h
new file mode 100644
index 0000000..f920ef0
--- /dev/null
+++ b/arch/arm/mach-armada/include/mach/system.h
@@ -0,0 +1,21 @@
+/*
+ * Marvell Armada SoC system defines
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __ASM_ARCH_SYSTEM_H
+#define __ASM_ARCH_SYSTEM_H
+
+static inline void arch_idle(void)
+{
+ cpu_do_idle();
+}
+
+#endif
diff --git a/arch/arm/mach-armada/include/mach/timex.h b/arch/arm/mach-armada/include/mach/timex.h
new file mode 100644
index 0000000..ab324a3
--- /dev/null
+++ b/arch/arm/mach-armada/include/mach/timex.h
@@ -0,0 +1,13 @@
+/*
+ * Marvell Armada SoC time definitions
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define CLOCK_TICK_RATE (100 * HZ)
diff --git a/arch/arm/mach-armada/include/mach/uncompress.h b/arch/arm/mach-armada/include/mach/uncompress.h
new file mode 100644
index 0000000..611ebf3
--- /dev/null
+++ b/arch/arm/mach-armada/include/mach/uncompress.h
@@ -0,0 +1,41 @@
+/*
+ * Marvell Armada SoC kernel uncompression UART routines
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <mach/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()
--
1.7.9.5
^ permalink raw reply related [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
2012-05-15 8:54 ` [PATCH 1/8] arm: mach-armada: add headers Thomas Petazzoni
@ 2012-05-15 8:54 ` Thomas Petazzoni
2012-05-15 9:12 ` Andrew Lunn
` (4 more replies)
2012-05-15 8:54 ` [PATCH 3/8] arm: mach-armada: add documentation for new device tree bindings Thomas Petazzoni
` (10 subsequent siblings)
12 siblings, 5 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 8:54 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds basic source files for Marvell Armada SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
arch/arm/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
diff --git a/arch/arm/boot/dts/a370.dtsi b/arch/arm/boot/dts/a370.dtsi
new file mode 100644
index 0000000..f11e56a
--- /dev/null
+++ b/arch/arm/boot/dts/a370.dtsi
@@ -0,0 +1,23 @@
+/*
+ * Device Tree Include file for Marvell Armada 370 family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Contains definitions specific to the Armada 370 SoC that are not
+ * common to all Armada SoCs.
+ */
+
+/include/ "armada.dtsi"
+
+/ {
+ model = "Marvell Armada 370 family SoC";
+ compatible = "marvell,armada370", "marvell,armada";
+ };
diff --git a/arch/arm/boot/dts/armada.dtsi b/arch/arm/boot/dts/armada.dtsi
new file mode 100644
index 0000000..3c99c30
--- /dev/null
+++ b/arch/arm/boot/dts/armada.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Device Tree Include file for Marvell Armada family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * This file contains the definitions that are common to the Armada
+ * 370 and Armada XP SoC.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Marvell Armada family SoC";
+ compatible = "marvell,armada";
+
+ cpus {
+ cpu at 0 {
+ compatible = "marvell,sheeva-v7";
+ };
+ };
+
+ mpic: interrupt-controller at d0020000 {
+ compatible = "marvell,mpic";
+ #interrupt-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-controller;
+ reg = <0xd0020000 0x1000>,
+ <0xd0021000 0x1000>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&mpic>;
+ ranges;
+
+ serial at d0012000 {
+ compatible = "ns16550";
+ reg = <0xd0012000 0x100>;
+ reg-shift = <2>;
+ interrupts = <41>;
+ };
+ serial at d0012100 {
+ compatible = "ns16550";
+ reg = <0xd0012100 0x100>;
+ reg-shift = <2>;
+ interrupts = <42>;
+ };
+
+ timer at d0020300 {
+ compatible = "marvell,timer";
+ reg = <0xd0020300 0x30>;
+ interrupts = <37>, <38>, <39>, <40>;
+ };
+ };
+};
+
diff --git a/arch/arm/boot/dts/axp.dtsi b/arch/arm/boot/dts/axp.dtsi
new file mode 100644
index 0000000..6427268
--- /dev/null
+++ b/arch/arm/boot/dts/axp.dtsi
@@ -0,0 +1,43 @@
+/*
+ * Device Tree Include file for Marvell Armada XP family SoC
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * 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 XP family SoC";
+ compatible = "marvell,armadaxp", "marvell,armada";
+
+ soc {
+ serial at d0012200 {
+ compatible = "ns16550";
+ reg = <0xd0012200 0x100>;
+ reg-shift = <2>;
+ interrupts = <43>;
+ };
+ serial at d0012300 {
+ compatible = "ns16550";
+ reg = <0xd0012300 0x100>;
+ reg-shift = <2>;
+ interrupts = <44>;
+ };
+
+ timer at d0020300 {
+ marvell,timer-25Mhz;
+ };
+ };
+ };
+
diff --git a/arch/arm/mach-armada/Kconfig b/arch/arm/mach-armada/Kconfig
new file mode 100644
index 0000000..010a6a3
--- /dev/null
+++ b/arch/arm/mach-armada/Kconfig
@@ -0,0 +1,5 @@
+if ARCH_ARMADA
+
+menu "Marvell Armada Implementations"
+
+endif
diff --git a/arch/arm/mach-armada/Makefile b/arch/arm/mach-armada/Makefile
new file mode 100644
index 0000000..6765961
--- /dev/null
+++ b/arch/arm/mach-armada/Makefile
@@ -0,0 +1,2 @@
+obj-y += common.o irq.o time.o
+
diff --git a/arch/arm/mach-armada/Makefile.boot b/arch/arm/mach-armada/Makefile.boot
new file mode 100644
index 0000000..b327175
--- /dev/null
+++ b/arch/arm/mach-armada/Makefile.boot
@@ -0,0 +1 @@
+zreladdr-y := 0x00008000
diff --git a/arch/arm/mach-armada/common.c b/arch/arm/mach-armada/common.c
new file mode 100644
index 0000000..92d9ec2
--- /dev/null
+++ b/arch/arm/mach-armada/common.c
@@ -0,0 +1,56 @@
+/*
+ * Core functions for Marvell Armada System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#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"
+
+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)
+ ;
+}
diff --git a/arch/arm/mach-armada/common.h b/arch/arm/mach-armada/common.h
new file mode 100644
index 0000000..e453161
--- /dev/null
+++ b/arch/arm/mach-armada/common.h
@@ -0,0 +1,27 @@
+/*
+ * Core functions for Marvell Armada System On Chip
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __ARCH_ARMADA_COMMON_H
+#define __ARCH_ARMADA_COMMON_H
+
+#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
diff --git a/arch/arm/mach-armada/irq.c b/arch/arm/mach-armada/irq.c
new file mode 100644
index 0000000..7006429
--- /dev/null
+++ b/arch/arm/mach-armada/irq.c
@@ -0,0 +1,116 @@
+/*
+ * Marvall Armada SoC IRQ handling
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * 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);
+}
+
+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,
+ 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;
+}
+
+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);
+
+ 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);
+ irqnr = irqstat & 0x3FF;
+
+ if (irqnr < 1023) {
+ irqnr = irq_find_mapping(armada_mpic_domain, irqnr);
+ handle_IRQ(irqnr, regs);
+ continue;
+ }
+
+ break;
+ } while (1);
+}
+
+static const struct of_device_id mpic_of_match[] __initconst = {
+ { .compatible = "marvell,mpic", .data = armada_mpic_of_init },
+ {},
+};
+
+void __init armada_init_irq(void)
+{
+ of_irq_init(mpic_of_match);
+}
diff --git a/arch/arm/mach-armada/time.c b/arch/arm/mach-armada/time.c
new file mode 100644
index 0000000..73817ea
--- /dev/null
+++ b/arch/arm/mach-armada/time.c
@@ -0,0 +1,243 @@
+/*
+ * Marvell Armada SoC timer handling.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Timer 0 is used as free-running clocksource, while timer 1 is
+ * used as clock_event_device.
+ */
+
+#include <linux/kernel.h>
+#include <linux/timer.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/irq.h>
+#include <asm/sched_clock.h>
+#include <asm/mach/time.h>
+
+/*
+ * Timer block registers.
+ */
+#define TIMER_CTRL_OFF 0x0000
+#define TIMER0_EN 0x0001
+#define TIMER0_RELOAD_EN 0x0002
+#define TIMER0_25MHZ 0x0800
+#define TIMER0_DIV(div) ((div) << 19)
+#define TIMER1_EN 0x0004
+#define TIMER1_RELOAD_EN 0x0008
+#define TIMER1_25MHZ 0x1000
+#define TIMER1_DIV(div) ((div) << 22)
+#define TIMER_EVENTS_STATUS 0x0004
+#define TIMER0_CLR_MASK (~0x1)
+#define TIMER1_CLR_MASK (~0x100)
+#define TIMER0_RELOAD_OFF 0x0010
+#define TIMER0_VAL_OFF 0x0014
+#define TIMER1_RELOAD_OFF 0x0018
+#define TIMER1_VAL_OFF 0x001c
+
+/* Global timers are connected to the coherency fabric clock, and the
+ below divider reduces their incrementing frequency. */
+#define TIMER_DIVIDER_SHIFT 5
+#define TIMER_DIVIDER (1 << TIMER_DIVIDER_SHIFT)
+
+/*
+ * SoC-specific data.
+ */
+static void __iomem *timer_base;
+static int timer_irq;
+
+/*
+ * Number of timer ticks per jiffy.
+ */
+static u32 ticks_per_jiffy;
+
+static u32 notrace armada_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));
+ writel(u, timer_base + TIMER_CTRL_OFF);
+
+ local_irq_restore(flags);
+
+ return 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@1/HZ intervals.
+ */
+ writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD_OFF);
+ writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL_OFF);
+
+ /*
+ * Enable timer.
+ */
+ u = readl(timer_base + TIMER_CTRL_OFF);
+
+ writel((u | TIMER1_EN | TIMER1_RELOAD_EN |
+ TIMER1_DIV(TIMER_DIVIDER_SHIFT)),
+ timer_base + TIMER_CTRL_OFF);
+ } else {
+ /*
+ * Disable timer.
+ */
+ u = readl(timer_base + TIMER_CTRL_OFF);
+ writel(u & ~TIMER1_EN, timer_base + TIMER_CTRL_OFF);
+
+ /*
+ * ACK pending timer interrupt.
+ */
+ writel(TIMER1_CLR_MASK,
+ timer_base + TIMER_EVENTS_STATUS);
+
+ }
+ local_irq_restore(flags);
+}
+
+static struct clock_event_device armada_clkevt = {
+ .name = "armada_tick",
+ .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
+ .shift = 32,
+ .rating = 300,
+ .set_next_event = armada_clkevt_next_event,
+ .set_mode = armada_clkevt_mode,
+};
+
+static irqreturn_t armada_timer_interrupt(int irq, void *dev_id)
+{
+ /*
+ * ACK timer interrupt and call event handler.
+ */
+
+ writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
+ armada_clkevt.event_handler(&armada_clkevt);
+
+ return IRQ_HANDLED;
+}
+
+static struct irqaction armada_timer_irq = {
+ .name = "armada_tick",
+ .flags = IRQF_DISABLED | IRQF_TIMER,
+ .handler = armada_timer_interrupt
+};
+
+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);
+ u = readl(timer_base + TIMER_CTRL_OFF);
+ writel(u & ~(TIMER0_25MHZ | TIMER1_25MHZ),
+ timer_base + TIMER_CTRL_OFF);
+ timer_clk = clk / TIMER_DIVIDER;
+ }
+
+ /* We use timer 0 as clocksource, and timer 1 for
+ clockevents */
+ timer_irq = irq_of_parse_and_map(np, 1);
+
+ ticks_per_jiffy = (timer_clk + HZ/2) / HZ;
+
+ /*
+ * Set scale and timer for sched_clock.
+ */
+ setup_sched_clock(armada_read_sched_clock, 32, timer_clk);
+
+ /*
+ * Setup free-running clocksource timer (interrupts
+ * disabled).
+ */
+ writel(0xffffffff, timer_base + TIMER0_VAL_OFF);
+ writel(0xffffffff, timer_base + TIMER0_RELOAD_OFF);
+
+ u = readl(timer_base + TIMER_CTRL_OFF);
+
+ writel((u | TIMER0_EN | TIMER0_RELOAD_EN |
+ TIMER0_DIV(TIMER_DIVIDER_SHIFT)),
+ timer_base + TIMER_CTRL_OFF);
+
+ clocksource_mmio_init(timer_base + TIMER0_VAL_OFF,
+ "armada_clocksource",
+ timer_clk, 300, 32,
+ clocksource_mmio_readl_down);
+
+ /*
+ * Setup clockevent timer (interrupt-driven).
+ */
+ setup_irq(timer_irq, &armada_timer_irq);
+ armada_clkevt.mult = div_sc(timer_clk, NSEC_PER_SEC,
+ armada_clkevt.shift);
+ armada_clkevt.max_delta_ns = clockevent_delta2ns(0xfffffffe,
+ &armada_clkevt);
+ armada_clkevt.min_delta_ns = clockevent_delta2ns(1, &armada_clkevt);
+ armada_clkevt.cpumask = cpumask_of(0);
+ clockevents_register_device(&armada_clkevt);
+}
+
+struct sys_timer armada_timer = {
+ .init = armada_time_init,
+};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 140+ messages in thread
* [PATCH 3/8] arm: mach-armada: add documentation for new device tree bindings
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
2012-05-15 8:54 ` [PATCH 1/8] arm: mach-armada: add headers Thomas Petazzoni
2012-05-15 8:54 ` [PATCH 2/8] arm: mach-armada: add source files Thomas Petazzoni
@ 2012-05-15 8:54 ` Thomas Petazzoni
2012-05-15 11:31 ` Ben Dooks
2012-05-15 8:54 ` [PATCH 4/8] arm: mach-armada: add compilation/configuration changes Thomas Petazzoni
` (9 subsequent siblings)
12 siblings, 1 reply; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 8:54 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../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
diff --git a/Documentation/devicetree/bindings/arm/armada-mpic.txt b/Documentation/devicetree/bindings/arm/armada-mpic.txt
new file mode 100644
index 0000000..3571f44
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-mpic.txt
@@ -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>;
+ };
diff --git a/Documentation/devicetree/bindings/arm/armada-timer.txt b/Documentation/devicetree/bindings/arm/armada-timer.txt
new file mode 100644
index 0000000..6bed565
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-timer.txt
@@ -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)
diff --git a/Documentation/devicetree/bindings/arm/armada.txt b/Documentation/devicetree/bindings/arm/armada.txt
new file mode 100644
index 0000000..9724178
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada.txt
@@ -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"
+
--
1.7.9.5
^ permalink raw reply related [flat|nested] 140+ messages in thread
* [PATCH 4/8] arm: mach-armada: add compilation/configuration changes
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
` (2 preceding siblings ...)
2012-05-15 8:54 ` [PATCH 3/8] arm: mach-armada: add documentation for new device tree bindings Thomas Petazzoni
@ 2012-05-15 8:54 ` Thomas Petazzoni
2012-05-15 8:54 ` [PATCH 5/8] arm: mach-armada: add support for Armada 370 board with device tree Thomas Petazzoni
` (8 subsequent siblings)
12 siblings, 0 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 8:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
arch/arm/Kconfig | 12 ++++++++++++
arch/arm/Makefile | 1 +
2 files changed, 13 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d595bd3..8c8987b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -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"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 8c4dac4..eaf84fa 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -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.
--
1.7.9.5
^ permalink raw reply related [flat|nested] 140+ messages in thread
* [PATCH 5/8] arm: mach-armada: add support for Armada 370 board with device tree
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
` (3 preceding siblings ...)
2012-05-15 8:54 ` [PATCH 4/8] arm: mach-armada: add compilation/configuration changes Thomas Petazzoni
@ 2012-05-15 8:54 ` Thomas Petazzoni
2012-05-15 8:54 ` [PATCH 6/8] arm: mach-armada: add support for Armada XP " Thomas Petazzoni
` (7 subsequent siblings)
12 siblings, 0 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 8:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
arch/arm/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
diff --git a/arch/arm/boot/dts/a370-db.dts b/arch/arm/boot/dts/a370-db.dts
new file mode 100644
index 0000000..7bf747e
--- /dev/null
+++ b/arch/arm/boot/dts/a370-db.dts
@@ -0,0 +1,41 @@
+/*
+ * Device Tree file for Marvell Armada 370 evaluation board
+ * (DB-88F6710-BP-DDR3)
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "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>;
+
+ };
+ };
+};
diff --git a/arch/arm/mach-armada/Kconfig b/arch/arm/mach-armada/Kconfig
index 010a6a3..7995813 100644
--- a/arch/arm/mach-armada/Kconfig
+++ b/arch/arm/mach-armada/Kconfig
@@ -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
diff --git a/arch/arm/mach-armada/Makefile b/arch/arm/mach-armada/Makefile
index 6765961..ac39fae 100644
--- a/arch/arm/mach-armada/Makefile
+++ b/arch/arm/mach-armada/Makefile
@@ -1,2 +1,3 @@
obj-y += common.o irq.o time.o
+obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o
diff --git a/arch/arm/mach-armada/a370-dt.c b/arch/arm/mach-armada/a370-dt.c
new file mode 100644
index 0000000..f75ba77
--- /dev/null
+++ b/arch/arm/mach-armada/a370-dt.c
@@ -0,0 +1,41 @@
+/*
+ * Device Tree support for Armada 370 platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of_platform.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/armada.h>
+#include "common.h"
+
+static void __init a370_dt_init(void)
+{
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char * const a370_dt_board_compat[] = {
+ "marvell,a370-db",
+ NULL,
+};
+
+DT_MACHINE_START(ARMADA_370_DT, "Marvell Aramada 370 (Device Tree)")
+ .init_machine = a370_dt_init,
+ .map_io = armada_map_io,
+ .init_irq = armada_init_irq,
+ .handle_irq = armada_handle_irq,
+ .timer = &armada_timer,
+ .restart = armada_restart,
+ .dt_compat = a370_dt_board_compat,
+MACHINE_END
--
1.7.9.5
^ permalink raw reply related [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
` (4 preceding siblings ...)
2012-05-15 8:54 ` [PATCH 5/8] arm: mach-armada: add support for Armada 370 board with device tree Thomas Petazzoni
@ 2012-05-15 8:54 ` Thomas Petazzoni
2012-05-15 9:58 ` Ben Dooks
2012-05-15 8:54 ` [PATCH 7/8] arm: mach-armada: add defconfig Thomas Petazzoni
` (6 subsequent siblings)
12 siblings, 1 reply; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 8:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
arch/arm/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
diff --git a/arch/arm/boot/dts/axp-db.dts b/arch/arm/boot/dts/axp-db.dts
new file mode 100644
index 0000000..916be09
--- /dev/null
+++ b/arch/arm/boot/dts/axp-db.dts
@@ -0,0 +1,40 @@
+/*
+ * Device Tree file for Marvell Armada XP evaluation board
+ * (DB-78460-BP)
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "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>;
+ };
+ };
+};
diff --git a/arch/arm/mach-armada/Kconfig b/arch/arm/mach-armada/Kconfig
index 7995813..2903096 100644
--- a/arch/arm/mach-armada/Kconfig
+++ b/arch/arm/mach-armada/Kconfig
@@ -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
diff --git a/arch/arm/mach-armada/Makefile b/arch/arm/mach-armada/Makefile
index ac39fae..7a3c438 100644
--- a/arch/arm/mach-armada/Makefile
+++ b/arch/arm/mach-armada/Makefile
@@ -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
diff --git a/arch/arm/mach-armada/axp-dt.c b/arch/arm/mach-armada/axp-dt.c
new file mode 100644
index 0000000..2c13d4e
--- /dev/null
+++ b/arch/arm/mach-armada/axp-dt.c
@@ -0,0 +1,41 @@
+/*
+ * Device Tree support for Armada XP platforms.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of_platform.h>
+#include <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);
+}
+
+static const char * const axp_dt_board_dt_compat[] = {
+ "marvell,axp-db",
+ NULL,
+};
+
+DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada XP (Device Tree)")
+ .init_machine = axp_dt_init,
+ .map_io = armada_map_io,
+ .init_irq = armada_init_irq,
+ .handle_irq = armada_handle_irq,
+ .timer = &armada_timer,
+ .restart = armada_restart,
+ .dt_compat = axp_dt_board_dt_compat,
+MACHINE_END
--
1.7.9.5
^ permalink raw reply related [flat|nested] 140+ messages in thread
* [PATCH 7/8] arm: mach-armada: add defconfig
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
` (5 preceding siblings ...)
2012-05-15 8:54 ` [PATCH 6/8] arm: mach-armada: add support for Armada XP " Thomas Petazzoni
@ 2012-05-15 8:54 ` Thomas Petazzoni
2012-05-15 9:58 ` Ben Dooks
2012-05-15 8:54 ` [PATCH 8/8] arm: mach-armada: add entry to MAINTAINERS Thomas Petazzoni
` (5 subsequent siblings)
12 siblings, 1 reply; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 8:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
arch/arm/configs/armada_defconfig | 47 +++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 arch/arm/configs/armada_defconfig
diff --git a/arch/arm/configs/armada_defconfig b/arch/arm/configs/armada_defconfig
new file mode 100644
index 0000000..3ead861
--- /dev/null
+++ b/arch/arm/configs/armada_defconfig
@@ -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
--
1.7.9.5
^ permalink raw reply related [flat|nested] 140+ messages in thread
* [PATCH 8/8] arm: mach-armada: add entry to MAINTAINERS
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
` (6 preceding siblings ...)
2012-05-15 8:54 ` [PATCH 7/8] arm: mach-armada: add defconfig Thomas Petazzoni
@ 2012-05-15 8:54 ` Thomas Petazzoni
2012-05-15 9:18 ` [PATCH] arm: Add basic support for new Marvell Armada SoC family Andrew Lunn
` (4 subsequent siblings)
12 siblings, 0 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 8:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ca8d7f9..2cd4235 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -894,6 +894,14 @@ ARM/MAGICIAN MACHINE SUPPORT
M: Philipp Zabel <philipp.zabel@gmail.com>
S: Maintained
+ARM/Marvell Armada SOC support
+M: Gregory Clement <gregory.clement@free-electrons.com>
+M: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+M: Lior Amsalem <alior@marvell.com>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/mach-armada/
+
ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support
M: Jason Cooper <jason@lakedaemon.net>
M: Andrew Lunn <andrew@lunn.ch>
--
1.7.9.5
^ permalink raw reply related [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 8:54 ` [PATCH 2/8] arm: mach-armada: add source files Thomas Petazzoni
@ 2012-05-15 9:12 ` Andrew Lunn
2012-05-15 9:17 ` Thomas Petazzoni
2012-05-15 9:27 ` Andrew Lunn
` (3 subsequent siblings)
4 siblings, 1 reply; 140+ messages in thread
From: Andrew Lunn @ 2012-05-15 9:12 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 10:54:38AM +0200, Thomas Petazzoni wrote:
> This patch adds basic source files for Marvell Armada SoCs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Lior Amsalem <alior@marvell.com>
> ---
> arch/arm/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
>
> diff --git a/arch/arm/boot/dts/a370.dtsi b/arch/arm/boot/dts/a370.dtsi
> new file mode 100644
> index 0000000..f11e56a
> --- /dev/null
> +++ b/arch/arm/boot/dts/a370.dtsi
> @@ -0,0 +1,23 @@
> +/*
> + * Device Tree Include file for Marvell Armada 370 family SoC
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * Contains definitions specific to the Armada 370 SoC that are not
> + * common to all Armada SoCs.
> + */
> +
> +/include/ "armada.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.
> +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)
> + ;
> +}
This chunk of code comes up multiple times in various orion
devices. Could it be refactored into plat-orion?
Thanks
Andrew
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 1/8] arm: mach-armada: add headers
2012-05-15 8:54 ` [PATCH 1/8] arm: mach-armada: add headers Thomas Petazzoni
@ 2012-05-15 9:16 ` Ben Dooks
2012-05-15 10:57 ` Ben Dooks
2012-05-15 13:21 ` Rob Herring
2012-05-15 18:42 ` Nicolas Pitre
2 siblings, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 9:16 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 10:54:37AM +0200, Thomas Petazzoni wrote:
> From: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> This patch adds basic header files for Armada SoCs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Lior Amsalem <alior@marvell.com>
> ---
> arch/arm/mach-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
>
> diff --git a/arch/arm/mach-armada/include/mach/armada.h b/arch/arm/mach-armada/include/mach/armada.h
> new file mode 100644
> index 0000000..be12667
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/armada.h
> @@ -0,0 +1,234 @@
> +/*
> + * Generic definitions for Marvell Armada SoCs
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __MACH_ARMADA_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)
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.
> diff --git a/arch/arm/mach-armada/include/mach/bridge-regs.h b/arch/arm/mach-armada/include/mach/bridge-regs.h
> new file mode 100644
> index 0000000..0eaefbd
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/bridge-regs.h
> @@ -0,0 +1,28 @@
> +/*
> + * Mbus-L to Mbus Bridge Registers
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __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
> diff --git a/arch/arm/mach-armada/include/mach/debug-macro.S b/arch/arm/mach-armada/include/mach/debug-macro.S
> new file mode 100644
> index 0000000..1c7c52f
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/debug-macro.S
> @@ -0,0 +1,23 @@
> +/*
> + * Early serial output macro for Marvell Armada SoC
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include <mach/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.
> + .endm
> +
> +#define UART_SHIFT 2
> +#include <asm/hardware/debug-8250.S>
> diff --git a/arch/arm/mach-armada/include/mach/gpio.h b/arch/arm/mach-armada/include/mach/gpio.h
> new file mode 100644
> index 0000000..e62f38a
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/gpio.h
> @@ -0,0 +1,13 @@
> +/*
> + * Marvell Armada SoC GPIO definitions
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <plat/gpio.h>
> diff --git a/arch/arm/mach-armada/include/mach/hardware.h b/arch/arm/mach-armada/include/mach/hardware.h
> new file mode 100644
> index 0000000..829111b
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/hardware.h
> @@ -0,0 +1,18 @@
> +/*
> + * Marvell Armada SoC hardware definitions
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __ASM_ARCH_HARDWARE_H
> +#define __ASM_ARCH_HARDWARE_H
> +
> +#include <mach/armada.h>
> +
> +#endif
thought this was going away.
> diff --git a/arch/arm/mach-armada/include/mach/io.h b/arch/arm/mach-armada/include/mach/io.h
> new file mode 100644
> index 0000000..48716c1
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/io.h
> @@ -0,0 +1,24 @@
> +/*
> + * Basic I/O macros
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#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
> diff --git a/arch/arm/mach-armada/include/mach/irqs.h b/arch/arm/mach-armada/include/mach/irqs.h
> new file mode 100644
> index 0000000..48844a4
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/irqs.h
> @@ -0,0 +1,96 @@
> +/*
> + * IRQ definitions for Marvell Armada SoC
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#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
> +
> +/*
> + * 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.
> diff --git a/arch/arm/mach-armada/include/mach/system.h b/arch/arm/mach-armad
a/include/mach/system.h
> new file mode 100644
> index 0000000..f920ef0
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/system.h
> @@ -0,0 +1,21 @@
> +/*
> + * Marvell Armada SoC system defines
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __ASM_ARCH_SYSTEM_H
> +#define __ASM_ARCH_SYSTEM_H
> +
> +static inline void arch_idle(void)
> +{
> + cpu_do_idle();
> +}
> +
> +#endif
> diff --git a/arch/arm/mach-armada/include/mach/timex.h b/arch/arm/mach-armada/include/mach/timex.h
> new file mode 100644
> index 0000000..ab324a3
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/timex.h
> @@ -0,0 +1,13 @@
> +/*
> + * Marvell Armada SoC time definitions
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#define CLOCK_TICK_RATE (100 * HZ)
> diff --git a/arch/arm/mach-armada/include/mach/uncompress.h b/arch/arm/mach-armada/include/mach/uncompress.h
> new file mode 100644
> index 0000000..611ebf3
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/uncompress.h
> @@ -0,0 +1,41 @@
> +/*
> + * Marvell Armada SoC kernel uncompression UART routines
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <mach/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
> +#define LSR_THRE 0x20
you could pull the <linux/serial_regs.h> in for these.
> +
> +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?
> +
> + *UART_THR = c;
> +}
> +
> +static void flush(void)
> +{
> +}
> +
> +/*
> + * nothing to do
> + */
> +#define arch_decomp_setup()
> +#define arch_decomp_wdog()
> --
> 1.7.9.5
>
--
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 9:12 ` Andrew Lunn
@ 2012-05-15 9:17 ` Thomas Petazzoni
2012-05-15 9:54 ` Ben Dooks
2012-05-15 10:00 ` Arnaud Patard (Rtp)
0 siblings, 2 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 9:17 UTC (permalink / raw)
To: linux-arm-kernel
Hello Andrew,
Thanks for the quick feedback!
Le Tue, 15 May 2012 11:12:18 +0200,
Andrew Lunn <andrew@lunn.ch> a ?crit :
> > +/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.
> 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?
> 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
` (7 preceding siblings ...)
2012-05-15 8:54 ` [PATCH 8/8] arm: mach-armada: add entry to MAINTAINERS Thomas Petazzoni
@ 2012-05-15 9:18 ` Andrew Lunn
2012-05-15 9:44 ` Thomas Petazzoni
2012-05-15 9:51 ` Ben Dooks
2012-05-15 11:06 ` Arnd Bergmann
` (3 subsequent siblings)
12 siblings, 2 replies; 140+ messages in thread
From: Andrew Lunn @ 2012-05-15 9:18 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 10:54:36AM +0200, Thomas Petazzoni wrote:
> 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
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 8:54 ` [PATCH 2/8] arm: mach-armada: add source files Thomas Petazzoni
2012-05-15 9:12 ` Andrew Lunn
@ 2012-05-15 9:27 ` Andrew Lunn
2012-05-15 9:54 ` Ben Dooks
2012-05-15 9:46 ` Ben Dooks
` (2 subsequent siblings)
4 siblings, 1 reply; 140+ messages in thread
From: Andrew Lunn @ 2012-05-15 9:27 UTC (permalink / raw)
To: linux-arm-kernel
> diff --git a/arch/arm/mach-armada/irq.c b/arch/arm/mach-armada/irq.c
> new file mode 100644
> index 0000000..7006429
> --- /dev/null
> +++ b/arch/arm/mach-armada/irq.c
> @@ -0,0 +1,116 @@
> +/*
> + * Marvall Armada SoC IRQ handling
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * 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);
> +}
> +
> +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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 9:18 ` [PATCH] arm: Add basic support for new Marvell Armada SoC family Andrew Lunn
@ 2012-05-15 9:44 ` Thomas Petazzoni
2012-05-15 9:51 ` Ben Dooks
1 sibling, 0 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 9:44 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 11:18:38 +0200,
Andrew Lunn <andrew@lunn.ch> a ?crit :
> 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 8:54 ` [PATCH 2/8] arm: mach-armada: add source files Thomas Petazzoni
2012-05-15 9:12 ` Andrew Lunn
2012-05-15 9:27 ` Andrew Lunn
@ 2012-05-15 9:46 ` Ben Dooks
2012-05-15 9:59 ` Gregory CLEMENT
` (2 more replies)
2012-05-16 14:27 ` Ben Dooks
2012-05-16 15:06 ` Ben Dooks
4 siblings, 3 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 9:46 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 09:54, Thomas Petazzoni wrote:
> This patch adds basic source files for Marvell Armada SoCs.
>
> Signed-off-by: Gregory CLEMENT<gregory.clement@free-electrons.com>
> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> Signed-off-by: Lior Amsalem<alior@marvell.com>
> ---
> arch/arm/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
>
> diff --git a/arch/arm/boot/dts/a370.dtsi b/arch/arm/boot/dts/a370.dtsi
> new file mode 100644
> index 0000000..f11e56a
> --- /dev/null
> +++ b/arch/arm/boot/dts/a370.dtsi
> @@ -0,0 +1,23 @@
> +/*
> + * Device Tree Include file for Marvell Armada 370 family SoC
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem<alior@marvell.com>
> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * Contains definitions specific to the Armada 370 SoC that are not
> + * common to all Armada SoCs.
> + */
> +
> +/include/ "armada.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.
> +/ {
> + 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.
> diff --git a/arch/arm/boot/dts/armada.dtsi b/arch/arm/boot/dts/armada.dtsi
> new file mode 100644
> index 0000000..3c99c30
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada.dtsi
> @@ -0,0 +1,67 @@
> +/*
> + * Device Tree Include file for Marvell Armada family SoC
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem<alior@marvell.com>
> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * 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./
> + */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + model = "Marvell Armada family SoC";
> + 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" ?
> + #interrupt-cells =<1>;
> + #address-cells =<1>;
> + #size-cells =<1>;
> + interrupt-controller;
> + reg =<0xd0020000 0x1000>,
> + <0xd0021000 0x1000>;
> + };
> +
> + 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?
> + 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?
> + reg =<0xd0020300 0x30>;
> + interrupts =<37>,<38>,<39>,<40>;
> + };
> + };
> +};
> +
> diff --git a/arch/arm/boot/dts/axp.dtsi b/arch/arm/boot/dts/axp.dtsi
> new file mode 100644
> index 0000000..6427268
> --- /dev/null
[snip, pretty much the same comments here.
> diff --git a/arch/arm/mach-armada/Kconfig b/arch/arm/mach-armada/Kconfig
> new file mode 100644
> index 0000000..010a6a3
> --- /dev/null
> +++ b/arch/arm/mach-armada/Kconfig
> @@ -0,0 +1,5 @@
> +if ARCH_ARMADA
> +
> +menu "Marvell Armada Implementations"
> +
> +endif
> diff --git a/arch/arm/mach-armada/Makefile b/arch/arm/mach-armada/Makefile
> new file mode 100644
> index 0000000..6765961
> --- /dev/null
> +++ b/arch/arm/mach-armada/Makefile
> @@ -0,0 +1,2 @@
> +obj-y += common.o irq.o time.o
> +
> diff --git a/arch/arm/mach-armada/Makefile.boot b/arch/arm/mach-armada/Makefile.boot
> new file mode 100644
> index 0000000..b327175
> --- /dev/null
> +++ b/arch/arm/mach-armada/Makefile.boot
> @@ -0,0 +1 @@
> +zreladdr-y := 0x00008000
> diff --git a/arch/arm/mach-armada/common.c b/arch/arm/mach-armada/common.c
> new file mode 100644
> index 0000000..92d9ec2
> --- /dev/null
> +++ b/arch/arm/mach-armada/common.c
> @@ -0,0 +1,56 @@
> +/*
> + * Core functions for Marvell Armada System On Chip
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem<alior@marvell.com>
> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include<linux/kernel.h>
> +#include<linux/delay.h>
> +#include<linux/init.h>
> +#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?
> +
> +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)
> + ;
> +}
> diff --git a/arch/arm/mach-armada/common.h b/arch/arm/mach-armada/common.h
> new file mode 100644
> index 0000000..e453161
> --- /dev/null
> +++ b/arch/arm/mach-armada/common.h
> @@ -0,0 +1,27 @@
> +/*
> + * Core functions for Marvell Armada System On Chip
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem<alior@marvell.com>
> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __ARCH_ARMADA_COMMON_H
> +#define __ARCH_ARMADA_COMMON_H
> +
> +#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
> diff --git a/arch/arm/mach-armada/irq.c b/arch/arm/mach-armada/irq.c
> new file mode 100644
> index 0000000..7006429
> --- /dev/null
> +++ b/arch/arm/mach-armada/irq.c
> @@ -0,0 +1,116 @@
> +/*
> + * Marvall Armada SoC IRQ handling
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem<alior@marvell.com>
> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> + *
> + * 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)
MPIC_ since you indicated earlier that it is pretty generic.
> +
> +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,
> + 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.
> +}
> +
> +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.
> +
> + 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);
> + 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?
> +}
> +
> +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);
> +}
> diff --git a/arch/arm/mach-armada/time.c b/arch/arm/mach-armada/time.c
> new file mode 100644
> index 0000000..73817ea
> --- /dev/null
> +++ b/arch/arm/mach-armada/time.c
> @@ -0,0 +1,243 @@
> +/*
> + * Marvell Armada SoC timer handling.
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem<alior@marvell.com>
> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * Timer 0 is used as free-running clocksource, while timer 1 is
> + * used as clock_event_device.
> + */
> +
> +#include<linux/kernel.h>
> +#include<linux/timer.h>
> +#include<linux/clockchips.h>
> +#include<linux/interrupt.h>
> +#include<linux/of.h>
> +#include<linux/of_irq.h>
> +#include<linux/of_address.h>
> +#include<linux/irq.h>
> +#include<asm/sched_clock.h>
> +#include<asm/mach/time.h>
Style issue again.
> +
> +/*
> + * 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));
> + 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.
> +}
> +
> +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.
> + */
> + 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?
> +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);
> + 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]
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 9:18 ` [PATCH] arm: Add basic support for new Marvell Armada SoC family Andrew Lunn
2012-05-15 9:44 ` Thomas Petazzoni
@ 2012-05-15 9:51 ` Ben Dooks
2012-05-15 9:55 ` Thomas Petazzoni
1 sibling, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 9:51 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 10:18, Andrew Lunn wrote:
> On Tue, May 15, 2012 at 10:54:36AM +0200, Thomas Petazzoni wrote:
>> 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]
> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 9:27 ` Andrew Lunn
@ 2012-05-15 9:54 ` Ben Dooks
2012-05-15 12:46 ` Lior Amsalem
0 siblings, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 9:54 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 10:27, Andrew Lunn wrote:
>
>> diff --git a/arch/arm/mach-armada/irq.c b/arch/arm/mach-armada/irq.c
>> new file mode 100644
>> index 0000000..7006429
>> --- /dev/null
>> +++ b/arch/arm/mach-armada/irq.c
>> @@ -0,0 +1,116 @@
>> +/*
>> + * Marvall Armada SoC IRQ handling
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Lior Amsalem<alior@marvell.com>
>> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> + *
>> + * 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);
>> +}
>> +
>> +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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 9:17 ` Thomas Petazzoni
@ 2012-05-15 9:54 ` Ben Dooks
2012-05-15 10:00 ` Arnaud Patard (Rtp)
1 sibling, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 9:54 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 10:17, Thomas Petazzoni wrote:
> Hello Andrew,
>
> Thanks for the quick feedback!
>
> Le Tue, 15 May 2012 11:12:18 +0200,
> Andrew Lunn<andrew@lunn.ch> a ?crit :
>
>>> +/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.
>
>> 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?
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]
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 9:51 ` Ben Dooks
@ 2012-05-15 9:55 ` Thomas Petazzoni
2012-05-15 13:15 ` Andrew Lunn
2012-05-15 14:35 ` Rob Herring
0 siblings, 2 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 9:55 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 10:51:35 +0100,
Ben Dooks <ben.dooks@codethink.co.uk> a ?crit :
> >> 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 8:54 ` [PATCH 6/8] arm: mach-armada: add support for Armada XP " Thomas Petazzoni
@ 2012-05-15 9:58 ` Ben Dooks
2012-05-15 13:10 ` Lior Amsalem
2012-05-15 13:31 ` Rob Herring
0 siblings, 2 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 9:58 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 09:54, Thomas Petazzoni wrote:
> From: Gregory CLEMENT<gregory.clement@free-electrons.com>
>
> Signed-off-by: Gregory CLEMENT<gregory.clement@free-electrons.com>
> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> Signed-off-by: Lior Amsalem<alior@marvell.com>
> ---
> arch/arm/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
>
> diff --git a/arch/arm/boot/dts/axp-db.dts b/arch/arm/boot/dts/axp-db.dts
> new file mode 100644
> index 0000000..916be09
> --- /dev/null
> +++ b/arch/arm/boot/dts/axp-db.dts
see previous comments.
> diff --git a/arch/arm/mach-armada/Kconfig b/arch/arm/mach-armada/Kconfig
> index 7995813..2903096 100644
> --- a/arch/arm/mach-armada/Kconfig
> +++ b/arch/arm/mach-armada/Kconfig
> @@ -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
> diff --git a/arch/arm/mach-armada/Makefile b/arch/arm/mach-armada/Makefile
> index ac39fae..7a3c438 100644
> --- a/arch/arm/mach-armada/Makefile
> +++ b/arch/arm/mach-armada/Makefile
> @@ -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
> diff --git a/arch/arm/mach-armada/axp-dt.c b/arch/arm/mach-armada/axp-dt.c
> new file mode 100644
> index 0000000..2c13d4e
> --- /dev/null
> +++ b/arch/arm/mach-armada/axp-dt.c
> @@ -0,0 +1,41 @@
> +/*
> + * Device Tree support for Armada XP platforms.
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem<alior@marvell.com>
> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include<linux/kernel.h>
> +#include<linux/init.h>
> +#include<linux/of_platform.h>
> +#include<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);
> +}
> +
> +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?
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 7/8] arm: mach-armada: add defconfig
2012-05-15 8:54 ` [PATCH 7/8] arm: mach-armada: add defconfig Thomas Petazzoni
@ 2012-05-15 9:58 ` Ben Dooks
2012-05-15 12:54 ` Thomas Petazzoni
0 siblings, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 9:58 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 09:54, Thomas Petazzoni wrote:
> From: Gregory CLEMENT<gregory.clement@free-electrons.com>
>
> Signed-off-by: Gregory CLEMENT<gregory.clement@free-electrons.com>
> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> Signed-off-by: Lior Amsalem<alior@marvell.com>
> ---
> arch/arm/configs/armada_defconfig | 47 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 arch/arm/configs/armada_defconfig
>
> diff --git a/arch/arm/configs/armada_defconfig b/arch/arm/configs/armada_defconfig
> new file mode 100644
personally, I'd go for armadaxp_defconfig.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 9:46 ` Ben Dooks
@ 2012-05-15 9:59 ` Gregory CLEMENT
2012-05-15 10:03 ` Andrew Lunn
2012-05-19 6:21 ` Grant Likely
2 siblings, 0 replies; 140+ messages in thread
From: Gregory CLEMENT @ 2012-05-15 9:59 UTC (permalink / raw)
To: linux-arm-kernel
On 05/15/2012 11:46 AM, Ben Dooks wrote:
> On 15/05/12 09:54, Thomas Petazzoni wrote:
>> This patch adds basic source files for Marvell Armada SoCs.
>>
>> Signed-off-by: Gregory CLEMENT<gregory.clement@free-electrons.com>
>> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> Signed-off-by: Lior Amsalem<alior@marvell.com>
>> ---
>> arch/arm/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
>>
>> diff --git a/arch/arm/boot/dts/a370.dtsi b/arch/arm/boot/dts/a370.dtsi
>> new file mode 100644
>> index 0000000..f11e56a
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/a370.dtsi
>> @@ -0,0 +1,23 @@
>> +/*
>> + * Device Tree Include file for Marvell Armada 370 family SoC
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Lior Amsalem<alior@marvell.com>
>> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + *
>> + * Contains definitions specific to the Armada 370 SoC that are not
>> + * common to all Armada SoCs.
>> + */
>> +
>> +/include/ "armada.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.
>
>> +/ {
>> + 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.
>
>> diff --git a/arch/arm/boot/dts/armada.dtsi b/arch/arm/boot/dts/armada.dtsi
>> new file mode 100644
>> index 0000000..3c99c30
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/armada.dtsi
>> @@ -0,0 +1,67 @@
>> +/*
>> + * Device Tree Include file for Marvell Armada family SoC
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Lior Amsalem<alior@marvell.com>
>> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + *
>> + * 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./
>
>> + */
>> +
>> +/include/ "skeleton.dtsi"
>> +
>> +/ {
>> + model = "Marvell Armada family SoC";
>> + 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" ?
>
>> + #interrupt-cells =<1>;
>> + #address-cells =<1>;
>> + #size-cells =<1>;
>> + interrupt-controller;
>> + reg =<0xd0020000 0x1000>,
>> + <0xd0021000 0x1000>;
>> + };
>> +
>> + 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?
>
>> + 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?
>
>> + reg =<0xd0020300 0x30>;
>> + interrupts =<37>,<38>,<39>,<40>;
>> + };
>> + };
>> +};
>> +
>> diff --git a/arch/arm/boot/dts/axp.dtsi b/arch/arm/boot/dts/axp.dtsi
>> new file mode 100644
>> index 0000000..6427268
>> --- /dev/null
>
> [snip, pretty much the same comments here.
>
>> diff --git a/arch/arm/mach-armada/Kconfig b/arch/arm/mach-armada/Kconfig
>> new file mode 100644
>> index 0000000..010a6a3
>> --- /dev/null
>> +++ b/arch/arm/mach-armada/Kconfig
>> @@ -0,0 +1,5 @@
>> +if ARCH_ARMADA
>> +
>> +menu "Marvell Armada Implementations"
>> +
>> +endif
>> diff --git a/arch/arm/mach-armada/Makefile b/arch/arm/mach-armada/Makefile
>> new file mode 100644
>> index 0000000..6765961
>> --- /dev/null
>> +++ b/arch/arm/mach-armada/Makefile
>> @@ -0,0 +1,2 @@
>> +obj-y += common.o irq.o time.o
>> +
>> diff --git a/arch/arm/mach-armada/Makefile.boot b/arch/arm/mach-armada/Makefile.boot
>> new file mode 100644
>> index 0000000..b327175
>> --- /dev/null
>> +++ b/arch/arm/mach-armada/Makefile.boot
>> @@ -0,0 +1 @@
>> +zreladdr-y := 0x00008000
>> diff --git a/arch/arm/mach-armada/common.c b/arch/arm/mach-armada/common.c
>> new file mode 100644
>> index 0000000..92d9ec2
>> --- /dev/null
>> +++ b/arch/arm/mach-armada/common.c
>> @@ -0,0 +1,56 @@
>> +/*
>> + * Core functions for Marvell Armada System On Chip
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Lior Amsalem<alior@marvell.com>
>> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#include<linux/kernel.h>
>> +#include<linux/delay.h>
>> +#include<linux/init.h>
>> +#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?
>
>> +
>> +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)
>> + ;
>> +}
>> diff --git a/arch/arm/mach-armada/common.h b/arch/arm/mach-armada/common.h
>> new file mode 100644
>> index 0000000..e453161
>> --- /dev/null
>> +++ b/arch/arm/mach-armada/common.h
>> @@ -0,0 +1,27 @@
>> +/*
>> + * Core functions for Marvell Armada System On Chip
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Lior Amsalem<alior@marvell.com>
>> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#ifndef __ARCH_ARMADA_COMMON_H
>> +#define __ARCH_ARMADA_COMMON_H
>> +
>> +#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
>> diff --git a/arch/arm/mach-armada/irq.c b/arch/arm/mach-armada/irq.c
>> new file mode 100644
>> index 0000000..7006429
>> --- /dev/null
>> +++ b/arch/arm/mach-armada/irq.c
>> @@ -0,0 +1,116 @@
>> +/*
>> + * Marvall Armada SoC IRQ handling
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Lior Amsalem<alior@marvell.com>
>> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> + *
>> + * 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)
>
> MPIC_ since you indicated earlier that it is pretty generic.
>
>> +
>> +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,
>> + 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.
>
>> +}
>> +
>> +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.
>
>> +
>> + 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);
>> + 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?
>
>> +}
>> +
>> +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);
>> +}
>> diff --git a/arch/arm/mach-armada/time.c b/arch/arm/mach-armada/time.c
>> new file mode 100644
>> index 0000000..73817ea
>> --- /dev/null
>> +++ b/arch/arm/mach-armada/time.c
>> @@ -0,0 +1,243 @@
>> +/*
>> + * Marvell Armada SoC timer handling.
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Lior Amsalem<alior@marvell.com>
>> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + *
>> + * Timer 0 is used as free-running clocksource, while timer 1 is
>> + * used as clock_event_device.
>> + */
>> +
>> +#include<linux/kernel.h>
>> +#include<linux/timer.h>
>> +#include<linux/clockchips.h>
>> +#include<linux/interrupt.h>
>> +#include<linux/of.h>
>> +#include<linux/of_irq.h>
>> +#include<linux/of_address.h>
>> +#include<linux/irq.h>
>> +#include<asm/sched_clock.h>
>> +#include<asm/mach/time.h>
>
> Style issue again.
>
>> +
>> +/*
>> + * 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));
>> + 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
>
>> +}
>> +
>> +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.
>> + */
>> + 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?
>
>> +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);
>> + 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.
> [snip]
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 9:17 ` Thomas Petazzoni
2012-05-15 9:54 ` Ben Dooks
@ 2012-05-15 10:00 ` Arnaud Patard (Rtp)
2012-05-15 10:37 ` Ben Dooks
1 sibling, 1 reply; 140+ messages in thread
From: Arnaud Patard (Rtp) @ 2012-05-15 10:00 UTC (permalink / raw)
To: linux-arm-kernel
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
> Hello Andrew,
>
> Thanks for the quick feedback!
>
> Le Tue, 15 May 2012 11:12:18 +0200,
> Andrew Lunn <andrew@lunn.ch> a ?crit :
>
>> > +/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.
>
>> 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?
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 9:46 ` Ben Dooks
2012-05-15 9:59 ` Gregory CLEMENT
@ 2012-05-15 10:03 ` Andrew Lunn
2012-05-19 6:21 ` Grant Likely
2 siblings, 0 replies; 140+ messages in thread
From: Andrew Lunn @ 2012-05-15 10:03 UTC (permalink / raw)
To: linux-arm-kernel
> >+ 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 10:00 ` Arnaud Patard (Rtp)
@ 2012-05-15 10:37 ` Ben Dooks
0 siblings, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 10:37 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 11:00, Arnaud Patard (Rtp) wrote:
> Thomas Petazzoni<thomas.petazzoni@free-electrons.com> writes:
>
> Hi,
>> Hello Andrew,
>>
>> Thanks for the quick feedback!
>>
>> Le Tue, 15 May 2012 11:12:18 +0200,
>> Andrew Lunn<andrew@lunn.ch> a ?crit :
>>
>>>> +/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.
>>
>>> 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?
>
> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 1/8] arm: mach-armada: add headers
2012-05-15 9:16 ` Ben Dooks
@ 2012-05-15 10:57 ` Ben Dooks
0 siblings, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 10:57 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 10:16, Ben Dooks wrote:
> On Tue, May 15, 2012 at 10:54:37AM +0200, Thomas Petazzoni wrote:
>> From: Gregory CLEMENT<gregory.clement@free-electrons.com>
>>
>> This patch adds basic header files for Armada SoCs.
>>
>> Signed-off-by: Gregory CLEMENT<gregory.clement@free-electrons.com>
>> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> Signed-off-by: Lior Amsalem<alior@marvell.com>
>> ---
>> arch/arm/mach-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
>>
>> diff --git a/arch/arm/mach-armada/include/mach/armada.h b/arch/arm/mach-armada/include/mach/armada.h
>> new file mode 100644
>> index 0000000..be12667
>> --- /dev/null
>> +++ b/arch/arm/mach-armada/include/mach/armada.h
>> @@ -0,0 +1,234 @@
>> +/*
>> + * Generic definitions for Marvell Armada SoCs
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Lior Amsalem<alior@marvell.com>
>> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#ifndef __MACH_ARMADA_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
>> + */
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?
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
` (8 preceding siblings ...)
2012-05-15 9:18 ` [PATCH] arm: Add basic support for new Marvell Armada SoC family Andrew Lunn
@ 2012-05-15 11:06 ` Arnd Bergmann
2012-05-15 12:50 ` Thomas Petazzoni
2012-05-15 16:03 ` Ben Dooks
2012-05-15 11:18 ` Ben Dooks
` (2 subsequent siblings)
12 siblings, 2 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-15 11:06 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 15 May 2012, Thomas Petazzoni wrote:
> 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:
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
` (9 preceding siblings ...)
2012-05-15 11:06 ` Arnd Bergmann
@ 2012-05-15 11:18 ` Ben Dooks
2012-05-15 12:26 ` Lior Amsalem
2012-05-15 12:51 ` Thomas Petazzoni
2012-05-15 11:20 ` Ben Dooks
2012-05-15 14:55 ` Ben Dooks
12 siblings, 2 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 11:18 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 09:54, Thomas Petazzoni wrote:
> 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.
Is there a git tree that can be pulled from?
> 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.
> * 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
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
` (10 preceding siblings ...)
2012-05-15 11:18 ` Ben Dooks
@ 2012-05-15 11:20 ` Ben Dooks
2012-05-15 12:29 ` Lior Amsalem
2012-05-15 14:55 ` Ben Dooks
12 siblings, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 11:20 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 09:54, Thomas Petazzoni wrote:
> 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?
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 3/8] arm: mach-armada: add documentation for new device tree bindings
2012-05-15 8:54 ` [PATCH 3/8] arm: mach-armada: add documentation for new device tree bindings Thomas Petazzoni
@ 2012-05-15 11:31 ` Ben Dooks
0 siblings, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 11:31 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 09:54, Thomas Petazzoni wrote:
> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> Signed-off-by: Gregory CLEMENT<gregory.clement@free-electrons.com>
> ---
> .../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
>
> diff --git a/Documentation/devicetree/bindings/arm/armada-mpic.txt b/Documentation/devicetree/bindings/arm/armada-mpic.txt
> new file mode 100644
> index 0000000..3571f44
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/armada-mpic.txt
> @@ -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'?
> +- 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.
> diff --git a/Documentation/devicetree/bindings/arm/armada-timer.txt b/Documentation/devicetree/bindings/arm/armada-timer.txt
> new file mode 100644
> index 0000000..6bed565
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/armada-timer.txt
> @@ -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.
> +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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 11:18 ` Ben Dooks
@ 2012-05-15 12:26 ` Lior Amsalem
2012-05-15 12:51 ` Thomas Petazzoni
1 sibling, 0 replies; 140+ messages in thread
From: Lior Amsalem @ 2012-05-15 12:26 UTC (permalink / raw)
To: linux-arm-kernel
> -----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]
> >
> > 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
>
> > 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.
> >
> > Best regards,
> >
> > Thomas Petazzoni
>
>
> --
> Ben Dooks http://www.codethink.co.uk/
> Senior Engineer Codethink - Providing Genius
Lior Amsalem
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 11:20 ` Ben Dooks
@ 2012-05-15 12:29 ` Lior Amsalem
0 siblings, 0 replies; 140+ messages in thread
From: Lior Amsalem @ 2012-05-15 12:29 UTC (permalink / raw)
To: linux-arm-kernel
> -----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
>
> On 15/05/12 09:54, Thomas Petazzoni wrote:
> > 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?
Work in progress. As well as SMP support.
>
> --
> Ben Dooks http://www.codethink.co.uk/
> Senior Engineer Codethink - Providing Genius
Lior Amsalem
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 9:54 ` Ben Dooks
@ 2012-05-15 12:46 ` Lior Amsalem
0 siblings, 0 replies; 140+ messages in thread
From: Lior Amsalem @ 2012-05-15 12:46 UTC (permalink / raw)
To: linux-arm-kernel
> -----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
>
> On 15/05/12 10:27, Andrew Lunn wrote:
> >
> >> diff --git a/arch/arm/mach-armada/irq.c b/arch/arm/mach-armada/irq.c
> >> new file mode 100644 index 0000000..7006429
> >> --- /dev/null
> >> +++ b/arch/arm/mach-armada/irq.c
> >> @@ -0,0 +1,116 @@
> >> +/*
> >> + * Marvall Armada SoC IRQ handling
> >> + *
> >> + * Copyright (C) 2012 Marvell
> >> + *
> >> + * Lior Amsalem<alior@marvell.com>
> >> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> >> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> >> + *
> >> + * 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); }
> >> +
> >> +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.
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.
>
> --
> Ben Dooks http://www.codethink.co.uk/
> Senior Engineer Codethink - Providing Genius
Lior Amsalem
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 11:06 ` Arnd Bergmann
@ 2012-05-15 12:50 ` Thomas Petazzoni
2012-05-15 16:03 ` Ben Dooks
1 sibling, 0 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 12:50 UTC (permalink / raw)
To: linux-arm-kernel
Hello Arnd,
Le Tue, 15 May 2012 11:06:46 +0000,
Arnd Bergmann <arnd@arndb.de> a ?crit :
> 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.
>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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 11:18 ` Ben Dooks
2012-05-15 12:26 ` Lior Amsalem
@ 2012-05-15 12:51 ` Thomas Petazzoni
1 sibling, 0 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 12:51 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 12:18:55 +0100,
Ben Dooks <ben.dooks@codethink.co.uk> a ?crit :
> > 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.
> > 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 7/8] arm: mach-armada: add defconfig
2012-05-15 9:58 ` Ben Dooks
@ 2012-05-15 12:54 ` Thomas Petazzoni
0 siblings, 0 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 12:54 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 10:58:39 +0100,
Ben Dooks <ben.dooks@codethink.co.uk> a ?crit :
> > diff --git a/arch/arm/configs/armada_defconfig
> > 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 9:58 ` Ben Dooks
@ 2012-05-15 13:10 ` Lior Amsalem
2012-05-15 13:19 ` Andrew Lunn
2012-05-15 13:33 ` Ben Dooks
2012-05-15 13:31 ` Rob Herring
1 sibling, 2 replies; 140+ messages in thread
From: Lior Amsalem @ 2012-05-15 13:10 UTC (permalink / raw)
To: linux-arm-kernel
> -----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
>
> On 15/05/12 09:54, Thomas Petazzoni wrote:
> > From: Gregory CLEMENT<gregory.clement@free-electrons.com>
> >
> > Signed-off-by: Gregory CLEMENT<gregory.clement@free-electrons.com>
> > Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> > Signed-off-by: Lior Amsalem<alior@marvell.com>
> > ---
> > arch/arm/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
> >
> > diff --git a/arch/arm/boot/dts/axp-db.dts
> > b/arch/arm/boot/dts/axp-db.dts new file mode 100644 index
> > 0000000..916be09
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/axp-db.dts
>
> see previous comments.
>
> > diff --git a/arch/arm/mach-armada/Kconfig
> > b/arch/arm/mach-armada/Kconfig index 7995813..2903096 100644
> > --- a/arch/arm/mach-armada/Kconfig
> > +++ b/arch/arm/mach-armada/Kconfig
> > @@ -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
> > diff --git a/arch/arm/mach-armada/Makefile
> > b/arch/arm/mach-armada/Makefile index ac39fae..7a3c438 100644
> > --- a/arch/arm/mach-armada/Makefile
> > +++ b/arch/arm/mach-armada/Makefile
> > @@ -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
> > diff --git a/arch/arm/mach-armada/axp-dt.c
> > b/arch/arm/mach-armada/axp-dt.c new file mode 100644 index
> > 0000000..2c13d4e
> > --- /dev/null
> > +++ b/arch/arm/mach-armada/axp-dt.c
> > @@ -0,0 +1,41 @@
> > +/*
> > + * Device Tree support for Armada XP platforms.
> > + *
> > + * Copyright (C) 2012 Marvell
> > + *
> > + * Lior Amsalem<alior@marvell.com>
> > + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> > + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> > + *
> > + * This file is licensed under the terms of the GNU General Public
> > + * License version 2. This program is licensed "as is" without any
> > + * warranty of any kind, whether express or implied.
> > + */
> > +
> > +#include<linux/kernel.h>
> > +#include<linux/init.h>
> > +#include<linux/of_platform.h>
> > +#include<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);
> > +}
> > +
> > +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?
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.
>
> --
> Ben Dooks http://www.codethink.co.uk/
> Senior Engineer Codethink - Providing Genius
Lior Amsalem
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 9:55 ` Thomas Petazzoni
@ 2012-05-15 13:15 ` Andrew Lunn
2012-05-15 14:35 ` Rob Herring
1 sibling, 0 replies; 140+ messages in thread
From: Andrew Lunn @ 2012-05-15 13:15 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 11:55:11AM +0200, Thomas Petazzoni wrote:
> Le Tue, 15 May 2012 10:51:35 +0100,
> Ben Dooks <ben.dooks@codethink.co.uk> a ??crit :
>
> > >> 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.
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 13:10 ` Lior Amsalem
@ 2012-05-15 13:19 ` Andrew Lunn
2012-05-15 14:23 ` Arnd Bergmann
2012-05-15 13:33 ` Ben Dooks
1 sibling, 1 reply; 140+ messages in thread
From: Andrew Lunn @ 2012-05-15 13:19 UTC (permalink / raw)
To: linux-arm-kernel
> > 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 1/8] arm: mach-armada: add headers
2012-05-15 8:54 ` [PATCH 1/8] arm: mach-armada: add headers Thomas Petazzoni
2012-05-15 9:16 ` Ben Dooks
@ 2012-05-15 13:21 ` Rob Herring
2012-05-15 18:42 ` Nicolas Pitre
2 siblings, 0 replies; 140+ messages in thread
From: Rob Herring @ 2012-05-15 13:21 UTC (permalink / raw)
To: linux-arm-kernel
On 05/15/2012 03:54 AM, Thomas Petazzoni wrote:
> From: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> This patch adds basic header files for Armada SoCs.
The split of patch 1 and 2 doesn't really make sense.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Lior Amsalem <alior@marvell.com>
> ---
> arch/arm/mach-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
>
> diff --git a/arch/arm/mach-armada/include/mach/armada.h b/arch/arm/mach-armada/include/mach/armada.h
> new file mode 100644
> index 0000000..be12667
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/armada.h
> @@ -0,0 +1,234 @@
> +/*
> + * Generic definitions for Marvell Armada SoCs
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __MACH_ARMADA_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)
> +
As Ben pointed out, all this should come from DT.
> +#endif /* __MACH_ARMADA_H */
> diff --git a/arch/arm/mach-armada/include/mach/bridge-regs.h b/arch/arm/mach-armada/include/mach/bridge-regs.h
> new file mode 100644
> index 0000000..0eaefbd
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/bridge-regs.h
> @@ -0,0 +1,28 @@
> +/*
> + * Mbus-L to Mbus Bridge Registers
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __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
> diff --git a/arch/arm/mach-armada/include/mach/debug-macro.S b/arch/arm/mach-armada/include/mach/debug-macro.S
> new file mode 100644
> index 0000000..1c7c52f
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/debug-macro.S
> @@ -0,0 +1,23 @@
> +/*
> + * Early serial output macro for Marvell Armada SoC
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include <mach/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>
> diff --git a/arch/arm/mach-armada/include/mach/gpio.h b/arch/arm/mach-armada/include/mach/gpio.h
> new file mode 100644
> index 0000000..e62f38a
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/gpio.h
> @@ -0,0 +1,13 @@
> +/*
> + * Marvell Armada SoC GPIO definitions
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <plat/gpio.h>
New platforms should probably have empty gpio.h.
> diff --git a/arch/arm/mach-armada/include/mach/hardware.h b/arch/arm/mach-armada/include/mach/hardware.h
> new file mode 100644
> index 0000000..829111b
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/hardware.h
You should not have a hardware.h. Include armada.h directly or ideally
remove the need for it.
> @@ -0,0 +1,18 @@
> +/*
> + * Marvell Armada SoC hardware definitions
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __ASM_ARCH_HARDWARE_H
> +#define __ASM_ARCH_HARDWARE_H
> +
> +#include <mach/armada.h>
> +
> +#endif
> diff --git a/arch/arm/mach-armada/include/mach/io.h b/arch/arm/mach-armada/include/mach/io.h
> new file mode 100644
> index 0000000..48716c1
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/io.h
> @@ -0,0 +1,24 @@
> +/*
> + * Basic I/O macros
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#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.
> +
> +#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.
> +#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).
> +
> +#endif
> diff --git a/arch/arm/mach-armada/include/mach/irqs.h b/arch/arm/mach-armada/include/mach/irqs.h
> new file mode 100644
> index 0000000..48844a4
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/irqs.h
> @@ -0,0 +1,96 @@
> +/*
> + * IRQ definitions for Marvell Armada SoC
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#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
> +
> +/*
> + * 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.
> +
> +#endif
> diff --git a/arch/arm/mach-armada/include/mach/system.h b/arch/arm/mach-armada/include/mach/system.h
> new file mode 100644
> index 0000000..f920ef0
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/system.h
This header is gone now. You don't need anything if you just use the
default cpu_do_idle.
> @@ -0,0 +1,21 @@
> +/*
> + * Marvell Armada SoC system defines
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __ASM_ARCH_SYSTEM_H
> +#define __ASM_ARCH_SYSTEM_H
> +
> +static inline void arch_idle(void)
> +{
> + cpu_do_idle();
> +}
> +
> +#endif
> diff --git a/arch/arm/mach-armada/include/mach/timex.h b/arch/arm/mach-armada/include/mach/timex.h
> new file mode 100644
> index 0000000..ab324a3
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/timex.h
> @@ -0,0 +1,13 @@
> +/*
> + * Marvell Armada SoC time definitions
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#define CLOCK_TICK_RATE (100 * HZ)
> diff --git a/arch/arm/mach-armada/include/mach/uncompress.h b/arch/arm/mach-armada/include/mach/uncompress.h
> new file mode 100644
> index 0000000..611ebf3
> --- /dev/null
> +++ b/arch/arm/mach-armada/include/mach/uncompress.h
> @@ -0,0 +1,41 @@
> +/*
> + * Marvell Armada SoC kernel uncompression UART routines
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <mach/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()
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 9:58 ` Ben Dooks
2012-05-15 13:10 ` Lior Amsalem
@ 2012-05-15 13:31 ` Rob Herring
2012-05-15 13:53 ` Ben Dooks
2012-05-17 23:35 ` Jason Cooper
1 sibling, 2 replies; 140+ messages in thread
From: Rob Herring @ 2012-05-15 13:31 UTC (permalink / raw)
To: linux-arm-kernel
On 05/15/2012 04:58 AM, Ben Dooks wrote:
> On 15/05/12 09:54, Thomas Petazzoni wrote:
>> From: Gregory CLEMENT<gregory.clement@free-electrons.com>
>>
>> Signed-off-by: Gregory CLEMENT<gregory.clement@free-electrons.com>
>> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> Signed-off-by: Lior Amsalem<alior@marvell.com>
>> ---
>> arch/arm/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
>>
>> diff --git a/arch/arm/boot/dts/axp-db.dts b/arch/arm/boot/dts/axp-db.dts
>> new file mode 100644
>> index 0000000..916be09
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/axp-db.dts
>
> see previous comments.
>
>> diff --git a/arch/arm/mach-armada/Kconfig b/arch/arm/mach-armada/Kconfig
>> index 7995813..2903096 100644
>> --- a/arch/arm/mach-armada/Kconfig
>> +++ b/arch/arm/mach-armada/Kconfig
>> @@ -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
>> diff --git a/arch/arm/mach-armada/Makefile
>> b/arch/arm/mach-armada/Makefile
>> index ac39fae..7a3c438 100644
>> --- a/arch/arm/mach-armada/Makefile
>> +++ b/arch/arm/mach-armada/Makefile
>> @@ -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
>> diff --git a/arch/arm/mach-armada/axp-dt.c
>> b/arch/arm/mach-armada/axp-dt.c
>> new file mode 100644
>> index 0000000..2c13d4e
>> --- /dev/null
>> +++ b/arch/arm/mach-armada/axp-dt.c
>> @@ -0,0 +1,41 @@
>> +/*
>> + * Device Tree support for Armada XP platforms.
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Lior Amsalem<alior@marvell.com>
>> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
>> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#include<linux/kernel.h>
>> +#include<linux/init.h>
>> +#include<linux/of_platform.h>
>> +#include<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);
>> +}
>> +
>> +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.
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.
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 13:10 ` Lior Amsalem
2012-05-15 13:19 ` Andrew Lunn
@ 2012-05-15 13:33 ` Ben Dooks
1 sibling, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 13:33 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 14:10, Lior Amsalem wrote:
>>> +}
>>> +
>>> +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?
> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 13:31 ` Rob Herring
@ 2012-05-15 13:53 ` Ben Dooks
2012-05-15 14:16 ` Thomas Petazzoni
2012-05-17 23:35 ` Jason Cooper
1 sibling, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 13:53 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 14:31, Rob Herring wrote:
> On 05/15/2012 04:58 AM, Ben Dooks wrote:
>> On 15/05/12 09:54, Thomas Petazzoni wrote:
>>> From: Gregory CLEMENT<gregory.clement@free-electrons.com>
>>>
>>> Signed-off-by: Gregory CLEMENT<gregory.clement@free-electrons.com>
>>> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>>> Signed-off-by: Lior Amsalem<alior@marvell.com>
>>> ---
>>> arch/arm/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
>>>
>>> diff --git a/arch/arm/boot/dts/axp-db.dts b/arch/arm/boot/dts/axp-db.dts
>>> new file mode 100644
>>> index 0000000..916be09
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/axp-db.dts
>>
>> see previous comments.
>>
>>> diff --git a/arch/arm/mach-armada/Kconfig b/arch/arm/mach-armada/Kconfig
>>> index 7995813..2903096 100644
>>> --- a/arch/arm/mach-armada/Kconfig
>>> +++ b/arch/arm/mach-armada/Kconfig
>>> @@ -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
>>> diff --git a/arch/arm/mach-armada/Makefile
>>> b/arch/arm/mach-armada/Makefile
>>> index ac39fae..7a3c438 100644
>>> --- a/arch/arm/mach-armada/Makefile
>>> +++ b/arch/arm/mach-armada/Makefile
>>> @@ -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
>>> diff --git a/arch/arm/mach-armada/axp-dt.c
>>> b/arch/arm/mach-armada/axp-dt.c
>>> new file mode 100644
>>> index 0000000..2c13d4e
>>> --- /dev/null
>>> +++ b/arch/arm/mach-armada/axp-dt.c
>>> @@ -0,0 +1,41 @@
>>> +/*
>>> + * Device Tree support for Armada XP platforms.
>>> + *
>>> + * Copyright (C) 2012 Marvell
>>> + *
>>> + * Lior Amsalem<alior@marvell.com>
>>> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
>>> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>>> + *
>>> + * This file is licensed under the terms of the GNU General Public
>>> + * License version 2. This program is licensed "as is" without any
>>> + * warranty of any kind, whether express or implied.
>>> + */
>>> +
>>> +#include<linux/kernel.h>
>>> +#include<linux/init.h>
>>> +#include<linux/of_platform.h>
>>> +#include<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);
>>> +}
>>> +
>>> +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.
>
> 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
>> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 13:53 ` Ben Dooks
@ 2012-05-15 14:16 ` Thomas Petazzoni
2012-05-15 14:25 ` Arnd Bergmann
2012-05-15 14:32 ` Ben Dooks
0 siblings, 2 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 14:16 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks <ben.dooks@codethink.co.uk> a ?crit :
> 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 13:19 ` Andrew Lunn
@ 2012-05-15 14:23 ` Arnd Bergmann
2012-05-15 18:37 ` Nicolas Pitre
2012-05-17 23:31 ` Jason Cooper
0 siblings, 2 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-15 14:23 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 15 May 2012, Andrew Lunn wrote:
> > > 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.
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:16 ` Thomas Petazzoni
@ 2012-05-15 14:25 ` Arnd Bergmann
2012-05-15 14:29 ` Thomas Petazzoni
` (2 more replies)
2012-05-15 14:32 ` Ben Dooks
1 sibling, 3 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-15 14:25 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 15 May 2012, Thomas Petazzoni wrote:
> Le Tue, 15 May 2012 14:53:45 +0100,
> Ben Dooks <ben.dooks@codethink.co.uk> a ?crit :
>
> > 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)
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:25 ` Arnd Bergmann
@ 2012-05-15 14:29 ` Thomas Petazzoni
2012-05-15 14:35 ` Ben Dooks
2012-05-15 14:53 ` Rob Herring
2 siblings, 0 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 14:29 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 14:25:30 +0000,
Arnd Bergmann <arnd@arndb.de> a ?crit :
> 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:16 ` Thomas Petazzoni
2012-05-15 14:25 ` Arnd Bergmann
@ 2012-05-15 14:32 ` Ben Dooks
2012-05-15 14:37 ` Arnd Bergmann
2012-05-15 14:58 ` Thomas Petazzoni
1 sibling, 2 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 14:32 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 15:16, Thomas Petazzoni wrote:
> Le Tue, 15 May 2012 14:53:45 +0100,
> Ben Dooks<ben.dooks@codethink.co.uk> a ?crit :
>
>> 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.
> * 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.
> * 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'll rework this for our v2.
Great.
> Thanks for the comments!
I'll get to testing this kernel soon, and report back
> Thomas
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:25 ` Arnd Bergmann
2012-05-15 14:29 ` Thomas Petazzoni
@ 2012-05-15 14:35 ` Ben Dooks
2012-05-15 14:53 ` Rob Herring
2 siblings, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 14:35 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 15:25, Arnd Bergmann wrote:
> On Tuesday 15 May 2012, Thomas Petazzoni wrote:
>> Le Tue, 15 May 2012 14:53:45 +0100,
>> Ben Dooks<ben.dooks@codethink.co.uk> a ?crit :
>>
>>> 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)
>
> 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()
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 9:55 ` Thomas Petazzoni
2012-05-15 13:15 ` Andrew Lunn
@ 2012-05-15 14:35 ` Rob Herring
2012-05-15 14:44 ` Thomas Petazzoni
1 sibling, 1 reply; 140+ messages in thread
From: Rob Herring @ 2012-05-15 14:35 UTC (permalink / raw)
To: linux-arm-kernel
On 05/15/2012 04:55 AM, Thomas Petazzoni wrote:
> Le Tue, 15 May 2012 10:51:35 +0100,
> Ben Dooks <ben.dooks@codethink.co.uk> a ?crit :
>
>>>> 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.
>
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:32 ` Ben Dooks
@ 2012-05-15 14:37 ` Arnd Bergmann
2012-05-15 16:31 ` Stephen Warren
2012-05-15 14:58 ` Thomas Petazzoni
1 sibling, 1 reply; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-15 14:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 15 May 2012, Ben Dooks wrote:
> > * 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.
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 14:35 ` Rob Herring
@ 2012-05-15 14:44 ` Thomas Petazzoni
2012-05-15 15:27 ` Arnd Bergmann
` (2 more replies)
0 siblings, 3 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 14:44 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 09:35:55 -0500,
Rob Herring <robherring2@gmail.com> a ?crit :
> 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.
> 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:25 ` Arnd Bergmann
2012-05-15 14:29 ` Thomas Petazzoni
2012-05-15 14:35 ` Ben Dooks
@ 2012-05-15 14:53 ` Rob Herring
2012-05-15 15:01 ` Ben Dooks
2 siblings, 1 reply; 140+ messages in thread
From: Rob Herring @ 2012-05-15 14:53 UTC (permalink / raw)
To: linux-arm-kernel
On 05/15/2012 09:25 AM, Arnd Bergmann wrote:
> On Tuesday 15 May 2012, Thomas Petazzoni wrote:
>> Le Tue, 15 May 2012 14:53:45 +0100,
>> Ben Dooks <ben.dooks@codethink.co.uk> a ?crit :
>>
>>> 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)
>
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
` (11 preceding siblings ...)
2012-05-15 11:20 ` Ben Dooks
@ 2012-05-15 14:55 ` Ben Dooks
2012-05-15 15:00 ` Thomas Petazzoni
12 siblings, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 14:55 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 09:54, Thomas Petazzoni wrote:
> 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:
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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:32 ` Ben Dooks
2012-05-15 14:37 ` Arnd Bergmann
@ 2012-05-15 14:58 ` Thomas Petazzoni
2012-05-15 15:07 ` Ben Dooks
1 sibling, 1 reply; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 14:58 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 15:32:36 +0100,
Ben Dooks <ben.dooks@codethink.co.uk> a ?crit :
> 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.
>
> > * 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.
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?
> > * 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.
> > Thanks for the comments!
>
> I'll get to testing this kernel soon, and report back
Excellent, thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 14:55 ` Ben Dooks
@ 2012-05-15 15:00 ` Thomas Petazzoni
2012-05-15 15:07 ` Ben Dooks
2012-05-15 15:36 ` Ben Dooks
0 siblings, 2 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 15:00 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 15:55:07 +0100,
Ben Dooks <ben.dooks@codethink.co.uk> a ?crit :
> > 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.
> 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:53 ` Rob Herring
@ 2012-05-15 15:01 ` Ben Dooks
2012-05-15 15:30 ` Russell King - ARM Linux
0 siblings, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 15:01 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 15:53, Rob Herring wrote:
> On 05/15/2012 09:25 AM, Arnd Bergmann wrote:
>> On Tuesday 15 May 2012, Thomas Petazzoni wrote:
>>> Le Tue, 15 May 2012 14:53:45 +0100,
>>> Ben Dooks<ben.dooks@codethink.co.uk> a ?crit :
>>>
>>>> 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)
>>
>> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 15:00 ` Thomas Petazzoni
@ 2012-05-15 15:07 ` Ben Dooks
2012-05-15 15:36 ` Ben Dooks
1 sibling, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 15:07 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 16:00, Thomas Petazzoni wrote:
> Le Tue, 15 May 2012 15:55:07 +0100,
> Ben Dooks<ben.dooks@codethink.co.uk> a ?crit :
>
>>> 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?
Cogent CS1726, using MV78460 (A0)
> 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.
>
>> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:58 ` Thomas Petazzoni
@ 2012-05-15 15:07 ` Ben Dooks
2012-05-15 15:32 ` Arnd Bergmann
2012-05-15 15:41 ` Russell King - ARM Linux
0 siblings, 2 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 15:07 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 15:58, Thomas Petazzoni wrote:
> Le Tue, 15 May 2012 15:32:36 +0100,
> Ben Dooks<ben.dooks@codethink.co.uk> a ?crit :
>
>> 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.
>>
>>> * 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.
>
> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 14:44 ` Thomas Petazzoni
@ 2012-05-15 15:27 ` Arnd Bergmann
2012-05-15 15:39 ` Thomas Petazzoni
2012-05-15 18:20 ` Nicolas Pitre
2012-05-15 16:22 ` Andrew Lunn
2012-05-16 11:12 ` Lior Amsalem
2 siblings, 2 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-15 15:27 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 15 May 2012, Thomas Petazzoni wrote:
> 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.
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 15:01 ` Ben Dooks
@ 2012-05-15 15:30 ` Russell King - ARM Linux
0 siblings, 0 replies; 140+ messages in thread
From: Russell King - ARM Linux @ 2012-05-15 15:30 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 04:01:22PM +0100, Ben Dooks wrote:
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 15:07 ` Ben Dooks
@ 2012-05-15 15:32 ` Arnd Bergmann
2012-05-15 15:46 ` Thomas Petazzoni
2012-05-15 15:49 ` Ben Dooks
2012-05-15 15:41 ` Russell King - ARM Linux
1 sibling, 2 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-15 15:32 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 15 May 2012, Ben Dooks wrote:
> >
> > 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 15:00 ` Thomas Petazzoni
2012-05-15 15:07 ` Ben Dooks
@ 2012-05-15 15:36 ` Ben Dooks
2012-05-15 15:39 ` Thomas Petazzoni
1 sibling, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 15:36 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 16:00, Thomas Petazzoni wrote:
> Le Tue, 15 May 2012 15:55:07 +0100,
> Ben Dooks<ben.dooks@codethink.co.uk> a ?crit :
>
>>> 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 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 15:27 ` Arnd Bergmann
@ 2012-05-15 15:39 ` Thomas Petazzoni
2012-05-15 16:26 ` Arnd Bergmann
2012-05-15 18:20 ` Nicolas Pitre
1 sibling, 1 reply; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 15:39 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 15:27:00 +0000,
Arnd Bergmann <arnd@arndb.de> a ?crit :
> 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.
> 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 15:36 ` Ben Dooks
@ 2012-05-15 15:39 ` Thomas Petazzoni
0 siblings, 0 replies; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 15:39 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 16:36:03 +0100,
Ben Dooks <ben.dooks@codethink.co.uk> a ?crit :
> 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.
Thanks for your report and investigation, you're obviously correct.
We'll fix that.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 15:07 ` Ben Dooks
2012-05-15 15:32 ` Arnd Bergmann
@ 2012-05-15 15:41 ` Russell King - ARM Linux
2012-05-15 15:59 ` Ben Dooks
1 sibling, 1 reply; 140+ messages in thread
From: Russell King - ARM Linux @ 2012-05-15 15:41 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 04:07:59PM +0100, Ben Dooks wrote:
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 15:32 ` Arnd Bergmann
@ 2012-05-15 15:46 ` Thomas Petazzoni
2012-05-15 21:22 ` Rob Herring
2012-05-15 15:49 ` Ben Dooks
1 sibling, 1 reply; 140+ messages in thread
From: Thomas Petazzoni @ 2012-05-15 15:46 UTC (permalink / raw)
To: linux-arm-kernel
Le Tue, 15 May 2012 15:32:20 +0000,
Arnd Bergmann <arnd@arndb.de> a ?crit :
> > > 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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 15:32 ` Arnd Bergmann
2012-05-15 15:46 ` Thomas Petazzoni
@ 2012-05-15 15:49 ` Ben Dooks
2012-05-15 19:06 ` Arnd Bergmann
1 sibling, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 15:49 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 16:32, Arnd Bergmann wrote:
> On Tuesday 15 May 2012, Ben Dooks wrote:
>>>
>>> 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.
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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 15:41 ` Russell King - ARM Linux
@ 2012-05-15 15:59 ` Ben Dooks
2012-05-15 16:03 ` Russell King - ARM Linux
0 siblings, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 15:59 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 16:41, Russell King - ARM Linux wrote:
> On Tue, May 15, 2012 at 04:07:59PM +0100, Ben Dooks wrote:
>> 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?
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 11:06 ` Arnd Bergmann
2012-05-15 12:50 ` Thomas Petazzoni
@ 2012-05-15 16:03 ` Ben Dooks
1 sibling, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 16:03 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 12:06, Arnd Bergmann wrote:
> On Tuesday 15 May 2012, Thomas Petazzoni wrote:
>> 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:
>
> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 15:59 ` Ben Dooks
@ 2012-05-15 16:03 ` Russell King - ARM Linux
0 siblings, 0 replies; 140+ messages in thread
From: Russell King - ARM Linux @ 2012-05-15 16:03 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 04:59:08PM +0100, Ben Dooks wrote:
> On 15/05/12 16:41, Russell King - ARM Linux wrote:
>> On Tue, May 15, 2012 at 04:07:59PM +0100, Ben Dooks wrote:
>>> 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?
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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 14:44 ` Thomas Petazzoni
2012-05-15 15:27 ` Arnd Bergmann
@ 2012-05-15 16:22 ` Andrew Lunn
2012-05-15 16:25 ` Ben Dooks
2012-05-16 11:12 ` Lior Amsalem
2 siblings, 1 reply; 140+ messages in thread
From: Andrew Lunn @ 2012-05-15 16:22 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 04:44:38PM +0200, Thomas Petazzoni wrote:
> Le Tue, 15 May 2012 09:35:55 -0500,
> Rob Herring <robherring2@gmail.com> a ??crit :
>
> > 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 16:22 ` Andrew Lunn
@ 2012-05-15 16:25 ` Ben Dooks
2012-05-15 16:30 ` Andrew Lunn
0 siblings, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 16:25 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 17:22, Andrew Lunn wrote:
> On Tue, May 15, 2012 at 04:44:38PM +0200, Thomas Petazzoni wrote:
>> Le Tue, 15 May 2012 09:35:55 -0500,
>> Rob Herring<robherring2@gmail.com> a ??crit :
>>
>>> 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?
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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 15:39 ` Thomas Petazzoni
@ 2012-05-15 16:26 ` Arnd Bergmann
2012-05-15 21:35 ` Arnd Bergmann
0 siblings, 1 reply; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-15 16:26 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 15 May 2012, Thomas Petazzoni wrote:
> > 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 16:25 ` Ben Dooks
@ 2012-05-15 16:30 ` Andrew Lunn
2012-05-15 16:37 ` Ben Dooks
0 siblings, 1 reply; 140+ messages in thread
From: Andrew Lunn @ 2012-05-15 16:30 UTC (permalink / raw)
To: linux-arm-kernel
> >>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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:37 ` Arnd Bergmann
@ 2012-05-15 16:31 ` Stephen Warren
2012-05-15 19:41 ` Arnd Bergmann
0 siblings, 1 reply; 140+ messages in thread
From: Stephen Warren @ 2012-05-15 16:31 UTC (permalink / raw)
To: linux-arm-kernel
On 05/15/2012 08:37 AM, Arnd Bergmann wrote:
> On Tuesday 15 May 2012, Ben Dooks wrote:
>>> * 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.
>
>> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 16:30 ` Andrew Lunn
@ 2012-05-15 16:37 ` Ben Dooks
0 siblings, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-15 16:37 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 17:30, Andrew Lunn wrote:
>>>> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 15:27 ` Arnd Bergmann
2012-05-15 15:39 ` Thomas Petazzoni
@ 2012-05-15 18:20 ` Nicolas Pitre
1 sibling, 0 replies; 140+ messages in thread
From: Nicolas Pitre @ 2012-05-15 18:20 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 15 May 2012, Arnd Bergmann wrote:
> On Tuesday 15 May 2012, Thomas Petazzoni wrote:
> > 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.
>
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:23 ` Arnd Bergmann
@ 2012-05-15 18:37 ` Nicolas Pitre
2012-05-17 23:31 ` Jason Cooper
1 sibling, 0 replies; 140+ messages in thread
From: Nicolas Pitre @ 2012-05-15 18:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 15 May 2012, Arnd Bergmann wrote:
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 1/8] arm: mach-armada: add headers
2012-05-15 8:54 ` [PATCH 1/8] arm: mach-armada: add headers Thomas Petazzoni
2012-05-15 9:16 ` Ben Dooks
2012-05-15 13:21 ` Rob Herring
@ 2012-05-15 18:42 ` Nicolas Pitre
2 siblings, 0 replies; 140+ messages in thread
From: Nicolas Pitre @ 2012-05-15 18:42 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 15 May 2012, Thomas Petazzoni wrote:
> From: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 15:49 ` Ben Dooks
@ 2012-05-15 19:06 ` Arnd Bergmann
0 siblings, 0 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-15 19:06 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 15 May 2012, Ben Dooks wrote:
> 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.
> With PCIe, there should be less old-style IO as PCIe devices are
> encouraged to go 32bit MMIO.
It should work nonetheless.
arnd
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 16:31 ` Stephen Warren
@ 2012-05-15 19:41 ` Arnd Bergmann
0 siblings, 0 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-15 19:41 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 15 May 2012, Stephen Warren wrote:
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 15:46 ` Thomas Petazzoni
@ 2012-05-15 21:22 ` Rob Herring
0 siblings, 0 replies; 140+ messages in thread
From: Rob Herring @ 2012-05-15 21:22 UTC (permalink / raw)
To: linux-arm-kernel
On 05/15/2012 10:46 AM, Thomas Petazzoni wrote:
> Le Tue, 15 May 2012 15:32:20 +0000,
> Arnd Bergmann <arnd@arndb.de> a ?crit :
>
>>>> 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.
>
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 16:26 ` Arnd Bergmann
@ 2012-05-15 21:35 ` Arnd Bergmann
2012-05-16 0:25 ` Nicolas Pitre
` (3 more replies)
0 siblings, 4 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-15 21:35 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 15 May 2012, Arnd Bergmann wrote:
> 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.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 852b12b..196dfbf 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -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"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index b3eb01a..ec55498 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -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
diff --git a/arch/arm/mach-dove/Makefile.boot b/arch/arm/mach-dove/Makefile.boot
deleted file mode 100644
index 760a0ef..0000000
--- a/arch/arm/mach-dove/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
- zreladdr-y += 0x00008000
-params_phys-y := 0x00000100
-initrd_phys-y := 0x00800000
diff --git a/arch/arm/mach-dove/include/mach/gpio.h b/arch/arm/mach-dove/include/mach/gpio.h
deleted file mode 100644
index e7e5101..0000000
--- a/arch/arm/mach-dove/include/mach/gpio.h
+++ /dev/null
@@ -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>
diff --git a/arch/arm/mach-dove/include/mach/hardware.h b/arch/arm/mach-dove/include/mach/hardware.h
deleted file mode 100644
index f1368b9..0000000
--- a/arch/arm/mach-dove/include/mach/hardware.h
+++ /dev/null
@@ -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
diff --git a/arch/arm/mach-kirkwood/include/mach/gpio.h b/arch/arm/mach-kirkwood/include/mach/gpio.h
deleted file mode 100644
index 84f340b..0000000
--- a/arch/arm/mach-kirkwood/include/mach/gpio.h
+++ /dev/null
@@ -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>
diff --git a/arch/arm/mach-kirkwood/include/mach/hardware.h b/arch/arm/mach-kirkwood/include/mach/hardware.h
deleted file mode 100644
index 742b74f..0000000
--- a/arch/arm/mach-kirkwood/include/mach/hardware.h
+++ /dev/null
@@ -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
diff --git a/arch/arm/mach-kirkwood/include/mach/timex.h b/arch/arm/mach-kirkwood/include/mach/timex.h
deleted file mode 100644
index c923cd1..0000000
--- a/arch/arm/mach-kirkwood/include/mach/timex.h
+++ /dev/null
@@ -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)
-
diff --git a/arch/arm/mach-mv78xx0/Makefile.boot b/arch/arm/mach-mv78xx0/Makefile.boot
deleted file mode 100644
index 760a0ef..0000000
--- a/arch/arm/mach-mv78xx0/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
- zreladdr-y += 0x00008000
-params_phys-y := 0x00000100
-initrd_phys-y := 0x00800000
diff --git a/arch/arm/mach-mv78xx0/include/mach/gpio.h b/arch/arm/mach-mv78xx0/include/mach/gpio.h
deleted file mode 100644
index 77e1b84..0000000
--- a/arch/arm/mach-mv78xx0/include/mach/gpio.h
+++ /dev/null
@@ -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>
diff --git a/arch/arm/mach-mv78xx0/include/mach/hardware.h b/arch/arm/mach-mv78xx0/include/mach/hardware.h
deleted file mode 100644
index 67cab0a..0000000
--- a/arch/arm/mach-mv78xx0/include/mach/hardware.h
+++ /dev/null
@@ -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
diff --git a/arch/arm/mach-mv78xx0/include/mach/timex.h b/arch/arm/mach-mv78xx0/include/mach/timex.h
deleted file mode 100644
index 0e8c443..0000000
--- a/arch/arm/mach-mv78xx0/include/mach/timex.h
+++ /dev/null
@@ -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)
diff --git a/arch/arm/mach-orion/Kconfig b/arch/arm/mach-orion/Kconfig
new file mode 100644
index 0000000..769908f
--- /dev/null
+++ b/arch/arm/mach-orion/Kconfig
@@ -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"
diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-orion/Kconfig.dove
similarity index 100%
rename from arch/arm/mach-dove/Kconfig
rename to arch/arm/mach-orion/Kconfig.dove
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-orion/Kconfig.kirkwood
similarity index 100%
rename from arch/arm/mach-kirkwood/Kconfig
rename to arch/arm/mach-orion/Kconfig.kirkwood
diff --git a/arch/arm/mach-mv78xx0/Kconfig b/arch/arm/mach-orion/Kconfig.mv78xx0
similarity index 100%
rename from arch/arm/mach-mv78xx0/Kconfig
rename to arch/arm/mach-orion/Kconfig.mv78xx0
diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion/Kconfig.orion5x
similarity index 100%
rename from arch/arm/mach-orion5x/Kconfig
rename to arch/arm/mach-orion/Kconfig.orion5x
diff --git a/arch/arm/mach-orion/Makefile b/arch/arm/mach-orion/Makefile
new file mode 100644
index 0000000..d91869d
--- /dev/null
+++ b/arch/arm/mach-orion/Makefile
@@ -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
diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-orion/Makefile.boot
similarity index 100%
rename from arch/arm/mach-kirkwood/Makefile.boot
rename to arch/arm/mach-orion/Makefile.boot
diff --git a/arch/arm/mach-dove/Makefile b/arch/arm/mach-orion/Makefile.dove
similarity index 55%
rename from arch/arm/mach-dove/Makefile
rename to arch/arm/mach-orion/Makefile.dove
index fa0f018..0625023 100644
--- a/arch/arm/mach-dove/Makefile
+++ b/arch/arm/mach-orion/Makefile.dove
@@ -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
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-orion/Makefile.kirkwood
similarity index 93%
rename from arch/arm/mach-kirkwood/Makefile
rename to arch/arm/mach-orion/Makefile.kirkwood
index d2b0590..223d581 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-orion/Makefile.kirkwood
@@ -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
diff --git a/arch/arm/mach-mv78xx0/Makefile b/arch/arm/mach-orion/Makefile.mv78xx0
similarity index 66%
rename from arch/arm/mach-mv78xx0/Makefile
rename to arch/arm/mach-orion/Makefile.mv78xx0
index 67a13f9..29032eb 100644
--- a/arch/arm/mach-mv78xx0/Makefile
+++ b/arch/arm/mach-orion/Makefile.mv78xx0
@@ -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
diff --git a/arch/arm/mach-orion5x/Makefile b/arch/arm/mach-orion/Makefile.orion5x
similarity index 93%
rename from arch/arm/mach-orion5x/Makefile
rename to arch/arm/mach-orion/Makefile.orion5x
index 7f18cda..7eb9c7b 100644
--- a/arch/arm/mach-orion5x/Makefile
+++ b/arch/arm/mach-orion/Makefile.orion5x
@@ -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
diff --git a/arch/arm/mach-dove/addr-map.c b/arch/arm/mach-orion/addr-map-dove.c
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
--- a/arch/arm/mach-dove/addr-map.c
+++ b/arch/arm/mach-orion/addr-map-dove.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/addr-map.c b/arch/arm/mach-orion/addr-map-kirkwood.c
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
--- a/arch/arm/mach-kirkwood/addr-map.c
+++ b/arch/arm/mach-orion/addr-map-kirkwood.c
@@ -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
diff --git a/arch/arm/mach-mv78xx0/addr-map.c b/arch/arm/mach-orion/addr-map-mv78xx0.c
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
--- a/arch/arm/mach-mv78xx0/addr-map.c
+++ b/arch/arm/mach-orion/addr-map-mv78xx0.c
@@ -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
diff --git a/arch/arm/mach-orion5x/addr-map.c b/arch/arm/mach-orion/addr-map-orion5x.c
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
--- a/arch/arm/mach-orion5x/addr-map.c
+++ b/arch/arm/mach-orion/addr-map-orion5x.c
@@ -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
diff --git a/arch/arm/plat-orion/addr-map.c b/arch/arm/mach-orion/addr-map.c
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
--- a/arch/arm/plat-orion/addr-map.c
+++ b/arch/arm/mach-orion/addr-map.c
@@ -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;
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c b/arch/arm/mach-orion/board-dnskw.c
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
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-orion/board-dnskw.c
@@ -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),
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-orion/board-dreamplug.c
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
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ b/arch/arm/mach-orion/board-dreamplug.c
@@ -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[] = {
{
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-orion/board-dt.c
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
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-orion/board-dt.c
@@ -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", },
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-orion/board-ib62x0.c
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
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ b/arch/arm/mach-orion/board-ib62x0.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/board-iconnect.c b/arch/arm/mach-orion/board-iconnect.c
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
--- a/arch/arm/mach-kirkwood/board-iconnect.c
+++ b/arch/arm/mach-orion/board-iconnect.c
@@ -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),
diff --git a/arch/arm/mach-mv78xx0/buffalo-wxl-setup.c b/arch/arm/mach-orion/buffalo-wxl-setup.c
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
--- a/arch/arm/mach-mv78xx0/buffalo-wxl-setup.c
+++ b/arch/arm/mach-orion/buffalo-wxl-setup.c
@@ -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 */
diff --git a/arch/arm/mach-dove/cm-a510.c b/arch/arm/mach-orion/cm-a510.c
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
--- a/arch/arm/mach-dove/cm-a510.c
+++ b/arch/arm/mach-orion/cm-a510.c
@@ -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,
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/mach-orion/common.c
similarity index 99%
rename from arch/arm/plat-orion/common.c
rename to arch/arm/mach-orion/common.c
index 74daf5e..90afe40 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/mach-orion/common.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/cpuidle.c b/arch/arm/mach-orion/cpuidle.c
similarity index 100%
rename from arch/arm/mach-kirkwood/cpuidle.c
rename to arch/arm/mach-orion/cpuidle.c
diff --git a/arch/arm/mach-orion5x/d2net-setup.c b/arch/arm/mach-orion/d2net-setup.c
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
--- a/arch/arm/mach-orion5x/d2net-setup.c
+++ b/arch/arm/mach-orion/d2net-setup.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/d2net_v2-setup.c b/arch/arm/mach-orion/d2net_v2-setup.c
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
--- a/arch/arm/mach-kirkwood/d2net_v2-setup.c
+++ b/arch/arm/mach-orion/d2net_v2-setup.c
@@ -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"
/*****************************************************************************
diff --git a/arch/arm/mach-mv78xx0/db78x00-bp-setup.c b/arch/arm/mach-orion/db78x00-bp-setup.c
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
--- a/arch/arm/mach-mv78xx0/db78x00-bp-setup.c
+++ b/arch/arm/mach-orion/db78x00-bp-setup.c
@@ -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),
diff --git a/arch/arm/mach-orion5x/db88f5281-setup.c b/arch/arm/mach-orion/db88f5281-setup.c
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
--- a/arch/arm/mach-orion5x/db88f5281-setup.c
+++ b/arch/arm/mach-orion/db88f5281-setup.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/db88f6281-bp-setup.c b/arch/arm/mach-orion/db88f6281-bp-setup.c
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
--- a/arch/arm/mach-kirkwood/db88f6281-bp-setup.c
+++ b/arch/arm/mach-orion/db88f6281-bp-setup.c
@@ -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[] = {
{
diff --git a/arch/arm/mach-orion5x/dns323-setup.c b/arch/arm/mach-orion/dns323-setup.c
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
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion/dns323-setup.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/dockstar-setup.c b/arch/arm/mach-orion/dockstar-setup.c
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
--- a/arch/arm/mach-kirkwood/dockstar-setup.c
+++ b/arch/arm/mach-orion/dockstar-setup.c
@@ -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[] = {
{
diff --git a/arch/arm/mach-dove/dove-db-setup.c b/arch/arm/mach-orion/dove-db-setup.c
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
--- a/arch/arm/mach-dove/dove-db-setup.c
+++ b/arch/arm/mach-orion/dove-db-setup.c
@@ -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,
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-orion/dove.c
similarity index 98%
rename from arch/arm/mach-dove/common.c
rename to arch/arm/mach-orion/dove.c
index 42ab1e7..e008c60 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-orion/dove.c
@@ -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);
diff --git a/arch/arm/mach-dove/common.h b/arch/arm/mach-orion/dove.h
similarity index 100%
rename from arch/arm/mach-dove/common.h
rename to arch/arm/mach-orion/dove.h
diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c b/arch/arm/mach-orion/edmini_v2-setup.c
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
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion/edmini_v2-setup.c
@@ -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
diff --git a/arch/arm/plat-orion/gpio.c b/arch/arm/mach-orion/gpio.c
similarity index 100%
rename from arch/arm/plat-orion/gpio.c
rename to arch/arm/mach-orion/gpio.c
diff --git a/arch/arm/mach-kirkwood/guruplug-setup.c b/arch/arm/mach-orion/guruplug-setup.c
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
--- a/arch/arm/mach-kirkwood/guruplug-setup.c
+++ b/arch/arm/mach-orion/guruplug-setup.c
@@ -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[] = {
{
diff --git a/arch/arm/plat-orion/include/plat/addr-map.h b/arch/arm/mach-orion/include/mach/addr-map.h
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
diff --git a/arch/arm/plat-orion/include/plat/audio.h b/arch/arm/mach-orion/include/mach/audio.h
similarity index 100%
rename from arch/arm/plat-orion/include/plat/audio.h
rename to arch/arm/mach-orion/include/mach/audio.h
diff --git a/arch/arm/mach-dove/include/mach/bridge-regs.h b/arch/arm/mach-orion/include/mach/bridge-regs-dove.h
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
diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h b/arch/arm/mach-orion/include/mach/bridge-regs-kirkwood.h
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
diff --git a/arch/arm/mach-mv78xx0/include/mach/bridge-regs.h b/arch/arm/mach-orion/include/mach/bridge-regs-mv78xx0.h
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
diff --git a/arch/arm/mach-orion5x/include/mach/bridge-regs.h b/arch/arm/mach-orion/include/mach/bridge-regs-orion5x.h
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
diff --git a/arch/arm/mach-orion/include/mach/bridge-regs.h b/arch/arm/mach-orion/include/mach/bridge-regs.h
new file mode 100644
index 0000000..29cfc01
--- /dev/null
+++ b/arch/arm/mach-orion/include/mach/bridge-regs.h
@@ -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
diff --git a/arch/arm/plat-orion/include/plat/cache-feroceon-l2.h b/arch/arm/mach-orion/include/mach/cache-feroceon-l2.h
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
diff --git a/arch/arm/plat-orion/include/plat/common.h b/arch/arm/mach-orion/include/mach/common.h
similarity index 100%
rename from arch/arm/plat-orion/include/plat/common.h
rename to arch/arm/mach-orion/include/mach/common.h
diff --git a/arch/arm/mach-dove/include/mach/debug-macro.S b/arch/arm/mach-orion/include/mach/debug-macro-dove.S
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
diff --git a/arch/arm/mach-kirkwood/include/mach/debug-macro.S b/arch/arm/mach-orion/include/mach/debug-macro-kirkwood.S
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
diff --git a/arch/arm/mach-mv78xx0/include/mach/debug-macro.S b/arch/arm/mach-orion/include/mach/debug-macro-mv78xx0.S
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
diff --git a/arch/arm/mach-orion5x/include/mach/debug-macro.S b/arch/arm/mach-orion/include/mach/debug-macro-orion5x.S
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
diff --git a/arch/arm/mach-orion/include/mach/debug-macro.S b/arch/arm/mach-orion/include/mach/debug-macro.S
new file mode 100644
index 0000000..9f1118e
--- /dev/null
+++ b/arch/arm/mach-orion/include/mach/debug-macro.S
@@ -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
diff --git a/arch/arm/mach-dove/include/mach/dove.h b/arch/arm/mach-orion/include/mach/dove.h
similarity index 100%
rename from arch/arm/mach-dove/include/mach/dove.h
rename to arch/arm/mach-orion/include/mach/dove.h
diff --git a/arch/arm/plat-orion/include/plat/ehci-orion.h b/arch/arm/mach-orion/include/mach/ehci-orion.h
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
diff --git a/arch/arm/mach-dove/include/mach/entry-macro.S b/arch/arm/mach-orion/include/mach/entry-macro-dove.S
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
diff --git a/arch/arm/mach-kirkwood/include/mach/entry-macro.S b/arch/arm/mach-orion/include/mach/entry-macro-kirkwood.S
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
diff --git a/arch/arm/mach-mv78xx0/include/mach/entry-macro.S b/arch/arm/mach-orion/include/mach/entry-macro-mv78xx0.S
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
diff --git a/arch/arm/mach-orion5x/include/mach/entry-macro.S b/arch/arm/mach-orion/include/mach/entry-macro-orion5x.S
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
diff --git a/arch/arm/mach-orion/include/mach/entry-macro.S b/arch/arm/mach-orion/include/mach/entry-macro.S
new file mode 100644
index 0000000..c30bac5
--- /dev/null
+++ b/arch/arm/mach-orion/include/mach/entry-macro.S
@@ -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
diff --git a/arch/arm/plat-orion/include/plat/gpio.h b/arch/arm/mach-orion/include/mach/gpio.h
similarity index 100%
rename from arch/arm/plat-orion/include/plat/gpio.h
rename to arch/arm/mach-orion/include/mach/gpio.h
diff --git a/arch/arm/mach-orion/include/mach/hardware.h b/arch/arm/mach-orion/include/mach/hardware.h
new file mode 100644
index 0000000..c3eb636
--- /dev/null
+++ b/arch/arm/mach-orion/include/mach/hardware.h
@@ -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
diff --git a/arch/arm/mach-dove/include/mach/io.h b/arch/arm/mach-orion/include/mach/io-dove.h
similarity index 100%
rename from arch/arm/mach-dove/include/mach/io.h
rename to arch/arm/mach-orion/include/mach/io-dove.h
diff --git a/arch/arm/mach-kirkwood/include/mach/io.h b/arch/arm/mach-orion/include/mach/io-kirkwood.h
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/io.h
rename to arch/arm/mach-orion/include/mach/io-kirkwood.h
diff --git a/arch/arm/mach-mv78xx0/include/mach/io.h b/arch/arm/mach-orion/include/mach/io-mv78xx0.h
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/io.h
rename to arch/arm/mach-orion/include/mach/io-mv78xx0.h
diff --git a/arch/arm/mach-orion/include/mach/io.h b/arch/arm/mach-orion/include/mach/io.h
new file mode 100644
index 0000000..044956d
--- /dev/null
+++ b/arch/arm/mach-orion/include/mach/io.h
@@ -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
diff --git a/arch/arm/plat-orion/include/plat/irq.h b/arch/arm/mach-orion/include/mach/irq.h
similarity index 100%
rename from arch/arm/plat-orion/include/plat/irq.h
rename to arch/arm/mach-orion/include/mach/irq.h
diff --git a/arch/arm/mach-dove/include/mach/irqs.h b/arch/arm/mach-orion/include/mach/irqs-dove.h
similarity index 100%
rename from arch/arm/mach-dove/include/mach/irqs.h
rename to arch/arm/mach-orion/include/mach/irqs-dove.h
diff --git a/arch/arm/mach-kirkwood/include/mach/irqs.h b/arch/arm/mach-orion/include/mach/irqs-kirkwood.h
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/irqs.h
rename to arch/arm/mach-orion/include/mach/irqs-kirkwood.h
diff --git a/arch/arm/mach-mv78xx0/include/mach/irqs.h b/arch/arm/mach-orion/include/mach/irqs-mv78xx0.h
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/irqs.h
rename to arch/arm/mach-orion/include/mach/irqs-mv78xx0.h
diff --git a/arch/arm/mach-orion5x/include/mach/irqs.h b/arch/arm/mach-orion/include/mach/irqs-orion5x.h
similarity index 100%
rename from arch/arm/mach-orion5x/include/mach/irqs.h
rename to arch/arm/mach-orion/include/mach/irqs-orion5x.h
diff --git a/arch/arm/mach-orion/include/mach/irqs.h b/arch/arm/mach-orion/include/mach/irqs.h
new file mode 100644
index 0000000..2f06667
--- /dev/null
+++ b/arch/arm/mach-orion/include/mach/irqs.h
@@ -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
diff --git a/arch/arm/mach-kirkwood/include/mach/kirkwood.h b/arch/arm/mach-orion/include/mach/kirkwood.h
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/kirkwood.h
rename to arch/arm/mach-orion/include/mach/kirkwood.h
diff --git a/arch/arm/mach-kirkwood/include/mach/leds-netxbig.h b/arch/arm/mach-orion/include/mach/leds-netxbig.h
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
diff --git a/arch/arm/mach-kirkwood/include/mach/leds-ns2.h b/arch/arm/mach-orion/include/mach/leds-ns2.h
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
diff --git a/arch/arm/plat-orion/include/plat/mpp.h b/arch/arm/mach-orion/include/mach/mpp.h
similarity index 100%
rename from arch/arm/plat-orion/include/plat/mpp.h
rename to arch/arm/mach-orion/include/mach/mpp.h
diff --git a/arch/arm/mach-mv78xx0/include/mach/mv78xx0.h b/arch/arm/mach-orion/include/mach/mv78xx0.h
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/mv78xx0.h
rename to arch/arm/mach-orion/include/mach/mv78xx0.h
diff --git a/arch/arm/plat-orion/include/plat/mv_xor.h b/arch/arm/mach-orion/include/mach/mv_xor.h
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
diff --git a/arch/arm/plat-orion/include/plat/mvsdio.h b/arch/arm/mach-orion/include/mach/mvsdio.h
similarity index 100%
rename from arch/arm/plat-orion/include/plat/mvsdio.h
rename to arch/arm/mach-orion/include/mach/mvsdio.h
diff --git a/arch/arm/mach-orion5x/include/mach/orion5x.h b/arch/arm/mach-orion/include/mach/orion5x.h
similarity index 100%
rename from arch/arm/mach-orion5x/include/mach/orion5x.h
rename to arch/arm/mach-orion/include/mach/orion5x.h
diff --git a/arch/arm/plat-orion/include/plat/orion_nand.h b/arch/arm/mach-orion/include/mach/orion_nand.h
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
diff --git a/arch/arm/plat-orion/include/plat/orion_wdt.h b/arch/arm/mach-orion/include/mach/orion_wdt.h
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
diff --git a/arch/arm/plat-orion/include/plat/pcie.h b/arch/arm/mach-orion/include/mach/pcie.h
similarity index 100%
rename from arch/arm/plat-orion/include/plat/pcie.h
rename to arch/arm/mach-orion/include/mach/pcie.h
diff --git a/arch/arm/mach-dove/include/mach/pm.h b/arch/arm/mach-orion/include/mach/pm.h
similarity index 100%
rename from arch/arm/mach-dove/include/mach/pm.h
rename to arch/arm/mach-orion/include/mach/pm.h
diff --git a/arch/arm/plat-orion/include/plat/time.h b/arch/arm/mach-orion/include/mach/time.h
similarity index 100%
rename from arch/arm/plat-orion/include/plat/time.h
rename to arch/arm/mach-orion/include/mach/time.h
diff --git a/arch/arm/mach-dove/include/mach/timex.h b/arch/arm/mach-orion/include/mach/timex.h
similarity index 100%
rename from arch/arm/mach-dove/include/mach/timex.h
rename to arch/arm/mach-orion/include/mach/timex.h
diff --git a/arch/arm/mach-dove/include/mach/uncompress.h b/arch/arm/mach-orion/include/mach/uncompress-dove.h
similarity index 100%
rename from arch/arm/mach-dove/include/mach/uncompress.h
rename to arch/arm/mach-orion/include/mach/uncompress-dove.h
diff --git a/arch/arm/mach-kirkwood/include/mach/uncompress.h b/arch/arm/mach-orion/include/mach/uncompress-kirkwood.h
similarity index 100%
rename from arch/arm/mach-kirkwood/include/mach/uncompress.h
rename to arch/arm/mach-orion/include/mach/uncompress-kirkwood.h
diff --git a/arch/arm/mach-mv78xx0/include/mach/uncompress.h b/arch/arm/mach-orion/include/mach/uncompress-mv78xx0.h
similarity index 100%
rename from arch/arm/mach-mv78xx0/include/mach/uncompress.h
rename to arch/arm/mach-orion/include/mach/uncompress-mv78xx0.h
diff --git a/arch/arm/mach-orion5x/include/mach/uncompress.h b/arch/arm/mach-orion/include/mach/uncompress-orion5x.h
similarity index 100%
rename from arch/arm/mach-orion5x/include/mach/uncompress.h
rename to arch/arm/mach-orion/include/mach/uncompress-orion5x.h
diff --git a/arch/arm/mach-orion/include/mach/uncompress.h b/arch/arm/mach-orion/include/mach/uncompress.h
new file mode 100644
index 0000000..fa1ba53
--- /dev/null
+++ b/arch/arm/mach-orion/include/mach/uncompress.h
@@ -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
diff --git a/arch/arm/mach-dove/irq.c b/arch/arm/mach-orion/irq-dove.c
similarity index 98%
rename from arch/arm/mach-dove/irq.c
rename to arch/arm/mach-orion/irq-dove.c
index f07fd16..1a78639 100644
--- a/arch/arm/mach-dove/irq.c
+++ b/arch/arm/mach-orion/irq-dove.c
@@ -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)
{
diff --git a/arch/arm/mach-kirkwood/irq.c b/arch/arm/mach-orion/irq-kirkwood.c
similarity index 97%
rename from arch/arm/mach-kirkwood/irq.c
rename to arch/arm/mach-orion/irq-kirkwood.c
index c4c68e5..75e124f 100644
--- a/arch/arm/mach-kirkwood/irq.c
+++ b/arch/arm/mach-orion/irq-kirkwood.c
@@ -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)
{
diff --git a/arch/arm/mach-mv78xx0/irq.c b/arch/arm/mach-orion/irq-mv78xx0.c
similarity index 97%
rename from arch/arm/mach-mv78xx0/irq.c
rename to arch/arm/mach-orion/irq-mv78xx0.c
index e421b70..695ae9b 100644
--- a/arch/arm/mach-mv78xx0/irq.c
+++ b/arch/arm/mach-orion/irq-mv78xx0.c
@@ -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)
{
diff --git a/arch/arm/mach-orion5x/irq.c b/arch/arm/mach-orion/irq-orion5x.c
similarity index 96%
rename from arch/arm/mach-orion5x/irq.c
rename to arch/arm/mach-orion/irq-orion5x.c
index b1b45ff..6d1f1f7 100644
--- a/arch/arm/mach-orion5x/irq.c
+++ b/arch/arm/mach-orion/irq-orion5x.c
@@ -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)
{
diff --git a/arch/arm/plat-orion/irq.c b/arch/arm/mach-orion/irq.c
similarity index 97%
rename from arch/arm/plat-orion/irq.c
rename to arch/arm/mach-orion/irq.c
index 2d5b9c1..b108805 100644
--- a/arch/arm/plat-orion/irq.c
+++ b/arch/arm/mach-orion/irq.c
@@ -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)
{
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-orion/kirkwood.c
similarity index 98%
rename from arch/arm/mach-kirkwood/common.c
rename to arch/arm/mach-orion/kirkwood.c
index 3ad0373..3dd3b3f 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-orion/kirkwood.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-orion/kirkwood.h
similarity index 100%
rename from arch/arm/mach-kirkwood/common.h
rename to arch/arm/mach-orion/kirkwood.h
diff --git a/arch/arm/mach-orion5x/kurobox_pro-setup.c b/arch/arm/mach-orion/kurobox_pro-setup.c
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
--- a/arch/arm/mach-orion5x/kurobox_pro-setup.c
+++ b/arch/arm/mach-orion/kurobox_pro-setup.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/lacie_v2-common.c b/arch/arm/mach-orion/lacie_v2-common.c
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
--- a/arch/arm/mach-kirkwood/lacie_v2-common.c
+++ b/arch/arm/mach-orion/lacie_v2-common.c
@@ -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)
diff --git a/arch/arm/mach-kirkwood/lacie_v2-common.h b/arch/arm/mach-orion/lacie_v2-common.h
similarity index 100%
rename from arch/arm/mach-kirkwood/lacie_v2-common.h
rename to arch/arm/mach-orion/lacie_v2-common.h
diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion/ls-chl-setup.c
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
--- a/arch/arm/mach-orion5x/ls-chl-setup.c
+++ b/arch/arm/mach-orion/ls-chl-setup.c
@@ -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
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c b/arch/arm/mach-orion/ls_hgl-setup.c
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
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion/ls_hgl-setup.c
@@ -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
diff --git a/arch/arm/mach-orion5x/lsmini-setup.c b/arch/arm/mach-orion/lsmini-setup.c
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
--- a/arch/arm/mach-orion5x/lsmini-setup.c
+++ b/arch/arm/mach-orion/lsmini-setup.c
@@ -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
diff --git a/arch/arm/mach-dove/mpp.c b/arch/arm/mach-orion/mpp-dove.c
similarity index 98%
rename from arch/arm/mach-dove/mpp.c
rename to arch/arm/mach-orion/mpp-dove.c
index 7f70afc..fa36a48 100644
--- a/arch/arm/mach-dove/mpp.c
+++ b/arch/arm/mach-orion/mpp-dove.c
@@ -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;
diff --git a/arch/arm/mach-dove/mpp.h b/arch/arm/mach-orion/mpp-dove.h
similarity index 100%
rename from arch/arm/mach-dove/mpp.h
rename to arch/arm/mach-orion/mpp-dove.h
diff --git a/arch/arm/mach-kirkwood/mpp.c b/arch/arm/mach-orion/mpp-kirkwood.c
similarity index 93%
rename from arch/arm/mach-kirkwood/mpp.c
rename to arch/arm/mach-orion/mpp-kirkwood.c
index 0c6ad63..da21b1b 100644
--- a/arch/arm/mach-kirkwood/mpp.c
+++ b/arch/arm/mach-orion/mpp-kirkwood.c
@@ -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)
{
diff --git a/arch/arm/mach-kirkwood/mpp.h b/arch/arm/mach-orion/mpp-kirkwood.h
similarity index 100%
rename from arch/arm/mach-kirkwood/mpp.h
rename to arch/arm/mach-orion/mpp-kirkwood.h
diff --git a/arch/arm/mach-mv78xx0/mpp.c b/arch/arm/mach-orion/mpp-mv78xx0.c
similarity index 92%
rename from arch/arm/mach-mv78xx0/mpp.c
rename to arch/arm/mach-orion/mpp-mv78xx0.c
index df50342..9d785d3 100644
--- a/arch/arm/mach-mv78xx0/mpp.c
+++ b/arch/arm/mach-orion/mpp-mv78xx0.c
@@ -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)
{
diff --git a/arch/arm/mach-mv78xx0/mpp.h b/arch/arm/mach-orion/mpp-mv78xx0.h
similarity index 100%
rename from arch/arm/mach-mv78xx0/mpp.h
rename to arch/arm/mach-orion/mpp-mv78xx0.h
diff --git a/arch/arm/mach-orion5x/mpp.c b/arch/arm/mach-orion/mpp-orion5x.c
similarity index 93%
rename from arch/arm/mach-orion5x/mpp.c
rename to arch/arm/mach-orion/mpp-orion5x.c
index 5b70026..2706cfc 100644
--- a/arch/arm/mach-orion5x/mpp.c
+++ b/arch/arm/mach-orion/mpp-orion5x.c
@@ -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)
{
diff --git a/arch/arm/mach-orion5x/mpp.h b/arch/arm/mach-orion/mpp-orion5x.h
similarity index 100%
rename from arch/arm/mach-orion5x/mpp.h
rename to arch/arm/mach-orion/mpp-orion5x.h
diff --git a/arch/arm/plat-orion/mpp.c b/arch/arm/mach-orion/mpp.c
similarity index 98%
rename from arch/arm/plat-orion/mpp.c
rename to arch/arm/mach-orion/mpp.c
index 3b1e17b..137c622 100644
--- a/arch/arm/plat-orion/mpp.c
+++ b/arch/arm/mach-orion/mpp.c
@@ -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,
diff --git a/arch/arm/mach-orion5x/mss2-setup.c b/arch/arm/mach-orion/mss2-setup.c
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
--- a/arch/arm/mach-orion5x/mss2-setup.c
+++ b/arch/arm/mach-orion/mss2-setup.c
@@ -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
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c b/arch/arm/mach-orion/mv2120-setup.c
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
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion/mv2120-setup.c
@@ -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
diff --git a/arch/arm/mach-mv78xx0/common.c b/arch/arm/mach-orion/mv78xx0.c
similarity index 98%
rename from arch/arm/mach-mv78xx0/common.c
rename to arch/arm/mach-orion/mv78xx0.c
index a5dcf766..a4bfa12 100644
--- a/arch/arm/mach-mv78xx0/common.c
+++ b/arch/arm/mach-orion/mv78xx0.c
@@ -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);
diff --git a/arch/arm/mach-mv78xx0/common.h b/arch/arm/mach-orion/mv78xx0.h
similarity index 100%
rename from arch/arm/mach-mv78xx0/common.h
rename to arch/arm/mach-orion/mv78xx0.h
diff --git a/arch/arm/mach-kirkwood/mv88f6281gtw_ge-setup.c b/arch/arm/mach-orion/mv88f6281gtw_ge-setup.c
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
--- a/arch/arm/mach-kirkwood/mv88f6281gtw_ge-setup.c
+++ b/arch/arm/mach-orion/mv88f6281gtw_ge-setup.c
@@ -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,
diff --git a/arch/arm/mach-orion5x/net2big-setup.c b/arch/arm/mach-orion/net2big-setup.c
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
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion/net2big-setup.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/netspace_v2-setup.c b/arch/arm/mach-orion/netspace_v2-setup.c
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
--- a/arch/arm/mach-kirkwood/netspace_v2-setup.c
+++ b/arch/arm/mach-orion/netspace_v2-setup.c
@@ -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"
/*****************************************************************************
diff --git a/arch/arm/mach-kirkwood/netxbig_v2-setup.c b/arch/arm/mach-orion/netxbig_v2-setup.c
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
--- a/arch/arm/mach-kirkwood/netxbig_v2-setup.c
+++ b/arch/arm/mach-orion/netxbig_v2-setup.c
@@ -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"
/*****************************************************************************
diff --git a/arch/arm/mach-kirkwood/openrd-setup.c b/arch/arm/mach-orion/openrd-setup.c
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
--- a/arch/arm/mach-kirkwood/openrd-setup.c
+++ b/arch/arm/mach-orion/openrd-setup.c
@@ -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[] = {
{
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion/orion5x.c
similarity index 98%
rename from arch/arm/mach-orion5x/common.c
rename to arch/arm/mach-orion/orion5x.c
index e2e9db4..8e0c16b 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion/orion5x.c
@@ -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
diff --git a/arch/arm/mach-orion5x/common.h b/arch/arm/mach-orion/orion5x.h
similarity index 100%
rename from arch/arm/mach-orion5x/common.h
rename to arch/arm/mach-orion/orion5x.h
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion/pci-orion5x.c
similarity index 99%
rename from arch/arm/mach-orion5x/pci.c
rename to arch/arm/mach-orion/pci-orion5x.c
index cb19e16..a545ae0 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion/pci-orion5x.c
@@ -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.
diff --git a/arch/arm/mach-dove/pcie.c b/arch/arm/mach-orion/pcie-dove.c
similarity index 98%
rename from arch/arm/mach-dove/pcie.c
rename to arch/arm/mach-orion/pcie-dove.c
index 48a0320..57134be 100644
--- a/arch/arm/mach-dove/pcie.c
+++ b/arch/arm/mach-orion/pcie-dove.c
@@ -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;
diff --git a/arch/arm/mach-kirkwood/pcie.c b/arch/arm/mach-orion/pcie-kirkwood.c
similarity index 98%
rename from arch/arm/mach-kirkwood/pcie.c
rename to arch/arm/mach-orion/pcie-kirkwood.c
index f56a011..2b65cb4 100644
--- a/arch/arm/mach-kirkwood/pcie.c
+++ b/arch/arm/mach-orion/pcie-kirkwood.c
@@ -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)
{
diff --git a/arch/arm/mach-mv78xx0/pcie.c b/arch/arm/mach-orion/pcie-mv78xx0.c
similarity index 99%
rename from arch/arm/mach-mv78xx0/pcie.c
rename to arch/arm/mach-orion/pcie-mv78xx0.c
index df3e380..c9616bf 100644
--- a/arch/arm/mach-mv78xx0/pcie.c
+++ b/arch/arm/mach-orion/pcie-mv78xx0.c
@@ -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;
diff --git a/arch/arm/plat-orion/pcie.c b/arch/arm/mach-orion/pcie.c
similarity index 99%
rename from arch/arm/plat-orion/pcie.c
rename to arch/arm/mach-orion/pcie.c
index 86dbb5b..921333a 100644
--- a/arch/arm/plat-orion/pcie.c
+++ b/arch/arm/mach-orion/pcie.c
@@ -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>
/*
diff --git a/arch/arm/mach-mv78xx0/rd78x00-masa-setup.c b/arch/arm/mach-orion/rd78x00-masa-setup.c
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
--- a/arch/arm/mach-mv78xx0/rd78x00-masa-setup.c
+++ b/arch/arm/mach-orion/rd78x00-masa-setup.c
@@ -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),
diff --git a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c b/arch/arm/mach-orion/rd88f5181l-fxo-setup.c
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
--- a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
+++ b/arch/arm/mach-orion/rd88f5181l-fxo-setup.c
@@ -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
diff --git a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c b/arch/arm/mach-orion/rd88f5181l-ge-setup.c
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
--- a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
+++ b/arch/arm/mach-orion/rd88f5181l-ge-setup.c
@@ -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
diff --git a/arch/arm/mach-orion5x/rd88f5182-setup.c b/arch/arm/mach-orion/rd88f5182-setup.c
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
--- a/arch/arm/mach-orion5x/rd88f5182-setup.c
+++ b/arch/arm/mach-orion/rd88f5182-setup.c
@@ -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
diff --git a/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c b/arch/arm/mach-orion/rd88f6183ap-ge-setup.c
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
--- a/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
+++ b/arch/arm/mach-orion/rd88f6183ap-ge-setup.c
@@ -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,
diff --git a/arch/arm/mach-kirkwood/rd88f6192-nas-setup.c b/arch/arm/mach-orion/rd88f6192-nas-setup.c
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
--- a/arch/arm/mach-kirkwood/rd88f6192-nas-setup.c
+++ b/arch/arm/mach-orion/rd88f6192-nas-setup.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/rd88f6281-setup.c b/arch/arm/mach-orion/rd88f6281-setup.c
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
--- a/arch/arm/mach-kirkwood/rd88f6281-setup.c
+++ b/arch/arm/mach-orion/rd88f6281-setup.c
@@ -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[] = {
{
diff --git a/arch/arm/mach-kirkwood/sheevaplug-setup.c b/arch/arm/mach-orion/sheevaplug-setup.c
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
--- a/arch/arm/mach-kirkwood/sheevaplug-setup.c
+++ b/arch/arm/mach-orion/sheevaplug-setup.c
@@ -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[] = {
{
diff --git a/arch/arm/mach-kirkwood/t5325-setup.c b/arch/arm/mach-orion/t5325-setup.c
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
--- a/arch/arm/mach-kirkwood/t5325-setup.c
+++ b/arch/arm/mach-orion/t5325-setup.c
@@ -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[] = {
{
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c b/arch/arm/mach-orion/terastation_pro2-setup.c
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
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion/terastation_pro2-setup.c
@@ -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
diff --git a/arch/arm/plat-orion/time.c b/arch/arm/mach-orion/time.c
similarity index 100%
rename from arch/arm/plat-orion/time.c
rename to arch/arm/mach-orion/time.c
diff --git a/arch/arm/mach-orion5x/ts209-setup.c b/arch/arm/mach-orion/ts209-setup.c
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
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion/ts209-setup.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/ts219-setup.c b/arch/arm/mach-orion/ts219-setup.c
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
--- a/arch/arm/mach-kirkwood/ts219-setup.c
+++ b/arch/arm/mach-orion/ts219-setup.c
@@ -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 = {
diff --git a/arch/arm/mach-orion5x/ts409-setup.c b/arch/arm/mach-orion/ts409-setup.c
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
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion/ts409-setup.c
@@ -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"
/*****************************************************************************
diff --git a/arch/arm/mach-kirkwood/ts41x-setup.c b/arch/arm/mach-orion/ts41x-setup.c
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
--- a/arch/arm/mach-kirkwood/ts41x-setup.c
+++ b/arch/arm/mach-orion/ts41x-setup.c
@@ -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
diff --git a/arch/arm/mach-orion5x/ts78xx-fpga.h b/arch/arm/mach-orion/ts78xx-fpga.h
similarity index 100%
rename from arch/arm/mach-orion5x/ts78xx-fpga.h
rename to arch/arm/mach-orion/ts78xx-fpga.h
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-orion/ts78xx-setup.c
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
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion/ts78xx-setup.c
@@ -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"
/*****************************************************************************
diff --git a/arch/arm/mach-orion5x/tsx09-common.c b/arch/arm/mach-orion/tsx09-common.c
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
--- a/arch/arm/mach-orion5x/tsx09-common.c
+++ b/arch/arm/mach-orion/tsx09-common.c
@@ -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
diff --git a/arch/arm/mach-orion5x/tsx09-common.h b/arch/arm/mach-orion/tsx09-common.h
similarity index 100%
rename from arch/arm/mach-orion5x/tsx09-common.h
rename to arch/arm/mach-orion/tsx09-common.h
diff --git a/arch/arm/mach-kirkwood/tsx1x-common.c b/arch/arm/mach-orion/tsx1x-common.c
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
--- a/arch/arm/mach-kirkwood/tsx1x-common.c
+++ b/arch/arm/mach-orion/tsx1x-common.c
@@ -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
diff --git a/arch/arm/mach-kirkwood/tsx1x-common.h b/arch/arm/mach-orion/tsx1x-common.h
similarity index 100%
rename from arch/arm/mach-kirkwood/tsx1x-common.h
rename to arch/arm/mach-orion/tsx1x-common.h
diff --git a/arch/arm/mach-orion5x/wnr854t-setup.c b/arch/arm/mach-orion/wnr854t-setup.c
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
--- a/arch/arm/mach-orion5x/wnr854t-setup.c
+++ b/arch/arm/mach-orion/wnr854t-setup.c
@@ -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) */
diff --git a/arch/arm/mach-orion5x/wrt350n-v2-setup.c b/arch/arm/mach-orion/wrt350n-v2-setup.c
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
--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion/wrt350n-v2-setup.c
@@ -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
diff --git a/arch/arm/mach-orion5x/Makefile.boot b/arch/arm/mach-orion5x/Makefile.boot
deleted file mode 100644
index 760a0ef..0000000
--- a/arch/arm/mach-orion5x/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
- zreladdr-y += 0x00008000
-params_phys-y := 0x00000100
-initrd_phys-y := 0x00800000
diff --git a/arch/arm/mach-orion5x/include/mach/gpio.h b/arch/arm/mach-orion5x/include/mach/gpio.h
deleted file mode 100644
index a1d0b78..0000000
--- a/arch/arm/mach-orion5x/include/mach/gpio.h
+++ /dev/null
@@ -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>
diff --git a/arch/arm/mach-orion5x/include/mach/hardware.h b/arch/arm/mach-orion5x/include/mach/hardware.h
deleted file mode 100644
index 3957354..0000000
--- a/arch/arm/mach-orion5x/include/mach/hardware.h
+++ /dev/null
@@ -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
diff --git a/arch/arm/mach-orion5x/include/mach/timex.h b/arch/arm/mach-orion5x/include/mach/timex.h
deleted file mode 100644
index 4c69820..0000000
--- a/arch/arm/mach-orion5x/include/mach/timex.h
+++ /dev/null
@@ -1,11 +0,0 @@
-/*
- * arch/arm/mach-orion5x/include/mach/timex.h
- *
- * Tzachi Perelstein <tzachi@marvell.com>
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#define CLOCK_TICK_RATE (100 * HZ)
diff --git a/arch/arm/mm/cache-feroceon-l2.c b/arch/arm/mm/cache-feroceon-l2.c
index dd3d591..2ace351 100644
--- a/arch/arm/mm/cache-feroceon-l2.c
+++ b/arch/arm/mm/cache-feroceon-l2.c
@@ -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.
diff --git a/arch/arm/plat-orion/Makefile b/arch/arm/plat-orion/Makefile
deleted file mode 100644
index c20ce0f..0000000
--- a/arch/arm/plat-orion/Makefile
+++ /dev/null
@@ -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
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index fa5d55f..425e972 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -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"
diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
index eeb8cd1..7d2daff 100644
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@ -24,7 +24,7 @@
#include <asm/sizes.h>
#include <asm/unaligned.h>
-#include <plat/mvsdio.h>
+#include <mach/mvsdio.h>
#include "mvsdio.h"
diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index 0f50ef3..407f43d 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -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)
{
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index 6c6a5a3..7b6eccb 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -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))
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 788aa15..a26bbb5 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -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.
diff --git a/sound/soc/kirkwood/kirkwood-i2s.c b/sound/soc/kirkwood/kirkwood-i2s.c
index 3cb9aa4..49db36c 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -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"
diff --git a/sound/soc/kirkwood/kirkwood-openrd.c b/sound/soc/kirkwood/kirkwood-openrd.c
index 80bd59c..778b1dd 100644
--- a/sound/soc/kirkwood/kirkwood-openrd.c
+++ b/sound/soc/kirkwood/kirkwood-openrd.c
@@ -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"
diff --git a/sound/soc/kirkwood/kirkwood-t5325.c b/sound/soc/kirkwood/kirkwood-t5325.c
index f898363..e3c7b32 100644
--- a/sound/soc/kirkwood/kirkwood-t5325.c
+++ b/sound/soc/kirkwood/kirkwood-t5325.c
@@ -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"
^ permalink raw reply related [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 21:35 ` Arnd Bergmann
@ 2012-05-16 0:25 ` Nicolas Pitre
2012-05-16 5:07 ` Andrew Lunn
` (2 subsequent siblings)
3 siblings, 0 replies; 140+ messages in thread
From: Nicolas Pitre @ 2012-05-16 0:25 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 15 May 2012, Arnd Bergmann wrote:
> On Tuesday 15 May 2012, Arnd Bergmann wrote:
>
> > 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.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
The problematic Armada naming issue simply goes away.
> 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(-)
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 21:35 ` Arnd Bergmann
2012-05-16 0:25 ` Nicolas Pitre
@ 2012-05-16 5:07 ` Andrew Lunn
2012-05-16 6:57 ` Arnd Bergmann
2012-05-16 6:57 ` Haojian Zhuang
2012-05-16 17:30 ` Andrew Lunn
3 siblings, 1 reply; 140+ messages in thread
From: Andrew Lunn @ 2012-05-16 5:07 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 09:35:26PM +0000, Arnd Bergmann wrote:
> On Tuesday 15 May 2012, Arnd Bergmann wrote:
>
> > 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.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 21:35 ` Arnd Bergmann
2012-05-16 0:25 ` Nicolas Pitre
2012-05-16 5:07 ` Andrew Lunn
@ 2012-05-16 6:57 ` Haojian Zhuang
2012-05-16 17:30 ` Andrew Lunn
3 siblings, 0 replies; 140+ messages in thread
From: Haojian Zhuang @ 2012-05-16 6:57 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 16, 2012 at 5:35 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 15 May 2012, Arnd Bergmann wrote:
>
>> 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.
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 5:07 ` Andrew Lunn
@ 2012-05-16 6:57 ` Arnd Bergmann
0 siblings, 0 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-16 6:57 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 16 May 2012, Andrew Lunn wrote:
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 14:44 ` Thomas Petazzoni
2012-05-15 15:27 ` Arnd Bergmann
2012-05-15 16:22 ` Andrew Lunn
@ 2012-05-16 11:12 ` Lior Amsalem
2012-05-16 11:36 ` Andrew Lunn
2012-05-16 12:00 ` Arnd Bergmann
2 siblings, 2 replies; 140+ messages in thread
From: Lior Amsalem @ 2012-05-16 11:12 UTC (permalink / raw)
To: linux-arm-kernel
> -----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 <robherring2@gmail.com> a ?crit :
>
> > 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.
>
> > 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.
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.
>
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 11:12 ` Lior Amsalem
@ 2012-05-16 11:36 ` Andrew Lunn
2012-05-16 12:00 ` Arnd Bergmann
1 sibling, 0 replies; 140+ messages in thread
From: Andrew Lunn @ 2012-05-16 11:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lior
Thanks for the list.
> 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.
> 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
mach-kirkwood supports 6180 6190 6192 6281 6282
6180 and 6281 are not on your list.
>
> 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
Is there any logic to the names/numbers?
Thanks
Andrew
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 11:12 ` Lior Amsalem
2012-05-16 11:36 ` Andrew Lunn
@ 2012-05-16 12:00 ` Arnd Bergmann
2012-05-16 14:55 ` Lior Amsalem
1 sibling, 1 reply; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-16 12:00 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 16 May 2012, Lior Amsalem wrote:
> > 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.
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 8:54 ` [PATCH 2/8] arm: mach-armada: add source files Thomas Petazzoni
` (2 preceding siblings ...)
2012-05-15 9:46 ` Ben Dooks
@ 2012-05-16 14:27 ` Ben Dooks
2012-05-16 15:06 ` Ben Dooks
4 siblings, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-16 14:27 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 09:54, Thomas Petazzoni wrote:
> diff --git a/arch/arm/mach-armada/common.h b/arch/arm/mach-armada/common.h
> new file mode 100644
> index 0000000..e453161
> --- /dev/null
> +++ b/arch/arm/mach-armada/common.h
> @@ -0,0 +1,27 @@
> +/*
> + * Core functions for Marvell Armada System On Chip
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem<alior@marvell.com>
> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __ARCH_ARMADA_COMMON_H
> +#define __ARCH_ARMADA_COMMON_H
> +
> +#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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 12:00 ` Arnd Bergmann
@ 2012-05-16 14:55 ` Lior Amsalem
2012-05-16 15:20 ` Nicolas Pitre
2012-05-16 15:28 ` Arnd Bergmann
0 siblings, 2 replies; 140+ messages in thread
From: Lior Amsalem @ 2012-05-16 14:55 UTC (permalink / raw)
To: linux-arm-kernel
> -----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]
>
> 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.
>
> 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/
> 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.
>
> Arnd
Lior Amsalem
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 8:54 ` [PATCH 2/8] arm: mach-armada: add source files Thomas Petazzoni
` (3 preceding siblings ...)
2012-05-16 14:27 ` Ben Dooks
@ 2012-05-16 15:06 ` Ben Dooks
4 siblings, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-16 15:06 UTC (permalink / raw)
To: linux-arm-kernel
On 15/05/12 09:54, Thomas Petazzoni wrote:
> diff --git a/arch/arm/mach-armada/common.h b/arch/arm/mach-armada/common.h
> new file mode 100644
> index 0000000..e453161
> --- /dev/null
> +++ b/arch/arm/mach-armada/common.h
> @@ -0,0 +1,27 @@
> +/*
> + * Core functions for Marvell Armada System On Chip
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Lior Amsalem<alior@marvell.com>
> + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __ARCH_ARMADA_COMMON_H
> +#define __ARCH_ARMADA_COMMON_H
> +
> +#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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 14:55 ` Lior Amsalem
@ 2012-05-16 15:20 ` Nicolas Pitre
2012-05-16 15:28 ` Arnd Bergmann
1 sibling, 0 replies; 140+ messages in thread
From: Nicolas Pitre @ 2012-05-16 15:20 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 16 May 2012, Lior Amsalem wrote:
> > -----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]
> >
> > 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 14:55 ` Lior Amsalem
2012-05-16 15:20 ` Nicolas Pitre
@ 2012-05-16 15:28 ` Arnd Bergmann
2012-05-16 16:49 ` Nicolas Pitre
1 sibling, 1 reply; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-16 15:28 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 16 May 2012, Lior Amsalem wrote:
> >
> > 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 15:28 ` Arnd Bergmann
@ 2012-05-16 16:49 ` Nicolas Pitre
2012-05-16 19:46 ` Arnd Bergmann
0 siblings, 1 reply; 140+ messages in thread
From: Nicolas Pitre @ 2012-05-16 16:49 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 16 May 2012, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Lior Amsalem wrote:
> > >
> > > 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.
Why not? Module aliases can be used if that is a concern.
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-15 21:35 ` Arnd Bergmann
` (2 preceding siblings ...)
2012-05-16 6:57 ` Haojian Zhuang
@ 2012-05-16 17:30 ` Andrew Lunn
3 siblings, 0 replies; 140+ messages in thread
From: Andrew Lunn @ 2012-05-16 17:30 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 09:35:26PM +0000, Arnd Bergmann wrote:
> On Tuesday 15 May 2012, Arnd Bergmann wrote:
>
> > 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.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It boots on my kirkwood QNAP TS109P+ and all the devices seem present
and correct.
Tested-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 16:49 ` Nicolas Pitre
@ 2012-05-16 19:46 ` Arnd Bergmann
2012-05-16 20:20 ` Nicolas Pitre
0 siblings, 1 reply; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-16 19:46 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 16 May 2012, Nicolas Pitre wrote:
> >
> > 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.
>
> > 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 19:46 ` Arnd Bergmann
@ 2012-05-16 20:20 ` Nicolas Pitre
2012-05-16 20:34 ` Arnd Bergmann
2012-05-18 19:18 ` Jason Cooper
0 siblings, 2 replies; 140+ messages in thread
From: Nicolas Pitre @ 2012-05-16 20:20 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 16 May 2012, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Nicolas Pitre wrote:
> > >
> > > 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.
> >
> > > 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.
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.
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 20:20 ` Nicolas Pitre
@ 2012-05-16 20:34 ` Arnd Bergmann
2012-05-18 19:20 ` Jason Cooper
2012-05-18 19:18 ` Jason Cooper
1 sibling, 1 reply; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-16 20:34 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 16 May 2012, Nicolas Pitre wrote:
> 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.
mvebu sounds reasonable to me, it's definitely unique and it's almost a
word ;-)
Arnd
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 14:23 ` Arnd Bergmann
2012-05-15 18:37 ` Nicolas Pitre
@ 2012-05-17 23:31 ` Jason Cooper
1 sibling, 0 replies; 140+ messages in thread
From: Jason Cooper @ 2012-05-17 23:31 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 02:23:30PM +0000, Arnd Bergmann wrote:
> On Tuesday 15 May 2012, Andrew Lunn wrote:
> > > > 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.
>
> 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.
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-15 13:31 ` Rob Herring
2012-05-15 13:53 ` Ben Dooks
@ 2012-05-17 23:35 ` Jason Cooper
2012-05-18 2:12 ` Rob Herring
1 sibling, 1 reply; 140+ messages in thread
From: Jason Cooper @ 2012-05-17 23:35 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2012 at 08:31:06AM -0500, Rob Herring wrote:
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-17 23:35 ` Jason Cooper
@ 2012-05-18 2:12 ` Rob Herring
2012-05-22 12:00 ` Ben Dooks
0 siblings, 1 reply; 140+ messages in thread
From: Rob Herring @ 2012-05-18 2:12 UTC (permalink / raw)
To: linux-arm-kernel
On 05/17/2012 06:35 PM, Jason Cooper wrote:
> On Tue, May 15, 2012 at 08:31:06AM -0500, Rob Herring wrote:
>> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 20:20 ` Nicolas Pitre
2012-05-16 20:34 ` Arnd Bergmann
@ 2012-05-18 19:18 ` Jason Cooper
2012-05-18 20:44 ` Arnd Bergmann
1 sibling, 1 reply; 140+ messages in thread
From: Jason Cooper @ 2012-05-18 19:18 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 16, 2012 at 04:20:36PM -0400, Nicolas Pitre wrote:
> On Wed, 16 May 2012, Arnd Bergmann wrote:
>
> > On Wednesday 16 May 2012, Nicolas Pitre wrote:
> > > >
> > > > 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.
> > >
> > > > 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.
>
> 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.
>
> > 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.
I prefer mvebu_* ... nice and concise.
thx,
Jason.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-16 20:34 ` Arnd Bergmann
@ 2012-05-18 19:20 ` Jason Cooper
2012-05-22 12:03 ` Ben Dooks
0 siblings, 1 reply; 140+ messages in thread
From: Jason Cooper @ 2012-05-18 19:20 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 16, 2012 at 08:34:49PM +0000, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Nicolas Pitre wrote:
> > 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.
>
> mvebu sounds reasonable to me, it's definitely unique and it's almost a
> word ;-)
mvebuntu? *ducks*
;-P
Jason.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-18 19:18 ` Jason Cooper
@ 2012-05-18 20:44 ` Arnd Bergmann
2012-05-18 22:51 ` Nicolas Pitre
2012-05-21 8:55 ` Ben Dooks
0 siblings, 2 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-18 20:44 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 18 May 2012, Jason Cooper wrote:
> >
> > 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.
>
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-18 20:44 ` Arnd Bergmann
@ 2012-05-18 22:51 ` Nicolas Pitre
2012-05-19 11:24 ` Jason Cooper
2012-05-21 8:55 ` Ben Dooks
1 sibling, 1 reply; 140+ messages in thread
From: Nicolas Pitre @ 2012-05-18 22:51 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 18 May 2012, Arnd Bergmann wrote:
> On Friday 18 May 2012, Jason Cooper wrote:
> > >
> > > 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.
> >
> > 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.
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 2/8] arm: mach-armada: add source files
2012-05-15 9:46 ` Ben Dooks
2012-05-15 9:59 ` Gregory CLEMENT
2012-05-15 10:03 ` Andrew Lunn
@ 2012-05-19 6:21 ` Grant Likely
2 siblings, 0 replies; 140+ messages in thread
From: Grant Likely @ 2012-05-19 6:21 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 15 May 2012 10:46:04 +0100, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
> On 15/05/12 09:54, Thomas Petazzoni wrote:
> > This patch adds basic source files for Marvell Armada SoCs.
> >
> > Signed-off-by: Gregory CLEMENT<gregory.clement@free-electrons.com>
> > Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> > Signed-off-by: Lior Amsalem<alior@marvell.com>
> > ---
> > arch/arm/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
> >
> > diff --git a/arch/arm/boot/dts/a370.dtsi b/arch/arm/boot/dts/a370.dtsi
> > new file mode 100644
> > index 0000000..f11e56a
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/a370.dtsi
> > @@ -0,0 +1,23 @@
> > +/*
> > + * Device Tree Include file for Marvell Armada 370 family SoC
> > + *
> > + * Copyright (C) 2012 Marvell
> > + *
> > + * Lior Amsalem<alior@marvell.com>
> > + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> > + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> > + *
> > + * This file is licensed under the terms of the GNU General Public
> > + * License version 2. This program is licensed "as is" without any
> > + * warranty of any kind, whether express or implied.
> > + *
> > + * Contains definitions specific to the Armada 370 SoC that are not
> > + * common to all Armada SoCs.
> > + */
> > +
> > +/include/ "armada.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.
>
> > +/ {
> > + 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.
>
> > diff --git a/arch/arm/boot/dts/armada.dtsi b/arch/arm/boot/dts/armada.dtsi
> > new file mode 100644
> > index 0000000..3c99c30
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/armada.dtsi
> > @@ -0,0 +1,67 @@
> > +/*
> > + * Device Tree Include file for Marvell Armada family SoC
> > + *
> > + * Copyright (C) 2012 Marvell
> > + *
> > + * Lior Amsalem<alior@marvell.com>
> > + * Gregory CLEMENT<gregory.clement@free-electrons.com>
> > + * Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> > + *
> > + * This file is licensed under the terms of the GNU General Public
> > + * License version 2. This program is licensed "as is" without any
> > + * warranty of any kind, whether express or implied.
> > + *
> > + * 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)
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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-18 22:51 ` Nicolas Pitre
@ 2012-05-19 11:24 ` Jason Cooper
2012-05-19 17:32 ` Arnd Bergmann
0 siblings, 1 reply; 140+ messages in thread
From: Jason Cooper @ 2012-05-19 11:24 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 18, 2012 at 06:51:22PM -0400, Nicolas Pitre wrote:
> On Fri, 18 May 2012, Arnd Bergmann wrote:
>
> > On Friday 18 May 2012, Jason Cooper wrote:
> > > >
> > > > 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.
> > >
> > > 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.
>
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-19 11:24 ` Jason Cooper
@ 2012-05-19 17:32 ` Arnd Bergmann
2012-05-20 0:45 ` Nicolas Pitre
0 siblings, 1 reply; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-19 17:32 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 19 May 2012, Jason Cooper wrote:
> > 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-19 17:32 ` Arnd Bergmann
@ 2012-05-20 0:45 ` Nicolas Pitre
2012-05-20 9:55 ` Russell King - ARM Linux
0 siblings, 1 reply; 140+ messages in thread
From: Nicolas Pitre @ 2012-05-20 0:45 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, 19 May 2012, Arnd Bergmann wrote:
> On Saturday 19 May 2012, Jason Cooper wrote:
> > > 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?
I think arch/arm/plat-mvvebu/include/mach/* could work.
Nicolas
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-20 0:45 ` Nicolas Pitre
@ 2012-05-20 9:55 ` Russell King - ARM Linux
2012-05-20 10:58 ` Arnd Bergmann
0 siblings, 1 reply; 140+ messages in thread
From: Russell King - ARM Linux @ 2012-05-20 9:55 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, May 19, 2012 at 08:45:03PM -0400, Nicolas Pitre wrote:
> On Sat, 19 May 2012, Arnd Bergmann wrote:
>
> > On Saturday 19 May 2012, Jason Cooper wrote:
> > > > 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?
>
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-20 9:55 ` Russell King - ARM Linux
@ 2012-05-20 10:58 ` Arnd Bergmann
2012-05-20 11:10 ` Russell King - ARM Linux
0 siblings, 1 reply; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-20 10:58 UTC (permalink / raw)
To: linux-arm-kernel
On Sunday 20 May 2012, Russell King - ARM Linux wrote:
> On Sat, May 19, 2012 at 08:45:03PM -0400, Nicolas Pitre wrote:
> > On Sat, 19 May 2012, Arnd Bergmann wrote:
> >
> > > On Saturday 19 May 2012, Jason Cooper wrote:
> > > > > 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?
> >
> > 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-20 10:58 ` Arnd Bergmann
@ 2012-05-20 11:10 ` Russell King - ARM Linux
2012-05-21 1:30 ` Jason Cooper
0 siblings, 1 reply; 140+ messages in thread
From: Russell King - ARM Linux @ 2012-05-20 11:10 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, May 20, 2012 at 10:58:37AM +0000, Arnd Bergmann wrote:
> On Sunday 20 May 2012, Russell King - ARM Linux wrote:
> > 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 (?)
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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-20 11:10 ` Russell King - ARM Linux
@ 2012-05-21 1:30 ` Jason Cooper
2012-05-21 7:58 ` Arnd Bergmann
2012-05-21 9:30 ` Russell King - ARM Linux
0 siblings, 2 replies; 140+ messages in thread
From: Jason Cooper @ 2012-05-21 1:30 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, May 20, 2012 at 12:10:25PM +0100, Russell King - ARM Linux wrote:
> On Sun, May 20, 2012 at 10:58:37AM +0000, Arnd Bergmann wrote:
> > On Sunday 20 May 2012, Russell King - ARM Linux wrote:
> > > 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
plat-mvebu/include/plat ?
> > * headers used to inteface between the first two go to
> > plat-mvebu/include/plat (?)
plat-mvebu/include ?
>
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 1:30 ` Jason Cooper
@ 2012-05-21 7:58 ` Arnd Bergmann
2012-05-21 9:30 ` Russell King - ARM Linux
1 sibling, 0 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-21 7:58 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 21 May 2012, Jason Cooper wrote:
> > > * 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.
> > > * 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.
> > 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?
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-18 20:44 ` Arnd Bergmann
2012-05-18 22:51 ` Nicolas Pitre
@ 2012-05-21 8:55 ` Ben Dooks
2012-05-21 9:16 ` Andrew Lunn
1 sibling, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-21 8:55 UTC (permalink / raw)
To: linux-arm-kernel
On 18/05/12 21:44, Arnd Bergmann wrote:
> On Friday 18 May 2012, Jason Cooper wrote:
>>>
>>> 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.
>>
>> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 8:55 ` Ben Dooks
@ 2012-05-21 9:16 ` Andrew Lunn
2012-05-21 9:27 ` Ben Dooks
0 siblings, 1 reply; 140+ messages in thread
From: Andrew Lunn @ 2012-05-21 9:16 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 21, 2012 at 09:55:43AM +0100, Ben Dooks wrote:
> On 18/05/12 21:44, Arnd Bergmann wrote:
> >On Friday 18 May 2012, Jason Cooper wrote:
> >>>
> >>>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.
> >>
> >>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.
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 9:16 ` Andrew Lunn
@ 2012-05-21 9:27 ` Ben Dooks
2012-05-21 9:40 ` Andrew Lunn
0 siblings, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-21 9:27 UTC (permalink / raw)
To: linux-arm-kernel
On 21/05/12 10:16, Andrew Lunn wrote:
> On Mon, May 21, 2012 at 09:55:43AM +0100, Ben Dooks wrote:
>> On 18/05/12 21:44, Arnd Bergmann wrote:
>>> On Friday 18 May 2012, Jason Cooper wrote:
>>>>>
>>>>> 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.
>>>>
>>>> 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.
>
> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 1:30 ` Jason Cooper
2012-05-21 7:58 ` Arnd Bergmann
@ 2012-05-21 9:30 ` Russell King - ARM Linux
2012-05-21 15:35 ` Jason Cooper
1 sibling, 1 reply; 140+ messages in thread
From: Russell King - ARM Linux @ 2012-05-21 9:30 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, May 20, 2012 at 09:30:50PM -0400, Jason Cooper wrote:
> On Sun, May 20, 2012 at 12:10:25PM +0100, Russell King - ARM Linux wrote:
> > On Sun, May 20, 2012 at 10:58:37AM +0000, Arnd Bergmann wrote:
> > > On Sunday 20 May 2012, Russell King - ARM Linux wrote:
> > > > 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
>
> plat-mvebu/include/plat ?
Better.
> > > * 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.
> > 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.
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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 9:27 ` Ben Dooks
@ 2012-05-21 9:40 ` Andrew Lunn
2012-05-21 15:39 ` Jason Cooper
0 siblings, 1 reply; 140+ messages in thread
From: Andrew Lunn @ 2012-05-21 9:40 UTC (permalink / raw)
To: linux-arm-kernel
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 9:30 ` Russell King - ARM Linux
@ 2012-05-21 15:35 ` Jason Cooper
2012-05-21 16:11 ` Russell King - ARM Linux
0 siblings, 1 reply; 140+ messages in thread
From: Jason Cooper @ 2012-05-21 15:35 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 21, 2012 at 10:30:42AM +0100, Russell King - ARM Linux wrote:
> On Sun, May 20, 2012 at 09:30:50PM -0400, Jason Cooper wrote:
> > On Sun, May 20, 2012 at 12:10:25PM +0100, Russell King - ARM Linux wrote:
> > > On Sun, May 20, 2012 at 10:58:37AM +0000, Arnd Bergmann wrote:
> > > > On Sunday 20 May 2012, Russell King - ARM Linux wrote:
> > > > > 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
> >
> > plat-mvebu/include/plat ?
>
> Better.
>
> > > > * 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.
Got it, thanks for the clarification.
> > > 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.
>
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 9:40 ` Andrew Lunn
@ 2012-05-21 15:39 ` Jason Cooper
2012-05-21 17:27 ` Andrew Lunn
0 siblings, 1 reply; 140+ messages in thread
From: Jason Cooper @ 2012-05-21 15:39 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 21, 2012 at 11:40:52AM +0200, Andrew Lunn wrote:
> > Personally, my view is leave it alone and just add a new machine
> > directory.
I agree, see my response to Russell.
> > 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 15:35 ` Jason Cooper
@ 2012-05-21 16:11 ` Russell King - ARM Linux
2012-05-21 16:58 ` Jason Cooper
0 siblings, 1 reply; 140+ messages in thread
From: Russell King - ARM Linux @ 2012-05-21 16:11 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 16:11 ` Russell King - ARM Linux
@ 2012-05-21 16:58 ` Jason Cooper
2012-05-21 19:40 ` Arnd Bergmann
0 siblings, 1 reply; 140+ messages in thread
From: Jason Cooper @ 2012-05-21 16:58 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 21, 2012 at 05:11:31PM +0100, Russell King - ARM Linux wrote:
> On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:
> > 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.
Fair enough, we can move that.
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 15:39 ` Jason Cooper
@ 2012-05-21 17:27 ` Andrew Lunn
0 siblings, 0 replies; 140+ messages in thread
From: Andrew Lunn @ 2012-05-21 17:27 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 21, 2012 at 11:39:22AM -0400, Jason Cooper wrote:
> On Mon, May 21, 2012 at 11:40:52AM +0200, Andrew Lunn wrote:
> > > Personally, my view is leave it alone and just add a new machine
> > > directory.
>
> I agree, see my response to Russell.
>
> > > 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?
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 16:58 ` Jason Cooper
@ 2012-05-21 19:40 ` Arnd Bergmann
2012-05-22 14:25 ` Nicolas Pitre
0 siblings, 1 reply; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-21 19:40 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 21 May 2012, Jason Cooper wrote:
> On Mon, May 21, 2012 at 05:11:31PM +0100, Russell King - ARM Linux wrote:
> > 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.
>
> 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-18 2:12 ` Rob Herring
@ 2012-05-22 12:00 ` Ben Dooks
2012-05-22 13:34 ` Jason Cooper
0 siblings, 1 reply; 140+ messages in thread
From: Ben Dooks @ 2012-05-22 12:00 UTC (permalink / raw)
To: linux-arm-kernel
On 18/05/12 03:12, Rob Herring wrote:
> On 05/17/2012 06:35 PM, Jason Cooper wrote:
>> On Tue, May 15, 2012 at 08:31:06AM -0500, Rob Herring wrote:
>>> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-18 19:20 ` Jason Cooper
@ 2012-05-22 12:03 ` Ben Dooks
0 siblings, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-22 12:03 UTC (permalink / raw)
To: linux-arm-kernel
On 18/05/12 20:20, Jason Cooper wrote:
> On Wed, May 16, 2012 at 08:34:49PM +0000, Arnd Bergmann wrote:
>> On Wednesday 16 May 2012, Nicolas Pitre wrote:
>>> 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.
>>
>> mvebu sounds reasonable to me, it's definitely unique and it's almost a
>> word ;-)
>
> mvebuntu? *ducks*
you, sir, are clearly quackers.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-22 12:00 ` Ben Dooks
@ 2012-05-22 13:34 ` Jason Cooper
2012-05-22 17:06 ` Arnd Bergmann
0 siblings, 1 reply; 140+ messages in thread
From: Jason Cooper @ 2012-05-22 13:34 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 22, 2012 at 01:00:23PM +0100, Ben Dooks wrote:
> On 18/05/12 03:12, Rob Herring wrote:
> >On 05/17/2012 06:35 PM, Jason Cooper wrote:
> >>On Tue, May 15, 2012 at 08:31:06AM -0500, Rob Herring wrote:
> >>>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.
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.
> 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:
diff --git a/drivers/rtc/rtc-mv.c b/drivers/rtc/rtc-mv.c
index b2185f4..de7b231 100644
--- a/drivers/rtc/rtc-mv.c
+++ b/drivers/rtc/rtc-mv.c
@@ -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.
> 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.
> 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.
^ permalink raw reply related [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-21 19:40 ` Arnd Bergmann
@ 2012-05-22 14:25 ` Nicolas Pitre
2012-05-22 16:03 ` Jason Cooper
0 siblings, 1 reply; 140+ messages in thread
From: Nicolas Pitre @ 2012-05-22 14:25 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 21 May 2012, Arnd Bergmann wrote:
> On Monday 21 May 2012, Jason Cooper wrote:
> > On Mon, May 21, 2012 at 05:11:31PM +0100, Russell King - ARM Linux wrote:
> > > 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.
> >
> > 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.
I'd suggest that mach-mvebu be created earlier for the new EBU ARmada
SOC support though.
Nicolas
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-22 14:25 ` Nicolas Pitre
@ 2012-05-22 16:03 ` Jason Cooper
2012-05-22 16:06 ` Ben Dooks
2012-05-22 17:09 ` Arnd Bergmann
0 siblings, 2 replies; 140+ messages in thread
From: Jason Cooper @ 2012-05-22 16:03 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 22, 2012 at 10:25:28AM -0400, Nicolas Pitre wrote:
> On Mon, 21 May 2012, Arnd Bergmann wrote:
>
> > On Monday 21 May 2012, Jason Cooper wrote:
> > > On Mon, May 21, 2012 at 05:11:31PM +0100, Russell King - ARM Linux wrote:
> > > > 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.
> > >
> > > 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.
>
> 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.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-22 16:03 ` Jason Cooper
@ 2012-05-22 16:06 ` Ben Dooks
2012-05-22 16:16 ` Jason Cooper
2012-05-24 11:18 ` Ben Dooks
2012-05-22 17:09 ` Arnd Bergmann
1 sibling, 2 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-22 16:06 UTC (permalink / raw)
To: linux-arm-kernel
On 22/05/12 17:03, Jason Cooper wrote:
> On Tue, May 22, 2012 at 10:25:28AM -0400, Nicolas Pitre wrote:
>> On Mon, 21 May 2012, Arnd Bergmann wrote:
>>
>>> On Monday 21 May 2012, Jason Cooper wrote:
>>>> On Mon, May 21, 2012 at 05:11:31PM +0100, Russell King - ARM Linux wrote:
>>>>> 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.
>>>>
>>>> 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.
>>
>> 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.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-22 16:06 ` Ben Dooks
@ 2012-05-22 16:16 ` Jason Cooper
2012-05-24 11:18 ` Ben Dooks
1 sibling, 0 replies; 140+ messages in thread
From: Jason Cooper @ 2012-05-22 16:16 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 22, 2012 at 05:06:12PM +0100, Ben Dooks wrote:
> On 22/05/12 17:03, Jason Cooper wrote:
> >On Tue, May 22, 2012 at 10:25:28AM -0400, Nicolas Pitre wrote:
> >>On Mon, 21 May 2012, Arnd Bergmann wrote:
> >>
> >>>On Monday 21 May 2012, Jason Cooper wrote:
> >>>>On Mon, May 21, 2012 at 05:11:31PM +0100, Russell King - ARM Linux wrote:
> >>>>>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.
> >>>>
> >>>>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.
> >>
> >>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.
Fair enough.
thx,
Jason.
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-22 13:34 ` Jason Cooper
@ 2012-05-22 17:06 ` Arnd Bergmann
2012-05-23 2:02 ` Haojian Zhuang
0 siblings, 1 reply; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-22 17:06 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 22 May 2012, Jason Cooper wrote:
> $ 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?
>
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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-22 16:03 ` Jason Cooper
2012-05-22 16:06 ` Ben Dooks
@ 2012-05-22 17:09 ` Arnd Bergmann
1 sibling, 0 replies; 140+ messages in thread
From: Arnd Bergmann @ 2012-05-22 17:09 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 22 May 2012, Jason Cooper wrote:
> On Tue, May 22, 2012 at 10:25:28AM -0400, Nicolas Pitre wrote:
> > 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
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device tree
2012-05-22 17:06 ` Arnd Bergmann
@ 2012-05-23 2:02 ` Haojian Zhuang
0 siblings, 0 replies; 140+ messages in thread
From: Haojian Zhuang @ 2012-05-23 2:02 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 23, 2012 at 1:06 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 22 May 2012, Jason Cooper wrote:
>> $ 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?
>>
>
> 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
>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH] arm: Add basic support for new Marvell Armada SoC family
2012-05-22 16:06 ` Ben Dooks
2012-05-22 16:16 ` Jason Cooper
@ 2012-05-24 11:18 ` Ben Dooks
1 sibling, 0 replies; 140+ messages in thread
From: Ben Dooks @ 2012-05-24 11:18 UTC (permalink / raw)
To: linux-arm-kernel
On 22/05/12 17:06, Ben Dooks wrote:
> On 22/05/12 17:03, Jason Cooper wrote:
[snip]
> 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/
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 140+ messages in thread
end of thread, other threads:[~2012-05-24 11:18 UTC | newest]
Thread overview: 140+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-15 8:54 [PATCH] arm: Add basic support for new Marvell Armada SoC family Thomas Petazzoni
2012-05-15 8:54 ` [PATCH 1/8] arm: mach-armada: add headers Thomas Petazzoni
2012-05-15 9:16 ` Ben Dooks
2012-05-15 10:57 ` Ben Dooks
2012-05-15 13:21 ` Rob Herring
2012-05-15 18:42 ` Nicolas Pitre
2012-05-15 8:54 ` [PATCH 2/8] arm: mach-armada: add source files Thomas Petazzoni
2012-05-15 9:12 ` Andrew Lunn
2012-05-15 9:17 ` Thomas Petazzoni
2012-05-15 9:54 ` Ben Dooks
2012-05-15 10:00 ` Arnaud Patard (Rtp)
2012-05-15 10:37 ` Ben Dooks
2012-05-15 9:27 ` Andrew Lunn
2012-05-15 9:54 ` Ben Dooks
2012-05-15 12:46 ` Lior Amsalem
2012-05-15 9:46 ` Ben Dooks
2012-05-15 9:59 ` Gregory CLEMENT
2012-05-15 10:03 ` Andrew Lunn
2012-05-19 6:21 ` Grant Likely
2012-05-16 14:27 ` Ben Dooks
2012-05-16 15:06 ` Ben Dooks
2012-05-15 8:54 ` [PATCH 3/8] arm: mach-armada: add documentation for new device tree bindings Thomas Petazzoni
2012-05-15 11:31 ` Ben Dooks
2012-05-15 8:54 ` [PATCH 4/8] arm: mach-armada: add compilation/configuration changes Thomas Petazzoni
2012-05-15 8:54 ` [PATCH 5/8] arm: mach-armada: add support for Armada 370 board with device tree Thomas Petazzoni
2012-05-15 8:54 ` [PATCH 6/8] arm: mach-armada: add support for Armada XP " Thomas Petazzoni
2012-05-15 9:58 ` Ben Dooks
2012-05-15 13:10 ` Lior Amsalem
2012-05-15 13:19 ` Andrew Lunn
2012-05-15 14:23 ` Arnd Bergmann
2012-05-15 18:37 ` Nicolas Pitre
2012-05-17 23:31 ` Jason Cooper
2012-05-15 13:33 ` Ben Dooks
2012-05-15 13:31 ` Rob Herring
2012-05-15 13:53 ` Ben Dooks
2012-05-15 14:16 ` Thomas Petazzoni
2012-05-15 14:25 ` Arnd Bergmann
2012-05-15 14:29 ` Thomas Petazzoni
2012-05-15 14:35 ` Ben Dooks
2012-05-15 14:53 ` Rob Herring
2012-05-15 15:01 ` Ben Dooks
2012-05-15 15:30 ` Russell King - ARM Linux
2012-05-15 14:32 ` Ben Dooks
2012-05-15 14:37 ` Arnd Bergmann
2012-05-15 16:31 ` Stephen Warren
2012-05-15 19:41 ` Arnd Bergmann
2012-05-15 14:58 ` Thomas Petazzoni
2012-05-15 15:07 ` Ben Dooks
2012-05-15 15:32 ` Arnd Bergmann
2012-05-15 15:46 ` Thomas Petazzoni
2012-05-15 21:22 ` Rob Herring
2012-05-15 15:49 ` Ben Dooks
2012-05-15 19:06 ` Arnd Bergmann
2012-05-15 15:41 ` Russell King - ARM Linux
2012-05-15 15:59 ` Ben Dooks
2012-05-15 16:03 ` Russell King - ARM Linux
2012-05-17 23:35 ` Jason Cooper
2012-05-18 2:12 ` Rob Herring
2012-05-22 12:00 ` Ben Dooks
2012-05-22 13:34 ` Jason Cooper
2012-05-22 17:06 ` Arnd Bergmann
2012-05-23 2:02 ` Haojian Zhuang
2012-05-15 8:54 ` [PATCH 7/8] arm: mach-armada: add defconfig Thomas Petazzoni
2012-05-15 9:58 ` Ben Dooks
2012-05-15 12:54 ` Thomas Petazzoni
2012-05-15 8:54 ` [PATCH 8/8] arm: mach-armada: add entry to MAINTAINERS Thomas Petazzoni
2012-05-15 9:18 ` [PATCH] arm: Add basic support for new Marvell Armada SoC family Andrew Lunn
2012-05-15 9:44 ` Thomas Petazzoni
2012-05-15 9:51 ` Ben Dooks
2012-05-15 9:55 ` Thomas Petazzoni
2012-05-15 13:15 ` Andrew Lunn
2012-05-15 14:35 ` Rob Herring
2012-05-15 14:44 ` Thomas Petazzoni
2012-05-15 15:27 ` Arnd Bergmann
2012-05-15 15:39 ` Thomas Petazzoni
2012-05-15 16:26 ` Arnd Bergmann
2012-05-15 21:35 ` Arnd Bergmann
2012-05-16 0:25 ` Nicolas Pitre
2012-05-16 5:07 ` Andrew Lunn
2012-05-16 6:57 ` Arnd Bergmann
2012-05-16 6:57 ` Haojian Zhuang
2012-05-16 17:30 ` Andrew Lunn
2012-05-15 18:20 ` Nicolas Pitre
2012-05-15 16:22 ` Andrew Lunn
2012-05-15 16:25 ` Ben Dooks
2012-05-15 16:30 ` Andrew Lunn
2012-05-15 16:37 ` Ben Dooks
2012-05-16 11:12 ` Lior Amsalem
2012-05-16 11:36 ` Andrew Lunn
2012-05-16 12:00 ` Arnd Bergmann
2012-05-16 14:55 ` Lior Amsalem
2012-05-16 15:20 ` Nicolas Pitre
2012-05-16 15:28 ` Arnd Bergmann
2012-05-16 16:49 ` Nicolas Pitre
2012-05-16 19:46 ` Arnd Bergmann
2012-05-16 20:20 ` Nicolas Pitre
2012-05-16 20:34 ` Arnd Bergmann
2012-05-18 19:20 ` Jason Cooper
2012-05-22 12:03 ` Ben Dooks
2012-05-18 19:18 ` Jason Cooper
2012-05-18 20:44 ` Arnd Bergmann
2012-05-18 22:51 ` Nicolas Pitre
2012-05-19 11:24 ` Jason Cooper
2012-05-19 17:32 ` Arnd Bergmann
2012-05-20 0:45 ` Nicolas Pitre
2012-05-20 9:55 ` Russell King - ARM Linux
2012-05-20 10:58 ` Arnd Bergmann
2012-05-20 11:10 ` Russell King - ARM Linux
2012-05-21 1:30 ` Jason Cooper
2012-05-21 7:58 ` Arnd Bergmann
2012-05-21 9:30 ` Russell King - ARM Linux
2012-05-21 15:35 ` Jason Cooper
2012-05-21 16:11 ` Russell King - ARM Linux
2012-05-21 16:58 ` Jason Cooper
2012-05-21 19:40 ` Arnd Bergmann
2012-05-22 14:25 ` Nicolas Pitre
2012-05-22 16:03 ` Jason Cooper
2012-05-22 16:06 ` Ben Dooks
2012-05-22 16:16 ` Jason Cooper
2012-05-24 11:18 ` Ben Dooks
2012-05-22 17:09 ` Arnd Bergmann
2012-05-21 8:55 ` Ben Dooks
2012-05-21 9:16 ` Andrew Lunn
2012-05-21 9:27 ` Ben Dooks
2012-05-21 9:40 ` Andrew Lunn
2012-05-21 15:39 ` Jason Cooper
2012-05-21 17:27 ` Andrew Lunn
2012-05-15 11:06 ` Arnd Bergmann
2012-05-15 12:50 ` Thomas Petazzoni
2012-05-15 16:03 ` Ben Dooks
2012-05-15 11:18 ` Ben Dooks
2012-05-15 12:26 ` Lior Amsalem
2012-05-15 12:51 ` Thomas Petazzoni
2012-05-15 11:20 ` Ben Dooks
2012-05-15 12:29 ` Lior Amsalem
2012-05-15 14:55 ` Ben Dooks
2012-05-15 15:00 ` Thomas Petazzoni
2012-05-15 15:07 ` Ben Dooks
2012-05-15 15:36 ` Ben Dooks
2012-05-15 15:39 ` Thomas Petazzoni
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.