From patchwork Sun Apr 17 09:50:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sasha Levin X-Patchwork-Id: 65988 Delivered-To: patch@linaro.org Received: by 10.140.93.198 with SMTP id d64csp757354qge; Sun, 17 Apr 2016 02:54:58 -0700 (PDT) X-Received: by 10.98.13.77 with SMTP id v74mr42026096pfi.162.1460886874173; Sun, 17 Apr 2016 02:54:34 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id dh6si6948416pad.189.2016.04.17.02.54.33; Sun, 17 Apr 2016 02:54:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-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 stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752030AbcDQJyd (ORCPT + 3 others); Sun, 17 Apr 2016 05:54:33 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:42611 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752015AbcDQJyc (ORCPT ); Sun, 17 Apr 2016 05:54:32 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3H9sHK1013117 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 17 Apr 2016 09:54:17 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u3H9sGXS025479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 17 Apr 2016 09:54:16 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u3H9sFDX013330; Sun, 17 Apr 2016 09:54:15 GMT Received: from lappy.us.oracle.com (/10.154.169.185) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 17 Apr 2016 02:54:14 -0700 From: Sasha Levin To: stable@vger.kernel.org, stable-commits@vger.kernel.org Cc: Sekhar Nori , John Ogness , Felipe Balbi , Jason Cooper , Marc Zyngier , Thomas Gleixner , Sasha Levin Subject: [added to the 4.1 stable tree] irqchip/omap-intc: Add support for spurious irq handling Date: Sun, 17 Apr 2016 05:50:41 -0400 Message-Id: <1460886804-19372-42-git-send-email-sasha.levin@oracle.com> X-Mailer: git-send-email 2.5.0 In-Reply-To: <1460886804-19372-1-git-send-email-sasha.levin@oracle.com> References: <1460886804-19372-1-git-send-email-sasha.levin@oracle.com> X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sekhar Nori This patch has been added to the 4.1 stable tree. If you have any objections, please let us know. -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html =============== [ Upstream commit d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d ] 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 Signed-off-by: Sasha Levin --- 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 e15f107..5ba876e 100644 --- a/drivers/irqchip/irq-omap-intc.c +++ b/drivers/irqchip/irq-omap-intc.c @@ -48,6 +48,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 @@ -331,11 +332,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); }