Commit Graph

10 Commits

Author SHA1 Message Date
Linus Torvalds ef42c58a5b Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq updates from Thomas Gleixner:
 "This lot provides:

   * Bugfixes for armada irq controller
   * Updates to renesas irq chip
   * Support for the TI-NSPIRE irq controller

  Not strictly a bug fix only pull request, but important updates for
  some of the arm Socs which I completely forgot to send last week.

  Seems like my obliviousness is getting worse, I just can't remember
  when it started"

* 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip: Add support for TI-NSPIRE irqchip
  irqchip: renesas-irqc: Enable mask on suspend
  irqchip: renesas-irqc: Use lazy disable
  irqchip: armada-370-xp: fix MSI race condition
  irqchip: armada-370-xp: fix IPI race condition
2014-02-05 16:02:53 -08:00
Arnaud Ebalard 19e61d4140 ARM: mvebu: fix compilation warning on Armada 370 (i.e. non-SMP)
The following appears during compilation for an Armada 370 target
because 'irq_controller_lock' is used only when CONFIG_SMP is
enabled:

 drivers/irqchip/irq-armada-370-xp.c:62:8: warning: 'irq_controller_lock' defined but not used [-Wunused-variable]

Fix that warning by moving declaration of 'irq_controller_lock'
inside existing #ifdef.

Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-01-21 00:55:47 +00:00
Lior Amsalem c7f7bd4a13 irqchip: armada-370-xp: fix MSI race condition
In the Armada 370/XP driver, when we receive an IRQ 1, we read the
list of doorbells that caused the interrupt from register
ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS. This gives the list of MSIs that
were generated. However, instead of acknowledging only the MSIs that
were generated, we acknowledge *all* the MSIs, by writing
~MSI_DOORBELL_MASK in the ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register.

This creates a race condition: if a new MSI that isn't part of the
ones read into the temporary "msimask" variable is fired before we
acknowledge all MSIs, then we will simply loose it.

It is important to mention that this ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS
register has the following behavior: "A CPU write of 0 clears the bits
in this field. A CPU write of 1 has no effect". This is what allows us
to simply write ~msimask to acknoledge the handled MSIs.

Notice that the same problem is present in the IPI implementation, but
it is fixed as a separate patch, so that this IPI fix can be pushed to
older stable versions as appropriate (all the way to 3.8), while the
MSI code only appeared in 3.13.

Signed-off-by: Lior Amsalem <alior@marvell.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-12-13 16:34:40 +00:00
Lior Amsalem a6f089e95b irqchip: armada-370-xp: fix IPI race condition
In the Armada 370/XP driver, when we receive an IRQ 0, we read the
list of doorbells that caused the interrupt from register
ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS. This gives the list of IPIs that
were generated. However, instead of acknowledging only the IPIs that
were generated, we acknowledge *all* the IPIs, by writing
~IPI_DOORBELL_MASK in the ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register.

This creates a race condition: if a new IPI that isn't part of the
ones read into the temporary "ipimask" variable is fired before we
acknowledge all IPIs, then we will simply loose it. This is causing
scheduling hangs on SMP intensive workloads.

It is important to mention that this ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS
register has the following behavior: "A CPU write of 0 clears the bits
in this field. A CPU write of 1 has no effect". This is what allows us
to simply write ~ipimask to acknoledge the handled IPIs.

Notice that the same problem is present in the MSI implementation, but
it will be fixed as a separate patch, so that this IPI fix can be
pushed to older stable versions as appropriate (all the way to 3.8),
while the MSI code only appeared in 3.13.

Signed-off-by: Lior Amsalem <alior@marvell.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: stable@vger.kernel.org # v3.8+
Fixes: 344e873e56 'arm: mvebu: Add IPI support via doorbells'
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-12-13 16:34:04 +00:00
Thomas Petazzoni 31f614edb7 irqchip: armada-370-xp: implement MSI support
This commit introduces the support for the MSI interrupts in the
armada-370-xp interrupt controller driver. It registers an MSI chip to
the MSI chip registry, which will be used by the Marvell PCIe host
controller driver.

