From: Tony Lindgren <tony@atomide.com>
To: "Stefan Sørensen" <stefan.sorensen@spectralink.com>
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] ARM: OMAP2+: Use handle_fasteoi_irq for INTC interrupt handling
Date: Fri, 28 Feb 2014 09:11:12 -0800 [thread overview]
Message-ID: <20140228171111.GA15399@atomide.com> (raw)
In-Reply-To: <1393236556-12361-1-git-send-email-stefan.sorensen@spectralink.com>
* Stefan Sørensen <stefan.sorensen@spectralink.com> [140224 02:12]:
> Currently INTC interrupts are handled using handle_level_irq which
> will acknowledge the interrupt before running the handler. If a second
> interrupt is then asserted and this interrupt is disabled while
> running the first handler, the INTC will be brought into an
> inconsistent state.
Hmm care to explain a bit more here if the second interrupt you're
talking about is the same interrupt or any interrupt in the same
interrupt bank? Is this limited to GPIO interrupts?
The reason I'm asking is because of the issues we've seen earlier
with not flushing posted writes from the interrupt handlers. In
those case the interrupt on the device gets acked too late without
the read back call.
> In this state the INTC will interrupt the CPU but
> the interrupt pending registers will show no pending interrupts
> causing the CPU to take no action. This will repeat until another
> higher priority interrupt triggers, hogging the CPU.
>
> handle_fasteoi_irq does not acknowledge the interrupt before after
> running the handler, so using this for handling INTC interrupts avoid
> the above problem. This also brings the handling more in line with the
> sequence described in the TRM.
>
> Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
> ---
> arch/arm/mach-omap2/irq.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
> index e022a86..9d09914 100644
> --- a/arch/arm/mach-omap2/irq.c
> +++ b/arch/arm/mach-omap2/irq.c
> @@ -97,12 +97,6 @@ static void omap_ack_irq(struct irq_data *d)
> intc_bank_write_reg(0x1, &irq_banks[0], INTC_CONTROL);
> }
>
> -static void omap_mask_ack_irq(struct irq_data *d)
> -{
> - irq_gc_mask_disable_reg(d);
> - omap_ack_irq(d);
> -}
> -
> static void __init omap_irq_bank_init_one(struct omap_irq_bank *bank)
> {
> unsigned long tmp;
> @@ -145,9 +139,9 @@ omap_alloc_gc(void __iomem *base, unsigned int irq_start, unsigned int num)
> struct irq_chip_type *ct;
>
> gc = irq_alloc_generic_chip("INTC", 1, irq_start, base,
> - handle_level_irq);
> + handle_fasteoi_irq);
> ct = gc->chip_types;
> - ct->chip.irq_ack = omap_mask_ack_irq;
> + ct->chip.irq_eoi = omap_ack_irq;
> ct->chip.irq_mask = irq_gc_mask_disable_reg;
> ct->chip.irq_unmask = irq_gc_unmask_enable_reg;
> ct->chip.flags |= IRQCHIP_SKIP_SET_WAKE;
> --
> 1.8.5.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-02-28 17:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-24 10:09 [PATCH] ARM: OMAP2+: Use handle_fasteoi_irq for INTC interrupt handling Stefan Sørensen
2014-02-28 17:11 ` Tony Lindgren [this message]
2014-03-01 9:59 ` Sørensen, Stefan
2014-03-02 17:37 ` Tony Lindgren
2014-03-03 11:05 ` Sørensen, Stefan
2014-03-03 17:49 ` Tony Lindgren
2014-03-06 14:32 ` Sørensen, Stefan
2014-03-06 18:15 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140228171111.GA15399@atomide.com \
--to=tony@atomide.com \
--cc=linux-omap@vger.kernel.org \
--cc=stefan.sorensen@spectralink.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).