Draft: Qualcomm Sensor Manager support (MSM8996 & Co. SSC)

Sensor Manager is a QMI service available on several Qualcomm SoCs which exposes available sensors and allows for getting raw data from them. This service is provided by either:

• SSC (Snapdragon Sensor Core): Also known as SLPI (Sensor Low Power Island). Has its own set of pins and peripherals to which sensors are connected. These peripherals are generally inaccessible from the AP, meaning sensors need to be operated exclusively through SSC. The only SoCs in this category are MSM8996 and MSM8998.
• ADSP (Audio DSP): Shares pins and peripherals with the AP. At least on some devices these pins could be set to GPIO which allows the AP to access sensors by bit-banging their interfaces. Some SoCs in this category are SDM630/660, MSM8953, MSM8974 and MSM8226.

Before Sensor Manager becomes accessible, another service known as Sensor Registry needs to be provided by the AP. The remote processor that provides Sensor Manager will then request data from it, and once that process is done, will expose several services including Sensor Manager.

Note that SDM845 and later don't provide Sensor Manager, opting for an entirely different interface instead. This MR is therefore unrelated to !4050 (merged)

Details

Supporting sensors on SoCs with Sensor Manager involves the following:

• Sensor Registry server: Included in this MR (sns-reg).
• Sensor Manager client: The biggest and most important component. Located in the kernel and summarized in these commits:
  • QRTR bus: Allows for probing the Sensor Manager driver dynamically.
    • https://gitlab.com/msm8996-mainline/linux/-/commit/febf87f1443307e8ca2b88287c10ea019816ab95
    • https://gitlab.com/msm8996-mainline/linux/-/commit/195e477970c76a9147ca27da9554a6c4b07c516b
  • Sensor Manager drivers: Includes a core driver which enumerates sensors and handles incoming data, and an accelerometer driver which exposes accelerometers over IIO. Other sensors should be relatively easy to implement as all of the heavy lifting is done by the core driver which is in good shape at this point.
    • https://gitlab.com/msm8996-mainline/linux/-/commit/cf7f780a1f8a6be8ae5027434ea4e3baf78f6f80
    • https://gitlab.com/msm8996-mainline/linux/-/commit/92672b3e6591ea506b49a454d2fcd01b0def34b5

The registry

The sensor registry consists of keys organized in groups with a specific structure. Sensor registry clients (i.e. SSC) request data in groups, and the server has to obtain the values of keys belonging to the requested group then send them in the structure and order the client expects.

