On Wed, Apr 26, 2017 at 11:23 AM, Gregory CLEMENT
<gregory.clement@xxxxxxxxxxxxxxxxxx> wrote:
> On lun., avril 24 2017, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>>> + spin_lock_irqsave(&info->irq_lock, flags);
>>> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
>>> + /* Manage only the interrupt that was enabled */
>>> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
>>> + spin_unlock_irqrestore(&info->irq_lock, flags);
>>> + while (status) {
>>> + u32 hwirq = ffs(status) - 1;
>>> + u32 virq = irq_find_mapping(d, hwirq +
>>> + i * GPIO_PER_REG);
>>> +
>>> + generic_handle_irq(virq);
>>> + status &= ~BIT(hwirq);
>>> + }
>>
>> You hae a problem here is a new IRQ appears while you are inside
>> of this loop. You need to re-read the status register for each iteration
>> (and &= with the IRQ_EN I guess).
>
> If a new IRQ appears during the loop, then the irq handler will be
> called again because the cause of this new IRQ won't have been acked
> yet. So I think we're fine here.
That *might* be true. It is true if the CPU gets a level IRQ from the
GPIO controller. But hardware dealing with edge IRQs can be very
quirky here, and just send a pulse on the line to the CPU if the
CPU-bound IRQ is also just edge triggered. And then that
pulse would potentially be missed while dealing with the current
IRQ in this handler. (And exactly this happened to us on other
hardware.)
But anyway: why let the irq handler be called again if you can avoid it?
You would avoid a double context switch by just checking it again
in the loop before exiting the handler. And that can be really nice
for latency-sensitive stuff.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
