1. 19 2月, 2011 6 次提交
    • T
      genirq: Consolidate disable/enable · 87923470
      Thomas Gleixner 提交于
      Create irq_disable/enable and use them to keep the flags consistent.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      87923470
    • T
      genirq: Consolidate startup/shutdown of interrupts · 46999238
      Thomas Gleixner 提交于
      Aside of duplicated code some of the startup/shutdown sites do not
      handle the MASKED/DISABLED flags and the depth field at all. Move that
      to a helper function and take care of it there.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20110202212551.787481468@linutronix.de>
      46999238
    • T
      genirq: Move irq thread flags to core · 1535dfac
      Thomas Gleixner 提交于
      Soleley used in core code.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      1535dfac
    • T
      genirq: Mark polled irqs and defer the real handler · fe200ae4
      Thomas Gleixner 提交于
      With the chip.end() function gone we might run into a situation where
      a poll call runs and the real interrupt comes in, sees IRQ_INPROGRESS
      and disables the line. That might be a perfect working one, which will
      then be masked forever.
      
      So mark them polled while the poll runs. When the real handler sees
      IRQ_INPROGRESS it checks the poll flag and waits for the polling to
      complete. Add the necessary amount of sanity checks to it to avoid
      deadlocks.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      fe200ae4
    • T
      genirq: Do not copy affinity before set · 3b8249e7
      Thomas Gleixner 提交于
      While rumaging through arch code I found that there are a few
      workarounds which deal with the fact that the initial affinity setting
      from request_irq() copies the mask into irq_data->affinity before the
      chip code is called. In the normal path we unconditionally copy the
      mask when the chip code returns 0.
      
      Copy after the code is called and add a return code
      IRQ_SET_MASK_OK_NOCOPY for the chip functions, which prevents the
      copy. That way we see the real mask when the chip function decided to
      truncate it further as some arches do. IRQ_SET_MASK_OK is 0, which is
      the current behaviour.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      3b8249e7
    • T
      genirq: Prevent access beyond allocated_irqs bitmap · c1ee6264
      Thomas Gleixner 提交于
      Lars-Peter Clausen pointed out:
      
         I stumbled upon this while looking through the existing archs using
         SPARSE_IRQ.  Even with SPARSE_IRQ the NR_IRQS is still the upper
         limit for the number of IRQs.
      
         Both PXA and MMP set NR_IRQS to IRQ_BOARD_START, with
         IRQ_BOARD_START being the number of IRQs used by the core.
      
         In various machine files the nr_irqs field of the ARM machine
         defintion struct is then set to "IRQ_BOARD_START + NR_BOARD_IRQS".
      
         As a result "nr_irqs" will greater then NR_IRQS which then again
         causes the "allocated_irqs" bitmap in the core irq code to be
         accessed beyond its size overwriting unrelated data.
      
      The core code really misses a sanity check there.
      
      This went unnoticed so far as by chance the compiler/linker places
      data behind that bitmap which gets initialized later on those affected
      platforms.
      
      So the obvious fix would be to add a sanity check in early_irq_init()
      and break all affected platforms. Though that check wants to be
      backported to stable as well, which will require to fix all known
      problematic platforms and probably some more yet not known ones as
      well. Lots of churn.
      
      A way simpler solution is to allocate a slightly larger bitmap and
      avoid the whole churn w/o breaking anything. Add a few warnings when
      an arch returns utter crap.
      Reported-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@kernel.org # .37
      Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      c1ee6264
  2. 12 10月, 2010 4 次提交
  3. 04 10月, 2010 4 次提交
  4. 18 2月, 2010 1 次提交
  5. 15 12月, 2009 1 次提交
  6. 17 8月, 2009 1 次提交
    • T
      genirq: Add buslock support · 70aedd24
      Thomas Gleixner 提交于
      Some interrupt chips are connected to a "slow" bus (i2c, spi ...). The
      bus access needs to sleep and therefor cannot be called in atomic
      contexts.
      
      Some of the generic interrupt management functions like disable_irq(),
      enable_irq() ... call interrupt chip functions with the irq_desc->lock
      held and interrupts disabled. This does not work for such devices.
      
      Provide a separate synchronization mechanism for such interrupt
      chips. The irq_chip structure is extended by two optional functions
      (bus_lock and bus_sync_and_unlock).
      
      The idea is to serialize the bus access for those operations in the
      core code so that drivers which are behind that bus operated interrupt
      controller do not have to worry about it and just can use the normal
      interfaces. To achieve this we add two function pointers to the
      irq_chip: bus_lock and bus_sync_unlock.
      
      bus_lock() is called to serialize access to the interrupt controller
      bus.
      
      Now the core code can issue chip->mask/unmask ... commands without
      changing the fast path code at all. The chip implementation merily
      stores that information in a chip private data structure and
      returns. No bus interaction as these functions are called from atomic
      context.
      
      After that bus_sync_unlock() is called outside the atomic context. Now
      the chip implementation issues the bus commands, waits for completion
      and unlocks the interrupt controller bus.
      
      The irq_chip implementation as pseudo code:
      
      struct irq_chip_data {
             struct mutex   mutex;
             unsigned int   irq_offset;
             unsigned long  mask;
             unsigned long  mask_status;
      }
      
      static void bus_lock(unsigned int irq)
      {
              struct irq_chip_data *data = get_irq_desc_chip_data(irq);
      
              mutex_lock(&data->mutex);
      }
      
      static void mask(unsigned int irq)
      {
              struct irq_chip_data *data = get_irq_desc_chip_data(irq);
      
              irq -= data->irq_offset;
              data->mask |= (1 << irq);
      }
      
      static void unmask(unsigned int irq)
      {
              struct irq_chip_data *data = get_irq_desc_chip_data(irq);
      
              irq -= data->irq_offset;
              data->mask &= ~(1 << irq);
      }
      
      static void bus_sync_unlock(unsigned int irq)
      {
              struct irq_chip_data *data = get_irq_desc_chip_data(irq);
      
              if (data->mask != data->mask_status) {
                      do_bus_magic_to_set_mask(data->mask);
                      data->mask_status = data->mask;
              }
              mutex_unlock(&data->mutex);
      }
      
      The device drivers can use request_threaded_irq, free_irq, disable_irq
      and enable_irq as usual with the only restriction that the calls need
      to come from non atomic context.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Trilok Soni <soni.trilok@gmail.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Joonyoung Shim <jy0922.shim@samsung.com>
      Cc: m.szyprowski@samsung.com
      Cc: t.fujak@samsung.com
      Cc: kyungmin.park@samsung.com,
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Daniel Ribeiro <drwyrm@gmail.com>
      Cc: arve@android.com
      Cc: Barry Song <21cnbao@gmail.com>
      70aedd24
  7. 21 7月, 2009 1 次提交
    • T
      genirq: Delegate irq affinity setting to the irq thread · 591d2fb0
      Thomas Gleixner 提交于
      irq_set_thread_affinity() calls set_cpus_allowed_ptr() which might
      sleep, but irq_set_thread_affinity() is called with desc->lock held
      and can be called from hard interrupt context as well. The code has
      another bug as it does not hold a ref on the task struct as required
      by set_cpus_allowed_ptr().
      
      Just set the IRQTF_AFFINITY bit in action->thread_flags. The next time
      the thread runs it migrates itself. Solves all of the above problems
      nicely.
      
      Add kerneldoc to irq_set_thread_affinity() while at it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <new-submission>
      591d2fb0
  8. 28 4月, 2009 2 次提交
    • Y
      x86/irq: change irq_desc_alloc() to take node instead of cpu · 85ac16d0
      Yinghai Lu 提交于
      This simplifies the node awareness of the code. All our allocators
      only deal with a NUMA node ID locality not with CPU ids anyway - so
      there's no need to maintain (and transform) a CPU id all across the
      IRq layer.
      
      v2: keep move_irq_desc related
      
      [ Impact: cleanup, prepare IRQ code to be NUMA-aware ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      LKML-Reference: <49F65536.2020300@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      85ac16d0
    • Y
      irq: only update affinity if ->set_affinity() is sucessfull · 57b150cc
      Yinghai Lu 提交于
      irq_set_affinity() and move_masked_irq() try to assign affinity
      before calling chip set_affinity(). Some archs are assigning it
      in ->set_affinity() again.
      
      We do something like:
      
       cpumask_cpy(desc->affinity, mask);
       desc->chip->set_affinity(mask);
      
      But in the failure path, affinity should not be touched - otherwise
      we'll end up with a different affinity mask despite the failure to
      migrate the IRQ.
      
      So try to update the afffinity only if set_affinity returns with 0.
      Also call irq_set_thread_affinity accordingly.
      
      v2: update after "irq, x86: Remove IRQ_DISABLED check in process context IRQ move"
      v3: according to Ingo, change set_affinity() in irq_chip should return int.
      v4: update comments by removing moving irq_desc code.
      
      [ Impact: fix /proc/irq/*/smp_affinity setting corner case bug ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      LKML-Reference: <49F65509.60307@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      57b150cc
  9. 31 3月, 2009 1 次提交
    • R
      PM: Introduce functions for suspending and resuming device interrupts · 0a0c5168
      Rafael J. Wysocki 提交于
      Introduce helper functions allowing us to prevent device drivers from
      getting any interrupts (without disabling interrupts on the CPU)
      during suspend (or hibernation) and to make them start to receive
      interrupts again during the subsequent resume.  These functions make it
      possible to keep timer interrupts enabled while the "late" suspend and
      "early" resume callbacks provided by device drivers are being
      executed.  In turn, this allows device drivers' "late" suspend and
      "early" resume callbacks to sleep, execute ACPI callbacks etc.
      
      The functions introduced here will be used to rework the handling of
      interrupts during suspend (hibernation) and resume.  Namely,
      interrupts will only be disabled on the CPU right before suspending
      sysdevs, while device drivers will be prevented from receiving
      interrupts, with the help of the new helper function, before their
      "late" suspend callbacks run (and analogously during resume).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      0a0c5168
  10. 09 2月, 2009 1 次提交
    • Y
      irq: clear kstat_irqs · 0f3c2a89
      Yinghai Lu 提交于
      Impact: get correct kstat_irqs [/proc/interrupts] for msi/msi-x etc
      
      need to call clear_kstat_irqs(), so when we reuse that irq_desc,
      we get correct kstat in /proc/interrupts.
      
      This makes /proc/interrupts not have <NULL> entries.
      
      Don't need to worry about arch that doesn't support genirq, because they
      will not call dynamic_irq_cleanup().
      
      v2: simplify and make clear_kstat_irqs more robust
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0f3c2a89
  11. 12 1月, 2009 1 次提交
    • M
      irq: allocate irq_desc_ptrs array based on nr_irqs · 0fa0ebbf
      Mike Travis 提交于
      Impact: allocate irq_desc_ptrs in preparation for making it variable-sized.
      
      This addresses this memory usage bump when NR_CPUS bumped from 128 to 4096:
      
          34816   +229376    264192  +658%  irq_desc_ptrs(.data.read_mostly)
      
      The patch is split into two parts, the first simply allocates the
      irq_desc_ptrs array.  Then next will deal with making it variable.
      This is only when CONFIG_SPARSE_IRQS=y.
      Signed-off-by: NMike Travis <travis@sgi.com>
      0fa0ebbf
  12. 17 12月, 2008 1 次提交
    • Y
      x86, sparseirq: move irq_desc according to smp_affinity, v7 · 48a1b10a
      Yinghai Lu 提交于
      Impact: improve NUMA handling by migrating irq_desc on smp_affinity changes
      
      if CONFIG_NUMA_MIGRATE_IRQ_DESC is set:
      
      -  make irq_desc to go with affinity aka irq_desc moving etc
      -  call move_irq_desc in irq_complete_move()
      -  legacy irq_desc is not moved, because they are allocated via static array
      
      for logical apic mode, need to add move_desc_in_progress_in_same_domain,
      otherwise it will not be moved ==> also could need two phases to get
      irq_desc moved.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      48a1b10a
  13. 10 11月, 2008 1 次提交
  14. 16 10月, 2008 1 次提交
  15. 02 10月, 2008 1 次提交
    • D
      genirq: record trigger type · 0c5d1eb7
      David Brownell 提交于
      Genirq hasn't previously recorded the trigger type used by any given IRQ,
      although some irq_chip support has done so.  That data can be useful when
      troubleshooting.  This patch records it in the relevant irq_desc.status
      bits, and improves consistency between the two driver-visible calls
      affected:
      
       - Make set_irq_type() usage match request_irq() usage:
          * IRQ_TYPE_NONE should be a NOP; succeed, so irq_chip methods
            won't have to handle that case any more (many do it wrong).
          * IRQ_TYPE_PROBE is ignored; any buggy out-of-tree callers
            might need to switch over to the real IRQ probing code.
          * emit the same diagnostics (from shared utility code)
      
       - Their kerneldoc now reflects usage:
          * request_irq() flags include IRQF_TRIGGER_* to specify
            active edge(s)/level ... docs previously omitted that
          * set_irq_type() is declared in <linux/irq.h> so callers
            should use the (bit-equivalent) IRQ_TYPE_* symbols there
      
      Also: adds a warning about shared IRQs that don't end up using the
      requested trigger mode; and fix an unrelated "sparse" warning.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0c5d1eb7
  16. 30 6月, 2006 2 次提交
  17. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4