1. 21 5月, 2019 1 次提交
  2. 01 5月, 2019 3 次提交
  3. 29 4月, 2019 1 次提交
  4. 20 4月, 2019 1 次提交
    • L
      irqchip: Add driver for IXP4xx · 5b978c10
      Linus Walleij 提交于
      The IXP4xx (arch/arm/mach-ixp4xx) is an old Intel XScale
      platform that has very wide deployment and use.
      
      As part of modernizing the platform, we need to implement a
      proper irqchip in the irqchip subsystem.
      
      The IXP4xx irqchip is tightly jotted together with the GPIO
      controller, and whereas in the past we would deal with this
      complex logic by adding necessarily different code, we can
      nowadays modernize it using a hierarchical irqchip.
      
      The actual IXP4 irqchip is a simple active low level IRQ
      controller, whereas the GPIO functionality resides in a
      different memory area and adds edge trigger support for
      the interrupts.
      
      The interrupts from GPIO lines 0..12 are 1:1 mapped to
      a fixed set of hardware IRQs on this IRQchip, so we
      expect the child GPIO interrupt controller to go in and
      allocate descriptors for these interrupts.
      
      For the other interrupts, as we do not yet have DT
      support for this platform, we create a linear irqdomain
      and then go in and allocate the IRQs that the legacy
      boards use. This code will be removed on the DT probe
      path when we add DT support to the platform.
      
      We add some translation code for supporting DT
      translations for the fwnodes, but we leave most of that
      for later.
      
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      5b978c10
  5. 19 2月, 2019 2 次提交
  6. 14 2月, 2019 1 次提交
  7. 18 12月, 2018 2 次提交
  8. 13 12月, 2018 1 次提交
  9. 26 10月, 2018 2 次提交
  10. 02 10月, 2018 1 次提交
  11. 13 8月, 2018 1 次提交
  12. 03 8月, 2018 2 次提交
    • P
      genirq/irqchip: Remove MULTI_IRQ_HANDLER as it's now obselete · 4f7799d9
      Palmer Dabbelt 提交于
      Now that every user of MULTI_IRQ_HANDLER has been convereted over to use
      GENERIC_IRQ_MULTI_HANDLER remove the references to MULTI_IRQ_HANDLER.
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: linux@armlinux.org.uk
      Cc: catalin.marinas@arm.com
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: jonas@southpole.se
      Cc: stefan.kristiansson@saunalahti.fi
      Cc: shorne@gmail.com
      Cc: jason@lakedaemon.net
      Cc: marc.zyngier@arm.com
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: nicolas.pitre@linaro.org
      Cc: vladimir.murzin@arm.com
      Cc: keescook@chromium.org
      Cc: jinb.park7@gmail.com
      Cc: yamada.masahiro@socionext.com
      Cc: alexandre.belloni@bootlin.com
      Cc: pombredanne@nexb.com
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: kstewart@linuxfoundation.org
      Cc: jhogan@kernel.org
      Cc: mark.rutland@arm.com
      Cc: ard.biesheuvel@linaro.org
      Cc: james.morse@arm.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: openrisc@lists.librecores.org
      Link: https://lkml.kernel.org/r/20180622170126.6308-6-palmer@sifive.com
      4f7799d9
    • P
      irqchip: Port the ARM IRQ drivers to GENERIC_IRQ_MULTI_HANDLER · 08fb550c
      Palmer Dabbelt 提交于
      GENERIC_IRQ_MULTI_HANDLER is incompatible with MULTI_IRQ_HANDLER because
      they define the same symbols.  Multiple generic irqchip drivers select
      MULTI_IRQ_HANDLER, which is now defined on all architectures that
      provide set_handle_irq().
      
      To solve this select GENERIC_IRQ_MULTI_HANDLER for all drivers that used to
      select MULTI_IRQ_HANDLER, but only when MULTI_IRQ_HANDLER doesn't exist.
      
      After that every architecture can be converted over from MULTI_IRQ_HANDLER
      to GENERIC_IRQ_MULTI_HANDLER before removing the extra MULTI_IRQ_HANDLER
      scaffolding.
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: linux@armlinux.org.uk
      Cc: catalin.marinas@arm.com
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: jonas@southpole.se
      Cc: stefan.kristiansson@saunalahti.fi
      Cc: shorne@gmail.com
      Cc: jason@lakedaemon.net
      Cc: marc.zyngier@arm.com
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: nicolas.pitre@linaro.org
      Cc: vladimir.murzin@arm.com
      Cc: keescook@chromium.org
      Cc: jinb.park7@gmail.com
      Cc: yamada.masahiro@socionext.com
      Cc: alexandre.belloni@bootlin.com
      Cc: pombredanne@nexb.com
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: kstewart@linuxfoundation.org
      Cc: jhogan@kernel.org
      Cc: mark.rutland@arm.com
      Cc: ard.biesheuvel@linaro.org
      Cc: james.morse@arm.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: openrisc@lists.librecores.org
      Cc: Shea Levy <shea@shealevy.com>
      Link: https://lkml.kernel.org/r/20180622170126.6308-2-palmer@sifive.com
      08fb550c
  13. 22 3月, 2018 1 次提交
  14. 14 3月, 2018 1 次提交
  15. 22 2月, 2018 1 次提交
  16. 04 1月, 2018 1 次提交
  17. 14 11月, 2017 1 次提交
    • M
      irqchip/gic-v3-its: Remove artificial dependency on PCI · 29f41139
      Marc Zyngier 提交于
      The GICv3 ITS doesn't really depend on PCI. Only the PCI/MSI
      part of it does, and there is no reason not to blow away most
      of the irqchip stack because PCI is not selected (though not
      selecting PCI seem to be asking for punishment, but hey...).
      
      So let's split the PCI-specific part from the ITS in the Kconfig
      file, and let's make that part depend on PCI. Architecture specific
      hacks (arch/arm{,64}/Kconfig) will be addressed in a separate patch.
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      29f41139
  18. 07 11月, 2017 1 次提交
  19. 03 11月, 2017 1 次提交
  20. 20 10月, 2017 1 次提交
    • T
      irqchip/meson: Disable COMPILE_TEST · d9ee91c1
      Thomas Gleixner 提交于
      The driver fails to compile with CONFIG_COMPILE_TEST=y on x86:
      
      irq-meson-gpio.c: In function ‘meson_gpio_irq_parse_dt’:
      irq-meson-gpio.c:343:8: error: implicit declaration of function
      			       ‘of_property_read_variable_u32_array’
        ret = of_property_read_variable_u32_array(node,
      
      Adding COMPILE_TEST to a driver requires at least compile testing it for
      x86....
      Reported-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      d9ee91c1
  21. 19 10月, 2017 1 次提交
  22. 17 10月, 2017 1 次提交
  23. 23 8月, 2017 1 次提交
  24. 18 8月, 2017 7 次提交
  25. 23 6月, 2017 2 次提交
  26. 15 6月, 2017 1 次提交
    • L
      ARM64/irqchip: Update ACPI_IORT symbol selection logic · c6bb8f89
      Lorenzo Pieralisi 提交于
      ACPI IORT is an ACPI addendum to describe the connection topology of
      devices with IOMMUs and interrupt controllers on ARM64 ACPI systems.
      
      Currently the ACPI IORT Kbuild symbol is selected whenever the Kbuild
      symbol ARM_GIC_V3_ITS is enabled, which in turn is selected by ARM64
      Kbuild defaults. This makes the logic behind ACPI_IORT selection a bit
      twisted and not easy to follow. On ARM64 systems enabling ACPI the
      kbuild symbol ACPI_IORT should always be selected in that it is a kernel
      layer provided to the ARM64 arch code to parse and enable ACPI firmware
      bindings.
      
      Make the ACPI_IORT selection explicit in ARM64 Kbuild and remove the
      selection from ARM_GIC_V3_ITS entry, making the ACPI_IORT selection
      logic clearer to follow.
      Acked-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      c6bb8f89
  27. 13 4月, 2017 1 次提交