aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/irqchip (follow)
AgeCommit message (Collapse)AuthorFilesLines
2017-08-31irqchip/gic-v3-its: Add device proxy for VPE management if !DirectLpiMarc Zyngier1-6/+145
When we don't have the DirectLPI feature, we must work around the architecture shortcomings to be able to perform the required maintenance (interrupt masking, clearing and injection). For this, we create a fake device whose sole purpose is to provide a way to issue commands as if we were dealing with LPIs coming from that device (while they actually originate from the ITS). This fake device doesn't have LPIs allocated to it, but instead uses the VPE LPIs. Of course, this could be a real bottleneck, and a naive implementation would require 6 commands to issue an invalidation. Instead, let's allocate at least one event per physical CPU (rounded up to the next power of 2), and opportunistically map the VPE doorbell to an event. This doorbell will be mapped until we roll over and need to reallocate this slot. This ensures that most of the time, we only need 2 commands to issue an INV, INT or CLEAR, making the performance a lot better, given that we always issue a CLEAR on entry, and an INV on each side of a trapped WFI. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Make LPI allocation optional on device creationMarc Zyngier1-7/+14
The normal course of action when allocating the ITS' view of a device is to allocate the corresponding LPIs. But we're about to introduce devices that borrow their interrupts from some other entities. So let's make the allocation optional. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VPE interrupt maskingMarc Zyngier1-0/+33
When masking/unmasking a doorbell interrupt, it is necessary to issue an invalidation to the corresponding redistributor. We use the DirectLPI feature by writting directly to the corresponding redistributor. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VPE affinity changesMarc Zyngier1-0/+96
When we're about to run a vcpu, it is crucial that the redistributor associated with the physical CPU is being told about the new residency. This is abstracted by hijacking the irq_set_affinity method for the doorbell interrupt associated with the VPE. It is expected that the hypervisor will call this method before scheduling the VPE. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VPE invalidation hookMarc Zyngier1-0/+4
When a guest issues a INVALL command targetting a collection, it must be translated into a VINVALL for the VPE that has this collection. This patch implements a hook that offers this functionallity to the hypervisor. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VPE schedulingMarc Zyngier1-0/+85
When a VPE is scheduled to run, the corresponding redistributor must be told so, by setting VPROPBASER to the VM's property table, and VPENDBASER to the vcpu's pending table. When scheduled out, we preserve the IDAI and PendingLast bits. The latter is specially important, as it tells the hypervisor that there are pending interrupts for this vcpu. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VPE irq domain [de]activationMarc Zyngier1-0/+102
On activation, a VPE is mapped using the VMAPP command, followed by a VINVALL for a good measure. On deactivation, the VPE is simply unmapped. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VPE irq domain allocation/teardownMarc Zyngier1-0/+169
When creating a VM, the low level GICv4 code is responsible for: - allocating each VPE a unique VPEID - allocating a doorbell interrupt for each VPE - allocating the pending tables for each VPE - allocating the property table for the VM This of course has to be reversed when the VM is brought down. All of this is wired into the irq domain alloc/free methods. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VPE domain infrastructureMarc Zyngier1-1/+30
Add the basic GICv4 VPE (vcpu in GICv4 parlance) infrastructure (irqchip, irq domain) that is going to be populated in the following patches. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VLPI configuration handlingMarc Zyngier1-5/+70
When a VLPI is reconfigured (enabled, disabled, change in priority), the full configuration byte must be written, and the caches invalidated. Also, when using the irq_mask/irq_unmask methods, it is necessary to disable the doorbell for that particular interrupt (by mapping it to 1023) on top of clearing the Enable bit. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VLPI map/unmap operationsMarc Zyngier1-3/+247
In order to let a VLPI being injected into a guest, the VLPI must be mapped using the VMAPTI command. When moved to a different vcpu, it must be moved with the VMOVI command. These commands are issued via the irq_set_vcpu_affinity method, making sure we unmap the corresponding host LPI first. The reverse is also done when the VLPI is unmapped from the guest. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add VLPI configuration hookMarc Zyngier1-0/+24
Add the skeleton irq_set_vcpu_affinity method that will be used to configure VLPIs. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-31irqchip/gic-v3-its: Add GICv4 ITS command definitionsMarc Zyngier1-1/+1
Add the new GICv4 ITS command definitions, most of them, being defined in terms of their physical counterparts. Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-30MIPS: GIC: Introduce asm/mips-gic.h with accessor functionsPaul Burton1-7/+6
This patch introduces a new header providing accessor functions for the MIPS Global Interrupt Controller (GIC) mirroring those provided for the other 2 components of the MIPS Coherent Processing System (CPS) - the Coherence Manager (CM) & Cluster Power Controller (CPC). This header makes use of the new standardised CPS accessor macros where possible, but does require some custom accessors for cases where we have either a bit or a register per interrupt. A major advantage of this over the existing include/linux/irqchip/mips-gic.h definitions is that code performing accesses can become much simpler, for example this: gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_TRIGGER) + GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr), (unsigned long)trig << GIC_INTR_BIT(intr)); ...can become simply: change_gic_trig(intr, trig); The accessors handle 32 vs 64 bit in the same way as for CM & CPC code, which means that GIC code will also not need to worry about the access size in most cases. They are also accessible outside of drivers/irqchip/irq-mips-gic.c which will allow for simplification in the use of the non-interrupt portions of the GIC (eg. counters) which currently require the interrupt controller driver to expose helper functions for access. This patch doesn't change any existing code over to use the new accessors yet, since a wholesale change would be invasive & difficult to review. Instead follow-on patches will convert code piecemeal to use this new header. The one change to existing code is to rename gic_base to mips_gic_base & make it global, in order to fit in with the naming expected by the standardised CPS accessor macros. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17020/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-08-30irqchip: mips-gic: SYNC after enabling GIC regionJames Hogan1-1/+4
A SYNC is required between enabling the GIC region and actually trying to use it, even if the first access is a read, otherwise its possible depending on the timing (and in my case depending on the precise alignment of certain kernel code) to hit CM bus errors on that first access. Add the SYNC straight after setting the GIC base. [paul.burton@imgtec.com: Changes later in this series increase our likelihood of hitting this by reducing the amount of code that runs between enabling the GIC & accessing it.] Fixes: a7057270c280 ("irqchip: mips-gic: Add device-tree support") Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Paul Burton <paul.burton@imgtec.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17019/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-08-30irqchip: mips-gic: SYNC after enabling GIC regionJames Hogan1-1/+4
A SYNC is required between enabling the GIC region and actually trying to use it, even if the first access is a read, otherwise its possible depending on the timing (and in my case depending on the precise alignment of certain kernel code) to hit CM bus errors on that first access. Add the SYNC straight after setting the GIC base. [paul.burton@imgtec.com: Changes later in this series increase our likelihood of hitting this by reducing the amount of code that runs between enabling the GIC & accessing it.] Fixes: a7057270c280 ("irqchip: mips-gic: Add device-tree support") Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Paul Burton <paul.burton@imgtec.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 3.19.x- Patchwork: https://patchwork.linux-mips.org/patch/17019/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-08-30MIPS: CPS: Have asm/mips-cps.h include CM & CPC headersPaul Burton1-1/+1
With Coherence Manager (CM) 3.5 information about the topology of the system, which has previously only been available through & accessed from the CM, is now also provided by the Cluster Power Controller (CPC). This includes a new CPC_CONFIG register mirroring GCR_CONFIG, and similarly a new CPC_Cx_CONFIG register mirroring GCR_Cx_CONFIG. In preparation for adjusting functions such as mips_cm_numcores(), which have previously only needed to access the CM, to also access the CPC this patch modifies the way we use the various CPS headers. Rather than having users include asm/mips-cm.h or asm/mips-cpc.h individually we instead have users include asm/mips-cps.h which in turn includes asm/mips-cm.h & asm/mips-cpc.h. This means that users will gain access to both CM & CPC registers by including one header, and most importantly it makes asm/mips-cps.h an ideal location for helper functions which need to access the various components of the CPS. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17015/ Patchwork: https://patchwork.linux-mips.org/patch/17217/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-08-30MIPS: Unify checks for sibling CPUsPaul Burton1-1/+1
Up until now we have open-coded checks for whether CPUs are siblings, with slight variations on whether we consider the package ID or not. This will only get more complex when we introduce cluster support, so in preparation for that this patch introduces a cpus_are_siblings() function which can be used to check whether or not 2 CPUs are siblings in a consistent manner. By checking globalnumber with the VP ID masked out this also has the neat side effect of being ready for multi-cluster systems already. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17011/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-08-29MIPS: CM: Use BIT/GENMASK for register fields, order & drop shiftsPaul Burton1-2/+2
There's no reason for us not to use BIT() & GENMASK() in asm/mips-cm.h when declaring macros corresponding to register fields. This patch modifies our definitions to do so. The *_SHF definitions are removed entirely - they duplicate information found in the masks, are infrequently used & can be replaced with use of __ffs() where needed. The *_MSK definitions then lose their _MSK suffix which is now somewhat redundant, and users are modified to match. The field definitions are moved to follow the appropriate register's accessor functions, which helps to keep the field definitions in order & to find the appropriate fields for a given register. Whilst here a comment is added describing each register & including its name, which is helpful both for linking the register back to hardware documentation & for grepping purposes. This also cleans up a couple of issues that became obvious as a result of making the changes described above: - We previously had definitions for GCR_Cx_RESET_EXT_BASE & a phony copy of that named GCR_RESET_EXT_BASE - a register which does not exist. The bad definitions were added by commit 497e803ebf98 ("MIPS: smp-cps: Ensure secondary cores start with EVA disabled") and made use of from boot_core(), which is now modified to use the GCR_Cx_RESET_EXT_BASE definitions. - We had a typo in CM_GCR_ERROR_CAUSE_ERRINGO_MSK - we now correctly define this as inFo rather than inGo. Now that we don't duplicate field information between _SHF & _MSK definitions, and keep the fields next to the register accessors, it will be much easier to spot & prevent any similar oddities being introduced in the future. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Acked-by: Thomas Gleixner <tglx@linutronix.de Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17001/ Patchwork: https://patchwork.linux-mips.org/patch/17216/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2017-08-23irqchip/gic-v3-its: Generalize LPI configurationMarc Zyngier1-10/+11
We're are going to need to change a bit more than just the enable bit in the LPI property table in the future. So let's change the LPI configuration funtion to take a set of bits to be cleared, and a set of bits to be set. This way, we'll be able to use it when a guest updates an LPI property (priority, for example). Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3-its: Generalize device table allocationMarc Zyngier1-10/+16
As we want to use 2-level tables for VCPUs, let's hack the device table allocator in order to make it slightly more generic. It will get reused in subsequent patches. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3-its: Rework LPI freeingMarc Zyngier1-6/+7
Rework LPI deallocation so that it can be reused by the v4 support code. Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3-its: Split out pending table allocationMarc Zyngier1-9/+20
Just as for the property table, let's move the pending table allocation to a separate function. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3-its: Allow use of indirect VCPU tablesMarc Zyngier1-8/+17
The VCPU tables can be quite sparse as well, and it makes sense to use indirect tables as well if possible. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3-its: Split out property table allocationMarc Zyngier1-10/+21
Move the LPI property table allocation into its own function, as this is going to be required for those associated with VMs in the future. Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3-its: Implement irq_set_irqchip_state for pending stateMarc Zyngier1-0/+78
Allow the pending state of an LPI to be set or cleared via irq_set_irqchip_state. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3-its: Macro-ize its_send_single_commandMarc Zyngier1-37/+47
Most ITS commands do operate on a collection object, and require a SYNC command to be performed on that collection in order to guarantee the execution of the first command. With GICv4 ITS, another set of commands perform similar operations on a VPE object, and a VSYNC operations must be executed to guarantee their execution. Given the similarities (post a command, perform a synchronization operation on a sync object), it makes sense to reuse the same mechanism for both class of commands. Let's start with turning its_send_single_command into a huge macro that performs the bulk of the work, and a set of helpers that make this macro usable for the GICv3 ITS commands. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3-its: Add probing for VLPI propertiesMarc Zyngier1-4/+67
Add the probing code for the ITS VLPI support. This includes configuring the ITS number if not supporting the single VMOVP command feature. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3-its: Move LPI definitions aroundMarc Zyngier1-12/+13
The various LPI definitions are in the middle of the code, and would be better placed at the beginning, given that we're going to use some of them much earlier. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3: Add VLPI/DirectLPI discoveryMarc Zyngier1-1/+23
Add helper functions that probe for VLPI and DirectLPI properties. Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip/gic-v3: Add redistributor iteratorMarc Zyngier1-22/+47
In order to discover the VLPI properties, we need to iterate over the redistributor regions. As we already have code that does this, let's factor it out and make it slightly more generic. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip: Convert to using %pOF instead of full_nameRob Herring16-56/+50
Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Lee Jones <lee@kernel.org> Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: Sylvain Lemieux <slemieux.tyco@gmail.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com> Cc: linux-rpi-kernel@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Cc: linux-tegra@vger.kernel.org Acked-by: Eric Anholt <eric@anholt.net> Acked-by: Baruch Siach <baruch@tkos.co.il> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Acked-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Alexandre Torgue <alexandre.torgue@st.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-23irqchip: Add UniPhier AIDET irqchip driverMasahiro Yamada3-0/+270
UniPhier SoCs contain AIDET (ARM Interrupt Detector). This is intended to provide additional features that are not covered by GIC. The main purpose is to provide logic inverter to support low level and falling edge trigger types for interrupt lines from on-board devices. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-19irqchip/gic-v3-its: Properly handle command queue wrappingMarc Zyngier1-1/+7
wait_for_range_completion() is nicely busted when handling wrapping of the command queue, leading to an early exit instead of waiting for the command to have been executed. Fortunately, the impact is pretty minor, as it only impair the detection of an ITS that doesn't make any forward progress for a whole second. And an ITS should *never* lock up. Reported-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-18irqchip/armada-370-xp: Enable MSI-X supportStefan Roese1-1/+1
Armada XP does not only support MSI, but also MSI-X. This patch sets the MSI_FLAG_PCI_MSIX flag in the interrupt controller driver which is the only change necessary to enable MSI-X support on this SoC. As the Linux PCI MSI-X infrastructure takes care of writing the data and address structures into the BAR specified by the MSI-X controller. Signed-off-by: Stefan Roese <sr@denx.de> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-18irqchip/xtensa-mx: Report that effective affinity is a single targetMarc Zyngier2-1/+6
The xtensa-mx driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-13-marc.zyngier@arm.com
2017-08-18irqchip/mips-gic: Report that effective affinity is a single targetMarc Zyngier2-3/+8
The MIPS GIC driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-12-marc.zyngier@arm.com
2017-08-18irqchip/hip04: Report that effective affinity is a single targetMarc Zyngier1-0/+3
The HIP04 driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-11-marc.zyngier@arm.com
2017-08-18irqchip/metag-ext: Report that effective affinity is a single targetMarc Zyngier1-0/+4
The metag-ext driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-10-marc.zyngier@arm.com
2017-08-18irqchip/bcm-7038-l1: Report that effective affinity is a single targetMarc Zyngier2-0/+4
The BCM 7038-L1 driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-9-marc.zyngier@arm.com
2017-08-18irqchip/bcm-6345-l1: Report that effective affinity is a single targetMarc Zyngier2-0/+4
The BCM 6345-L1 driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-8-marc.zyngier@arm.com
2017-08-18irqchip/armada-370-xp: Report that effective affinity is a single targetMarc Zyngier2-0/+4
The Armada 370 XP driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-7-marc.zyngier@arm.com
2017-08-18irqchip/gic-v3-its: Report that effective affinity is a single targetMarc Zyngier1-1/+6
The GICv3 ITS driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-6-marc.zyngier@arm.com
2017-08-18irqchip/gic-v3: Report that effective affinity is a single targetMarc Zyngier2-0/+4
The GICv3 driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-5-marc.zyngier@arm.com
2017-08-18irqchip/gic: Report that effective affinity is a single targetMarc Zyngier2-0/+4
The GIC driver only targets a single CPU at a time, even if the notional affinity is wider. Let's inform the core code about this. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: James Hogan <james.hogan@imgtec.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Chris Zankel <chris@zankel.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Link: http://lkml.kernel.org/r/20170818083925.10108-4-marc.zyngier@arm.com
2017-08-14Merge tag 'irqchip-4.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgentThomas Gleixner9-33/+74
Pull irqchip fixes for 4.13 from Marc Zyngier Mostly GIC related, again: - GICv3 ITS NUMA handling fixes - GICv3 force affinity handling - Barrier adjustment in both GIC interrupt handling - Error reporting when the DT presents an incompatible interrupt - GICv3 platform MSI DT parsing bug fix - Broadcom L2 PM fix - Atmel AIC cleanups
2017-08-10irqchip/gic-v3-its-platform-msi: Fix msi-parent parsing loopLorenzo Pieralisi1-0/+1
While parsing the msi-parent property to chase up the IRQ domain a given device belongs to, the index into the msi-parent tuple should be incremented to ensure all properties entries are taken into account. Current code missed the index update so the parsing loop does not work in case multiple msi-parent phandles are present and may turn into an infinite loop in of_pmsi_get_dev_id() if phandle at index 0 does not correspond to the domain we are actually looking-up. Fix the code by updating the phandle index at each iteration in of_pmsi_get_dev_id(). Fixes: deac7fc1c87f ("irqchip/gic-v3-its: Parse new version of msi-parent property") Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-10irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODESHanjun Guo1-7/+31
When enabling ITS NUMA support on D05, I got the boot log: [ 0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0 [ 0.000000] SRAT: PXM 0 -> ITS 1 -> Node 0 [ 0.000000] SRAT: PXM 0 -> ITS 2 -> Node 0 [ 0.000000] SRAT: PXM 1 -> ITS 3 -> Node 1 [ 0.000000] SRAT: ITS affinity exceeding max count[4] This is wrong on D05 as we have 8 ITSs with 4 NUMA nodes. So dynamically alloc the memory needed instead of using its_srat_maps[MAX_NUMNODES], which count the number of ITS entry(ies) in SRAT and alloc its_srat_maps as needed, then build the mapping of numa node to ITS ID. Of course, its_srat_maps will be freed after ITS probing because we don't need that after boot. After doing this, I got what I wanted: [ 0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0 [ 0.000000] SRAT: PXM 0 -> ITS 1 -> Node 0 [ 0.000000] SRAT: PXM 0 -> ITS 2 -> Node 0 [ 0.000000] SRAT: PXM 1 -> ITS 3 -> Node 1 [ 0.000000] SRAT: PXM 2 -> ITS 4 -> Node 2 [ 0.000000] SRAT: PXM 2 -> ITS 5 -> Node 2 [ 0.000000] SRAT: PXM 2 -> ITS 6 -> Node 2 [ 0.000000] SRAT: PXM 3 -> ITS 7 -> Node 3 Fixes: dbd2b8267233 ("irqchip/gic-v3-its: Add ACPI NUMA node mapping") Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com> Cc: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-07irqchip: brcmstb-l2: Define an irq_pm_shutdown functionFlorian Fainelli1-0/+1
The Broadcom STB platforms support S5 and we allow specific hardware wake-up events to take us out of this state. Because we were not defining an irq_pm_shutdown() function pointer, we would not be correctly masking non-wakeup events, which would result in spurious wake-ups from sources that were not explicitly configured for wake-up. Fixes: 7f646e92766e ("irqchip: brcmstb-l2: Add Broadcom Set Top Box Level-2 interrupt controller") Acked-by: Gregory Fong <gregory.0xf0@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2017-08-02irqchip/gic: Ensure we have an ISB between ack and ->handle_irqWill Deacon2-2/+7
Devices that expose their interrupt status registers via system registers (e.g. Statistical profiling, CPU PMU, DynamIQ PMU, arch timer, vgic (although unused by Linux), ...) rely on a context synchronising operation on the CPU to ensure that the updated status register is visible to the CPU when handling the interrupt. This usually happens as a result of taking the IRQ exception in the first place, but there are two race scenarios where this isn't the case. For example, let's say we have two peripherals (X and Y), where Y uses a system register for its interrupt status. Case 1: 1. CPU takes an IRQ exception as a result of X raising an interrupt 2. Y then raises its interrupt line, but the update to its system register is not yet visible to the CPU 3. The GIC decides to expose Y's interrupt number first in the Ack register 4. The CPU runs the IRQ handler for Y, but the status register is stale Case 2: 1. CPU takes an IRQ exception as a result of X raising an interrupt 2. CPU reads the interrupt number for X from the Ack register and runs its IRQ handler 3. Y raises its interrupt line and the Ack register is updated, but again, the update to its system register is not yet visible to the CPU. 4. Since the GIC drivers poll the Ack register, we read Y's interrupt number and run its handler without a context synchronisation operation, therefore seeing the stale register value. In either case, we run the risk of missing an IRQ. This patch solves the problem by ensuring that we execute an ISB in the GIC drivers prior to invoking the interrupt handler. This is already the case for GICv3 and EOIMode 1 (the usual case for the host). Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>