1. 07 1月, 2011 1 次提交
  2. 24 12月, 2010 1 次提交
    • E
      ARM: 6532/1: Allow machine to specify it's own IRQ handlers at run-time · 52108641
      eric miao 提交于
      Normally different ARM platform has different way to decode the IRQ
      hardware status and demultiplex to the corresponding IRQ handler.
      This is highly optimized by macro irq_handler in entry-armv.S, and
      each machine defines their own macro to decode the IRQ number.
      However, this prevents multiple machine classes to be built into a
      single kernel.
      
      By allowing each machine to specify thier own handler, and making
      function pointer 'handle_arch_irq' to point to it at run time, this
      can be solved. And introduce CONFIG_MULTI_IRQ_HANDLER to allow both
      solutions to work.
      
      Comparing with the highly optimized macro of irq_handler, the new
      function must be written with care not to lose too much performance.
      And the IPI stuff on SMP is expected to move to the provided arch
      IRQ handler as well.
      
      The assembly code to invoke handle_arch_irq is optimized by Russell
      King.
      Signed-off-by: NEric Miao <eric.miao@canonical.com>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      52108641
  3. 06 12月, 2010 1 次提交
  4. 05 12月, 2010 1 次提交
  5. 26 11月, 2010 1 次提交
  6. 25 10月, 2010 2 次提交
  7. 22 10月, 2010 2 次提交
  8. 21 10月, 2010 4 次提交
  9. 19 10月, 2010 1 次提交
    • P
      irq_work: Add generic hardirq context callbacks · e360adbe
      Peter Zijlstra 提交于
      Provide a mechanism that allows running code in IRQ context. It is
      most useful for NMI code that needs to interact with the rest of the
      system -- like wakeup a task to drain buffers.
      
      Perf currently has such a mechanism, so extract that and provide it as
      a generic feature, independent of perf so that others may also
      benefit.
      
      The IRQ context callback is generated through self-IPIs where
      possible, or on architectures like powerpc the decrementer (the
      built-in timer facility) is set to generate an interrupt immediately.
      
      Architectures that don't have anything like this get to do with a
      callback from the timer tick. These architectures can call
      irq_work_run() at the tail of any IRQ handlers that might enqueue such
      work (like the perf IRQ handler) to avoid undue latencies in
      processing the work.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      [ various fixes ]
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      LKML-Reference: <1287036094.7768.291.camel@yhuang-dev>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e360adbe
  10. 18 10月, 2010 2 次提交
  11. 09 10月, 2010 1 次提交
  12. 08 10月, 2010 2 次提交
  13. 05 10月, 2010 4 次提交
  14. 02 10月, 2010 1 次提交
  15. 28 9月, 2010 1 次提交
  16. 20 9月, 2010 1 次提交
  17. 19 9月, 2010 1 次提交
  18. 18 9月, 2010 1 次提交
  19. 17 9月, 2010 2 次提交
  20. 10 9月, 2010 1 次提交
  21. 08 9月, 2010 1 次提交
  22. 02 9月, 2010 2 次提交
  23. 27 8月, 2010 1 次提交
  24. 11 8月, 2010 2 次提交
  25. 06 8月, 2010 3 次提交