From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753895AbcAFLDM (ORCPT ); Wed, 6 Jan 2016 06:03:12 -0500 Received: from terminus.zytor.com ([198.137.202.10]:49324 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752950AbcAFKj6 (ORCPT ); Wed, 6 Jan 2016 05:39:58 -0500 Date: Wed, 6 Jan 2016 02:39:37 -0800 From: tip-bot for Sekhar Nori Message-ID: Cc: linux-kernel@vger.kernel.org, nsekhar@ti.com, marc.zyngier@arm.com, john.ogness@linutronix.de, tglx@linutronix.de, mingo@kernel.org, tony@atomide.com, balbi@ti.com, jason@lakedaemon.net, hpa@zytor.com Reply-To: balbi@ti.com, tony@atomide.com, hpa@zytor.com, jason@lakedaemon.net, mingo@kernel.org, tglx@linutronix.de, marc.zyngier@arm.com, john.ogness@linutronix.de, nsekhar@ti.com, linux-kernel@vger.kernel.org In-Reply-To: <9c78a6db02ac55f7af7371b417b6e414d2c3095b.1450188128.git.nsekhar@ti.com> References: <9c78a6db02ac55f7af7371b417b6e414d2c3095b.1450188128.git.nsekhar@ti.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:irq/core] irqchip/omap-intc: Add support for spurious irq handling Git-Commit-ID: d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d Gitweb: http://git.kernel.org/tip/d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d Author: Sekhar Nori AuthorDate: Tue, 15 Dec 2015 19:56:12 +0530 Committer: Thomas Gleixner CommitDate: Wed, 6 Jan 2016 11:35:13 +0100 irqchip/omap-intc: Add support for spurious irq handling Under some conditions, irq sorting procedure used by INTC can go wrong resulting in a spurious irq getting reported. If this condition is not handled, it results in endless stream of: unexpected IRQ trap at vector 00 messages from ack_bad_irq() Handle the spurious interrupt condition in omap-intc driver to prevent this. Measurements using kernel function profiler on AM335x EVM running at 720MHz show that after this patch omap_intc_handle_irq() takes about 37.4us against 34us before this patch. Signed-off-by: Sekhar Nori Acked-by: Tony Lindgren Cc: John Ogness Cc: Felipe Balbi Cc: Jason Cooper Cc: Marc Zyngier Link: http://lkml.kernel.org/r/9c78a6db02ac55f7af7371b417b6e414d2c3095b.1450188128.git.nsekhar@ti.com Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner --- drivers/irqchip/irq-omap-intc.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c index ed25175..9d1bcfc 100644 --- a/drivers/irqchip/irq-omap-intc.c +++ b/drivers/irqchip/irq-omap-intc.c @@ -47,6 +47,7 @@ #define INTC_ILR0 0x0100 #define ACTIVEIRQ_MASK 0x7f /* omap2/3 active interrupt bits */ +#define SPURIOUSIRQ_MASK (0x1ffffff << 7) #define INTCPS_NR_ILR_REGS 128 #define INTCPS_NR_MIR_REGS 4 @@ -329,11 +330,35 @@ static int __init omap_init_irq(u32 base, struct device_node *node) static asmlinkage void __exception_irq_entry omap_intc_handle_irq(struct pt_regs *regs) { + extern unsigned long irq_err_count; u32 irqnr; irqnr = intc_readl(INTC_SIR); + + /* + * A spurious IRQ can result if interrupt that triggered the + * sorting is no longer active during the sorting (10 INTC + * functional clock cycles after interrupt assertion). Or a + * change in interrupt mask affected the result during sorting + * time. There is no special handling required except ignoring + * the SIR register value just read and retrying. + * See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K + * + * Many a times, a spurious interrupt situation has been fixed + * by adding a flush for the posted write acking the IRQ in + * the device driver. Typically, this is going be the device + * driver whose interrupt was handled just before the spurious + * IRQ occurred. Pay attention to those device drivers if you + * run into hitting the spurious IRQ condition below. + */ + if (unlikely((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK)) { + pr_err_once("%s: spurious irq!\n", __func__); + irq_err_count++; + omap_ack_irq(NULL); + return; + } + irqnr &= ACTIVEIRQ_MASK; - WARN_ONCE(!irqnr, "Spurious IRQ ?\n"); handle_domain_irq(domain, irqnr, regs); }