1. 07 Nov, 2017 2 commits
  2. 02 Nov, 2017 13 commits
    • Paul Burton's avatar
      irqchip: mips-gic: Make IPI bitmaps static · 61dc367e
      Paul Burton authored
      We have 2 bitmaps used to keep track of interrupts dedicated to IPIs in
      the MIPS GIC irqchip driver. These bitmaps are only used from the one
      compilation unit of that driver, and so can be made static. Do so in
      order to avoid polluting the symbol table & global namespace.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      61dc367e
    • Paul Burton's avatar
      irqchip: mips-gic: Share register writes in gic_set_type() · 5af3e93e
      Paul Burton authored
      The gic_set_type() function included writes to the MIPS GIC polarity,
      trigger & dual-trigger registers in each case of a switch statement
      determining the IRQs type. This is all well & good when we only have a
      single cluster & thus a single GIC whose register we want to update. It
      will lead to significant duplication once we have multi-cluster support
      & multiple GICs to update.
      
      Refactor this such that we determine values for the polarity, trigger &
      dual-trigger registers and then have a single set of register writes
      following the switch statement. This will allow us to write the same
      values to each GIC in a multi-cluster system in a later patch, rather
      than needing to duplicate more register writes in each case.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      5af3e93e
    • Paul Burton's avatar
      irqchip: mips-gic: Remove gic_vpes variable · 82857688
      Paul Burton authored
      Following the past few patches nothing uses the gic_vpes variable any
      longer. Remove the dead code.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      82857688
    • Paul Burton's avatar
      irqchip: mips-gic: Use num_possible_cpus() to reserve IPIs · 25c51dad
      Paul Burton authored
      Reserving a number of IPIs based upon the number of VPs reported by the
      GIC makes little sense for a few reasons:
      
       - The kernel may have been configured with NR_CPUS less than the number
         of VPs in the cluster, in which case using gic_vpes causes us to
         reserve more interrupts for IPIs than we will possibly use.
      
       - If a kernel is configured without support for multi-threading & runs
         on a system with multi-threading & multiple VPs per core then we'll
         similarly reserve more interrupts for IPIs than we will possibly use.
      
       - In systems with multiple clusters the GIC can only provide us with
         the number of VPs in its cluster, not across all clusters. In this
         case we'll reserve fewer interrupts for IPIs than we need.
      
      Fix these issues by using num_possible_cpus() instead, which in all
      cases is actually indicative of how many IPIs we may need.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      25c51dad
    • Paul Burton's avatar
      irqchip: mips-gic: Configure EIC when CPUs come online · 890f6b55
      Paul Burton authored
      Rather than configuring EIC mode for all CPUs during boot, configure it
      locally on each when they come online. This will become important with
      multi-cluster support, since clusters may be powered on & off (for
      example via hotplug) and would lose the EIC configuration when powered
      off.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      890f6b55
    • Paul Burton's avatar
      irqchip: mips-gic: Mask local interrupts when CPUs come online · 25ac19e1
      Paul Burton authored
      We currently walk through the range 0..gic_vpes-1, expecting these
      values all to be valid Linux CPU numbers to provide to mips_cm_vp_id(),
      and masking all routable local interrupts during boot. This approach has
      a few drawbacks:
      
       - In multi-cluster systems we won't have access to all CPU's GIC local
         registers when the driver is probed, since clusters (and their GICs)
         may be powered down at this point & only brought online later.
      
       - In multi-cluster systems we may power down clusters at runtime, for
         example if we offline all CPUs within it via hotplug, and the
         cluster's GIC may lose state. We therefore need to reinitialise it
         when powering back up, which this approach does not take into
         account.
      
       - The range 0..gic_vpes-1 may not all be valid Linux CPU numbers, for
         example if we run a kernel configured to support fewer CPUs than the
         system it is running on actually has. In this case we'll get garbage
         values from mips_cm_vp_id() as we read past the end of the cpu_data
         array.
      
      Fix this and simplify the code somewhat by writing an all-bits-set
      value to the VP-local reset mask register when a CPU is brought online,
      before any local interrupts are configured for it. This removes the need
      for us to access all CPUs during driver probe, removing all of the
      problems described above.
      
      In the name of simplicity we drop the checks for routability of
      interrupts and simply clear the mask bits for all interrupts. Bits for
      non-routable local interrupts will have no effect so there's no point
      performing extra work to avoid modifying them.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      25ac19e1
    • Paul Burton's avatar
      irqchip: mips-gic: Use irq_cpu_online to (un)mask all-VP(E) IRQs · da61fcf9
      Paul Burton authored
      The gic_all_vpes_local_irq_controller chip currently attempts to operate
      on all CPUs/VPs in the system when masking or unmasking an interrupt.
      This has a few drawbacks:
      
       - In multi-cluster systems we may not always have access to all CPUs in
         the system. When all CPUs in a cluster are powered down that
         cluster's GIC may also power down, in which case we cannot configure
         its state.
      
       - Relatedly, if we power down a cluster after having configured
         interrupts for CPUs within it then the cluster's GIC may lose state &
         we need to reconfigure it. The current approach doesn't take this
         into account.
      
       - It's wasteful if we run Linux on fewer VPs than are present in the
         system. For example if we run a uniprocessor kernel on CPU0 of a
         system with 16 CPUs then there's no point in us configuring CPUs
         1-15.
      
       - The implementation is also lacking in that it expects the range
         0..gic_vpes-1 to represent valid Linux CPU numbers which may not
         always be the case - for example if we run on a system with more VPs
         than the kernel is configured to support.
      
      Fix all of these issues by only configuring the affected interrupts for
      CPUs which are online at the time, and recording the configuration in a
      new struct gic_all_vpes_chip_data for later use by CPUs being brought
      online. We register a CPU hotplug state (reusing
      CPUHP_AP_IRQ_GIC_STARTING which the ARM GIC driver uses, and which seems
      suitably generic for reuse with the MIPS GIC) and execute
      irq_cpu_online() in order to configure the interrupts on the newly
      onlined CPU.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      da61fcf9
    • Paul Burton's avatar
      irqchip: mips-gic: Inline gic_local_irq_domain_map() · 63b746b1
      Paul Burton authored
      The gic_local_irq_domain_map() function has only one callsite in
      gic_irq_domain_map(), and the split between the two functions makes it
      unclear that they duplicate calculations & checks.
      
      Inline gic_local_irq_domain_map() into gic_irq_domain_map() in order to
      clean this up. Doing this makes the following small issues obvious, and
      the patch tidies them up:
      
       - Both functions used GIC_HWIRQ_TO_LOCAL() to convert a hwirq number to
         a local IRQ number. We now only do this once. Although the compiler
         ought to have optimised this away before anyway, the change leaves us
         with less duplicate code.
      
       - gic_local_irq_domain_map() had a check for invalid local interrupt
         numbers (intr > GIC_LOCAL_INT_FDC). This condition can never occur
         because any hwirq higher than those used for local interrupts is a
         shared interrupt, which gic_irq_domain_map() already handles
         separately. We therefore remove this check.
      
       - The decision of whether to map the interrupt to gic_cpu_pin or
         timer_cpu_pin can be handled within the existing switch statement in
         gic_irq_domain_map(), shortening the code a little.
      
      The change additionally prepares us nicely for the following patch of
      the series which would otherwise need to duplicate the check for whether
      a local interrupt should be percpu_devid or just percpu (ie. the switch
      statement from gic_irq_domain_map()) in gic_local_irq_domain_map().
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      63b746b1
    • Martin Blumenstingl's avatar
      irqchip/meson-gpio: add support for Meson8 SoCs · 4e4cb1b1
      Martin Blumenstingl authored
      Meson8 uses the same GPIO interrupt controller IP block as the other
      Meson SoCs. A total of 134 pins can be spied on, which is the sum of:
      - 22 pins on bank GPIOX
      - 17 pins on bank GPIOY
      - 30 pins on bank GPIODV
      - 10 pins on bank GPIOH
      - 15 pins on bank GPIOZ
      - 7 pins on bank CARD
      - 19 pins on bank BOOT
      - 14 pins in the AO domain
      Acked-by: default avatarKevin Hilman <khilman@baylibre.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      4e4cb1b1
    • Dou Liyang's avatar
      irqdomain: Update the comments of fwnode field of irq_domain structure · 4b821300
      Dou Liyang authored
      Commit:
      
      f110711a ("irqdomain: Convert irqdomain-%3Eof_node to fwnode")
      
      converted of_node field to fwnode, but didn't update its comments.
      
      Update it.
      
      Fixes: f110711a ("irqdomain: Convert irqdomain-%3Eof_node to fwnode")
      Signed-off-by: default avatarDou Liyang <douly.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      4b821300
    • Marc Zyngier's avatar
      irqchip/gic: Deal with broken firmware exposing only 4kB of GICv2 CPU interface · 0962289b
      Marc Zyngier authored
      There is a lot of broken firmware out there that don't really
      expose the information the kernel requires when it comes with dealing
      with GICv2:
      
      (1) Firmware that only describes the first 4kB of GICv2
      (2) Firmware that describe 128kB of CPU interface, while
          the usable portion of the address space is between
          60 and 68kB
      
      So far, we only deal with (2). But we have platforms exhibiting
      behaviour (1), resulting in two sub-cases:
      (a) The GIC is occupying 8kB, as required by the GICv2 architecture
      (b) It is actually spread 128kB, and this is likely to be a version
          of (2)
      
      This patch tries to work around both (a) and (b) by poking at
      the outside of the described memory region, and try to work out
      what is actually there. This is of course unsafe, and should
      only be enabled if there is no way to otherwise fix the DT provided
      by the firmware (we provide a "irqchip.gicv2_force_probe" option
      to that effect).
      
      Note that for the time being, we restrict ourselves to GICv2
      implementations provided by ARM, since there I have no knowledge
      of an alternative implementations. This could be relaxed if such
      an implementation comes to light on a broken platform.
      Reviewed-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      0962289b
    • Marc Zyngier's avatar
      irqchip/gic-v3-its: Setup VLPI properties at map time · d4d7b4ad
      Marc Zyngier authored
      So far, we require the hypervisor to update the VLPI properties
      once the the VLPI mapping has been established. While this
      makes it easy for the ITS driver, it creates a window where
      an incoming interrupt can be delivered with an unknown set
      of properties. Not very nice.
      
      Instead, let's add a "properties" field to the mapping structure,
      and use that to configure the VLPI before it actually gets mapped.
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      d4d7b4ad
    • Marc Zyngier's avatar
      Merge tag 'v4.14-rc3' into irq/irqchip-4.15 · 05f36473
      Marc Zyngier authored
      Required merge to get mainline irqchip updates.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      05f36473
  3. 19 Oct, 2017 24 commits
  4. 16 Oct, 2017 1 commit