1. 18 8月, 2017 3 次提交
  2. 23 6月, 2017 2 次提交
  3. 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
  4. 13 4月, 2017 1 次提交
  5. 07 4月, 2017 1 次提交
    • L
      irqchip/gemini: Refactor Gemini driver to reflect Faraday origin · 6ee532e2
      Linus Walleij 提交于
      The Gemini irqchip turns out to be a standard IP component from
      Faraday Technology named FTINTC010 after some research and new
      information.
      
      - Rename the driver and all symbols to reflect the new information.
      - Add the new compatible string "faraday,ftintc010"
      - Create a Kconfig symbol CONFIG_FARADAY_FTINTC010 so that SoCs
        using this interrupt controller can easily select and reuse it
        instead of hardwiring it to ARCH_GEMINI
      
      I have created a separate patch to select the new Kconfig symbol
      from the Gemini machine, which will be merged through the ARM
      SoC tree.
      
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Paulius Zaleckas <paulius.zaleckas@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      6ee532e2
  6. 14 3月, 2017 1 次提交
    • A
      irqchip/mvebu-odmi: Select GENERIC_MSI_IRQ_DOMAIN · fa23b9d1
      Arnd Bergmann 提交于
      This driver uses the MSI domain but has no strict dependency on PCI_MSI, so we
      may run into a build failure when CONFIG_GENERIC_MSI_IRQ_DOMAIN is disabled:
      
      drivers/irqchip/irq-mvebu-odmi.c:152:15: error: variable 'odmi_msi_ops' has initializer but incomplete type
       static struct msi_domain_ops odmi_msi_ops = {
                     ^~~~~~~~~~~~~~
      drivers/irqchip/irq-mvebu-odmi.c:155:15: error: variable 'odmi_msi_domain_info' has initializer but incomplete type
       static struct msi_domain_info odmi_msi_domain_info = {
                     ^~~~~~~~~~~~~~~
      drivers/irqchip/irq-mvebu-odmi.c:156:3: error: 'struct msi_domain_info' has no member named 'flags'
        .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
         ^~~~~
      drivers/irqchip/irq-mvebu-odmi.c:156:12: error: 'MSI_FLAG_USE_DEF_DOM_OPS' undeclared here (not in a function)
        .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
                  ^~~~~~~~~~~~~~~~~~~~~~~~
      drivers/irqchip/irq-mvebu-odmi.c:156:39: error: 'MSI_FLAG_USE_DEF_CHIP_OPS' undeclared here (not in a function); did you mean 'MSI_FLAG_USE_DEF_DOM_OPS'?
      
      Selecting the option from this driver seems to solve this nicely, though I could
      not find any other instance of this in irqchip drivers.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      fa23b9d1
  7. 03 2月, 2017 1 次提交
    • A
      irqchip/qcom: Add IRQ combiner driver · f20cc9b0
      Agustin Vega-Frias 提交于
      Driver for interrupt combiners in the Top-level Control and Status
      Registers (TCSR) hardware block in Qualcomm Technologies chips.
      
      An interrupt combiner in this block combines a set of interrupts by
      OR'ing the individual interrupt signals into a summary interrupt
      signal routed to a parent interrupt controller, and provides read-
      only, 32-bit registers to query the status of individual interrupts.
      The status bit for IRQ n is bit (n % 32) within register (n / 32)
      of the given combiner. Thus, each combiner can be described as a set
      of register offsets and the number of IRQs managed.
      Signed-off-by: NAgustin Vega-Frias <agustinv@codeaurora.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      f20cc9b0
  8. 29 11月, 2016 1 次提交
  9. 20 10月, 2016 1 次提交
  10. 21 9月, 2016 1 次提交
  11. 13 9月, 2016 1 次提交
  12. 23 8月, 2016 1 次提交
  13. 09 8月, 2016 1 次提交
  14. 16 6月, 2016 1 次提交
    • A
      PCI/MSI: irqchip: Fix PCI_MSI dependencies · 3ee80364
      Arnd Bergmann 提交于
      The PCI_MSI symbol is used inconsistently throughout the tree, with some
      drivers using 'select' and others using 'depends on', or using conditional
      selects.  This keeps causing problems; the latest one is a result of
      ARCH_ALPINE using a 'select' statement to enable its platform-specific MSI
      driver without enabling MSI:
      
        warning: (ARCH_ALPINE) selects ALPINE_MSI which has unmet direct dependencies (PCI && PCI_MSI)
        drivers/irqchip/irq-alpine-msi.c:104:15: error: variable 'alpine_msix_domain_info' has initializer but incomplete type
         static struct msi_domain_info alpine_msix_domain_info = {
      		 ^~~~~~~~~~~~~~~
        drivers/irqchip/irq-alpine-msi.c:105:2: error: unknown field 'flags' specified in initializer
          .flags = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
          ^
        drivers/irqchip/irq-alpine-msi.c:105:11: error: 'MSI_FLAG_USE_DEF_DOM_OPS' undeclared here (not in a function)
          .flags = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
      	     ^~~~~~~~~~~~~~~~~~~~~~~~
      
      There is little reason to enable PCI support for a platform that uses MSI
      but then leave MSI disabled at compile time.
      
      Select PCI_MSI from irqchips that implement MSI, and make PCI host bridges
      that use MSI on ARM depend on PCI_MSI_IRQ_DOMAIN.
      
      For all three architectures that support PCI_MSI_IRQ_DOMAIN (ARM, ARM64,
      X86), enable it by default whenever MSI is enabled.
      
      [bhelgaas: changelog, omit crypto config change]
      Suggested-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      3ee80364
  15. 13 6月, 2016 1 次提交
    • J
      irqchip/gic: Add platform driver for non-root GICs that require RPM · 9c8edddf
      Jon Hunter 提交于
      Add a platform driver to support non-root GICs that require runtime
      power-management. Currently, only non-root GICs are supported because
      the functions, smp_cross_call() and set_handle_irq(), that need to
      be called for a root controller are located in the __init section and
      so cannot be called by the platform driver.
      
      The GIC platform driver re-uses many functions from the existing GIC
      driver including some functions to save and restore the GIC context
      during power transitions. The functions for saving and restoring the
      GIC context are currently only defined if CONFIG_CPU_PM is enabled and
      to ensure that these functions are always defined when the platform
      driver is enabled, a dependency on CONFIG_ARM_GIC_PM (which selects the
      platform driver) has been added.
      
      In order to re-use the private GIC initialisation code, a new public
      function, gic_of_init_child(), has been added which calls various
      private functions to initialise the GIC. This is different from the
      existing gic_of_init() because it only supports non-root GICs (ie. does
      not call smp_cross_call() is set_handle_irq()) and is not located in
      the __init section (so can be used by platform drivers). Furthermore,
      gic_of_init_child() dynamically allocates memory for the GIC chip data
      which is also different from gic_of_init().
      
      There is no specific suspend handling for GICs registered as platform
      devices. Non-wakeup interrupts will be disabled by the kernel during
      late suspend, however, this alone will not power down the GIC if
      interrupts have been requested and not freed. Therefore, requestors of
      non-wakeup interrupts will need to free them on entering suspend in
      order to power-down the GIC.
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      9c8edddf
  16. 21 5月, 2016 1 次提交
  17. 09 5月, 2016 1 次提交
  18. 04 5月, 2016 1 次提交
  19. 02 5月, 2016 2 次提交
    • M
      irqchip/gic-v3: Add support for partitioned PPIs · e3825ba1
      Marc Zyngier 提交于
      Plug the partitioning layer into the GICv3 PPI code, parsing the
      DT and building the partition affinities and providing the generic
      code with partition data and callbacks.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: devicetree@vger.kernel.org
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Link: http://lkml.kernel.org/r/1460365075-7316-5-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      e3825ba1
    • M
      irqchip: Add per-cpu interrupt partitioning library · 9e2c986c
      Marc Zyngier 提交于
      We've unfortunately started seeing a situation where percpu interrupts
      are partitioned in the system: one arbitrary set of CPUs has an
      interrupt connected to a type of device, while another disjoint
      set of CPUs has the same interrupt connected to another type of device.
      
      This makes it impossible to have a device driver requesting this interrupt
      using the current percpu-interrupt abstraction, as the same interrupt number
      is now potentially claimed by at least two drivers, and we forbid interrupt
      sharing on per-cpu interrupt.
      
      A solution to this is to turn things upside down. Let's assume that our
      system describes all the possible partitions for a given interrupt, and
      give each of them a unique identifier. It is then possible to create
      a namespace where the affinity identifier itself is a form of interrupt
      number. At this point, it becomes easy to implement a set of partitions
      as a cascaded irqchip, each affinity identifier being the HW irq.
      
      This allows us to keep a number of nice properties:
      - Each partition results in a separate percpu-interrupt (with a restrictied
        affinity), which keeps drivers happy.
      - Because the underlying interrupt is still per-cpu, the overhead of
        the indirection can be kept pretty minimal.
      - The core code can ignore most of that crap.
      
      For that purpose, we implement a small library that deals with some of
      the boilerplate code, relying on platform-specific drivers to provide
      a description of the affinity sets and a set of callbacks.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: devicetree@vger.kernel.org
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Link: http://lkml.kernel.org/r/1460365075-7316-4-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      9e2c986c
  20. 23 3月, 2016 1 次提交
  21. 09 3月, 2016 1 次提交
  22. 25 2月, 2016 2 次提交
  23. 19 2月, 2016 1 次提交
  24. 18 2月, 2016 2 次提交
  25. 17 2月, 2016 3 次提交
  26. 08 2月, 2016 1 次提交
    • S
      irqchips/bmips: Add bcm6345-l1 interrupt controller · c7c42ec2
      Simon Arlott 提交于
      Add the BCM6345 interrupt controller based on the SMP-capable BCM7038
      and the BCM3380 but with packed interrupt registers.
      
      Add the BCM6345 interrupt controller to a list with the existing BCM7038
      so that interrupts on CPU1 are not ignored.
      
      Update the maintainers file list for BMIPS to include this driver.
      Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: devicetree@vger.kernel.org
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: linux-mips@linux-mips.org
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Jonas Gorski <jogo@openwrt.org>
      Cc: Kumar Gala <galak@codeaurora.org>
      Cc: Rob Herring <robh@kernel.org>
      Link: http://lkml.kernel.org/r/5651D176.6030908@simon.arlott.org.ukSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      c7c42ec2
  27. 26 1月, 2016 1 次提交
  28. 24 1月, 2016 1 次提交
  29. 29 12月, 2015 1 次提交
  30. 18 12月, 2015 2 次提交
    • M
      irqchip/mgigen: Add platform device driver for mbigen device · 717c3dbc
      Ma Jun 提交于
      Mbigen means Message Based Interrupt Generator(MBIGEN).
      
      Its a kind of interrupt controller that collects
      the interrupts from external devices and generate msi interrupt.
      Mbigen is applied to reduce the number of wire connected interrupts.
      
      As the peripherals increasing, the interrupts lines needed is
      increasing much, especially on the Arm64 server SOC.
      
      Therefore, the interrupt pin in GIC is not enough to cover so
      many peripherals.
      
      Mbigen is designed to fix this problem.
      
      Mbigen chip locates in ITS or outside of ITS.
      
      Mbigen chip hardware structure shows as below:
      
      		mbigen chip
      |---------------------|-------------------|
      mgn_node0	  mgn_node1		mgn_node2
       |		 |-------|		|-------|------|
      dev1		dev1    dev2		dev1   dev3   dev4
      
      Each mbigen chip contains several mbigen nodes.
      
      External devices can connect to mbigen node through wire connecting way.
      
      Because a mbigen node only can support 128 interrupt maximum, depends
      on the interrupt lines number of devices, a device can connects to one
      more mbigen nodes.
      
      Also, several different devices can connect to a same mbigen node.
      
      When devices triggered interrupt,mbigen chip detects and collects
      the interrupts and generates the MBI interrupts by writing the ITS
      Translator register.
      
      To simplify mbigen driver,I used a new conception--mbigen device.
      Each mbigen device is initialized as a platform device.
      
      Mbigen device presents the parts(register, pin definition etc.) in
      mbigen chip corresponding to a peripheral device.
      
      So from software view, the structure likes below
      
      	            mbigen chip
           |---------------------|-----------------|
      mbigen device1       mbigen device2  mbigen device3
            |                   |                |
           dev1                dev2             dev3
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NMa Jun <majun258@huawei.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      717c3dbc
    • L
      irqchip/gic: Kconfig the number of instances · a27d21e0
      Linus Walleij 提交于
      There is currently a hack in the GIC driver making it possible
      to pass the number of GIC instances from the platform-specific
      include files and thus override the variable MAX_GIC_NR.
      
      With multiplatform deployments, this will not work as we need
      to get rid of the platform-specific include files.
      
      It turns out that this feature is only used by the RealView
      platform which has a cascaded GIC. So move the configuration
      to Kconfig and bump to 2 instances if we're building for the
      RealView. The include file hacks can then be removed.
      
      Tested on the ARM PB11MPCore with its cascaded GIC.
      Suggested-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      a27d21e0
  31. 14 10月, 2015 1 次提交