aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/mach-mvebu/armada-370-xp.c
AgeCommit message (Collapse)Author
2013-05-13ARM: Orion: Remove redundant init_dma_coherent_pool_size()Andrew Lunn
The patch: 387870f mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls makes these calls on Kirkwood and Orion5x redundant. The drivers are not making atomic requests for coherent memory and hence the default pool size is now sufficient. Jason Cooper added mach-mvebu/ hunk, and corrected minor typos in commit message. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-05-07Merge tag 'cleanup-for-linus-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC late cleanups from Arnd Bergmann: "These are cleanups and smaller changes that either depend on earlier feature branches or came in late during the development cycle. We normally try to get all cleanups early, so these are the exceptions: - A follow-up on the clocksource reworks, hopefully the last time we need to merge clocksource subsystem changes through arm-soc. A first set of patches was part of the original 3.10 arm-soc cleanup series because of interdependencies with timer drivers now moved out of arch/arm. - Migrating the SPEAr13xx platform away from using auxdata for DMA channel descriptions towards using information in device tree, based on the earlier SPEAr multiplatform series - A few follow-ups on the Atmel SAMA5 support and other changes for Atmel at91 based on the larger at91 reworks. - Moving the armada irqchip implementation to drivers/irqchip - Several OMAP cleanups following up on the larger series already merged in 3.10." * tag 'cleanup-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (50 commits) ARM: OMAP4: change the device names in usb_bind_phy ARM: OMAP2+: Fix mismerge for timer.c between ff931c82 and da4a686a ARM: SPEAr: conditionalize SMP code ARM: arch_timer: Silence debug preempt warnings ARM: OMAP: remove unused variable serial: amba-pl011: fix !CONFIG_DMA_ENGINE case ata: arasan: remove the need for platform_data ARM: at91/sama5d34ek.dts: remove not needed compatibility string ARM: at91: dts: add MCI DMA support ARM: at91: dts: add i2c dma support ARM: at91: dts: set #dma-cells to the correct value ARM: at91: suspend both memory controllers on at91sam9263 irqchip: armada-370-xp: slightly cleanup irq controller driver irqchip: armada-370-xp: move IRQ handler to avoid forward declaration irqchip: move IRQ driver for Armada 370/XP ARM: mvebu: move L2 cache initialization in init_early() devtree: add binding documentation for sp804 ARM: integrator-cp: convert use CLKSRC_OF for timer init ARM: versatile: use OF init for sp804 timer ARM: versatile: add versatile dtbs to dtbs target ...
2013-04-15irqchip: move IRQ driver for Armada 370/XPThomas Petazzoni
When the Marvell Armada 370/XP support was included in the kernel, the drivers/irqchip/ directory didn't exist and the minimal infrastructure in it also didn't exist. Now that we have those things in place, we move the Armada 370/XP IRQ controller driver from arch/arm/mach-mvebu/irq-armada-370-xp.c to drivers/irqchip/irq-armada-370-xp.c. Note in order to reduce code movement and therefore ease the review of this patch, we intentionally introduce a forward declaration of armada_370_xp_handle_irq(). It is in fact not needed because this handler can now simply be implemented before armada_370_xp_mpic_of_init(). That will be done in the next commit. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-15ARM: mvebu: move L2 cache initialization in init_early()Thomas Petazzoni
In preparation for moving the IRQ controller driver to drivers/irqchip/, we don't want the IRQ controller driver to be responsible for initializing the L2 cache. Instead, let's initialize the L2 cache at the init_early() level, like mach-exynos/common.c is doing. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-15arm: mach-mvebu: convert to use mvebu-mbus driverThomas Petazzoni
The changes needed to migrate the mach-mvebu (Armada 370 and Armada XP) to the mvebu-mbus driver are fairly minimal, since not many devices currently supported on those SoCs use address decoding windows. The only one being the BootROM window, used to bring up secondary CPUs. However, this BootROM window needed for SMP brings an important requirement: the mvebu-mbus driver must be initialized at the ->early_init() time, otherwise the BootROM window cannot be setup early enough to be ready before the secondary CPUs are started. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-12-24ARM: delete struct sys_timerStephen Warren
Now that the only field in struct sys_timer is .init, delete the struct, and replace the machine descriptor .timer field with the initialization function itself. This will enable moving timer drivers into drivers/clocksource without having to place a public prototype of each struct sys_timer object into include/linux; the intent is to create a single of_clocksource_init() function that determines which timer driver to initialize by scanning the device dtree, much like the proposed irqchip_init() at: http://www.spinics.net/lists/arm-kernel/msg203686.html Includes mach-omap2 fixes from Igor Grinberg. Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-11-22Merge tag 'marvell-armadaxp-smp-for-3.8' of ↵Thomas Petazzoni
github.com:MISL-EBU-System-SW/mainline-public into mevbu-dt-additions SMP support for Armada XP The purpose of this series is to add the SMP support for the Armada XP SoCs. Beside the SMP support itself brought by the last 3 commits, this series also adds the support for the coherency fabric unit and the power management service unit. The coherency fabric is responsible for ensuring hardware coherency between all CPUs and between CPUs and I/O masters. This unit is also available for Armada 370 and will be used in an incoming patch set for hardware I/O cache coherency. The power management service unit is responsible for powering down and waking up CPUs and other SOC units. Conflicts: arch/arm/mach-mvebu/armada-370-xp.c
2012-11-22Merge branch 'for-jason-1/cleanup' into mevbu-dt-additionsThomas Petazzoni
2012-11-21arm: mvebu: Add SMP support for Armada XPGregory CLEMENT
This enables SMP support on the Armada XP processor. It adds the mandatory functions to support SMP such as: the SMP initialization functions in platsmp.c, the secondary CPU entry point in headsmp.S and the CPU hotplug initial support in hotplug.c. Signed-off-by: Yehuda Yitschak <yehuday@marvell.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Will Deacon <will.deacon@arm.com>
2012-11-20arm: mvebu: increase atomic coherent pool size for armada 370/XPGregory CLEMENT
For Armada 370/XP we have the same problem that for the commit cb01b63, so we applied the same solution: "The default 256 KiB coherent pool may be too small for some of the Kirkwood devices, so increase it to make sure that devices will be able to allocate their buffers with GFP_ATOMIC flag" Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
2012-11-20clk: armada-370-xp: add support for clock frameworkGregory CLEMENT
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by Gregory CLEMENT <gregory.clement@free-electrons.com>
2012-11-14arm: mvebu: fix typo in machine name for Armada 370/XPThomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2012-11-14arm: mvebu: don't list all boards in dt compat field for Armada 370/XPThomas Petazzoni
Instead of listing explicitly all boards in the .dt_compat field of the DT_MACHINE_START structure for Armada 370/XP, use instead a compatible string that is common to all boards using the Armada 370/XP. This allows to add new boards by just using a different Device Tree, without having to modify the source code of the kernel. Note that the name of the array containing the compatible string is also renamed, to reflect the fact that it no longer contains the list of all boards. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2012-09-22Merge branch 'kirkwood/addr_decode' of ↵Olof Johansson
git://git.infradead.org/users/jcooper/linux into late/kirkwood * 'kirkwood/addr_decode' of git://git.infradead.org/users/jcooper/linux: arm: mvebu: add address decoding controller to the DT arm: mvebu: add basic address decoding support to Armada 370/XP arm: plat-orion: make bridge_virt_base non-const to support DT use case arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option arm: plat-orion: use void __iomem pointers for addr-map functions arm: plat-orion: use void __iomem pointers for time functions arm: plat-orion: use void __iomem pointers for MPP functions arm: plat-orion: use void __iomem pointers for UART registration functions arm: mach-mvebu: use IOMEM() for base address definitions arm: mach-orion5x: use IOMEM() for base address definitions arm: mach-mv78xx0: use IOMEM() for base address definitions arm: mach-kirkwood: use IOMEM() for base address definitions arm: mach-dove: use IOMEM() for base address definitions arm: mach-orion5x: use plus instead of or for address definitions arm: mach-mv78xx0: use plus instead of or for address definitions arm: mach-kirkwood: use plus instead of or for address definitions arm: mach-dove: use plus instead of or for address definitions This branch had quite a few conflicts, in particular with the PCI static map rework from Rob Herring, and a few other context conflicts due to changes in Kconfig, etc. I fixed up conflicts in: arch/arm/Kconfig arch/arm/mach-dove/common.c arch/arm/mach-dove/include/mach/dove.h arch/arm/mach-kirkwood/common.c arch/arm/mach-kirkwood/include/mach/kirkwood.h arch/arm/mach-mv78xx0/common.c arch/arm/mach-mv78xx0/include/mach/mv78xx0.h arch/arm/mach-orion5x/common.c arch/arm/mach-orion5x/include/mach/orion5x.h Signed-off-by: Olof Johansson <olof@lixom.net>
2012-09-21arm: mach-mvebu: use IOMEM() for base address definitionsThomas Petazzoni
We now define all virtual base address constants using IOMEM() so that those are naturally typed as void __iomem pointers, and we do the necessary adjustements in the mach-mvebu code. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-09-14ARM: mvebu: move armada-370-xp.h in mach dirRob Herring
Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch>
2012-07-10arm: mach-mvebu: add support for Armada 370 and Armada XP with DTThomas Petazzoni
[ben.dooks@codethink.co.uk: ensure error check on of_property_read_u32] [ben.dooks@codethink.co.uk: use mpic address instead of bus-unit's ] [ben.dooks@codethink.co.uk: BUG_ON() if the of_iomap() fails for mpic] [ben.dooks@codethink.co.uk: move mpic per-cpu register base ] [ben.dooks@codethink.co.uk: number fetch should use irqd_to_hwirq()] Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Lior Amsalem <alior@marvell.com> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Yehuda Yitschak <yehuday@marvell.com> Tested-by: Lior Amsalem <alior@marvell.com>