> > Maybe I understood the issue between the buffered reading and event generation. > > I guess it is a race here between when the device is generating the interrupt > > and when you set enable_event. I think there are two solutions: > > 1- trivial one: always read wakeup_src_reg > > 2- set hw->enable_event as first instruction in st_lsm6dsx_write_event_config() > > and roll back in case of error. > > > > Could you please try that changes and double check if you are still able to > > trigger the issue? > > [...] > $ cd /sys/bus/iio/devices/iio:device2 > $ echo 1 > events/in_accel_x_thresh_either_en > $ echo 1 > events/in_accel_x_thresh_either_value > $ echo 1 > scan_elements/in_accel_x_en > $ echo 1 > buffer/enable > > FIFO interrupts ticking in... until I trigger the first event. :-( > The event is reported correctly. The interrupt pin is staying high. > The result is the same if I enable the FIFO first. > I don't think we have a race in the driver around this, to me it looks like > something in the ism330 device should be cleared. > Could the device go into sleep or power down mode? probably a silly question..are you tracing the interrupt line with an oscilloscope or a logical analyser? If you dump interrupt counters in /proc/interrupts will you see an interrupt storm for the selected irq pin? Regards, Lorenzo > > 2. Seems like an okay idea, do you want this in v7? > > /Sean
Attachment:
signature.asc
Description: PGP signature
