arm: Add basic support for new Marvell Armada SoC family
Subsystems (16)
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Arnd, Olof,
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the arch/arm/mach-armada/ directory.
At the moment, both the Armada 370 and the Armada XP SoCs are supported in this directory, and we are able to build a single kernel image that boots on both SoCs. Both SoCs use the PJ4B processor, a Marvell-developed ARM core that implements the ARMv7 instruction set. We are currently using Marvell evaluation boards for both of those SoCs, and the support for those boards is added in this patch set.
This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:
Documentation/devicetree/bindings/arm/armada-mpic.txt | 23 + Documentation/devicetree/bindings/arm/armada-timer.txt | 11 Documentation/devicetree/bindings/arm/armada.txt | 24 + MAINTAINERS | 8 arch/arm/Kconfig | 12 arch/arm/Makefile | 1 arch/arm/boot/dts/a370-db.dts | 41 ++ arch/arm/boot/dts/a370.dtsi | 23 + arch/arm/boot/dts/armada.dtsi | 67 ++++ arch/arm/boot/dts/axp-db.dts | 40 ++ arch/arm/boot/dts/axp.dtsi | 43 +++ arch/arm/configs/armada_defconfig | 47 +++ arch/arm/mach-armada/Kconfig | 19 + arch/arm/mach-armada/Makefile | 3 arch/arm/mach-armada/Makefile.boot | 1 arch/arm/mach-armada/a370-dt.c | 41 ++ arch/arm/mach-armada/axp-dt.c | 41 ++ arch/arm/mach-armada/common.c | 56 +++ arch/arm/mach-armada/common.h | 27 + arch/arm/mach-armada/include/mach/armada.h | 234 ++++++++++++++++ arch/arm/mach-armada/include/mach/bridge-regs.h | 28 + arch/arm/mach-armada/include/mach/debug-macro.S | 23 + arch/arm/mach-armada/include/mach/gpio.h | 13 arch/arm/mach-armada/include/mach/hardware.h | 18 + arch/arm/mach-armada/include/mach/io.h | 24 + arch/arm/mach-armada/include/mach/irqs.h | 96 ++++++ arch/arm/mach-armada/include/mach/system.h | 21 + arch/arm/mach-armada/include/mach/timex.h | 13 arch/arm/mach-armada/include/mach/uncompress.h | 41 ++ arch/arm/mach-armada/irq.c | 116 ++++++++ arch/arm/mach-armada/time.c | 243 +++++++++++++++++ 31 files changed, 1398 insertions(+)
This patch set, and the support for those SoCs, is at the moment a collaborative effort from Marvell engineers (who have done the initial development work) and Free Electrons engineers (who are reshaping the code for mainline submission, adding device tree support, etc.). Other contributors are expected to join this effort.
The patch set is based on your arm-soc/for-next branch.
We intend to quickly build on top of this initial support with the following elements:
* Usage of the clock framework
* Usage the pinctrl subsystem and GPIO subsystems for pin-muxing and GPIO support
* SMP support
* L2 cache support
* Integration with device drivers. Many of the IPs used in these Marvell SoCs are similar to the ones used in previous Marvell SoCs (for SATA, USB and more), but the drivers for those IPs will require modification to add a device tree binding.
Of course, we welcome all comments on this initial submission and are ready to quickly submit updated versions of the patch set to take into those comments.
Best regards,
Thomas Petazzoni
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/8 arm: mach-armada: add headers
From: Gregory CLEMENT <[email protected]>
This patch adds basic header files for Armada SoCs.
--- arch/arm/mach-armada/include/mach/armada.h | 234 +++++++++++++++++++++++ arch/arm/mach-armada/include/mach/bridge-regs.h | 28 +++ arch/arm/mach-armada/include/mach/debug-macro.S | 23 +++ arch/arm/mach-armada/include/mach/gpio.h | 13 ++ arch/arm/mach-armada/include/mach/hardware.h | 18 ++ arch/arm/mach-armada/include/mach/io.h | 24 +++ arch/arm/mach-armada/include/mach/irqs.h | 96 ++++++++++ arch/arm/mach-armada/include/mach/system.h | 21 ++ arch/arm/mach-armada/include/mach/timex.h | 13 ++ arch/arm/mach-armada/include/mach/uncompress.h | 41 ++++ 10 files changed, 511 insertions(+) create mode 100644 arch/arm/mach-armada/include/mach/armada.h create mode 100644 arch/arm/mach-armada/include/mach/bridge-regs.h create mode 100644 arch/arm/mach-armada/include/mach/debug-macro.S create mode 100644 arch/arm/mach-armada/include/mach/gpio.h create mode 100644 arch/arm/mach-armada/include/mach/hardware.h create mode 100644 arch/arm/mach-armada/include/mach/io.h create mode 100644 arch/arm/mach-armada/include/mach/irqs.h create mode 100644 arch/arm/mach-armada/include/mach/system.h create mode 100644 arch/arm/mach-armada/include/mach/timex.h create mode 100644 arch/arm/mach-armada/include/mach/uncompress.h
arch/arm/mach-armada/include/mach/armada.h new file +234 -0
@@ -0,0 +1,234 @@ +/* +* Generic definitions for Marvell Armada SoCs +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* Gregory CLEMENT <[email protected]> +* Thomas Petazzoni <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __MACH_ARMADA_H +#define __MACH_ARMADA_H + +/* +* Marvell ARMADA address maps. +* +* phys virt size +* d0000000 feb00000 1M internal registers +* d0100000 @runtime 1M uart +* d0200000 fec00000 1M PCIe-0 I/O (port 0.0) +* d0300000 fed00000 1M PCIe-1 I/O (port 1.0) +* d0400000 fee00000 1M PCIe-2 I/O (port 2.0) +* d0500000 fef00000 1M PCIe-3 I/O (port 3.0) +* d0600000 @runtime 1M cryptographic sram-0 +* d0700000 @runtime 1M cryptographic sram-1 +* d0800000 reserved 8M reserved for future +* d1000000 @runtime 16M device bus cs-0 +* d2000000 @runtime 16M device bus cs-0 +* d3000000 @runtime 16M device bus cs-0 +* d4000000 @runtime 16M device bus cs-0 +* d5000000 @runtime 16M device bus boot cs +* d6000000 @runtime 16M spi-0 flash +* d7000000 @runtime 16M spi-1 flash +* d8000000 @runtime 64M PCIe-0 Memory (port 0.0) +* dc000000 @runtime 64M PCIe-1 Memory (port 1.0) +* e0000000 @runtime 64M PCIe-2 Memory (port 2.0) +* e4000000 @runtime 64M PCIe-3 Memory (port 3.0) +* fff00000 @runtime 1M internal bootrom +*/ + +#define ARMADA_REGS_PHYS_BASE 0xd0000000 +#define ARMADA_REGS_VIRT_BASE 0xfeb00000 +#define ARMADA_REGS_SIZE SZ_1M + +#define ARMADA_UART_REGS_BASE 0xd0100000 +#define ARMADA_UART_SIZE _1M + +#define ARMADA_PCIE0_IO_PHYS_BASE 0xd0200000 +#define ARMADA_PCIE0_IO_VIRT_BASE 0xfec00000 +#define ARMADA_PCIE0_IO_BUS_BASE 0x00100000 +#define ARMADA_PCIE0_IO_SIZE SZ_1M + +#define ARMADA_PCIE1_IO_PHYS_BASE 0xd0300000 +#define ARMADA_PCIE1_IO_VIRT_BASE 0xfed00000 +#define ARMADA_PCIE1_IO_BUS_BASE 0x00200000 +#define ARMADA_PCIE1_IO_SIZE SZ_1M + +#define ARMADA_PCIE2_IO_PHYS_BASE 0xd0400000 +#define ARMADA_PCIE2_IO_VIRT_BASE 0xfee00000 +#define ARMADA_PCIE2_IO_BUS_BASE 0x00300000 +#define ARMADA_PCIE2_IO_SIZE SZ_1M + +#define ARMADA_PCIE3_IO_PHYS_BASE 0xd0500000 +#define ARMADA_PCIE3_IO_VIRT_BASE 0xfef00000 +#define ARMADA_PCIE3_IO_BUS_BASE 0x00400000 +#define ARMADA_PCIE3_IO_SIZE SZ_1M + +#define ARMADA_CESA0_PHYS_BASE 0xd0600000 +#define ARMADA_CESA0_SIZE SZ_1M + +#define ARMADA_CESA1_PHYS_BASE 0xd0700000 +#define ARMADA_CESA1_SIZE SZ_1M + +#define ARMADA_DEVICE_CS0_PHYS_BASE 0xd1000000 +#define ARMADA_DEVICE_CS0_SIZE SZ_16M + +#define ARMADA_DEVICE_CS1_PHYS_BASE 0xd2000000 +#define ARMADA_DEVICE_CS1_SIZE SZ_16M + +#define ARMADA_DEVICE_CS2_PHYS_BASE 0xd3000000 +#define ARMADA_DEVICE_CS2_SIZE SZ_16M + +#define ARMADA_DEVICE_CS3_PHYS_BASE 0xd4000000 +#define ARMADA_DEVICE_CS3_SIZE SZ_16M + +#define ARMADA_DEVICE_BOOT_CS_PHYS_BASE 0xd5000000 +#define ARMADA_DEVICE_BOOT_CS_SIZE SZ_16M + +#define ARMADA_SPI0_CS0_PHYS_BASE 0xd6000000 +#define ARMADA_SPI0_CS0_SIZE SZ_16M + +#define ARMADA_SPI1_CS0_PHYS_BASE 0xd7000000 +#define ARMADA_SPI1_CS0_SIZE SZ_16M + +#define ARMADA_PCIE0_MEM_PHYS_BASE 0xd8000000 +#define ARMADA_PCIE0_MEM_SIZE SZ_64M + +#define ARMADA_PCIE1_MEM_PHYS_BASE 0xdc000000 +#define ARMADA_PCIE1_MEM_SIZE SZ_64M + +#define ARMADA_PCIE2_MEM_PHYS_BASE 0xe0000000 +#define ARMADA_PCIE2_MEM_SIZE SZ_64M + +#define ARMADA_PCIE3_MEM_PHYS_BASE 0xe4000000 +#define ARMADA_PCIE3_MEM_SIZE SZ_64M + +#define ARMADA_BOOTROM_PHYS_BASE 0xFFF00000 +#define ARMADA_BOOTROM_SIZE SZ_1M + +/* +* Core Registers Map +*/ + +/* DRAM */ +#define ARMADA_DRAM_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x0) +#define ARMADA_DRAM_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x0) + +/* L2 Cache */ +#define ARMADA_L2_CACHE_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x8000) +#define ARMADA_L2_CACHE_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x8000) + +/* RTC */ +#define ARMADA_RTC_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10300) +#define ARMADA_RTC_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x10300) + +/* SPI */ +#define ARMADA_SPI0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10600) +#define ARMADA_SPI0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x10600) +#define ARMADA_SPI1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10680) +#define ARMADA_SPI1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x10680) + +/* I2C */ +#define ARMADA_I2C0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x11000) +#define ARMADA_I2C0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x11000) +#define ARMADA_I2C1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x11100) +#define ARMADA_I2C1_VIRT_BASE (ARMADA_REGS_PHYS_BASE | 0x11100) + +/* UART */ +#define ARMADA_UART0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x12000) +#define ARMADA_UART0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x12000) +#define ARMADA_UART1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x12100) +#define ARMADA_UART1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x12100) + +/* MPP (pin muxing) */ +#define ARMADA_MPP_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x18000) +#define ARMADA_MPP_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18000) + +/* GPIO */ +#define ARMADA_GPIO_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x18100) +#define ARMADA_GPIO_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18100) + +/* Misc registers */ +#define ARMADA_SYSTEM_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x18200) +#define ARMADA_SYSTEM_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18200) + +/* CPU */ +#define ARMADA_CPU_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x20000) +#define ARMADA_CPU_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x20000) + +/* Audio */ +#define ARMADA_AUDIO_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x30000) +#define ARMADA_AUDIO_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x30000) + +/* PCIe */ +#define ARMADA_PCIE0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x40000) +#define ARMADA_PCIE0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x40000) +#define ARMADA_PCIE1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x80000) +#define ARMADA_PCIE1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x80000) +#define ARMADA_PCIE2_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x42000) +#define ARMADA_PCIE2_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x42000) +#define ARMADA_PCIE3_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x82000) +#define ARMADA_PCIE3_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x82000) + +/* USB */ +#define ARMADA_USB0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x50000) +#define ARMADA_USB0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x50000) +#define ARMADA_USB1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x51000) +#define ARMADA_USB1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x51000) + +/* XOR Engines */ +#define ARMADA_XOR0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x60900) +#define ARMADA_XOR0_HIGH_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x60B00) +#define ARMADA_XOR1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xF0900) +#define ARMADA_XOR1_HIGH_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xF0B00) + +/* Cryptographic Engine */ +#define ARMADA_CRYPT_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x30000) + +/* Gigabit Ethernet */ +#define ARMADA_GE00_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x70000) +#define ARMADA_GE01_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x74000) +#define ARMADA_GE10_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x30000) +#define ARMADA_GE11_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x34000) + +/* SDIO */ +#define ARMADA_SDIO0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x92000) + +/* SATA */ +#define ARMADA_SATA_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xa0000) + +/* NAND Flash Controller */ +#define ARMADA_NFC_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xd0000) + +/* MPP, GPIO, Reset Sampling */ +#define ARMADA_MPP_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18000) +#define ARMADA_GPIO0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18100) +#define ARMADA_GPIO1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18140) +#define ARMADA_GPIO2_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18180) + +/* Power Management */ +#define ARMADA_PMU_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x1c000) + +/* Real Time Clock */ +#define ARMADA_RTC_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10300) + +/* Memory Controller */ +#define ARMADA_MC_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x20180) + +/* Timers */ +#define ARMADA_TIMER_VIRT_BASE (ARMADA_CPU_VIRT_BASE | 0x0300) +#define ARMADA_TIMERS_INT_TIMER1_CLR (~0x0100) +#define TIMER_VIRT_BASE ARMADA_TIMER_VIRT_BASE + +/* Main Interrupt Controller Control and Configuration */ +#define ARMADA_MAIN_INT_CNTL_BASE (ARMADA_CPU_VIRT_BASE | 0x0) + +/* Per CPU Interrupt Controller Control and Configuration */ +#define ARMADA_PER_CPU_INT_CNTL_BASE (ARMADA_CPU_VIRT_BASE | 0x1000) + +#endif /* __MACH_ARMADA_H */
arch/arm/mach-armada/include/mach/bridge-regs.h new file +28 -0
@@ -0,0 +1,28 @@ +/* +* Mbus-L to Mbus Bridge Registers +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* Gregory CLEMENT <[email protected]> +* Thomas Petazzoni <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_BRIDGE_REGS_H +#define __ASM_ARCH_BRIDGE_REGS_H + +#include <mach/armada.h> + +#define RSTOUTn_MASK (ARMADA_SYSTEM_VIRT_BASE | 0x60) +#define SOFT_RESET_OUT_EN 0x00000001 + +#define SYSTEM_SOFT_RESET (ARMADA_SYSTEM_VIRT_BASE | 0x64) +#define SOFT_RESET 0x00000001 + +#define SOC_ID (ARMADA_MISC_VIRT_BASE | 0x3C) + +#endif
arch/arm/mach-armada/include/mach/debug-macro.S new file +23 -0
@@ -0,0 +1,23 @@ +/* + * Early serial output macro for Marvell Armada SoC + * + * Copyright (C) 2012 Marvell + * + * Lior Amsalem <[email protected]> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include <mach/armada.h> + + .macro addruart, rp, rv, tmp + ldr \rp, =ARMADA_REGS_PHYS_BASE + ldr \rv, =ARMADA_REGS_VIRT_BASE + orr \rp, \rp, #0x00012000 + orr \rv, \rv, #0x00012000 + .endm + +#define UART_SHIFT 2 +#include <asm/hardware/debug-8250.S>
arch/arm/mach-armada/include/mach/gpio.h new file +13 -0
@@ -0,0 +1,13 @@ +/* +* Marvell Armada SoC GPIO definitions +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <plat/gpio.h>
arch/arm/mach-armada/include/mach/hardware.h new file +18 -0
@@ -0,0 +1,18 @@ +/* +* Marvell Armada SoC hardware definitions +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_HARDWARE_H +#define __ASM_ARCH_HARDWARE_H + +#include <mach/armada.h> + +#endif
arch/arm/mach-armada/include/mach/io.h new file +24 -0
@@ -0,0 +1,24 @@ +/* +* Basic I/O macros +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_IO_H +#define __ASM_ARCH_IO_H + +#include <mach/armada.h> + +#define IO_SPACE_LIMIT 0xffffffff + +#define __io (a) ((void __iomem *)(((a) - ARMADA_PCIE0_IO_BUS_BASE) + \ + ARMADA_PCIE0_IO_VIRT_BASE)) +#define __mem_pci (a) (a) + +#endif
arch/arm/mach-armada/include/mach/irqs.h new file +96 -0
96 lines not on this page · raw message
arch/arm/mach-armada/include/mach/system.h new file +21 -0
@@ -0,0 +1,21 @@ +/* +* Marvell Armada SoC system defines +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_SYSTEM_H +#define __ASM_ARCH_SYSTEM_H + +static inline void arch_idle (void ) +{ +cpu_do_idle (); +} + +#endif
arch/arm/mach-armada/include/mach/timex.h new file +13 -0
@@ -0,0 +1,13 @@ +/* +* Marvell Armada SoC time definitions +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#define CLOCK_TICK_RATE (100 * HZ)
arch/arm/mach-armada/include/mach/uncompress.h new file +41 -0
41 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH 1/8 arm: mach-armada: add headers
Quoted 247 lines · Thomas Petazzoni
From: Gregory CLEMENT <[email protected]>
This patch adds basic header files for Armada SoCs.
Signed-off-by Gregory CLEMENT <[email protected]>Signed-off-by Thomas Petazzoni <[email protected]>Signed-off-by Lior Amsalem <[email protected]>--- 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.harch/arm/mach-armada/include/mach/armada.h new file +211
-0@@ -0,0 +1,234 @@ +/* +* Generic definitions for Marvell Armada SoCs +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* Gregory CLEMENT <[email protected]> +* Thomas Petazzoni <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __MACH_ARMADA_H +#define __MACH_ARMADA_H + +/* +* Marvell ARMADA address maps. +* +* phys virt size +* d0000000 feb00000 1M internal registers +* d0100000 @runtime 1M uart +* d0200000 fec00000 1M PCIe-0 I/O (port 0.0) +* d0300000 fed00000 1M PCIe-1 I/O (port 1.0) +* d0400000 fee00000 1M PCIe-2 I/O (port 2.0) +* d0500000 fef00000 1M PCIe-3 I/O (port 3.0) +* d0600000 @runtime 1M cryptographic sram-0 +* d0700000 @runtime 1M cryptographic sram-1 +* d0800000 reserved 8M reserved for future +* d1000000 @runtime 16M device bus cs-0 +* d2000000 @runtime 16M device bus cs-0 +* d3000000 @runtime 16M device bus cs-0 +* d4000000 @runtime 16M device bus cs-0 +* d5000000 @runtime 16M device bus boot cs +* d6000000 @runtime 16M spi-0 flash +* d7000000 @runtime 16M spi-1 flash +* d8000000 @runtime 64M PCIe-0 Memory (port 0.0) +* dc000000 @runtime 64M PCIe-1 Memory (port 1.0) +* e0000000 @runtime 64M PCIe-2 Memory (port 2.0) +* e4000000 @runtime 64M PCIe-3 Memory (port 3.0) +* fff00000 @runtime 1M internal bootrom +*/ + +#define ARMADA_REGS_PHYS_BASE 0xd0000000 +#define ARMADA_REGS_VIRT_BASE 0xfeb00000 +#define ARMADA_REGS_SIZE SZ_1M + +#define ARMADA_UART_REGS_BASE 0xd0100000 +#define ARMADA_UART_SIZE _1M + +#define ARMADA_PCIE0_IO_PHYS_BASE 0xd0200000 +#define ARMADA_PCIE0_IO_VIRT_BASE 0xfec00000 +#define ARMADA_PCIE0_IO_BUS_BASE 0x00100000 +#define ARMADA_PCIE0_IO_SIZE SZ_1M + +#define ARMADA_PCIE1_IO_PHYS_BASE 0xd0300000 +#define ARMADA_PCIE1_IO_VIRT_BASE 0xfed00000 +#define ARMADA_PCIE1_IO_BUS_BASE 0x00200000 +#define ARMADA_PCIE1_IO_SIZE SZ_1M + +#define ARMADA_PCIE2_IO_PHYS_BASE 0xd0400000 +#define ARMADA_PCIE2_IO_VIRT_BASE 0xfee00000 +#define ARMADA_PCIE2_IO_BUS_BASE 0x00300000 +#define ARMADA_PCIE2_IO_SIZE SZ_1M + +#define ARMADA_PCIE3_IO_PHYS_BASE 0xd0500000 +#define ARMADA_PCIE3_IO_VIRT_BASE 0xfef00000 +#define ARMADA_PCIE3_IO_BUS_BASE 0x00400000 +#define ARMADA_PCIE3_IO_SIZE SZ_1M + +#define ARMADA_CESA0_PHYS_BASE 0xd0600000 +#define ARMADA_CESA0_SIZE SZ_1M + +#define ARMADA_CESA1_PHYS_BASE 0xd0700000 +#define ARMADA_CESA1_SIZE SZ_1M + +#define ARMADA_DEVICE_CS0_PHYS_BASE 0xd1000000 +#define ARMADA_DEVICE_CS0_SIZE SZ_16M + +#define ARMADA_DEVICE_CS1_PHYS_BASE 0xd2000000 +#define ARMADA_DEVICE_CS1_SIZE SZ_16M + +#define ARMADA_DEVICE_CS2_PHYS_BASE 0xd3000000 +#define ARMADA_DEVICE_CS2_SIZE SZ_16M + +#define ARMADA_DEVICE_CS3_PHYS_BASE 0xd4000000 +#define ARMADA_DEVICE_CS3_SIZE SZ_16M + +#define ARMADA_DEVICE_BOOT_CS_PHYS_BASE 0xd5000000 +#define ARMADA_DEVICE_BOOT_CS_SIZE SZ_16M + +#define ARMADA_SPI0_CS0_PHYS_BASE 0xd6000000 +#define ARMADA_SPI0_CS0_SIZE SZ_16M + +#define ARMADA_SPI1_CS0_PHYS_BASE 0xd7000000 +#define ARMADA_SPI1_CS0_SIZE SZ_16M + +#define ARMADA_PCIE0_MEM_PHYS_BASE 0xd8000000 +#define ARMADA_PCIE0_MEM_SIZE SZ_64M + +#define ARMADA_PCIE1_MEM_PHYS_BASE 0xdc000000 +#define ARMADA_PCIE1_MEM_SIZE SZ_64M + +#define ARMADA_PCIE2_MEM_PHYS_BASE 0xe0000000 +#define ARMADA_PCIE2_MEM_SIZE SZ_64M + +#define ARMADA_PCIE3_MEM_PHYS_BASE 0xe4000000 +#define ARMADA_PCIE3_MEM_SIZE SZ_64M + +#define ARMADA_BOOTROM_PHYS_BASE 0xFFF00000 +#define ARMADA_BOOTROM_SIZE SZ_1M + +/* +* Core Registers Map +*/ + +/* DRAM */ +#define ARMADA_DRAM_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x0) +#define ARMADA_DRAM_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x0) + +/* L2 Cache */ +#define ARMADA_L2_CACHE_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x8000) +#define ARMADA_L2_CACHE_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x8000) + +/* RTC */ +#define ARMADA_RTC_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10300) +#define ARMADA_RTC_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x10300) + +/* SPI */ +#define ARMADA_SPI0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10600) +#define ARMADA_SPI0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x10600) +#define ARMADA_SPI1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10680) +#define ARMADA_SPI1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x10680) + +/* I2C */ +#define ARMADA_I2C0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x11000) +#define ARMADA_I2C0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x11000) +#define ARMADA_I2C1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x11100) +#define ARMADA_I2C1_VIRT_BASE (ARMADA_REGS_PHYS_BASE | 0x11100) + +/* UART */ +#define ARMADA_UART0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x12000) +#define ARMADA_UART0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x12000) +#define ARMADA_UART1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x12100) +#define ARMADA_UART1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x12100) + +/* MPP (pin muxing) */ +#define ARMADA_MPP_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x18000) +#define ARMADA_MPP_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18000) + +/* GPIO */ +#define ARMADA_GPIO_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x18100) +#define ARMADA_GPIO_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18100) + +/* Misc registers */ +#define ARMADA_SYSTEM_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x18200) +#define ARMADA_SYSTEM_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18200) + +/* CPU */ +#define ARMADA_CPU_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x20000) +#define ARMADA_CPU_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x20000) + +/* Audio */ +#define ARMADA_AUDIO_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x30000) +#define ARMADA_AUDIO_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x30000) + +/* PCIe */ +#define ARMADA_PCIE0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x40000) +#define ARMADA_PCIE0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x40000) +#define ARMADA_PCIE1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x80000) +#define ARMADA_PCIE1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x80000) +#define ARMADA_PCIE2_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x42000) +#define ARMADA_PCIE2_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x42000) +#define ARMADA_PCIE3_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x82000) +#define ARMADA_PCIE3_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x82000) + +/* USB */ +#define ARMADA_USB0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x50000) +#define ARMADA_USB0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x50000) +#define ARMADA_USB1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x51000) +#define ARMADA_USB1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x51000) + +/* XOR Engines */ +#define ARMADA_XOR0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x60900) +#define ARMADA_XOR0_HIGH_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x60B00) +#define ARMADA_XOR1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xF0900) +#define ARMADA_XOR1_HIGH_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xF0B00) + +/* Cryptographic Engine */ +#define ARMADA_CRYPT_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x30000) + +/* Gigabit Ethernet */ +#define ARMADA_GE00_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x70000) +#define ARMADA_GE01_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x74000) +#define ARMADA_GE10_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x30000) +#define ARMADA_GE11_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x34000) + +/* SDIO */ +#define ARMADA_SDIO0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x92000) + +/* SATA */ +#define ARMADA_SATA_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xa0000) + +/* NAND Flash Controller */ +#define ARMADA_NFC_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xd0000) + +/* MPP, GPIO, Reset Sampling */ +#define ARMADA_MPP_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18000) +#define ARMADA_GPIO0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18100) +#define ARMADA_GPIO1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18140)
arch/arm/mach-armada/include/mach/armada.h line 221
Quoted 10 lines
arch/arm/mach-armada/include/mach/armada.h new file +10
-0+#define ARMADA_GPIO2_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18180) + +/* Power Management */ +#define ARMADA_PMU_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x1c000) + +/* Real Time Clock */ +#define ARMADA_RTC_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10300) + +/* Memory Controller */ +#define ARMADA_MC_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x20180)
I would just delete most of these, either they'll come from the fdt or they won't be needed. There's far more here than is necessary to get the core up and my view is that these should be removed.
Quoted 49 lines
arch/arm/mach-armada/include/mach/bridge-regs.h new file +28
-0@@ -0,0 +1,28 @@ +/* +* Mbus-L to Mbus Bridge Registers +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* Gregory CLEMENT <[email protected]> +* Thomas Petazzoni <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_BRIDGE_REGS_H +#define __ASM_ARCH_BRIDGE_REGS_H + +#include <mach/armada.h> + +#define RSTOUTn_MASK (ARMADA_SYSTEM_VIRT_BASE | 0x60) +#define SOFT_RESET_OUT_EN 0x00000001 + +#define SYSTEM_SOFT_RESET (ARMADA_SYSTEM_VIRT_BASE | 0x64) +#define SOFT_RESET 0x00000001 + +#define SOC_ID (ARMADA_MISC_VIRT_BASE | 0x3C) + +#endif arch/arm/mach-armada/include/mach/debug-macro.S new file +9
-0@@ -0,0 +1,23 @@ +/* + * Early serial output macro for Marvell Armada SoC + * + * Copyright (C) 2012 Marvell + * + * Lior Amsalem <[email protected]> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as
arch/arm/mach-armada/include/mach/debug-macro.S line 19
Quoted 10 lines
arch/arm/mach-armada/include/mach/debug-macro.S new file +10
-0+ * published by the Free Software Foundation. +*/ + +#include <mach/armada.h> + + .macro addruart, rp, rv, tmp + ldr \rp, =ARMADA_REGS_PHYS_BASE + ldr \rv, =ARMADA_REGS_VIRT_BASE + orr \rp, \rp, #0x00012000 + orr \rv, \rv, #0x00012000
you could do \rp, =(ARMADA_REGS_PHYS_BASE | 0x00012000) and remove the second orr.
Quoted 37 lines
arch/arm/mach-armada/include/mach/debug-macro.S new file +4
-0+ .endm + +#define UART_SHIFT 2 +#include <asm/hardware/debug-8250.S>arch/arm/mach-armada/include/mach/gpio.h new file +13
-0@@ -0,0 +1,13 @@ +/* +* Marvell Armada SoC GPIO definitions +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <plat/gpio.h> arch/arm/mach-armada/include/mach/hardware.h new file +8
-0@@ -0,0 +1,18 @@ +/* +* Marvell Armada SoC hardware definitions +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public
arch/arm/mach-armada/include/mach/hardware.h line 18
Quoted 10 lines
arch/arm/mach-armada/include/mach/hardware.h new file +10
-0+* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_HARDWARE_H +#define __ASM_ARCH_HARDWARE_H + +#include <mach/armada.h> + +#endif
thought this was going away.
Quoted 122 lines
arch/arm/mach-armada/include/mach/io.h new file +24
-0@@ -0,0 +1,24 @@ +/* +* Basic I/O macros +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_IO_H +#define __ASM_ARCH_IO_H + +#include <mach/armada.h> + +#define IO_SPACE_LIMIT 0xffffffff + +#define __io (a) ((void __iomem *)(((a) - ARMADA_PCIE0_IO_BUS_BASE) + \ + ARMADA_PCIE0_IO_VIRT_BASE)) +#define __mem_pci (a) (a) + +#endif arch/arm/mach-armada/include/mach/irqs.h new file +86
-0@@ -0,0 +1,96 @@ +/* +* IRQ definitions for Marvell Armada SoC +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_IRQS_H +#define __ASM_ARCH_IRQS_H + +/* +* Per-cpu Interrupts +*/ +#define IRQ_ARMADA_DRBL_LOW 0 +#define IRQ_ARMADA_DRBL_HI 1 +#define IRQ_ARMADA_DRBL_SUM 2 +#define IRQ_ARMADA_FABRIC 3 +#define IRQ_ARMADA_SOC_ERR 4 +#define IRQ_ARMADA_LCL_TIMER0 5 +#define IRQ_ARMADA_LCL_TIMER1 6 +#define IRQ_ARMADA_LCL_WD 7 +#define IRQ_ARMADA_GE0_TH_RXTX 8 +#define IRQ_ARMADA_GE0_RXTX 9 +#define IRQ_ARMADA_GE1_TH_RXTX 10 +#define IRQ_ARMADA_GE1_RXTX 11 +#define IRQ_ARMADA_GE2_TH_RXTX 12 +#define IRQ_ARMADA_GE2_RXTX 13 +#define IRQ_ARMADA_GE3_TH_RXTX 14 +#define IRQ_ARMADA_GE3_RXTX 15 + +/* +* Global interrupts +*/ +#define IRQ_ARMADA_LCD 29 +#define IRQ_ARMADA_SPI0 30 +#define IRQ_ARMADA_I2C0 31 +#define IRQ_ARMADA_I2C1 32 +#define IRQ_ARMADA_GLBL_TIMER0 37 +#define IRQ_ARMADA_GLBL_TIMER1 38 +#define IRQ_ARMADA_GLBL_TIMER2 39 +#define IRQ_ARMADA_GLBL_TIMER3 40 +#define IRQ_ARMADA_UART0 41 +#define IRQ_ARMADA_UART1 42 +#define IRQ_ARMADA_UART2 43 +#define IRQ_ARMADA_UART3 44 +#define IRQ_ARMADA_USB0 45 +#define IRQ_ARMADA_USB1 46 +#define IRQ_ARMADA_USB2 47 +#define IRQ_ARMADA_CESA0 48 +#define IRQ_ARMADA_CESA1 49 +#define IRQ_ARMADA_RTC 50 +#define IRQ_ARMADA_XOR0_CH0 51 +#define IRQ_ARMADA_XOR0_CH1 52 +#define IRQ_ARMADA_SDIO 54 +#define IRQ_ARMADA_SATA0 55 +#define IRQ_ARMADA_TDM 56 +#define IRQ_ARMADA_SATA1 57 +#define IRQ_ARMADA_PCIE0 61 +#define IRQ_ARMADA_PCIE1 62 +#define IRQ_ARMADA_GPIO_0_7 82 +#define IRQ_ARMADA_GPIO_8_15 83 +#define IRQ_ARMADA_GPIO_16_23 84 +#define IRQ_ARMADA_GPIO_24_31 85 +#define IRQ_ARMADA_GPIO_32_39 87 +#define IRQ_ARMADA_GPIO_40_47 88 +#define IRQ_ARMADA_GPIO_48_55 89 +#define IRQ_ARMADA_GPIO_56_63 90 +#define IRQ_ARMADA_GPIO_64_66 91 +#define IRQ_ARMADA_SPI1 92 +#define IRQ_ARMADA_WD 93 +#define IRQ_ARMADA_XOR1_CH0 94 +#define IRQ_ARMADA_XOR1_CH1 95 +#define IRQ_ARMADA_PCIE2 99 +#define IRQ_ARMADA_PCIE3 103 +#define IRQ_ARMADA_DRAM 108 +#define IRQ_ARMADA_GE0_WKUP 109 +#define IRQ_ARMADA_GE1_WKUP 110 +#define IRQ_ARMADA_GE2_WKUP 111 +#define IRQ_ARMADA_GE3_WKUP 112 +#define IRQ_ARMADA_NFC 113 +
arch/arm/mach-armada/include/mach/irqs.h line 96
Quoted 10 lines
arch/arm/mach-armada/include/mach/irqs.h new file +10
-0+/* +* ARMADA General Purpose Pins +*/ +#define IRQ_ARMADA_GPIO_START 82 +#define NR_GPIO_IRQS 64 + +#define NR_IRQS (115) + + +#endif
I'm going to go with the same comment as before, why do we have all these defines sitting here when I expect they'll never be used.
arch/arm/mach-armad
Quoted 1 line
arch/arm/mach-armad renamed from arch/arm/mach-armada/include/mach/system.h +0
-0
a/include/mach/system.h
Quoted 57 lines
new file mode 100644
index 0000000..f920ef0arch/arm/mach-armada/include/mach/system.h new file +21
-0@@ -0,0 +1,21 @@ +/* +* Marvell Armada SoC system defines +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_SYSTEM_H +#define __ASM_ARCH_SYSTEM_H + +static inline void arch_idle (void ) +{ +cpu_do_idle (); +} + +#endif arch/arm/mach-armada/include/mach/timex.h new file +13
-0@@ -0,0 +1,13 @@ +/* +* Marvell Armada SoC time definitions +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#define CLOCK_TICK_RATE (100 * HZ)arch/arm/mach-armada/include/mach/uncompress.h new file +6
-0@@ -0,0 +1,41 @@ +/* +* Marvell Armada SoC kernel uncompression UART routines +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]>
arch/arm/mach-armada/include/mach/uncompress.h line 16
Quoted 10 lines
arch/arm/mach-armada/include/mach/uncompress.h new file +10
-0+* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <mach/armada.h> + +#define UART_THR ((volatile unsigned char *)(ARMADA_UART0_PHYS_BASE + 0x0)) +#define UART_LSR ((volatile unsigned char *)(ARMADA_UART0_PHYS_BASE + 0x14))
you've used a different set of addresses for your debug-macro.S
arch/arm/mach-armada/include/mach/uncompress.h line 18
Quoted 1 line
arch/arm/mach-armada/include/mach/uncompress.h new file +1
-0+#define LSR_THRE 0x20
you could pull the <linux/serial_regs.h> in for these.
arch/arm/mach-armada/include/mach/uncompress.h line 28
Quoted 10 lines
arch/arm/mach-armada/include/mach/uncompress.h new file +10
-0+ +static void putc (const char c) +{ +int i; + +for (i =0 ; i <0x1000 ; i++) { +/* Transmit fifo not full? */ +if (*UART_LSR &LSR_THRE ) +break ; + }
is that really long enough to wait for a fast core like the AXP?
Quoted 16 lines
arch/arm/mach-armada/include/mach/uncompress.h new file +13
-0+ + *UART_THR = c; +} + +static void flush (void ) +{ +} + +/* +* nothing to do +*/ +#define arch_decomp_setup () +#define arch_decomp_wdog ()Signature · 1 line
1.7.9.5
Signature · 3 lines
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear.
PATCH 1/8 arm: mach-armada: add headers
Quoted 72 lines · Ben Dooks
Quoted 71 lines · Thomas Petazzoni
From: Gregory CLEMENT<[email protected]>
This patch adds basic header files for Armada SoCs.
Signed-off-by Gregory CLEMENT<[email protected]>Signed-off-by Thomas Petazzoni<[email protected]>Signed-off-by Lior Amsalem<[email protected]>--- 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.hcreate mode 100644arch/arm/mach-armada/include/mach/bridge-regs.hcreate mode 100644arch/arm/mach-armada/include/mach/debug-macro.Screate mode 100644arch/arm/mach-armada/include/mach/gpio.hcreate mode 100644arch/arm/mach-armada/include/mach/hardware.hcreate mode 100644arch/arm/mach-armada/include/mach/io.hcreate mode 100644arch/arm/mach-armada/include/mach/irqs.hcreate mode 100644arch/arm/mach-armada/include/mach/system.hcreate mode 100644arch/arm/mach-armada/include/mach/timex.hcreate mode 100644arch/arm/mach-armada/include/mach/uncompress.harch/arm/mach-armada/include/mach/armada.h new file +35
-0@@ -0,0 +1,234 @@ +/* +* Generic definitions for Marvell Armada SoCs +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __MACH_ARMADA_H +#define __MACH_ARMADA_H + +/* +* Marvell ARMADA address maps. +* +* phys virt size +* d0000000 feb00000 1M internal registers +* d0100000 @runtime 1M uart +* d0200000 fec00000 1M PCIe-0 I/O (port 0.0) +* d0300000 fed00000 1M PCIe-1 I/O (port 1.0) +* d0400000 fee00000 1M PCIe-2 I/O (port 2.0) +* d0500000 fef00000 1M PCIe-3 I/O (port 3.0) +* d0600000 @runtime 1M cryptographic sram-0 +* d0700000 @runtime 1M cryptographic sram-1 +* d0800000 reserved 8M reserved for future +* d1000000 @runtime 16M device bus cs-0 +* d2000000 @runtime 16M device bus cs-0 +* d3000000 @runtime 16M device bus cs-0 +* d4000000 @runtime 16M device bus cs-0 +* d5000000 @runtime 16M device bus boot cs
Quoted 8 lines
arch/arm/mach-armada/include/mach/armada.h line 43
Quoted 8 lines
arch/arm/mach-armada/include/mach/armada.h new file +8
-0+* d6000000 @runtime 16M spi-0 flash +* d7000000 @runtime 16M spi-1 flash +* d8000000 @runtime 64M PCIe-0 Memory (port 0.0) +* dc000000 @runtime 64M PCIe-1 Memory (port 1.0) +* e0000000 @runtime 64M PCIe-2 Memory (port 2.0) +* e4000000 @runtime 64M PCIe-3 Memory (port 3.0) +* fff00000 @runtime 1M internal bootrom +*/
I think these mappings are mostly un-necessary at initialisation time and secondly the support merged so far does not need most of these. I would say that the PCIe and SPI should be dynamically mapped when they are instantiated from the device tree.
Second comment, why do we have two sets of UART mappings, one from the internal registers and the second from its own phys space?
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/8 arm: mach-armada: add headers
In reply to Thomas PetazzoniQuoted 3 lines · Thomas Petazzoni
From: Gregory CLEMENT <[email protected]>
This patch adds basic header files for Armada SoCs.
The split of patch 1 and 2 doesn't really make sense.
Quoted 256 lines
Signed-off-by Gregory CLEMENT <[email protected]>Signed-off-by Thomas Petazzoni <[email protected]>Signed-off-by Lior Amsalem <[email protected]>--- 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.harch/arm/mach-armada/include/mach/armada.h new file +223
-0@@ -0,0 +1,234 @@ +/* +* Generic definitions for Marvell Armada SoCs +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* Gregory CLEMENT <[email protected]> +* Thomas Petazzoni <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __MACH_ARMADA_H +#define __MACH_ARMADA_H + +/* +* Marvell ARMADA address maps. +* +* phys virt size +* d0000000 feb00000 1M internal registers +* d0100000 @runtime 1M uart +* d0200000 fec00000 1M PCIe-0 I/O (port 0.0) +* d0300000 fed00000 1M PCIe-1 I/O (port 1.0) +* d0400000 fee00000 1M PCIe-2 I/O (port 2.0) +* d0500000 fef00000 1M PCIe-3 I/O (port 3.0) +* d0600000 @runtime 1M cryptographic sram-0 +* d0700000 @runtime 1M cryptographic sram-1 +* d0800000 reserved 8M reserved for future +* d1000000 @runtime 16M device bus cs-0 +* d2000000 @runtime 16M device bus cs-0 +* d3000000 @runtime 16M device bus cs-0 +* d4000000 @runtime 16M device bus cs-0 +* d5000000 @runtime 16M device bus boot cs +* d6000000 @runtime 16M spi-0 flash +* d7000000 @runtime 16M spi-1 flash +* d8000000 @runtime 64M PCIe-0 Memory (port 0.0) +* dc000000 @runtime 64M PCIe-1 Memory (port 1.0) +* e0000000 @runtime 64M PCIe-2 Memory (port 2.0) +* e4000000 @runtime 64M PCIe-3 Memory (port 3.0) +* fff00000 @runtime 1M internal bootrom +*/ + +#define ARMADA_REGS_PHYS_BASE 0xd0000000 +#define ARMADA_REGS_VIRT_BASE 0xfeb00000 +#define ARMADA_REGS_SIZE SZ_1M + +#define ARMADA_UART_REGS_BASE 0xd0100000 +#define ARMADA_UART_SIZE _1M + +#define ARMADA_PCIE0_IO_PHYS_BASE 0xd0200000 +#define ARMADA_PCIE0_IO_VIRT_BASE 0xfec00000 +#define ARMADA_PCIE0_IO_BUS_BASE 0x00100000 +#define ARMADA_PCIE0_IO_SIZE SZ_1M + +#define ARMADA_PCIE1_IO_PHYS_BASE 0xd0300000 +#define ARMADA_PCIE1_IO_VIRT_BASE 0xfed00000 +#define ARMADA_PCIE1_IO_BUS_BASE 0x00200000 +#define ARMADA_PCIE1_IO_SIZE SZ_1M + +#define ARMADA_PCIE2_IO_PHYS_BASE 0xd0400000 +#define ARMADA_PCIE2_IO_VIRT_BASE 0xfee00000 +#define ARMADA_PCIE2_IO_BUS_BASE 0x00300000 +#define ARMADA_PCIE2_IO_SIZE SZ_1M + +#define ARMADA_PCIE3_IO_PHYS_BASE 0xd0500000 +#define ARMADA_PCIE3_IO_VIRT_BASE 0xfef00000 +#define ARMADA_PCIE3_IO_BUS_BASE 0x00400000 +#define ARMADA_PCIE3_IO_SIZE SZ_1M + +#define ARMADA_CESA0_PHYS_BASE 0xd0600000 +#define ARMADA_CESA0_SIZE SZ_1M + +#define ARMADA_CESA1_PHYS_BASE 0xd0700000 +#define ARMADA_CESA1_SIZE SZ_1M + +#define ARMADA_DEVICE_CS0_PHYS_BASE 0xd1000000 +#define ARMADA_DEVICE_CS0_SIZE SZ_16M + +#define ARMADA_DEVICE_CS1_PHYS_BASE 0xd2000000 +#define ARMADA_DEVICE_CS1_SIZE SZ_16M + +#define ARMADA_DEVICE_CS2_PHYS_BASE 0xd3000000 +#define ARMADA_DEVICE_CS2_SIZE SZ_16M + +#define ARMADA_DEVICE_CS3_PHYS_BASE 0xd4000000 +#define ARMADA_DEVICE_CS3_SIZE SZ_16M + +#define ARMADA_DEVICE_BOOT_CS_PHYS_BASE 0xd5000000 +#define ARMADA_DEVICE_BOOT_CS_SIZE SZ_16M + +#define ARMADA_SPI0_CS0_PHYS_BASE 0xd6000000 +#define ARMADA_SPI0_CS0_SIZE SZ_16M + +#define ARMADA_SPI1_CS0_PHYS_BASE 0xd7000000 +#define ARMADA_SPI1_CS0_SIZE SZ_16M + +#define ARMADA_PCIE0_MEM_PHYS_BASE 0xd8000000 +#define ARMADA_PCIE0_MEM_SIZE SZ_64M + +#define ARMADA_PCIE1_MEM_PHYS_BASE 0xdc000000 +#define ARMADA_PCIE1_MEM_SIZE SZ_64M + +#define ARMADA_PCIE2_MEM_PHYS_BASE 0xe0000000 +#define ARMADA_PCIE2_MEM_SIZE SZ_64M + +#define ARMADA_PCIE3_MEM_PHYS_BASE 0xe4000000 +#define ARMADA_PCIE3_MEM_SIZE SZ_64M + +#define ARMADA_BOOTROM_PHYS_BASE 0xFFF00000 +#define ARMADA_BOOTROM_SIZE SZ_1M + +/* +* Core Registers Map +*/ + +/* DRAM */ +#define ARMADA_DRAM_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x0) +#define ARMADA_DRAM_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x0) + +/* L2 Cache */ +#define ARMADA_L2_CACHE_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x8000) +#define ARMADA_L2_CACHE_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x8000) + +/* RTC */ +#define ARMADA_RTC_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10300) +#define ARMADA_RTC_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x10300) + +/* SPI */ +#define ARMADA_SPI0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10600) +#define ARMADA_SPI0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x10600) +#define ARMADA_SPI1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10680) +#define ARMADA_SPI1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x10680) + +/* I2C */ +#define ARMADA_I2C0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x11000) +#define ARMADA_I2C0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x11000) +#define ARMADA_I2C1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x11100) +#define ARMADA_I2C1_VIRT_BASE (ARMADA_REGS_PHYS_BASE | 0x11100) + +/* UART */ +#define ARMADA_UART0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x12000) +#define ARMADA_UART0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x12000) +#define ARMADA_UART1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x12100) +#define ARMADA_UART1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x12100) + +/* MPP (pin muxing) */ +#define ARMADA_MPP_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x18000) +#define ARMADA_MPP_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18000) + +/* GPIO */ +#define ARMADA_GPIO_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x18100) +#define ARMADA_GPIO_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18100) + +/* Misc registers */ +#define ARMADA_SYSTEM_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x18200) +#define ARMADA_SYSTEM_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18200) + +/* CPU */ +#define ARMADA_CPU_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x20000) +#define ARMADA_CPU_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x20000) + +/* Audio */ +#define ARMADA_AUDIO_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x30000) +#define ARMADA_AUDIO_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x30000) + +/* PCIe */ +#define ARMADA_PCIE0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x40000) +#define ARMADA_PCIE0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x40000) +#define ARMADA_PCIE1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x80000) +#define ARMADA_PCIE1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x80000) +#define ARMADA_PCIE2_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x42000) +#define ARMADA_PCIE2_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x42000) +#define ARMADA_PCIE3_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x82000) +#define ARMADA_PCIE3_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x82000) + +/* USB */ +#define ARMADA_USB0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x50000) +#define ARMADA_USB0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x50000) +#define ARMADA_USB1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x51000) +#define ARMADA_USB1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x51000) + +/* XOR Engines */ +#define ARMADA_XOR0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x60900) +#define ARMADA_XOR0_HIGH_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x60B00) +#define ARMADA_XOR1_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xF0900) +#define ARMADA_XOR1_HIGH_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xF0B00) + +/* Cryptographic Engine */ +#define ARMADA_CRYPT_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x30000) + +/* Gigabit Ethernet */ +#define ARMADA_GE00_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x70000) +#define ARMADA_GE01_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x74000) +#define ARMADA_GE10_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x30000) +#define ARMADA_GE11_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x34000) + +/* SDIO */ +#define ARMADA_SDIO0_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x92000) + +/* SATA */ +#define ARMADA_SATA_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xa0000) + +/* NAND Flash Controller */ +#define ARMADA_NFC_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0xd0000) + +/* MPP, GPIO, Reset Sampling */ +#define ARMADA_MPP_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18000) +#define ARMADA_GPIO0_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18100) +#define ARMADA_GPIO1_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18140) +#define ARMADA_GPIO2_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x18180) + +/* Power Management */ +#define ARMADA_PMU_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x1c000) + +/* Real Time Clock */ +#define ARMADA_RTC_PHYS_BASE (ARMADA_REGS_PHYS_BASE | 0x10300) + +/* Memory Controller */ +#define ARMADA_MC_VIRT_BASE (ARMADA_REGS_VIRT_BASE | 0x20180) + +/* Timers */
arch/arm/mach-armada/include/mach/armada.h line 233
Quoted 10 lines
arch/arm/mach-armada/include/mach/armada.h new file +10
-0+#define ARMADA_TIMER_VIRT_BASE (ARMADA_CPU_VIRT_BASE | 0x0300) +#define ARMADA_TIMERS_INT_TIMER1_CLR (~0x0100) +#define TIMER_VIRT_BASE ARMADA_TIMER_VIRT_BASE + +/* Main Interrupt Controller Control and Configuration */ +#define ARMADA_MAIN_INT_CNTL_BASE (ARMADA_CPU_VIRT_BASE | 0x0) + +/* Per CPU Interrupt Controller Control and Configuration */ +#define ARMADA_PER_CPU_INT_CNTL_BASE (ARMADA_CPU_VIRT_BASE | 0x1000) +
As Ben pointed out, all this should come from DT.
Quoted 73 lines
arch/arm/mach-armada/include/mach/armada.h new file +1
-0+#endif /* __MACH_ARMADA_H */ arch/arm/mach-armada/include/mach/bridge-regs.h new file +28
-0@@ -0,0 +1,28 @@ +/* +* Mbus-L to Mbus Bridge Registers +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* Gregory CLEMENT <[email protected]> +* Thomas Petazzoni <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_BRIDGE_REGS_H +#define __ASM_ARCH_BRIDGE_REGS_H + +#include <mach/armada.h> + +#define RSTOUTn_MASK (ARMADA_SYSTEM_VIRT_BASE | 0x60) +#define SOFT_RESET_OUT_EN 0x00000001 + +#define SYSTEM_SOFT_RESET (ARMADA_SYSTEM_VIRT_BASE | 0x64) +#define SOFT_RESET 0x00000001 + +#define SOC_ID (ARMADA_MISC_VIRT_BASE | 0x3C) + +#endif arch/arm/mach-armada/include/mach/debug-macro.S new file +23
-0@@ -0,0 +1,23 @@ +/* + * Early serial output macro for Marvell Armada SoC + * + * Copyright (C) 2012 Marvell + * + * Lior Amsalem <[email protected]> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +#include <mach/armada.h> + + .macro addruart, rp, rv, tmp + ldr \rp, =ARMADA_REGS_PHYS_BASE + ldr \rv, =ARMADA_REGS_VIRT_BASE + orr \rp, \rp, #0x00012000 + orr \rv, \rv, #0x00012000 + .endm + +#define UART_SHIFT 2 +#include <asm/hardware/debug-8250.S>arch/arm/mach-armada/include/mach/gpio.h new file +3
-0@@ -0,0 +1,13 @@ +/* +* Marvell Armada SoC GPIO definitions +*
arch/arm/mach-armada/include/mach/gpio.h line 13
Quoted 10 lines
arch/arm/mach-armada/include/mach/gpio.h new file +10
-0+* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <plat/gpio.h>
New platforms should probably have empty gpio.h.
arch/arm/mach-armada/include/mach/hardware.h
Quoted 5 lines
arch/arm/mach-armada/include/mach/hardware.h new file +0
-0
You should not have a hardware.h. Include armada.h directly or ideally remove the need for it.
Quoted 33 lines
arch/arm/mach-armada/include/mach/hardware.h new file +18
-0@@ -0,0 +1,18 @@ +/* +* Marvell Armada SoC hardware definitions +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_HARDWARE_H +#define __ASM_ARCH_HARDWARE_H + +#include <mach/armada.h> + +#endif arch/arm/mach-armada/include/mach/io.h new file +8
-0@@ -0,0 +1,24 @@ +/* +* Basic I/O macros +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public
arch/arm/mach-armada/include/mach/io.h line 18
Quoted 10 lines
arch/arm/mach-armada/include/mach/io.h new file +10
-0+* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_IO_H +#define __ASM_ARCH_IO_H + +#include <mach/armada.h> + +#define IO_SPACE_LIMIT 0xffffffff
Your i/o window should really not be full 32-bit address space.
arch/arm/mach-armada/include/mach/io.h line 21
Quoted 3 lines
arch/arm/mach-armada/include/mach/io.h new file +3
-0+ +#define __io (a) ((void __iomem *)(((a) - ARMADA_PCIE0_IO_BUS_BASE) + \ + ARMADA_PCIE0_IO_VIRT_BASE))
Are you including PCI in initial patches? This is not needed.
arch/arm/mach-armada/include/mach/io.h line 22
Quoted 1 line
arch/arm/mach-armada/include/mach/io.h new file +1
-0+#define __mem_pci (a) (a)
Not needed.
In other words, remove io.h. It's no longer needed except for a few cases like PCI and that will be fixed soon (hopefully).
Quoted 92 lines
arch/arm/mach-armada/include/mach/io.h new file +2
-0+ +#endif arch/arm/mach-armada/include/mach/irqs.h new file +84
-0@@ -0,0 +1,96 @@ +/* +* IRQ definitions for Marvell Armada SoC +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_IRQS_H +#define __ASM_ARCH_IRQS_H + +/* +* Per-cpu Interrupts +*/ +#define IRQ_ARMADA_DRBL_LOW 0 +#define IRQ_ARMADA_DRBL_HI 1 +#define IRQ_ARMADA_DRBL_SUM 2 +#define IRQ_ARMADA_FABRIC 3 +#define IRQ_ARMADA_SOC_ERR 4 +#define IRQ_ARMADA_LCL_TIMER0 5 +#define IRQ_ARMADA_LCL_TIMER1 6 +#define IRQ_ARMADA_LCL_WD 7 +#define IRQ_ARMADA_GE0_TH_RXTX 8 +#define IRQ_ARMADA_GE0_RXTX 9 +#define IRQ_ARMADA_GE1_TH_RXTX 10 +#define IRQ_ARMADA_GE1_RXTX 11 +#define IRQ_ARMADA_GE2_TH_RXTX 12 +#define IRQ_ARMADA_GE2_RXTX 13 +#define IRQ_ARMADA_GE3_TH_RXTX 14 +#define IRQ_ARMADA_GE3_RXTX 15 + +/* +* Global interrupts +*/ +#define IRQ_ARMADA_LCD 29 +#define IRQ_ARMADA_SPI0 30 +#define IRQ_ARMADA_I2C0 31 +#define IRQ_ARMADA_I2C1 32 +#define IRQ_ARMADA_GLBL_TIMER0 37 +#define IRQ_ARMADA_GLBL_TIMER1 38 +#define IRQ_ARMADA_GLBL_TIMER2 39 +#define IRQ_ARMADA_GLBL_TIMER3 40 +#define IRQ_ARMADA_UART0 41 +#define IRQ_ARMADA_UART1 42 +#define IRQ_ARMADA_UART2 43 +#define IRQ_ARMADA_UART3 44 +#define IRQ_ARMADA_USB0 45 +#define IRQ_ARMADA_USB1 46 +#define IRQ_ARMADA_USB2 47 +#define IRQ_ARMADA_CESA0 48 +#define IRQ_ARMADA_CESA1 49 +#define IRQ_ARMADA_RTC 50 +#define IRQ_ARMADA_XOR0_CH0 51 +#define IRQ_ARMADA_XOR0_CH1 52 +#define IRQ_ARMADA_SDIO 54 +#define IRQ_ARMADA_SATA0 55 +#define IRQ_ARMADA_TDM 56 +#define IRQ_ARMADA_SATA1 57 +#define IRQ_ARMADA_PCIE0 61 +#define IRQ_ARMADA_PCIE1 62 +#define IRQ_ARMADA_GPIO_0_7 82 +#define IRQ_ARMADA_GPIO_8_15 83 +#define IRQ_ARMADA_GPIO_16_23 84 +#define IRQ_ARMADA_GPIO_24_31 85 +#define IRQ_ARMADA_GPIO_32_39 87 +#define IRQ_ARMADA_GPIO_40_47 88 +#define IRQ_ARMADA_GPIO_48_55 89 +#define IRQ_ARMADA_GPIO_56_63 90 +#define IRQ_ARMADA_GPIO_64_66 91 +#define IRQ_ARMADA_SPI1 92 +#define IRQ_ARMADA_WD 93 +#define IRQ_ARMADA_XOR1_CH0 94 +#define IRQ_ARMADA_XOR1_CH1 95 +#define IRQ_ARMADA_PCIE2 99 +#define IRQ_ARMADA_PCIE3 103 +#define IRQ_ARMADA_DRAM 108 +#define IRQ_ARMADA_GE0_WKUP 109 +#define IRQ_ARMADA_GE1_WKUP 110 +#define IRQ_ARMADA_GE2_WKUP 111 +#define IRQ_ARMADA_GE3_WKUP 112
arch/arm/mach-armada/include/mach/irqs.h line 94
Quoted 10 lines
arch/arm/mach-armada/include/mach/irqs.h new file +10
-0+#define IRQ_ARMADA_NFC 113 + +/* +* ARMADA General Purpose Pins +*/ +#define IRQ_ARMADA_GPIO_START 82 +#define NR_GPIO_IRQS 64 + +#define NR_IRQS (115) +
All this should come from DT. Enable SPARSE_IRQ.
arch/arm/mach-armada/include/mach/system.h
Quoted 7 lines
arch/arm/mach-armada/include/mach/irqs.h new file +2
-0+ +#endif arch/arm/mach-armada/include/mach/system.h new file +0
-0
This header is gone now. You don't need anything if you just use the default cpu_do_idle.
Quoted 88 lines
arch/arm/mach-armada/include/mach/system.h new file +21
-0@@ -0,0 +1,21 @@ +/* +* Marvell Armada SoC system defines +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ASM_ARCH_SYSTEM_H +#define __ASM_ARCH_SYSTEM_H + +static inline void arch_idle (void ) +{ +cpu_do_idle (); +} + +#endif arch/arm/mach-armada/include/mach/timex.h new file +13
-0@@ -0,0 +1,13 @@ +/* +* Marvell Armada SoC time definitions +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#define CLOCK_TICK_RATE (100 * HZ)arch/arm/mach-armada/include/mach/uncompress.h new file +41
-0@@ -0,0 +1,41 @@ +/* +* Marvell Armada SoC kernel uncompression UART routines +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <mach/armada.h> + +#define UART_THR ((volatile unsigned char *)(ARMADA_UART0_PHYS_BASE + 0x0)) +#define UART_LSR ((volatile unsigned char *)(ARMADA_UART0_PHYS_BASE + 0x14)) + +#define LSR_THRE 0x20 + +static void putc (const char c) +{ +int i; + +for (i =0 ; i <0x1000 ; i++) { +/* Transmit fifo not full? */ +if (*UART_LSR &LSR_THRE ) +break ; + } + + *UART_THR = c; +} + +static void flush (void ) +{ +} + +/* +* nothing to do +*/ +#define arch_decomp_setup () +#define arch_decomp_wdog ()
Nicolas Pitre
maintainerPATCH 1/8 arm: mach-armada: add headers
In reply to Thomas PetazzoniQuoted 3 lines · Thomas Petazzoni
From: Gregory CLEMENT <[email protected]>
This patch adds basic header files for Armada SoCs.
Some of those files, such as system.h, have been made obsolete in mainline lately. Please remove them.
Nicolas
PATCH 2/8 arm: mach-armada: add source files
In reply to Thomas PetazzoniThis patch adds basic source files for Marvell Armada SoCs.
--- arch/arm/boot/dts/a370.dtsi | 23 ++++ arch/arm/boot/dts/armada.dtsi | 67 ++++++++++ arch/arm/boot/dts/axp.dtsi | 43 +++++++ arch/arm/mach-armada/Kconfig | 5 + arch/arm/mach-armada/Makefile | 2 + arch/arm/mach-armada/Makefile.boot | 1 + arch/arm/mach-armada/common.c | 56 +++++++++ arch/arm/mach-armada/common.h | 27 ++++ arch/arm/mach-armada/irq.c | 116 +++++++++++++++++ arch/arm/mach-armada/time.c | 243 ++++++++++++++++++++++++++++++++++++ 10 files changed, 583 insertions(+) create mode 100644 arch/arm/boot/dts/a370.dtsi create mode 100644 arch/arm/boot/dts/armada.dtsi create mode 100644 arch/arm/boot/dts/axp.dtsi create mode 100644 arch/arm/mach-armada/Kconfig create mode 100644 arch/arm/mach-armada/Makefile create mode 100644 arch/arm/mach-armada/Makefile.boot create mode 100644 arch/arm/mach-armada/common.c create mode 100644 arch/arm/mach-armada/common.h create mode 100644 arch/arm/mach-armada/irq.c create mode 100644 arch/arm/mach-armada/time.c
arch/arm/boot/dts/a370.dtsi new file +23 -0
@@ -0,0 +1,23 @@ +/* + * Device Tree Include file for Marvell Armada 370 family SoC + * + * Copyright (C) 2012 Marvell + * + * Lior Amsalem <[email protected]> + * Gregory CLEMENT <[email protected]> + * Thomas Petazzoni <[email protected]> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + * + * Contains definitions specific to the Armada 370 SoC that are not + * common to all Armada SoCs. + */ + +/include/ "armada.dtsi" + +/ { + model = "Marvell Armada 370 family SoC"; + compatible = "marvell,armada370", "marvell,armada"; + };
arch/arm/boot/dts/armada.dtsi new file +67 -0
67 lines not on this page · raw message
arch/arm/boot/dts/axp.dtsi new file +43 -0
43 lines not on this page · raw message
arch/arm/mach-armada/Kconfig new file +5 -0
@@ -0,0 +1,5 @@ +if ARCH_ARMADA + +menu "Marvell Armada Implementations" + +endif
arch/arm/mach-armada/Makefile new file +2 -0
@@ -0,0 +1,2 @@ +obj-y += common.o irq.o time.o +
arch/arm/mach-armada/Makefile.boot new file +1 -0
@@ -0,0 +1 @@ +zreladdr-y := 0x00008000
arch/arm/mach-armada/common.c new file +56 -0
56 lines not on this page · raw message
arch/arm/mach-armada/common.h new file +27 -0
@@ -0,0 +1,27 @@ +/* +* Core functions for Marvell Armada System On Chip +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* Gregory CLEMENT <[email protected]> +* Thomas Petazzoni <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ARCH_ARMADA_COMMON_H +#define __ARCH_ARMADA_COMMON_H + +#include <asm/exception.h> + +extern struct sys_timer armada_timer; + +void armada_map_io (void ); +void armada_init_irq (void ); +void armada_restart (char ,const char *); +asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs); + +#endif
arch/arm/mach-armada/irq.c new file +116 -0
116 lines not on this page · raw message
arch/arm/mach-armada/time.c new file +243 -0
243 lines not on this page · raw message
Signature · 1 line
1.7.9.5
Andrew Lunn
maintainerPATCH 2/8 arm: mach-armada: add source files
Quoted 46 lines · Thomas Petazzoni
This patch adds basic source files for Marvell Armada SoCs.
Signed-off-by Gregory CLEMENT <[email protected]>Signed-off-by Thomas Petazzoni <[email protected]>Signed-off-by Lior Amsalem <[email protected]>--- 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.carch/arm/boot/dts/a370.dtsi new file +12
-0@@ -0,0 +1,23 @@ +/* + * Device Tree Include file for Marvell Armada 370 family SoC + * + * Copyright (C) 2012 Marvell + * + * Lior Amsalem <[email protected]> + * Gregory CLEMENT <[email protected]> + * Thomas Petazzoni <[email protected]> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied.
arch/arm/boot/dts/a370.dtsi line 22
Quoted 10 lines
arch/arm/boot/dts/a370.dtsi new file +10
-0+ * + * Contains definitions specific to the Armada 370 SoC that are not + * common to all Armada SoCs. + */ + +/include/ "armada.dtsi" + +/ { + model = "Marvell Armada 370 family SoC"; + compatible = "marvell,armada370", "marvell,armada";
It should be mrvl, not marvell, in all the compatibility strings.
Also, we need to be careful with armada. kirkwood is an armada for example. It maybe be better to not actually use armada without postfix.
Quoted 4 lines
arch/arm/boot/dts/a370.dtsi new file +4
-0+void armada_restart(char mode, const char *cmd) +{ + /* + * Enable soft reset to assert RSTOUTn.
arch/arm/boot/dts/a370.dtsi
Quoted 10 lines
arch/arm/boot/dts/a370.dtsi new file +10
-0+ */ + writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK); + + /* + * Assert soft reset. + */ + writel(SOFT_RESET, SYSTEM_SOFT_RESET); + while (1) + ; +}
This chunk of code comes up multiple times in various orion devices. Could it be refactored into plat-orion?
Thanks
Andrew
PATCH 2/8 arm: mach-armada: add source files
Hello Andrew,
Thanks for the quick feedback!
Le Tue, 15 May 2012 11:12:18 +0200,
Andrew Lunn <[email protected]> a ?crit :
Quoted 7 lines
arch/arm/boot/dts/a370.dtsi line 22
Quoted 5 lines
arch/arm/boot/dts/a370.dtsi new file +5
-0+/include/ "armada.dtsi" + +/ { + model = "Marvell Armada 370 family SoC"; + compatible = "marvell,armada370", "marvell,armada";It should be mrvl, not marvell, in all the compatibility strings.
Ok, we will change that.
Quoted 3 lines
Also, we need to be careful with armada. kirkwood is an armada for example. It maybe be better to not actually use armada without postfix.
Do you have a recommendation for this? We support both Armada 370 and Armada XP, so the obvious common prefix for these two platforms is "armada". Since kirkwood are ARMv5 and those new Armada are ARMv7, would armadav7 be a better prefix? Then we could have armadav7-370 and armadav7-xp? Other suggestions?
Quoted 2 lines
This chunk of code comes up multiple times in various orion devices. Could it be refactored into plat-orion?
Probably yes. However, the register definitions are different between the different devices.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 2/8 arm: mach-armada: add source files
Quoted 21 lines · Thomas Petazzoni
Hello Andrew,
Thanks for the quick feedback!
Le Tue, 15 May 2012 11:12:18 +0200,
Andrew Lunn<[email protected]> a ?crit :Quoted 7 lines
arch/arm/boot/dts/a370.dtsi line 22
Quoted 5 lines
arch/arm/boot/dts/a370.dtsi new file +5
-0+/include/ "armada.dtsi" + +/ { + model = "Marvell Armada 370 family SoC"; + compatible = "marvell,armada370", "marvell,armada";It should be mrvl, not marvell, in all the compatibility strings.
Ok, we will change that.
Quoted 3 lines
Also, we need to be careful with armada. kirkwood is an armada for example. It maybe be better to not actually use armada without postfix.
Quoted 5 lines
Do you have a recommendation for this? We support both Armada 370 and Armada XP, so the obvious common prefix for these two platforms is "armada". Since kirkwood are ARMv5 and those new Armada are ARMv7, would armadav7 be a better prefix? Then we could have armadav7-370 and armadav7-xp? Other suggestions?
You might want to talk to Marvell about that. I went with armadaxp or a shortened axp (although that might have bad connections back to the old Alphas)
[snip]
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 2/8 arm: mach-armada: add source files
In reply to Thomas PetazzoniThomas Petazzoni <[email protected]> writes:
Hi,
Quoted 21 lines
Hello Andrew,
Thanks for the quick feedback!
Le Tue, 15 May 2012 11:12:18 +0200,
Andrew Lunn <[email protected]> a ?crit :Quoted 7 lines
arch/arm/boot/dts/a370.dtsi line 22
Quoted 5 lines
arch/arm/boot/dts/a370.dtsi new file +5
-0+/include/ "armada.dtsi" + +/ { + model = "Marvell Armada 370 family SoC"; + compatible = "marvell,armada370", "marvell,armada";It should be mrvl, not marvell, in all the compatibility strings.
Ok, we will change that.
Quoted 3 lines
Also, we need to be careful with armada. kirkwood is an armada for example. It maybe be better to not actually use armada without postfix.
Quoted 5 lines
Do you have a recommendation for this? We support both Armada 370 and Armada XP, so the obvious common prefix for these two platforms is "armada". Since kirkwood are ARMv5 and those new Armada are ARMv7, would armadav7 be a better prefix? Then we could have armadav7-370 and armadav7-xp? Other suggestions?
Please be carefull with what you'll choose. There's also Dove SoCs which are v7 too (88AP510 / armada 510 in Marvell namings). I would be tempted to use "mrvl,dove" like was what was used for kirkwood so this won't conflict but still, can be quite confusing.
Regards,
Arnaud
PATCH 2/8 arm: mach-armada: add source files
Quoted 30 lines · Arnaud Patard (Rtp)
Thomas Petazzoni<[email protected]> writes:
Hi,
Quoted 21 lines
Hello Andrew,
Thanks for the quick feedback!
Le Tue, 15 May 2012 11:12:18 +0200,
Andrew Lunn<[email protected]> a ?crit :Quoted 7 lines
arch/arm/boot/dts/a370.dtsi line 22
Quoted 5 lines
arch/arm/boot/dts/a370.dtsi new file +5
-0+/include/ "armada.dtsi" + +/ { + model = "Marvell Armada 370 family SoC"; + compatible = "marvell,armada370", "marvell,armada";It should be mrvl, not marvell, in all the compatibility strings.
Ok, we will change that.
Quoted 3 lines
Also, we need to be careful with armada. kirkwood is an armada for example. It maybe be better to not actually use armada without postfix.
Quoted 5 lines
Do you have a recommendation for this? We support both Armada 370 and Armada XP, so the obvious common prefix for these two platforms is "armada". Since kirkwood are ARMv5 and those new Armada are ARMv7, would armadav7 be a better prefix? Then we could have armadav7-370 and armadav7-xp? Other suggestions?
Quoted 4 lines
Please be carefull with what you'll choose. There's also Dove SoCs which are v7 too (88AP510 / armada 510 in Marvell namings). I would be tempted to use "mrvl,dove" like was what was used for kirkwood so this won't conflict but still, can be quite confusing.
For the device tree naming, I would go for the device's manufacturing code simply to ensure that there is no confusion about what is being supported.
For further compatibility fields, I'm not sure on how good it would be to put things that are not at-least sub-sets of what is being supported in the compatibilty line... We'd like to avoid changing the kernel too much, but adding an extra line or two to selected drivers is not difficult.
The actuall CPU core shouldn't really come in to it, as that is taken care of elsewhere in the kernel initialisation sequence.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
Andrew Lunn
maintainerPATCH 2/8 arm: mach-armada: add source files
In reply to Thomas PetazzoniQuoted 44 lines
arch/arm/mach-armada/irq.c new file +37
-0@@ -0,0 +1,116 @@ +/* +* Marvall Armada SoC IRQ handling +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem <[email protected]> +* Gregory CLEMENT <[email protected]> +* Thomas Petazzoni <[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/irq.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/of_address.h> +#include <linux/of_irq.h> +#include <linux/irqdomain.h> +#include <asm/mach/arch.h> +#include <asm/exception.h> + +/* Interrupt Controller Registers Map */ +#define ARMADA_INT_SET_MASK_OFFS (0xBC) +#define ARMADA_INT_CLEAR_MASK_OFFS (0xB8) + +#define ARMADA_INT_SET_ENABLE_OFFS (0xA30) +#define ARMADA_INT_CLEAR_ENABLE_OFFS (0xA34) + +#define ARMADA_CPU_INTACK_OFFS (0xB4) + +static void __iomem *per_cpu_int_base; +static void __iomem *main_int_base; +static struct irq_domain *armada_mpic_domain;
arch/arm/mach-armada/irq.c line 47
Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10
-0+ +static void armada_irq_mask (struct irq_data *d) +{ +writel (d->irq, per_cpu_int_base +ARMADA_INT_CLEAR_MASK_OFFS ); +} + +static void armada_irq_unmask (struct irq_data *d) +{ +writel (d->irq, per_cpu_int_base +ARMADA_INT_SET_MASK_OFFS ); +}
All the other orion's use the generic-chip interrupt routines. Can this device also use it? It would also allow you to use the generic DT bindings.
Andrew
PATCH 2/8 arm: mach-armada: add source files
Quoted 50 lines · Andrew Lunn
Quoted 50 lines
arch/arm/mach-armada/irq.c new file +43
-0@@ -0,0 +1,116 @@ +/* +* Marvall Armada SoC IRQ handling +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/irq.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/of_address.h> +#include <linux/of_irq.h> +#include <linux/irqdomain.h> +#include <asm/mach/arch.h> +#include <asm/exception.h> + +/* Interrupt Controller Registers Map */ +#define ARMADA_INT_SET_MASK_OFFS (0xBC) +#define ARMADA_INT_CLEAR_MASK_OFFS (0xB8) + +#define ARMADA_INT_SET_ENABLE_OFFS (0xA30) +#define ARMADA_INT_CLEAR_ENABLE_OFFS (0xA34) + +#define ARMADA_CPU_INTACK_OFFS (0xB4) + +static void __iomem *per_cpu_int_base; +static void __iomem *main_int_base; +static struct irq_domain *armada_mpic_domain; + +static void armada_irq_mask (struct irq_data *d) +{ +writel (d->irq, per_cpu_int_base +ARMADA_INT_CLEAR_MASK_OFFS ); +} +
Quoted 8 lines
arch/arm/mach-armada/irq.c line 47
Quoted 4 lines
arch/arm/mach-armada/irq.c new file +4
-0+static void armada_irq_unmask (struct irq_data *d) +{ +writel (d->irq, per_cpu_int_base +ARMADA_INT_SET_MASK_OFFS ); +}All the other orion's use the generic-chip interrupt routines. Can this device also use it? It would also allow you to use the generic DT bindings.
Possibly, but there'll need to be support for setting interrupt affinity added at some point, as this is used on multi-core systems.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 2/8 arm: mach-armada: add source files
Quoted 60 lines
-----Original Message-----
From: Ben Dooks [mailto:ben.dooks at codethink.co.uk]
Sent: Tuesday, May 15, 2012 12:54 PM
To: Thomas Petazzoni; Arnd Bergmann; Olof Johansson; Ben Dooks; Jason Cooper; Andrew Lunn; Nicolas Pitre; Lior Amsalem; Maen Suleiman; linux- arm-kernel at lists.infradead.org; Gregory CLEMENT
Subject: Re: [PATCH 2/8] arm: mach-armada: add source filesQuoted 37 lines · Andrew Lunn
Quoted 37 lines
arch/arm/mach-armada/irq.c new file +31
-0@@ -0,0 +1,116 @@ +/* +* Marvall Armada SoC IRQ handling +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/irq.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/of_address.h> +#include <linux/of_irq.h> +#include <linux/irqdomain.h> +#include <asm/mach/arch.h> +#include <asm/exception.h> + +/* Interrupt Controller Registers Map */ +#define ARMADA_INT_SET_MASK_OFFS (0xBC) +#define ARMADA_INT_CLEAR_MASK_OFFS (0xB8) + +#define ARMADA_INT_SET_ENABLE_OFFS (0xA30) +#define ARMADA_INT_CLEAR_ENABLE_OFFS (0xA34)Quoted 8 lines
arch/arm/mach-armada/irq.c
Quoted 8 lines
arch/arm/mach-armada/irq.c new file +8
-0+ +#define ARMADA_CPU_INTACK_OFFS (0xB4) + +static void __iomem *per_cpu_int_base;static void __iomem +*main_int_base;static struct irq_domain *armada_mpic_domain; + +static void armada_irq_mask (struct irq_data *d) { + writel(d->irq, per_cpu_int_base +
ARMADA_INT_CLEAR_MASK_OFFS); }Quoted 3 lines
arch/arm/mach-armada/irq.c line 46
Quoted 3 lines
arch/arm/mach-armada/irq.c new file +3
-0+ +static void armada_irq_unmask (struct irq_data *d) { +writel (d->irq, per_cpu_int_base +ARMADA_INT_SET_MASK_OFFS );}
Quoted 1 line
Quoted 6 lines
Quoted 3 lines
All the other orion's use the generic-chip interrupt routines. Can this device also use it? It would also allow you to use the generic DT bindings.
Possibly, but there'll need to be support for setting interrupt affinity added at some point, as this is used on multi-core systems.
Exactly, also:
1. we're working on SMP implementation,
the interrupt code will also include SMP related changes and additions (affinity and raise_softirq)
2. The generic-chip uses locking in mask/unmask when system is configured for SMP.
We can avoid it with our HW design, so why not.
3. I've also tried to look into the gic implementation but it seems too far off our HW design.
Quoted 4 lines
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
Lior Amsalem
PATCH 2/8 arm: mach-armada: add source files
In reply to Thomas PetazzoniQuoted 42 lines · Thomas Petazzoni
This patch adds basic source files for Marvell Armada SoCs.
Signed-off-by Gregory CLEMENT<[email protected]>Signed-off-by Thomas Petazzoni<[email protected]>Signed-off-by Lior Amsalem<[email protected]>--- 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.dtsicreate mode 100644arch/arm/boot/dts/armada.dtsicreate mode 100644arch/arm/boot/dts/axp.dtsicreate mode 100644arch/arm/mach-armada/Kconfigcreate mode 100644arch/arm/mach-armada/Makefilecreate mode 100644arch/arm/mach-armada/Makefile.bootcreate mode 100644arch/arm/mach-armada/common.ccreate mode 100644arch/arm/mach-armada/common.hcreate mode 100644arch/arm/mach-armada/irq.ccreate mode 100644arch/arm/mach-armada/time.carch/arm/boot/dts/a370.dtsi new file +8
-0@@ -0,0 +1,23 @@ +/* + * Device Tree Include file for Marvell Armada 370 family SoC + * + * Copyright (C) 2012 Marvell + * + * Lior Amsalem<[email protected]> + * Gregory CLEMENT<[email protected]> + * Thomas Petazzoni<[email protected]>
arch/arm/boot/dts/a370.dtsi line 18
Quoted 10 lines
arch/arm/boot/dts/a370.dtsi new file +10
-0+ * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + * + * Contains definitions specific to the Armada 370 SoC that are not + * common to all Armada SoCs. + */ + +/include/ "armada.dtsi"
I would use armada_xp.dtsi at the least, we've no way of knowing what further Armada devices are going to be produced and whether they will be compatible with.
arch/arm/boot/dts/a370.dtsi line 23
Quoted 4 lines
arch/arm/boot/dts/a370.dtsi new file +4
-0+/ { + model = "Marvell Armada 370 family SoC"; + compatible = "marvell,armada370", "marvell,armada"; + };
Firstly, it is mrvl, not marvell everywhere else in the kernel (see MIPS and device tree documentation).
Secondly, I would strongly advise against using the generic marketing name for these devices in the compatible list, "marvell,armada" as we have no way of knowing what new devices will come along in the future and if they'll be compatible.
Quoted 11 lines
arch/arm/boot/dts/armada.dtsi new file +5
-0@@ -0,0 +1,67 @@ +/* + * Device Tree Include file for Marvell Armada family SoC + * + * Copyright (C) 2012 Marvell + *
arch/arm/boot/dts/armada.dtsi line 15
Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10
-0+ * Lior Amsalem<[email protected]> + * Gregory CLEMENT<[email protected]> + * Thomas Petazzoni<[email protected]> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + * + * This file contains the definitions that are common to the Armada + * 370 and Armada XP SoC.
I really do not want to see these files in the kernel, we where suppose to remove any specific manchine dependency by moving to device tree and not push the problem from a board.c to a .dts file.
Given these really should be part of the bootloader, I am not sure if a GPLv2 compliant license is really appropriate for these files. At best some form of dual-licensing to allow them to be moved out into a devtree repository elsewhere would be useful.
(Feedback from Grant here would be useful)
PS, given the amount of devtree related stuff, CC'ing Grant Likely may have been useful./
Quoted 6 lines
arch/arm/boot/dts/armada.dtsi new file +6
-0+ */ + +/include/ "skeleton.dtsi" + +/ { + model = "Marvell Armada family SoC";
arch/arm/boot/dts/armada.dtsi line 31
Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10
-0+ compatible = "marvell,armada"; + + cpus { + cpu at 0 { + compatible = "marvell,sheeva-v7"; + }; + }; + + mpic: interrupt-controller at d0020000 { + compatible = "marvell,mpic";
Should this be "mrvl,axp_mpic" ?
Quoted 7 lines
arch/arm/boot/dts/armada.dtsi new file +7
-0+ #interrupt-cells =<1>; + #address-cells =<1>; + #size-cells =<1>; + interrupt-controller; + reg =<0xd0020000 0x1000>, + <0xd0021000 0x1000>; + };
arch/arm/boot/dts/armada.dtsi line 48
Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10
-0+ + soc { + #address-cells =<1>; + #size-cells =<1>; + compatible = "simple-bus"; + interrupt-parent =<&mpic>; + ranges; + + serial at d0012000 { + compatible = "ns16550";
thought these where more akin to the designware uart blocks?
arch/arm/boot/dts/armada.dtsi line 61
Quoted 13 lines
arch/arm/boot/dts/armada.dtsi new file +13
-0+ reg =<0xd0012000 0x100>; + reg-shift =<2>; + interrupts =<41>; + }; + serial at d0012100 { + compatible = "ns16550"; + reg =<0xd0012100 0x100>; + reg-shift =<2>; + interrupts =<42>; + }; + + timer at d0020300 { + compatible = "marvell,timer";
Is this really a generic marvell timer block?
arch/arm/boot/dts/axp.dtsi
Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +6
-0+ reg =<0xd0020300 0x30>; + interrupts =<37>,<38>,<39>,<40>; + }; + }; +}; +arch/arm/boot/dts/axp.dtsi new file +0
-1--- /dev/null
[snip, pretty much the same comments here.
Quoted 49 lines
arch/arm/mach-armada/Kconfig new file +5
-0@@ -0,0 +1,5 @@ +if ARCH_ARMADA + +menu "Marvell Armada Implementations" + +endifarch/arm/mach-armada/Makefile new file +2
-0@@ -0,0 +1,2 @@ +obj-y += common.o irq.o time.o +arch/arm/mach-armada/Makefile.boot new file +1
-0@@ -0,0 +1 @@ +zreladdr-y := 0x00008000arch/arm/mach-armada/common.c new file +17
-0@@ -0,0 +1,56 @@ +/* +* Core functions for Marvell Armada System On Chip +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> +#include <linux/delay.h> +#include <linux/init.h>
arch/arm/mach-armada/common.c line 27
Quoted 10 lines
arch/arm/mach-armada/common.c new file +10
-0+#include <linux/platform_device.h> +#include <linux/irq.h> +#include <linux/timex.h> +#include <asm/page.h> +#include <asm/setup.h> +#include <asm/mach/map.h> +#include <plat/addr-map.h> +#include <mach/armada.h> +#include <mach/bridge-regs.h> +#include "common.h"
for some reason there are no spaces between #include and the rest of the code?
Quoted 91 lines
arch/arm/mach-armada/common.c new file +29
-0+ +static struct map_desc armada_io_desc[]__initdata = { + { + .virtual =ARMADA_REGS_VIRT_BASE , + .pfn =__phys_to_pfn (ARMADA_REGS_PHYS_BASE ), + .length =ARMADA_REGS_SIZE , + .type =MT_DEVICE , + }, +}; + +void __init armada_map_io (void ) +{ +iotable_init (armada_io_desc,ARRAY_SIZE (armada_io_desc)); +} + +void armada_restart (char mode,const char *cmd) +{ +/* +* Enable soft reset to assert RSTOUTn. +*/ +writel (SOFT_RESET_OUT_EN , RSTOUTn_MASK); + +/* +* Assert soft reset. +*/ +writel (SOFT_RESET ,SYSTEM_SOFT_RESET ); +while (1 ) + ; +}arch/arm/mach-armada/common.h new file +27
-0@@ -0,0 +1,27 @@ +/* +* Core functions for Marvell Armada System On Chip +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ARCH_ARMADA_COMMON_H +#define __ARCH_ARMADA_COMMON_H + +#include <asm/exception.h> + +extern struct sys_timer armada_timer; + +void armada_map_io (void ); +void armada_init_irq (void ); +void armada_restart (char ,const char *); +asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs); + +#endif arch/arm/mach-armada/irq.c new file +23
-0@@ -0,0 +1,116 @@ +/* +* Marvall Armada SoC IRQ handling +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/irq.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/of_address.h> +#include <linux/of_irq.h> +#include <linux/irqdomain.h> +#include <asm/mach/arch.h>
arch/arm/mach-armada/irq.c line 33
Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10
-0+#include <asm/exception.h> + +/* Interrupt Controller Registers Map */ +#define ARMADA_INT_SET_MASK_OFFS (0xBC) +#define ARMADA_INT_CLEAR_MASK_OFFS (0xB8) + +#define ARMADA_INT_SET_ENABLE_OFFS (0xA30) +#define ARMADA_INT_CLEAR_ENABLE_OFFS (0xA34) + +#define ARMADA_CPU_INTACK_OFFS (0xB4)
MPIC_ since you indicated earlier that it is pretty generic.
Quoted 24 lines
arch/arm/mach-armada/irq.c new file +24
-0+ +static void __iomem *per_cpu_int_base; +static void __iomem *main_int_base; +static struct irq_domain *armada_mpic_domain; + +static void armada_irq_mask (struct irq_data *d) +{ +writel (d->irq, per_cpu_int_base +ARMADA_INT_CLEAR_MASK_OFFS ); +} + +static void armada_irq_unmask (struct irq_data *d) +{ +writel (d->irq, per_cpu_int_base +ARMADA_INT_SET_MASK_OFFS ); +} + +static struct irq_chip armada_irq_chip = { + .name ="armada_irq" , + .irq_mask = armada_irq_mask, + .irq_mask_ack = armada_irq_mask, + .irq_unmask = armada_irq_unmask, +}; + +static int armada_mpic_irq_map(struct irq_domain *h, + unsigned int virq,
arch/arm/mach-armada/irq.c line 67
Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10
-0+ irq_hw_number_t hw) +{ +armada_irq_mask (irq_get_irq_data (virq)); +writel (virq, main_int_base +ARMADA_INT_SET_ENABLE_OFFS ); + +irq_set_chip_and_handler (virq,&armada_irq_chip, + handle_level_irq); +irq_set_status_flags (virq,IRQ_LEVEL ); +set_irq_flags (virq,IRQF_VALID |IRQF_PROBE ); +return 0 ;
you could have used the per-irq driver private data to keep things like the base of controller in.
arch/arm/mach-armada/irq.c line 79
Quoted 12 lines
arch/arm/mach-armada/irq.c new file +12
-0+} + +static struct irq_domain_ops armada_mpic_irq_ops = { + .map = armada_mpic_irq_map, + .xlate = irq_domain_xlate_onecell, +}; + +static void __init armada_mpic_of_init (struct device_node *node, +struct device_node *parent) +{ + main_int_base =of_iomap (node,0 ); + per_cpu_int_base =of_iomap (node,1 );
Please verify the return values.
Quoted 16 lines
arch/arm/mach-armada/irq.c new file +16
-0+ + armada_mpic_domain =irq_domain_add_linear (node,NR_IRQS , + &armada_mpic_irq_ops,NULL ); +if (!armada_mpic_domain) +panic ("Unable to add Armada MPIC irq domain (DT)\n" ); + +irq_set_default_host (armada_mpic_domain); +} + +asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs) +{ +u32 irqstat, irqnr; + + do { + irqstat = readl_relaxed(per_cpu_int_base + + ARMADA_CPU_INTACK_OFFS);
arch/arm/mach-armada/irq.c line 105
Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10
-0+ irqnr = irqstat&0x3FF ; + +if (irqnr<1023 ) { + irqnr =irq_find_mapping (armada_mpic_domain, irqnr); +handle_IRQ (irqnr, regs); +continue ; + } + +break ; + }while (1 );
no timeout to get out of handling many IRQs?
Quoted 34 lines
arch/arm/mach-armada/irq.c new file +11
-0+} + +static const struct of_device_id mpic_of_match[]__initconst = { + { .compatible ="marvell,mpic" , .data = armada_mpic_of_init }, + {}, +}; + +void __init armada_init_irq (void ) +{ +of_irq_init (mpic_of_match); +}arch/arm/mach-armada/time.c new file +17
-0@@ -0,0 +1,243 @@ +/* +* Marvell Armada SoC timer handling. +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +* +* Timer 0 is used as free-running clocksource, while timer 1 is +* used as clock_event_device. +*/ +
arch/arm/mach-armada/time.c line 27
Quoted 10 lines
arch/arm/mach-armada/time.c new file +10
-0+#include <linux/kernel.h> +#include <linux/timer.h> +#include <linux/clockchips.h> +#include <linux/interrupt.h> +#include <linux/of.h> +#include <linux/of_irq.h> +#include <linux/of_address.h> +#include <linux/irq.h> +#include <asm/sched_clock.h> +#include <asm/mach/time.h>
Style issue again.
Quoted 67 lines
arch/arm/mach-armada/time.c new file +67
-0+ +/* +* Timer block registers. +*/ +#define TIMER_CTRL_OFF 0x0000 +#define TIMER0_EN 0x0001 +#define TIMER0_RELOAD_EN 0x0002 +#define TIMER0_25MHZ 0x0800 +#define TIMER0_DIV (div) ((div)<< 19) +#define TIMER1_EN 0x0004 +#define TIMER1_RELOAD_EN 0x0008 +#define TIMER1_25MHZ 0x1000 +#define TIMER1_DIV (div) ((div)<< 22) +#define TIMER_EVENTS_STATUS 0x0004 +#define TIMER0_CLR_MASK (~0x1) +#define TIMER1_CLR_MASK (~0x100) +#define TIMER0_RELOAD_OFF 0x0010 +#define TIMER0_VAL_OFF 0x0014 +#define TIMER1_RELOAD_OFF 0x0018 +#define TIMER1_VAL_OFF 0x001c + +/* Global timers are connected to the coherency fabric clock, and the +below divider reduces their incrementing frequency. */ +#define TIMER_DIVIDER_SHIFT 5 +#define TIMER_DIVIDER (1<< TIMER_DIVIDER_SHIFT) + +/* +* SoC-specific data. +*/ +static void __iomem *timer_base; +static int timer_irq; + +/* +* Number of timer ticks per jiffy. +*/ +static u32 ticks_per_jiffy; + +static u32 notrace armada_read_sched_clock(void) +{ +return ~readl (timer_base +TIMER0_VAL_OFF ); +} + +/* +* Clockevent handling. +*/ +static int +armada_clkevt_next_event (unsigned long delta,struct clock_event_device *dev) +{ +unsigned long flags; +u32 u; + +if (delta ==0 ) +return -ETIME ; + +local_irq_save (flags); + +/* +* Clear clockevent timer interrupt. +*/ +writel (TIMER1_CLR_MASK , timer_base +TIMER_EVENTS_STATUS ); + +/* +* Setup new clockevent timer value. +*/ +writel (delta, timer_base +TIMER1_VAL_OFF ); + +/*
arch/arm/mach-armada/time.c line 104
Quoted 10 lines
arch/arm/mach-armada/time.c new file +10
-0+* Enable the timer. +*/ + u =readl (timer_base +TIMER_CTRL_OFF ); + u = ((u& ~TIMER1_RELOAD_EN ) |TIMER1_EN | +TIMER1_DIV (TIMER_DIVIDER_SHIFT )); +writel (u, timer_base +TIMER_CTRL_OFF ); + +local_irq_restore (flags); + +return 0 ;
you could have halved the length by just using single line comments.
Quoted 28 lines
arch/arm/mach-armada/time.c new file +28
-0+} + +static void +armada_clkevt_mode (enum clock_event_mode mode,struct clock_event_device *dev) +{ +unsigned long flags; +u32 u; + +local_irq_save (flags); +if (mode ==CLOCK_EVT_MODE_PERIODIC ) { +/* +* Setup timer to fire at 1/HZ intervals. +*/ +writel (ticks_per_jiffy -1 , timer_base +TIMER1_RELOAD_OFF ); +writel (ticks_per_jiffy -1 , timer_base +TIMER1_VAL_OFF ); + +/* +* Enable timer. +*/ + u =readl (timer_base +TIMER_CTRL_OFF ); + +writel ((u |TIMER1_EN |TIMER1_RELOAD_EN | +TIMER1_DIV (TIMER_DIVIDER_SHIFT )), + timer_base +TIMER_CTRL_OFF ); + }else { +/* +* Disable timer. +*/
arch/arm/mach-armada/time.c line 142
Quoted 10 lines
arch/arm/mach-armada/time.c new file +10
-0+ u =readl (timer_base +TIMER_CTRL_OFF ); +writel (u& ~TIMER1_EN , timer_base +TIMER_CTRL_OFF ); + +/* +* ACK pending timer interrupt. +*/ +writel (TIMER1_CLR_MASK , + timer_base +TIMER_EVENTS_STATUS ); + + }
How about handling the one-shot case that you advertise below?
Quoted 15 lines
arch/arm/mach-armada/time.c new file +15
-0+static void __init armada_time_init (void ) +{ +u32 u; +struct device_node *np; +unsigned int timer_clk; + + np =of_find_compatible_node (NULL ,NULL ,"marvell,timer" ); + timer_base =of_iomap (np,0 ); +WARN_ON (!timer_base); + +if (of_find_property (np,"marvell,timer-25Mhz" ,NULL )) { +/* The fixed 25MHz timer is available so let's use it*/ + u =readl (timer_base +TIMER_CTRL_OFF ); +writel (u |TIMER0_25MHZ |TIMER1_25MHZ , + timer_base +TIMER_CTRL_OFF );
arch/arm/mach-armada/time.c line 197
Quoted 10 lines
arch/arm/mach-armada/time.c new file +10
-0+ timer_clk =25000000 ; + }else { +u32 clk; +of_property_read_u32 (np,"clock-frequency" ,&clk); +WARN_ON (!clk); + u =readl (timer_base +TIMER_CTRL_OFF ); +writel (u& ~(TIMER0_25MHZ |TIMER1_25MHZ ), + timer_base +TIMER_CTRL_OFF ); + timer_clk = clk /TIMER_DIVIDER ; + }
Give we've not got clk_() support yet, should you just force 25M operation until clk_get_rate() is supported?
[snip]
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 2/8 arm: mach-armada: add source files
Quoted 543 lines · Ben Dooks
Quoted 42 lines · Thomas Petazzoni
This patch adds basic source files for Marvell Armada SoCs.
Signed-off-by Gregory CLEMENT<[email protected]>Signed-off-by Thomas Petazzoni<[email protected]>Signed-off-by Lior Amsalem<[email protected]>--- 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.dtsicreate mode 100644arch/arm/boot/dts/armada.dtsicreate mode 100644arch/arm/boot/dts/axp.dtsicreate mode 100644arch/arm/mach-armada/Kconfigcreate mode 100644arch/arm/mach-armada/Makefilecreate mode 100644arch/arm/mach-armada/Makefile.bootcreate mode 100644arch/arm/mach-armada/common.ccreate mode 100644arch/arm/mach-armada/common.hcreate mode 100644arch/arm/mach-armada/irq.ccreate mode 100644arch/arm/mach-armada/time.carch/arm/boot/dts/a370.dtsi new file +8
-0@@ -0,0 +1,23 @@ +/* + * Device Tree Include file for Marvell Armada 370 family SoC + * + * Copyright (C) 2012 Marvell + * + * Lior Amsalem<[email protected]> + * Gregory CLEMENT<[email protected]> + * Thomas Petazzoni<[email protected]>arch/arm/boot/dts/a370.dtsi line 18
Quoted 10 lines
arch/arm/boot/dts/a370.dtsi new file +10
-0+ * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + * + * Contains definitions specific to the Armada 370 SoC that are not + * common to all Armada SoCs. + */ + +/include/ "armada.dtsi"I would use
armada_xp.dtsiat the least, we've no way of knowing what further Armada devices are going to be produced and whether they will be compatible with.arch/arm/boot/dts/a370.dtsi line 23
Quoted 4 lines
arch/arm/boot/dts/a370.dtsi new file +4
-0+/ { + model = "Marvell Armada 370 family SoC"; + compatible = "marvell,armada370", "marvell,armada"; + };Firstly, it is mrvl, not marvell everywhere else in the kernel (see MIPS and device tree documentation).
Secondly, I would strongly advise against using the generic marketing name for these devices in the compatible list, "marvell,armada" as we have no way of knowing what new devices will come along in the future and if they'll be compatible.
Quoted 11 lines
arch/arm/boot/dts/armada.dtsi new file +5
-0@@ -0,0 +1,67 @@ +/* + * Device Tree Include file for Marvell Armada family SoC + * + * Copyright (C) 2012 Marvell + *arch/arm/boot/dts/armada.dtsi line 15
Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10
-0+ * Lior Amsalem<[email protected]> + * Gregory CLEMENT<[email protected]> + * Thomas Petazzoni<[email protected]> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + * + * This file contains the definitions that are common to the Armada + * 370 and Armada XP SoC.I really do not want to see these files in the kernel, we where suppose to remove any specific manchine dependency by moving to device tree and not push the problem from a
board.cto a .dts file.Given these really should be part of the bootloader, I am not sure if a GPLv2 compliant license is really appropriate for these files. At best some form of dual-licensing to allow them to be moved out into a devtree repository elsewhere would be useful.
(Feedback from Grant here would be useful)
PS, given the amount of devtree related stuff, CC'ing Grant Likely may have been useful./
Quoted 6 lines
arch/arm/boot/dts/armada.dtsi new file +6
-0+ */ + +/include/ "skeleton.dtsi" + +/ { + model = "Marvell Armada family SoC";arch/arm/boot/dts/armada.dtsi line 31
Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10
-0+ compatible = "marvell,armada"; + + cpus { + cpu at 0 { + compatible = "marvell,sheeva-v7"; + }; + }; + + mpic: interrupt-controller at d0020000 { + compatible = "marvell,mpic";Should this be "mrvl,axp_mpic" ?
Quoted 7 lines
arch/arm/boot/dts/armada.dtsi new file +7
-0+ #interrupt-cells =<1>; + #address-cells =<1>; + #size-cells =<1>; + interrupt-controller; + reg =<0xd0020000 0x1000>, + <0xd0021000 0x1000>; + };arch/arm/boot/dts/armada.dtsi line 48
Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10
-0+ + soc { + #address-cells =<1>; + #size-cells =<1>; + compatible = "simple-bus"; + interrupt-parent =<&mpic>; + ranges; + + serial at d0012000 { + compatible = "ns16550";thought these where more akin to the designware uart blocks?
arch/arm/boot/dts/armada.dtsi line 61
Quoted 13 lines
arch/arm/boot/dts/armada.dtsi new file +13
-0+ reg =<0xd0012000 0x100>; + reg-shift =<2>; + interrupts =<41>; + }; + serial at d0012100 { + compatible = "ns16550"; + reg =<0xd0012100 0x100>; + reg-shift =<2>; + interrupts =<42>; + }; + + timer at d0020300 { + compatible = "marvell,timer";Is this really a generic marvell timer block?
arch/arm/boot/dts/axp.dtsi
Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +6
-0+ reg =<0xd0020300 0x30>; + interrupts =<37>,<38>,<39>,<40>; + }; + }; +}; +arch/arm/boot/dts/axp.dtsi new file +0
-1--- /dev/null[snip, pretty much the same comments here.
Quoted 49 lines
arch/arm/mach-armada/Kconfig new file +5
-0@@ -0,0 +1,5 @@ +if ARCH_ARMADA + +menu "Marvell Armada Implementations" + +endifarch/arm/mach-armada/Makefile new file +2
-0@@ -0,0 +1,2 @@ +obj-y += common.o irq.o time.o +arch/arm/mach-armada/Makefile.boot new file +1
-0@@ -0,0 +1 @@ +zreladdr-y := 0x00008000arch/arm/mach-armada/common.c new file +17
-0@@ -0,0 +1,56 @@ +/* +* Core functions for Marvell Armada System On Chip +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> +#include <linux/delay.h> +#include <linux/init.h> arch/arm/mach-armada/common.c line 27
Quoted 10 lines
arch/arm/mach-armada/common.c new file +10
-0+#include <linux/platform_device.h> +#include <linux/irq.h> +#include <linux/timex.h> +#include <asm/page.h> +#include <asm/setup.h> +#include <asm/mach/map.h> +#include <plat/addr-map.h> +#include <mach/armada.h> +#include <mach/bridge-regs.h> +#include "common.h" for some reason there are no spaces between #include and the rest of the code?
Quoted 91 lines
arch/arm/mach-armada/common.c new file +29
-0+ +static struct map_desc armada_io_desc[]__initdata = { + { + .virtual =ARMADA_REGS_VIRT_BASE , + .pfn =__phys_to_pfn (ARMADA_REGS_PHYS_BASE ), + .length =ARMADA_REGS_SIZE , + .type =MT_DEVICE , + }, +}; + +void __init armada_map_io (void ) +{ +iotable_init (armada_io_desc,ARRAY_SIZE (armada_io_desc)); +} + +void armada_restart (char mode,const char *cmd) +{ +/* +* Enable soft reset to assert RSTOUTn. +*/ +writel (SOFT_RESET_OUT_EN , RSTOUTn_MASK); + +/* +* Assert soft reset. +*/ +writel (SOFT_RESET ,SYSTEM_SOFT_RESET ); +while (1 ) + ; +}arch/arm/mach-armada/common.h new file +27
-0@@ -0,0 +1,27 @@ +/* +* Core functions for Marvell Armada System On Chip +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ARCH_ARMADA_COMMON_H +#define __ARCH_ARMADA_COMMON_H + +#include <asm/exception.h> + +extern struct sys_timer armada_timer; + +void armada_map_io (void ); +void armada_init_irq (void ); +void armada_restart (char ,const char *); +asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs); + +#endif arch/arm/mach-armada/irq.c new file +23
-0@@ -0,0 +1,116 @@ +/* +* Marvall Armada SoC IRQ handling +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/irq.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/of_address.h> +#include <linux/of_irq.h> +#include <linux/irqdomain.h> +#include <asm/mach/arch.h> arch/arm/mach-armada/irq.c line 33
Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10
-0+#include <asm/exception.h> + +/* Interrupt Controller Registers Map */ +#define ARMADA_INT_SET_MASK_OFFS (0xBC) +#define ARMADA_INT_CLEAR_MASK_OFFS (0xB8) + +#define ARMADA_INT_SET_ENABLE_OFFS (0xA30) +#define ARMADA_INT_CLEAR_ENABLE_OFFS (0xA34) + +#define ARMADA_CPU_INTACK_OFFS (0xB4)
MPIC_since you indicated earlier that it is pretty generic.Quoted 24 lines
arch/arm/mach-armada/irq.c new file +24
-0+ +static void __iomem *per_cpu_int_base; +static void __iomem *main_int_base; +static struct irq_domain *armada_mpic_domain; + +static void armada_irq_mask (struct irq_data *d) +{ +writel (d->irq, per_cpu_int_base +ARMADA_INT_CLEAR_MASK_OFFS ); +} + +static void armada_irq_unmask (struct irq_data *d) +{ +writel (d->irq, per_cpu_int_base +ARMADA_INT_SET_MASK_OFFS ); +} + +static struct irq_chip armada_irq_chip = { + .name ="armada_irq" , + .irq_mask = armada_irq_mask, + .irq_mask_ack = armada_irq_mask, + .irq_unmask = armada_irq_unmask, +}; + +static int armada_mpic_irq_map(struct irq_domain *h, + unsigned int virq,arch/arm/mach-armada/irq.c line 67
Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10
-0+ irq_hw_number_t hw) +{ +armada_irq_mask (irq_get_irq_data (virq)); +writel (virq, main_int_base +ARMADA_INT_SET_ENABLE_OFFS ); + +irq_set_chip_and_handler (virq,&armada_irq_chip, + handle_level_irq); +irq_set_status_flags (virq,IRQ_LEVEL ); +set_irq_flags (virq,IRQF_VALID |IRQF_PROBE ); +return 0 ;you could have used the per-irq driver private data to keep things like the base of controller in.
arch/arm/mach-armada/irq.c line 79
Quoted 12 lines
arch/arm/mach-armada/irq.c new file +12
-0+} + +static struct irq_domain_ops armada_mpic_irq_ops = { + .map = armada_mpic_irq_map, + .xlate = irq_domain_xlate_onecell, +}; + +static void __init armada_mpic_of_init (struct device_node *node, +struct device_node *parent) +{ + main_int_base =of_iomap (node,0 ); + per_cpu_int_base =of_iomap (node,1 );Please verify the return values.
Quoted 16 lines
arch/arm/mach-armada/irq.c new file +16
-0+ + armada_mpic_domain =irq_domain_add_linear (node,NR_IRQS , + &armada_mpic_irq_ops,NULL ); +if (!armada_mpic_domain) +panic ("Unable to add Armada MPIC irq domain (DT)\n" ); + +irq_set_default_host (armada_mpic_domain); +} + +asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs) +{ +u32 irqstat, irqnr; + + do { + irqstat = readl_relaxed(per_cpu_int_base + + ARMADA_CPU_INTACK_OFFS);arch/arm/mach-armada/irq.c line 105
Quoted 10 lines
arch/arm/mach-armada/irq.c new file +10
-0+ irqnr = irqstat&0x3FF ; + +if (irqnr<1023 ) { + irqnr =irq_find_mapping (armada_mpic_domain, irqnr); +handle_IRQ (irqnr, regs); +continue ; + } + +break ; + }while (1 );no timeout to get out of handling many IRQs?
Quoted 34 lines
arch/arm/mach-armada/irq.c new file +11
-0+} + +static const struct of_device_id mpic_of_match[]__initconst = { + { .compatible ="marvell,mpic" , .data = armada_mpic_of_init }, + {}, +}; + +void __init armada_init_irq (void ) +{ +of_irq_init (mpic_of_match); +}arch/arm/mach-armada/time.c new file +17
-0@@ -0,0 +1,243 @@ +/* +* Marvell Armada SoC timer handling. +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +* +* Timer 0 is used as free-running clocksource, while timer 1 is +* used as clock_event_device. +*/ +arch/arm/mach-armada/time.c line 27
Quoted 10 lines
arch/arm/mach-armada/time.c new file +10
-0+#include <linux/kernel.h> +#include <linux/timer.h> +#include <linux/clockchips.h> +#include <linux/interrupt.h> +#include <linux/of.h> +#include <linux/of_irq.h> +#include <linux/of_address.h> +#include <linux/irq.h> +#include <asm/sched_clock.h> +#include <asm/mach/time.h> Style issue again.
Quoted 72 lines
arch/arm/mach-armada/time.c new file +72
-0+ +/* +* Timer block registers. +*/ +#define TIMER_CTRL_OFF 0x0000 +#define TIMER0_EN 0x0001 +#define TIMER0_RELOAD_EN 0x0002 +#define TIMER0_25MHZ 0x0800 +#define TIMER0_DIV (div) ((div)<< 19) +#define TIMER1_EN 0x0004 +#define TIMER1_RELOAD_EN 0x0008 +#define TIMER1_25MHZ 0x1000 +#define TIMER1_DIV (div) ((div)<< 22) +#define TIMER_EVENTS_STATUS 0x0004 +#define TIMER0_CLR_MASK (~0x1) +#define TIMER1_CLR_MASK (~0x100) +#define TIMER0_RELOAD_OFF 0x0010 +#define TIMER0_VAL_OFF 0x0014 +#define TIMER1_RELOAD_OFF 0x0018 +#define TIMER1_VAL_OFF 0x001c + +/* Global timers are connected to the coherency fabric clock, and the +below divider reduces their incrementing frequency. */ +#define TIMER_DIVIDER_SHIFT 5 +#define TIMER_DIVIDER (1<< TIMER_DIVIDER_SHIFT) + +/* +* SoC-specific data. +*/ +static void __iomem *timer_base; +static int timer_irq; + +/* +* Number of timer ticks per jiffy. +*/ +static u32 ticks_per_jiffy; + +static u32 notrace armada_read_sched_clock(void) +{ +return ~readl (timer_base +TIMER0_VAL_OFF ); +} + +/* +* Clockevent handling. +*/ +static int +armada_clkevt_next_event (unsigned long delta,struct clock_event_device *dev) +{ +unsigned long flags; +u32 u; + +if (delta ==0 ) +return -ETIME ; + +local_irq_save (flags); + +/* +* Clear clockevent timer interrupt. +*/ +writel (TIMER1_CLR_MASK , timer_base +TIMER_EVENTS_STATUS ); + +/* +* Setup new clockevent timer value. +*/ +writel (delta, timer_base +TIMER1_VAL_OFF ); + +/* +* Enable the timer. +*/ + u =readl (timer_base +TIMER_CTRL_OFF ); + u = ((u& ~TIMER1_RELOAD_EN ) |TIMER1_EN | +TIMER1_DIV (TIMER_DIVIDER_SHIFT ));
Quoted 8 lines
arch/arm/mach-armada/time.c line 104
Quoted 5 lines
arch/arm/mach-armada/time.c new file +5
-0+writel (u, timer_base +TIMER_CTRL_OFF ); + +local_irq_restore (flags); + +return 0 ;you could have halved the length by just using single line comments.
Right
Quoted 62 lines
Quoted 29 lines
arch/arm/mach-armada/time.c new file +28
-0+} + +static void +armada_clkevt_mode (enum clock_event_mode mode,struct clock_event_device *dev) +{ +unsigned long flags; +u32 u; + +local_irq_save (flags); +if (mode ==CLOCK_EVT_MODE_PERIODIC ) { +/* +* Setup timer to fire at 1/HZ intervals. +*/ +writel (ticks_per_jiffy -1 , timer_base +TIMER1_RELOAD_OFF ); +writel (ticks_per_jiffy -1 , timer_base +TIMER1_VAL_OFF ); + +/* +* Enable timer. +*/ + u =readl (timer_base +TIMER_CTRL_OFF ); + +writel ((u |TIMER1_EN |TIMER1_RELOAD_EN | +TIMER1_DIV (TIMER_DIVIDER_SHIFT )), + timer_base +TIMER_CTRL_OFF ); + }else { +/* +* Disable timer. +*/ arch/arm/mach-armada/time.c line 142
Quoted 10 lines
arch/arm/mach-armada/time.c new file +10
-0+ u =readl (timer_base +TIMER_CTRL_OFF ); +writel (u& ~TIMER1_EN , timer_base +TIMER_CTRL_OFF ); + +/* +* ACK pending timer interrupt. +*/ +writel (TIMER1_CLR_MASK , + timer_base +TIMER_EVENTS_STATUS ); + + }How about handling the one-shot case that you advertise below?
Quoted 20 lines
arch/arm/mach-armada/time.c new file +20
-0+static void __init armada_time_init (void ) +{ +u32 u; +struct device_node *np; +unsigned int timer_clk; + + np =of_find_compatible_node (NULL ,NULL ,"marvell,timer" ); + timer_base =of_iomap (np,0 ); +WARN_ON (!timer_base); + +if (of_find_property (np,"marvell,timer-25Mhz" ,NULL )) { +/* The fixed 25MHz timer is available so let's use it*/ + u =readl (timer_base +TIMER_CTRL_OFF ); +writel (u |TIMER0_25MHZ |TIMER1_25MHZ , + timer_base +TIMER_CTRL_OFF ); + timer_clk =25000000 ; + }else { +u32 clk; +of_property_read_u32 (np,"clock-frequency" ,&clk); +WARN_ON (!clk);
Quoted 9 lines
arch/arm/mach-armada/time.c line 197
Quoted 5 lines
arch/arm/mach-armada/time.c new file +5
-0+ u =readl (timer_base +TIMER_CTRL_OFF ); +writel (u& ~(TIMER0_25MHZ |TIMER1_25MHZ ), + timer_base +TIMER_CTRL_OFF ); + timer_clk = clk /TIMER_DIVIDER ; + }Give we've not got
clk_()support yet, should you just force 25M operation untilclk_get_rate()is supported?
This code support Aramade XP _and_ Armada 370, and for Armada 370 there is not such feature available.
Quoted 3 lines
[snip]
Signature · 5 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com +33 602 196 044
Andrew Lunn
maintainerPATCH 2/8 arm: mach-armada: add source files
In reply to Ben DooksQuoted 4 lines
arch/arm/boot/dts/armada.dtsi line 61
Quoted 2 lines
arch/arm/boot/dts/armada.dtsi new file +2
-0+ timer at d0020300 { + compatible = "marvell,timer";Is this really a generic marvell timer block?
Looking at the code below, its very similar to plat-orion timer.
I've not look at all the details, but i suspect it should not have its own timer implementation, it should just be using plat-orion functions.
Andrew
PATCH 2/8 arm: mach-armada: add source files
In reply to Ben DooksQuoted 97 lines · Ben Dooks
Quoted 42 lines · Thomas Petazzoni
This patch adds basic source files for Marvell Armada SoCs.
Signed-off-by Gregory CLEMENT<[email protected]>Signed-off-by Thomas Petazzoni<[email protected]>Signed-off-by Lior Amsalem<[email protected]>--- 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.dtsicreate mode 100644arch/arm/boot/dts/armada.dtsicreate mode 100644arch/arm/boot/dts/axp.dtsicreate mode 100644arch/arm/mach-armada/Kconfigcreate mode 100644arch/arm/mach-armada/Makefilecreate mode 100644arch/arm/mach-armada/Makefile.bootcreate mode 100644arch/arm/mach-armada/common.ccreate mode 100644arch/arm/mach-armada/common.hcreate mode 100644arch/arm/mach-armada/irq.ccreate mode 100644arch/arm/mach-armada/time.carch/arm/boot/dts/a370.dtsi new file +8
-0@@ -0,0 +1,23 @@ +/* + * Device Tree Include file for Marvell Armada 370 family SoC + * + * Copyright (C) 2012 Marvell + * + * Lior Amsalem<[email protected]> + * Gregory CLEMENT<[email protected]> + * Thomas Petazzoni<[email protected]>arch/arm/boot/dts/a370.dtsi line 18
Quoted 10 lines
arch/arm/boot/dts/a370.dtsi new file +10
-0+ * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + * + * Contains definitions specific to the Armada 370 SoC that are not + * common to all Armada SoCs. + */ + +/include/ "armada.dtsi"I would use
armada_xp.dtsiat the least, we've no way of knowing what further Armada devices are going to be produced and whether they will be compatible with.arch/arm/boot/dts/a370.dtsi line 23
Quoted 4 lines
arch/arm/boot/dts/a370.dtsi new file +4
-0+/ { + model = "Marvell Armada 370 family SoC"; + compatible = "marvell,armada370", "marvell,armada"; + };Firstly, it is mrvl, not marvell everywhere else in the kernel (see MIPS and device tree documentation).
Secondly, I would strongly advise against using the generic marketing name for these devices in the compatible list, "marvell,armada" as we have no way of knowing what new devices will come along in the future and if they'll be compatible.
Quoted 11 lines
arch/arm/boot/dts/armada.dtsi new file +5
-0@@ -0,0 +1,67 @@ +/* + * Device Tree Include file for Marvell Armada family SoC + * + * Copyright (C) 2012 Marvell + *arch/arm/boot/dts/armada.dtsi line 15
Quoted 10 lines
arch/arm/boot/dts/armada.dtsi new file +10
-0+ * Lior Amsalem<[email protected]> + * Gregory CLEMENT<[email protected]> + * Thomas Petazzoni<[email protected]> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + * + * This file contains the definitions that are common to the Armada + * 370 and Armada XP SoC.I really do not want to see these files in the kernel, we where suppose to remove any specific manchine dependency by moving to device tree and not push the problem from a
board.cto a .dts file.
Quoted 6 lines
Given these really should be part of the bootloader, I am not sure if a GPLv2 compliant license is really appropriate for these files. At best some form of dual-licensing to allow them to be moved out into a devtree repository elsewhere would be useful.
(Feedback from Grant here would be useful)
Without another repository the kernel tree is the correct place to put these files. I certainly don't want them considered as part of the boot loader either since there needs to be the base expectation that this data may need to change. Please do keep them in arch/arm/boot/dts for now.
g.
PATCH 2/8 arm: mach-armada: add source files
In reply to Thomas PetazzoniQuoted 23 lines · Thomas Petazzoni
arch/arm/mach-armada/common.h new file +17
-0@@ -0,0 +1,27 @@ +/* +* Core functions for Marvell Armada System On Chip +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ARCH_ARMADA_COMMON_H +#define __ARCH_ARMADA_COMMON_H +
arch/arm/mach-armada/common.h line 27
Quoted 10 lines
arch/arm/mach-armada/common.h new file +10
-0+#include <asm/exception.h> + +extern struct sys_timer armada_timer; + +void armada_map_io (void ); +void armada_init_irq (void ); +void armada_restart (char ,const char *); +asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs); + +#endif
you should have extern before all these function declarations.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 2/8 arm: mach-armada: add source files
In reply to Thomas PetazzoniQuoted 23 lines · Thomas Petazzoni
arch/arm/mach-armada/common.h new file +17
-0@@ -0,0 +1,27 @@ +/* +* Core functions for Marvell Armada System On Chip +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#ifndef __ARCH_ARMADA_COMMON_H +#define __ARCH_ARMADA_COMMON_H +
arch/arm/mach-armada/common.h line 27
Quoted 10 lines
arch/arm/mach-armada/common.h new file +10
-0+#include <asm/exception.h> + +extern struct sys_timer armada_timer; + +void armada_map_io (void ); +void armada_init_irq (void ); +void armada_restart (char ,const char *); +asmlinkage void __exception_irq_entry armada_handle_irq(struct pt_regs *regs); + +#endif
As a note, I don't think you need the __exception_irq_entry or the asmlinkage on the declaration of armada_handle_irq, so you could probably drop the include of <asm/exception.h> too.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 3/8 arm: mach-armada: add documentation for new device tree bindings
In reply to Thomas Petazzoni--- .../devicetree/bindings/arm/armada-mpic.txt | 23 +++++++++++++++++++ .../devicetree/bindings/arm/armada-timer.txt | 11 +++++++++ Documentation/devicetree/bindings/arm/armada.txt | 24 ++++++++++++++++++++ 3 files changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/armada-mpic.txt create mode 100644 Documentation/devicetree/bindings/arm/armada-timer.txt create mode 100644 Documentation/devicetree/bindings/arm/armada.txt
Documentation/devicetree/bindings/arm/armada-mpic.txt new file +23 -0
@@ -0,0 +1,23 @@ +Marvell Armada Interrupt Controller +----------------------------------- + +Required properties: +- compatible: Should be "marvell,mpic" +- interrupt-controller: Identifies the node as an interrupt controller. +- #interrupt-cells: The number of cells to define the interrupts. Should be 1. + The cell is the IRQ number +- reg: Should contain PMIC registers location and length. First pair + for the main interrupt registers, second pair for the per-CPU + interrupt registers + +Example: + + mpic: interrupt-controller at d0020000 { + compatible = "marvell,mpic"; + #interrupt-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + interrupt-controller; + reg = <0xd0020000 0x1000>, + <0xd0021000 0x1000>; + };
Documentation/devicetree/bindings/arm/armada-timer.txt new file +11 -0
@@ -0,0 +1,11 @@ +Marvell Armada Global Timers +---------------------------- + +Required properties: +- compatible: Should be "marvell,timer" +- interrupts: Should contain the list of Global Timer interrupts +- reg: Should contain the base address of the Global Timer registers + +Optional properties: +- marvell,timer-25Mhz: Tells whether the Global timer supports the 25 + Mhz fixed mode (available on Armada XP and not on Armada 370)
Documentation/devicetree/bindings/arm/armada.txt new file +24 -0
@@ -0,0 +1,24 @@ +Marvell Armada Platforms Device Tree Bindings +--------------------------------------------- + +Boards with a SoC of the Marvell Armada family shall have the +following property: + +Required root node property: + +compatible: must contain "marvell,armada" + +In addition, boards using the Marvell Armada 370 SoC shall have the +following property: + +Required root node property: + +compatible: must contain "marvell,armada370" + +In addition, boards using the Marvell Armada XP SoC shall have the +following property: + +Required root node property: + +compatible: must contain "marvell,armadaxp" +
Signature · 1 line
1.7.9.5
PATCH 3/8 arm: mach-armada: add documentation for new device tree bindings
Quoted 17 lines · Thomas Petazzoni
Signed-off-by Thomas Petazzoni<[email protected]>Signed-off-by Gregory CLEMENT<[email protected]>--- .../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.txtcreate mode 100644Documentation/devicetree/bindings/arm/armada-timer.txtcreate mode 100644Documentation/devicetree/bindings/arm/armada.txtDocumentation/devicetree/bindings/arm/armada-mpic.txt new file +0
-0
Documentation/devicetree/bindings/arm/armada-mpic.txt line 5
Quoted 5 lines
Documentation/devicetree/bindings/arm/armada-mpic.txt new file +5
-0@@ -0,0 +1,23 @@ +Marvell Armada Interrupt Controller +----------------------------------- + +Required properties: +- compatible: Should be "marvell,mpic"
see notes on mrvl, and the usage of very generic names. Maybe find a better name than the generic 'mpic'?
Documentation/devicetree/bindings/arm/armada-mpic.txt line 11
Quoted 6 lines
Documentation/devicetree/bindings/arm/armada-mpic.txt new file +6
-0+- interrupt-controller: Identifies the node as an interrupt controller. +- #interrupt-cells: The number of cells to define the interrupts. Should be 1. + The cell is the IRQ number +- reg: Should contain PMIC registers location and length. First pair + for the main interrupt registers, second pair for the per-CPU + interrupt registers
you mis-spelled MPIC as PMIC.
Documentation/devicetree/bindings/arm/armada-timer.txt line 7
Quoted 13 lines
Documentation/devicetree/bindings/arm/armada-timer.txt new file +7
-0@@ -0,0 +1,11 @@ +Marvell Armada Global Timers +---------------------------- + +Required properties: +- compatible: Should be "marvell,timer" +- interrupts: Should contain the list of Global Timer interrupts +- reg: Should contain the base address of the Global Timer registers
I'd say that given you already have a clock-frequency field, just use that and detect == 25MHz.
Personally, I would have added a static clock to give to the timer something to reference.
Documentation/devicetree/bindings/arm/armada-timer.txt line 11
Quoted 3 lines
Documentation/devicetree/bindings/arm/armada-timer.txt new file +3
-0+Optional properties: +- marvell,timer-25Mhz: Tells whether the Global timer supports the 25 + Mhz fixed mode (available on Armada XP and not on Armada 370)
See above comment.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 4/8 arm: mach-armada: add compilation/configuration changes
In reply to Thomas PetazzoniFrom: Gregory CLEMENT <[email protected]>
--- arch/arm/Kconfig | 12 ++++++++++++ arch/arm/Makefile | 1 + 2 files changed, 13 insertions(+)
arch/arm/Kconfig +12 -0
@@ -545,6 +545,16 @@ config ARCH_IXP4XX help Support for Intel's IXP4XX (XScale) family of processors. +config ARCH_ARMADA + bool "Marvell Armada" + select CPU_V7 + select ARCH_REQUIRE_GPIOLIB + select GENERIC_CLOCKEVENTS + select PLAT_ORION + select MULTI_IRQ_HANDLER + help + Support for the Marvell Armada SoC Family + config ARCH_DOVE bool "Marvell Dove" select CPU_V7
@@ -999,6 +1009,8 @@ endchoice # Kconfigs may be included either alphabetically (according to the # plat- suffix) or along side the corresponding mach-* source. # +source "arch/arm/mach-armada/Kconfig" + source "arch/arm/mach-at91/Kconfig" source "arch/arm/mach-bcmring/Kconfig"
arch/arm/Makefile +1 -0
@@ -195,6 +195,7 @@ machine-$(CONFIG_MACH_SPEAR310) := spear3xx machine-$(CONFIG_MACH_SPEAR320) := spear3xx machine-$(CONFIG_MACH_SPEAR600) := spear6xx machine-$(CONFIG_ARCH_ZYNQ) := zynq +machine-$(CONFIG_ARCH_ARMADA) := armada # Platform directory name. This list is sorted alphanumerically # by CONFIG_* macro name.
Signature · 1 line
1.7.9.5
PATCH 5/8 arm: mach-armada: add support for Armada 370 board with device tree
In reply to Thomas PetazzoniFrom: Gregory CLEMENT <[email protected]>
--- arch/arm/boot/dts/a370-db.dts | 41 ++++++++++++++++++++++++++++++++++++++++ arch/arm/mach-armada/Kconfig | 8 ++++++++ arch/arm/mach-armada/Makefile | 1 + arch/arm/mach-armada/a370-dt.c | 41 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 91 insertions(+) create mode 100644 arch/arm/boot/dts/a370-db.dts create mode 100644 arch/arm/mach-armada/a370-dt.c
arch/arm/boot/dts/a370-db.dts new file +41 -0
@@ -0,0 +1,41 @@ +/* + * Device Tree file for Marvell Armada 370 evaluation board + * (DB-88F6710-BP-DDR3) + * + * Copyright (C) 2012 Marvell + * + * Lior Amsalem <[email protected]> + * Gregory CLEMENT <[email protected]> + * Thomas Petazzoni <[email protected]> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +/dts-v1/; +/include/ "a370.dtsi" + +/ { + model = "Marvell Armada 370 Evaluation Board"; + compatible = "marvell,a370-db", "marvell,armada370", "marvell,armada"; + + chosen { + bootargs = "console=ttyS0,115200 earlyprintk"; + }; + + memory { + device_type = "memory"; + reg = <0x00000000 0x20000000>; /* 512 MB */ + }; + + soc { + serial at d0012000 { + clock-frequency = <200000000>; + }; + timer at d0020300 { + clock-frequency = <600000000>; + + }; + }; +};
arch/arm/mach-armada/Kconfig +8 -0
@@ -2,4 +2,12 @@ if ARCH_ARMADA menu "Marvell Armada Implementations" +config MACH_ARMADA_370_DT + bool "Marvell Armada 370 boards with device-tree support" + help + Say 'Y' here if you want your kernel to support + boards based on Marvell Armada 370 with device tree. + +endmenu + endif
arch/arm/mach-armada/Makefile +1 -0
@@ -1,2 +1,3 @@ obj-y += common.o irq.o time.o +obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o
arch/arm/mach-armada/a370-dt.c new file +41 -0
41 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Thomas PetazzoniFrom: Gregory CLEMENT <[email protected]>
--- arch/arm/boot/dts/axp-db.dts | 40 ++++++++++++++++++++++++++++++++++++++++ arch/arm/mach-armada/Kconfig | 6 ++++++ arch/arm/mach-armada/Makefile | 2 +- arch/arm/mach-armada/axp-dt.c | 41 +++++++++++++++++++++++++++++++++++++++++ 4 files changed, 88 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/axp-db.dts create mode 100644 arch/arm/mach-armada/axp-dt.c
arch/arm/boot/dts/axp-db.dts new file +40 -0
@@ -0,0 +1,40 @@ +/* + * Device Tree file for Marvell Armada XP evaluation board + * (DB-78460-BP) + * + * Copyright (C) 2012 Marvell + * + * Lior Amsalem <[email protected]> + * Gregory CLEMENT <[email protected]> + * Thomas Petazzoni <[email protected]> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +/dts-v1/; +/include/ "axp.dtsi" + +/ { + model = "Marvell Armada XP Evaluation Board"; + compatible = "marvell,axp-db", "marvell,armadaxp", "marvell,armada"; + + chosen { + bootargs = "console=ttyS0,115200 earlyprintk"; + }; + + memory { + device_type = "memory"; + reg = <0x00000000 0x20000000>; /* 512 MB */ + }; + + soc { + serial at d0012000 { + clock-frequency = <250000000>; + }; + serial at d0012100 { + clock-frequency = <250000000>; + }; + }; +};
arch/arm/mach-armada/Kconfig +6 -0
@@ -8,6 +8,12 @@ config MACH_ARMADA_370_DT Say 'Y' here if you want your kernel to support boards based on Marvell Armada 370 with device tree. +config MACH_ARMADA_XP_DT + bool "Marvell Armada XP boards with device-tree support" + help + Say 'Y' here if you want your kernel to support + boards based on Marvell Armada XP with device tree. + endmenu endif
arch/arm/mach-armada/Makefile +1 -1
@@ -1,3 +1,3 @@ obj-y += common.o irq.o time.o obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o - +obj-$(CONFIG_MACH_ARMADA_XP_DT) += axp-dt.o
arch/arm/mach-armada/axp-dt.c new file +41 -0
41 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
arch/arm/boot/dts/axp-db.dts
Quoted 19 lines · Thomas Petazzoni
From: Gregory CLEMENT<[email protected]>
Signed-off-by Gregory CLEMENT<[email protected]>Signed-off-by Thomas Petazzoni<[email protected]>Signed-off-by Lior Amsalem<[email protected]>--- arch/arm/boot/dts/axp-db.dts | 40 ++++++++++++++++++++++++++++++++++++++++ arch/arm/mach-armada/Kconfig | 6 ++++++ arch/arm/mach-armada/Makefile | 2 +- arch/arm/mach-armada/axp-dt.c | 41 +++++++++++++++++++++++++++++++++++++++++ 4 files changed, 88 insertions(+), 1 deletion(-)create mode 100644
arch/arm/boot/dts/axp-db.dtscreate mode 100644arch/arm/mach-armada/axp-dt.carch/arm/boot/dts/axp-db.dts new file +0
-0
see previous comments.
Quoted 52 lines
arch/arm/mach-armada/Kconfig +6
-0@@ -8,6 +8,12 @@ config MACH_ARMADA_370_DT Say 'Y' here if you want your kernel to support boards based on Marvell Armada 370 with device tree. +config MACH_ARMADA_XP_DT + bool "Marvell Armada XP boards with device-tree support" + help + Say 'Y' here if you want your kernel to support + boards based on Marvell Armada XP with device tree. + endmenu endifarch/arm/mach-armada/Makefile +1
-1@@ -1,3 +1,3 @@ obj-y += common.o irq.o time.o obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o - +obj-$(CONFIG_MACH_ARMADA_XP_DT) += axp-dt.oarch/arm/mach-armada/axp-dt.c new file +20
-0@@ -0,0 +1,41 @@ +/* +* Device Tree support for Armada XP platforms. +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/of_platform.h> +#include <asm/mach-types.h> +#include <asm/mach/arch.h> +#include <mach/armada.h>
arch/arm/mach-armada/axp-dt.c line 30
Quoted 10 lines
arch/arm/mach-armada/axp-dt.c new file +10
-0+#include "common.h" + +static void __init axp_dt_init (void ) +{ +of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); +} + +static const char *const axp_dt_board_dt_compat[] = { +"marvell,axp-db" , +NULL ,
This is where the device support becomes confusing.
I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.
Also, given how close they are, do we really need separate machine support files?
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 101 lines
-----Original Message-----
From: Ben Dooks [mailto:ben.dooks at codethink.co.uk]
Sent: Tuesday, May 15, 2012 12:58 PM
To: Thomas Petazzoni
Cc: Arnd Bergmann; Olof Johansson; Lior Amsalem; Andrew Lunn; Jason Cooper; Nicolas Pitre; Maen Suleiman; Ben Dooks; Gregory CLEMENT; linux- arm-kernel at lists.infradead.org
Subject: Re: [PATCH 6/8] arm: mach-armada: add support for Armada XP board with device treeQuoted 7 lines · Thomas Petazzoni
From: Gregory CLEMENT<[email protected]>
Signed-off-by Gregory CLEMENT<[email protected]>Signed-off-by Thomas Petazzoni<[email protected]>Signed-off-by Lior Amsalem<[email protected]>--- arch/arm/boot/dts/axp-db.dts | 40++++++++++++++++++++++++++++++++++++++++
Quoted 3 lines
arch/arm/mach-armada/Kconfig | 6 ++++++ arch/arm/mach-armada/Makefile | 2 +- arch/arm/mach-armada/axp-dt.c | 41+++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/axp-db.dts
Quoted 9 lines
4 files changed, 88 insertions(+), 1 deletion(-)create mode 100644
arch/arm/boot/dts/axp-db.dtscreate mode 100644arch/arm/mach-armada/axp-dt.c(quoted diff) +0
-0
b/arch/arm/boot/dts/axp-db.dtsnew file mode 100644 index 0000000..916be09arch/arm/boot/dts/axp-db.dts new file +0
-0see previous comments.
Quoted 47 lines
(quoted diff) +0
-0b/arch/arm/mach-armada/Kconfig index 7995813..2903096 100644
arch/arm/mach-armada/Kconfig +6
-0@@ -8,6 +8,12 @@ config MACH_ARMADA_370_DT Say 'Y' here if you want your kernel to support boards based on Marvell Armada 370 with device tree. +config MACH_ARMADA_XP_DT + bool "Marvell Armada XP boards with device-tree support" + help + Say 'Y' here if you want your kernel to support + boards based on Marvell Armada XP with device tree. + endmenu endif(quoted diff) +0
-0b/arch/arm/mach-armada/Makefile index ac39fae..7a3c438 100644
arch/arm/mach-armada/Makefile +1
-1@@ -1,3 +1,3 @@ obj-y += common.o irq.o time.o obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o - +obj-$(CONFIG_MACH_ARMADA_XP_DT) += axp-dt.o(quoted diff) +0
-0
b/arch/arm/mach-armada/axp-dt.cnew file mode 100644 index 0000000..2c13d4earch/arm/mach-armada/axp-dt.c new file +15
-0@@ -0,0 +1,41 @@ +/* +* Device Tree support for Armada XP platforms. +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> arch/arm/mach-armada/axp-dt.c line 25
Quoted 10 lines
arch/arm/mach-armada/axp-dt.c new file +10
-0+#include <linux/init.h> +#include <linux/of_platform.h> +#include <asm/mach-types.h> +#include <asm/mach/arch.h> +#include <mach/armada.h> +#include "common.h" + +static void __init axp_dt_init (void ) +{ + of_platform_populate(NULL, of_default_bus_match_table, NULL,NULL);
arch/arm/mach-armada/axp-dt.c line 30
Quoted 5 lines
arch/arm/mach-armada/axp-dt.c new file +5
-0+} + +static const char *const axp_dt_board_dt_compat[] = { +"marvell,axp-db" , +NULL ,This is where the device support becomes confusing.
Quoted 5 lines
I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.
Also, given how close they are, do we really need separate machine support files?
The problem with 78230 is that it's only one flavor of the AXP family which includes 78230, 78260 and 78460 resulting different core count, L2 size, DRAM bandwidth, etc.
Quoted 4 lines
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
Lior Amsalem
Andrew Lunn
maintainerPATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 7 lines
Quoted 5 lines
I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.
Also, given how close they are, do we really need separate machine support files?
The problem with 78230 is that it's only one flavor of the AXP family which includes 78230, 78260 and 78460 resulting different core count, L2 size, DRAM bandwidth, etc.
Can you explain the naming scheme and mapping to device numbers? Please don't limit it to these new devices, but also include the existing supported devices. From that we might be able to figure out and appropriate naming scheme.
Thanks
Andrew
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 5 lines · Andrew Lunn
Quoted 5 lines
Quoted 5 lines
I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.
Also, given how close they are, do we really need separate machine support files?
Quoted 7 lines
Quoted 2 lines
The problem with 78230 is that it's only one flavor of the AXP family which includes 78230, 78260 and 78460 resulting different core count, L2 size, DRAM bandwidth, etc.
Can you explain the naming scheme and mapping to device numbers? Please don't limit it to these new devices, but also include the existing supported devices. From that we might be able to figure out and appropriate naming scheme.
The names and numbers are already extremely confusing in the code we have. Maybe we can use the addition of the new code as an excuse to clean up what we have ;-)
I agree that "armada" is a rather bad choice, because chips under that name include both the pxa/mmp family and the orion/kirkwood/mv78xx0/dove family which AFAICT don't have much in common at all besides the CPU cores.
One option would be to move all DT-enabled board files under plat-orion once they are fully done, and leave just the non-DT board files in the individual directories until they have all been converted. We can start with the platform code that's being discussed here and move over the kirkwood and orion5x board-dt.c files once they don't depend on anything else in those directories any more.
Arnd
Nicolas Pitre
maintainerPATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 3 lines · Arnd Bergmann
I agree that "armada" is a rather bad choice, because chips under that name include both the pxa/mmp family and the orion/kirkwood/mv78xx0/dove family which AFAICT don't have much in common at all besides the CPU cores.
Oh, right. I remember now. Scrap my earlier suggestion then. Armada came out of Marvell's marketing dept, not the engineering dept.
Maybe we should just go with mach-mrvl_ebu and eventually move orion5x, kirkwood, dove, and friends in there. Why "ebu"? Because that's the internal Marvell name for the division that produced all those SOCs, hence their similarities, whereas PXA/MMP SOCs came from Intel initially.
Nicolas
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Arnd BergmannQuoted 10 lines · Arnd Bergmann
Quoted 9 lines · Andrew Lunn
Quoted 8 lines
Quoted 5 lines
I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.
Also, given how close they are, do we really need separate machine support files?
The problem with 78230 is that it's only one flavor of the AXP family which includes 78230, 78260 and 78460 resulting different core count, L2 size, DRAM bandwidth, etc.
Quoted 8 lines
Quoted 4 lines
Can you explain the naming scheme and mapping to device numbers? Please don't limit it to these new devices, but also include the existing supported devices. From that we might be able to figure out and appropriate naming scheme.
The names and numbers are already extremely confusing in the code we have. Maybe we can use the addition of the new code as an excuse to clean up what we have ;-)
Agreed.
Quoted 10 lines
I agree that "armada" is a rather bad choice, because chips under that name include both the pxa/mmp family and the orion/kirkwood/mv78xx0/dove family which AFAICT don't have much in common at all besides the CPU cores.
One option would be to move all DT-enabled board files under plat-orion once they are fully done, and leave just the non-DT board files in the individual directories until they have all been converted. We can start with the platform code that's being discussed here and move over the kirkwood and orion5x
board-dt.cfiles 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.
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Lior AmsalemQuoted 8 lines · Lior Amsalem
Quoted 8 lines
arch/arm/mach-armada/axp-dt.c line 30
Quoted 5 lines
arch/arm/mach-armada/axp-dt.c new file +5
-0+} + +static const char *const axp_dt_board_dt_compat[] = { +"marvell,axp-db" , +NULL ,This is where the device support becomes confusing.
Quoted 7 lines
Quoted 5 lines
I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.
Also, given how close they are, do we really need separate machine support files?
The problem with 78230 is that it's only one flavor of the AXP family which includes 78230, 78260 and 78460 resulting different core count, L2 size, DRAM bandwidth, etc.
The number of cores is discoverable from the cpu scu and the rest should either be encoded into the device-tree as either specific device names or node properties.
I would try and involve the _minimum_ number of additions to get the system up and running.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Ben DooksQuoted 92 lines · Ben Dooks
arch/arm/boot/dts/axp-db.dts
Quoted 21 lines · Thomas Petazzoni
From: Gregory CLEMENT<[email protected]>
Signed-off-by Gregory CLEMENT<[email protected]>Signed-off-by Thomas Petazzoni<[email protected]>Signed-off-by Lior Amsalem<[email protected]>--- arch/arm/boot/dts/axp-db.dts | 40 ++++++++++++++++++++++++++++++++++++++++ arch/arm/mach-armada/Kconfig | 6 ++++++ arch/arm/mach-armada/Makefile | 2 +- arch/arm/mach-armada/axp-dt.c | 41 +++++++++++++++++++++++++++++++++++++++++ 4 files changed, 88 insertions(+), 1 deletion(-)create mode 100644
arch/arm/boot/dts/axp-db.dtscreate mode 100644arch/arm/mach-armada/axp-dt.carch/arm/boot/dts/axp-db.dts new file +0
-0see previous comments.
Quoted 54 lines
arch/arm/mach-armada/Kconfig +6
-0@@ -8,6 +8,12 @@ config MACH_ARMADA_370_DT Say 'Y' here if you want your kernel to support boards based on Marvell Armada 370 with device tree. +config MACH_ARMADA_XP_DT + bool "Marvell Armada XP boards with device-tree support" + help + Say 'Y' here if you want your kernel to support + boards based on Marvell Armada XP with device tree. + endmenu endifarch/arm/mach-armada/Makefile +1
-1@@ -1,3 +1,3 @@ obj-y += common.o irq.o time.o obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o - +obj-$(CONFIG_MACH_ARMADA_XP_DT) += axp-dt.oarch/arm/mach-armada/axp-dt.c new file +20
-0@@ -0,0 +1,41 @@ +/* +* Device Tree support for Armada XP platforms. +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/of_platform.h> +#include <asm/mach-types.h> +#include <asm/mach/arch.h> +#include <mach/armada.h> arch/arm/mach-armada/axp-dt.c line 30
Quoted 10 lines
arch/arm/mach-armada/axp-dt.c new file +10
-0+#include "common.h" + +static void __init axp_dt_init (void ) +{ +of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); +} + +static const char *const axp_dt_board_dt_compat[] = { +"marvell,axp-db" , +NULL ,This is where the device support becomes confusing.
Quoted 3 lines
I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.
The name here should uniquely identify the board, not the chip. If you additionally want to have the chip name, then that should be after the board name. However, "marvell,armada" is too generic to be useful.
marvell is the documented vendor string, not mrvl.
Quoted 2 lines
Also, given how close they are, do we really need separate machine support files?
There does need to be justification why they need to be separate.
Rob
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 97 lines · Rob Herring
Quoted 92 lines · Ben Dooks
arch/arm/boot/dts/axp-db.dts
Quoted 21 lines · Thomas Petazzoni
From: Gregory CLEMENT<[email protected]>
Signed-off-by Gregory CLEMENT<[email protected]>Signed-off-by Thomas Petazzoni<[email protected]>Signed-off-by Lior Amsalem<[email protected]>--- arch/arm/boot/dts/axp-db.dts | 40 ++++++++++++++++++++++++++++++++++++++++ arch/arm/mach-armada/Kconfig | 6 ++++++ arch/arm/mach-armada/Makefile | 2 +- arch/arm/mach-armada/axp-dt.c | 41 +++++++++++++++++++++++++++++++++++++++++ 4 files changed, 88 insertions(+), 1 deletion(-)create mode 100644
arch/arm/boot/dts/axp-db.dtscreate mode 100644arch/arm/mach-armada/axp-dt.carch/arm/boot/dts/axp-db.dts new file +0
-0see previous comments.
Quoted 54 lines
arch/arm/mach-armada/Kconfig +6
-0@@ -8,6 +8,12 @@ config MACH_ARMADA_370_DT Say 'Y' here if you want your kernel to support boards based on Marvell Armada 370 with device tree. +config MACH_ARMADA_XP_DT + bool "Marvell Armada XP boards with device-tree support" + help + Say 'Y' here if you want your kernel to support + boards based on Marvell Armada XP with device tree. + endmenu endifarch/arm/mach-armada/Makefile +1
-1@@ -1,3 +1,3 @@ obj-y += common.o irq.o time.o obj-$(CONFIG_MACH_ARMADA_370_DT) += a370-dt.o - +obj-$(CONFIG_MACH_ARMADA_XP_DT) += axp-dt.oarch/arm/mach-armada/axp-dt.c new file +20
-0@@ -0,0 +1,41 @@ +/* +* Device Tree support for Armada XP platforms. +* +* Copyright (C) 2012 Marvell +* +* Lior Amsalem<[email protected]> +* Gregory CLEMENT<[email protected]> +* Thomas Petazzoni<[email protected]> +* +* This file is licensed under the terms of the GNU General Public +* License version 2. This program is licensed "as is" without any +* warranty of any kind, whether express or implied. +*/ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/of_platform.h> +#include <asm/mach-types.h> +#include <asm/mach/arch.h> +#include <mach/armada.h> arch/arm/mach-armada/axp-dt.c line 30
Quoted 10 lines
arch/arm/mach-armada/axp-dt.c new file +10
-0+#include "common.h" + +static void __init axp_dt_init (void ) +{ +of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); +} + +static const char *const axp_dt_board_dt_compat[] = { +"marvell,axp-db" , +NULL ,This is where the device support becomes confusing.
Quoted 3 lines
I would strongly advise on using "mrvl,mv78230" as the binding name. It isn't as if you can't have multiple names associated with one binding.
Quoted 5 lines
The name here should uniquely identify the board, not the chip. If you additionally want to have the chip name, then that should be after the board name. However, "marvell,armada" is too generic to be useful.
marvell is the documented vendor string, not mrvl.
I could swear I read it as mrvl in the documentation for device-tree
Quoted 4 lines
Quoted 2 lines
Also, given how close they are, do we really need separate machine support files?
There does need to be justification why they need to be separate.
I'd say for the "core" support that they could all be handled by this case catching the "marvell,mv...." and initialising all the core bits such as timer, io, irq, etc.
Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks <[email protected]> a ?crit :
Quoted 3 lines
Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.
The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:
* Maybe those mappings can be done using a normal ioremap() rather than in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)
* We probably shouldn't have anticipated this too much, and keep only one file for this initial submission.
We'll rework this for our v2.
Thanks for the comments!
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 7 lines · Thomas Petazzoni
Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks <[email protected]> a ?crit :Quoted 3 lines
Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.
Quoted 8 lines
The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:
* Maybe those mappings can be done using a normal
ioremap()rather than in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)
I'm pretty sure we can use ioremap for new PCI implementations now. Also, you can scan the device tree in map_io() if necesary, to see which PCIe ports are enabled.
Arnd
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Le Tue, 15 May 2012 14:25:30 +0000,
Arnd Bergmann <[email protected]> a ?crit :
Quoted 3 lines
I'm pretty sure we can use ioremap for new PCI implementations now. Also, you can scan the device tree in
map_io()if necesary, to see which PCIe ports are enabled.
Great. We'll work on that before submitting the PCIe bits.
Thanks,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Arnd BergmannQuoted 12 lines · Arnd Bergmann
Quoted 11 lines · Thomas Petazzoni
Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks<[email protected]> a ?crit :Quoted 3 lines
Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.
The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:
Quoted 8 lines
Quoted 4 lines
* Maybe those mappings can be done using a normal
ioremap()ratherthan in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)I'm pretty sure we can use ioremap for new PCI implementations now. Also, you can scan the device tree in
map_io()if necesary, to see which PCIe ports are enabled.
To be honest, if you need it, then it'd be a good idea to fix anyway.
And at worst you can always construct map_desc entries on the stack and call iotable_init()
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Arnd BergmannQuoted 12 lines · Arnd Bergmann
Quoted 11 lines · Thomas Petazzoni
Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks <[email protected]> a ?crit :Quoted 3 lines
Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.
The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:
Quoted 8 lines
Quoted 4 lines
* Maybe those mappings can be done using a normal
ioremap()rather than in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)I'm pretty sure we can use ioremap for new PCI implementations now. Also, you can scan the device tree in
map_io()if necesary, to see which PCIe ports are enabled.
For the i/o windows, they should be static because we want a fixed virtual address across platforms. 0xfef00000 is the planned address. Memory windows should be ioremap.
Rob
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 18 lines · Rob Herring
Quoted 17 lines · Arnd Bergmann
Quoted 15 lines · Thomas Petazzoni
Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks<[email protected]> a ?crit :Quoted 3 lines
Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.
The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:
* Maybe those mappings can be done using a normal
ioremap()ratherthan in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)
Quoted 7 lines
Quoted 3 lines
I'm pretty sure we can use ioremap for new PCI implementations now. Also, you can scan the device tree in
map_io()if necesary, to see which PCIe ports are enabled.For the i/o windows, they should be static because we want a fixed virtual address across platforms.
0xfef00000is the planned address. Memory windows should be ioremap.
It might be worth looking at changing ioremap() to work nicely with large page entries if it hasn't already been done.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 2 lines · Ben Dooks
It might be worth looking at changing
ioremap()to work nicely with large page entries if it hasn't already been done.
It's already been done, but not for SMP systems. There's issues there which make that racy and horrible.
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Thomas PetazzoniQuoted 10 lines · Thomas Petazzoni
Le Tue, 15 May 2012 14:53:45 +0100,
Ben Dooks<[email protected]> a ?crit :Quoted 3 lines
Since the two board support files are identical, except for the names they print, I'd say this is the job of one file. It can always be split later.
The initial motivation for keeping two files here is that the two SoC have a different number of PCIe memory areas, and those areas are typically mapped in ->map_io(). However:
Yes, the number of times I've viewed the kernel and seen very similar code replicated multiple times tends to make me burst into tears.
Quoted 4 lines
* Maybe those mappings can be done using a normal
ioremap()ratherthan in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)
That's a very old way of doing it. I'm pretty sure there's no reason to get these allocated so early.
I believe you can probably leave the PCI/PCIe bindings until you have enough kernel state to do ioremap() or similar and then associate the necessary mappings with the bus creation.
Quoted 2 lines
* We probably shouldn't have anticipated this too much, and keep only one file for this initial submission.
Yes, the less we need to review the better.
Quoted 1 line
We'll rework this for our v2.
Great.
Quoted 1 line
Thanks for the comments!
I'll get to testing this kernel soon, and report back
Quoted 1 line
Thomas
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 6 lines · Ben Dooks
Quoted 4 lines
* Maybe those mappings can be done using a normal
ioremap()ratherthan in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)That's a very old way of doing it. I'm pretty sure there's no reason to get these allocated so early.
Well, you might actually still want to use static mappings for any large areas that are accessed a lot in the kernel, because that lets you use larger page TLB entries, which ioremap by itself cannot. The host driver should however still use ioremap, it will now just get the area that was set up with map_io.
Quoted 3 lines
I believe you can probably leave the PCI/PCIe bindings until you have enough kernel state to do
ioremap()or similar and then associate the necessary mappings with the bus creation.
I think it was Stephen Warrent who told me that he can actually do a PCI host driver as a loadable module now, with only a few changes in the ARM core code.
Arnd
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 14 lines · Arnd Bergmann
Quoted 6 lines · Ben Dooks
Quoted 4 lines
* Maybe those mappings can be done using a normal
ioremap()ratherthan in ->map_io(), according to DT informations (but most other ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)That's a very old way of doing it. I'm pretty sure there's no reason to get these allocated so early.
Well, you might actually still want to use static mappings for any large areas that are accessed a lot in the kernel, because that lets you use larger page TLB entries, which ioremap by itself cannot. The host driver should however still use ioremap, it will now just get the area that was set up with
map_io.
Quoted 7 lines
Quoted 3 lines
I believe you can probably leave the PCI/PCIe bindings until you have enough kernel state to do
ioremap()or similar and then associate the necessary mappings with the bus creation.I think it was Stephen Warrent who told me that he can actually do a PCI host driver as a loadable module now, with only a few changes in the ARM core code.
Thierry Redding was working on this (actually, perhaps PCIe as a platform driver rather than as a module, but I'm not sure) in the context of the Tegra PCIe driver. See some of the patches at
http://patchwork.ozlabs.org/project/linux-tegra/list/, e.g. "PCI: Keep pci_fixup_irqs() around after init" and "ARM: pci: Keep pci_common_init() around after init" IIRC.
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 6 lines · Stephen Warren
Thierry Redding was working on this (actually, perhaps PCIe as a platform driver rather than as a module, but I'm not sure) in the context of the Tegra PCIe driver. See some of the patches at
http://patchwork.ozlabs.org/project/linux-tegra/list/, e.g. "PCI: Keeppci_fixup_irqs()around after init" and "ARM: pci: Keeppci_common_init()around after init" IIRC.
Ah, right. Thanks for the clarification.
Arnd
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Ben DooksLe Tue, 15 May 2012 15:32:36 +0100,
Ben Dooks <[email protected]> a ?crit :
Quoted 8 lines
Yes, the number of times I've viewed the kernel and seen very similar code replicated multiple times tends to make me burst into tears.
Quoted 4 lines
* Maybe those mappings can be done using a normal
ioremap()ratherthan in ->map_io(), according to DT informations (but mostother ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)
Quoted 6 lines
That's a very old way of doing it. I'm pretty sure there's no reason to get these allocated so early.
I believe you can probably leave the PCI/PCIe bindings until you have enough kernel state to do
ioremap()or similar and then associate the necessary mappings with the bus creation.
Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?
Quoted 4 lines
Quoted 2 lines
* We probably shouldn't have anticipated this too much, and keep
only one file for this initial submission.Yes, the less we need to review the better.
We've tried to minimize as much as possible the amount of code for this initial submission. We already have some code for PCI, L2 cache support, network driver, etc, but we wanted to limit ourselves to the strict minimum to get a kernel booting with an initramfs based root filesystem.
Quoted 3 lines
Quoted 1 line
Thanks for the comments!
I'll get to testing this kernel soon, and report back
Excellent, thanks!
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 14 lines · Thomas Petazzoni
Le Tue, 15 May 2012 15:32:36 +0100,
Ben Dooks<[email protected]> a ?crit :Quoted 11 lines
Yes, the number of times I've viewed the kernel and seen very similar code replicated multiple times tends to make me burst into tears.
Quoted 4 lines
* Maybe those mappings can be done using a normal
ioremap()ratherthan in ->map_io(), according to DT informations (but mostother ARM SoC support at the moment seem to do PCI mappings using static mappings in ->map_io)
That's a very old way of doing it. I'm pretty sure there's no reason to get these allocated so early.
Quoted 7 lines
Quoted 3 lines
I believe you can probably leave the PCI/PCIe bindings until you have enough kernel state to do
ioremap()or similar and then associate the necessary mappings with the bus creation.Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?
I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 9 lines · Ben Dooks
Quoted 4 lines
Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?
I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.
No, as Rob pointed out, we might not need them early, but we definitely want a fixed address for the PIO window, which ioremap does not provide.
Arnd
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Le Tue, 15 May 2012 15:32:20 +0000,
Arnd Bergmann <[email protected]> a ?crit :
Quoted 11 lines
Quoted 7 lines
Quoted 3 lines
Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?
I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.
No, as Rob pointed out, we might not need them early, but we definitely want a fixed address for the PIO window, which ioremap does not provide.
A fixed address for the PIO window of the PCI registers? Or a fixed address for the PIO window used to access UART registers?
I would understand why a fixed address is needed for the latter, but not really for the former.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 15 lines · Thomas Petazzoni
Le Tue, 15 May 2012 15:32:20 +0000,
Arnd Bergmann <[email protected]> a ?crit :Quoted 11 lines
Quoted 7 lines
Quoted 3 lines
Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?
I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.
No, as Rob pointed out, we might not need them early, but we definitely want a fixed address for the PIO window, which ioremap does not provide.
Quoted 6 lines
A fixed address for the PIO window of the PCI registers? Or a fixed address for the PIO window used to access UART registers?
I would understand why a fixed address is needed for the latter, but not really for the former.
I'm not sure which PCI registers you mean, but we're talking about PCI I/O space. The i/o space should be a fixed virtual address so that the __io() is a constant base for ALL arm platforms. This isn't in place yet, but that is the plan. Although current macros are constant base.
Rob
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Arnd BergmannQuoted 6 lines · Arnd Bergmann
Quoted 5 lines · Ben Dooks
Quoted 4 lines
Agreed. When looking at the code, I wasn't sure why PCI mappings were needed so early. Surely, the minimal mappings to get an UART are quite useful to have very early, but why PCI?
Quoted 8 lines
Quoted 4 lines
I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.
No, as Rob pointed out, we might not need them early, but we definitely want a fixed address for the PIO window, which ioremap does not provide.
Yes, I can see a not a lot of fun with multiple PCIe busses and the need for a single IO space. You'll probably have to reserve a VM area for people to use for legacy-IO accesses.
With PCIe, there should be less old-style IO as PCIe devices are encouraged to go 32bit MMIO.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 3 lines · Ben Dooks
Yes, I can see a not a lot of fun with multiple PCIe busses and the need for a single IO space. You'll probably have to reserve a VM area for people to use for legacy-IO accesses.
Yes, that is the plan, across all platforms in the long run actually.
Quoted 2 lines
With PCIe, there should be less old-style IO as PCIe devices are encouraged to go 32bit MMIO.
It should work nonetheless.
arnd
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Ben DooksQuoted 3 lines · Ben Dooks
I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.
No. PCI needs nothing other than access to the configuration space, and the PCI IO window. There has _never_ been any hard requirement to map PCI memory in map_io() because that is _always_ done by drivers calling ioremap().
There is one exception to this: if you have a VGA card in a PCI slot, it appears by default as an ISA peripheral with the VGA memory appearing at around PCI_MEM_BASE + 640K or so. Linux expects that to already be mapped.
If you're not supporting VGA cards in text mode, that detail doesn't concern you.
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 9 lines · Russell King - ARM Linux
Quoted 3 lines · Ben Dooks
I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.
No. PCI needs nothing other than access to the configuration space, and the PCI IO window. There has _never_ been any hard requirement to map PCI memory in
map_io()because that is _always_ done by drivers callingioremap().
What about inb, outb and their related functions?
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 6 lines · Ben Dooks
Quoted 5 lines · Russell King - ARM Linux
Quoted 3 lines · Ben Dooks
I think it was because that PCI was initialised early and requires a large mapping space. It is very likely to be legacy kernel stuff that people have kept copying through.
Quoted 6 lines
Quoted 4 lines
No. PCI needs nothing other than access to the configuration space, and the PCI IO window. There has _never_ been any hard requirement to map PCI memory in
map_io()because that is _always_ done by drivers callingioremap().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.
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
In reply to Rob HerringQuoted 1 line · Rob Herring
marvell is the documented vendor string, not mrvl.
When Arnd and I were adding the initial kirkwood support for devicetree, the common wisdom was to use the stock ticker symbol when available. Hence, mrvl, iom, and dlink (only on taiwanese exchange, which uses numbers)...
thx,
Jason.
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 7 lines · Jason Cooper
Quoted 1 line · Rob Herring
marvell is the documented vendor string, not mrvl.
When Arnd and I were adding the initial kirkwood support for devicetree, the common wisdom was to use the stock ticker symbol when available. Hence, mrvl, iom, and dlink (only on taiwanese exchange, which uses numbers)...
Yes, that's true. But consistency is more important. If we have cases of both, then one needs to be deprecated.
Rob
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 11 lines · Rob Herring
Quoted 7 lines · Jason Cooper
Quoted 1 line · Rob Herring
marvell is the documented vendor string, not mrvl.
When Arnd and I were adding the initial kirkwood support for devicetree, the common wisdom was to use the stock ticker symbol when available. Hence, mrvl, iom, and dlink (only on taiwanese exchange, which uses numbers)...
Yes, that's true. But consistency is more important. If we have cases of both, then one needs to be deprecated.
I'd go for "should" instead of "needs". I would say it would be nice to settle on marvell.
There are already instances of "mrvl" in the kernel, see
drivers/i2c/busses/i2c-pxa.c drivers/tty/serial/pxa.c drivers/rtc/rtc-mv.c drivers/rtc/rtc-sa1100.c
Do people mind if the original compatibilities are left in to avoid having to rename .dts file contents, or are we happy to go with just "marvell"?
Also, it seems that some of the marvell bluetooth firmware is defined to be mrvl prefixed.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 10 lines · Ben Dooks
Quoted 9 lines · Rob Herring
Quoted 7 lines · Jason Cooper
Quoted 1 line · Rob Herring
marvell is the documented vendor string, not mrvl.
When Arnd and I were adding the initial kirkwood support for devicetree, the common wisdom was to use the stock ticker symbol when available. Hence, mrvl, iom, and dlink (only on taiwanese exchange, which uses numbers)...
Quoted 5 lines
Quoted 2 lines
Yes, that's true. But consistency is more important. If we have cases of both, then one needs to be deprecated.
I'd go for "should" instead of "needs". I would say it would be nice to settle on marvell.
Looking back on it, when Arnd and I were discussing this, I should have voiced my concerns. Stock ticker symbols are concise, unique, and generally recognizable. However, not all companies are publicly traded, nor do all stock exchanges use english contractions/abbreviations. The taiwanese stock exchange, for example, uses numerical identifiers.
Quoted 6 lines
There are already instances of "mrvl" in the kernel, see
drivers/i2c/busses/i2c-pxa.c drivers/tty/serial/pxa.c drivers/rtc/rtc-mv.c drivers/rtc/rtc-sa1100.c
drivers with dt bindings are easy to maintain reverse compatibility:
drivers/rtc/rtc-mv.c +0 -0
@@ -298,6 +298,7 @@ static int __exit mv_rtc_remove(struct
platform_device *pdev)
#ifdef CONFIG_OF
static struct of_device_id rtc_mv_of_match_table[] = {
{ .compatible = "mrvl,orion-rtc", },
+ { .compatible = "marvell,orion-rtc", },
{} };
#endif
If that ends up being necessary.
Quoted 3 lines
Do people mind if the original compatibilities are left in to avoid having to rename .dts file contents, or are we happy to go with just "marvell"?
The kirkwood DT support is young enough, I think, that everyone using it is also compiling/hacking/tweaking on it. So, if we are going to change it, now's the time.
Quoted 2 lines
Also, it seems that some of the marvell bluetooth firmware is defined to be mrvl prefixed.
It would seem you are finding a lot of evidence for "mrvl" to be preferred. So, I started digging. There's quite a bit where "marvell" is preferred:
$ git grep -l [^@]marvell,
Documentation/devicetree/bindings/marvell.txt Documentation/devicetree/bindings/net/mdio-mux-gpio.txt Documentation/devicetree/bindings/net/mdio-mux.txt arch/powerpc/boot/cuboot-c2k.c arch/powerpc/boot/dts/c2k.dts arch/powerpc/boot/dts/prpmc2800.dts arch/powerpc/boot/mv64x60.c arch/powerpc/boot/mv64x60_i2c.c arch/powerpc/boot/prpmc2800.c arch/powerpc/boot/serial.c arch/powerpc/platforms/embedded6xx/c2k.c arch/powerpc/platforms/embedded6xx/prpmc2800.c arch/powerpc/sysdev/mv64x60_dev.c arch/powerpc/sysdev/mv64x60_pci.c arch/powerpc/sysdev/mv64x60_pic.c arch/powerpc/sysdev/mv64x60_udbg.c drivers/net/phy/marvell.c
And, just to compare apples to apples:
$ git grep -l [^@]mrvl,
Documentation/devicetree/bindings/arm/mrvl.txt Documentation/devicetree/bindings/gpio/mrvl-gpio.txt Documentation/devicetree/bindings/i2c/mrvl-i2c.txt Documentation/devicetree/bindings/rtc/sa1100-rtc.txt Documentation/devicetree/bindings/serial/mrvl-serial.txt arch/arm/boot/dts/kirkwood-dreamplug.dts arch/arm/boot/dts/kirkwood.dtsi arch/arm/boot/dts/pxa168-aspenite.dts arch/arm/boot/dts/pxa168.dtsi arch/arm/mach-mmp/mmp-dt.c drivers/i2c/busses/i2c-pxa.c drivers/rtc/rtc-mv.c drivers/rtc/rtc-sa1100.c drivers/tty/serial/pxa.c
So, basically, the powerpc folks have been using "marvell", and now we're trying to change it to "mrvl".
I can't think of a technical reason to prefer one over the other. So, based purely on compatibility and uniformity, I'd say stick with "marvell". Grant, Arnd, is there something we're missing?
thx,
Jason.
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 17 lines · Jason Cooper
$ git grep -l [^@]mrvl,Documentation/devicetree/bindings/arm/mrvl.txt Documentation/devicetree/bindings/gpio/mrvl-gpio.txt Documentation/devicetree/bindings/i2c/mrvl-i2c.txt Documentation/devicetree/bindings/rtc/sa1100-rtc.txt Documentation/devicetree/bindings/serial/mrvl-serial.txt arch/arm/boot/dts/kirkwood-dreamplug.dts arch/arm/boot/dts/kirkwood.dtsi arch/arm/boot/dts/pxa168-aspenite.dts arch/arm/boot/dts/pxa168.dtsi arch/arm/mach-mmp/mmp-dt.c drivers/i2c/busses/i2c-pxa.c drivers/rtc/rtc-mv.c drivers/rtc/rtc-sa1100.c drivers/tty/serial/pxa.c
Quoted 7 lines
So, basically, the powerpc folks have been using "marvell", and now we're trying to change it to "mrvl".
I can't think of a technical reason to prefer one over the other. So, based purely on compatibility and uniformity, I'd say stick with "marvell". Grant, Arnd, is there something we're missing?
A few are now getting merged into v3.5:
$ git grep -l [^@]mrvl, Documentation/devicetree/bindings/arm/mrvl/intc.txt Documentation/devicetree/bindings/arm/mrvl/mrvl.txt Documentation/devicetree/bindings/arm/mrvl/timer.txt Documentation/devicetree/bindings/gpio/mrvl-gpio.txt Documentation/devicetree/bindings/i2c/mrvl-i2c.txt Documentation/devicetree/bindings/mtd/orion-nand.txt Documentation/devicetree/bindings/rtc/sa1100-rtc.txt Documentation/devicetree/bindings/serial/mrvl-serial.txt arch/arm/boot/dts/kirkwood-dns320.dts arch/arm/boot/dts/kirkwood-dns325.dts arch/arm/boot/dts/kirkwood-dreamplug.dts arch/arm/boot/dts/kirkwood-ib62x0.dts arch/arm/boot/dts/kirkwood-iconnect.dts arch/arm/boot/dts/kirkwood.dtsi arch/arm/boot/dts/mmp2-brownstone.dts arch/arm/boot/dts/mmp2.dtsi arch/arm/boot/dts/pxa168-aspenite.dts arch/arm/boot/dts/pxa168.dtsi arch/arm/boot/dts/pxa910-dkb.dts arch/arm/boot/dts/pxa910.dtsi arch/arm/mach-mmp/irq.c arch/arm/mach-mmp/mmp-dt.c arch/arm/mach-mmp/mmp2-dt.c arch/arm/mach-mmp/time.c drivers/gpio/gpio-pxa.c drivers/i2c/busses/i2c-pxa.c drivers/mtd/nand/orion_nand.c drivers/rtc/rtc-mv.c drivers/rtc/rtc-sa1100.c drivers/tty/serial/pxa.c
I'm fine with changing all of them from mrvl to marvell, if one of you makes a patch, I think we can send that after all the other stuff is merged.
This also needs an Ack from Haojian Zhuang, who has submitted the pxa/mmp related patches adding more "mrvl," prefixes.
Arnd
PATCH 6/8 arm: mach-armada: add support for Armada XP board with device tree
Quoted 60 lines · Arnd Bergmann
Quoted 17 lines · Jason Cooper
$ git grep -l [^@]mrvl,? ? ? ?
Documentation/devicetree/bindings/arm/mrvl.txt? ? ? ?Documentation/devicetree/bindings/gpio/mrvl-gpio.txt? ? ? ?Documentation/devicetree/bindings/i2c/mrvl-i2c.txt? ? ? ?Documentation/devicetree/bindings/rtc/sa1100-rtc.txt? ? ? ?Documentation/devicetree/bindings/serial/mrvl-serial.txt? ? ? ?arch/arm/boot/dts/kirkwood-dreamplug.dts
? ? ? ?arch/arm/boot/dts/kirkwood.dtsi
? ? ? ?arch/arm/boot/dts/pxa168-aspenite.dts
? ? ? ?arch/arm/boot/dts/pxa168.dtsi
? ? ? ?arch/arm/mach-mmp/mmp-dt.c
? ? ? ?drivers/i2c/busses/i2c-pxa.c
? ? ? ?drivers/rtc/rtc-mv.c
? ? ? ?drivers/rtc/rtc-sa1100.c
? ? ? ?drivers/tty/serial/pxa.cQuoted 7 lines
So, basically, the powerpc folks have been using "marvell", and now we're trying to change it to "mrvl".
I can't think of a technical reason to prefer one over the other. ?So, based purely on compatibility and uniformity, I'd say stick with "marvell". ?Grant, Arnd, is there something we're missing?
A few are now getting merged into v3.5:
$ git grep -l [^@]mrvl, Documentation/devicetree/bindings/arm/mrvl/intc.txt Documentation/devicetree/bindings/arm/mrvl/mrvl.txt Documentation/devicetree/bindings/arm/mrvl/timer.txt Documentation/devicetree/bindings/gpio/mrvl-gpio.txt Documentation/devicetree/bindings/i2c/mrvl-i2c.txt Documentation/devicetree/bindings/mtd/orion-nand.txt Documentation/devicetree/bindings/rtc/sa1100-rtc.txt Documentation/devicetree/bindings/serial/mrvl-serial.txt arch/arm/boot/dts/kirkwood-dns320.dts arch/arm/boot/dts/kirkwood-dns325.dts arch/arm/boot/dts/kirkwood-dreamplug.dts arch/arm/boot/dts/kirkwood-ib62x0.dts arch/arm/boot/dts/kirkwood-iconnect.dts arch/arm/boot/dts/kirkwood.dtsi arch/arm/boot/dts/mmp2-brownstone.dts arch/arm/boot/dts/mmp2.dtsi arch/arm/boot/dts/pxa168-aspenite.dts arch/arm/boot/dts/pxa168.dtsi arch/arm/boot/dts/pxa910-dkb.dts arch/arm/boot/dts/pxa910.dtsi arch/arm/mach-mmp/irq.c arch/arm/mach-mmp/mmp-dt.c arch/arm/mach-mmp/mmp2-dt.c arch/arm/mach-mmp/time.c drivers/gpio/gpio-pxa.c drivers/i2c/busses/i2c-pxa.c drivers/mtd/nand/orion_nand.c drivers/rtc/rtc-mv.c drivers/rtc/rtc-sa1100.c drivers/tty/serial/pxa.c
Quoted 9 lines
I'm fine with changing all of them from mrvl to marvell, if one of you makes a patch, I think we can send that after all the other stuff is merged.
This also needs an Ack from Haojian Zhuang, who has submitted the pxa/mmp related patches adding more "mrvl," prefixes.
? ? ? ?Arnd
PATCH 7/8 arm: mach-armada: add defconfig
In reply to Thomas PetazzoniFrom: Gregory CLEMENT <[email protected]>
--- arch/arm/configs/armada_defconfig | 47 +++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 arch/arm/configs/armada_defconfig
arch/arm/configs/armada_defconfig new file +47 -0
@@ -0,0 +1,47 @@ +CONFIG_EXPERIMENTAL=y +CONFIG_SYSVIPC=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_BLK_DEV_INITRD=y +CONFIG_EXPERT=y +CONFIG_SLAB=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_ARCH_ARMADA=y +CONFIG_MACH_ARMADA_370_DT=y +CONFIG_MACH_ARMADA_XP_DT=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_AEABI=y +CONFIG_USE_OF=y +CONFIG_ZBOOT_ROM_TEXT=0x0 +CONFIG_ZBOOT_ROM_BSS=0x0 +CONFIG_ARM_APPENDED_DTB=y +CONFIG_VFP=y +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_RUNTIME_UARTS=2 +CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_EXT2_FS=y +CONFIG_EXT3_FS=y +# CONFIG_EXT3_FS_XATTR is not set +CONFIG_ISO9660_FS=y +CONFIG_JOLIET=y +CONFIG_UDF_FS=m +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_TMPFS=y +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_CODEPAGE_850=y +CONFIG_NLS_ISO8859_1=y +CONFIG_NLS_ISO8859_2=y +CONFIG_NLS_UTF8=y +CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_FS=y +# CONFIG_SCHED_DEBUG is not set +CONFIG_TIMER_STATS=y +# CONFIG_DEBUG_BUGVERBOSE is not set +CONFIG_DEBUG_INFO=y +CONFIG_DEBUG_USER=y +CONFIG_DEBUG_LL=y +CONFIG_EARLY_PRINTK=y
Signature · 1 line
1.7.9.5
PATCH 7/8 arm: mach-armada: add defconfig
arch/arm/configs/armada_defconfig
Quoted 12 lines · Thomas Petazzoni
From: Gregory CLEMENT<[email protected]>
Signed-off-by Gregory CLEMENT<[email protected]>Signed-off-by Thomas Petazzoni<[email protected]>Signed-off-by Lior Amsalem<[email protected]>--- arch/arm/configs/armada_defconfig | 47 +++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)create mode 100644
arch/arm/configs/armada_defconfigarch/arm/configs/armada_defconfig new file +0
-0
personally, I'd go for armadaxp_defconfig.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 7/8 arm: mach-armada: add defconfig
Le Tue, 15 May 2012 10:58:39 +0100,
Ben Dooks <[email protected]> a ?crit :
Quoted 4 lines
Quoted 2 lines
(quoted diff) +0
-0b/arch/arm/configs/armada_defconfig new file mode 100644
personally, I'd go for
armadaxp_defconfig.
Unfortunately, this would be very confusing: we support both Armada XP and Armada 370 here.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 8/8 arm: mach-armada: add entry to MAINTAINERS
In reply to Thomas PetazzoniFrom: Gregory CLEMENT <[email protected]>
--- MAINTAINERS | 8 ++++++++ 1 file changed, 8 insertions(+)
MAINTAINERS +8 -0
@@ -894,6 +894,14 @@ ARM/MAGICIAN MACHINE SUPPORT M: Philipp Zabel <[email protected]> S: Maintained +ARM/Marvell Armada SOC support +M: Gregory Clement <[email protected]> +M: Thomas Petazzoni <[email protected]> +M: Lior Amsalem <[email protected]> +L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: arch/arm/mach-armada/ + ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support M: Jason Cooper <[email protected]> M: Andrew Lunn <[email protected]>
Signature · 1 line
1.7.9.5
Andrew Lunn
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Thomas PetazzoniQuoted 18 lines · Thomas Petazzoni
Arnd, Olof,
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.At the moment, both the Armada 370 and the Armada XP SoCs are supported in this directory, and we are able to build a single kernel image that boots on both SoCs. Both SoCs use the PJ4B processor, a Marvell-developed ARM core that implements the ARMv7 instruction set. We are currently using Marvell evaluation boards for both of those SoCs, and the support for those boards is added in this patch set.
This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:
Quoted 14 lines
Documentation/devicetree/bindings/arm/armada-mpic.txt | 23 + Documentation/devicetree/bindings/arm/armada-timer.txt | 11 Documentation/devicetree/bindings/arm/armada.txt | 24 + MAINTAINERS | 8 arch/arm/Kconfig | 12 arch/arm/Makefile | 1 arch/arm/boot/dts/a370-db.dts | 41 ++ arch/arm/boot/dts/a370.dtsi | 23 + arch/arm/boot/dts/armada.dtsi | 67 ++++ arch/arm/boot/dts/axp-db.dts | 40 ++ arch/arm/boot/dts/axp.dtsi | 43 +++ arch/arm/configs/armada_defconfig | 47 +++ arch/arm/mach-armada/Kconfig | 19 + arch/arm/mach-armada/Makefile | 3
Hi Thomas
Is mach-armada a good idea? What are many different armada chipsets families:
Armada 100, 300, 500, 600, 1000, 15000, XP.
You only seem to support 300 and XP. Where would the others go? 300 is actually mach-dove, etc.
Andrew
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Le Tue, 15 May 2012 11:18:38 +0200,
Andrew Lunn <[email protected]> a ?crit :
Quoted 7 lines
Is mach-armada a good idea? What are many different armada chipsets families:
Armada 100, 300, 500, 600, 1000, 15000, XP.
You only seem to support 300 and XP. Where would the others go? 300 is actually mach-dove, etc.
We support 370 and XP in this new mach directory, and we've chosen to support them in an unique directory in order to easily validate the fact that we are able to build and run a single binary kernel image that works on both SoCs.
We are definitely open to suggestions regarding the naming of the directory, or even combining with existing Marvell SoCs support if it makes sense. What would be your suggestion on this?
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Andrew LunnQuoted 6 lines · Andrew Lunn
Quoted 5 lines · Thomas Petazzoni
Arnd, Olof,
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.
I went for the arch/arm/mach-mv-armadaxp as it kept the marvell socs together (ignoring kirkwood and dove for the moment).
I'm not sure how important the naming is as long as it is clear in the Kconfig what machines are being supported by the system.
I'd say you can put the core support for multiple difference SoCs into the same directory without too much trouble, since there is now no need for multiple board files to go in there with it. Shared peripherals can either go into the relevant drivers/ directory, or in to some form of common directory such as arch/arm/common.
[snip]
Quoted 8 lines
Hi Thomas
Is mach-armada a good idea? What are many different armada chipsets families:
Armada 100, 300, 500, 600, 1000, 15000, XP.
You only seem to support 300 and XP. Where would the others go? 300 is actually mach-dove, etc.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Le Tue, 15 May 2012 10:51:35 +0100,
Ben Dooks <[email protected]> a ?crit :
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.I went for the
arch/arm/mach-mv-armadaxpas it kept the marvell socs together (ignoring kirkwood and dove for the moment).
mach-mv-armadaxp would be a good name if we supported only the Armada XP SoC, but we also support the Armada 370 SoC within the same directory. This makes it easy to build a single binary kernel image that boots and runs on both SoCs.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Andrew Lunn
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 7 lines · Thomas Petazzoni
Le Tue, 15 May 2012 10:51:35 +0100,
Ben Dooks <[email protected]> a ??crit :Quoted 4 lines
Quoted 3 lines
Quoted 3 lines
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.
Quoted 6 lines
Quoted 2 lines
I went for the
arch/arm/mach-mv-armadaxpas 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
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Thomas PetazzoniQuoted 7 lines · Thomas Petazzoni
Le Tue, 15 May 2012 10:51:35 +0100,
Ben Dooks <[email protected]> a ?crit :Quoted 4 lines
Quoted 3 lines
Quoted 3 lines
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.
Quoted 8 lines
Quoted 2 lines
I went for the
arch/arm/mach-mv-armadaxpas 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
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Le Tue, 15 May 2012 09:35:55 -0500,
Rob Herring <[email protected]> a ?crit :
Quoted 3 lines
Directory location doesn't really have anything to do with what can be in a single kernel binary. We will soon be building single images across mach directories.
Agreed, but it's not the case right now, and we wanted to submit today a kernel that boots on both of those SoCs.
The 370 and XP both use the PJ4B core, which is a Marvell implementation of an ARMv7 compatible core. The 370 has one PJ4B, and the various XP variants have a choice of 2 or 4 PJ4Bs, and various other differences. To us, it makes a lot of sense to be able to support those SoCs together in the same kernel image and in the same directory, even if both concepts are not directly tied together.
Quoted 6 lines
With some hacks and limitations, Arnd has
built (not run) omap2+, u8500, imx and one other in a single kernel. If there's overlap with dove or other platforms, then they should probably all be combined into a single mach directory. One option would be make the new mach directory somewhat generic and then later move dove or others into the new directory.
This would be one solution.
On the naming side, we are really open to what the community prefers. We knew there would be quite a bit of discussion around this, because there's a lot quite a few Marvell SoCs supported in various places, and it's not obvious what's the right place and name for a new SoC family.
What about making it mach-marvell, which would contain the DT-enabled SoC support for Marvell SoCs? We can start with 370 and XP today, and gradually add future SoCs, or even port previous SoCs as they are moved to support the device tree.
Again we're really open on the solution. Lior from Marvell can give all the necessary input to explain how the SoC family is organized.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 5 lines · Thomas Petazzoni
On the naming side, we are really open to what the community prefers. We knew there would be quite a bit of discussion around this, because there's a lot quite a few Marvell SoCs supported in various places, and it's not obvious what's the right place and name for a new SoC family.
Quoted 7 lines
What about making it mach-marvell, which would contain the DT-enabled SoC support for Marvell SoCs? We can start with 370 and XP today, and gradually add future SoCs, or even port previous SoCs as they are moved to support the device tree.
Again we're really open on the solution. Lior from Marvell can give all the necessary input to explain how the SoC family is organized.
The problem with mach-marvell is that it would be confusing in the presence of pxa/mmp which I would probably still leave out of that directory, since they are rather different inside.
I think we can just start with the existing plat-orion directory until someone comes up with a better place.
Arnd
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Le Tue, 15 May 2012 15:27:00 +0000,
Arnd Bergmann <[email protected]> a ?crit :
Quoted 3 lines
The problem with mach-marvell is that it would be confusing in the presence of pxa/mmp which I would probably still leave out of that directory, since they are rather different inside.
Sure.
Quoted 2 lines
I think we can just start with the existing plat-orion directory until someone comes up with a better place.
So you want us to put all this new source code that typically belongs to a mach-* directory into plat-orion/ ?
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 5 lines · Thomas Petazzoni
Quoted 2 lines
I think we can just start with the existing plat-orion directory until someone comes up with a better place.
So you want us to put all this new source code that typically belongs to a mach-* directory into plat-orion/ ?
Well, it's just an idea, since it would make sense to move dove/kirkwood/mv78xx0/orion5x closer together anyway, the logical choice is to use the plat-orion directory for that.
So the stages would be
1. add new platform code into plat-orion
2. move DT-based parts of dove/kirkwood/mv78xx0/orion5x into plat-orion
3. over time phase out the other directories as they fall into disuse
4. rename plat-orion to mach-orion
As you point out, the ugly part of this is that we'd end up having code in a plat-* directory that doesn't really belong there.
Another way would be to reorganize those directories upfront:
plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.h
and then go from there. The differences between the headers are fairly small already, so that should be manageable.
Arnd
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 8 lines · Arnd Bergmann
Another way would be to reorganize those directories upfront:
plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.hand then go from there. The differences between the headers are fairly small already, so that should be manageable.
Actually we could do a trivial move of all files into one directory at any time, e.g. at the end of the merge window, to minimize conflicts with other patches.
This is a semi-automated move of all plat-orion based machines into a single mach-orion directory, and we could of course add the new stuff in there as well. I've specifically tried to keep this move simple, even if that means a lot of the easy cleanups for code that are mostly identical are not done here. Cleanups after this could come one at a time to reduce this duplication and simplify the platform.
Obvious next steps are to merge the various Makefile and Kconfig files as well as all the headers, and to actually allow building stuff together.
arch/arm/mach-dove/Makefile.boot | 3 -- arch/arm/mach-dove/include/mach/gpio.h | 9 ------- arch/arm/mach-dove/include/mach/hardware.h | 19 ---------------- arch/arm/mach-kirkwood/include/mach/gpio.h | 9 ------- arch/arm/mach-kirkwood/include/mach/hardware.h | 14 ------------ arch/arm/mach-kirkwood/include/mach/timex.h | 10 -------- arch/arm/mach-mv78xx0/Makefile.boot | 3 -- arch/arm/mach-mv78xx0/include/mach/gpio.h | 9 ------- arch/arm/mach-mv78xx0/include/mach/hardware.h | 14 ------------ arch/arm/mach-mv78xx0/include/mach/timex.h | 9 ------- arch/arm/mach-orion5x/Makefile.boot | 3 -- arch/arm/mach-orion5x/include/mach/gpio.h | 9 ------- arch/arm/mach-orion5x/include/mach/hardware.h | 14 ------------ arch/arm/mach-orion5x/include/mach/timex.h | 11 --------- arch/arm/plat-orion/Makefile | 10 -------- b/arch/arm/Kconfig | 8 ------- b/arch/arm/Makefile | 9 +++---- b/arch/arm/mach-orion/Kconfig | 7 ++++++ b/arch/arm/mach-orion/Makefile | 26 +++++++++++++++++++++++ b/arch/arm/mach-orion/Makefile.dove | 2 - b/arch/arm/mach-orion/Makefile.kirkwood | 2 - b/arch/arm/mach-orion/Makefile.mv78xx0 | 2 - b/arch/arm/mach-orion/Makefile.orion5x | 2 - b/arch/arm/mach-orion/addr-map-dove.c | 4 +-- b/arch/arm/mach-orion/addr-map-kirkwood.c | 4 +-- b/arch/arm/mach-orion/addr-map-mv78xx0.c | 4 +-- b/arch/arm/mach-orion/addr-map-orion5x.c | 4 +-- b/arch/arm/mach-orion/addr-map.c | 2 - b/arch/arm/mach-orion/board-dnskw.c | 4 +-- b/arch/arm/mach-orion/board-dreamplug.c | 6 ++--- b/arch/arm/mach-orion/board-dt.c | 2 - b/arch/arm/mach-orion/board-ib62x0.c | 4 +-- b/arch/arm/mach-orion/board-iconnect.c | 4 +-- b/arch/arm/mach-orion/buffalo-wxl-setup.c | 4 +-- b/arch/arm/mach-orion/cm-a510.c | 2 - b/arch/arm/mach-orion/common.c | 6 ++--- b/arch/arm/mach-orion/d2net-setup.c | 4 +-- b/arch/arm/mach-orion/d2net_v2-setup.c | 4 +-- b/arch/arm/mach-orion/db78x00-bp-setup.c | 2 - b/arch/arm/mach-orion/db88f5281-setup.c | 6 ++--- b/arch/arm/mach-orion/db88f6281-bp-setup.c | 6 ++--- b/arch/arm/mach-orion/dns323-setup.c | 4 +-- b/arch/arm/mach-orion/dockstar-setup.c | 6 ++--- b/arch/arm/mach-orion/dove-db-setup.c | 2 - b/arch/arm/mach-orion/dove.c | 10 ++++---- b/arch/arm/mach-orion/edmini_v2-setup.c | 4 +-- b/arch/arm/mach-orion/guruplug-setup.c | 6 ++--- b/arch/arm/mach-orion/include/mach/bridge-regs.h | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/debug-macro.S | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/entry-macro.S | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/hardware.h | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/io.h | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/irqs.h | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/uncompress.h | 12 ++++++++++ b/arch/arm/mach-orion/irq-dove.c | 4 +-- b/arch/arm/mach-orion/irq-kirkwood.c | 4 +-- b/arch/arm/mach-orion/irq-mv78xx0.c | 4 +-- b/arch/arm/mach-orion/irq-orion5x.c | 4 +-- b/arch/arm/mach-orion/irq.c | 2 - b/arch/arm/mach-orion/kirkwood.c | 18 +++++++-------- b/arch/arm/mach-orion/kurobox_pro-setup.c | 6 ++--- b/arch/arm/mach-orion/lacie_v2-common.c | 4 +-- b/arch/arm/mach-orion/ls-chl-setup.c | 4 +-- b/arch/arm/mach-orion/ls_hgl-setup.c | 4 +-- b/arch/arm/mach-orion/lsmini-setup.c | 4 +-- b/arch/arm/mach-orion/mpp-dove.c | 4 +-- b/arch/arm/mach-orion/mpp-kirkwood.c | 6 ++--- b/arch/arm/mach-orion/mpp-mv78xx0.c | 6 ++--- b/arch/arm/mach-orion/mpp-orion5x.c | 6 ++--- b/arch/arm/mach-orion/mpp.c | 2 - b/arch/arm/mach-orion/mss2-setup.c | 4 +-- b/arch/arm/mach-orion/mv2120-setup.c | 4 +-- b/arch/arm/mach-orion/mv78xx0.c | 14 ++++++------ b/arch/arm/mach-orion/mv88f6281gtw_ge-setup.c | 4 +-- b/arch/arm/mach-orion/net2big-setup.c | 4 +-- b/arch/arm/mach-orion/netspace_v2-setup.c | 4 +-- b/arch/arm/mach-orion/netxbig_v2-setup.c | 4 +-- b/arch/arm/mach-orion/openrd-setup.c | 6 ++--- b/arch/arm/mach-orion/orion5x.c | 12 +++++----- b/arch/arm/mach-orion/pci-orion5x.c | 6 ++--- b/arch/arm/mach-orion/pcie-dove.c | 6 ++--- b/arch/arm/mach-orion/pcie-kirkwood.c | 6 ++--- b/arch/arm/mach-orion/pcie-mv78xx0.c | 6 ++--- b/arch/arm/mach-orion/pcie.c | 4 +-- b/arch/arm/mach-orion/rd78x00-masa-setup.c | 2 - b/arch/arm/mach-orion/rd88f5181l-fxo-setup.c | 4 +-- b/arch/arm/mach-orion/rd88f5181l-ge-setup.c | 4 +-- b/arch/arm/mach-orion/rd88f5182-setup.c | 4 +-- b/arch/arm/mach-orion/rd88f6183ap-ge-setup.c | 2 - b/arch/arm/mach-orion/rd88f6192-nas-setup.c | 2 - b/arch/arm/mach-orion/rd88f6281-setup.c | 6 ++--- b/arch/arm/mach-orion/sheevaplug-setup.c | 6 ++--- b/arch/arm/mach-orion/t5325-setup.c | 4 +-- b/arch/arm/mach-orion/terastation_pro2-setup.c | 4 +-- b/arch/arm/mach-orion/ts209-setup.c | 4 +-- b/arch/arm/mach-orion/ts219-setup.c | 4 +-- b/arch/arm/mach-orion/ts409-setup.c | 4 +-- b/arch/arm/mach-orion/ts41x-setup.c | 6 ++--- b/arch/arm/mach-orion/ts78xx-setup.c | 4 +-- b/arch/arm/mach-orion/tsx09-common.c | 2 - b/arch/arm/mach-orion/tsx1x-common.c | 2 - b/arch/arm/mach-orion/wnr854t-setup.c | 4 +-- b/arch/arm/mach-orion/wrt350n-v2-setup.c | 4 +-- b/arch/arm/mm/cache-feroceon-l2.c | 2 - b/drivers/dma/mv_xor.c | 2 - b/drivers/mmc/host/mvsdio.c | 2 - b/drivers/mtd/nand/orion_nand.c | 2 - b/drivers/usb/host/ehci-orion.c | 2 - b/drivers/watchdog/orion_wdt.c | 2 - b/sound/soc/kirkwood/kirkwood-i2s.c | 2 - b/sound/soc/kirkwood/kirkwood-openrd.c | 2 - b/sound/soc/kirkwood/kirkwood-t5325.c | 2 - 112 files changed, 306 insertions(+), 342 deletions(-)
arch/arm/Kconfig +1 -7
@@ -1013,8 +1013,6 @@ source "arch/arm/mach-cns3xxx/Kconfig" source "arch/arm/mach-davinci/Kconfig" -source "arch/arm/mach-dove/Kconfig" - source "arch/arm/mach-ep93xx/Kconfig" source "arch/arm/mach-footbridge/Kconfig"
@@ -1033,16 +1031,12 @@ source "arch/arm/mach-iop13xx/Kconfig" source "arch/arm/mach-ixp4xx/Kconfig" -source "arch/arm/mach-kirkwood/Kconfig" - source "arch/arm/mach-ks8695/Kconfig" source "arch/arm/mach-lpc32xx/Kconfig" source "arch/arm/mach-msm/Kconfig" -source "arch/arm/mach-mv78xx0/Kconfig" - source "arch/arm/plat-mxc/Kconfig" source "arch/arm/mach-mxs/Kconfig"
@@ -1058,7 +1052,7 @@ source "arch/arm/mach-omap1/Kconfig" source "arch/arm/mach-omap2/Kconfig" -source "arch/arm/mach-orion5x/Kconfig" +source "arch/arm/mach-orion/Kconfig" source "arch/arm/mach-pxa/Kconfig" source "arch/arm/plat-pxa/Kconfig"
arch/arm/Makefile +4 -5
@@ -139,7 +139,7 @@ machine-$(CONFIG_ARCH_BCMRING) := bcmring machine-$(CONFIG_ARCH_CLPS711X) := clps711x machine-$(CONFIG_ARCH_CNS3XXX) := cns3xxx machine-$(CONFIG_ARCH_DAVINCI) := davinci -machine-$(CONFIG_ARCH_DOVE) := dove +machine-$(CONFIG_ARCH_DOVE) := orion machine-$(CONFIG_ARCH_EBSA110) := ebsa110 machine-$(CONFIG_ARCH_EP93XX) := ep93xx machine-$(CONFIG_ARCH_GEMINI) := gemini
@@ -150,12 +150,12 @@ machine-$(CONFIG_ARCH_IOP13XX) := iop13xx machine-$(CONFIG_ARCH_IOP32X) := iop32x machine-$(CONFIG_ARCH_IOP33X) := iop33x machine-$(CONFIG_ARCH_IXP4XX) := ixp4xx -machine-$(CONFIG_ARCH_KIRKWOOD) := kirkwood +machine-$(CONFIG_ARCH_KIRKWOOD) := orion machine-$(CONFIG_ARCH_KS8695) := ks8695 machine-$(CONFIG_ARCH_LPC32XX) := lpc32xx machine-$(CONFIG_ARCH_MMP) := mmp machine-$(CONFIG_ARCH_MSM) := msm -machine-$(CONFIG_ARCH_MV78XX0) := mv78xx0 +machine-$(CONFIG_ARCH_MV78XX0) := orion machine-$(CONFIG_ARCH_IMX_V4_V5) := imx machine-$(CONFIG_ARCH_IMX_V6_V7) := imx machine-$(CONFIG_ARCH_MXS) := mxs
@@ -163,7 +163,7 @@ machine-$(CONFIG_ARCH_NETX) := netx machine-$(CONFIG_ARCH_NOMADIK) := nomadik machine-$(CONFIG_ARCH_OMAP1) := omap1 machine-$(CONFIG_ARCH_OMAP2PLUS) := omap2 -machine-$(CONFIG_ARCH_ORION5X) := orion5x +machine-$(CONFIG_ARCH_ORION5X) := orion machine-$(CONFIG_ARCH_PICOXCELL) := picoxcell machine-$(CONFIG_ARCH_PNX4008) := pnx4008 machine-$(CONFIG_ARCH_PRIMA2) := prima2
@@ -204,7 +204,6 @@ plat-$(CONFIG_ARCH_S3C64XX) := samsung plat-$(CONFIG_ARCH_ZYNQ) := versatile plat-$(CONFIG_PLAT_IOP) := iop plat-$(CONFIG_PLAT_NOMADIK) := nomadik -plat-$(CONFIG_PLAT_ORION) := orion plat-$(CONFIG_PLAT_PXA) := pxa plat-$(CONFIG_PLAT_S3C24XX) := s3c24xx samsung plat-$(CONFIG_PLAT_S5P) := samsung
arch/arm/mach-dove/Makefile.boot deleted +0 -3
@@ -1,3 +0,0 @@ - zreladdr-y += 0x00008000 -params_phys-y := 0x00000100 -initrd_phys-y := 0x00800000
arch/arm/mach-dove/include/mach/gpio.h deleted +0 -9
@@ -1,9 +0,0 @@ -/* -* arch/arm/mach-dove/include/mach/gpio.h -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#include <plat/gpio.h>
arch/arm/mach-dove/include/mach/hardware.h deleted +0 -19
@@ -1,19 +0,0 @@ -/* -* arch/arm/mach-dove/include/mach/hardware.h -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#ifndef __ASM_ARCH_HARDWARE_H -#define __ASM_ARCH_HARDWARE_H - -#include "dove.h" - -/* Macros below are required for compatibility with PXA AC'97 driver. */ -#define __REG (x) (*((volatile u32 *)((x) - DOVE_SB_REGS_PHYS_BASE + \ - DOVE_SB_REGS_VIRT_BASE))) -#define __PREG (x) (((u32)&(x)) - DOVE_SB_REGS_VIRT_BASE + \ - DOVE_SB_REGS_PHYS_BASE) -#endif
arch/arm/mach-kirkwood/include/mach/gpio.h deleted +0 -9
@@ -1,9 +0,0 @@ -/* -* arch/asm-arm/mach-kirkwood/include/mach/gpio.h -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#include <plat/gpio.h>
arch/arm/mach-kirkwood/include/mach/hardware.h deleted +0 -14
@@ -1,14 +0,0 @@ -/* -* arch/arm/mach-kirkwood/include/mach/hardware.h -* -* This program is free software; you can redistribute it and/or modify -* it under the terms of the GNU General Public License version 2 as -* published by the Free Software Foundation. -*/ - -#ifndef __ASM_ARCH_HARDWARE_H -#define __ASM_ARCH_HARDWARE_H - -#include "kirkwood.h" - -#endif
arch/arm/mach-kirkwood/include/mach/timex.h deleted +0 -10
@@ -1,10 +0,0 @@ -/* -* arch/arm/mach-kirkwood/include/mach/timex.h -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#define CLOCK_TICK_RATE (100 * HZ) -
arch/arm/mach-mv78xx0/Makefile.boot deleted +0 -3
@@ -1,3 +0,0 @@ - zreladdr-y += 0x00008000 -params_phys-y := 0x00000100 -initrd_phys-y := 0x00800000
arch/arm/mach-mv78xx0/include/mach/gpio.h deleted +0 -9
@@ -1,9 +0,0 @@ -/* -* arch/asm-arm/mach-mv78xx0/include/mach/gpio.h -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#include <plat/gpio.h>
arch/arm/mach-mv78xx0/include/mach/hardware.h deleted +0 -14
@@ -1,14 +0,0 @@ -/* -* arch/arm/mach-mv78xx0/include/mach/hardware.h -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#ifndef __ASM_ARCH_HARDWARE_H -#define __ASM_ARCH_HARDWARE_H - -#include "mv78xx0.h" - -#endif
arch/arm/mach-mv78xx0/include/mach/timex.h deleted +0 -9
@@ -1,9 +0,0 @@ -/* -* arch/arm/mach-mv78xx0/include/mach/timex.h -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#define CLOCK_TICK_RATE (100 * HZ)
arch/arm/mach-orion/Kconfig new file +7 -0
@@ -0,0 +1,7 @@ +source "arch/arm/mach-orion/Kconfig.dove" + +source "arch/arm/mach-orion/Kconfig.kirkwood" + +source "arch/arm/mach-orion/Kconfig.mv78xx0" + +source "arch/arm/mach-orion/Kconfig.orion5x"
arch/arm/mach-orion/Kconfig.dove renamed from arch/arm/mach-dove/Kconfig +0 -0
arch/arm/mach-orion/Kconfig.kirkwood renamed from arch/arm/mach-kirkwood/Kconfig +0 -0
arch/arm/mach-orion/Kconfig.mv78xx0 renamed from arch/arm/mach-mv78xx0/Kconfig +0 -0
arch/arm/mach-orion/Kconfig.orion5x renamed from arch/arm/mach-orion5x/Kconfig +0 -0
arch/arm/mach-orion/Makefile new file +26 -0
@@ -0,0 +1,26 @@ +# +# Makefile for the linux kernel. +# + +obj-y := irq.o pcie.o time.o common.o mpp.o addr-map.o +obj-m := +obj-n := +obj- := + +obj-$(CONFIG_GENERIC_GPIO) += gpio.o + +ifdef CONFIG_ARCH_DOVE +include arch/arm/mach-orion/Makefile.dove +endif + +ifdef CONFIG_ARCH_KIRKWOOD +include arch/arm/mach-orion/Makefile.kirkwood +endif + +ifdef CONFIG_ARCH_MV78xx0 +include arch/arm/mach-orion/Makefile.mv78xx0 +endif + +ifdef CONFIG_ARCH_ORION5X +include arch/arm/mach-orion/Makefile.orion5x +endif
arch/arm/mach-orion/Makefile.boot renamed from arch/arm/mach-kirkwood/Makefile.boot +0 -0
arch/arm/mach-orion/Makefile.dove renamed from arch/arm/mach-dove/Makefile +1 -1
@@ -1,4 +1,4 @@ -obj-y += common.o addr-map.o irq.o pcie.o mpp.o +obj-y += dove.o addr-map-dove.o irq-dove.o pcie-dove.o mpp-dove.o obj-$(CONFIG_MACH_DOVE_DB) += dove-db-setup.o obj-$(CONFIG_MACH_CM_A510) += cm-a510.o
arch/arm/mach-orion/Makefile.kirkwood renamed from arch/arm/mach-kirkwood/Makefile +1 -1
@@ -1,4 +1,4 @@ -obj-y += common.o addr-map.o irq.o pcie.o mpp.o +obj-y += kirkwood.o addr-map-kirkwood.o irq-kirkwood.o pcie-kirkwood.o mpp-kirkwood.o obj-$(CONFIG_MACH_DB88F6281_BP) += db88f6281-bp-setup.o obj-$(CONFIG_MACH_RD88F6192_NAS) += rd88f6192-nas-setup.o
arch/arm/mach-orion/Makefile.mv78xx0 renamed from arch/arm/mach-mv78xx0/Makefile +1 -1
@@ -1,4 +1,4 @@ -obj-y += common.o addr-map.o mpp.o irq.o pcie.o +obj-y += mv78xx0.o addr-map-mv78xx0.o mpp-mv78xx0.o irq-mv78xx0.o pcie-mv78xx0.o obj-$(CONFIG_MACH_DB78X00_BP) += db78x00-bp-setup.o obj-$(CONFIG_MACH_RD78X00_MASA) += rd78x00-masa-setup.o obj-$(CONFIG_MACH_TERASTATION_WXL) += buffalo-wxl-setup.o
arch/arm/mach-orion/Makefile.orion5x renamed from arch/arm/mach-orion5x/Makefile +1 -1
@@ -1,4 +1,4 @@ -obj-y += common.o addr-map.o pci.o irq.o mpp.o +obj-y += orion5x.o addr-map-orion5x.o pci-orion5x.o irq-orion5x.o mpp-orion5x.o obj-$(CONFIG_MACH_DB88F5281) += db88f5281-setup.o obj-$(CONFIG_MACH_RD88F5182) += rd88f5182-setup.o obj-$(CONFIG_MACH_KUROBOX_PRO) += kurobox_pro-setup.o
arch/arm/mach-orion/addr-map-dove.c renamed from arch/arm/mach-dove/addr-map.c +2 -2
@@ -15,8 +15,8 @@#include <asm/mach/arch.h> #include <asm/setup.h> #include <mach/dove.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/addr-map.h> +#include "dove.h" /* * Generic Address Decode Windows bit settings
arch/arm/mach-orion/addr-map-kirkwood.c renamed from arch/arm/mach-kirkwood/addr-map.c +2 -2
@@ -13,8 +13,8 @@#include <linux/mbus.h> #include <linux/io.h> #include <mach/hardware.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/addr-map.h> +#include "kirkwood.h" /* * Generic Address Decode Windows bit settings
arch/arm/mach-orion/addr-map-mv78xx0.c renamed from arch/arm/mach-mv78xx0/addr-map.c +2 -2
@@ -12,8 +12,8 @@#include <linux/init.h> #include <linux/mbus.h> #include <linux/io.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/addr-map.h> +#include "mv78xx0.h" /* * Generic Address Decode Windows bit settings
arch/arm/mach-orion/addr-map-orion5x.c renamed from arch/arm/mach-orion5x/addr-map.c +2 -2
@@ -15,8 +15,8 @@#include <linux/mbus.h> #include <linux/io.h> #include <mach/hardware.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/addr-map.h> +#include "orion5x.h" /* * The Orion has fully programmable address map. There's a separate address
arch/arm/mach-orion/addr-map.c renamed from arch/arm/plat-orion/addr-map.c +1 -1
@@ -13,7 +13,7 @@#include <linux/init.h> #include <linux/mbus.h> #include <linux/io.h> -#include <plat/addr-map.h> +#include <mach/addr-map.h> struct mbus_dram_target_info orion_mbus_dram_info;
arch/arm/mach-orion/board-dnskw.c renamed from arch/arm/mach-kirkwood/board-dnskw.c +2 -2
@@ -28,8 +28,8 @@#include <asm/mach/map.h> #include <mach/kirkwood.h> #include <mach/bridge-regs.h> -#include "common.h" -#include "mpp.h" +#include "kirkwood.h" +#include "mpp-kirkwood.h" static struct mv643xx_eth_platform_data dnskw_ge00_data = { .phy_addr =MV643XX_ETH_PHY_ADDR (8 ),
arch/arm/mach-orion/board-dreamplug.c renamed from arch/arm/mach-kirkwood/board-dreamplug.c +3 -3
@@ -33,9 +33,9 @@#include <asm/mach/map.h> #include <mach/kirkwood.h> #include <mach/bridge-regs.h> -#include <plat/mvsdio.h> -#include "common.h" -#include "mpp.h" +#include <mach/mvsdio.h> +#include "kirkwood.h" +#include "mpp-kirkwood.h" struct mtd_partition dreamplug_partitions[] = { {
arch/arm/mach-orion/board-dt.c renamed from arch/arm/mach-kirkwood/board-dt.c +1 -1
@@ -18,7 +18,7 @@#include <asm/mach/arch.h> #include <asm/mach/map.h> #include <mach/bridge-regs.h> -#include "common.h" +#include "kirkwood.h" static struct of_device_id kirkwood_dt_match_table[]__initdata = { { .compatible ="simple-bus" , },
arch/arm/mach-orion/board-ib62x0.c renamed from arch/arm/mach-kirkwood/board-ib62x0.c +2 -2
@@ -24,8 +24,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include "common.h" -#include "mpp.h" +#include "kirkwood.h" +#include "mpp-kirkwood.h" #define IB62X0_GPIO_POWER_OFF 24
arch/arm/mach-orion/board-iconnect.c renamed from arch/arm/mach-kirkwood/board-iconnect.c +2 -2
@@ -28,8 +28,8 @@#include <linux/gpio_keys.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include "common.h" -#include "mpp.h" +#include "kirkwood.h" +#include "mpp-kirkwood.h" static struct mv643xx_eth_platform_data iconnect_ge00_data = { .phy_addr =MV643XX_ETH_PHY_ADDR (11 ),
arch/arm/mach-orion/buffalo-wxl-setup.c renamed from arch/arm/mach-mv78xx0/buffalo-wxl-setup.c +2 -2
@@ -20,8 +20,8 @@#include <mach/mv78xx0.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> -#include "common.h" -#include "mpp.h" +#include "mv78xx0.h" +#include "mpp-mv78xx0.h" /* This arch has 2 Giga Ethernet */
arch/arm/mach-orion/cm-a510.c renamed from arch/arm/mach-dove/cm-a510.c +1 -1
@@ -24,7 +24,7 @@#include <mach/dove.h> -#include "common.h" +#include "dove.h" static struct mv643xx_eth_platform_data cm_a510_ge00_data = { .phy_addr =MV643XX_ETH_PHY_ADDR_DEFAULT ,
arch/arm/mach-orion/common.c renamed from arch/arm/plat-orion/common.c +3 -3
@@ -18,9 +18,9 @@#include <linux/mv643xx_i2c.h> #include <net/dsa.h> #include <linux/spi/orion_spi.h> -#include <plat/orion_wdt.h> -#include <plat/mv_xor.h> -#include <plat/ehci-orion.h> +#include <mach/orion_wdt.h> +#include <mach/mv_xor.h> +#include <mach/ehci-orion.h> #include <mach/bridge-regs.h> /* Fill in the resources structure and link it into the platform
arch/arm/mach-orion/cpuidle.c renamed from arch/arm/mach-kirkwood/cpuidle.c +0 -0
arch/arm/mach-orion/d2net-setup.c renamed from arch/arm/mach-orion5x/d2net-setup.c +2 -2
@@ -27,8 +27,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * LaCie d2 Network Info
arch/arm/mach-orion/d2net_v2-setup.c renamed from arch/arm/mach-kirkwood/d2net_v2-setup.c +2 -2
@@ -33,8 +33,8 @@#include <asm/mach/arch.h> #include <mach/kirkwood.h> #include <mach/leds-ns2.h> -#include "common.h" -#include "mpp.h" +#include "kirkwood.h" +#include "mpp-kirkwood.h" #include "lacie_v2-common.h" /*****************************************************************************
arch/arm/mach-orion/db78x00-bp-setup.c renamed from arch/arm/mach-mv78xx0/db78x00-bp-setup.c +1 -1
@@ -18,7 +18,7 @@#include <mach/mv78xx0.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> -#include "common.h" +#include "mv78xx0.h" static struct mv643xx_eth_platform_data db78x00_ge00_data = { .phy_addr =MV643XX_ETH_PHY_ADDR (8 ),
arch/arm/mach-orion/db88f5281-setup.c renamed from arch/arm/mach-orion5x/db88f5281-setup.c +3 -3
@@ -24,9 +24,9 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include <plat/orion_nand.h> -#include "common.h" -#include "mpp.h" +#include <mach/orion_nand.h> +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * DB-88F5281 on board devices
arch/arm/mach-orion/db88f6281-bp-setup.c renamed from arch/arm/mach-kirkwood/db88f6281-bp-setup.c +3 -3
@@ -17,9 +17,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include <plat/mvsdio.h> -#include "common.h" -#include "mpp.h" +#include <mach/mvsdio.h> +#include "kirkwood.h" +#include "mpp-kirkwood.h" static struct mtd_partition db88f6281_nand_parts[] = { {
arch/arm/mach-orion/dns323-setup.c renamed from arch/arm/mach-orion5x/dns323-setup.c +2 -2
@@ -34,8 +34,8 @@#include <asm/mach/pci.h> #include <asm/system_info.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /* Rev A1 and B1 */ #define DNS323_GPIO_LED_RIGHT_AMBER 1
arch/arm/mach-orion/dockstar-setup.c renamed from arch/arm/mach-kirkwood/dockstar-setup.c +3 -3
@@ -19,9 +19,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include <plat/mvsdio.h> -#include "common.h" -#include "mpp.h" +#include <mach/mvsdio.h> +#include "kirkwood.h" +#include "mpp-kirkwood.h" static struct mtd_partition dockstar_nand_parts[] = { {
arch/arm/mach-orion/dove-db-setup.c renamed from arch/arm/mach-dove/dove-db-setup.c +1 -1
@@ -26,7 +26,7 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/dove.h> -#include "common.h" +#include "dove.h" static struct mv643xx_eth_platform_data dove_db_ge00_data = { .phy_addr =MV643XX_ETH_PHY_ADDR_DEFAULT ,
arch/arm/mach-orion/dove.c renamed from arch/arm/mach-dove/common.c +5 -5
@@ -27,11 +27,11 @@#include <mach/bridge-regs.h> #include <asm/mach/arch.h> #include <linux/irq.h> -#include <plat/time.h> -#include <plat/ehci-orion.h> -#include <plat/common.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/time.h> +#include <mach/ehci-orion.h> +#include <mach/common.h> +#include <mach/addr-map.h> +#include "dove.h" static int get_tclk (void );
arch/arm/mach-orion/dove.h renamed from arch/arm/mach-dove/common.h +0 -0
arch/arm/mach-orion/edmini_v2-setup.c renamed from arch/arm/mach-orion5x/edmini_v2-setup.c +2 -2
@@ -35,8 +35,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * EDMINI_V2 Info
arch/arm/mach-orion/gpio.c renamed from arch/arm/plat-orion/gpio.c +0 -0
arch/arm/mach-orion/guruplug-setup.c renamed from arch/arm/mach-kirkwood/guruplug-setup.c +3 -3
@@ -19,9 +19,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include <plat/mvsdio.h> -#include "common.h" -#include "mpp.h" +#include <mach/mvsdio.h> +#include "kirkwood.h" +#include "mpp-kirkwood.h" static struct mtd_partition guruplug_nand_parts[] = { {
arch/arm/mach-orion/include/mach/addr-map.h renamed from arch/arm/plat-orion/include/plat/addr-map.h +0 -0
arch/arm/mach-orion/include/mach/audio.h renamed from arch/arm/plat-orion/include/plat/audio.h +0 -0
arch/arm/mach-orion/include/mach/bridge-regs-dove.h renamed from arch/arm/mach-dove/include/mach/bridge-regs.h +0 -0
arch/arm/mach-orion/include/mach/bridge-regs-kirkwood.h renamed from arch/arm/mach-kirkwood/include/mach/bridge-regs.h +0 -0
arch/arm/mach-orion/include/mach/bridge-regs-mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/bridge-regs.h +0 -0
arch/arm/mach-orion/include/mach/bridge-regs-orion5x.h renamed from arch/arm/mach-orion5x/include/mach/bridge-regs.h +0 -0
arch/arm/mach-orion/include/mach/bridge-regs.h new file +12 -0
@@ -0,0 +1,12 @@ +#ifdef CONFIG_ARCH_DOVE +#include <mach/bridge-regs-dove.h> +#endif +#ifdef CONFIG_ARCH_KIRKWOOD +#include <mach/bridge-regs-kirkwood.h> +#endif +#ifdef CONFIG_ARCH_MV78XX0 +#include <mach/bridge-regs-mv78xx0.h> +#endif +#ifdef CONFIG_ARCH_ORION5X +#include <mach/bridge-regs-orion5x.h> +#endif
arch/arm/mach-orion/include/mach/cache-feroceon-l2.h renamed from arch/arm/plat-orion/include/plat/cache-feroceon-l2.h +0 -0
arch/arm/mach-orion/include/mach/common.h renamed from arch/arm/plat-orion/include/plat/common.h +0 -0
arch/arm/mach-orion/include/mach/debug-macro-dove.S renamed from arch/arm/mach-dove/include/mach/debug-macro.S +0 -0
arch/arm/mach-orion/include/mach/debug-macro-kirkwood.S renamed from arch/arm/mach-kirkwood/include/mach/debug-macro.S +0 -0
arch/arm/mach-orion/include/mach/debug-macro-mv78xx0.S renamed from arch/arm/mach-mv78xx0/include/mach/debug-macro.S +0 -0
arch/arm/mach-orion/include/mach/debug-macro-orion5x.S renamed from arch/arm/mach-orion5x/include/mach/debug-macro.S +0 -0
arch/arm/mach-orion/include/mach/debug-macro.S new file +12 -0
@@ -0,0 +1,12 @@ +#ifdef CONFIG_ARCH_DOVE +#include <mach/debug-macro-dove.S> +#endif +#ifdef CONFIG_ARCH_KIRKWOOD +#include <mach/debug-macro-kirkwood.S> +#endif +#ifdef CONFIG_ARCH_MV78XX0 +#include <mach/debug-macro-mv78xx0.S> +#endif +#ifdef CONFIG_ARCH_ORION5X +#include <mach/debug-macro-orion5x.S> +#endif
arch/arm/mach-orion/include/mach/dove.h renamed from arch/arm/mach-dove/include/mach/dove.h +0 -0
arch/arm/mach-orion/include/mach/ehci-orion.h renamed from arch/arm/plat-orion/include/plat/ehci-orion.h +0 -0
arch/arm/mach-orion/include/mach/entry-macro-dove.S renamed from arch/arm/mach-dove/include/mach/entry-macro.S +0 -0
arch/arm/mach-orion/include/mach/entry-macro-kirkwood.S renamed from arch/arm/mach-kirkwood/include/mach/entry-macro.S +0 -0
arch/arm/mach-orion/include/mach/entry-macro-mv78xx0.S renamed from arch/arm/mach-mv78xx0/include/mach/entry-macro.S +0 -0
arch/arm/mach-orion/include/mach/entry-macro-orion5x.S renamed from arch/arm/mach-orion5x/include/mach/entry-macro.S +0 -0
arch/arm/mach-orion/include/mach/entry-macro.S new file +12 -0
@@ -0,0 +1,12 @@ +#ifdef CONFIG_ARCH_DOVE +#include <mach/entry-macro-dove.S> +#endif +#ifdef CONFIG_ARCH_KIRKWOOD +#include <mach/entry-macro-kirkwood.S> +#endif +#ifdef CONFIG_ARCH_MV78XX0 +#include <mach/entry-macro-mv78xx0.S> +#endif +#ifdef CONFIG_ARCH_ORION5X +#include <mach/entry-macro-orion5x.S> +#endif
arch/arm/mach-orion/include/mach/gpio.h renamed from arch/arm/plat-orion/include/plat/gpio.h +0 -0
arch/arm/mach-orion/include/mach/hardware.h new file +12 -0
@@ -0,0 +1,12 @@ +#ifdef CONFIG_ARCH_DOVE +#include <mach/dove.h> +#endif +#ifdef CONFIG_ARCH_KIRKWOOD +#include <mach/kirkwood.h> +#endif +#ifdef CONFIG_ARCH_MV78XX0 +#include <mach/mv78xx0.h> +#endif +#ifdef CONFIG_ARCH_ORION5X +#include <mach/orion5x.h> +#endif
arch/arm/mach-orion/include/mach/io-dove.h renamed from arch/arm/mach-dove/include/mach/io.h +0 -0
arch/arm/mach-orion/include/mach/io-kirkwood.h renamed from arch/arm/mach-kirkwood/include/mach/io.h +0 -0
arch/arm/mach-orion/include/mach/io-mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/io.h +0 -0
arch/arm/mach-orion/include/mach/io.h new file +12 -0
@@ -0,0 +1,12 @@ +#ifdef CONFIG_ARCH_DOVE +#include <mach/io-dove.h> +#endif +#ifdef CONFIG_ARCH_KIRKWOOD +#include <mach/io-kirkwood.h> +#endif +#ifdef CONFIG_ARCH_MV78XX0 +#include <mach/io-mv78xx0.h> +#endif +#ifdef CONFIG_ARCH_ORION5X +#include <mach/io-orion5x.h> +#endif
arch/arm/mach-orion/include/mach/irq.h renamed from arch/arm/plat-orion/include/plat/irq.h +0 -0
arch/arm/mach-orion/include/mach/irqs-dove.h renamed from arch/arm/mach-dove/include/mach/irqs.h +0 -0
arch/arm/mach-orion/include/mach/irqs-kirkwood.h renamed from arch/arm/mach-kirkwood/include/mach/irqs.h +0 -0
arch/arm/mach-orion/include/mach/irqs-mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/irqs.h +0 -0
arch/arm/mach-orion/include/mach/irqs-orion5x.h renamed from arch/arm/mach-orion5x/include/mach/irqs.h +0 -0
arch/arm/mach-orion/include/mach/irqs.h new file +12 -0
@@ -0,0 +1,12 @@ +#ifdef CONFIG_ARCH_DOVE +#include <mach/irqs-dove.h> +#endif +#ifdef CONFIG_ARCH_KIRKWOOD +#include <mach/irqs-kirkwood.h> +#endif +#ifdef CONFIG_ARCH_MV78XX0 +#include <mach/irqs-mv78xx0.h> +#endif +#ifdef CONFIG_ARCH_ORION5X +#include <mach/irqs-orion5x.h> +#endif
arch/arm/mach-orion/include/mach/kirkwood.h renamed from arch/arm/mach-kirkwood/include/mach/kirkwood.h +0 -0
arch/arm/mach-orion/include/mach/leds-netxbig.h renamed from arch/arm/mach-kirkwood/include/mach/leds-netxbig.h +0 -0
arch/arm/mach-orion/include/mach/leds-ns2.h renamed from arch/arm/mach-kirkwood/include/mach/leds-ns2.h +0 -0
arch/arm/mach-orion/include/mach/mpp.h renamed from arch/arm/plat-orion/include/plat/mpp.h +0 -0
arch/arm/mach-orion/include/mach/mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/mv78xx0.h +0 -0
arch/arm/mach-orion/include/mach/mv_xor.h renamed from arch/arm/plat-orion/include/plat/mv_xor.h +0 -0
arch/arm/mach-orion/include/mach/mvsdio.h renamed from arch/arm/plat-orion/include/plat/mvsdio.h +0 -0
arch/arm/mach-orion/include/mach/orion5x.h renamed from arch/arm/mach-orion5x/include/mach/orion5x.h +0 -0
arch/arm/mach-orion/include/mach/orion_nand.h renamed from arch/arm/plat-orion/include/plat/orion_nand.h +0 -0
arch/arm/mach-orion/include/mach/orion_wdt.h renamed from arch/arm/plat-orion/include/plat/orion_wdt.h +0 -0
arch/arm/mach-orion/include/mach/pcie.h renamed from arch/arm/plat-orion/include/plat/pcie.h +0 -0
arch/arm/mach-orion/include/mach/pm.h renamed from arch/arm/mach-dove/include/mach/pm.h +0 -0
arch/arm/mach-orion/include/mach/time.h renamed from arch/arm/plat-orion/include/plat/time.h +0 -0
arch/arm/mach-orion/include/mach/timex.h renamed from arch/arm/mach-dove/include/mach/timex.h +0 -0
arch/arm/mach-orion/include/mach/uncompress-dove.h renamed from arch/arm/mach-dove/include/mach/uncompress.h +0 -0
arch/arm/mach-orion/include/mach/uncompress-kirkwood.h renamed from arch/arm/mach-kirkwood/include/mach/uncompress.h +0 -0
arch/arm/mach-orion/include/mach/uncompress-mv78xx0.h renamed from arch/arm/mach-mv78xx0/include/mach/uncompress.h +0 -0
arch/arm/mach-orion/include/mach/uncompress-orion5x.h renamed from arch/arm/mach-orion5x/include/mach/uncompress.h +0 -0
arch/arm/mach-orion/include/mach/uncompress.h new file +12 -0
@@ -0,0 +1,12 @@ +#ifdef CONFIG_ARCH_DOVE +#include <mach/uncompress-dove.h> +#endif +#ifdef CONFIG_ARCH_KIRKWOOD +#include <mach/uncompress-kirkwood.h> +#endif +#ifdef CONFIG_ARCH_MV78XX0 +#include <mach/uncompress-mv78xx0.h> +#endif +#ifdef CONFIG_ARCH_ORION5X +#include <mach/uncompress-orion5x.h> +#endif
arch/arm/mach-orion/irq-dove.c renamed from arch/arm/mach-dove/irq.c +2 -2
@@ -14,11 +14,11 @@#include <linux/gpio.h> #include <linux/io.h> #include <asm/mach/arch.h> -#include <plat/irq.h> +#include <mach/irq.h> #include <asm/mach/irq.h> #include <mach/pm.h> #include <mach/bridge-regs.h> -#include "common.h" +#include "dove.h" static void gpio_irq_handler (unsigned int irq,struct irq_desc *desc) {
arch/arm/mach-orion/irq-kirkwood.c renamed from arch/arm/mach-kirkwood/irq.c +2 -2
@@ -13,8 +13,8 @@#include <linux/irq.h> #include <linux/io.h> #include <mach/bridge-regs.h> -#include <plat/irq.h> -#include "common.h" +#include <mach/irq.h> +#include "kirkwood.h" static void gpio_irq_handler (unsigned int irq,struct irq_desc *desc) {
arch/arm/mach-orion/irq-mv78xx0.c renamed from arch/arm/mach-mv78xx0/irq.c +2 -2
@@ -13,8 +13,8 @@#include <linux/pci.h> #include <linux/irq.h> #include <mach/bridge-regs.h> -#include <plat/irq.h> -#include "common.h" +#include <mach/irq.h> +#include "mv78xx0.h" static void gpio_irq_handler (unsigned int irq,struct irq_desc *desc) {
arch/arm/mach-orion/irq-orion5x.c renamed from arch/arm/mach-orion5x/irq.c +2 -2
@@ -15,8 +15,8 @@#include <linux/irq.h> #include <linux/io.h> #include <mach/bridge-regs.h> -#include <plat/irq.h> -#include "common.h" +#include <mach/irq.h> +#include "orion5x.h" static void gpio_irq_handler (unsigned int irq,struct irq_desc *desc) {
arch/arm/mach-orion/irq.c renamed from arch/arm/plat-orion/irq.c +1 -1
@@ -12,7 +12,7 @@#include <linux/init.h> #include <linux/irq.h> #include <linux/io.h> -#include <plat/irq.h> +#include <mach/irq.h> void __init orion_irq_init (unsigned int irq_start,void __iomem *maskaddr) {
arch/arm/mach-orion/kirkwood.c renamed from arch/arm/mach-kirkwood/common.c +9 -9
@@ -24,15 +24,15 @@#include <asm/mach/time.h> #include <mach/kirkwood.h> #include <mach/bridge-regs.h> -#include <plat/audio.h> -#include <plat/cache-feroceon-l2.h> -#include <plat/mvsdio.h> -#include <plat/orion_nand.h> -#include <plat/ehci-orion.h> -#include <plat/common.h> -#include <plat/time.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/audio.h> +#include <mach/cache-feroceon-l2.h> +#include <mach/mvsdio.h> +#include <mach/orion_nand.h> +#include <mach/ehci-orion.h> +#include <mach/common.h> +#include <mach/time.h> +#include <mach/addr-map.h> +#include "kirkwood.h" /***************************************************************************** * I/O Address Mapping
arch/arm/mach-orion/kirkwood.h renamed from arch/arm/mach-kirkwood/common.h +0 -0
arch/arm/mach-orion/kurobox_pro-setup.c renamed from arch/arm/mach-orion5x/kurobox_pro-setup.c +3 -3
@@ -24,9 +24,9 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include <plat/orion_nand.h> -#include "common.h" -#include "mpp.h" +#include <mach/orion_nand.h> +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * KUROBOX-PRO Info
arch/arm/mach-orion/lacie_v2-common.c renamed from arch/arm/mach-kirkwood/lacie_v2-common.c +2 -2
@@ -17,8 +17,8 @@#include <asm/mach/time.h> #include <mach/kirkwood.h> #include <mach/irqs.h> -#include <plat/time.h> -#include "common.h" +#include <mach/time.h> +#include "kirkwood.h" /***************************************************************************** * 512KB SPI Flash on Boot Device (MACRONIX MX25L4005)
arch/arm/mach-orion/lacie_v2-common.h renamed from arch/arm/mach-kirkwood/lacie_v2-common.h +0 -0
arch/arm/mach-orion/ls-chl-setup.c renamed from arch/arm/mach-orion5x/ls-chl-setup.c +2 -2
@@ -23,8 +23,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * Linkstation LS-CHL Info
arch/arm/mach-orion/ls_hgl-setup.c renamed from arch/arm/mach-orion5x/ls_hgl-setup.c +2 -2
@@ -22,8 +22,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * Linkstation LS-HGL Info
arch/arm/mach-orion/lsmini-setup.c renamed from arch/arm/mach-orion5x/lsmini-setup.c +2 -2
@@ -22,8 +22,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * Linkstation Mini Info
arch/arm/mach-orion/mpp-dove.c renamed from arch/arm/mach-dove/mpp.c +2 -2
@@ -11,9 +11,9 @@#include <linux/kernel.h> #include <linux/gpio.h> #include <linux/io.h> -#include <plat/mpp.h> +#include <mach/mpp.h> #include <mach/dove.h> -#include "mpp.h" +#include "mpp-dove.h" struct dove_mpp_grp {int start;
arch/arm/mach-orion/mpp-dove.h renamed from arch/arm/mach-dove/mpp.h +0 -0
arch/arm/mach-orion/mpp-kirkwood.c renamed from arch/arm/mach-kirkwood/mpp.c +3 -3
@@ -12,9 +12,9 @@#include <linux/init.h> #include <linux/io.h> #include <mach/hardware.h> -#include <plat/mpp.h> -#include "common.h" -#include "mpp.h" +#include <mach/mpp.h> +#include "kirkwood.h" +#include "mpp-kirkwood.h" static unsigned int __init kirkwood_variant (void ) {
arch/arm/mach-orion/mpp-kirkwood.h renamed from arch/arm/mach-kirkwood/mpp.h +0 -0
arch/arm/mach-orion/mpp-mv78xx0.c renamed from arch/arm/mach-mv78xx0/mpp.c +3 -3
@@ -11,10 +11,10 @@#include <linux/kernel.h> #include <linux/init.h> #include <linux/io.h> -#include <plat/mpp.h> +#include <mach/mpp.h> #include <mach/hardware.h> -#include "common.h" -#include "mpp.h" +#include "mv78xx0.h" +#include "mpp-mv78xx0.h" static unsigned int __init mv78xx0_variant (void ) {
arch/arm/mach-orion/mpp-mv78xx0.h renamed from arch/arm/mach-mv78xx0/mpp.h +0 -0
arch/arm/mach-orion/mpp-orion5x.c renamed from arch/arm/mach-orion5x/mpp.c +3 -3
@@ -12,9 +12,9 @@#include <linux/init.h> #include <linux/io.h> #include <mach/hardware.h> -#include <plat/mpp.h> -#include "mpp.h" -#include "common.h" +#include <mach/mpp.h> +#include "mpp-orion5x.h" +#include "orion5x.h" static unsigned int __init orion5x_variant (void ) {
arch/arm/mach-orion/mpp-orion5x.h renamed from arch/arm/mach-orion5x/mpp.h +0 -0
arch/arm/mach-orion/mpp.c renamed from arch/arm/plat-orion/mpp.c +1 -1
@@ -14,7 +14,7 @@#include <linux/io.h> #include <linux/gpio.h> #include <mach/hardware.h> -#include <plat/mpp.h> +#include <mach/mpp.h> /* Address of the ith MPP control register */ static __init unsigned long mpp_ctrl_addr(unsigned int i,
arch/arm/mach-orion/mss2-setup.c renamed from arch/arm/mach-orion5x/mss2-setup.c +2 -2
@@ -27,8 +27,8 @@#include <asm/mach/pci.h> #include <mach/orion5x.h> #include <mach/bridge-regs.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" #define MSS2_NOR_BOOT_BASE 0xff800000#define MSS2_NOR_BOOT_SIZE SZ_256K
arch/arm/mach-orion/mv2120-setup.c renamed from arch/arm/mach-orion5x/mv2120-setup.c +2 -2
@@ -22,8 +22,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" #define MV2120_NOR_BOOT_BASE 0xf4000000#define MV2120_NOR_BOOT_SIZE SZ_512K
arch/arm/mach-orion/mv78xx0.c renamed from arch/arm/mach-mv78xx0/common.c +7 -7
@@ -18,13 +18,13 @@#include <asm/mach/time.h> #include <mach/mv78xx0.h> #include <mach/bridge-regs.h> -#include <plat/cache-feroceon-l2.h> -#include <plat/ehci-orion.h> -#include <plat/orion_nand.h> -#include <plat/time.h> -#include <plat/common.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/cache-feroceon-l2.h> +#include <mach/ehci-orion.h> +#include <mach/orion_nand.h> +#include <mach/time.h> +#include <mach/common.h> +#include <mach/addr-map.h> +#include "mv78xx0.h" static int get_tclk (void );
arch/arm/mach-orion/mv78xx0.h renamed from arch/arm/mach-mv78xx0/common.h +0 -0
arch/arm/mach-orion/mv88f6281gtw_ge-setup.c renamed from arch/arm/mach-kirkwood/mv88f6281gtw_ge-setup.c +2 -2
@@ -29,8 +29,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/kirkwood.h> -#include "common.h" -#include "mpp.h" +#include "kirkwood.h" +#include "mpp-kirkwood.h" static struct mv643xx_eth_platform_data mv88f6281gtw_ge_ge00_data = { .phy_addr =MV643XX_ETH_PHY_NONE ,
arch/arm/mach-orion/net2big-setup.c renamed from arch/arm/mach-orion5x/net2big-setup.c +2 -2
@@ -25,8 +25,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * LaCie 2Big Network Info
arch/arm/mach-orion/netspace_v2-setup.c renamed from arch/arm/mach-kirkwood/netspace_v2-setup.c +2 -2
@@ -35,8 +35,8 @@#include <asm/mach/arch.h> #include <mach/kirkwood.h> #include <mach/leds-ns2.h> -#include "common.h" -#include "mpp.h" +#include "kirkwood.h" +#include "mpp-kirkwood.h" #include "lacie_v2-common.h" /*****************************************************************************
arch/arm/mach-orion/netxbig_v2-setup.c renamed from arch/arm/mach-kirkwood/netxbig_v2-setup.c +2 -2
@@ -33,8 +33,8 @@#include <asm/mach/arch.h> #include <mach/kirkwood.h> #include <mach/leds-netxbig.h> -#include "common.h" -#include "mpp.h" +#include "kirkwood.h" +#include "mpp-kirkwood.h" #include "lacie_v2-common.h" /*****************************************************************************
arch/arm/mach-orion/openrd-setup.c renamed from arch/arm/mach-kirkwood/openrd-setup.c +3 -3
@@ -20,9 +20,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include <plat/mvsdio.h> -#include "common.h" -#include "mpp.h" +#include <mach/mvsdio.h> +#include "kirkwood.h" +#include "mpp-kirkwood.h" static struct mtd_partition openrd_nand_parts[] = { {
arch/arm/mach-orion/orion5x.c renamed from arch/arm/mach-orion5x/common.c +6 -6
@@ -29,12 +29,12 @@#include <mach/bridge-regs.h> #include <mach/hardware.h> #include <mach/orion5x.h> -#include <plat/orion_nand.h> -#include <plat/ehci-orion.h> -#include <plat/time.h> -#include <plat/common.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/orion_nand.h> +#include <mach/ehci-orion.h> +#include <mach/time.h> +#include <mach/common.h> +#include <mach/addr-map.h> +#include "orion5x.h" /***************************************************************************** * I/O Address Mapping
arch/arm/mach-orion/orion5x.h renamed from arch/arm/mach-orion5x/common.h +0 -0
arch/arm/mach-orion/pci-orion5x.c renamed from arch/arm/mach-orion5x/pci.c +3 -3
@@ -17,10 +17,10 @@#include <video/vga.h> #include <asm/irq.h> #include <asm/mach/pci.h> -#include <plat/pcie.h> -#include <plat/addr-map.h> +#include <mach/pcie.h> +#include <mach/addr-map.h> #include <mach/orion5x.h> -#include "common.h" +#include "orion5x.h" /***************************************************************************** * Orion has one PCIe controller and one PCI controller.
arch/arm/mach-orion/pcie-dove.c renamed from arch/arm/mach-dove/pcie.c +3 -3
@@ -15,11 +15,11 @@#include <asm/mach/arch.h> #include <asm/setup.h> #include <asm/delay.h> -#include <plat/pcie.h> +#include <mach/pcie.h> #include <mach/irqs.h> #include <mach/bridge-regs.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/addr-map.h> +#include "dove.h" struct pcie_port {u8 index;
arch/arm/mach-orion/pcie-kirkwood.c renamed from arch/arm/mach-kirkwood/pcie.c +3 -3
@@ -14,10 +14,10 @@#include <video/vga.h> #include <asm/irq.h> #include <asm/mach/pci.h> -#include <plat/pcie.h> +#include <mach/pcie.h> #include <mach/bridge-regs.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/addr-map.h> +#include "kirkwood.h" void kirkwood_enable_pcie (void ) {
arch/arm/mach-orion/pcie-mv78xx0.c renamed from arch/arm/mach-mv78xx0/pcie.c +3 -3
@@ -13,9 +13,9 @@#include <video/vga.h> #include <asm/irq.h> #include <asm/mach/pci.h> -#include <plat/pcie.h> -#include <plat/addr-map.h> -#include "common.h" +#include <mach/pcie.h> +#include <mach/addr-map.h> +#include "mv78xx0.h" struct pcie_port {u8 maj;
arch/arm/mach-orion/pcie.c renamed from arch/arm/plat-orion/pcie.c +2 -2
@@ -12,8 +12,8 @@#include <linux/pci.h> #include <linux/mbus.h> #include <asm/mach/pci.h> -#include <plat/pcie.h> -#include <plat/addr-map.h> +#include <mach/pcie.h> +#include <mach/addr-map.h> #include <linux/delay.h> /*
arch/arm/mach-orion/rd78x00-masa-setup.c renamed from arch/arm/mach-mv78xx0/rd78x00-masa-setup.c +1 -1
@@ -17,7 +17,7 @@#include <mach/mv78xx0.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> -#include "common.h" +#include "mv78xx0.h" static struct mv643xx_eth_platform_data rd78x00_masa_ge00_data = { .phy_addr =MV643XX_ETH_PHY_ADDR (8 ),
arch/arm/mach-orion/rd88f5181l-fxo-setup.c renamed from arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c +2 -2
@@ -22,8 +22,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * RD-88F5181L FXO Info
arch/arm/mach-orion/rd88f5181l-ge-setup.c renamed from arch/arm/mach-orion5x/rd88f5181l-ge-setup.c +2 -2
@@ -23,8 +23,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * RD-88F5181L GE Info
arch/arm/mach-orion/rd88f5182-setup.c renamed from arch/arm/mach-orion5x/rd88f5182-setup.c +2 -2
@@ -24,8 +24,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * RD-88F5182 Info
arch/arm/mach-orion/rd88f6183ap-ge-setup.c renamed from arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c +1 -1
@@ -25,7 +25,7 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" +#include "orion5x.h" static struct mv643xx_eth_platform_data rd88f6183ap_ge_eth_data = { .phy_addr =-1 ,
arch/arm/mach-orion/rd88f6192-nas-setup.c renamed from arch/arm/mach-kirkwood/rd88f6192-nas-setup.c +1 -1
@@ -20,7 +20,7 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include "common.h" +#include "kirkwood.h" #define RD88F6192_GPIO_USB_VBUS 10
arch/arm/mach-orion/rd88f6281-setup.c renamed from arch/arm/mach-kirkwood/rd88f6281-setup.c +3 -3
@@ -20,9 +20,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include <plat/mvsdio.h> -#include "common.h" -#include "mpp.h" +#include <mach/mvsdio.h> +#include "kirkwood.h" +#include "mpp-kirkwood.h" static struct mtd_partition rd88f6281_nand_parts[] = { {
arch/arm/mach-orion/sheevaplug-setup.c renamed from arch/arm/mach-kirkwood/sheevaplug-setup.c +3 -3
@@ -19,9 +19,9 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include <plat/mvsdio.h> -#include "common.h" -#include "mpp.h" +#include <mach/mvsdio.h> +#include "kirkwood.h" +#include "mpp-kirkwood.h" static struct mtd_partition sheevaplug_nand_parts[] = { {
arch/arm/mach-orion/t5325-setup.c renamed from arch/arm/mach-kirkwood/t5325-setup.c +2 -2
@@ -27,8 +27,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include "common.h" -#include "mpp.h" +#include "kirkwood.h" +#include "mpp-kirkwood.h" struct mtd_partition hp_t5325_partitions[] = { {
arch/arm/mach-orion/terastation_pro2-setup.c renamed from arch/arm/mach-orion5x/terastation_pro2-setup.c +2 -2
@@ -23,8 +23,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /***************************************************************************** * Terastation Pro 2/Live Info
arch/arm/mach-orion/time.c renamed from arch/arm/plat-orion/time.c +0 -0
arch/arm/mach-orion/ts209-setup.c renamed from arch/arm/mach-orion5x/ts209-setup.c +2 -2
@@ -26,8 +26,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" #include "tsx09-common.h" #define QNAP_TS209_NOR_BOOT_BASE 0xf4000000
arch/arm/mach-orion/ts219-setup.c renamed from arch/arm/mach-kirkwood/ts219-setup.c +2 -2
@@ -22,8 +22,8 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include "common.h" -#include "mpp.h" +#include "kirkwood.h" +#include "mpp-kirkwood.h" #include "tsx1x-common.h" static struct i2c_board_info __initdata qnap_ts219_i2c_rtc = {
arch/arm/mach-orion/ts409-setup.c renamed from arch/arm/mach-orion5x/ts409-setup.c +2 -2
@@ -28,8 +28,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" #include "tsx09-common.h" /*****************************************************************************
arch/arm/mach-orion/ts41x-setup.c renamed from arch/arm/mach-kirkwood/ts41x-setup.c +3 -3
@@ -23,12 +23,12 @@#include <asm/mach-types.h> #include <asm/mach/arch.h> #include <mach/kirkwood.h> -#include "common.h" -#include "mpp.h" +#include "kirkwood.h" +#include "mpp-kirkwood.h" #include "tsx1x-common.h" /* for the PCIe reset workaround */ -#include <plat/pcie.h> +#include <mach/pcie.h> #define QNAP_TS41X_JUMPER_JP1 45
arch/arm/mach-orion/ts78xx-fpga.h renamed from arch/arm/mach-orion5x/ts78xx-fpga.h +0 -0
arch/arm/mach-orion/ts78xx-setup.c renamed from arch/arm/mach-orion5x/ts78xx-setup.c +2 -2
@@ -24,8 +24,8 @@#include <asm/mach/arch.h> #include <asm/mach/map.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" #include "ts78xx-fpga.h" /*****************************************************************************
arch/arm/mach-orion/tsx09-common.c renamed from arch/arm/mach-orion5x/tsx09-common.c +1 -1
@@ -17,7 +17,7 @@#include <linux/serial_reg.h> #include <mach/orion5x.h> #include "tsx09-common.h" -#include "common.h" +#include "orion5x.h" /***************************************************************************** * QNAP TS-x09 specific power off method via UART1-attached PIC
arch/arm/mach-orion/tsx09-common.h renamed from arch/arm/mach-orion5x/tsx09-common.h +0 -0
arch/arm/mach-orion/tsx1x-common.c renamed from arch/arm/mach-kirkwood/tsx1x-common.c +1 -1
@@ -7,7 +7,7 @@#include <linux/spi/orion_spi.h> #include <linux/serial_reg.h> #include <mach/kirkwood.h> -#include "common.h" +#include "kirkwood.h" /* * QNAP TS-x1x Boards flash
arch/arm/mach-orion/tsx1x-common.h renamed from arch/arm/mach-kirkwood/tsx1x-common.h +0 -0
arch/arm/mach-orion/wnr854t-setup.c renamed from arch/arm/mach-orion5x/wnr854t-setup.c +2 -2
@@ -20,8 +20,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" static unsigned int wnr854t_mpp_modes[]__initdata = {MPP0_GPIO ,/* Power LED green (0=on) */
arch/arm/mach-orion/wrt350n-v2-setup.c renamed from arch/arm/mach-orion5x/wrt350n-v2-setup.c +2 -2
@@ -23,8 +23,8 @@#include <asm/mach/arch.h> #include <asm/mach/pci.h> #include <mach/orion5x.h> -#include "common.h" -#include "mpp.h" +#include "orion5x.h" +#include "mpp-orion5x.h" /* * LEDs attached to GPIO
arch/arm/mach-orion5x/Makefile.boot deleted +0 -3
@@ -1,3 +0,0 @@ - zreladdr-y += 0x00008000 -params_phys-y := 0x00000100 -initrd_phys-y := 0x00800000
arch/arm/mach-orion5x/include/mach/gpio.h deleted +0 -9
@@ -1,9 +0,0 @@ -/* -* arch/arm/mach-orion5x/include/mach/gpio.h -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#include <plat/gpio.h>
arch/arm/mach-orion5x/include/mach/hardware.h deleted +0 -14
@@ -1,14 +0,0 @@ -/* -* arch/arm/mach-orion5x/include/mach/hardware.h -* -* This program is free software; you can redistribute it and/or modify -* it under the terms of the GNU General Public License version 2 as -* published by the Free Software Foundation. -*/ - -#ifndef __ASM_ARCH_HARDWARE_H -#define __ASM_ARCH_HARDWARE_H - -#include "orion5x.h" - -#endif
arch/arm/mach-orion5x/include/mach/timex.h deleted +0 -11
@@ -1,11 +0,0 @@ -/* -* arch/arm/mach-orion5x/include/mach/timex.h -* -* Tzachi Perelstein <[email protected]> -* -* This file is licensed under the terms of the GNU General Public -* License version 2. This program is licensed "as is" without any -* warranty of any kind, whether express or implied. -*/ - -#define CLOCK_TICK_RATE (100 * HZ)
arch/arm/mm/cache-feroceon-l2.c +1 -1
@@ -16,7 +16,7 @@#include <linux/highmem.h> #include <asm/cacheflush.h> #include <asm/cp15.h> -#include <plat/cache-feroceon-l2.h> +#include <mach/cache-feroceon-l2.h> /* * Low-level cache maintenance operations.
arch/arm/plat-orion/Makefile deleted +0 -10
@@ -1,10 +0,0 @@ -# -# Makefile for the linux kernel. -# - -obj-y := irq.o pcie.o time.o common.o mpp.o addr-map.o -obj-m := -obj-n := -obj- := - -obj-$(CONFIG_GENERIC_GPIO) += gpio.o
drivers/dma/mv_xor.c +1 -1
@@ -25,7 +25,7 @@#include <linux/interrupt.h> #include <linux/platform_device.h> #include <linux/memory.h> -#include <plat/mv_xor.h> +#include <mach/mv_xor.h> #include "dmaengine.h" #include "mv_xor.h"
drivers/mmc/host/mvsdio.c +1 -1
@@ -24,7 +24,7 @@#include <asm/sizes.h> #include <asm/unaligned.h> -#include <plat/mvsdio.h> +#include <mach/mvsdio.h> #include "mvsdio.h"
drivers/mtd/nand/orion_nand.c +1 -1
@@ -20,7 +20,7 @@#include <asm/io.h> #include <asm/sizes.h> #include <mach/hardware.h> -#include <plat/orion_nand.h> +#include <mach/orion_nand.h> static void orion_nand_cmd_ctrl (struct mtd_info *mtd,int cmd,unsigned int ctrl) {
drivers/usb/host/ehci-orion.c +1 -1
@@ -12,7 +12,7 @@#include <linux/module.h> #include <linux/platform_device.h> #include <linux/mbus.h> -#include <plat/ehci-orion.h> +#include <mach/ehci-orion.h> #define rdl (off) __raw_readl(hcd->regs + (off))#define wrl (off, val) __raw_writel((val), hcd->regs + (off))
drivers/watchdog/orion_wdt.c +1 -1
@@ -25,7 +25,7 @@#include <linux/io.h> #include <linux/spinlock.h> #include <mach/bridge-regs.h> -#include <plat/orion_wdt.h> +#include <mach/orion_wdt.h> /* * Watchdog timer block registers.
sound/soc/kirkwood/kirkwood-i2s.c +1 -1
@@ -20,7 +20,7 @@#include <sound/pcm.h> #include <sound/pcm_params.h> #include <sound/soc.h> -#include <plat/audio.h> +#include <mach/audio.h> #include "kirkwood.h" #define DRV_NAME "kirkwood-i2s"
sound/soc/kirkwood/kirkwood-openrd.c +1 -1
@@ -17,7 +17,7 @@#include <linux/slab.h> #include <sound/soc.h> #include <mach/kirkwood.h> -#include <plat/audio.h> +#include <mach/audio.h> #include <asm/mach-types.h> #include "../codecs/cs42l51.h"
sound/soc/kirkwood/kirkwood-t5325.c +1 -1
@@ -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"
Nicolas Pitre
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 22 lines · Arnd Bergmann
Quoted 8 lines · Arnd Bergmann
Another way would be to reorganize those directories upfront:
plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.hand then go from there. The differences between the headers are fairly small already, so that should be manageable.
Actually we could do a trivial move of all files into one directory at any time, e.g. at the end of the merge window, to minimize conflicts with other patches.
This is a semi-automated move of all plat-orion based machines into a single mach-orion directory, and we could of course add the new stuff in there as well. I've specifically tried to keep this move simple, even if that means a lot of the easy cleanups for code that are mostly identical are not done here. Cleanups after this could come one at a time to reduce this duplication and simplify the platform.
Quoted 4 lines
Obvious next steps are to merge the various
MakefileandKconfigfiles as well as all the headers, and to actually allow building stuff together.Signed-off-by Arnd Bergmann <[email protected]>
The problematic Armada naming issue simply goes away.
Quoted 113 lines
arch/arm/mach-dove/Makefile.boot | 3 -- arch/arm/mach-dove/include/mach/gpio.h | 9 ------- arch/arm/mach-dove/include/mach/hardware.h | 19 ---------------- arch/arm/mach-kirkwood/include/mach/gpio.h | 9 ------- arch/arm/mach-kirkwood/include/mach/hardware.h | 14 ------------ arch/arm/mach-kirkwood/include/mach/timex.h | 10 -------- arch/arm/mach-mv78xx0/Makefile.boot | 3 -- arch/arm/mach-mv78xx0/include/mach/gpio.h | 9 ------- arch/arm/mach-mv78xx0/include/mach/hardware.h | 14 ------------ arch/arm/mach-mv78xx0/include/mach/timex.h | 9 ------- arch/arm/mach-orion5x/Makefile.boot | 3 -- arch/arm/mach-orion5x/include/mach/gpio.h | 9 ------- arch/arm/mach-orion5x/include/mach/hardware.h | 14 ------------ arch/arm/mach-orion5x/include/mach/timex.h | 11 --------- arch/arm/plat-orion/Makefile | 10 -------- b/arch/arm/Kconfig | 8 ------- b/arch/arm/Makefile | 9 +++---- b/arch/arm/mach-orion/Kconfig | 7 ++++++ b/arch/arm/mach-orion/Makefile | 26 +++++++++++++++++++++++ b/arch/arm/mach-orion/Makefile.dove | 2 - b/arch/arm/mach-orion/Makefile.kirkwood | 2 - b/arch/arm/mach-orion/Makefile.mv78xx0 | 2 - b/arch/arm/mach-orion/Makefile.orion5x | 2 - b/arch/arm/mach-orion/addr-map-dove.c | 4 +-- b/arch/arm/mach-orion/addr-map-kirkwood.c | 4 +-- b/arch/arm/mach-orion/addr-map-mv78xx0.c | 4 +-- b/arch/arm/mach-orion/addr-map-orion5x.c | 4 +-- b/arch/arm/mach-orion/addr-map.c | 2 - b/arch/arm/mach-orion/board-dnskw.c | 4 +-- b/arch/arm/mach-orion/board-dreamplug.c | 6 ++--- b/arch/arm/mach-orion/board-dt.c | 2 - b/arch/arm/mach-orion/board-ib62x0.c | 4 +-- b/arch/arm/mach-orion/board-iconnect.c | 4 +-- b/arch/arm/mach-orion/buffalo-wxl-setup.c | 4 +-- b/arch/arm/mach-orion/cm-a510.c | 2 - b/arch/arm/mach-orion/common.c | 6 ++--- b/arch/arm/mach-orion/d2net-setup.c | 4 +-- b/arch/arm/mach-orion/d2net_v2-setup.c | 4 +-- b/arch/arm/mach-orion/db78x00-bp-setup.c | 2 - b/arch/arm/mach-orion/db88f5281-setup.c | 6 ++--- b/arch/arm/mach-orion/db88f6281-bp-setup.c | 6 ++--- b/arch/arm/mach-orion/dns323-setup.c | 4 +-- b/arch/arm/mach-orion/dockstar-setup.c | 6 ++--- b/arch/arm/mach-orion/dove-db-setup.c | 2 - b/arch/arm/mach-orion/dove.c | 10 ++++---- b/arch/arm/mach-orion/edmini_v2-setup.c | 4 +-- b/arch/arm/mach-orion/guruplug-setup.c | 6 ++--- b/arch/arm/mach-orion/include/mach/bridge-regs.h | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/debug-macro.S | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/entry-macro.S | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/hardware.h | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/io.h | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/irqs.h | 12 ++++++++++ b/arch/arm/mach-orion/include/mach/uncompress.h | 12 ++++++++++ b/arch/arm/mach-orion/irq-dove.c | 4 +-- b/arch/arm/mach-orion/irq-kirkwood.c | 4 +-- b/arch/arm/mach-orion/irq-mv78xx0.c | 4 +-- b/arch/arm/mach-orion/irq-orion5x.c | 4 +-- b/arch/arm/mach-orion/irq.c | 2 - b/arch/arm/mach-orion/kirkwood.c | 18 +++++++-------- b/arch/arm/mach-orion/kurobox_pro-setup.c | 6 ++--- b/arch/arm/mach-orion/lacie_v2-common.c | 4 +-- b/arch/arm/mach-orion/ls-chl-setup.c | 4 +-- b/arch/arm/mach-orion/ls_hgl-setup.c | 4 +-- b/arch/arm/mach-orion/lsmini-setup.c | 4 +-- b/arch/arm/mach-orion/mpp-dove.c | 4 +-- b/arch/arm/mach-orion/mpp-kirkwood.c | 6 ++--- b/arch/arm/mach-orion/mpp-mv78xx0.c | 6 ++--- b/arch/arm/mach-orion/mpp-orion5x.c | 6 ++--- b/arch/arm/mach-orion/mpp.c | 2 - b/arch/arm/mach-orion/mss2-setup.c | 4 +-- b/arch/arm/mach-orion/mv2120-setup.c | 4 +-- b/arch/arm/mach-orion/mv78xx0.c | 14 ++++++------ b/arch/arm/mach-orion/mv88f6281gtw_ge-setup.c | 4 +-- b/arch/arm/mach-orion/net2big-setup.c | 4 +-- b/arch/arm/mach-orion/netspace_v2-setup.c | 4 +-- b/arch/arm/mach-orion/netxbig_v2-setup.c | 4 +-- b/arch/arm/mach-orion/openrd-setup.c | 6 ++--- b/arch/arm/mach-orion/orion5x.c | 12 +++++----- b/arch/arm/mach-orion/pci-orion5x.c | 6 ++--- b/arch/arm/mach-orion/pcie-dove.c | 6 ++--- b/arch/arm/mach-orion/pcie-kirkwood.c | 6 ++--- b/arch/arm/mach-orion/pcie-mv78xx0.c | 6 ++--- b/arch/arm/mach-orion/pcie.c | 4 +-- b/arch/arm/mach-orion/rd78x00-masa-setup.c | 2 - b/arch/arm/mach-orion/rd88f5181l-fxo-setup.c | 4 +-- b/arch/arm/mach-orion/rd88f5181l-ge-setup.c | 4 +-- b/arch/arm/mach-orion/rd88f5182-setup.c | 4 +-- b/arch/arm/mach-orion/rd88f6183ap-ge-setup.c | 2 - b/arch/arm/mach-orion/rd88f6192-nas-setup.c | 2 - b/arch/arm/mach-orion/rd88f6281-setup.c | 6 ++--- b/arch/arm/mach-orion/sheevaplug-setup.c | 6 ++--- b/arch/arm/mach-orion/t5325-setup.c | 4 +-- b/arch/arm/mach-orion/terastation_pro2-setup.c | 4 +-- b/arch/arm/mach-orion/ts209-setup.c | 4 +-- b/arch/arm/mach-orion/ts219-setup.c | 4 +-- b/arch/arm/mach-orion/ts409-setup.c | 4 +-- b/arch/arm/mach-orion/ts41x-setup.c | 6 ++--- b/arch/arm/mach-orion/ts78xx-setup.c | 4 +-- b/arch/arm/mach-orion/tsx09-common.c | 2 - b/arch/arm/mach-orion/tsx1x-common.c | 2 - b/arch/arm/mach-orion/wnr854t-setup.c | 4 +-- b/arch/arm/mach-orion/wrt350n-v2-setup.c | 4 +-- b/arch/arm/mm/cache-feroceon-l2.c | 2 - b/drivers/dma/mv_xor.c | 2 - b/drivers/mmc/host/mvsdio.c | 2 - b/drivers/mtd/nand/orion_nand.c | 2 - b/drivers/usb/host/ehci-orion.c | 2 - b/drivers/watchdog/orion_wdt.c | 2 - b/sound/soc/kirkwood/kirkwood-i2s.c | 2 - b/sound/soc/kirkwood/kirkwood-openrd.c | 2 - b/sound/soc/kirkwood/kirkwood-t5325.c | 2 - 112 files changed, 306 insertions(+), 342 deletions(-)
Andrew Lunn
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Arnd BergmannQuoted 22 lines · Arnd Bergmann
Quoted 8 lines · Arnd Bergmann
Another way would be to reorganize those directories upfront:
plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.hand then go from there. The differences between the headers are fairly small already, so that should be manageable.
Actually we could do a trivial move of all files into one directory at any time, e.g. at the end of the merge window, to minimize conflicts with other patches.
This is a semi-automated move of all plat-orion based machines into a single mach-orion directory, and we could of course add the new stuff in there as well. I've specifically tried to keep this move simple, even if that means a lot of the easy cleanups for code that are mostly identical are not done here. Cleanups after this could come one at a time to reduce this duplication and simplify the platform.
Quoted 4 lines
Obvious next steps are to merge the various
MakefileandKconfigfiles as well as all the headers, and to actually allow building stuff together.Signed-off-by Arnd Bergmann <[email protected]>
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
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 9 lines · Andrew Lunn
Quoted 2 lines
Signed-off-by Arnd Bergmann <[email protected]>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
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Arnd BergmannQuoted 11 lines · Arnd Bergmann
Quoted 8 lines · Arnd Bergmann
Another way would be to reorganize those directories upfront:
plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.hand then go from there. The differences between the headers are fairly small already, so that should be manageable.
Quoted 7 lines
Actually we could do a trivial move of all files into one directory at any time, e.g. at the end of the merge window, to minimize conflicts with other patches.
This is a semi-automated move of all plat-orion based machines into a single mach-orion directory, and we could of course add the new stuff in there as well.
mach-orion is better than mach-armada. Armada is just a Logo, not a silicon family.
Silicons with ARMv5/v6/v7 core are all marked with Armada Logo.
By the way, silicons in mach-pxa and mach-mmp are also named Armada.
Regards
Haojian
Andrew Lunn
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Arnd BergmannQuoted 22 lines · Arnd Bergmann
Quoted 8 lines · Arnd Bergmann
Another way would be to reorganize those directories upfront:
plat-orion -> mach-orion
mach-*/*.c -> mach/orion/*/*.c mach-*/include/mach/* -> mach-orion/include/mach/*.hand then go from there. The differences between the headers are fairly small already, so that should be manageable.
Actually we could do a trivial move of all files into one directory at any time, e.g. at the end of the merge window, to minimize conflicts with other patches.
This is a semi-automated move of all plat-orion based machines into a single mach-orion directory, and we could of course add the new stuff in there as well. I've specifically tried to keep this move simple, even if that means a lot of the easy cleanups for code that are mostly identical are not done here. Cleanups after this could come one at a time to reduce this duplication and simplify the platform.
Quoted 4 lines
Obvious next steps are to merge the various
MakefileandKconfigfiles as well as all the headers, and to actually allow building stuff together.Signed-off-by Arnd Bergmann <[email protected]>
It boots on my kirkwood QNAP TS109P+ and all the devices seem present and correct.
Andrew
Nicolas Pitre
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Arnd BergmannQuoted 14 lines · Arnd Bergmann
Quoted 5 lines · Thomas Petazzoni
On the naming side, we are really open to what the community prefers. We knew there would be quite a bit of discussion around this, because there's a lot quite a few Marvell SoCs supported in various places, and it's not obvious what's the right place and name for a new SoC family.
Quoted 7 lines
What about making it mach-marvell, which would contain the DT-enabled SoC support for Marvell SoCs? We can start with 370 and XP today, and gradually add future SoCs, or even port previous SoCs as they are moved to support the device tree.
Again we're really open on the solution. Lior from Marvell can give all the necessary input to explain how the SoC family is organized.
Quoted 6 lines
The problem with mach-marvell is that it would be confusing in the presence of pxa/mmp which I would probably still leave out of that directory, since they are rather different inside.
I think we can just start with the existing plat-orion directory until someone comes up with a better place.
plat-orion for the common bits totally makes sense.
I wouldn't use that for SOC specific stuff though. The proposed mach-armada is probably a good choice.
mach-marvell, mach-mrvl or any other derivatives based on the company name is a really bad choice. Marvell is a large company and it has several SOC families with totally disjoint history.
Nicolas
Andrew Lunn
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Thomas PetazzoniQuoted 11 lines · Thomas Petazzoni
Le Tue, 15 May 2012 09:35:55 -0500,
Rob Herring <[email protected]> a ??crit :Quoted 3 lines
Directory location doesn't really have anything to do with what can be in a single kernel binary. We will soon be building single images across mach directories.
Agreed, but it's not the case right now, and we wanted to submit today a kernel that boots on both of those SoCs.
The 370 and XP both use the PJ4B core
Could mach-pj4b be an option?
Andrew
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 8 lines · Andrew Lunn
Quoted 7 lines · Thomas Petazzoni
Le Tue, 15 May 2012 09:35:55 -0500,
Rob Herring<[email protected]> a ??crit :Quoted 3 lines
Directory location doesn't really have anything to do with what can be in a single kernel binary. We will soon be building single images across mach directories.
Quoted 6 lines
Quoted 4 lines
Agreed, but it's not the case right now, and we wanted to submit today a kernel that boots on both of those SoCs.
The 370 and XP both use the PJ4B core
Could mach-pj4b be an option?
Not really, that's the CPU core and will probably get re-used for a number of products.
I'm personally happy with any of mach-marvell, mach-mv, mach-mv-axp or similar.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
Andrew Lunn
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
The 370 and XP both use the PJ4B core
Could mach-pj4b be an option?
Not really, that's the CPU core and will probably get re-used for a number of products.
However, if everything is DT based, does that matter? All these products end up in here.
Andrew
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 9 lines · Andrew Lunn
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
The 370 and XP both use the PJ4B core
Could mach-pj4b be an option?
Not really, that's the CPU core and will probably get re-used for a number of products.
However, if everything is DT based, does that matter? All these products end up in here.
I'd prefer a slightly more segregated directory structure, you'd end up with masses of files in one directory if you went of cpu-arch as most people use the v5/v6/v7 ARM cores.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Thomas PetazzoniQuoted 41 lines
-----Original Message-----
From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
Sent: Tuesday, May 15, 2012 5:45 PM
To: Rob Herring
Cc: Ben Dooks; Lior Amsalem; Andrew Lunn; Jason Cooper; Arnd Bergmann; Nicolas Pitre; Maen Suleiman; Ben Dooks; Olof Johansson; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH] arm: Add basic support for new Marvell Armada SoC familyLe Tue, 15 May 2012 09:35:55 -0500,
Rob Herring <[email protected]> a ?crit :Quoted 3 lines
Directory location doesn't really have anything to do with what can be in a single kernel binary. We will soon be building single images across mach directories.
Agreed, but it's not the case right now, and we wanted to submit today a kernel that boots on both of those SoCs.
The 370 and XP both use the PJ4B core, which is a Marvell implementation of an ARMv7 compatible core. The 370 has one PJ4B, and the various XP variants have a choice of 2 or 4 PJ4Bs, and various other differences. To us, it makes a lot of sense to be able to support those SoCs together in the same kernel image and in the same directory, even if both concepts are not directly tied together.
Quoted 6 lines
With some hacks and limitations, Arnd has built (not run) omap2+, u8500, imx and one other in a single kernel.
If there's overlap with dove or other platforms, then they should probably all be combined into a single mach directory. One option would be make the new mach directory somewhat generic and then later move dove or others into the new directory.This would be one solution.
On the naming side, we are really open to what the community prefers. We knew there would be quite a bit of discussion around this, because there's a lot quite a few Marvell SoCs supported in various places, and it's not obvious what's the right place and name for a new SoC family.
Quoted 7 lines
What about making it mach-marvell, which would contain the DT-enabled SoC support for Marvell SoCs? We can start with 370 and XP today, and gradually add future SoCs, or even port previous SoCs as they are moved to support the device tree.
Again we're really open on the solution. Lior from Marvell can give all the necessary input to explain how the SoC family is organized.
I'll try to arrange our SoCs (EBU):
Orion family:
Flavors:
5082, 5181, 5181L, 5281, 6183, ...
Core: ARMv5 compatible (Feroceon and Jolteon)
Process: 90nm
Directory: mach-orion5x
Kirkwood family:
Flavors:
6190, 6192, ...
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-kirkwood
6282 a.k.a Kirkwood 55, Armada 300
6283 a.k.a Kirkwood 55, Armada 310
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: not in mainline, future plan
6710 a.k.a Kirkwood 40, Armada 370
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new code
Discovery family:
Flavors:
78100/78200 a.k.a DiscoDuo
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-mv78xx0
78230/78260/78460 a.k.a DiscoSMP, Armada XP
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new code
Avanta family: (a.k.a Kirkwood 2)
Flavors:
6560/60, 6530P, 6510
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: no code in mainline yet, future plan
Dove: (application processor)
Flavors:
ap510 a.k.a Armada 510
Core: ARMv7 compatible (PJ4)
Process: 65nm
Directory: mach-dove
plat-orion holds code shared between the SoCs.
There are more SoCs called Armada which are developed in other business units in Marvell (mmp, pxa) but I'm not that familier with it.
I hope it helps mapping the different SoCs.
Quoted 9 lines
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux development, consulting, training and support.
http://free-electrons.com
Lior Amsalem
Andrew Lunn
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Hi Lior
Thanks for the list.
Quoted 8 lines
I'll try to arrange our SoCs (EBU):
Orion family:
Flavors:
5082, 5181, 5181L, 5281, 6183, ...
Core: ARMv5 compatible (Feroceon and Jolteon)
Process: 90nm
Directory: mach-orion5x
mach-orion5x also supports 5182, which is not on your list.
Quoted 7 lines
Kirkwood family:
Flavors:
6190, 6192, ...
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-kirkwood
Quoted 5 lines
6282 a.k.a Kirkwood 55, Armada 300
6283 a.k.a Kirkwood 55, Armada 310
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: not in mainline, future plan
mach-kirkwood supports 6180 6190 6192 6281 6282
6180 and 6281 are not on your list.
Quoted 25 lines
6710 a.k.a Kirkwood 40, Armada 370
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new codeDiscovery family:
Flavors:
78100/78200 a.k.a DiscoDuo
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-mv78xx078230/78260/78460 a.k.a DiscoSMP, Armada XP
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new codeAvanta family: (a.k.a Kirkwood 2)
Flavors:
6560/60, 6530P, 6510
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: no code in mainline yet, future plan
Quoted 6 lines
Dove: (application processor)
Flavors:
ap510 a.k.a Armada 510
Core: ARMv7 compatible (PJ4)
Process: 65nm
Directory: mach-dove
Is there any logic to the names/numbers?
Thanks
Andrew
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Lior AmsalemQuoted 56 lines · Lior Amsalem
Quoted 2 lines
Again we're really open on the solution. Lior from Marvell can give all the necessary input to explain how the SoC family is organized.
I'll try to arrange our SoCs (EBU):
Orion family:
Flavors:
5082, 5181, 5181L, 5281, 6183, ...
Core: ARMv5 compatible (Feroceon and Jolteon)
Process: 90nm
Directory: mach-orion5xKirkwood family:
Flavors:
6190, 6192, ...
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-kirkwood6282 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 plan6710 a.k.a Kirkwood 40, Armada 370
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new codeDiscovery family:
Flavors:
78100/78200 a.k.a DiscoDuo
Core: ARMv5 compatible (Gandalf)
Process: 65nm
Directory: mach-mv78xx078230/78260/78460 a.k.a DiscoSMP, Armada XP
Core: ARMv7 compatible (PJ4B)
Process: 40nm
Directory: new codeAvanta family: (a.k.a Kirkwood 2)
Flavors:
6560/60, 6530P, 6510
Core: ARMv5 compatible (Gandalf)
Process: 55nm
Directory: no code in mainline yet, future planDove: (application processor)
Flavors:
ap510 a.k.a Armada 510
Core: ARMv7 compatible (PJ4)
Process: 65nm
Directory: mach-dove
Quoted 5 lines
plat-orion holds code shared between the SoCs.
There are more SoCs called Armada which are developed in other business units in Marvell (mmp, pxa) but I'm not that familier with it.I hope it helps mapping the different SoCs.
Thanks for the list, very helpful!
So do you think it makes sense to put all of these into mach-orion?
Where does the Armada 1000/1500 (88DE3010/88DE3100) fit in here. Is it related to the EBU family above or the PXA/MMP family, or is it something entirely different?
Also, I've seen dove (Armada 510) being referred to as PXA510. Is that also an official designation or just a mistake made by people who were confused by the marketing names?
Arnd
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 10 lines
-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Wednesday, May 16, 2012 3:01 PM
To: Lior Amsalem
Cc: Thomas Petazzoni; Rob Herring; Ben Dooks; Andrew Lunn; Jason Cooper; Nicolas Pitre; Maen Suleiman; Ben Dooks; Olof Johansson; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH] arm: Add basic support for new Marvell Armada SoC family
[snip]
Quoted 5 lines
Thanks for the list, very helpful!
So do you think it makes sense to put all of these into mach-orion?
Well, Orion is old and seems like not the best name for a directory to include all the new platforms.
We are discussing it internally as well and I'll update with our suggestion.
Quoted 5 lines
Where does the Armada 1000/1500 (88DE3010/88DE3100) fit in here. Is it related to the EBU family above or the PXA/MMP family, or is it something entirely different?
I only know general info, no more than what can be found in Marvell's site:
http://www.marvell.com/digital-entertainment/
Quoted 3 lines
Also, I've seen dove (Armada 510) being referred to as PXA510. Is that also an official designation or just a mistake made by people who were confused by the marketing names?
It was the SoC name at some point, the official name is Armada 510.
Quoted 2 lines
Arnd
Lior Amsalem
Nicolas Pitre
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 12 lines · Lior Amsalem
Quoted 10 lines
-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: Wednesday, May 16, 2012 3:01 PM
To: Lior Amsalem
Cc: Thomas Petazzoni; Rob Herring; Ben Dooks; Andrew Lunn; Jason Cooper; Nicolas Pitre; Maen Suleiman; Ben Dooks; Olof Johansson; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH] arm: Add basic support for new Marvell Armada SoC family[snip]
Quoted 1 line
Quoted 7 lines
Quoted 4 lines
Thanks for the list, very helpful!
So do you think it makes sense to put all of these into mach-orion?
Well, Orion is old and seems like not the best name for a directory to include all the new platforms.
We are discussing it internally as well and I'll update with our suggestion.
My suggestion is: mach-mrvl-ebu or plat-mrvl-ebu
Rational: any marketing name is going to be unsuitable for structuring common code in the kernel, especially as Marvell has a tendency to reuse the same marketing name for different things, as well as different names for similar things. One thing that is common to Orion/Kirkwood/Dove/(insert some Armada flavours here)/etc though is that they came out of Marvell's EBU division.
Nicolas
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Lior AmsalemQuoted 8 lines · Lior Amsalem
Quoted 5 lines
Thanks for the list, very helpful!
So do you think it makes sense to put all of these into mach-orion?
Well, Orion is old and seems like not the best name for a directory to include all the new platforms.
We are discussing it internally as well and I'll update with our suggestion.
The name has the advantage that we have a bunch of drivers using it already:
arch/arm/plat-orion/gpio.carch/arm/plat-orion/irq.carch/arm/plat-orion/mpp.carch/arm/plat-orion/pcie.carch/arm/plat-orion/time.cdrivers/mtd/nand/orion_nand.cdrivers/spi/spi-orion.cdrivers/usb/host/ehci-orion.cdrivers/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
Nicolas Pitre
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 22 lines · Arnd Bergmann
Quoted 8 lines · Lior Amsalem
Quoted 5 lines
Thanks for the list, very helpful!
So do you think it makes sense to put all of these into mach-orion?
Well, Orion is old and seems like not the best name for a directory to include all the new platforms.
We are discussing it internally as well and I'll update with our suggestion.The name has the advantage that we have a bunch of drivers using it already:
arch/arm/plat-orion/gpio.carch/arm/plat-orion/irq.carch/arm/plat-orion/mpp.carch/arm/plat-orion/pcie.carch/arm/plat-orion/time.cdrivers/mtd/nand/orion_nand.cdrivers/spi/spi-orion.cdrivers/usb/host/ehci-orion.cdrivers/watchdog/orion_wdt.c
Quoted 2 lines
AFAICT, those are shared between most of those socs, and I would not want to change the code in them to the new name.
Why not? Module aliases can be used if that is a concern.
Quoted 3 lines
If we change the directory
name to something completely different, it no longer matches the driver names.
I wouldn't consider this as a major concern. For example, the ethernet driver that all those SOCs use is not called "orion".
Nicolas
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 4 lines · Nicolas Pitre
Quoted 3 lines
AFAICT, those are shared between most of those socs, and I would not want to change the code in them to the new name.
Quoted 8 lines
Why not? Module aliases can be used if that is a concern.
Quoted 3 lines
If we change the directory
name to something completely different, it no longer matches the driver names.I wouldn't consider this as a major concern. For example, the ethernet driver that all those SOCs use is not called "orion".
It's not a big thing, I just feel that leaving the drivers alone makes it a bit easier to port patches between kernel versions. Another argument for orion is that it's nicer to read as a function name prefix than mrvl_ebu_* as you suggested. The main counterargument to keeping orion_ as I understand it is that it's actually only the name for the oldest members of this family, right? This is a good point, but we also have a lot of other cases in the kernel where code is named after the first thing that used it, e.g. arch/x86 was called arch/i386 for a long time and we still have tons of references to that.
Arnd
Nicolas Pitre
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · Nicolas Pitre
Quoted 3 lines
AFAICT, those are shared between most of those socs, and I would not want to change the code in them to the new name.
Why not? Module aliases can be used if that is a concern.
Quoted 3 lines
If we change the directory
name to something completely different, it no longer matches the driver names.
Quoted 5 lines
Quoted 2 lines
I wouldn't consider this as a major concern. For example, the ethernet driver that all those SOCs use is not called "orion".
It's not a big thing, I just feel that leaving the drivers alone makes it a bit easier to port patches between kernel versions.
Sure. My point is that we can rename the SOC directory and leave drivers alone if we wish to minimize churn. Drivers can be renamed at a later time if that is seen as useful.
Quoted 8 lines
Another argument
for orion is that it's nicer to read as a function name prefix than mrvl_ebu_* as you suggested. The main counterargument to keepingorion_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/x86was calledarch/i386for 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
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 12 lines · Nicolas Pitre
In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.
I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.
Quoted 4 lines
Since this is code not marketing, we don't have to have something flashy either, as long as it doesn't create more confusion than "orion" does. The various
Kconfighelp 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
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 13 lines · Arnd Bergmann
Quoted 12 lines · Nicolas Pitre
In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.
I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.
Quoted 7 lines
Quoted 4 lines
Since this is code not marketing, we don't have to have something flashy either, as long as it doesn't create more confusion than "orion" does. The various
Kconfighelp 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.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 19 lines · Jason Cooper
Quoted 18 lines · Arnd Bergmann
Quoted 16 lines · Nicolas Pitre
In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.
I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.
Since this is code not marketing, we don't have to have something flashy either, as long as it doesn't create more confusion than "orion" does. The various
Kconfighelp texts are good places to put all the marketing names du jour.
Quoted 4 lines
Quoted 2 lines
mvebu sounds reasonable to me, it's definitely unique and it's almost a word ;-)
mvebuntu? *ducks*
you, sir, are clearly quackers.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Nicolas PitreQuoted 45 lines · Nicolas Pitre
Quoted 11 lines · Arnd Bergmann
Quoted 10 lines · Nicolas Pitre
Quoted 3 lines
AFAICT, those are shared between most of those socs, and I would not want to change the code in them to the new name.
Why not? Module aliases can be used if that is a concern.
Quoted 3 lines
If we change the directory
name to something completely different, it no longer matches the driver names.Quoted 5 lines
Quoted 2 lines
I wouldn't consider this as a major concern. For example, the ethernet driver that all those SOCs use is not called "orion".
It's not a big thing, I just feel that leaving the drivers alone makes it a bit easier to port patches between kernel versions.
Sure. My point is that we can rename the SOC directory and leave drivers alone if we wish to minimize churn. Drivers can be renamed at a later time if that is seen as useful.
Quoted 8 lines
Another argument
for orion is that it's nicer to read as a function name prefix than mrvl_ebu_* as you suggested. The main counterargument to keepingorion_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/x86was calledarch/i386for a long time and we still have tons of references to that.Indeed. "sa1100" is another example of that and I didn't want to rename it to sa11x0 at the time.
But in the sa1100 or i386 cases, the alternatives are close enough not to cause too much confusion.
In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, _especially_ if we're going to cause churn by moving things around already.
Quoted 4 lines
I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.
I prefer mvebu_* ... nice and concise.
thx,
Jason.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 8 lines · Jason Cooper
Quoted 8 lines
In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.
Quoted 7 lines
Quoted 4 lines
I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.
I prefer mvebu_* ... nice and concise.
On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to arch/arm/mach-mvebu/board/*.c instead of arch/arm/mach-mvebu/*-setup.c
The reasons I think this would help are that the directory is getting a bit crowded when we move five or more of the current platforms in there, and that I hope we can start ignoring them for most practical purposes as some point in the future when all boards have been made to work with DT, and at an even later point we can just delete that directory. The main disadvantage that this approach would bring is that it's not consistent with what any of the other platforms do.
Arnd
Nicolas Pitre
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 22 lines · Arnd Bergmann
Quoted 8 lines · Jason Cooper
Quoted 8 lines
In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.
Quoted 7 lines
Quoted 4 lines
I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.
I prefer mvebu_* ... nice and concise.
On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to
arch/arm/mach-mvebu/board/*.cinstead ofarch/arm/mach-mvebu/*-setup.c
Quoted 7 lines
The reasons I think this would help are that the directory is getting a bit crowded when we move five or more of the current platforms in there, and that I hope we can start ignoring them for most practical purposes as some point in the future when all boards have been made to work with DT, and at an even later point we can just delete that directory. The main disadvantage that this approach would bring is that it's not consistent with what any of the other platforms do.
Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.
Nicolas
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 32 lines · Nicolas Pitre
Quoted 22 lines · Arnd Bergmann
Quoted 8 lines · Jason Cooper
Quoted 8 lines
In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.
Quoted 7 lines
Quoted 4 lines
I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.
I prefer mvebu_* ... nice and concise.
On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to
arch/arm/mach-mvebu/board/*.cinstead ofarch/arm/mach-mvebu/*-setup.cQuoted 7 lines
The reasons I think this would help are that the directory is getting a bit crowded when we move five or more of the current platforms in there, and that I hope we can start ignoring them for most practical purposes as some point in the future when all boards have been made to work with DT, and at an even later point we can just delete that directory. The main disadvantage that this approach would bring is that it's not consistent with what any of the other platforms do.
Quoted 2 lines
Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.
Took the words right out of my mouth. Once DT conversions are complete, mach-*/ would either go away, or hold legacy non-DT boards.
On a side note, I also like this because it would make converting old board files like sheevaplug and guruplug to DT easier. The legacy implementation would be in mach-mvebu/ and the DT implementation would be in plat-mvebu/. Newcomers to the code would see a clearly defined separation.
thx,
Jason.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 11 lines · Jason Cooper
Quoted 2 lines
Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.
Took the words right out of my mouth. Once DT conversions are complete, mach-*/ would either go away, or hold legacy non-DT boards.
On a side note, I also like this because it would make converting old board files like sheevaplug and guruplug to DT easier. The legacy implementation would be in mach-mvebu/ and the DT implementation would be in plat-mvebu/. Newcomers to the code would see a clearly defined separation.
With that layout, where do the mach/* headers go?
Arnd
Nicolas Pitre
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 7 lines · Arnd Bergmann
Quoted 6 lines · Jason Cooper
Quoted 2 lines
Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.
Took the words right out of my mouth. Once DT conversions are complete, mach-*/ would either go away, or hold legacy non-DT boards.
Quoted 7 lines
Quoted 5 lines
On a side note, I also like this because it would make converting old board files like sheevaplug and guruplug to DT easier. The legacy implementation would be in mach-mvebu/ and the DT implementation would be in plat-mvebu/. Newcomers to the code would see a clearly defined separation.
With that layout, where do the mach/* headers go?
I think arch/arm/plat-mvvebu/include/mach/* could work.
Nicolas
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 15 lines · Nicolas Pitre
Quoted 13 lines · Arnd Bergmann
Quoted 11 lines · Jason Cooper
Quoted 2 lines
Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.
Took the words right out of my mouth. Once DT conversions are complete, mach-*/ would either go away, or hold legacy non-DT boards.
On a side note, I also like this because it would make converting old board files like sheevaplug and guruplug to DT easier. The legacy implementation would be in mach-mvebu/ and the DT implementation would be in plat-mvebu/. Newcomers to the code would see a clearly defined separation.
Quoted 3 lines
Quoted 1 line
With that layout, where do the mach/* headers go?
I think
arch/arm/plat-mvvebu/include/mach/*could work.
And try to avoid putting anything in the include/mach/ directory which isn't needed by any code outside of arch/arm/{plat,mach}-* directory.
In other words, headers needed only for code in arch/arm/plat-mvvebu/ should be in that very same directory.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 18 lines · Russell King - ARM Linux
Quoted 17 lines · Nicolas Pitre
Quoted 14 lines · Arnd Bergmann
Quoted 11 lines · Jason Cooper
Quoted 2 lines
Board files in mach-mvebu and the rest in plat-mvebu. That would match the spirit of the current split between mach-* and plat-*.
Took the words right out of my mouth. Once DT conversions are complete, mach-*/ would either go away, or hold legacy non-DT boards.
On a side note, I also like this because it would make converting old board files like sheevaplug and guruplug to DT easier. The legacy implementation would be in mach-mvebu/ and the DT implementation would be in plat-mvebu/. Newcomers to the code would see a clearly defined separation.
With that layout, where do the mach/* headers go?
Quoted 7 lines
Quoted 1 line
I think
arch/arm/plat-mvvebu/include/mach/*could work.And try to avoid putting anything in the
include/mach/directory which isn't needed by any code outside ofarch/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
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 7 lines · Arnd Bergmann
Quoted 5 lines · Russell King - ARM Linux
And try to avoid putting anything in the
include/mach/directory which isn't needed by any code outside ofarch/arm/{plat,mach}-*directory.In other words, headers needed only for code in
arch/arm/plat-mvvebu/should be in that very same directory.
Quoted 8 lines
Ok, so let me make sure I got it all right:
* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/mach
* headers used to inteface between the first two go to plat-mvebu/include/plat (?)
That sounds reasonable. The only eyebrow raising thing is having an include/mach inside a plat-* directory... that seems an odd way to do things as mach/ includes normally come from the mach-* directory.
So I wonder whether Nicolas' idea of "dt-only stuff in arch/arm/plat-*" is the right idea. It just makes plat-* the same as a mach-* but with a different name, whereas it is _supposed_ to be for stuff shared between a bunch of mach-* directories.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Arnd Bergmann
Quoted 5 lines · Russell King - ARM Linux
And try to avoid putting anything in the
include/mach/directory which isn't needed by any code outside ofarch/arm/{plat,mach}-*directory.In other words, headers needed only for code in
arch/arm/plat-mvvebu/should be in that very same directory.
Quoted 6 lines
Quoted 6 lines
Ok, so let me make sure I got it all right:
* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/mach
plat-mvebu/include/plat ?
Quoted 2 lines
Quoted 2 lines
* headers used to inteface between the first two go to plat-mvebu/include/plat (?)
plat-mvebu/include ?
Quoted 9 lines
That sounds reasonable. The only eyebrow raising thing is having an
include/machinside 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.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 6 lines · Jason Cooper
Quoted 4 lines
Quoted 4 lines
* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/machplat-mvebu/include/plat ?
Doesn't work because of the handful of places that #include <mach/*> with a common name, like irqs.h or debug-macro.S.
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
* headers used to inteface between the first two go to plat-mvebu/include/plat (?)
plat-mvebu/include ?
That would still put them into a globally visible location since we do gcc -I arch/arm/plat-${PLAT}/include.
Quoted 9 lines
Quoted 8 lines
That sounds reasonable. The only eyebrow raising thing is having an
include/machinside a plat-* directory... that seems an odd way to do things as mach/ includes normally come from the mach-* directory.So I wonder whether Nicolas' idea of "dt-only stuff in
arch/arm/plat-*" is the right idea. It just makes plat-* the same as a mach-* but with a different name, whereas it is supposed to be for stuff shared between a bunch of mach-* directories.
Quoted 5 lines
In an ideal (dt) world, plat-*/ would hold all the dt source files, and
arch/arm/boot/dts/would become the new mach-*/. mach-*/ is kept around for the few legacy, unconverted boards.Or, am I barking up the wrong tree?
I think we're not likely to get there any time soon. Most platforms in fact only have a mach-* directory at the moment and no plat-* directory.
Arnd
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Jason CooperQuoted 9 lines · Jason Cooper
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Arnd Bergmann
Quoted 5 lines · Russell King - ARM Linux
And try to avoid putting anything in the
include/mach/directory which isn't needed by any code outside ofarch/arm/{plat,mach}-*directory.In other words, headers needed only for code in
arch/arm/plat-mvvebu/should be in that very same directory.
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
Ok, so let me make sure I got it all right:
* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/machplat-mvebu/include/plat ?
Better.
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
* headers used to inteface between the first two go to plat-mvebu/include/plat (?)
plat-mvebu/include ?
No, we don't put include files in that directory, always a subdirectory. But note - any header file used _only_ by files in plat-mvebu should be in plat-mvebu itself and not some subdirectory. Locality of reference is the key idea there.
Quoted 4 lines
Quoted 4 lines
That sounds reasonable. The only eyebrow raising thing is having an
include/machinside a plat-* directory... that seems an odd way to do things as mach/ includes normally come from the mach-* directory.
Quoted 8 lines
Quoted 4 lines
So I wonder whether Nicolas' idea of "dt-only stuff in
arch/arm/plat-*" is the right idea. It just makes plat-* the same as a mach-* but with a different name, whereas it is _supposed_ to be for stuff shared between a bunch of mach-* directories.In an ideal (dt) world, plat-*/ would hold all the dt source files, and
arch/arm/boot/dts/would become the new mach-*/. mach-*/ is kept around for the few legacy, unconverted boards.
At that point I'd suggest the plat-* is renamed to mach-* ;)
plat-* was only invented to allow SoC folk to have some place to put common code shared between a set of mach-*, and nothing more.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 24 lines · Russell King - ARM Linux
Quoted 9 lines · Jason Cooper
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Arnd Bergmann
Quoted 5 lines · Russell King - ARM Linux
And try to avoid putting anything in the
include/mach/directory which isn't needed by any code outside ofarch/arm/{plat,mach}-*directory.In other words, headers needed only for code in
arch/arm/plat-mvvebu/should be in that very same directory.Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
Ok, so let me make sure I got it all right:
* all *.c files that are used for multiple boards go to plat-mvebu
* all *-setup.c files go to mach-mvebu
* only headers that are used outside of {mach,plat}-mvebug go to plat-mvebu/include/machplat-mvebu/include/plat ?
Better.
Quoted 3 lines
Quoted 2 lines
Quoted 2 lines
* headers used to inteface between the first two go to plat-mvebu/include/plat (?)
Quoted 6 lines
Quoted 1 line
plat-mvebu/include ?
No, we don't put include files in that directory, always a subdirectory. But note - any header file used _only_ by files in plat-mvebu should be in plat-mvebu itself and not some subdirectory. Locality of reference is the key idea there.
Got it, thanks for the clarification.
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
That sounds reasonable. The only eyebrow raising thing is having an
include/machinside a plat-* directory... that seems an odd way to do things as mach/ includes normally come from the mach-* directory.So I wonder whether Nicolas' idea of "dt-only stuff in
arch/arm/plat-*" is the right idea. It just makes plat-* the same as a mach-* but with a different name, whereas it is _supposed_ to be for stuff shared between a bunch of mach-* directories.
Quoted 8 lines
Quoted 3 lines
In an ideal (dt) world, plat-*/ would hold all the dt source files, and
arch/arm/boot/dts/would become the new mach-*/. mach-*/ is kept around for the few legacy, unconverted boards.At that point I'd suggest the plat-* is renamed to mach-* ;)
plat-* was only invented to allow SoC folk to have some place to put common code shared between a set of mach-*, and nothing more.
So lets follow that to it's logical end. How about we rename plat-orion/ to mach-mvebu/, put all dt-compatible code in mach-mvebu/, and empty the remaining mach-*/'s as they get converted?
mach-mvebu/'s directory tree structure could be:
include/ # no headers
include/mach/ # headers used by drivers, etc
include/board/ # common headers used by legacy board files
board/ # common source code for legacy board files
The end goal being to empty and remove the board/'s and remove the other mach-*/ directories.
Alternatively, in this scenario we could name 'board' -> 'legacy' to make it more obvious.
thx,
Jason.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 8 lines · Jason Cooper
mach-mvebu/'s directory tree structure could be:
include/# no headers
include/mach/# headers used by drivers, etc
include/board/# common headers used by legacy board files
board/ # common source code for legacy board filesThe 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.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 10 lines · Russell King - ARM Linux
Quoted 8 lines · Jason Cooper
mach-mvebu/'s directory tree structure could be:
include/# no headers
include/mach/# headers used by drivers, etc
include/board/# common headers used by legacy board files
board/ # common source code for legacy board filesThe end goal being to empty and remove the board/'s and remove the other mach-*/ directories.
Quoted 7 lines
Looking at what's in dove, kirkwood, mv78xx0 and orion5x directories, I don't see many board specific files. The only two I can see are leds-*.h, which are shared with platform drivers in
drivers/leds.We have a place for this already -
include/linux/platform_data.So I don't think we need
include/board/at all.
Fair enough, we can move that.
Quoted 2 lines
I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them
board-foo.c.
This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is board-dt.c, and board-dreamplug.c. board-dt.c is the DT code, while board-dreamplug.c is board specific init code that hasn't been converted to DT yet. Once converted, board-dreamplug.c will disappear. This follows what tegra is doing.
We can leave the legacy, unconverted boards where they are (mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c, pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...
Of course, we could leave everything alone (keep plat-orion/ as is), and create mach-mvebu/ for all devicetree boards under the mvebu umbrella. As boards are converted/moved to mach-mvebu/, they are deleted from their original mach-*/ All new boards would also go into mach-mvebu/
thx,
Jason.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 13 lines · Jason Cooper
Quoted 4 lines · Russell King - ARM Linux
On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:
I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them
board-foo.c.This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is
board-dt.c, andboard-dreamplug.c.board-dt.cis the DT code, whileboard-dreamplug.cis board specific init code that hasn't been converted to DT yet. Once converted,board-dreamplug.cwill disappear. This follows what tegra is doing.
Quoted 4 lines
We can leave the legacy, unconverted boards where they are (
mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c,pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...
I like the idea of leaving the *-setup.c board files where they are, while moving all the other files (headers and the platform-wide .c files) to mach-mvebu.
However, given that we still don't have consensus on where things should really be and the merge window is already open, I would suggest don't try to do it all now for v3.5 but rather plan it for v3.6 once we agreed on one approach, and then do some of the next consolidation steps as well.
Arnd
Nicolas Pitre
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 23 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 4 lines · Russell King - ARM Linux
On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:
I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them
board-foo.c.This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is
board-dt.c, andboard-dreamplug.c.board-dt.cis the DT code, whileboard-dreamplug.cis board specific init code that hasn't been converted to DT yet. Once converted,board-dreamplug.cwill disappear. This follows what tegra is doing.Quoted 4 lines
We can leave the legacy, unconverted boards where they are (
mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c,pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...I like the idea of leaving the *-setup.c board files where they are, while moving all the other files (headers and the platform-wide .c files) to mach-mvebu.
Quoted 5 lines
However, given that we still don't have consensus on where things should really be and the merge window is already open, I would suggest don't try to do it all now for v3.5 but rather plan it for v3.6 once we agreed on one approach, and then do some of the next consolidation steps as well.
I'd suggest that mach-mvebu be created earlier for the new EBU ARmada SOC support though.
Nicolas
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 25 lines · Nicolas Pitre
Quoted 23 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 4 lines · Russell King - ARM Linux
On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:
I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them
board-foo.c.This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is
board-dt.c, andboard-dreamplug.c.board-dt.cis the DT code, whileboard-dreamplug.cis board specific init code that hasn't been converted to DT yet. Once converted,board-dreamplug.cwill disappear. This follows what tegra is doing.Quoted 4 lines
We can leave the legacy, unconverted boards where they are (
mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c,pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...I like the idea of leaving the *-setup.c board files where they are, while moving all the other files (headers and the platform-wide .c files) to mach-mvebu.
Quoted 8 lines
Quoted 5 lines
However, given that we still don't have consensus on where things should really be and the merge window is already open, I would suggest don't try to do it all now for v3.5 but rather plan it for v3.6 once we agreed on one approach, and then do some of the next consolidation steps as well.
I'd suggest that mach-mvebu be created earlier for the new EBU ARmada SOC support though.
I'd like to second that, and suggest moving mach-kirkwood/board-*.c to it. Basically, make it the one location for marvell SoC dt boards.
I'm looking at the scope of it now.
thx,
Jason.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 32 lines · Jason Cooper
Quoted 31 lines · Nicolas Pitre
Quoted 28 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 4 lines · Russell King - ARM Linux
On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:
I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them
board-foo.c.This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is
board-dt.c, andboard-dreamplug.c.board-dt.cis the DT code, whileboard-dreamplug.cis board specific init code that hasn't been converted to DT yet. Once converted,board-dreamplug.cwill disappear. This follows what tegra is doing.Quoted 4 lines
We can leave the legacy, unconverted boards where they are (
mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c,pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...I like the idea of leaving the *-setup.c board files where they are, while moving all the other files (headers and the platform-wide .c files) to mach-mvebu.
However, given that we still don't have consensus on where things should really be and the merge window is already open, I would suggest don't try to do it all now for v3.5 but rather plan it for v3.6 once we agreed on one approach, and then do some of the next consolidation steps as well.
Quoted 7 lines
Quoted 2 lines
I'd suggest that mach-mvebu be created earlier for the new EBU ARmada SOC support though.
I'd like to second that, and suggest moving
mach-kirkwood/board-*.cto it. Basically, make it the one location for marvell SoC dt boards.I'm looking at the scope of it now.
I'm going to say let's leave these alone for the moment. The kernel per-version diff is large enough as it is and moving stuff around for the sake of it is just going to make it larger and thus draw more unwanted attention to arch/arm.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 39 lines · Ben Dooks
Quoted 38 lines · Jason Cooper
Quoted 25 lines · Nicolas Pitre
Quoted 23 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 4 lines · Russell King - ARM Linux
On Mon, May 21, 2012 at 11:35:59AM -0400, Jason Cooper wrote:
I'd also suggest going against our current setup of not having "board/" subdirectories in mach-*. Just name them
board-foo.c.This is what we are currently doing for boards in the midst of DT conversion. In mach-kirkwood/ there is
board-dt.c, andboard-dreamplug.c.board-dt.cis the DT code, whileboard-dreamplug.cis board specific init code that hasn't been converted to DT yet. Once converted,board-dreamplug.cwill disappear. This follows what tegra is doing.Quoted 4 lines
We can leave the legacy, unconverted boards where they are (
mach-kirkwood/guruplug-setup.c), but what about the common code they depend on (mpp.c,pcie.c, etc)? That's what I was suggesting putting in mach-mvebu/board/...I like the idea of leaving the *-setup.c board files where they are, while moving all the other files (headers and the platform-wide .c files) to mach-mvebu.
Quoted 8 lines
Quoted 5 lines
However, given that we still don't have consensus on where things should really be and the merge window is already open, I would suggest don't try to do it all now for v3.5 but rather plan it for v3.6 once we agreed on one approach, and then do some of the next consolidation steps as well.
I'd suggest that mach-mvebu be created earlier for the new EBU ARmada SOC support though.
I'd like to second that, and suggest moving
mach-kirkwood/board-*.cto it. Basically, make it the one location for marvell SoC dt boards.
Quoted 6 lines
Quoted 1 line
I'm looking at the scope of it now.
I'm going to say let's leave these alone for the moment. The kernel per-version diff is large enough as it is and moving stuff around for the sake of it is just going to make it larger and thus draw more unwanted attention to
arch/arm.
Fair enough.
thx,
Jason.
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Ben DooksQuoted 1 line · Ben Dooks
On 22/05/12 17:03, Jason Cooper wrote:
[snip]
Quoted 4 lines
I'm going to say let's leave these alone for the moment. The kernel per-version diff is large enough as it is and moving stuff around for the sake of it is just going to make it larger and thus draw more unwanted attention to
arch/arm.
We can re-visit this once we've had a chance to move the items out of plat-orion which can go under drivers/
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Jason CooperQuoted 8 lines · Jason Cooper
Quoted 4 lines · Nicolas Pitre
On Mon, 21 May 2012, Arnd Bergmann wrote:
I'd suggest that mach-mvebu be created earlier for the new EBU ARmada SOC support though.
I'd like to second that, and suggest moving
mach-kirkwood/board-*.cto 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
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Arnd BergmannQuoted 14 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 12 lines
In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.
I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.
Quoted 7 lines
Quoted 2 lines
I prefer mvebu_* ... nice and concise.
On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to
arch/arm/mach-mvebu/board/*.cinstead ofarch/arm/mach-mvebu/*-setup.c
What board files?
As I see it there are no current users and all additional kernel support should simply use devicetree.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
Andrew Lunn
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 23 lines · Ben Dooks
Quoted 14 lines · Arnd Bergmann
Quoted 13 lines · Jason Cooper
Quoted 12 lines
In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.
I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.
Quoted 7 lines
Quoted 2 lines
I prefer mvebu_* ... nice and concise.
On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to
arch/arm/mach-mvebu/board/*.cinstead ofarch/arm/mach-mvebu/*-setup.c
Quoted 4 lines
What board files?
As I see it there are no current users and all additional kernel support should simply use devicetree.
There are currently 14 kirkwood boards, 21 orion5x, 2 dove and 5 mv78xx0 boards. All would end up in the same directory as part of this rename/merge.
Andrewy
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 24 lines · Andrew Lunn
Quoted 23 lines · Ben Dooks
Quoted 21 lines · Arnd Bergmann
Quoted 8 lines · Jason Cooper
Quoted 8 lines
In this case, we have wildly different names referring to the same chip family, and "orion" is far from hinting that it also constitute the support for Kirkwood, Dove or (some not all) Armadas, unless you are familiar with some legacy Marvell products. This is why in this case I think that a directory name change might be appropriate, especially if we're going to cause churn by moving things around already.
Quoted 7 lines
Quoted 4 lines
I agree that mrvl_ebu_* is not pretty. This could be mv_ebu_* or mvebu_*. Unless someone has another logical identifier to suggest which would capture all that family of SOCs that came out of EBU in Marvell of course.
I prefer mvebu_* ... nice and concise.
On a related topic, any preferences on where we will put all the board files? I think it would be helpful to put them into a separate place from the main platform files, so e.g. have all *-setup.c files go to
arch/arm/mach-mvebu/board/*.cinstead ofarch/arm/mach-mvebu/*-setup.c
Quoted 8 lines
Quoted 4 lines
What board files?
As I see it there are no current users and all additional kernel support should simply use devicetree.
There are currently 14 kirkwood boards, 21 orion5x, 2 dove and 5 mv78xx0 boards. All would end up in the same directory as part of this rename/merge.
Personally, my view is leave it alone and just add a new machine directory.
Pushing items around doesn't really help the amount of code in the kernel, the organisation does not add more than a line or two to the Makefiles.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
Andrew Lunn
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 6 lines
Personally, my view is leave it alone and just add a new machine directory.
Pushing items around doesn't really help the amount of code in the kernel, the organisation does not add more than a line or two to the Makefiles.
It does however make it easier to see where the same code has been cut/paste. There is some stuff in the various Orion mach- directories which is repeated 4 times. The Armada XP port wanted to add a 5th copy. All this repeated code needs to be put into plat-orion.
Andrew
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 2 lines · Andrew Lunn
Quoted 2 lines
Personally, my view is leave it alone and just add a new machine directory.
I agree, see my response to Russell.
Quoted 8 lines
Quoted 3 lines
Pushing items around doesn't really help the amount of code in the kernel, the organisation does not add more than a line or two to the Makefiles.
It does however make it easier to see where the same code has been cut/paste. There is some stuff in the various Orion mach- directories which is repeated 4 times. The Armada XP port wanted to add a 5th copy. All this repeated code needs to be put into plat-orion.
Does my suggested layout/migration path cover your concerns?
thx,
Jason.
Andrew Lunn
maintainerPATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 10 lines · Jason Cooper
Quoted 2 lines · Andrew Lunn
Quoted 2 lines
Personally, my view is leave it alone and just add a new machine directory.
I agree, see my response to Russell.
Quoted 4 lines
Quoted 3 lines
Pushing items around doesn't really help the amount of code in the kernel, the organisation does not add more than a line or two to the Makefiles.
Quoted 6 lines
Quoted 4 lines
It does however make it easier to see where the same code has been cut/paste. There is some stuff in the various Orion mach- directories which is repeated 4 times. The Armada XP port wanted to add a 5th copy. All this repeated code needs to be put into plat-orion.
Does my suggested layout/migration path cover your concerns?
I actually like Arnd patch of putting everything into one directory. I've been building on that patch removing duplicate code, modifying the address map to make it as similar as possible, removing defines which are the same on all SoCs etc. I think actually having everything spread out is what has contributed to the X copies and needless incompatibilities.
My vote is to commit Arnd patch as is.
Andrew
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Thomas PetazzoniQuoted 12 lines · Thomas Petazzoni
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.At the moment, both the Armada 370 and the Armada XP SoCs are supported in this directory, and we are able to build a single kernel image that boots on both SoCs. Both SoCs use the PJ4B processor, a Marvell-developed ARM core that implements the ARMv7 instruction set. We are currently using Marvell evaluation boards for both of those SoCs, and the support for those boards is added in this patch set.
Quoted 3 lines
This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:
Hi Thomas,
The code looks reasonable overall, but I fear your timing is unfortunate and we can't expect to complete the review before the merge window opens. Things would have been much easier if you had posted preliminary versions a few weeks earlier, but my feeling is that this should be treated as v3.6 material.
Arnd
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Hello Arnd,
Le Tue, 15 May 2012 11:06:46 +0000,
Arnd Bergmann <[email protected]> a ?crit :
Quoted 5 lines
The code looks reasonable overall, but I fear your timing is unfortunate and we can't expect to complete the review before the merge window opens. Things would have been much easier if you had posted preliminary versions a few weeks earlier, but my feeling is that this should be treated as v3.6 material.
We do not expect this to be treated as v3.5 material. From the very beginning, with a posting at this time, we have been targeting v3.6 for a potential inclusion.
Quoted 1 line
From our point of view, these are kind of the preliminary versions:
there are many comments that we'll have to take into account before getting to the version that can be merged.
Thanks,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Arnd BergmannQuoted 17 lines · Arnd Bergmann
Quoted 12 lines · Thomas Petazzoni
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.At the moment, both the Armada 370 and the Armada XP SoCs are supported in this directory, and we are able to build a single kernel image that boots on both SoCs. Both SoCs use the PJ4B processor, a Marvell-developed ARM core that implements the ARMv7 instruction set. We are currently using Marvell evaluation boards for both of those SoCs, and the support for those boards is added in this patch set.
Quoted 3 lines
This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:
Quoted 7 lines
Hi Thomas,
The code looks reasonable overall, but I fear your timing is unfortunate and we can't expect to complete the review before the merge window opens. Things would have been much easier if you had posted preliminary versions a few weeks earlier, but my feeling is that this should be treated as v3.6 material.
I'm happy for this to go in once v3.5 is out as long as the issues with the device-tree binding is sorted out and the few issues that have cropped up in testing are fixed.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Thomas PetazzoniQuoted 51 lines · Thomas Petazzoni
Arnd, Olof,
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.At the moment, both the Armada 370 and the Armada XP SoCs are supported in this directory, and we are able to build a single kernel image that boots on both SoCs. Both SoCs use the PJ4B processor, a Marvell-developed ARM core that implements the ARMv7 instruction set. We are currently using Marvell evaluation boards for both of those SoCs, and the support for those boards is added in this patch set.
This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:
Documentation/devicetree/bindings/arm/armada-mpic.txt | 23 + Documentation/devicetree/bindings/arm/armada-timer.txt | 11 Documentation/devicetree/bindings/arm/armada.txt | 24 + MAINTAINERS | 8 arch/arm/Kconfig | 12 arch/arm/Makefile | 1 arch/arm/boot/dts/a370-db.dts | 41 ++ arch/arm/boot/dts/a370.dtsi | 23 + arch/arm/boot/dts/armada.dtsi | 67 ++++ arch/arm/boot/dts/axp-db.dts | 40 ++ arch/arm/boot/dts/axp.dtsi | 43 +++ arch/arm/configs/armada_defconfig | 47 +++ arch/arm/mach-armada/Kconfig | 19 + arch/arm/mach-armada/Makefile | 3 arch/arm/mach-armada/Makefile.boot | 1 arch/arm/mach-armada/a370-dt.c | 41 ++ arch/arm/mach-armada/axp-dt.c | 41 ++ arch/arm/mach-armada/common.c | 56 +++ arch/arm/mach-armada/common.h | 27 + arch/arm/mach-armada/include/mach/armada.h | 234 ++++++++++++++++ arch/arm/mach-armada/include/mach/bridge-regs.h | 28 + arch/arm/mach-armada/include/mach/debug-macro.S | 23 + arch/arm/mach-armada/include/mach/gpio.h | 13 arch/arm/mach-armada/include/mach/hardware.h | 18 + arch/arm/mach-armada/include/mach/io.h | 24 + arch/arm/mach-armada/include/mach/irqs.h | 96 ++++++ arch/arm/mach-armada/include/mach/system.h | 21 + arch/arm/mach-armada/include/mach/timex.h | 13 arch/arm/mach-armada/include/mach/uncompress.h | 41 ++ arch/arm/mach-armada/irq.c | 116 ++++++++ arch/arm/mach-armada/time.c | 243 +++++++++++++++++ 31 files changed, 1398 insertions(+)
Quoted 7 lines
This patch set, and the support for those SoCs, is at the moment a collaborative effort from Marvell engineers (who have done the initial development work) and Free Electrons engineers (who are reshaping the code for mainline submission, adding device tree support, etc.). Other contributors are expected to join this effort.
The patch set is based on your arm-soc/for-next branch.
Is there a git tree that can be pulled from?
Quoted 4 lines
We intend to quickly build on top of this initial support with the following elements:
* Usage of the clock framework
I'd say that was a pretty important part even if it just a couple of static clocks for the tclk and fabric clock.
Quoted 19 lines
* Usage the pinctrl subsystem and GPIO subsystems for pin-muxing and GPIO support
* SMP support
* L2 cache support
* Integration with device drivers. Many of the IPs used in these Marvell SoCs are similar to the ones used in previous Marvell SoCs (for SATA, USB and more), but the drivers for those IPs will require modification to add a device tree binding.
Of course, we welcome all comments on this initial submission and are ready to quickly submit updated versions of the patch set to take into those comments.
Best regards,
Thomas Petazzoni
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 11 lines
-----Original Message-----
From: Ben Dooks [mailto:ben.dooks at codethink.co.uk]
Sent: Tuesday, May 15, 2012 2:19 PM
To: Thomas Petazzoni
Cc: Arnd Bergmann; Olof Johansson; Lior Amsalem; Andrew Lunn; Jason Cooper; Nicolas Pitre; Maen Suleiman; Ben Dooks; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH] arm: Add basic support for new Marvell Armada SoC familyOn 15/05/12 09:54, Thomas Petazzoni wrote:
[snip]
Quoted 4 lines
Quoted 2 lines
The patch set is based on your arm-soc/for-next branch.
Is there a git tree that can be pulled from?
https://github.com/Marvell-Semi/EBU_mainline_public/tree/for-next
Quoted 9 lines
Quoted 5 lines
We intend to quickly build on top of this initial support with the following elements:
* Usage of the clock framework
I'd say that was a pretty important part even if it just a couple of static clocks for the tclk and fabric clock.
It's one of our tasks list, should be ready soon.
Quoted 9 lines
Quoted 4 lines
Best regards,
Thomas Petazzoni
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
Lior Amsalem
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Ben DooksLe Tue, 15 May 2012 12:18:55 +0100,
Ben Dooks <[email protected]> a ?crit :
Quoted 3 lines
Quoted 1 line
The patch set is based on your arm-soc/for-next branch.
Is there a git tree that can be pulled from?
Yes: https://github.com/Marvell-Semi/EBU_mainline_public/tree/for-next.
Note that of course we will be constantly rebasing this branch.
Quoted 7 lines
Quoted 4 lines
We intend to quickly build on top of this initial support with the following elements:
* Usage of the clock framework
I'd say that was a pretty important part even if it just a couple of static clocks for the tclk and fabric clock.
As Lior said, it's on the TODO-list. It's true that adding the few static clocks to tclk and the fabric clock can probably be done in this initial submission, as the amount of work needed is fairly small.
Thanks,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Thomas PetazzoniQuoted 5 lines · Thomas Petazzoni
Arnd, Olof,
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.
[snip]
Out of interest, what about the Marvell Sheeva-V7 core specific errata that the Marvell kernel has?
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 13 lines
-----Original Message-----
From: Ben Dooks [mailto:ben.dooks at codethink.co.uk]
Sent: Tuesday, May 15, 2012 2:21 PM
To: Thomas Petazzoni
Cc: Arnd Bergmann; Olof Johansson; Lior Amsalem; Andrew Lunn; Jason Cooper; Nicolas Pitre; Maen Suleiman; Ben Dooks; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH] arm: Add basic support for new Marvell Armada SoC familyQuoted 2 lines · Thomas Petazzoni
Arnd, Olof,
Quoted 8 lines
Quoted 3 lines
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.[snip]
Out of interest, what about the Marvell Sheeva-V7 core specific errata that the Marvell kernel has?
Work in progress. As well as SMP support.
Quoted 4 lines
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
Lior Amsalem
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Thomas PetazzoniQuoted 14 lines · Thomas Petazzoni
Arnd, Olof,
You'll find in this patch set the initial support for a new family of ARMv7-compatible Marvell SoCs, that we have choosen to support in the
arch/arm/mach-armada/directory.At the moment, both the Armada 370 and the Armada XP SoCs are supported in this directory, and we are able to build a single kernel image that boots on both SoCs. Both SoCs use the PJ4B processor, a Marvell-developed ARM core that implements the ARMv7 instruction set. We are currently using Marvell evaluation boards for both of those SoCs, and the support for those boards is added in this patch set.
Quoted 3 lines
This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:
FYI, built and tested on our system here and it gets to printing the sched_clock line and getting no further.
I will have a debug.
The only comment so far other than the review issues is that we needed to enable CONFIG_HIGMEM to get >780MiB of memory as this system comes with 2048MiB as standard.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Le Tue, 15 May 2012 15:55:07 +0100,
Ben Dooks <[email protected]> a ?crit :
Quoted 8 lines
Quoted 3 lines
This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:
FYI, built and tested on our system here and it gets to printing the
sched_clockline and getting no further.I will have a debug.
Hum, strange. On which platform exactly?
I've built from scratch a kernel image this morning and boot tested it on both the DB-78460-BP (Armada XP) and DB-88F6710-BP (Armada 370) this morning, and it was working.
Quoted 3 lines
The only comment so far other than the review issues is that we needed to enable
CONFIG_HIGMEMto get >780MiB of memory as this system comes with 2048MiB as standard.
Good point. Will do.
Thanks!
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Quoted 7 lines · Thomas Petazzoni
Le Tue, 15 May 2012 15:55:07 +0100,
Ben Dooks<[email protected]> a ?crit :Quoted 4 lines
Quoted 3 lines
This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:
Quoted 6 lines
Quoted 4 lines
FYI, built and tested on our system here and it gets to printing the
sched_clockline and getting no further.I will have a debug.
Hum, strange. On which platform exactly?
Cogent CS1726, using MV78460 (A0)
Quoted 9 lines
I've built from scratch a kernel image this morning and boot tested it on both the DB-78460-BP (Armada XP) and DB-88F6710-BP (Armada 370) this morning, and it was working.
Quoted 3 lines
The only comment so far other than the review issues is that we needed to enable
CONFIG_HIGMEMto get>780MiB of memory as this system comes with 2048MiB as standard.Good point. Will do.
I'm guessing it'll be a useful default, but not a necessity.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
In reply to Thomas PetazzoniQuoted 7 lines · Thomas Petazzoni
Le Tue, 15 May 2012 15:55:07 +0100,
Ben Dooks<[email protected]> a ?crit :Quoted 4 lines
Quoted 3 lines
This preliminary support only includes the necessary code for timer and IRQ support, the serial controller is a standard 16550-compatible one. The diffstat looks like:
Quoted 6 lines
Quoted 4 lines
FYI, built and tested on our system here and it gets to printing the
sched_clockline and getting no further.I will have a debug.
Hum, strange. On which platform exactly?
I've tracked this down to the following:arch/arm/mach-armada/time.c
190 } else {
191 u32 clk;
192 of_property_read_u32(np, "clock-frequency", &clk);
193 WARN_ON(!clk);The problem is the 'clk' variable is un-initialised and therefore the fact my device-tree is missing a clock-frequency property is causing the system to use what was in 'clk' which was around 16000 from the stack.
I suggest that any property that is necessary to a unit operation should check that there was something to read. WARN_ON() is fine, but they you should not carry on and initialise the unit anyway.
I have now gone and fixed my .dts file and the system now gets to the point to try and mount an initrd.
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH 1/1 arm: Add basic support for new Marvell Armada SoC family
Le Tue, 15 May 2012 16:36:03 +0100,
Ben Dooks <[email protected]> a ?crit :
Quoted 13 lines
I've tracked this down to the following:
arch/arm/mach-armada/time.c190 } else { 191 u32 clk; 192 of_property_read_u32(np, "clock-frequency",&clk); 193
WARN_ON(!clk);The problem is the 'clk' variable is un-initialised and therefore the fact my device-tree is missing a clock-frequency property is causing the system to use what was in 'clk' which was around 16000 from the stack.
Quoted 6 lines
I suggest that any property that is necessary to a unit operation should check that there was something to read.
WARN_ON()is fine, but they you should not carry on and initialise the unit anyway.I have now gone and fixed my .dts file and the system now gets to the point to try and mount an initrd.
Thanks for your report and investigation, you're obviously correct. We'll fix that.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com