[PATCHv2 02/10] ARM: vic: MULTI_IRQ_HANDLER handler
Russell King - ARM Linux
linux at arm.linux.org.uk
Thu Nov 3 23:51:36 EST 2011
On Thu, Nov 03, 2011 at 01:29:08PM +0100, Linus Walleij wrote:
> No, if we receive another IRQ *after* the read of the register was the
> question, right?
>
> Just replace
>
> stat &= ~(1 << irq);
>
> with a second
>
> stat = readl_relaxed(vic->base + VIC_IRQ_STATUS);
>
> It'll work just fine, the IRQ line should be low when you read
> it the second time, else it is probably fully proper to call
> the IRQ handler again anyway.
It depends on what kind of behaviour you want. There are two solutions:
stat = readl_relaxed(vic->base + VIC_IRQ_STATUS);
while (stat) {
irq = ffs(stat) - 1;
handle_irq(irq);
stat = readl_relaxed(vic->base + VIC_IRQ_STATUS);
}
This gives priority to the lowest numbered interrupts; if these get stuck
then they can exclude higher numbered interrupts. This is what we
implement in the assembly code versions, and as far as I know, no one has
ever complained about that behaviour.
stat = readl_relaxed(vic->base + VIC_IRQ_STATUS);
while (stat) {
while (stat) {
irq = ffs(stat) - 1;
stat &= ~(1 << irq);
handle_irq(irq);
}
stat = readl_relaxed(vic->base + VIC_IRQ_STATUS);
}
This ensures that we process all interrupts found pending before we
re-check for any new interrupts pending. Arguably this is a much
fairer implementation (and may mean if things get irrevokably stuck,
things like sysrq via the console uart may still work.)
More information about the devicetree-discuss
mailing list