Re: [PATCH 3/3] iio: st_sensors: Use level interrupts

[Jonathan Cameron <jic23@kernel.org>]

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
>> <leonard.crestez@intel.com> 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@linaro.org>
>>> Cc: Giuseppe Barba <giuseppe.barba@st.com>
>>> Cc: Denis Ciocca <denis.ciocca@st.com>
>>> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
>>
>> 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
>