Necessity of iio_device_claim_direct_mode()

The adxl345, 362 and 372 all prevent in_temp_raw access while buffer/enable == 1. We are leveraging that code to support adxl355 (is there already a driver from you?).

We need to read the temperate without interrupting accel sampling, but iio_device_claim_direct_mode() causes the direct read on in_temp_raw to fail while buffering is enabled.

My guess is that a FIFO IRQ could fail to obtain access to the SPI (in our case) bus while directly reading the temp out registers. Can you confirm?

Can you suggest a workaround?

(Sorry, indents got eaten)
890 case IIO_TEMP:
891 ret = iio_device_claim_direct_mode(indio_dev);
892 dev_dbg(st->dev, "%s: %d, iio_device_claim_direct_mode(): %d\n",
893 __FUNCTION__, __LINE__, ret );
894 if (ret)
895 return ret;
896
897 dev_dbg(st->dev, "%s: %d, adxl355_read_temp_raw()\n",
898 __FUNCTION__, __LINE__ );
899 ret = adxl355_read_temp_raw(st,
900 adxl355_data_reg_lookup_tbl[chan->address]);
901 dev_dbg(st->dev, "%s: %d, adxl355_read_temp_raw(): %d\n",
902 __FUNCTION__, __LINE__, ret );
903
904 iio_device_release_direct_mode(indio_dev);
905 if (ret < 0)
906 return ret;
907
908 *val = ret ;
909 return IIO_VAL_INT;

Top Replies

    •  Analog Employees 
    Jul 15, 2020 in reply to Dan G. +1 verified
    Thanks. The `claim_direct` calls are in the ADXL drivers from which we are deriving the 355 driver. The question is not about what the call does, but why the drivers are even making the call…
  • 0
    •  Analog Employees 
    on Jul 14, 2020 9:32 AM 4 months ago

    We don't have a Linux driver for ADXL355 yet.

    Questions about IIO Linux framework typically go to the IIO mailing list here:

    http://vger.kernel.org/vger-lists.html#linux-iio

    [ i.e. linux-iio@vger.kernel.org ]

    My guess is that a FIFO IRQ could fail to obtain access to the SPI (in our case) bus while directly reading the temp out registers. Can you confirm?

    Depends how this is implemented.

    Some locking can be used and also an interrupt-service-thread to take over if the lock is held.

    I would recommend to try/test things a bit.

    It's hard to confirm anything without running the driver & chip.

  • Thanks. The `claim_direct` calls are in the ADXL drivers from which we are deriving the 355 driver. The question is not about what the call does, but why the drivers are even making the call at all.

    Attempting to answer my own question, the drivers, as-is, optimize for latency and lose access to temperature. In our case, we are reading temperature in order to compensate for potential bias drift. Although our app can tolerate workqueue latency, disabling buffering entirely, reading temp_raw, and re-enabling is too much. We'll probably go with a workqueue and remove the claim_direct calls in our driver.

    Perhaps the chip compensates well enough internally? If so, we can leave well-enough alone.

  • +1
    •  Analog Employees 
    on Jul 15, 2020 1:24 PM 4 months ago in reply to Dan G.
    Thanks. The `claim_direct` calls are in the ADXL drivers from which we are deriving the 355 driver. The question is not about what the call does, but why the drivers are even making the call at all.

    If my memory serves me correctly, the IIO driver can be in different modes internally (buffered mode, triggered mode, and some other modes).

    Direct-mode is where you'd typically read directly from the driver a value (like temperature, a voltage, etc).

    Now when in buffered mode, it's probably not a good idea to read data, while data is being streamed/buffered from the device, so claim_direct & release_direct are mechanisms to tell the IIO framework to hold off streaming for a while.

    We'll probably go with a workqueue and remove the claim_direct calls in our driver.

    If that works, sure.

    Perhaps the chip compensates well enough internally? If so, we can leave well-enough alone.

    I did not play with the ADXL345 / ADXL355 to offer any answers; which is why I'm not confirming anything.

    Our group typically writes drivers for chips, but chip behavior can usually be better explained by the BU that built the chip. So, we're no better at explaining these chips.

    I'd recommend trying things and seeing how they work/behave.

    Odds are things would work fine, and maybe there's too much worrying for something that may not be an issue.

  • Now when in buffered mode, it's probably not a good idea to read data, while data is being streamed/buffered from the device, so claim_direct & release_direct are mechanisms to tell the IIO framework to hold off streaming for a while.

    The ADXL355 datasheet makes no mention about restrictions on temperature register reads. Experimentation shows that the chip updates the temperature registers, regardless of FIFO status. So far, so good. We'll check with the chip BU to confirm.

    Thank you for your comments.