| Message ID | 1390516686-2224-4-git-send-email-sebastian.hesselbarth@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jan 23, 2014 at 11:38:06PM +0100, Sebastian Hesselbarth wrote: > Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in > IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear > them before unmask. This installs an .irq_enable callback to ensure stale > irqs are cleared before initial unmask. I'm not sure if putting this in irq_enable is correct. I think this should only happen at irq_startup. The question boils down to what is supposed to happen with this code sequence: disable_irq(..); write(.. something to cause an interrupt edge ..); .. synchronize .. enable_irq(..); Do we get the interrupt or not? I found this message from Linus long ago: http://yarchive.net/comp/linux/edge_triggered_interrupts.html > Btw, the "disable_irq()/enable_irq()" subsystem has been written so that > when you disable an edge-triggered interrupt, and the edge happens while > the interrupt is disabled, we will re-play the interrupt at enable time. > Exactly so that drivers can have an easier time and don't have to > normally worry about whether something is edge or level-triggered. And found this note in Documentation/DocBook/genericirq.tmpl: > This prevents losing edge interrupts on hardware which does > not store an edge interrupt event while the interrupt is disabled at > the hardware level. So I think it is very clear that the chip driver should not discard edges that happened while the interrupt was disabled. Regards, Jason
On 01/23/2014 11:52 PM, Jason Gunthorpe wrote: > On Thu, Jan 23, 2014 at 11:38:06PM +0100, Sebastian Hesselbarth wrote: >> Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in >> IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear >> them before unmask. This installs an .irq_enable callback to ensure stale >> irqs are cleared before initial unmask. > > I'm not sure if putting this in irq_enable is correct. I think this > should only happen at irq_startup. > > The question boils down to what is supposed to happen with this code > sequence: > > disable_irq(..); > write(.. something to cause an interrupt edge ..); > .. synchronize .. > enable_irq(..); > > Do we get the interrupt or not? Jason, I get the point and actually I'd chosen .irq_enable because using .irq_startup didn't work. I rechecked this and now it works.. maybe it is getting too late for me. I'll send a v2 of this patch shortly. Sebastian > I found this message from Linus long ago: > http://yarchive.net/comp/linux/edge_triggered_interrupts.html >> Btw, the "disable_irq()/enable_irq()" subsystem has been written so that >> when you disable an edge-triggered interrupt, and the edge happens while >> the interrupt is disabled, we will re-play the interrupt at enable time. >> Exactly so that drivers can have an easier time and don't have to >> normally worry about whether something is edge or level-triggered. > > And found this note in Documentation/DocBook/genericirq.tmpl: > >> This prevents losing edge interrupts on hardware which does >> not store an edge interrupt event while the interrupt is disabled at >> the hardware level. > > So I think it is very clear that the chip driver should not discard > edges that happened while the interrupt was disabled. > > Regards, > Jason >
On Thu, Jan 23, 2014 at 03:52:08PM -0700, Jason Gunthorpe wrote: > On Thu, Jan 23, 2014 at 11:38:06PM +0100, Sebastian Hesselbarth wrote: > > Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in > > IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear > > them before unmask. This installs an .irq_enable callback to ensure stale > > irqs are cleared before initial unmask. > > I'm not sure if putting this in irq_enable is correct. I think this > should only happen at irq_startup. > > The question boils down to what is supposed to happen with this code > sequence: > > disable_irq(..); > write(.. something to cause an interrupt edge ..); > .. synchronize .. > enable_irq(..); > > Do we get the interrupt or not? The answer is... yes, the interrupt should be delivered after the interrupt is re-enabled. > I found this message from Linus long ago: > http://yarchive.net/comp/linux/edge_triggered_interrupts.html > > Btw, the "disable_irq()/enable_irq()" subsystem has been written so that > > when you disable an edge-triggered interrupt, and the edge happens while > > the interrupt is disabled, we will re-play the interrupt at enable time. > > Exactly so that drivers can have an easier time and don't have to > > normally worry about whether something is edge or level-triggered. > > And found this note in Documentation/DocBook/genericirq.tmpl: > > > This prevents losing edge interrupts on hardware which does > > not store an edge interrupt event while the interrupt is disabled at > > the hardware level. > > So I think it is very clear that the chip driver should not discard > edges that happened while the interrupt was disabled. Correct.
diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c index 1f636f719065..80b13c1a0947 100644 --- a/drivers/irqchip/irq-orion.c +++ b/drivers/irqchip/irq-orion.c @@ -123,6 +123,18 @@ static void orion_bridge_irq_handler(unsigned int irq, struct irq_desc *desc) } } +/* + * Bridge IRQ_CAUSE is asserted regardless of IRQ_MASK register. + * To avoid interrupt events on stale irqs, we clear them before unmask. + */ +static void orion_bridge_irq_enable(struct irq_data *d) +{ + struct irq_chip_type *ct = irq_data_get_chip_type(d); + + ct->chip.irq_ack(d); + ct->chip.irq_unmask(d); +} + static int __init orion_bridge_irq_init(struct device_node *np, struct device_node *parent) { @@ -176,6 +188,7 @@ static int __init orion_bridge_irq_init(struct device_node *np, gc->chip_types[0].regs.ack = ORION_BRIDGE_IRQ_CAUSE; gc->chip_types[0].regs.mask = ORION_BRIDGE_IRQ_MASK; + gc->chip_types[0].chip.irq_enable = orion_bridge_irq_enable; gc->chip_types[0].chip.irq_ack = irq_gc_ack_clr_bit; gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit; gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear them before unmask. This installs an .irq_enable callback to ensure stale irqs are cleared before initial unmask. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> --- Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- drivers/irqchip/irq-orion.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)