1. 19 2月, 2011 21 次提交
  2. 11 2月, 2011 1 次提交
    • D
      genirq: Call bus_lock/unlock functions in setup_irq() · 986c011d
      David Daney 提交于
      irq_chips that supply .irq_bus_lock/.irq_bus_sync_unlock functions,
      expect that the other chip methods will be called inside of calls to
      the pair.  If this expectation is not met, things tend to not work.
      
      Make setup_irq() call chip_bus_lock()/chip_bus_sync_unlock() too.
      
      For the vast majority of irq_chips, this will be a NOP as most don't
      have these bus lock functions.
      
      [ tglx: No we don't want to call that in __setup_irq(). Way too many
        	error exit pathes. ]
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      LKML-Reference: <1297296265-18680-1-git-send-email-ddaney@caviumnetworks.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      986c011d
  3. 08 2月, 2011 1 次提交
  4. 31 1月, 2011 1 次提交
  5. 23 1月, 2011 1 次提交
    • B
      genirq: Add IRQ affinity notifiers · cd7eab44
      Ben Hutchings 提交于
      When initiating I/O on a multiqueue and multi-IRQ device, we may want
      to select a queue for which the response will be handled on the same
      or a nearby CPU.  This requires a reverse-map of IRQ affinity.  Add a
      notification mechanism to support this.
      
      This is based closely on work by Thomas Gleixner <tglx@linutronix.de>.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Cc: linux-net-drivers@solarflare.com
      Cc: Tom Herbert <therbert@google.com>
      Cc: David Miller <davem@davemloft.net>
      LKML-Reference: <1295470904.11126.84.camel@bwh-desktop>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      cd7eab44
  6. 07 1月, 2011 1 次提交
  7. 23 10月, 2010 1 次提交
  8. 22 10月, 2010 1 次提交
  9. 04 10月, 2010 8 次提交
  10. 29 7月, 2010 1 次提交
    • I
      irq: Add new IRQ flag IRQF_NO_SUSPEND · 685fd0b4
      Ian Campbell 提交于
      A small number of users of IRQF_TIMER are using it for the implied no
      suspend behaviour on interrupts which are not timer interrupts.
      
      Therefore add a new IRQF_NO_SUSPEND flag, rename IRQF_TIMER to
      __IRQF_TIMER and redefine IRQF_TIMER in terms of these new flags.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: xen-devel@lists.xensource.com
      Cc: linux-input@vger.kernel.org
      Cc: linuxppc-dev@ozlabs.org
      Cc: devicetree-discuss@lists.ozlabs.org
      LKML-Reference: <1280398595-29708-1-git-send-email-ian.campbell@citrix.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      685fd0b4
  11. 09 6月, 2010 1 次提交
    • T
      genirq: Deal with desc->set_type() changing desc->chip · 46732475
      Thomas Gleixner 提交于
      The set_type() function can change the chip implementation when the
      trigger mode changes. That might result in using an non-initialized
      irq chip when called from __setup_irq() or when called via
      set_irq_type() on an already enabled irq. 
      
      The set_irq_type() function should not be called on an enabled irq,
      but because we forgot to put a check into it, we have a bunch of users
      which grew the habit of doing that and it never blew up as the
      function is serialized via desc->lock against all users of desc->chip
      and they never hit the non-initialized irq chip issue.
      
      The easy fix for the __setup_irq() issue would be to move the
      irq_chip_set_defaults(desc->chip) call after the trigger setting to
      make sure that a chip change is covered.
      
      But as we have already users, which do the type setting after
      request_irq(), the safe fix for now is to call irq_chip_set_defaults()
      from __irq_set_trigger() when desc->set_type() changed the irq chip.
      
      It needs a deeper analysis whether we should refuse to change the chip
      on an already enabled irq, but that'd be a large scale change to fix
      all the existing users. So that's neither stable nor 2.6.35 material.
      Reported-by: NEsben Haabendal <eha@doredevelopment.dk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
      Cc: stable@kernel.org
      46732475
  12. 03 5月, 2010 1 次提交
    • P
      genirq: Add CPU mask affinity hint · e7a297b0
      Peter P Waskiewicz Jr 提交于
      This patch adds a cpumask affinity hint to the irq_desc structure,
      along with a registration function and a read-only proc entry for each
      interrupt.
      
      This affinity_hint handle for each interrupt can be used by underlying
      drivers that need a better mechanism to control interrupt affinity.
      The underlying driver can register a cpumask for the interrupt, which
      will allow the driver to provide the CPU mask for the interrupt to
      anything that requests it.  The intent is to extend the userspace
      daemon, irqbalance, to help hint to it a preferred CPU mask to balance
      the interrupt into.
      
      [ tglx: Fixed compile warnings, added WARN_ON, made SMP only ]
      Signed-off-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
      Cc: davem@davemloft.net
      Cc: arjan@linux.jf.intel.com
      Cc: bhutchings@solarflare.com
      LKML-Reference: <20100430214445.3992.41647.stgit@ppwaskie-hc2.jf.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      e7a297b0
  13. 13 4月, 2010 1 次提交
    • T
      genirq: Remove IRQF_DISABLED from core code · 6932bf37
      Thomas Gleixner 提交于
      Remove all code which is related to IRQF_DISABLED from the core kernel
      code. IRQF_DISABLED still exists as a flag, but becomes a NOOP and
      will be removed after a grace period. That way we can easily revert to
      the previous behaviour by just restoring the core code.
      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.991244690@linutronix.de>
      6932bf37