1. 28 Jul, 2014 2 commits
  2. 09 Jul, 2014 1 commit
  3. 07 Jun, 2014 2 commits
  4. 07 Mar, 2014 1 commit
  5. 20 Feb, 2014 1 commit
    • Lior Amsalem's avatar
      irqchip: armada-370-xp: fix IPI race condition · 86f06cac
      Lior Amsalem authored
      commit a6f089e95b1e08cdea9633d50ad20aa5d44ba64d upstream.
      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
      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: default avatarLior Amsalem <alior@marvell.com>
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Fixes: 344e873e 'arm: mvebu: Add IPI support via doorbells'
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. 15 Jan, 2014 1 commit
  7. 20 Jun, 2013 1 commit
    • Shawn Guo's avatar
      irqchip: gic: call gic_cpu_init() as well in CPU_STARTING_FROZEN case · 8b6fd652
      Shawn Guo authored
      Commit c0114709 (irqchip: gic: Perform the gic_secondary_init() call via
      CPU notifier) moves gic_secondary_init() that used to be called in
      .smp_secondary_init hook into a notifier call.  But it changes the
      system behavior a little bit.  Before the commit, gic_cpu_init()
      is called not only when kernel brings up the secondary cores but also
      when system resuming procedure hot-plugs the cores back to kernel.
      While after the commit, the function will not be called in the latter
      case, where the 'action' will not be CPU_STARTING but
      CPU_STARTING_FROZEN.  This behavior difference at least causes the
      following suspend/resume regression on imx6q.
      $ echo mem > /sys/power/state
      PM: Syncing filesystems ... done.
      PM: Preparing system for mem sleep
      mmc1: card e624 removed
      Freezing user space processes ... (elapsed 0.01 seconds) done.
      Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
      PM: Entering mem sleep
      PM: suspend of devices complete after 5.930 msecs
      PM: suspend devices took 0.010 seconds
      PM: late suspend of devices complete after 0.343 msecs
      PM: noirq suspend of devices complete after 0.828 msecs
      Disabling non-boot CPUs ...
      CPU1: shutdown
      CPU2: shutdown
      CPU3: shutdown
      Enabling non-boot CPUs ...
      CPU1: Booted secondary processor
      INFO: rcu_sched detected stalls on CPUs/tasks: { 1 2 3} (detected by 0, t=2102 jiffies, g=4294967169, c=4294967168, q=17)
      Task dump for CPU 1:
      swapper/1       R running      0     0      1 0x00000000
      [<bf895ff4>] (0xbf895ff4) from [<00000000>] (  (null))
      Backtrace aborted due to bad frame pointer <8007ccdc>
      Task dump for CPU 2:
      swapper/2       R running      0     0      1 0x00000000
      [<8075dbdc>] (0x8075dbdc) from [<00000000>] (  (null))
      Backtrace aborted due to bad frame pointer <00000002>
      Task dump for CPU 3:
      swapper/3       R running      0     0      1 0x00000000
      [<8075dbdc>] (0x8075dbdc) from [<00000000>] (  (null))
      Fix the regression by checking 'action' being CPU_STARTING_FROZEN to
      have gic_cpu_init() called for secondary cores when system resumes.
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: default avatarJoseph Lo <josephl@nvidia.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
  8. 08 Jun, 2013 1 commit
    • Grant Likely's avatar
      irqchip: Return -EPERM for reserved IRQs · d94ea3f6
      Grant Likely authored
      The irqdomain core will report a log message for any attempted map call
      that fails unless the error code is -EPERM. This patch changes the
      Versatile irq controller drivers to use -EPERM because it is normal for
      a subset of the IRQ inputs to be marked as reserved on the various
      Versatile platforms.
      Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
  9. 03 Jun, 2013 1 commit
  10. 29 Apr, 2013 1 commit
    • Arnd Bergmann's avatar
      irqchip: s3c24xx: add missing __init annotations · bc8fd900
      Arnd Bergmann authored
      The s3c24xx_init_intc and s3c2412_init_irq functions are only called
      at init time, and they call functions already marked __init, so they
      should be marked in the same way. This was reported as
      WARNING: vmlinux.o(.text+0x19e0b4): Section mismatch in reference from the function s3c2412_init_irq() to the function .init.text:s3c24xx_init_intc.constprop.8()
      The function s3c2412_init_irq() references
      the function __init s3c24xx_init_intc.constprop.8().
      This is often because s3c2412_init_irq lacks a __init
      annotation or the annotation of s3c24xx_init_intc.constprop.8 is wrong.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
  11. 19 Apr, 2013 5 commits
    • Arnd Bergmann's avatar
      irqchip: exynos: look up irq using irq_find_mapping · 20adee8f
      Arnd Bergmann authored
      Since we want to move to using the linear IRQ domain in the
      future, we cannot rely on the irq numbers to be contiguous
      and need to look up the irq from the hwirq using the domain.
      This also turns the bogus comparison with NR_IRQ into a
      more meaningful check to see if the number has a valid mapping.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
    • Arnd Bergmann's avatar
      irqchip: exynos: pass irq_base from platform · 863a08dc
      Arnd Bergmann authored
      The platform code knows the IRQ base, while the irqchip driver
      should really not. This is a littly hacky because we still
      hardwire the IRQ base to 160 for the combiner in the DT case,
      when we should really use -1. Removing that line will cause
      a linear IRQ domain to be use, as we should.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
    • Arnd Bergmann's avatar
      irqchip: exynos: localize irq lookup for ATAGS · 92c8e496
      Arnd Bergmann authored
      The IRQ_SPI() macro is not available in the driver when building with sparse
      IRQs or multiplatform, so let's move all users of this into one function
      that we can leave out when building DT-only.
      Signed-off-by: default avatarArnd Bergmann <arnd@arnd.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
    • Arnd Bergmann's avatar
      irqchip: exynos: allocate combiner_data dynamically · d34f03d4
      Arnd Bergmann authored
      The number of combiners on a given SoC is a platform specific
      constant, and we cannot encode this number on a multiplatform
      kernel since the header file defining it is not available.
      Allocating the structure dynamically ends up cleaner anyway
      since we keep all the data local.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
    • Arnd Bergmann's avatar
      irqchip: exynos: pass max combiner number to combiner_init · 6761dcfe
      Arnd Bergmann authored
      We can find out the number of combined IRQs from the device
      tree, but in case of ATAGS boot, the driver currently uses
      hardcoded values based on the SoC type. We can't do that
      in general for a multiplatform kernel, so let's instead pass
      this information from platform code directly in case of
      ATAGS boot.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
  12. 15 Apr, 2013 3 commits
  13. 13 Apr, 2013 1 commit
  14. 08 Apr, 2013 4 commits
  15. 04 Apr, 2013 7 commits
  16. 02 Apr, 2013 2 commits
  17. 01 Apr, 2013 1 commit
  18. 28 Mar, 2013 1 commit
    • Bastian Hecht's avatar
      irqchip: intc-irqpin: Add support for shared interrupt lines · 427cc720
      Bastian Hecht authored
      On some hardware we don't have a 1-1 mapping from the external
      interrupts coming from INTC to the GIC SPI pins. We can however
      share lines to demux incoming IRQs on these SoCs.
      This patch enables the intc_irqpin driver to detect requests for shared
      interrupt lines and demuxes them properly by querying the INTC INTREQx0A
      If you need multiple shared intc_irqpin device instances, be sure to mask
      out all interrupts on the INTC that share the one line before you start
      to register them. Else you run into IRQ floods that would be caused by
      interrupts for which no handler has been set up yet when the first
      intc_irqpin device is registered.
      Signed-off-by: default avatarBastian Hecht <hechtb+renesas@gmail.com>
      Acked-by: default avatarMagnus Damm <damm@opensource.se>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
  19. 27 Mar, 2013 1 commit
  20. 26 Mar, 2013 3 commits