On 05/04/2016 05:34 PM, Linus Walleij wrote: > On Wed, May 4, 2016 at 9:35 AM, Jonathan Cameron <jic23@xxxxxxxxxx> 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 -- 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
