On 05/24/2016 02:40 PM, Linus Walleij wrote: > On Fri, May 13, 2016 at 8:43 PM, Crestez Dan Leonard > <leonard.crestez@xxxxxxxxx> wrote: > >> As far as I can tell DRDY for ST sensors behaves as a level rather than >> edge interrupt. Registering for IRQF_TRIGGER_RISING instead of >> IRQF_TRIGGER_HIGH mostly works except when the sampling frequency is >> high enough that new samples come before the new ones are read >> completely. In that case the interrupt line remains high, no more rising >> edges occur and the iio buffer stalls. >> >> Configuring the interrupt as IRQF_TRIGGER_HIGH makes it work as >> expected. This patch makes it so that st_sensors_trigger interrupt >> request code doesn't mangle the request flags into IRQF_TRIGGER_RISING. >> >> Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> >> Cc: Giuseppe Barba <giuseppe.barba@xxxxxx> >> Cc: Denis Ciocca <denis.ciocca@xxxxxx> >> Signed-off-by: Crestez Dan Leonard <leonard.crestez@xxxxxxxxx> > > The analysis is probably correct: the sensors will hold the line low > until the values have been read and no data is ready in the pipe. > > This is delicate when the sensors are used with GPIO controllers > as interrupt line handlers, because some of them (like mine > on Ux500) do not support level interrupts :( This might be completely crazy, but wouldn't it be possible to support gpio level interrupts purely in software? Just read the GPIO state again after the interrupt is unmasked and retrigger. This seems preferable to implementing per-driver workarounds. Perhaps it would even fit in some gpio-irqchip glue. -- Regards, Leonard -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
