1. 12 9月, 2011 1 次提交
  2. 24 8月, 2011 1 次提交
    • L
      Revert "irq: Always set IRQF_ONESHOT if no primary handler is specified" · 69dd3d8e
      Linus Torvalds 提交于
      This reverts commit f3637a5f.
      
      It turns out that this breaks several drivers, one example being OMAP
      boards which use the on-board OMAP UARTs and the omap-serial driver that
      will not boot to userspace after the commit.
      
      Paul Walmsley reports that enabling CONFIG_DEBUG_SHIRQ reveals 'IRQ
      handler type mismatch' errors:
      
        IRQ handler type mismatch for IRQ 74
        current handler: serial idle
        ...
      
      and the reason is that setting IRQF_ONESHOT will now result in those
      interrupt handlers having different IRQF flags, and thus being
      unsharable.  So the commit log in the reverted commit:
      
                                  "Since it is required for those users and
          there is no difference for others it makes sense to add this flag
          unconditionally."
      
      is simply not true: there may not be any difference from a "actions at
      irq time", but there is a *big* difference wrt this flag testing irq
      management (see __setup_irq() in kernel/irq/manage.c).
      
      One solution may be to stop verifying IRQF_ONESHOT in __setup_irq(), but
      right now the safe course of action is to revert the change.  Let's
      revisit this in a later merge window.
      Reported-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Requested-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      69dd3d8e
  3. 28 7月, 2011 2 次提交
  4. 10 6月, 2011 1 次提交
  5. 03 6月, 2011 1 次提交
  6. 23 4月, 2011 1 次提交
  7. 03 4月, 2011 1 次提交
  8. 29 3月, 2011 4 次提交
  9. 28 3月, 2011 1 次提交
  10. 27 3月, 2011 1 次提交
    • D
      genirq: Split irq_set_affinity() so it can be called with lock held. · c2d0c555
      David Daney 提交于
      The .irq_cpu_online() and .irq_cpu_offline() functions may need to
      adjust affinity, but they are called with the descriptor lock held.
      Create __irq_set_affinity_locked() which is called with the lock held.
      Make irq_set_affinity() just a wrapper that acquires the lock.
      
      [ tglx: Changed the argument to irq_data, added a !desc check and
              moved the !irq_set_affinity check where it belongs ]
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      Cc: linux-mips@linux-mips.org
      Cc: ralf@linux-mips.org
      LKML-Reference: <1301081931-11240-4-git-send-email-ddaney@caviumnetworks.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      c2d0c555
  11. 17 3月, 2011 1 次提交
  12. 26 2月, 2011 3 次提交
    • T
      genirq: Provide forced interrupt threading · 8d32a307
      Thomas Gleixner 提交于
      Add a commandline parameter "threadirqs" which forces all interrupts except
      those marked IRQF_NO_THREAD to run threaded. That's mostly a debug option to
      allow retrieving better debug data from crashing interrupt handlers. If
      "threadirqs" is not enabled on the kernel command line, then there is no
      impact in the interrupt hotpath.
      
      Architecture code needs to select CONFIG_IRQ_FORCED_THREADING after
      marking the interrupts which cant be threaded IRQF_NO_THREAD. All
      interrupts which have IRQF_TIMER set are implict marked
      IRQF_NO_THREAD. Also all PER_CPU interrupts are excluded.
      
      Forced threading hard interrupts also forces all soft interrupt
      handling into thread context.
      
      When enabled it might slow down things a bit, but for debugging problems in
      interrupt code it's a reasonable penalty as it does not immediately
      crash and burn the machine when an interrupt handler is buggy.
      
      Some test results on a Core2Duo machine:
      
      Cache cold run of:
       # time git grep irq_desc
      
            non-threaded       threaded
       real 1m18.741s          1m19.061s
       user 0m1.874s           0m1.757s
       sys  0m5.843s           0m5.427s
      
       # iperf -c server
      non-threaded
      [  3]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   934 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
      threaded
      [  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   934 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   937 Mbits/sec
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20110223234956.772668648@linutronix.de>
      8d32a307
    • T
      genirq: Allow shared oneshot interrupts · 9d591edd
      Thomas Gleixner 提交于
      Support ONESHOT on shared interrupts, if all drivers agree on it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20110223234956.483640430@linutronix.de>
      9d591edd
    • T
      genirq: Prepare the handling of shared oneshot interrupts · b5faba21
      Thomas Gleixner 提交于
      For level type interrupts we need to track how many threads are on
      flight to avoid useless interrupt storms when not all thread handlers
      have finished yet. Keep track of the woken threads and only unmask
      when there are no more threads in flight.
      
      Yes, I'm lazy and using a bitfield. But not only because I'm lazy, the
      main reason is that it's way simpler than using a refcount. A refcount
      based solution would need to keep track of various things like
      crashing the irq thread, spurious interrupts coming in,
      disables/enables, free_irq() and some more. The bitfield keeps the
      tracking simple and makes things just work. It's also nicely confined
      to the thread code pathes and does not require additional checks all
      over the place.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20110223234956.388095876@linutronix.de>
      b5faba21
  13. 22 2月, 2011 1 次提交
  14. 19 2月, 2011 21 次提交