Closed kataklysmo closed 3 years ago
mariotesi
commented
3 years ago I think the issue is in the driver because the scan_elements entries need to be created in order to describe the channel data format, otherwise the buffer is not capable to read data from sensors. I suggest you to check if CONFIG_IIO_BUFFER is enabled in iio frameworks (it should be automatically enabled by choosing the imu68 device driver checkbox in the menuconfig, anyway) and report the kernel dmesg
kataklysmo
commented
3 years ago Hi @mariotesi From the current build the flags related to the IIO using cat /proc/config.gz i attach the dmesg and also the logcat.
# CONFIG_IIO_PERIODIC_RTC_TRIGGER is not set
# CONFIG_IIO_SIMPLE_DUMMY is not set
CONFIG_IIO=y
CONFIG_IIO_BUFFER=y
CONFIG_IIO_BUFFER_CB=y
CONFIG_IIO_KFIFO_BUF=y
CONFIG_IIO_TRIGGERED_BUFFER=y
CONFIG_IIO_TRIGGER=y
CONFIG_IIO_CONSUMERS_PER_TRIGGER=2
# CONFIG_IIO_ST_ACCEL_3AXIS is not set
# CONFIG_IIO_ST_GYRO_3AXIS is not set
CONFIG_IIO_ST_IMU68=y
CONFIG_IIO_ST_IMU68_I2C=y
CONFIG_IIO_ST_IMU68_SPI=y
# CONFIG_IIO_ST_ASM330LHH is not set
# CONFIG_IIO_ST_LSM6DSO is not set
# CONFIG_IIO_ST_LSM6DSR is not set
# CONFIG_IIO_ST_ISM330DHCX is not set
# CONFIG_IIO_ST_LSM6DSO32 is not set
# CONFIG_IIO_ST_MAGN_3AXIS is not set
# CONFIG_IIO_INTERRUPT_TRIGGER is not set
# CONFIG_IIO_SYSFS_TRIGGER is not set
# CONFIG_IIO_ST_PRESS is not setThe scan_elements folder is not present. About SELinux is on permissive mode so i have multiple avc messages pending to be fixed. Here a example from the logcat file.
01-01 00:11:36.439 414 414 I : Loaded library from /vendor/lib/hw/STsensors.msm8909.so
01-01 00:11:36.479 421 421 I ServiceManagement: Removing namespace from process name vendor.qti.hardware.qteeconnector@1.0-service to qteeconnector@1.
01-01 00:11:36.487 414 414 I Sensors : Found calibration library:libcalmodule_common.so
01-01 00:11:36.509 414 414 I android.hardwar: type=1400 audit(0.0:6): avc: denied { write } for name="/" dev="mmcblk0p38" ino=2 scontext=u:r:hal_sensors_default:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1
01-01 00:11:36.509 414 414 I android.hardwar: type=1400 audit(0.0:7): avc: denied { add_name } for name="STSensorHAL" scontext=u:r:hal_sensors_default:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1
01-01 00:11:36.509 414 414 I android.hardwar: type=1400 audit(0.0:8): avc: denied { create } for name="STSensorHAL" scontext=u:r:hal_sensors_default:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1
01-01 00:11:36.509 414 414 I android.hardwar: type=1400 audit(0.0:9): avc: denied { read } for name="devices" dev="sysfs" ino=16143 scontext=u:r:hal_sensors_default:s0 tcontext=u:object_r:sysfs:s0 tclass=dir permissive=1
01-01 00:11:36.509 414 414 I android.hardwar: type=1400 audit(0.0:10): avc: denied { open } for path="/sys/bus/iio/devices" dev="sysfs" ino=16143 scontext=u:r:hal_sensors_default:s0 tcontext=u:object_r:sysfs:s0 tclass=dir permissive=1Thank you.
kataklysmo
commented
3 years ago Hi again @mariotesi,
I added a print just to show that the channels are NULL once STMems_Android_Sensor_HAL_IIO loads.
01-01 02:36:49.155 416 416 D SensorHAL: 3 IIO devices available into /sys/bus/iio/devices/ folder.
01-01 02:36:49.155 416 416 D SensorHAL: "lsm9ds1_accel": IIO device found and supported. Wake-up sensor: no
01-01 02:36:49.158 416 416 D SensorHAL: SensorHal.cpp:1216- data[index].channels is NULL!The st_imu68 driver doesn't create the scan_elements folder and the function scan_channel from STMems_Android_Sensor_HAL_IIO (utils.cpp) checks if the directory exists.
int device_iio_utils::scan_channel(const char *device_dir,
struct device_iio_info_channel **data,
int *counter)
memset(dfilename, 0, DEVICE_IIO_MAX_FILENAME_LEN + 1);
snprintf(dname, DEVICE_IIO_MAX_FILENAME_LEN, "%s/scan_elements",
device_dir);
ret = sysfs_opendir(dname, &dp);and that generates the crash once STMems_Android_Sensor_HAL_IIO loads as i pointed before.
mariotesi
commented
3 years ago Yes I see, but the issue is in the imu driver, it must create the entries scan_elements otherwise is not possible ti use the buffer I think there are some issue on buffer allocation in your kernel 3,18 driver so I suggest to add some kernel printk in the imu68 driver during the probe and in the init buffer, devm_request_threaded_irq, just to check where the driver fails (maybe the irq is not configured in the device tree ?)
kataklysmo
commented
3 years ago And just to try to help, I found a comment from a year ago where you indicate that the st_imu68 driver does not create the directory scan_elements it uses the entry path or at least that's what I understand from the comment, I'll will add some printk on the imu68 driver following your suggestion.
About the IRQ it's configured on the device tree.
lsm9ds1_ag@6b {
compatible = "st,lsm9ds1";
reg = <0x6B>;
interrupt-parent = <&msm_gpio>;
interrupts = <65>;
};
lsm9ds1_m@1e{
compatible = "st,lsm9ds1_magn";
reg = <0x1E>;
interrupt-parent = <&msm_gpio>;
interrupts = <94>;
};Hi @mariotesi ,
Just adding some printk as you suggested, the IRQ was not correctly defined. For anyone with the same problem i just added the interupt-names field. Now the interrupt is registered and the scan_elements created.
lsm9ds1_ag@6b {
compatible = "st,lsm9ds1";
reg = <0x6B>;
interrupt-parent = <&msm_gpio>;
interrupts = <65>;
interrupt-names = "ag_irq";
};Thanks for the support.
mariotesi
commented
3 years ago Thanks you too !
Hi @mariotesi ,
I'm using the LSM9DS1 sensor and i added the st_imu68 IIO driver into my kernel.
https://github.com/STMicroelectronics/STMems_Linux_IIO_drivers/tree/linux-3.18-gh/drivers/iio/imu/st_imu68
Inside /sys/bus/iio/devices i can read raw devices. So the driver is working fine.
/sys/bus/iio/devices/iio:devicex/in_xxx_x_raw /sys/bus/iio/devices/iio:devicex/in_xxx_y_raw /sys/bus/iio/devices/iio:devicex/in_xxx_z_raw
Once i add the STMems_Android_Sensor_HAL_IIO the service is crashing.
Line 1216-SensorHal.cpp - st_hal_set_fullscale this function is using data[index].channels and in my case these channels are null.
The function used to initialize these channels is called in Line 1173-SensorHAL.cpp and defined in 371-utils.cpp
This function looks for the scan_elements path, and in my case this path is not created by the driver.
As a workaround i just added a check before the st_hal_set_fullscale call. The driver is loading and i can see the sensors on the system (dumpsys sensorservice) . I can still read raw values but the system is not able to read any value from the sensor.
Some idea of what may be happening? Thank you in advance.