Re: iio: ad7192: Pending IRQ on SDO/RDY causing retrigger of interrupt handler and missing every sample

[Lars-Peter Clausen]

On 4/5/23 06:49, Nuno Sá wrote:
> [...]
> I just tested the patch, but, at least on the platform I'm working on
> (I.MX6), it does not
> solve the issue.
> Whereas the thread describes the very same issue I am experiencing, I
> am not sure
> IRQ_DISABLE_UNLAZY would have any impact. By reading CPU registers I see
> I was expecting to have. AFAIU, the lazy approach would be the responsible for
> this behavior because when you call disable_irq() it does not really mask the
> IRQ in HW. Just marks it as disabled and if another IRQ event comes set's it to
> PENDING and only then masks at HW level... If we "unlazy" the IRQ, we should
> mask the IRQ right away so I would expect not to have any pending IRQ...
>
> > the IRQ line disabled at the hardware level, but when the IRQ flag of
> > the processor
> > is set (and this happens even if the interrupt is masked in HW), the
> > interrupt is immediately
> > triggered anyway.
> > (I see GPIOx_IMR cleared, so interrupt is masked, but GPIOx_ISR set. As soon
> > as
> > enable_irq() is called the interrupt is triggered. Just by clearing
> > GPIOx_ISR before
> > enable_irq() solves the issue. I might share a few debug printk).

This sounds to me that the GPIO driver should implement an 
`irq_enable()` callback where it clears the pending bits before 
unmasking. This is consistent with what other GPIO IRQ drivers do.