Re: [PATCH v6 5/6] iio: imu: st_lsm6dsx: add motion report function and call from interrupt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 09/09/2019 14.05, Lorenzo Bianconi wrote:
  static irqreturn_t st_lsm6dsx_handler_irq(int irq, void *private)
  {
  	return IRQ_WAKE_THREAD;
@@ -1668,6 +1726,18 @@ static irqreturn_t st_lsm6dsx_handler_thread(int irq, void *private)
  {
  	struct st_lsm6dsx_hw *hw = private;
  	int count;
+	int data, err;
+
+	if (hw->enable_event) {

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?


1. Without the last [PATCH v6 6/6] and this diff:

diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
index bd5c7c65a519..b303459e0d31 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
@@ -1728,7 +1728,6 @@ static irqreturn_t st_lsm6dsx_handler_thread(int irq, void *private)
        int count;
        int data, err;

-       if (hw->enable_event) {
                err = regmap_read(hw->regmap,

hw->settings->event_settings.wakeup_src_reg,
                                  &data);
@@ -1737,7 +1736,6 @@ static irqreturn_t st_lsm6dsx_handler_thread(int irq, void *private)

if (data & hw->settings->event_settings.wakeup_src_status_mask)
                        st_lsm6dsx_report_motion_event(hw, data);
-       }

        mutex_lock(&hw->fifo_lock);
        count = hw->settings->fifo_ops.read_fifo(hw);

$ 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?

2. Seems like an okay idea, do you want this in v7?

/Sean



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux