From patchwork Tue Dec 15 14:26:12 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sekhar Nori X-Patchwork-Id: 58444 Delivered-To: patch@linaro.org Received: by 10.112.89.199 with SMTP id bq7csp71959lbb; Tue, 15 Dec 2015 06:26:39 -0800 (PST) X-Received: by 10.66.254.234 with SMTP id al10mr54969510pad.87.1450189599526; Tue, 15 Dec 2015 06:26:39 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x16si2212766pfa.116.2015.12.15.06.26.39; Tue, 15 Dec 2015 06:26:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965291AbbLOO0f (ORCPT + 28 others); Tue, 15 Dec 2015 09:26:35 -0500 Received: from arroyo.ext.ti.com ([192.94.94.40]:51466 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965273AbbLOO0b (ORCPT ); Tue, 15 Dec 2015 09:26:31 -0500 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id tBFEQGv6011772; Tue, 15 Dec 2015 08:26:16 -0600 Received: from DFLE73.ent.ti.com (dfle73.ent.ti.com [128.247.5.110]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id tBFEQGm1015359; Tue, 15 Dec 2015 08:26:16 -0600 Received: from dlep32.itg.ti.com (157.170.170.100) by DFLE73.ent.ti.com (128.247.5.110) with Microsoft SMTP Server id 14.3.224.2; Tue, 15 Dec 2015 08:26:16 -0600 Received: from psplinux063.india.ti.com (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id tBFEQD9h030833; Tue, 15 Dec 2015 08:26:13 -0600 From: Sekhar Nori To: Tony Lindgren , Thomas Gleixner , Jason Cooper , Marc Zyngier CC: John Ogness , Felipe Balbi , Linux OMAP Mailing List , Subject: [PATCH v3] irqchip: omap-intc: add support for spurious irq handling Date: Tue, 15 Dec 2015 19:56:12 +0530 Message-ID: <9c78a6db02ac55f7af7371b417b6e414d2c3095b.1450188128.git.nsekhar@ti.com> X-Mailer: git-send-email 2.6.3 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- v3: add unlikely(), add profiling information to commit message. v2: increment error irq counter, use pr_err_once, add a comment on tips to debug spurious irq condition. This patch results in a checkpatch warning about extern definition of irq_err_count, but looks like thats the prevalent method of accessing that counter. drivers/irqchip/irq-omap-intc.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c index 8587d0f8d8c0..f6cb1b8bb981 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 @@ -330,11 +331,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); }