On 24/05/16 13:35, Crestez Dan Leonard wrote: > On 05/24/2016 02:40 PM, Linus Walleij wrote: >> On Fri, May 13, 2016 at 8:43 PM, Crestez Dan Leonard >> <[email protected]> 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 <[email protected]> >>> Cc: Giuseppe Barba <[email protected]> >>> Cc: Denis Ciocca <[email protected]> >>> Signed-off-by: Crestez Dan Leonard <[email protected]> >> >> 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. That's precisely the question I raised way back when writing the lis3l02dq driver. Apparently someone once had a go but it never went anywhere...
Feel free to try! It would be great if possible. Jonathan >
