Integration Issue with LSM6DSVX IMU Sensor HAL on Android 10 (i.MX Processor

[yogeshmanjashetty]

We observe mutually exclusive behavior in the LSM6DSVX driver:

1. With interrupts DISABLED:

   • Can successfully read raw values via sysfs:

     cat /sys/bus/iio/devices/iio:deviceX/in_accel_x_raw  # Returns valid data

2. With interrupts ENABLED:

   • Sysfs reads return 0:

     cat /sys/bus/iio/devices/iio:deviceX/in_accel_x_raw  # Returns 0

   • Kernel driver appears functional (interrupts fire in dmesg)

   • HAL receives flush events but no sensor data

Debugging Performed:

• Confirmed IIO buffer configuration:

  echo 1 > /sys/bus/iio/devices/iio:deviceX/buffer/enable

• Verified no resource conflicts (lsof /dev/iio:device*)

• Tested with/without FIFO mode - same behavior

Suspected Root Cause:
Driver may be locking out sysfs reads when interrupts are active, or buffer ownership isn't properly shared between interrupt and sysfs access modes.

Request:
Could you clarify:

1. Is this expected behavior in the LSM6DSVX driver?

2. Recommended workaround to allow both interrupt-driven AND sysfs access?

3. Any known patches or configuration flags to resolve this?

Additional Context:

• Kernel: ______

• HAL: android.hardware.sensors@2.0 (ST implementation)

• Platform: i.MX8MM

[Federica Bossi]

Hi @yogeshmanjashetty ,

The driver behavior is intentional: if you read data using the IIO buffer interface, you cannot access read polling on the raw sensor data.
With the IIO buffer interface, the sensor is always on and streaming data, which is more convenient than polling read where the driver would have to do those steps:
1) turn on the sensor
2) wait for the data to be stable
3) reads the data from the sensor
4) turns off the sensor

Possibly if you also want polling reading at the same time as interrupt reading we can give you support.

[yogeshmanjashetty]

Hi Federica Bossi
Thank you for confirming the behavior regarding the IIO buffer interface and polling read support.

As you mentioned, when interrupts are enabled and I check the buffer enable path via cat, it shows 0. After manually enabling it using:
echo 1 > /sys/bus/iio/devices/iio:deviceX/buffer/enable

…it returns a “resource busy” error. This is consistent with your explanation and is understood.

We have also completed the HAL integration as per the documentation provided. However, we’re encountering the following warning logs at runtime:
05-13 13:12:31.231 306 306 W stm-sensors: failed to load gyro bias
05-13 13:12:31.231 306 306 W stm-sensors: failed to load accel bias

Additionally, even though the pollrate changes correctly when we open the Sensor APK (indicating some interaction with the HAL), no actual accelerometer or gyroscope data is reaching the application layer — the APK shows no real-time sensor values.

For your reference, I’ve attached the relevant logs.

Please advise if any additional configuration or patch is required on the HAL side to resolve this behavior.

[Federica Bossi]

Hi @yogeshmanjashetty ,

That message has no impact on the proper functioning of the HAL, it is only a Warning (W) message.
As for the apk not receiving data, this obviously can depend on many factors including:

1) If you have the timesync library:
- verify that the Linux lsm6dsvx driver is compiled with the option CONFIG_IIO_ST_LSM6DSVX_ASYNC_HW_TIMESTAMP=y
- verify that in the SensorHAL the option “-DHAL_ENABLE_TIMESYNC=1” is active in <sensor hal topdir>/core/Android.bp
- check that in the SensorHAL the option -DHAL_ENABLE_TIMESYNC=1 is active in <sensor hal topdir>/core/Android.mk

2) If you do not have the timesync library:
- verify that the Linux lsm6dsvx driver is not compiled with the CONFIG_IIO_ST_LSM6DSVX_ASYNC_HW_TIMESTAMP option.
- check that in the SensorHAL the option “-DHAL_ENABLE_TIMESYNC=0” in <sensor hal topdir>/core/Android.bp is disabled
- check that in SensorHAL the option -DHAL_ENABLE_TIMESYNC=0 in <sensor hal topdir>/core/Android.mk is turned off.

In case you have done the configuration correctly (HAL + Linux Driver), then the suggestion is to debug in steps, checking if, once the apk has enabled the sensor, the sensor interrupts grow over time, with the shell command:

# cat /proc/interrupts | grep lsm6dsv

You should observe an increasing number of interrupts over time at a rate equal to the value of the ODR set on the sensor.