* [PATCH v3] irqchip: omap-intc: add support for spurious irq handling
@ 2015-12-15 14:26 ` Sekhar Nori
0 siblings, 0 replies; 6+ messages in thread
From: Sekhar Nori @ 2015-12-15 14:26 UTC (permalink / raw)
To: Tony Lindgren, Thomas Gleixner, Jason Cooper, Marc Zyngier
Cc: John Ogness, Felipe Balbi, Linux OMAP Mailing List, linux-kernel
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 <nsekhar@ti.com>
---
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(-)
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);
}
--
2.6.3
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v3] irqchip: omap-intc: add support for spurious irq handling
2015-12-15 14:26 ` Sekhar Nori
(?)
@ 2015-12-15 15:28 ` Tony Lindgren
2016-01-04 8:35 ` Sekhar Nori
-1 siblings, 1 reply; 6+ messages in thread
From: Tony Lindgren @ 2015-12-15 15:28 UTC (permalink / raw)
To: Sekhar Nori
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, John Ogness,
Felipe Balbi, Linux OMAP Mailing List, linux-kernel
* Sekhar Nori <nsekhar@ti.com> [151215 06:26]:
> 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 <nsekhar@ti.com>
Looks good to me, probably should get tagged Cc stable when
committing:
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> 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(-)
>
> 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);
> }
>
> --
> 2.6.3
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v3] irqchip: omap-intc: add support for spurious irq handling
2015-12-15 15:28 ` Tony Lindgren
@ 2016-01-04 8:35 ` Sekhar Nori
0 siblings, 0 replies; 6+ messages in thread
From: Sekhar Nori @ 2016-01-04 8:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Tony Lindgren, Jason Cooper, Marc Zyngier, John Ogness,
Felipe Balbi, Linux OMAP Mailing List, linux-kernel
Hi Thomas,
On Tuesday 15 December 2015 08:58 PM, Tony Lindgren wrote:
> * Sekhar Nori <nsekhar@ti.com> [151215 06:26]:
>> 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 <nsekhar@ti.com>
>
> Looks good to me, probably should get tagged Cc stable when
> committing:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Can you please apply this if it looks good?
Thanks,
Sekhar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v3] irqchip: omap-intc: add support for spurious irq handling
@ 2016-01-04 8:35 ` Sekhar Nori
0 siblings, 0 replies; 6+ messages in thread
From: Sekhar Nori @ 2016-01-04 8:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Tony Lindgren, Jason Cooper, Marc Zyngier, John Ogness,
Felipe Balbi, Linux OMAP Mailing List, linux-kernel
Hi Thomas,
On Tuesday 15 December 2015 08:58 PM, Tony Lindgren wrote:
> * Sekhar Nori <nsekhar@ti.com> [151215 06:26]:
>> 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 <nsekhar@ti.com>
>
> Looks good to me, probably should get tagged Cc stable when
> committing:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Can you please apply this if it looks good?
Thanks,
Sekhar
^ permalink raw reply [flat|nested] 6+ messages in thread
* [tip:irq/core] irqchip/omap-intc: Add support for spurious irq handling
2015-12-15 14:26 ` Sekhar Nori
(?)
(?)
@ 2016-01-06 10:39 ` tip-bot for Sekhar Nori
-1 siblings, 0 replies; 6+ messages in thread
From: tip-bot for Sekhar Nori @ 2016-01-06 10:39 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, nsekhar, marc.zyngier, john.ogness, tglx, mingo,
tony, balbi, jason, hpa
Commit-ID: d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d
Gitweb: http://git.kernel.org/tip/d3b421cd07e4c0d4d6c0bbd55ca169c054fc081d
Author: Sekhar Nori <nsekhar@ti.com>
AuthorDate: Tue, 15 Dec 2015 19:56:12 +0530
Committer: Thomas Gleixner <tglx@linutronix.de>
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 <nsekhar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Link: http://lkml.kernel.org/r/9c78a6db02ac55f7af7371b417b6e414d2c3095b.1450188128.git.nsekhar@ti.com
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
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);
}
^ permalink raw reply related [flat|nested] 6+ messages in thread