1. 17 7月, 2015 1 次提交
  2. 12 7月, 2015 1 次提交
  3. 25 6月, 2015 1 次提交
  4. 18 6月, 2015 1 次提交
    • R
      irq: Add irq_set_chained_handler_and_data() · 3b0f95be
      Russell King 提交于
      Driver authors seem to get the ordering of irq_set_chained_handler()
      and irq_set_handler_data() wrong - ordering the former before the
      latter.  This opens a race window where, if there is an interrupt
      pending, the handler will be called between these two calls,
      potentially resulting in an oops.
      
      Provide a single interface to set both of these together, especially
      as that's commonly what is required.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/E1Z4yzs-0002Rw-4B@rmk-PC.arm.linux.org.ukSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      3b0f95be
  5. 12 6月, 2015 3 次提交
  6. 19 5月, 2015 1 次提交
    • J
      genirq: Introduce irq_set_vcpu_affinity() to target an interrupt to a VCPU · 0a4377de
      Jiang Liu 提交于
      With Posted-Interrupts support in Intel CPU and IOMMU, an external
      interrupt from assigned-devices could be directly delivered to a
      virtual CPU in a virtual machine. Instead of hacking KVM and Intel
      IOMMU drivers, we propose a platform independent interface to target
      an interrupt to a specific virtual CPU in a virtual machine, or set
      virtual CPU affinity for an interrupt.
      
      By adopting this new interface and the hierarchy irqdomain, we could
      easily support posted-interrupts on Intel platforms, and also provide
      flexible enough interfaces for other platforms to support similar
      features.
      
      Here is the usage scenario for this interface:
      Guest update MSI/MSI-X interrupt configuration
              -->QEMU and KVM handle this
              -->KVM call this interface (passing posted interrupts descriptor
                 and guest vector)
              -->irq core will transfer the control to IOMMU
              -->IOMMU will do the real work of updating IRTE (IRTE has new
                 format for VT-d Posted-Interrupts)
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NFeng Wu <feng.wu@intel.com>
      Link: http://lkml.kernel.org/r/1432026437-16560-2-git-send-email-feng.wu@intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      0a4377de
  7. 18 5月, 2015 1 次提交
    • S
      genirq: Add irq_chip_(enable/disable)_parent · 3cfeffc2
      Stefan Agner 提交于
      Add helper irq_chip_enable_parent and irq_chip_disable_parent. The
      helper implement the default behavior in case irq_enable or irq_disable
      is not implemented for the parent interrupt chip, which is calling the
      irq_mask or irq_unmask respectively.
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Cc: marc.zyngier@arm.com
      Cc: linux@arm.linux.org.uk
      Cc: u.kleine-koenig@pengutronix.de
      Cc: olof@lixom.net
      Cc: arnd@arndb.de
      Cc: daniel.lezcano@linaro.org
      Cc: mark.rutland@arm.com
      Cc: pawel.moll@arm.com
      Cc: robh+dt@kernel.org
      Cc: ijc+devicetree@hellion.org.uk
      Cc: galak@codeaurora.org
      Cc: mcoquelin.stm32@gmail.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: shawn.guo@linaro.org
      Cc: kernel@pengutronix.de
      Cc: jason@lakedaemon.net
      Link: http://lkml.kernel.org/r/1431769465-26867-3-git-send-email-stefan@agner.chSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      3cfeffc2
  8. 09 4月, 2015 1 次提交
    • M
      genirq: Allow the irqchip state of an IRQ to be save/restored · 1b7047ed
      Marc Zyngier 提交于
      There is a number of cases where a kernel subsystem may want to
      introspect the state of an interrupt at the irqchip level:
      
      - When a peripheral is shared between virtual machines,
        its interrupt state becomes part of the guest's state,
        and must be switched accordingly. KVM on arm/arm64 requires
        this for its guest-visible timer
      - Some GPIO controllers seem to require peeking into the
        interrupt controller they are connected to to report
        their internal state
      
      This seem to be a pattern that is common enough for the core code
      to try and support this without too many horrible hacks. Introduce
      a pair of accessors (irq_get_irqchip_state/irq_set_irqchip_state)
      to retrieve the bits that can be of interest to another subsystem:
      pending, active, and masked.
      
      - irq_get_irqchip_state returns the state of the interrupt according
        to a parameter set to IRQCHIP_STATE_PENDING, IRQCHIP_STATE_ACTIVE,
        IRQCHIP_STATE_MASKED or IRQCHIP_STATE_LINE_LEVEL.
      - irq_set_irqchip_state similarly sets the state of the interrupt.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
      Tested-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Phong Vo <pvo@apm.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Tin Huynh <tnhuynh@apm.com>
      Cc: Y Vo <yvo@apm.com>
      Cc: Toan Le <toanle@apm.com>
      Cc: Bjorn Andersson <bjorn@kryo.se>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Link: http://lkml.kernel.org/r/1426676484-21812-2-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      1b7047ed
  9. 15 3月, 2015 1 次提交
  10. 08 12月, 2014 1 次提交
  11. 23 11月, 2014 7 次提交
    • J
      genirq: Introduce callback irq_chip.irq_write_msi_msg · 9dde55b7
      Jiang Liu 提交于
      Introduce callback irq_chip.irq_write_msi_msg, so we can share common
      code among MSI alike interrupt controllers, such as HPET and DMAR.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
      Cc: Yijing Wang <wangyijing@huawei.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9dde55b7
    • T
      genirq: Split out flow handler typedefs into seperate header file · 75ffc007
      Thomas Gleixner 提交于
      Required to avoid circular include dependencies.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      75ffc007
    • J
      genirq: Add IRQ_SET_MASK_OK_DONE to support stacked irqchip · 2cb62547
      Jiang Liu 提交于
      Add IRQ_SET_MASK_OK_DONE in addition to IRQ_SET_MASK_OK and
      IRQ_SET_MASK_OK_NOCOPY to support stacked irqchip. IRQ_SET_MASK_OK_DONE
      is the same as IRQ_SET_MASK_OK to irq core. To stacked irqchip, it means
      that ascendant irqchips have done all the work and no more handling
      needed in descendant irqchips.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
      Cc: Yijing Wang <wangyijing@huawei.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      2cb62547
    • J
      genirq: Introduce irq_chip.irq_compose_msi_msg() to support stacked irqchip · 515085ef
      Jiang Liu 提交于
      Add callback irq_compose_msi_msg to struct irq_chip, which will be used
      to support stacked irqchip.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
      Cc: Yijing Wang <wangyijing@huawei.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      515085ef
    • Y
      genirq: Add more helper functions to support stacked irq_chip · 56e8abab
      Yingjoe Chen 提交于
      Add more helper function for stacked irq_chip to just call parent's
      function.
      Signed-off-by: NYingjoe Chen <yingjoe.chen@mediatek.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Matthias Brugger <matthias.bgg@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Gran Likely <grant.likely@linaro.org>
      Cc: Boris BREZILLON <boris.brezillon@free-electrons.com>
      Cc: <linux-arm-kernel@lists.infradead.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Yijing Wang <wangyijing@huawei.com>
      Cc: <srv_heupstream@mediatek.com>
      Cc: <yingjoe.chen@gmail.com>
      Cc: <hc.yen@mediatek.com>
      Cc: <eddie.huang@mediatek.com>
      Cc: <nathan.chung@mediatek.com>
      Cc: <yh.chen@mediatek.com>
      Cc: Sascha Hauer <kernel@pengutronix.de>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Link: http://lkml.kernel.org/r/1415893029-2971-3-git-send-email-yingjoe.chen@mediatek.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      56e8abab
    • J
      genirq: Introduce helper functions to support stacked irq_chip · 85f08c17
      Jiang Liu 提交于
      Now we already support hierarchy irq_data, so introduce several helpers
      to support stacked irq_chips.
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
      Cc: Yijing Wang <wangyijing@huawei.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      85f08c17
    • J
      irqdomain: Introduce new interfaces to support hierarchy irqdomains · f8264e34
      Jiang Liu 提交于
      We plan to use hierarchy irqdomain to suppport CPU vector assignment,
      interrupt remapping controller, IO-APIC controller, MSI interrupt
      and hypertransport interrupt etc on x86 platforms. So extend irqdomain
      interfaces to support hierarchy irqdomain.
      
      There are already many clients of current irqdomain interfaces.
      To minimize the changes, we choose to introduce new version 2 interfaces
      to support hierarchy instead of extending existing irqdomain interfaces.
      
      According to Thomas's suggestion, the most important design decision is
      to build hierarchy struct irq_data to support hierarchy irqdomain, so
      hierarchy irqdomain related data could be saved in struct irq_data.
      With support of hierarchy irq_data, we could also support stacked
      irq_chips. This is most useful in case of set_affinity().
      
      The new hierarchy irqdomain introduces following interfaces:
      1) irq_domain_alloc_irqs()/irq_domain_free_irqs(): allocate/release IRQ
         and related resources.
      2) __irq_domain_alloc_irqs(): a special version to support legacy IRQs.
      3) irq_domain_activate_irq()/irq_domain_deactivate_irq(): program
         interrupt controllers to activate/deactivate interrupt.
      
      There are also several help functions to ease irqdomain implemenations:
      1) irq_domain_get_irq_data(): get irq_data associated with a specific
         irqdomain.
      2) irq_domain_set_hwirq_and_chip(): save irqdomain specific data into
         irq_data.
      3) irq_domain_alloc_irqs_parent()/irq_domain_free_irqs_parent(): invoke
         parent irqdomain's alloc/free callbacks.
      
      We also changed irq_startup()/irq_shutdown() to invoke
      irq_domain_activate_irq()/irq_domain_deactivate_irq() to program
      interrupt controller when start/stop interrupts.
      
      [ tglx: Folded parts of the later patch series in ]
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Yingjoe Chen <yingjoe.chen@mediatek.com>
      Cc: Yijing Wang <wangyijing@huawei.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f8264e34
  12. 09 11月, 2014 3 次提交
  13. 01 9月, 2014 1 次提交
  14. 17 7月, 2014 1 次提交
  15. 16 5月, 2014 6 次提交
  16. 28 4月, 2014 1 次提交
    • T
      genirq: x86: Ensure that dynamic irq allocation does not conflict · 62a08ae2
      Thomas Gleixner 提交于
      On x86 the allocation of irq descriptors may allocate interrupts which
      are in the range of the GSI interrupts. That's wrong as those
      interrupts are hardwired and we don't have the irq domain translation
      like PPC. So one of these interrupts can be hooked up later to one of
      the devices which are hard wired to it and the io_apic init code for
      that particular interrupt line happily reuses that descriptor with a
      completely different configuration so hell breaks lose.
      
      Inside x86 we allocate dynamic interrupts from above nr_gsi_irqs,
      except for a few usage sites which have not yet blown up in our face
      for whatever reason. But for drivers which need an irq range, like the
      GPIO drivers, we have no limit in place and we don't want to expose
      such a detail to a driver.
      
      To cure this introduce a function which an architecture can implement
      to impose a lower bound on the dynamic interrupt allocations.
      
      Implement it for x86 and set the lower bound to nr_gsi_irqs, which is
      the end of the hardwired interrupt space, so all dynamic allocations
      happen above.
      
      That not only allows the GPIO driver to work sanely, it also protects
      the bogus callsites of create_irq_nr() in hpet, uv, irq_remapping and
      htirq code. They need to be cleaned up as well, but that's a separate
      issue.
      Reported-by: NJin Yao <yao.jin@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Krogerus Heikki <heikki.krogerus@intel.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1404241617360.28206@ionos.tec.linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      62a08ae2
  17. 18 4月, 2014 1 次提交
    • T
      genirq: Allow forcing cpu affinity of interrupts · 01f8fa4f
      Thomas Gleixner 提交于
      The current implementation of irq_set_affinity() refuses rightfully to
      route an interrupt to an offline cpu.
      
      But there is a special case, where this is actually desired. Some of
      the ARM SoCs have per cpu timers which require setting the affinity
      during cpu startup where the cpu is not yet in the online mask.
      
      If we can't do that, then the local timer interrupt for the about to
      become online cpu is routed to some random online cpu.
      
      The developers of the affected machines tried to work around that
      issue, but that results in a massive mess in that timer code.
      
      We have a yet unused argument in the set_affinity callbacks of the irq
      chips, which I added back then for a similar reason. It was never
      required so it got not used. But I'm happy that I never removed it.
      
      That allows us to implement a sane handling of the above scenario. So
      the affected SoC drivers can add the required force handling to their
      interrupt chip, switch the timer code to irq_force_affinity() and
      things just work.
      
      This does not affect any existing user of irq_set_affinity().
      
      Tagged for stable to allow a simple fix of the affected SoC clock
      event drivers.
      Reported-and-tested-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Tomasz Figa <t.figa@samsung.com>,
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: linux-arm-kernel@lists.infradead.org,
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20140416143315.717251504@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      01f8fa4f
  18. 14 3月, 2014 2 次提交
  19. 12 3月, 2014 1 次提交
  20. 13 11月, 2013 1 次提交
    • T
      genirq: Prevent spurious detection for unconditionally polled interrupts · b39898cd
      Thomas Gleixner 提交于
      On a 68k platform a couple of interrupts are demultiplexed and
      "polled" from a top level interrupt. Unfortunately there is no way to
      determine which of the sub interrupts raised the top level interrupt,
      so all of the demultiplexed interrupt handlers need to be
      invoked. Given a high enough frequency this can trigger the spurious
      interrupt detection mechanism, if one of the demultiplex interrupts
      returns IRQ_NONE continuously. But this is a false positive as the
      polling causes this behaviour and not buggy hardware/software.
      
      Introduce IRQ_POLLED which can be set at interrupt chip setup time via
      irq_set_status_flags(). The flag excludes the interrupt from the
      spurious detector and from all core polling activities.
      Reported-and-tested-by: NMichael Schmitz <schmitzmic@gmail.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: linux-m68k@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1311061149250.23353@ionos.tec.linutronix.de
      b39898cd
  21. 13 9月, 2013 1 次提交
  22. 25 6月, 2013 1 次提交
  23. 29 5月, 2013 2 次提交