summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-dove/irq.c
Commit message (Collapse)AuthorAgeFilesLines
* ARM: orion: switch to a per-platform handle_irq() functionThomas Petazzoni2014-04-261-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | Moving to the Device Tree implies having CONFIG_MULTI_IRQ_HANDLER enabled, even for non-DT platforms (if we want both DT and non-DT platforms to be supported in a single kernel). However, the common CONFIG_MULTI_IRQ_HANDLER handler for non-DT platforms in plat-orion/irq.c doesn't match the needs of Orion5x. Also, it doesn't make much sense for orion_irq_init() to register the multi-IRQ handler: orion_irq_init() is called once for each IRQ cause/mask tuple, while the multi-IRQ handler only needs to be registered once. To solve this problem, we move the multi-IRQ handle in per-platform code: mach-kirkwood/irq.c and mach-dove/irq.c. The Orion5x variant will be introduced in a followup commit. Of course, this code will ultimately be completely removed once all boards are converted to the Device Tree. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: https://lkml.kernel.org/r/1398202002-28530-23-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* Dove: Attempt to fix PMU/RTC interruptsRussell King - ARM Linux2012-11-211-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the acknowledgement of PMU interrupts on Dove: some Dove hardware has not been sensibly designed so that interrupts can be handled in a race free manner. The PMU is one such instance. The pending (aka 'cause') register is a bunch of RW bits, meaning that these bits can be both cleared and set by software (confirmed on the Armada-510 on the cubox.) Hardware sets the appropriate bit when an interrupt is asserted, and software is required to clear the bits which are to be processed. If we write ~(1 << bit), then we end up asserting every other interrupt except the one we're processing. So, we need to do a read-modify-write cycle to clear the asserted bit. However, any interrupts which occur in the middle of this cycle will also be written back as zero, which will also clear the new interrupts. The upshot of this is: there is _no_ way to safely clear down interrupts in this register (and other similarly behaving interrupt pending registers on this device.) The patch below at least stops us creating new interrupts. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: stable@vger.kernel.org Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* Merge branch 'kirkwood/addr_decode' of ↵Olof Johansson2012-09-221-5/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * arm: mach-dove: use IOMEM() for base address definitionsThomas Petazzoni2012-09-211-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-dove code. Note that we introduce a few temporary additional "unsigned long" casts when calling into plat-orion functions. Those are removed by followup patches converting plat-orion functions to void __iomem pointers as well. 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>
* | ARM: orion: move custom gpio functions to orion-gpio.hRob Herring2012-09-141-0/+1
|/ | | | | | | | | Move custom orion platforms gpio code to orion-gpio to remove the dependency on mach/gpio.h. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch>
* ARM: Orion: DT support for IRQ and GPIO ControllersAndrew Lunn2012-07-271-29/+29
| | | | | | | | | | | | | Both IRQ and GPIO controllers can now be represented in DT. The IRQ controllers are setup first, and then the GPIO controllers. Interrupts for GPIO lines are placed directly after the main interrupts in the interrupt space. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Josh Coombs <josh.coombs@gmail.com> Tested-by: Simon Baatz <gmbnomis@gmail.com>
* arm: Fold irq_set_chip/irq_set_handlerThomas Gleixner2011-03-291-2/+1
| | | | | | Use irq_set_chip_and_handler() instead. Converted with coccinelle. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* arm: Cleanup the irq namespaceThomas Gleixner2011-03-291-8/+8
| | | | | | Convert to the new function names. Automated with coccinelle. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* arm: dove: Use proper irq accessor functionsThomas Gleixner2011-03-291-3/+2
| | | | | | Remove the obsolete desc_handle_irq() helper. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* ARM: Remove dependency of plat-orion GPIO code on mach directory includes.Lennert Buytenhek2011-03-031-16/+14
| | | | | | | | | | | | This patch makes the various mach dirs that use the plat-orion GPIO code pass in GPIO-related platform info (GPIO controller base address, secondary base IRQ number, etc) explicitly, instead of having plat-orion get those values by including a mach dir include file -- the latter mechanism is problematic if you want to support multiple ARM platforms in the same kernel image. Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
* ARM: dove: irq_data conversion.Lennert Buytenhek2011-01-131-9/+9
| | | | | Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca> Acked-by: Nicolas Pitre <nico@fluxnic.net>
* ARM: add base support for Marvell Dove SoCSaeed Bishara2009-11-271-0/+133
The Marvell Dove (88AP510) is a high-performance, highly integrated, low power SoC with high-end ARM-compatible processor (known as PJ4), graphics processing unit, high-definition video decoding acceleration hardware, and a broad range of peripherals. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Saeed Bishara <saeed@marvell.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>
OpenPOWER on IntegriCloud