From: dushistov@mail.ru (Evgeniy Dushistov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] fix for certain sequnce of request_irq can cause irq storm
Date: Sat, 26 Jul 2014 19:56:59 +0400 [thread overview]
Message-ID: <20140726155659.GA22977@fifteen> (raw)
The problem is that hardware handled by arm/plat-orion/gpio.c,
require ack for edge irq, and no ack for level irq.
The code handle this issue, by two "struct irq_chip_type" per
one "struct irq_chip_generic". For one "struct irq_chip_generic"
irq_ack pointer is setted, for another it is NULL.
But we have only one mask_cache per two "struct irq_chip_type".
So if we
1)unmask interrupt A for "edge type" trigger,
2)unmask interrupt B for "level type" trigger,
3)unmask interrupt C for "edge type",
we, because of usage of generic irq_gc_mask_clr_bit/irq_gc_mask_set_bit,
have hardware configured to trigger interrupt B on "edge type",
because of shared mask_cache. But kernel think that B is "level type",
so when interrupt B occur via "edge" reason, we don't ack it,
and B triggered again and again.
Signed-off-by: Evgeniy A. Dushistov <dushistov@mail.ru>
---
arch/arm/plat-orion/gpio.c | 36 ++++++++++++++++++++++++++++++++----
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-orion/gpio.c b/arch/arm/plat-orion/gpio.c
index b61a3bc..e048f61 100644
--- a/arch/arm/plat-orion/gpio.c
+++ b/arch/arm/plat-orion/gpio.c
@@ -497,6 +497,34 @@ static void orion_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
#define orion_gpio_dbg_show NULL
#endif
+static void orion_gpio_unmask_irq(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+ u32 reg_val;
+ u32 mask = d->mask;
+
+ irq_gc_lock(gc);
+ reg_val = irq_reg_readl(gc->reg_base + ct->regs.mask);
+ reg_val |= mask;
+ irq_reg_writel(reg_val, gc->reg_base + ct->regs.mask);
+ irq_gc_unlock(gc);
+}
+
+static void orion_gpio_mask_irq(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+ u32 mask = d->mask;
+ u32 reg_val;
+
+ irq_gc_lock(gc);
+ reg_val = irq_reg_readl(gc->reg_base + ct->regs.mask);
+ reg_val &= ~mask;
+ irq_reg_writel(reg_val, gc->reg_base + ct->regs.mask);
+ irq_gc_unlock(gc);
+}
+
void __init orion_gpio_init(struct device_node *np,
int gpio_base, int ngpio,
void __iomem *base, int mask_offset,
@@ -565,8 +593,8 @@ void __init orion_gpio_init(struct device_node *np,
ct = gc->chip_types;
ct->regs.mask = ochip->mask_offset + GPIO_LEVEL_MASK_OFF;
ct->type = IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW;
- ct->chip.irq_mask = irq_gc_mask_clr_bit;
- ct->chip.irq_unmask = irq_gc_mask_set_bit;
+ ct->chip.irq_mask = orion_gpio_mask_irq;
+ ct->chip.irq_unmask = orion_gpio_unmask_irq;
ct->chip.irq_set_type = gpio_irq_set_type;
ct->chip.name = ochip->chip.label;
@@ -575,8 +603,8 @@ void __init orion_gpio_init(struct device_node *np,
ct->regs.ack = GPIO_EDGE_CAUSE_OFF;
ct->type = IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING;
ct->chip.irq_ack = irq_gc_ack_clr_bit;
- ct->chip.irq_mask = irq_gc_mask_clr_bit;
- ct->chip.irq_unmask = irq_gc_mask_set_bit;
+ ct->chip.irq_mask = orion_gpio_mask_irq;
+ ct->chip.irq_unmask = orion_gpio_unmask_irq;
ct->chip.irq_set_type = gpio_irq_set_type;
ct->handler = handle_edge_irq;
ct->chip.name = ochip->chip.label;
--
1.8.5.5
--
/Evgeniy
next reply other threads:[~2014-07-26 15:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-26 15:56 Evgeniy Dushistov [this message]
2014-07-26 16:56 ` [PATCH] fix for certain sequnce of request_irq can cause irq storm Andrew Lunn
2014-07-26 17:12 ` Evgeniy Dushistov
2014-10-21 14:15 ` Thomas Petazzoni
2014-10-21 15:20 ` Evgeniy Dushistov
2014-10-21 15:37 ` Thomas Petazzoni
2014-10-21 18:54 ` Evgeniy Dushistov
2014-07-26 17:45 ` Andrew Lunn
2014-07-26 18:48 ` Evgeniy Dushistov
2014-10-15 0:08 ` Evgeniy Dushistov
2014-10-15 15:51 ` Jason Cooper
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=20140726155659.GA22977@fifteen \
--to=dushistov@mail.ru \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.