758e8366754d3fa57da978fef9d2c652f7b55c02 |
|
25-Sep-2014 |
Grzegorz Jaszczyk <jaz@semihalf.com> |
irqchip: armada-370-xp: Fix MPIC interrupt handling In both Armada-375 and Armada-38x MPIC interrupts should be identified by reading cause register multiplied by the interrupt mask. A lack of above mentioned multiplication resulted in a bug, caused by the fact that in Armada-375 and Armada-38x some of the interrupts (e.g. network interrupts) can be handled either as a GIC or MPIC interrupts. Therefore during MPIC interrupts handling, cause register shows hits from interrupts even if they are masked for MPIC but unmasked for a GIC. This resulted in 'bad IRQ' error, because masked MPIC interrupt without registered interrupt handler, was trying to be handled during interrupt handling procedure of some other unmasked MPIC interrupt (e.g. local timer irq). This commit fixes that by ensuring that during MPIC interrupt handling only interrupts that are unmasked for MPIC are processed. Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Fixes: bc69b8adfe22 ("irqchip: armada-370-xp: Setup a chained handler for the MPIC") Cc: <stable@vger.kernel.org> # v3.15+ Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Link: https://lkml.kernel.org/r/1411643839-64925-3-git-send-email-jaz@semihalf.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
298dcb2dd0267d51e4f7c94a628cd0765a50ad75 |
|
25-Sep-2014 |
Grzegorz Jaszczyk <jaz@semihalf.com> |
irqchip: armada-370-xp: Fix MSI interrupt handling The MSI interrupts use the 16 high doorbells, which are notified by using IRQ1 of the main interrupt controller. The MSI interrupts were handled correctly for Armada-XP and Armada-370 but not for Armada-375 and Armada-38x, which use chained handler for the MPIC. This commit fixes that by checking proper interrupt number in chained handler for the MPIC. Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Fixes: bc69b8adfe22 ("irqchip: armada-370-xp: Setup a chained handler for the MPIC") Cc: <stable@vger.kernel.org> # v3.15+ Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Link: https://lkml.kernel.org/r/1411643839-64925-2-git-send-email-jaz@semihalf.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
3930115e0dd67f61b3b1882c7a34d0baeff1bb4c |
|
07-Sep-2014 |
Alexander Gordeev <agordeev@redhat.com> |
irqchip: armada-370-xp: Remove arch_msi_check_device() Move MSI checks from arch_msi_check_device() to arch_setup_msi_irqs(). This makes the code more compact and allows removing arch_msi_check_device() from generic MSI code. Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jason Cooper <jason@lakedaemon.net> CC: Thomas Gleixner <tglx@linutronix.de>
|
e89c6a06b876239161653da84dbb2a0e243768b8 |
|
26-Aug-2014 |
Marc Zyngier <marc.zyngier@arm.com> |
irqchip: armada-370-xp: Convert to handle_domain_irq Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://lkml.kernel.org/r/1409047421-27649-7-git-send-email-marc.zyngier@arm.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
b73842b75646da3810d6e1e161f223a288c64bd8 |
|
30-May-2014 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
irqchip: armada-370-xp: Mask all interrupts during initialization. Until now, the irq-armada-370-xp irqchip driver was not masking all interrupts at initialization. While in most cases this is not a problem because the bootloader has probably masked all interrupts, it becomes a problem when you use kexec: you're in kernel A, with many interrupts enabled, and then kexec into kernel B, without going through the bootloader. So during the boot process, if an interrupt occurs while the corresponding driver has not been loaded, you would get spurious interrupts. This commit fixes that by ensuring all interrupts are properly masked when the irqchip driver is initialized. Note that interrupt masking takes place at two level: at the global level (main_int_base) and at the per-CPU level (per_cpu_int_base). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1401481098-23326-6-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
d7df84b3cecad4c768e4065d1d61b2f8fd02b7fa |
|
14-Apr-2014 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
irqchip: irq-armada-370-xp: Use cpu notifier to initialize secondary CPUs Some irqchip initialization must be done on secondary CPUs. On mvebu platforms, this is currently achieved by having the arch/arm/mach-mvebu/platsmp.c code directly call into a function exported by the irqchip driver, which isn't really nice. This commit changes this by using the same solution as the one used in the GIC driver: the irqchip driver registers a CPU notifier, which is used to do the secondary CPU IRQ initialization. This way, the irqchip driver is completely autonomous, and the function no longer needs to be exposed from the irqchip driver to the SoC code. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397483648-26611-6-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
ef37d337e1d37bd84ccaa5811a8d1f00f8b3677c |
|
14-Apr-2014 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
irqchip: irq-armada-370-xp: Do the set_smp_cross_call() in the driver Instead of having the SoC code in arch/arm/mach-mvebu/platsmp.c do the set_smp_cross_call() to register the IPI-triggering function, it makes more sense to do exactly what the GIC driver is doing: let the irqchip driver do it. This way, it avoids having to expose the armada_mpic_send_doorbell() function between the irqchip driver and the SoC code. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397483648-26611-5-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
8cc3cfc5ccf1680b7c88f874912b6bec2797b76b |
|
04-Mar-2014 |
Thomas Gleixner <tglx@linutronix.de> |
irqchip: armanda: Sanitize set_irq_affinity() The set_irq_affinity() function has two issues: 1) It has no protection against selecting an offline cpu from the given mask. 2) It pointlessly restricts the affinity masks to have a single cpu set. This collides with the irq migration code of arm. irq affinity is set to core 3 core 3 goes offline migration code sets mask to cpu_online_mask and calls the irq_set_affinity() callback of the irq_chip which fails due to bit 0,1,2 set. So instead of doing silly for_each_cpu() loops just pick any bit of the mask which intersects with the online mask. Get rid of fiddling with the default_irq_affinity as well. [ Gregory: Fixed the access to the routing register ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@elte.hu> Link: http://lkml.kernel.org/r/20140304203101.088889302@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
ff3c664505bf8a8334bca5045e87b85cfe4d2277 |
|
18-Apr-2014 |
Neil Greatorex <neil@fatboyfat.co.uk> |
irqchip: armada-370-xp: Fix releasing of MSIs Store the value of d->hwirq in a local variable as the real value is wiped out by calling irq_dispose_mapping. Without this patch, the armada_370_xp_free_msi function would always free MSI#0, no matter what was passed to it. Fixes: 31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support') Cc: <stable@vger.kernel.org> # v3.13+ Signed-off-by: Neil Greatorex <neil@fatboyfat.co.uk> Link: https://lkml.kernel.org/r/1397823593-1932-4-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-4-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
830cbe4b7a918613276aa3d3b28d24410623f92c |
|
18-Apr-2014 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
irqchip: armada-370-xp: implement the ->check_device() msi_chip operation Until now, we were leaving the ->check_device() msi_chip operation empty, which leads the PCI core to believe that we support both MSI and MSI-X. In fact, we do not support MSI-X, so we have to tell this to the PCI core by providing an implementation of this operation. Fixes: 31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support') Cc: <stable@vger.kernel.org> # v3.13+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-3-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <neil@fatboyfat.co.uk> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
da343fc776e0bcb238b65d9d24610819b95d0ef4 |
|
18-Apr-2014 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
irqchip: armada-370-xp: fix invalid cast of signed value into unsigned variable The armada_370_xp_alloc_msi() function returns a signed int, which is negative on error. However, we store the return value into an irq_hw_number_t, which is unsigned. Therefore, we actually never test if armada_370_xp_alloc_msi() returns an error or not, which may lead us to use hwirq numbers of as 0xffffffe4 (when armada_370_xp_alloc_msi() returns -ENOSPC). This commit fixes that by storing the return value of armada_370_xp_alloc_msi() in a signed variable. Fixes: 31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 ('irqchip: armada-370-xp: implement MSI support') Cc: <stable@vger.kernel.org> # v3.13+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397823593-1932-2-git-send-email-thomas.petazzoni@free-electrons.com Tested-by: Neil Greatorex <neil@fatboyfat.co.uk> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
8783dd3a37a5853689e1a8fa728827a50905b912 |
|
05-Mar-2014 |
Stephen Boyd <sboyd@codeaurora.org> |
irqchip: Remove asmlinkage from static functions LTO patches add __visible to the asmlinkage define, causing compilation warnings like: drivers/irqchip/irq-gic.c:283:1: warning: 'externally_visible' attribute have effect only on public objects [-Wattributes] Drop asmlinkage here to avoid such warnings. Reported-by: Olof's autobuilder <build@lixom.net> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Cc: linux-arm-kernel@lists.infradead.org Cc: khilman@linaro.org Cc: Russell King <linux@arm.linux.org.uk> Cc: Josh Cartwright <joshc@codeaurora.org> Cc: Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/1393980030-17770-1-git-send-email-sboyd@codeaurora.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
bc69b8adfe221def02ea10f7b9ab32e80195334c |
|
10-Feb-2014 |
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> |
irqchip: armada-370-xp: Setup a chained handler for the MPIC The new Armada 375 and Armada 38x Marvell SoCs are based on Cortex-A9 CPU cores and use the ARM GIC as their main interrupt controller. However, for various purposes (wake-up from suspend, MSI interrupts), they have kept a separate MPIC interrupt controller, acting as a slave to the GIC. This MPIC was already used as the primary controller on previous Marvell SoCs, so this commit extends the existing driver to allow the MPIC to be used as a GIC slave. Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
9b8cf779f93bc48c0f12ef71e5bc90fd92322656 |
|
10-Feb-2014 |
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> |
irqchip: armada-370-xp: Add helper for the MSI IRQ handling Introduce a helper function to handle the MSI interrupts. This makes the code more readable. In addition, this will allow to introduce a chained IRQ handler mechanism, which is needed in situations where the MPIC is used as a slave to another interrupt controller. Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
19e61d41404fe4094c2d54943dbf883d9bbca864 |
|
20-Jan-2014 |
Arnaud Ebalard <arno@natisbad.org> |
ARM: mvebu: fix compilation warning on Armada 370 (i.e. non-SMP) The following appears during compilation for an Armada 370 target because 'irq_controller_lock' is used only when CONFIG_SMP is enabled: drivers/irqchip/irq-armada-370-xp.c:62:8: warning: 'irq_controller_lock' defined but not used [-Wunused-variable] Fix that warning by moving declaration of 'irq_controller_lock' inside existing #ifdef. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
c7f7bd4a136e4b02dd2a66bf95aec545bd93e8db |
|
25-Nov-2013 |
Lior Amsalem <alior@marvell.com> |
irqchip: armada-370-xp: fix MSI race condition In the Armada 370/XP driver, when we receive an IRQ 1, we read the list of doorbells that caused the interrupt from register ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS. This gives the list of MSIs that were generated. However, instead of acknowledging only the MSIs that were generated, we acknowledge *all* the MSIs, by writing ~MSI_DOORBELL_MASK in the ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register. This creates a race condition: if a new MSI that isn't part of the ones read into the temporary "msimask" variable is fired before we acknowledge all MSIs, then we will simply loose it. It is important to mention that this ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register has the following behavior: "A CPU write of 0 clears the bits in this field. A CPU write of 1 has no effect". This is what allows us to simply write ~msimask to acknoledge the handled MSIs. Notice that the same problem is present in the IPI implementation, but it is fixed as a separate patch, so that this IPI fix can be pushed to older stable versions as appropriate (all the way to 3.8), while the MSI code only appeared in 3.13. Signed-off-by: Lior Amsalem <alior@marvell.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
a6f089e95b1e08cdea9633d50ad20aa5d44ba64d |
|
25-Nov-2013 |
Lior Amsalem <alior@marvell.com> |
irqchip: armada-370-xp: fix IPI race condition In the Armada 370/XP driver, when we receive an IRQ 0, we read the list of doorbells that caused the interrupt from register ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS. This gives the list of IPIs that were generated. However, instead of acknowledging only the IPIs that were generated, we acknowledge *all* the IPIs, by writing ~IPI_DOORBELL_MASK in the ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register. This creates a race condition: if a new IPI that isn't part of the ones read into the temporary "ipimask" variable is fired before we acknowledge all IPIs, then we will simply loose it. This is causing scheduling hangs on SMP intensive workloads. It is important to mention that this ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS register has the following behavior: "A CPU write of 0 clears the bits in this field. A CPU write of 1 has no effect". This is what allows us to simply write ~ipimask to acknoledge the handled IPIs. Notice that the same problem is present in the MSI implementation, but it will be fixed as a separate patch, so that this IPI fix can be pushed to older stable versions as appropriate (all the way to 3.8), while the MSI code only appeared in 3.13. Signed-off-by: Lior Amsalem <alior@marvell.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: stable@vger.kernel.org # v3.8+ Fixes: 344e873e5657e8dc0 'arm: mvebu: Add IPI support via doorbells' Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
31f614edb726fcc4d5aa0f2895fbdec9b04a3ca4 |
|
09-Aug-2013 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
irqchip: armada-370-xp: implement MSI support This commit introduces the support for the MSI interrupts in the armada-370-xp interrupt controller driver. It registers an MSI chip to the MSI chip registry, which will be used by the Marvell PCIe host controller driver. The MSI interrupts use the 16 high doorbells, and are therefore notified using IRQ1 of the main interrupt controller. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
627dfcc249e2eae07982272808ad560592e730e0 |
|
09-Aug-2013 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
irqchip: armada-370-xp: properly request resources Instead of using of_iomap(), we now use of_address_to_resource(), request_mem_region() and ioremap(). This allows the corresponding I/O regions to be properly requested and visible in /proc/iomem. The main motivation for this change is that the introduction of the MSI support requires us to get the physical address of the main interrupt controller registers, so we will need the corresponding 'struct resource' anyway. We also take this opportunity to change a panic() to BUG_ON(), in order to be consistent with the rest of the driver. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Daniel Price <daniel.price@gmail.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
5ec69017cc944f3ed88362d4b60818713a45e616 |
|
09-Apr-2013 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
irqchip: armada-370-xp: slightly cleanup irq controller driver In preparation for the introduction of MSI support in the IRQ controller driver, we clarify the implementation of IPI using additional defines for the manipulation of doorbells. Just like IPIs are implemented using doorbells, MSIs will also use doorbells, so it makes sense to do this preparatory cleanup first. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
b313ada8c7a45e37e270bcaafef3f455fa9f4abf |
|
09-Apr-2013 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
irqchip: armada-370-xp: move IRQ handler to avoid forward declaration If we move the IRQ handler function above the initialization function, we avoid a forward declaration. This wasn't done as part of the previous commit, in order to increase the readibility of the previous commit, who was also moving the IRQ controller driver from arch/arm to drivers/irqchip. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|
9339d432fdf4b492d2209316791b6e54cdae0242 |
|
09-Apr-2013 |
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
irqchip: move IRQ driver for Armada 370/XP When the Marvell Armada 370/XP support was included in the kernel, the drivers/irqchip/ directory didn't exist and the minimal infrastructure in it also didn't exist. Now that we have those things in place, we move the Armada 370/XP IRQ controller driver from arch/arm/mach-mvebu/irq-armada-370-xp.c to drivers/irqchip/irq-armada-370-xp.c. Note in order to reduce code movement and therefore ease the review of this patch, we intentionally introduce a forward declaration of armada_370_xp_handle_irq(). It is in fact not needed because this handler can now simply be implemented before armada_370_xp_mpic_of_init(). That will be done in the next commit. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
|