In Android, the individual key-value pairs are stored in plain text in /*/etc/sensors/sensor_def_qcomdev.conf. A proprietary daemon named sensors.qti reads that file and generates /persist/sensors/sns.reg, which contains the values in binary format. Some devices don't ship with a working sensor_def_qcomdev.conf and rely on the sns.reg file they ship with.

sns-reg reads key-value pairs from /etc/sns-reg.d/registry.conf. This file can either be sensor_def_qcomdev.conf unmodified, or if a working one isn't available, a generator tool is available in the sns-reg repository to generate a plain text registry from a working sns.reg.

Current status

Auto-rotation with the accelerometer works on the Xiaomi Mi Note 2 (MSM8996).

iio-sensor-proxy currently supports IIO devices that provide a raw read interface, as well as ones that have triggered buffers. However, it doesn't support devices with trigger-less buffers that also don't have a raw read interface. Therefore, this MR is necessary to support Sensor Manager accelerometers in iio-sensor-proxy: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/merge_requests/368

Call for testing

Anyone with one of the SoCs mentioned above or another SoC with Sensor Manager is welcome to test this.

Steps for testing:

• Obtain registry.conf as explained above, then place it in /etc/sns-reg.d.
• Run the Sensor Registry server, then look for the Sensor Manager service (ID 256) using qrtr-lookup.
• If found, note the version and instance ID. Stop here and report if not found; the kernel driver will do nothing without the Sensor Manager service being available.
• Apply kernel patches.
• If the version and instance ID found earlier are different from what is currently in the QRTR match table of the driver (version 1, instance 50), add a new entry to the table.
• Boot with patched kernel and run the Sensor Registry server. With driver debug messages enabled, a list of available sensors will be printed in the kernel log:

[  482.700894] smgr 9-18: Getting available sensors
[  482.779657] smgr 9-18: 0x00,0: STMicroelectronics LSM6DSM Accelerometer
[  482.783388] smgr 9-18: 0x0a,0: STMicroelectronics LSM6DSM Gyroscope
[  482.784239] smgr 9-18: 0x14,0: AKM AK09915 Magnetometer
[  482.785245] smgr 9-18: 0x28,0: Capella CM36686 PRX
[  482.785257] smgr 9-18: 0x28,1: Capella CM36686 ALS
[  482.786140] smgr 9-18: 0x1e,0: BOSCH BMP280 Pressure
[  482.786152] smgr 9-18: 0x1e,1: BOSCH BMP280 Temperature
[  482.787021] smgr 9-18: 0x50,0: Xiaomi hall Xiaomi_Hall_Dummy

• The accelerometer can be tested either with iio_generic_buffer, or with iio-sensor-proxy after applying the MR mentioned earlier.

added 3 commits

• 030d865f - sns-reg: new package
• 92c8b262 - firmware-xiaomi-scorpio: add sensor registry
• a5e7f00d - device-xiaomi-scorpio: add dependency on sns-reg

Compare with previous version

By Yassine Oudjana on 2023-05-25T16:57:59

This looks like binary firmware, wouldn't it be better to place it in /lib/firmware/? Do you know how to edit it? Having it in /etc kind of suggests that it's an easily editable configuration file.

By Minecrell on 2023-05-25T17:05:05

It is binary, but I don't know if it classifies as firmware since it's just data.

By Yassine Oudjana on 2023-05-25T17:06:52

I'd treat it similar to /lib/firmware/ath10k/QCA6174/hw3.0/board-2.bin which is also in /lib/firmware. It's probably just (board-specific) data too.

By Minecrell on 2023-05-25T17:08:58

changed this line in version 3 of the diff

By Yassine Oudjana on 2023-08-04T10:56:59

sns-reg now takes a plain-text file with key-value pairs. I've placed the file in the device package.

By Yassine Oudjana on 2023-08-04T10:58:33

It would indeed be nicer if sns-reg was not a userspace program, but kernel module that waits for specific remoteproc to start (using qcom_register_ssr_notifier ).

And the firmware even in textual form looks like textual representation of binary garbage anyway, agree with @Minecrell . Who will edit it by hand? It better be placed in /lib/firmware in binary form of sns.reg. And loaded by standard request_firmware() by driver in probe.

Maybe it should be done in form of auxiliary driver, same as in-kernel pd-mapper is now implemented. After figuring out which remote proc to wait for (using top-level SoC compatible, or ask pd-mapper which hexagon has sensor_pd for current SoC, is has all the data anyway) register ssr (SubSystem Restart) notifier callback (e.g. for "dsps" on 8996, "lpass" on 660). In that callback when startup notification is received, register and start QMI sns-reg server and handle the requests directly from kernel. pd-mapper can do it, so this all looks doable?

This is not a blocker for this MR though. Just an idea I thought worth noting.

Sensor registry was just a thing I had to get out of the way while getting sensor manager to work so I didn't give it full attention. I looked at the rmtfs server while making it, which was also a userspace daemon. Also leaving it in userspace means less things to upstream.

It should be possible to move to the kernel but I think it isn't that important or worth the effort. I think we should focus on the sensor manager client implementation since that's the most important part, and keep the current sensor registry server implementation as long as its working.

added category::device type::feature labels

removed category::device label

changed the description

By Yassine Oudjana on 2023-05-26T15:20:41

mentioned in issue #2132 (closed)

By Yassine Oudjana on 2023-06-05T12:16:20

@Tooniis The path is /etc/sns-reg.d/sns.reg instead of /etc/sns.reg.d/sns.reg You miss typed in your overview.

By Barnabás Czémán on 2023-07-04T20:15:18

changed the description

By Yassine Oudjana on 2023-07-04T20:14:46

Hi @Tooniis,

I started to test the changes and I find out the CONFIG_QRTR and CONFIG_QRTR_SMD cannot be compiled as a module anymore. They have to be set CONFIG_QRTR=y and CONFIG_QRTR_SMD=y, or else it cause compile errors.

err.log

By Barnabás Czémán on 2023-07-09T20:29:44

I tested the smgr driver on some msm8953 xiaomi devices (mido, tissot, sakura, ysl). The sns-reg starts fine and it logged out some message. The Sensor Manager service did not appear on any of the devices. mido, tissot, sakura/daisy do nothing but the ysl is logged out some message and it loaded smgr, sns_smgr and smgr_accel module. I have used the same kernel build for all device.

[  171.257865] qmi_decode: Data len 20 > max spec 15
[  171.257889] failed to decode incoming message
[  171.258040] smgr 5-8: Failed to get sensors from ID 0x28: -ETOOSMALL
[  171.258061] smgr: probe of 5-8 failed with error -525

By Barnabás Czémán on 2023-08-03T20:53:47

In my daisy (msm8953) it works fine:

[ 3647.573146] smgr 5-8: Getting available sensors
[ 3647.598169] smgr 5-8: 0x00,0: STMicroelectronics LSM6DS3 Accelerometer
[ 3647.602015] smgr 5-8: 0x0a,0: STMicroelectronics LSM6DS3 Gyroscope
[ 3647.603507] smgr 5-8: 0x14,0: AKM AK09918 Magnetometer
[ 3647.605249] smgr 5-8: 0x28,0: LiteOn LTR579 ALSPS
[ 3647.605271] smgr 5-8: 0x28,1: LiteOn LTR579 ALSPS

Also, with the needed MR for iio-sensor-proxy, the accelerometer is picked up and UI orientation changes correctly. Great job @Tooniis!

By alikates on 2023-08-03T19:33:20

added 328 commits

• a5e7f00d...1a388075 - 326 commits from branch postmarketOS:master
• 183898f8 - sns-reg: new package
• 9110ed64 - device-xiaomi-scorpio: add sensor registry

Compare with previous version

By Yassine Oudjana on 2023-08-04T10:57:02

changed the description

By Yassine Oudjana on 2023-08-04T11:21:34

@Tooniis if you are going to package sns-reg for alpine, make sure to adjust it for using argp-standalone. Alpine doesn't have the glibc version and I had to manually specify the linker flags for it to build correcty.

By alikates on 2023-08-04T20:09:34

I might drop argp altogether and go for a simpler approach if that's the case. Though for now I've only packaged the server which doesn't depend on argp.

By Yassine Oudjana on 2023-08-04T20:09:34

Also I had a sensor_def_qcomdev.conf which included values for other SoCs. Creating a registry.conf from it made the phone crash when the service is started.

I tried to create a conf only with the values for my SoC/board but it didn't work either.

Only the registry.conf generated from the previous sns.reg works.

By alikates on 2023-08-04T20:16:21

The firmware doesn't tolerate invalid data or sometimes just different values too much. I also got mine to crash when I sent wrong values for group 10 but that was due to a bug. For me it doesn't crash with sensor_def_qcomdev.conf but the sensor manager service becomes unresponsive. Maybe these files are leftovers from BSPs or something since they look highly "default".

By Yassine Oudjana on 2023-08-04T20:16:21

Indeed, there are sections for QRD and MTP board variants. Looks like vendor has commented out what doesn't fit their design.

By alikates on 2023-08-04T20:17:37

changed the description

By Yassine Oudjana on 2023-08-04T20:27:15

added status::mr-stale label