1. 16 Sep, 2015 1 commit
    • Thomas Gleixner's avatar
      genirq: Remove irq argument from irq flow handlers · bd0b9ac4
      Thomas Gleixner authored
      Most interrupt flow handlers do not use the irq argument. Those few
      which use it can retrieve the irq number from the irq descriptor.
      Remove the argument.
      Search and replace was done with coccinelle and some extra helper
      scripts around it. Thanks to Julia for her help!
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
  2. 13 Jul, 2015 3 commits
  3. 26 Nov, 2014 1 commit
  4. 04 Nov, 2014 1 commit
  5. 01 Nov, 2014 1 commit
    • Evgeniy Dushistov's avatar
      ARM: orion: Fix for certain sequence of request_irq can cause irq storm · 9ece8839
      Evgeniy Dushistov authored
      The problem is that hardware handled by arm/plat-orion/gpio.c,
      require ack for edge irq, and no ack for level irq.
      The code handle this issue, by two "struct irq_chip_type" per
      one "struct irq_chip_generic". For one "struct irq_chip_generic"
      irq_ack pointer is setted, for another it is NULL.
      But we have only one mask_cache per two "struct irq_chip_type".
      So if we
      1)unmask interrupt A for "edge type" trigger,
      2)unmask interrupt B for "level type" trigger,
      3)unmask interrupt C for "edge type",
      we, because of usage of generic irq_gc_mask_clr_bit/irq_gc_mask_set_bit,
      have hardware configured to trigger interrupt B on "edge type",
      because of shared mask_cache. But kernel think that B is "level type",
      so when interrupt B occur via "edge" reason, we don't ack it,
      and B triggered again and again.
      Signed-off-by: default avatarEvgeniy A. Dushistov <dushistov@mail.ru>
      Link: https://lkml.kernel.org/r/20140726155659.GA22977@fifteenSigned-off-by: default avatarJason Cooper <jason@lakedaemon.net>
  6. 26 Apr, 2014 1 commit
  7. 25 Jun, 2013 1 commit
  8. 16 Apr, 2013 1 commit
  9. 30 Mar, 2013 1 commit
  10. 14 Sep, 2012 1 commit
  11. 27 Jul, 2012 1 commit
  12. 15 May, 2012 2 commits
  13. 20 Dec, 2011 1 commit
  14. 07 Jul, 2011 1 commit
    • Simon Guinot's avatar
      genirq: replace irq_gc_ack() with {set,clr}_bit variants (fwd) · 659fb32d
      Simon Guinot authored
      This fixes a regression introduced by e59347a1 "arm: orion:
      Use generic irq chip".
      Depending on the device, interrupts acknowledgement is done by setting
      or by clearing a dedicated register. Replace irq_gc_ack() with some
      {set,clr}_bit variants allows to handle both cases.
      Note that this patch affects the following SoCs: Davinci, Samsung and
      Orion. Except for this last, the change is minor: irq_gc_ack() is just
      renamed into irq_gc_ack_set_bit().
      For the Orion SoCs, the edge GPIO interrupts support is currently
      broken. irq_gc_ack() try to acknowledge a such interrupt by setting
      the corresponding cause register bit. The Orion GPIO device expect the
      opposite. To fix this issue, the irq_gc_ack_clr_bit() variant is used.
      Tested on Network Space v2.
      Reported-by: default avatarJoey Oravec <joravec@drewtech.com>
      Signed-off-by: default avatarSimon Guinot <sguinot@lacie.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
  15. 16 May, 2011 1 commit
  16. 29 Mar, 2011 3 commits
  17. 03 Mar, 2011 1 commit
  18. 13 Jan, 2011 1 commit
  19. 08 Jun, 2009 1 commit
  20. 20 Feb, 2009 1 commit
  21. 17 Feb, 2009 1 commit
    • Nicolas Pitre's avatar
      [ARM] 5401/1: Orion: fix edge triggered GPIO interrupt support · fd4b9b36
      Nicolas Pitre authored
      The GPIO interrupts can be configured as either level triggered or edge
      triggered, with a default of level triggered.  When an edge triggered
      interrupt is requested, the gpio_irq_set_type method is called which
      currently switches the given IRQ descriptor between two struct irq_chip
      instances: orion_gpio_irq_level_chip and orion_gpio_irq_edge_chip. This
      happens via __setup_irq() which also calls irq_chip_set_defaults() to
      assign default methods to uninitialized ones.  The problem is that
      irq_chip_set_defaults() is called before the irq_chip reference is
      switched, leaving the new irq_chip (orion_gpio_irq_edge_chip in this
      case) with uninitialized methods such as chip->startup() causing a kernel
      Many solutions are possible, such as making irq_chip_set_defaults() global
      and calling it from gpio_irq_set_type(), or calling __irq_set_trigger()
      before irq_chip_set_defaults() in __setup_irq().  But those require
      modifications to the generic IRQ code which might have adverse effect on
      other architectures, and that would still be a fragile arrangement.
      Manually copying the missing methods from within gpio_irq_set_type()
      would be really ugly and it would break again the day new methods with
      automatic defaults are added.
      A better solution is to have a single irq_chip instance which can deal
      with both edge and level triggered interrupts.  It is also a good idea
      to switch the IRQ handler instead, as the edge IRQ handler allows for
      one edge IRQ event to be queued as the IRQ is actually masked only when
      that second IRQ is received, at which point the hardware can queue an
      additional IRQ event, making edge triggered interrupts a bit more
      Tested-by: Martin Michlmayr's avatarMartin Michlmayr <tbm@cyrius.com>
      Signed-off-by: default avatarNicolas Pitre <nico@marvell.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  22. 20 Dec, 2008 2 commits