On 03/20/2017 06:21 AM, Ladislav Michl wrote: > On Thu, Mar 16, 2017 at 12:17:45PM -0700, Tony Lindgren wrote: >> Hmm maybe we need to flush posted writes when re-enabling the GPIO interrupts? >> >> Below is an untested patch that might help if that's the case. > > Unfortunately that's not the case. Even writing set&clear version of > interrupt demux handler did not make it any better. And idea from > ancient patch I initially sent is not easily extensible when we > need to trigger interrupt on both edges. So far I'm clueless... So, just to be sure - can you reproduce it with LKML? As per code, the possible problem could be with double acking of edge irqs (theoretically): - omap_gpio_irq_handler - "isr" = read irq status - omap_clear_gpio_irqbank(bank, isr_saved & ~level_mask); --- clear edge status, so new irq can be accepted - loop while "isr" generic_handle_irq() - handle_edge_irq() - desc->irq_data.chip->irq_ack(&desc->irq_data); - omap_gpio_ack_irq() it might be that at this moment edge IRQ was triggered again and it will be cleared. just as an experiment, could you try to update omap_gpio_ack_irq() as below: if (irq type is not edge) omap_clear_gpio_irqstatus(bank, offset); -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