The MSI interrupts use the 16 high doorbells, and are therefore
notified using IRQ1 of the main interrupt controller.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-09-30 14:58:12 +00:00
Thomas Petazzoni 627dfcc249 irqchip: armada-370-xp: properly request resources
Instead of using of_iomap(), we now use of_address_to_resource(),
request_mem_region() and ioremap(). This allows the corresponding I/O
regions to be properly requested and visible in /proc/iomem.

The main motivation for this change is that the introduction of the
MSI support requires us to get the physical address of the main
interrupt controller registers, so we will need the corresponding
'struct resource' anyway.

We also take this opportunity to change a panic() to BUG_ON(), in
order to be consistent with the rest of the driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Daniel Price <daniel.price@gmail.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-09-30 14:58:07 +00:00
Linus Torvalds 1bf25e78af ARM: arm-soc: late cleanups
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.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIVAwUAUYj5U2CrR//JCVInAQLNIRAAvsCtYOmXTxkRBxdtNEUUbkEjx71Se7q0
 h9PR8vqlkbYwONkJ8a6j8pKq/WJDmLpHQWg/moBsvlGc6uEVBPBFhCWHs1+yGUzX
 GhnJOaIKh3+651hIoXccS+/YZ16e1EAzdCM7+1QegPTldsRGkTOiwXgmR51kmPrz
 6cZ8P5MFqMrWIy4XqWhOBbMDCY/An05IHMpniGIamUg2/uB921Z0wNFvDrnsg97u
 DsVEwimyCJ0j7aO4TH+fkvsjoGWnIhxPtpaIm8iff6TPRI49deRb3zYpnIONm+oG
 /cQrRf3BNW+aiTuRCTEjdBNGtcrYgN6CLWWjzgMhv1itSlX8swBcOhuNJRCGNQRI
 v3wL4aEBxUpPGGL8erc2GIW7pe29YC2UEYI2z1X/5MEzYO589zkkG2k+/3HQVUwp
 dnYpQxhjRMvh4mcodBJFRjzH1Z7agKUwtoKalAHRRH7r5gJDkpL3zLoMhYPTG5IZ
 OwU+aYf+dDxh2kKW0zs8a/qL97UTHjlTRUC9LPoumvJ7LlKeDfzEn7DHUm2gggiu
 dO9ye/NF/xEXoDXTl0Qp2wJ6/sbPSLyCYCIMdP/gJjWUiDDqqZ0VRaKL7vE/JWrd
 NJ7k5yunX8/kRgfqgRFLDdFnPj1JeYHlmexsq4l9TPbPstoIcbw8u1v9sr8aZF+Z
 agh9u4e7QU8=
 =HWfp
 -----END PGP SIGNATURE-----

Merge tag 'cleanup-for-linus-2' of 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-05-07 11:22:14 -07:00
Thomas Petazzoni 5ec69017cc irqchip: armada-370-xp: slightly cleanup irq controller driver
In preparation for the introduction of MSI support in the IRQ
controller driver, we clarify the implementation of IPI using
additional defines for the manipulation of doorbells. Just like IPIs
are implemented using doorbells, MSIs will also use doorbells, so it
makes sense to do this preparatory cleanup first.

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-15 19:35:17 +00:00
Thomas Petazzoni b313ada8c7 irqchip: armada-370-xp: move IRQ handler to avoid forward declaration
If we move the IRQ handler function above the initialization function,
we avoid a forward declaration. This wasn't done as part of the
previous commit, in order to increase the readibility of the previous
commit, who was also moving the IRQ controller driver from arch/arm to
drivers/irqchip.

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-15 19:34:50 +00:00
Thomas Petazzoni 9339d432fd irqchip: move IRQ driver for Armada 370/XP
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-15 19:34:36 +00:00