1. 12 7月, 2015 1 次提交
  2. 22 3月, 2014 1 次提交
  3. 20 2月, 2014 1 次提交
    • T
      genirq: Provide irq_wake_thread() · a92444c6
      Thomas Gleixner 提交于
      In course of the sdhci/sdio discussion with Russell about killing the
      sdio kthread hackery we discovered the need to be able to wake an
      interrupt thread from software.
      
      The rationale for this is, that sdio hardware can lack proper
      interrupt support for certain features. So the driver needs to poll
      the status registers, but at the same time it needs to be woken up by
      an hardware interrupt.
      
      To be able to get rid of the home brewn kthread construct of sdio we
      need a way to wake an irq thread independent of an actual hardware
      interrupt.
      
      Provide an irq_wake_thread() function which wakes up the thread which
      is associated to a given dev_id. This allows sdio to invoke the irq
      thread from the hardware irq handler via the IRQ_WAKE_THREAD return
      value and provides a possibility to wake it via a timer for the
      polling scenarios. That allows to simplify the sdio logic
      significantly.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Chris Ball <chris@printf.net>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20140215003823.772565780@linutronix.de
      a92444c6
  4. 15 7月, 2012 1 次提交
  5. 29 3月, 2012 1 次提交
  6. 14 3月, 2012 1 次提交
    • I
      genirq: Flush the irq thread on synchronization · 7140ea19
      Ido Yariv 提交于
      The current implementation does not always flush the threaded handler
      when disabling the irq. In case the irq handler was called, but the
      threaded handler hasn't started running yet, the interrupt will be
      flagged as pending, and the handler will not run. This implementation
      has some issues:
      
      First, if the interrupt is a wake source and flagged as pending, the
      system will not be able to suspend.
      
      Second, when quickly disabling and re-enabling the irq, the threaded
      handler might continue to run after the irq is re-enabled without the
      irq handler being called first. This might be an unexpected behavior.
      
      In addition, it might be counter-intuitive that the threaded handler
      will not be called even though the irq handler was called and returned
      IRQ_WAKE_THREAD.
      
      Fix this by always waiting for the threaded handler to complete in
      synchronize_irq().
      
      [ tglx: Massaged comments, added WARN_ONs and the missing
        	IRQTF_RUNTHREAD check in exit_irq_thread() ]
      Signed-off-by: NIdo Yariv <ido@wizery.com>
      Link: http://lkml.kernel.org/r/1322843052-7166-1-git-send-email-ido@wizery.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      7140ea19
  7. 10 3月, 2012 1 次提交
  8. 03 6月, 2011 1 次提交
  9. 29 3月, 2011 1 次提交
  10. 28 3月, 2011 2 次提交
  11. 26 2月, 2011 2 次提交
    • 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
    • T
      genirq: Make warning in handle_percpu_event useful · 1204e956
      Thomas Gleixner 提交于
      The WARN_ON_ONCE in handle_percpu_event() which emits a warning when
      an action handler returns with interrupts enabled is not really
      useful. It does not reveal the interrupt number and handler function
      which caused it. Make it WARN_ONCE() and add the information.
      Reported-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      1204e956
  12. 22 2月, 2011 1 次提交
    • T
      genirq: Use the correct variable for note_interrupt · 70433c01
      Thomas Gleixner 提交于
      note_interrupt wants to be called with the combined result of all
      handlers called, not with the last one. If it's a shared interrupt
      then the last handler might return IRQ_NONE often enough to trigger
      the spurious dectector which turns off a perfectly fine working
      interrupt line. Bug was introduced in commit 1277a532(genirq: Simplify
      handle_irq_event()).
      
      Yes, I really messed up there. First the variable ret should not have
      been named differently to avoid similarity with retval. Second it
      should have been declared in the do {} loop.
      
      Rename it to res and move it into the do {} loop and vanish under a
      huge brown paperbag.
      Reported-bisected-tested-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      70433c01
  13. 19 2月, 2011 6 次提交
  14. 21 1月, 2011 1 次提交
  15. 12 10月, 2010 1 次提交
  16. 04 10月, 2010 10 次提交
  17. 13 4月, 2010 1 次提交
    • I
      genirq: Run irq handlers with interrupts disabled · e58aa3d2
      Ingo Molnar 提交于
      Running interrupt handlers with interrupts enabled can cause stack
      overflows. That has been observed with multiqueue NICs delivering all
      their interrupts to a single core. We might band aid that somehow by
      checking the interrupt stacks, but the real safe fix is to run the irq
      handlers with interrupts disabled.
      
      Drivers for whacky hardware still can reenable them in the handler
      itself, if the need arises. (They do already due to lockdep)
      
      The risk of doing this is rather low:
      
       - lockdep already enforces this
       - CONFIG_NOHZ has shaken out the drivers which relied on jiffies updates
       - time keeping is not longer sensitive to the timer interrupt being delayed
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Linus Torvalds <torvalds@osdl.org>
      LKML-Reference: <20100326000405.758579387@linutronix.de>
      e58aa3d2
  18. 18 2月, 2010 3 次提交
  19. 15 12月, 2009 1 次提交
  20. 12 10月, 2009 1 次提交
  21. 29 8月, 2009 1 次提交
  22. 12 6月, 2009 1 次提交
    • Y
      irq: slab alloc for default irq_affinity · 28be225b
      Yinghai Lu 提交于
      Ingo had
      
      [    0.000000] ------------[ cut here ]------------
      [    0.000000] WARNING: at mm/bootmem.c:537 alloc_arch_preferred_bootmem+0x2b/0x71()
      [    0.000000] Hardware name: System Product Name
      [    0.000000] Modules linked in:
      [    0.000000] Pid: 0, comm: swapper Tainted: G        W  2.6.30-tip-03087-g0bb2618-dirty #52506
      [    0.000000] Call Trace:
      [    0.000000]  [<81032588>] warn_slowpath_common+0x60/0x90
      [    0.000000]  [<810325c5>] warn_slowpath_null+0xd/0x10
      [    0.000000]  [<819d1bc0>] alloc_arch_preferred_bootmem+0x2b/0x71
      [    0.000000]  [<819d1c31>] ___alloc_bootmem_nopanic+0x2b/0x9a
      [    0.000000]  [<81050a0a>] ? lock_release+0xac/0xb2
      [    0.000000]  [<819d1d4c>] ___alloc_bootmem+0xe/0x2d
      [    0.000000]  [<819d1e9f>] __alloc_bootmem+0xa/0xc
      [    0.000000]  [<819d7c63>] alloc_bootmem_cpumask_var+0x21/0x26
      [    0.000000]  [<819d0cc8>] early_irq_init+0x15/0x10d
      [    0.000000]  [<819bb75a>] start_kernel+0x167/0x326
      [    0.000000]  [<819bb06b>] __init_begin+0x6b/0x70
      [    0.000000] ---[ end trace 4eaa2a86a8e2da23 ]---
      [    0.000000] NR_IRQS:2304 nr_irqs:424
      [    0.000000] CPU 0 irqstacks, hard=821e6000 soft=821e7000
      
      we need to update init_irq_default_affinity
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      28be225b