Re: [PATCH 3/4] iio: st_sensors: verify interrupt event to status

[Crestez Dan Leonard <cdleonard@gmail.com>]

On 05/04/2016 05:34 PM, Linus Walleij wrote:
> On Wed, May 4, 2016 at 9:35 AM, Jonathan Cameron <jic23@kernel.org> wrote:
>> On 03/05/16 21:10, Linus Walleij wrote:
> 
>>>> Even with hardware triggers: are you sure this is correct? Shouldn't
>>>> iio_trigger_notify_done still get called even when there is nothing to do?
>>>
>>> No then the (hardware) IRQ can have come in from some other
>>> device sharing the line with the peripheral and we need to return
>>> IRQ_NONE. It's not our interrupt.
>>
>> Gah, I fouled up reviewing this.  We really need to know if it is our
>> trigger 'before' we fire off the trigger logic - any number of other
>> devices can in theory be hanging off a given trigger - none of them will
>> be able to know if it was a real trigger or not.
> 
> Ooops sorry, but the good thing is: we get to properly fix it.
> 
I've been testing with some st_sensors devices I have around and it
seems to me that triggered buffers with hardware interrupts don't
actually work properly at high sampling frequencies. It is possible for
another sample to come in before the buffer handler completes and
further interrupts will be lost.

This happens on at least LIS3DH.

It's not obvious how to handle this. Presumably the fix would be to
check STATUS_REG after reading one sample and if new values are
available schedule a new read?

This is easy to reproduce for me because I use an usb-to-i2c adapter
with high latencies. It helps if you increase the sampling_frequency but
it might still be very hard to reproduce on a direct i2c bus.

-- 
Regards,
Leonard