[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a27872f0-6359-2c73-002c-2550ef6a9a2b@kernel.org>
Date: Sun, 29 May 2016 20:29:40 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Crestez Dan Leonard <leonard.crestez@...el.com>,
Linus Walleij <linus.walleij@...aro.org>
Cc: "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Peter Meerwald-Stadler <pmeerw@...erw.net>,
Daniel Baluta <daniel.baluta@...el.com>,
Giuseppe Barba <giuseppe.barba@...com>,
Denis Ciocca <denis.ciocca@...com>
Subject: Re: [PATCH 3/3] iio: st_sensors: Use level interrupts
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@...el.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@...aro.org>
>>> Cc: Giuseppe Barba <giuseppe.barba@...com>
>>> Cc: Denis Ciocca <denis.ciocca@...com>
>>> Signed-off-by: Crestez Dan Leonard <leonard.crestez@...el.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
>
Powered by blists - more mailing lists