- 16 Jun, 2019 1 commit
-
-
Thomas Gleixner authored
Merge tag 'irqchip-5.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes for 5.2 from Marc Zyngier: - CSky mpintc: allow interrupts to be broadcast - TI sci-inta: fix error handling - MIPS GIC: Fix local interrupt mapping - ITS: Fix command queue wrapping
-
- 05 Jun, 2019 4 commits
-
-
Heyi Guo authored
When we run several VMs with PCI passthrough and GICv4 enabled, not pinning vCPUs, we will occasionally see below warnings in dmesg: ITS queue timeout (65440 65504 480) ITS cmd its_build_vmovp_cmd failed The reason for the above issue is that in BUILD_SINGLE_CMD_FUNC: 1. Post the write command. 2. Release the lock. 3. Start to read GITS_CREADR to get the reader pointer. 4. Compare the reader pointer to the target pointer. 5. If reader pointer does not reach the target, sleep 1us and continue to try. If we have several processors running the above concurrently, other CPUs will post write commands while the 1st CPU is waiting the completion. So we may have below issue: phase 1: ---rd_idx-----from_idx-----to_idx--0--------- wait 1us: phase 2: --------------from_idx-----to_idx--0-rd_idx-- That is the rd_idx may fly ahead of to_idx, and if in case to_idx is near the wrap point, rd_idx will wrap around. So the below condition will not be met even after 1s: if (from_idx < to_idx && rd_idx >= to_idx) There is another theoretical issue. For a slow and busy ITS, the initial rd_idx may fall behind from_idx a lot, just as below: ---rd_idx---0--from_idx-----to_idx----------- This will cause the wait function exit too early. Actually, it does not make much sense to use from_idx to judge if to_idx is wrapped, but we need a initial rd_idx when lock is still acquired, and it can be used to judge whether to_idx is wrapped and the current rd_idx is wrapped. We switch to a method of calculating the delta of two adjacent reads and accumulating it to get the sum, so that we can get the real rd_idx from the wrapped value even when the queue is almost full. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Signed-off-by:
Heyi Guo <guoheyi@huawei.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Paul Burton authored
The MIPS GIC contains a block of registers used to map local interrupts to a particular CPU interrupt pin. Since these registers are found at a consecutive range of addresses we access them using an index, via the (read|write)_gic_v[lo]_map accessor functions. We currently use values from enum mips_gic_local_interrupt as those indices. Unfortunately whilst enum mips_gic_local_interrupt provides the correct offsets for bits in the pending & mask registers, the ordering of the map registers is subtly different... Compared with the ordering of pending & mask bits, the map registers move the FDC from the end of the list to index 3 after the timer interrupt. As a result the performance counter & software interrupts are therefore at indices 4-6 rather than indices 3-5. Notably this causes problems with performance counter interrupts being incorrectly mapped on some systems, and presumably will also cause problems for FDC interrupts. Introduce a function to map from enum mips_gic_local_interrupt to the index of the corresponding map register, and use it to ensure we access the map registers for the correct interrupts. Signed-off-by:
Paul Burton <paul.burton@mips.com> Fixes: a0dc5cb5 ("irqchip: mips-gic: Simplify gic_local_irq_domain_map()") Fixes: da61fcf9 ("irqchip: mips-gic: Use irq_cpu_online to (un)mask all-VP(E) IRQs") Reported-and-tested-by:
Archer Yan <ayan@wavecomp.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: stable@vger.kernel.org # v4.14+ Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Peter Ujfalusi authored
irq_create_fwspec_mapping() can fail, returning 0 as parent_virq. In this case vint_desc is going to be NULL in ti_sci_inta_alloc_irq() which will cause NULL pointer dereference. Also note that irq_create_fwspec_mapping() returns 'unsigned int' so the check '<=' was wrong. Use -EINVAL if irq_create_fwspec_mapping() returned with 0. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Guo Ren authored
The csky,mpintc could deliver a external irq to one cpu or all cpus, but it couldn't deliver a external irq to a group of cpus with cpu_mask. So we only use auto deliver mode when affinity mask_val is equal to cpu_present_mask. There is no limitation for only two cpus in SMP system. Signed-off-by:
Guo Ren <ren_guo@c-sky.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
- 06 May, 2019 1 commit
-
-
Thomas Gleixner authored
Merge tag 'irqchip-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates from Marc Zyngier - The huge (and terrifying) TI INTR/INTA set of drivers - Rewrite of the stm32mp1-exti driver as a platform driver - Update the IOMMU MSI mapping API to be RT friendly - A number of cleanups and other low impact fixes
-
- 03 May, 2019 7 commits
-
-
Julien Grall authored
A recent change split iommu_dma_map_msi_msg() in two new functions. The function was still implemented to avoid modifying all the callers at once. Now that all the callers have been reworked, iommu_dma_map_msi_msg() can be removed. Signed-off-by:
Julien Grall <julien.grall@arm.com> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Acked-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Julien Grall authored
The functions mbi_compose_m{b, s}i_msg may be called from non-preemptible context. However, on RT, iommu_dma_map_msi_msg() requires to be called from a preemptible context. A recent patch split iommu_dma_map_msi_msg in two new functions: one that should be called in preemptible context, the other does not have any requirement. The GICv3 MSI driver is reworked to avoid executing preemptible code in non-preemptible context. This can be achieved by preparing the MSI mapping when allocating the MSI interrupt. Signed-off-by:
Julien Grall <julien.grall@arm.com> [maz: only call iommu_dma_prepare_msi once, fix commit log accordingly] Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Julien Grall authored
ls_scfg_msi_compose_msg() may be called from non-preemptible context. However, on RT, iommu_dma_map_msi_msg() requires to be called from a preemptible context. A recent patch split iommu_dma_map_msi_msg() in two new functions: one that should be called in preemptible context, the other does not have any requirement. The FreeScale SCFG MSI driver is reworked to avoid executing preemptible code in non-preemptible context. This can be achieved by preparing the MSI maping when allocating the MSI interrupt. Signed-off-by:
Julien Grall <julien.grall@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Julien Grall authored
its_irq_compose_msi_msg() may be called from non-preemptible context. However, on RT, iommu_dma_map_msi_msg requires to be called from a preemptible context. A recent change split iommu_dma_map_msi_msg() in two new functions: one that should be called in preemptible context, the other does not have any requirement. The GICv3 ITS driver is reworked to avoid executing preemptible code in non-preemptible context. This can be achieved by preparing the MSI mapping when allocating the MSI interrupt. Signed-off-by:
Julien Grall <julien.grall@arm.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Julien Grall authored
gicv2m_compose_msi_msg() may be called from non-preemptible context. However, on RT, iommu_dma_map_msi_msg() requires to be called from a preemptible context. A recent change split iommu_dma_map_msi_msg() in two new functions: one that should be called in preemptible context, the other does not have any requirement. The GICv2m driver is reworked to avoid executing preemptible code in non-preemptible context. This can be achieved by preparing the MSI mapping when allocating the MSI interrupt. Signed-off-by:
Julien Grall <julien.grall@arm.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Julien Grall authored
On RT, iommu_dma_map_msi_msg() may be called from non-preemptible context. This will lead to a splat with CONFIG_DEBUG_ATOMIC_SLEEP as the function is using spin_lock (they can sleep on RT). iommu_dma_map_msi_msg() is used to map the MSI page in the IOMMU PT and update the MSI message with the IOVA. Only the part to lookup for the MSI page requires to be called in preemptible context. As the MSI page cannot change over the lifecycle of the MSI interrupt, the lookup can be cached and re-used later on. iomma_dma_map_msi_msg() is now split in two functions: - iommu_dma_prepare_msi(): This function will prepare the mapping in the IOMMU and store the cookie in the structure msi_desc. This function should be called in preemptible context. - iommu_dma_compose_msi_msg(): This function will update the MSI message with the IOVA when the device is behind an IOMMU. Signed-off-by:
Julien Grall <julien.grall@arm.com> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Acked-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Julien Grall authored
When an MSI doorbell is located downstream of an IOMMU, it is required to swizzle the physical address with an appropriately-mapped IOVA for any device attached to one of our DMA ops domain. At the moment, the allocation of the mapping may be done when composing the message. However, the composing may be done in non-preemtible context while the allocation requires to be called from preemptible context. A follow-up change will split the current logic in two functions requiring to keep an IOMMU cookie per MSI. A new field is introduced in msi_desc to store an IOMMU cookie. As the cookie may not be required in some configuration, the field is protected under a new config CONFIG_IRQ_MSI_IOMMU. A pair of helpers has also been introduced to access the field. Signed-off-by:
Julien Grall <julien.grall@arm.com> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
- 01 May, 2019 14 commits
-
-
Lokesh Vutla authored
Select the TISCI Interrupt Router, Aggregator drivers and all its dependencies for TI's SoCs based on K3 architecture. Suggested-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
Add a msi domain that is child to the INTA domain. Clients uses the INTA MSI bus layer to allocate irqs in this MSI domain. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
With the system coprocessor managing the range allocation of the inputs to Interrupt Aggregator, it is difficult to represent the device IRQs from DT. The suggestion is to use MSI in such cases where devices wants to allocate and group interrupts dynamically. Create a MSI domain bus layer that allocates and frees MSIs for a device. APIs that are implemented: - ti_sci_inta_msi_create_irq_domain() that creates a MSI domain - ti_sci_inta_msi_domain_alloc_irqs() that creates MSIs for the specified device and resource. - ti_sci_inta_msi_domain_free_irqs() frees the irqs attached to the device. - ti_sci_inta_msi_get_virq() for getting the virq attached to a specific event. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator which is an interrupt controller that does the following: - Converts events to interrupts that can be understood by an interrupt router. - Allows for multiplexing of events to interrupts. Configuration of the interrupt aggregator registers can only be done by a system co-processor and the driver needs to send a message to this co processor over TISCI protocol. Add the required infrastructure to allow the allocation and routing of these events. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
Add the DT binding documentation for Interrupt Aggregator driver. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
Texas Instruments' K3 generation SoCs has an IP Interrupt Router that does allows for redirection of input interrupts to host interrupt controller. Interrupt Router inputs are either from a peripheral or from an Interrupt Aggregator which is another interrupt controller. Configuration of the interrupt router registers can only be done by a system co-processor and the driver needs to send a message to this co processor over TISCI protocol. Add support for Interrupt Router driver over TISCI protocol. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
Add the DT binding documentation for Interrupt router driver. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
thunderx_gpio_irq_{request,release}_resources apis are trying to {request,release} resources on parent interrupt. There are default apis doing the same. Use the default parent apis instead of writing the same code snippet. Cc: linux-gpio@vger.kernel.org Cc: Linus Walleij <linus.walleij@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
Introduce irq_chip_{request,release}_resource_parent() apis so that these can be used in hierarchical irqchips. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
Each resource with in the device can be uniquely identified as defined by TISCI. Since this is generic across the devices, resource allocation also can be made generic instead of each client driver handling the resource. So add helper apis to manage the resource. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Peter Ujfalusi authored
Add the resource mapping table for AM654 SoC as defined in http://downloads.ti.com/tisci/esd/latest/5_soc_doc/am6x/resasg_types.html Introduce a new compatible for AM654 "ti,am654-sci" for using this resource map table. Reviewed-by:
Rob Herring <robh@kernel.org> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
TISCI abstracts the handling of IRQ routes where interrupt sources are not directly connected to host interrupt controller. Add support for the set of TISCI commands for requesting and releasing IRQs. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Lokesh Vutla authored
TISCI provides support for getting the resources(IRQ, RING etc..) assigned to a specific device. These resources can be handled by the client and in turn sends TISCI cmd to configure the resources. It is very important that client should keep track on usage of these resources. Add support for TISCI commands to get resource ranges. Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Grygorii Strashko authored
TISCI has been updated to have support for Resource management(like interrupts etc..). And there can be multiple device instances of a resource type in a SoC. So every driver corresponding to a resource type should get a TISCI handle so that it can make TISCI calls. And each DT node corresponding to a device should exist under its corresponding bus node as per the SoC architecture. But existing apis in TISCI library assumes that all TISCI users are child nodes of TISCI. Which is not true in the above case. So introduce (devm_)ti_sci_get_by_phandle() apis that can be used by TISCI users to get TISCI handle using of phandle property. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
- 29 Apr, 2019 13 commits
-
-
Geert Uytterhoeven authored
There is no need to print a message if devm_kzalloc() fails, as the memory allocation core already takes care of that. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Geert Uytterhoeven authored
IRQ_DOMAIN_HIERARCHY selects IRQ_DOMAIN, hence there is no need for drivers to select both. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Rasmus Villemoes authored
Using list_add + list_sort to insert an element and keeping the list sorted is a somewhat blunt instrument; one can find the right place to insert in fewer lines of code than the cmp callback uses. Moreover, walking the entire list afterwards to merge adjacent ranges is overkill, since we know that only the just-inserted element may be merged with its neighbours. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Rasmus Villemoes authored
There's no reason to ask kmalloc() to zero the allocation, since all the fields get initialized immediately afterwards. Except that there's also not any reason to initialize the ->entry member, since the element gets added to the lpi_range_list immediately. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Rasmus Villemoes authored
There's no reason to do the allocation of the new lpi_range inside the lpi_range_lock. One could change the code to avoid the allocation altogether in case the freed range can be merged with one or two existing ranges (in which case the allocation would naturally be done under the lock), but it's probably not worth complicating the code for that. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Fabien Dessenne authored
This irqchip driver uses the hwspinlock framework (coprocessor HW regs access concurrency) for the stm32mp1-exti device. Hence, this driver needs to handle the hwspinlock driver dependency using the deferred probe mechanism which requires to move this driver into a platform one with a probe() ops. This applies only for the device which is "st,stm32mp1-exti" compatible, the management of the other devices (st,stm32h7-exti / st,stm32-exti) is kept unchanged (use IRQCHIP_DECLARE) Signed-off-by:
Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Sameer Pujar authored
If interrupts are enabled for a non-root GIC device that uses the gic-pm driver, when system suspend occurs, the current interrupt state is not saved and restored correctly and so interrupts do not work again on resuming the system. Add a late suspend handler to save and restore the state for these devices. Suggested-by:
Jonathan Hunter <jonathanh@nvidia.com> Signed-off-by:
Sameer Pujar <spujar@nvidia.com> Reviewed-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Sameer Pujar authored
gic-pm driver is using pm-clk framework to manage clock resources, where clocks remain always ON. This happens on Tegra devices which use BPMP co-processor to manage the clocks. Calls to BPMP are always blocking and hence it is necessary to enable/disable clocks during prepare/unprepare phase respectively. When pm-clk is used, prepare count of clock is not balanced until pm_clk_remove() happens. Clock is prepared in the driver probe() and thus prepare count of clock remains non-zero, which in turn keeps clock ON always. Please note that above mentioned behavior is specific to Tegra devices using BPMP for clock management and this should not be seen on other devices. Though this patch uses clk_bulk APIs to address the mentioned behavior, this works fine for all devices. To simplify gic_get_clocks() API is removed and instead probe can do necessary setup. Suggested-by:
Mohan Kumar D <mkumard@nvidia.com> Signed-off-by:
Sameer Pujar <spujar@nvidia.com> Reviewed-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Julien Grall authored
The word 'number' has been misspelt in the comment on top of _irq_domain_alloc_irqs(). Signed-off-by:
Julien Grall <julien.grall@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Anson Huang authored
Use the new helper devm_platform_ioremap_resource() which wraps the platform_get_resource() and devm_ioremap_resource() together, to simplify the code. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Julien Grall authored
The word 'entirely' has been misspelt in a comment in its_msi_prepare(). Signed-off-by:
Julien Grall <julien.grall@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Hongbo Yao authored
Some definitions of Inner Cacheability attibutes need to be corrected. Fixes: 8c828a53 ("irqchip/gicv3-its: Restore all cacheability attributes") Signed-off-by:
Hongbo Yao <yaohongbo@huawei.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Florian Fainelli authored
It is useful to print which interrupt controllers are registered in the system and which parent IRQ they use, especially given that L2 interrupt controllers do not call request_irq() on their parent interrupt and do not appear under /proc/interrupts for that reason. We used to print the base register address virtual address which had little value, use %pOF to print the path to the Device Tree node which maps to the physical address more easily and is what people need to troubleshoot systems. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-