1. 29 11月, 2016 1 次提交
  2. 20 10月, 2016 1 次提交
  3. 21 9月, 2016 1 次提交
  4. 13 9月, 2016 1 次提交
  5. 23 8月, 2016 1 次提交
  6. 09 8月, 2016 1 次提交
  7. 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
  8. 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
  9. 21 5月, 2016 1 次提交
  10. 09 5月, 2016 1 次提交
  11. 04 5月, 2016 1 次提交
  12. 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
  13. 23 3月, 2016 1 次提交
  14. 09 3月, 2016 1 次提交
  15. 25 2月, 2016 2 次提交
  16. 19 2月, 2016 1 次提交
  17. 18 2月, 2016 2 次提交
  18. 17 2月, 2016 3 次提交
  19. 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
  20. 26 1月, 2016 1 次提交
  21. 24 1月, 2016 1 次提交
  22. 29 12月, 2015 1 次提交
  23. 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
  24. 14 10月, 2015 1 次提交
  25. 30 9月, 2015 1 次提交
  26. 25 8月, 2015 1 次提交
  27. 01 8月, 2015 1 次提交
  28. 23 6月, 2015 1 次提交
  29. 22 6月, 2015 2 次提交
  30. 18 5月, 2015 1 次提交
  31. 01 4月, 2015 1 次提交
    • K
      IRQCHIP: Add new driver for BCM7038-style level 1 interrupt controllers · 5f7f0317
      Kevin Cernekee 提交于
      This is the main peripheral IRQ controller on the BCM7xxx MIPS chips;
      it has the following characteristics:
      
       - 64 to 160+ level IRQs
       - Atomic set/clear registers
       - Reasonably predictable register layout (N status words, then N
         mask status words, then N mask set words, then N mask clear words)
       - SMP affinity supported on most systems
       - Typically connected to MIPS IRQ 2,3,2,3 on CPUs 0,1,2,3
      
      This driver registers one IRQ domain and one IRQ chip to cover all
      instances of the block.  Up to 4 instances of the block may appear, as
      it supports 4-way IRQ affinity on BCM7435.
      
      The same block exists on the ARM BCM7xxx chips, but typically the ARM GIC
      is used instead.  So this driver is primarily intended for MIPS STB chips.
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Cc: f.fainelli@gmail.com
      Cc: jaedon.shin@gmail.com
      Cc: abrestic@chromium.org
      Cc: tglx@linutronix.de
      Cc: jason@lakedaemon.net
      Cc: jogo@openwrt.org
      Cc: arnd@arndb.de
      Cc: computersforpeace@gmail.com
      Cc: linux-mips@linux-mips.org
      Cc: devicetree@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/8844/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5f7f0317
  32. 04 3月, 2015 1 次提交
  33. 26 11月, 2014 1 次提交