kit/linux-gts6l
1
0
Fork 0
Code Issues 18 Pull requests Projects Releases Packages Wiki Activity Actions

Sensors: LSM6DSO accel/gyro, AK09918 compass, VEML3328 light (SSC island) #5

New issue
Open
opened 2026-08-20 13:22:13 +00:00 by kit · 5 comments
kit commented 2026-08-20 13:22:13 +00:00
Owner
Copy link

Hardware (from Samsung drivers/adsp_factory/): AK09918 magnetometer, LPS22HH pressure, plus accel/gyro (exact part TBD — check adsp_factory Kconfig/Makefile for the accel entry). All are behind the SLPI sensor hub — no AP-side I2C nodes in the DT; the DSP owns the bus and Android reads via QMI/SEE.

Two routes:

Route 1 — reclaim the I2C bus (pragmatic, try first):

  • The sensors sit on a QUP the SLPI normally owns; the AP can claim the same QUP.
  • Find the bus: gts6l pinctrl dtsi sensor i2c pins / SLPI firmware config; then enable that QUP in our DTS, keep SLPI remoteproc off, i2cdetect.
  • Mainline IIO drivers exist: ak09918 (ak8975 driver), st_pressure (lps22hh), st_lsm6dsx-class for accel/gyro if it's an ST part.
  • Risk: pin mux ownership / TrustZone-reserved ranges.

Route 2 — SLPI + hexagonrpc (proper, longer):

  • Boot remoteproc_slpi with Samsung-signed firmware via the link-farm.
  • Userspace: postmarketOS hexagonrpcd/fastrpc SEE bridge (sdm845 precedent).
  • One bring-up covers all sensors incl. any fusion.

Start with route 1 recon: identify the sensor QUP + addresses from the Samsung tree.

Hardware (from Samsung `drivers/adsp_factory/`): AK09918 magnetometer, LPS22HH pressure, plus accel/gyro (exact part TBD — check adsp_factory Kconfig/Makefile for the accel entry). All are behind the **SLPI sensor hub** — no AP-side I2C nodes in the DT; the DSP owns the bus and Android reads via QMI/SEE. Two routes: **Route 1 — reclaim the I2C bus (pragmatic, try first):** - The sensors sit on a QUP the SLPI normally owns; the AP can claim the same QUP. - Find the bus: gts6l pinctrl dtsi sensor i2c pins / SLPI firmware config; then enable that QUP in our DTS, keep SLPI remoteproc off, `i2cdetect`. - Mainline IIO drivers exist: ak09918 (ak8975 driver), st_pressure (lps22hh), st_lsm6dsx-class for accel/gyro if it's an ST part. - Risk: pin mux ownership / TrustZone-reserved ranges. **Route 2 — SLPI + hexagonrpc (proper, longer):** - Boot `remoteproc_slpi` with Samsung-signed firmware via the link-farm. - Userspace: postmarketOS `hexagonrpcd`/fastrpc SEE bridge (sdm845 precedent). - One bring-up covers all sensors incl. any fusion. Start with route 1 recon: identify the sensor QUP + addresses from the Samsung tree.
kit commented 2026-08-20 13:22:31 +00:00
Author
Owner
Copy link

Parts identified from adsp_factory: LSM6DSO accel+gyro (mainline st_lsm6dsx supports it natively), AK09918 mag, LPS22HH pressure, STK3A9x/TCS3701 light (board-dependent), AK09970 digital hall. Everything on the route-1 path has a mainline IIO driver — the whole question reduces to whether the sensor QUP/I2C pins can be reclaimed from the SLPI.

Parts identified from adsp_factory: **LSM6DSO** accel+gyro (mainline `st_lsm6dsx` supports it natively), AK09918 mag, LPS22HH pressure, STK3A9x/TCS3701 light (board-dependent), AK09970 digital hall. Everything on the route-1 path has a mainline IIO driver — the whole question reduces to whether the sensor QUP/I2C pins can be reclaimed from the SLPI.
kit commented 2026-08-20 13:25:41 +00:00
Author
Owner
Copy link

Recon from the Samsung tree (device-free):

  • gts6l has no board sensor DT at all; even downstream only describes the SLPI loader (pil_ssc@5c00000). The bus topology (which SSC QUP, slave addresses, IRQ/reset GPIOs, VDD rails) lives in the SLPI sensor registry on the vendor partition (/vendor/etc/sensors/ config files) — which we already mount.
  • Other Samsung sm8150 boards' sensor dtsi (bloom) shows the pattern: sensor VDD is a PMIC LDO (pm8150l_l8 @1.8V there) enabled for the SSC.
  • Route-1 next step (needs device): read the vendor sensor registry → extract bus/addr/gpio → determine whether the bus is an SSC-island QUP (would need a new geni-se instance + SSC power domain in our DTS — uncharted on mainline) or AP-reachable TLMM muxing (trivial). Decision follows from the registry contents.

Priority note: sensors scheduled ahead of LTE (agreed 2026-08-20).

Recon from the Samsung tree (device-free): - gts6l has no board sensor DT at all; even downstream only describes the SLPI loader (`pil_ssc@5c00000`). The bus topology (which SSC QUP, slave addresses, IRQ/reset GPIOs, VDD rails) lives in the **SLPI sensor registry on the vendor partition** (`/vendor/etc/sensors/` config files) — which we already mount. - Other Samsung sm8150 boards' sensor dtsi (bloom) shows the pattern: sensor VDD is a PMIC LDO (pm8150l_l8 @1.8V there) enabled for the SSC. - Route-1 next step (needs device): read the vendor sensor registry → extract bus/addr/gpio → determine whether the bus is an SSC-island QUP (would need a new geni-se instance + SSC power domain in our DTS — uncharted on mainline) or AP-reachable TLMM muxing (trivial). Decision follows from the registry contents. Priority note: sensors scheduled ahead of LTE (agreed 2026-08-20).
kit commented 2026-08-20 15:18:31 +00:00
Author
Owner
Copy link

Device recon 2026-08-20: topology found, island is unpowered (route 1 is NOT a TLMM exercise)

Populated sensors (corrected from the issue text) — gts6l_usa_vzw_defconfig + SLPI fw strings + persist registry all agree:

  • LSM6DSO accel+gyro
  • AK09918 mag
  • VEML3328 ALS/RGB (not STK3A9x/TCS3701)
  • No barometer (CONFIG_LPS22HH_FACTORY not set; no registry entry; sensors_list.txt has no pressure). No AK09970 (hall is a plain GPIO switch + wacom hall).

Bus topology (from /mnt/vendor/persist/sensors/registry/registry/*_platform.config, which the SEE daemon compiled from /vendor/etc/sensors/config/msmnile_*.json — hw_platform matched the QC reference set, so these are the real values):

sensor bus SSC bus_instance addr IRQ rails
lsm6dso I3C (bus_type 3) 1 0x6b static / 0x0a dyn dri_irq_num 7667844 (I3C IBI encoding, not a GPIO) sensor_vddio
ak0991x I2C 2 0x0c GPIO 134 (SLPI-TLMM numbering? — 134 > 14 pins, so probably main TLMM; verify) sensor_vddio
veml3328 I2C 6 0x10 none sensor_vdd + sensor_vddio

Orientation matrices also recorded (lsm6dso -x,+y,-z; ak0991x -y,-x,-z) — useful for IIO mount-matrix later.

Where the buses physically live — the SSC island, not the AP TLMM:

  • Main SM8150 TLMM has zero SSC mux functions (checked mainline pinctrl-sm8150.c).
  • Downstream sm8150-slpi-pinctrl.dtsi: SLPI TLMM @0x02B40000, 14 pins (qcom,slpi-pinctrl, driver pinctrl-slpi.c). 7 SEs × 2 pins fits bus_instance 0..6.
  • Downstream sa8155-vm-qupv3.dtsi: SSC QUP wrapper qupv3_3 @0x26c0000, SEs at 0x2680000 + n·0x4000 (se20..23 = SE0..3, IRQs GIC_SPI 442+), IOMMU SID 0x4e3, clocks from SCC @0x2b10000 (scc-sm8150.c, vdd_scc_cx = pm8150_l8 level = LCX).
  • The automotive SA8155/SA8195 DTs run exactly these QUPs from the AP (&slpi_tlmm status=ok, &ssc_sensors disabled) — that's the precedent for route 1. Note they still boot pil_ssc.

Mainline has none of it: no SCC clock driver, no SLPI pinctrl, no SSC QUP nodes. All three exist downstream as ordinary qcom drivers (clk-rcg2/branch; pinctrl is a close cousin of pinctrl-lpass-lpi; QUP is stock geni-se with different clocks) — portable, but it's a port, not a DT tweak.

Experiment + result: cross-compiled a /dev/mem peek tool; AP TLMM/GCC read fine, first read of SCC 0x2b10000 hard-stalled the SoC. USB gadget stayed enumerated (no reset), APSS watchdog did not bite after >5 min — AHB stall blocks everything. Needs physical power cycle. Do not touch 0x26xxxxx/0x2bxxxxx from the AP until the island is powered.

Why it's unpowered / what powers it: downstream pil_ssc = LCX (pm8150_l8) + LMX (pm8150_l4) proxy votes + AOSS QMP load_state slpi on (qcom,signal-aop); mainline's qcom,sm8150-slpi-pas does the same (rpmhpd LCX/LMX + qcom,qmp). Our DTS has &remoteproc_slpi status="okay" with the link-farm slpi.mdt — so either SLPI never came up (auth/fw issue → PAS drops the island again) or it's up and the stall has another cause. First thing after power cycle: cat /sys/class/remoteproc/*/{name,state} + dmesg | grep -i slpi.

Revised plan:

  1. Get the SLPI to actually boot (route 2 step 1 anyway). If it runs, the island is powered and we can re-try the SCC/SLPI-TLMM peek safely to confirm accessibility.
  2. Then decide: (a) route 1 = small "ssc-island" power driver (LCX+LMX+QMP load_state, no firmware) + port scc-sm8150 + pinctrl-slpi + SSC geni nodes, run the I3C SE as plain I2C (LSM6DSO answers I2C at 0x6b pre-DAA; mainline has no geni I3C master); or (b) route 2 = SLPI + hexagonrpc/SEE bridge, which uses the registry above as-is.
  3. AK09918 IRQ GPIO 134 identity to be confirmed.
## Device recon 2026-08-20: topology found, island is unpowered (route 1 is NOT a TLMM exercise) **Populated sensors (corrected from the issue text)** — `gts6l_usa_vzw_defconfig` + SLPI fw strings + persist registry all agree: - **LSM6DSO** accel+gyro - **AK09918** mag - **VEML3328** ALS/RGB (not STK3A9x/TCS3701) - No barometer (`CONFIG_LPS22HH_FACTORY` not set; no registry entry; `sensors_list.txt` has no pressure). No AK09970 (hall is a plain GPIO switch + wacom hall). **Bus topology** (from `/mnt/vendor/persist/sensors/registry/registry/*_platform.config`, which the SEE daemon compiled from `/vendor/etc/sensors/config/msmnile_*.json` — hw_platform matched the QC reference set, so these are the real values): | sensor | bus | SSC bus_instance | addr | IRQ | rails | |---|---|---|---|---|---| | lsm6dso | I3C (bus_type 3) | 1 | 0x6b static / 0x0a dyn | `dri_irq_num` 7667844 (I3C IBI encoding, not a GPIO) | sensor_vddio | | ak0991x | I2C | 2 | 0x0c | GPIO 134 (SLPI-TLMM numbering? — 134 > 14 pins, so probably main TLMM; verify) | sensor_vddio | | veml3328 | I2C | 6 | 0x10 | none | sensor_vdd + sensor_vddio | Orientation matrices also recorded (lsm6dso `-x,+y,-z`; ak0991x `-y,-x,-z`) — useful for IIO `mount-matrix` later. **Where the buses physically live — the SSC island, not the AP TLMM:** - Main SM8150 TLMM has zero SSC mux functions (checked mainline `pinctrl-sm8150.c`). - Downstream `sm8150-slpi-pinctrl.dtsi`: **SLPI TLMM @0x02B40000, 14 pins** (`qcom,slpi-pinctrl`, driver `pinctrl-slpi.c`). 7 SEs × 2 pins fits bus_instance 0..6. - Downstream `sa8155-vm-qupv3.dtsi`: SSC QUP wrapper **qupv3_3 @0x26c0000**, SEs at **0x2680000 + n·0x4000** (se20..23 = SE0..3, IRQs GIC_SPI 442+), IOMMU SID 0x4e3, clocks from **SCC @0x2b10000** (`scc-sm8150.c`, vdd_scc_cx = pm8150_l8 level = LCX). - The **automotive SA8155/SA8195 DTs run exactly these QUPs from the AP** (`&slpi_tlmm status=ok`, `&ssc_sensors disabled`) — that's the precedent for route 1. Note they still boot `pil_ssc`. **Mainline has none of it**: no SCC clock driver, no SLPI pinctrl, no SSC QUP nodes. All three exist downstream as ordinary qcom drivers (clk-rcg2/branch; pinctrl is a close cousin of `pinctrl-lpass-lpi`; QUP is stock geni-se with different clocks) — portable, but it's a port, not a DT tweak. **Experiment + result**: cross-compiled a `/dev/mem` peek tool; AP TLMM/GCC read fine, **first read of SCC 0x2b10000 hard-stalled the SoC**. USB gadget stayed enumerated (no reset), APSS watchdog did not bite after >5 min — AHB stall blocks everything. Needs physical power cycle. **Do not touch 0x26xxxxx/0x2bxxxxx from the AP until the island is powered.** **Why it's unpowered / what powers it**: downstream `pil_ssc` = LCX (pm8150_l8) + LMX (pm8150_l4) proxy votes + AOSS QMP `load_state slpi on` (`qcom,signal-aop`); mainline's `qcom,sm8150-slpi-pas` does the same (`rpmhpd LCX/LMX` + `qcom,qmp`). Our DTS has `&remoteproc_slpi status="okay"` with the link-farm `slpi.mdt` — so either SLPI never came up (auth/fw issue → PAS drops the island again) or it's up and the stall has another cause. **First thing after power cycle**: `cat /sys/class/remoteproc/*/{name,state}` + `dmesg | grep -i slpi`. **Revised plan**: 1. Get the SLPI to actually boot (route 2 step 1 anyway). If it runs, the island is powered and we can re-try the SCC/SLPI-TLMM peek safely to confirm accessibility. 2. Then decide: (a) route 1 = small "ssc-island" power driver (LCX+LMX+QMP load_state, no firmware) + port scc-sm8150 + pinctrl-slpi + SSC geni nodes, run the I3C SE as plain I2C (LSM6DSO answers I2C at 0x6b pre-DAA; mainline has no geni I3C master); or (b) route 2 = SLPI + hexagonrpc/SEE bridge, which uses the registry above as-is. 3. AK09918 IRQ GPIO 134 identity to be confirmed.
kit changed title from Sensors: accelerometer, gyro, compass, barometer to Sensors: LSM6DSO accel/gyro, AK09918 compass, VEML3328 light (SSC island) 2026-08-20 15:18:41 +00:00
kit commented 2026-08-20 16:25:53 +00:00
Author
Owner
Copy link

2026-08-20: ACCEL + MAG + COMPASS WORKING via SLPI (route 2)

ssccli --sensor accelerometer → X=1.11 Y=0.35 Z=9.65 m/s², magnetometer in µT, compass heading in °. From a clean boot, no DSP crashes.

Route 1 is dead on this silicon

Not just "island unpowered": the SLPI was already running (island powered) on the next boot and the SCC read stalled anyway. libssc docs confirm the hypervisor forbids AP access to the sensor island on these SoCs. Don't revisit.

The real bug: SM8150 SDSP SMMU interconnect quirk → kernel patch 260c328df626

  • Service 0x190 (SNS_CLIENT) was already on QRTR node 9 — SEE was alive, but the registry sensor waits for the AP file server (hexagonrpcd).
  • First sensors-PD attach: SMMU fault SID 0x5a1 @ iova 0x1fffff000, then err_qdi.c:964 EX:sensor_process … frpck_0_0 fatal → SLPI crash, attach returns EPIPE.
  • Instrumented fastrpc.ko: buffer allocated at iova 0xfffff000 (mapped fine), but msg->addr = 0x1fffff000 because fastrpc folds sid << 32 into every address and expects the DSP to strip it. Samsung/QC's SM8150 SLPI doesn't — downstream adsprpc.c has an explicit "Software workaround for SMMU interconnect HW bug" for SDSP_DOMAIN_ID: cb = sid & 3, 34-bit DMA mask, IOVA mapping window offset by cb << 32, and no cb << 32 added to addresses.
  • Mainline fix (new DT flag qcom,iova-cb-window on the sdsp fastrpc node): 34-bit mask + bus_dma_limit = ((sid+1) << 32) - 1 (IOVA allocator is top-down, so every allocation lands in bank N's window without reservations), skip the sid << 32 add, use the full address for the DMA API on free/mmap. DT-side iommu-addresses reservations were a dead end (needs dma-ranges through glink-edge/fastrpc nodes with #size-cells = 0).
  • Disproven on the way: dma-coherent on the cbs (downstream has it, no effect), coherent-mask theory (already 32-bit).

Userspace (on the tablet now, NOT yet packaged)

  • libssc 0.4.4 + iio-sensor-proxy are in ALARM extra. hexagonrpcd is not: built from https://github.com/linux-msm/hexagonrpc on-device, installed to /usr/local (+ /etc/ld.so.conf.d/usr-local.conf).
  • Served tree /usr/share/qcom/sm8150/Samsung/gts6l/: sensors/config → /firmware/vendor/etc/sensors/config, sensors/sns_reg.conf → …/sns_reg_config, sensors/registry = copy of persist:/sensors/registry/registry (hexagonrpcd refuses writes anyway; the DSP tries to write fac_cal files — harmless), socinfo/ = soc_id+revision from sysfs plus hand-written hw_platform=MTP, platform_subtype=Unknown, platform_subtype_id=0, platform_version=65536, dsp → /firmware/vendor/dsp.
  • Unit hexagonrpcd-sdsp.service (root, ExecStart=hexagonrpcd -f /dev/fastrpc-sdsp -d sdsp -s -R <tree>), enabled.
  • Never kill/restart hexagonrpcd while the SLPI is up: the DSP blocks on an RFS call → "SEE Sensor exceeded processing time limit" → SLPI fatal → SSR cascade also took the ADSP down (glink channel-migration assert; mainline SSR notify timeouts). Reboot instead.
  • Also: rmmod/modprobe of fastrpc on a live system oopses in qcom_glink_send_open_req (stale endpoint) — reboot for module swaps too.

Open

  • Light (VEML3328): SEE reports no ambient_light sensor. Registry entry exists (I2C SSC bus 6 @0x10, needs sensor_vdd+sensor_vddio). Maybe the rail isn't up, or hw_platform/socinfo gating. Gyro: ssccli has no gyro mode; check libssc API / iio-sensor-proxy.
  • Package it in gts6l-alarm: hexagonrpcd PKGBUILD, the served tree (gts6l-device), the unit, libssc + iio-sensor-proxy deps; iio-sensor-proxy needs AF_QIPCRTR allowed in its unit (RestrictAddressFamilies).
  • Upstreamable form of the fastrpc quirk (soc_data flag instead of DT bool? binding for qcom,iova-cb-window).
  • Orientation matrix check (registry: lsm -x,+y,-z, mag -y,-x,-z) once iio-sensor-proxy is on.
## 2026-08-20: ACCEL + MAG + COMPASS WORKING via SLPI (route 2) `ssccli --sensor accelerometer` → `X=1.11 Y=0.35 Z=9.65 m/s²`, magnetometer in µT, compass heading in °. From a clean boot, no DSP crashes. ### Route 1 is dead on this silicon Not just "island unpowered": the SLPI was already `running` (island powered) on the next boot and the SCC read stalled anyway. libssc docs confirm the hypervisor forbids AP access to the sensor island on these SoCs. Don't revisit. ### The real bug: SM8150 SDSP SMMU interconnect quirk → kernel patch `260c328df626` - Service `0x190` (SNS_CLIENT) was already on QRTR node 9 — SEE was alive, but the `registry` sensor waits for the AP file server (`hexagonrpcd`). - First sensors-PD attach: SMMU fault SID 0x5a1 @ iova **0x1fffff000**, then `err_qdi.c:964 EX:sensor_process … frpck_0_0` fatal → SLPI crash, attach returns EPIPE. - Instrumented `fastrpc.ko`: buffer allocated at iova 0xfffff000 (mapped fine), but `msg->addr` = 0x1fffff000 because fastrpc folds `sid << 32` into every address and expects the DSP to strip it. **Samsung/QC's SM8150 SLPI doesn't** — downstream `adsprpc.c` has an explicit *"Software workaround for SMMU interconnect HW bug"* for `SDSP_DOMAIN_ID`: `cb = sid & 3`, 34-bit DMA mask, IOVA mapping window offset by `cb << 32`, and no `cb << 32` added to addresses. - Mainline fix (new DT flag `qcom,iova-cb-window` on the sdsp fastrpc node): 34-bit mask + `bus_dma_limit = ((sid+1) << 32) - 1` (IOVA allocator is top-down, so every allocation lands in bank N's window without reservations), skip the `sid << 32` add, use the full address for the DMA API on free/mmap. DT-side `iommu-addresses` reservations were a dead end (needs `dma-ranges` through glink-edge/fastrpc nodes with `#size-cells = 0`). - Disproven on the way: `dma-coherent` on the cbs (downstream has it, no effect), coherent-mask theory (already 32-bit). ### Userspace (on the tablet now, NOT yet packaged) - `libssc 0.4.4` + `iio-sensor-proxy` are in ALARM `extra`. `hexagonrpcd` is not: built from https://github.com/linux-msm/hexagonrpc on-device, installed to `/usr/local` (+ `/etc/ld.so.conf.d/usr-local.conf`). - Served tree `/usr/share/qcom/sm8150/Samsung/gts6l/`: `sensors/config` → `/firmware/vendor/etc/sensors/config`, `sensors/sns_reg.conf` → `…/sns_reg_config`, `sensors/registry` = **copy** of `persist:/sensors/registry/registry` (hexagonrpcd refuses writes anyway; the DSP tries to write fac_cal files — harmless), `socinfo/` = soc_id+revision from sysfs plus hand-written `hw_platform=MTP`, `platform_subtype=Unknown`, `platform_subtype_id=0`, `platform_version=65536`, `dsp` → `/firmware/vendor/dsp`. - Unit `hexagonrpcd-sdsp.service` (root, `ExecStart=hexagonrpcd -f /dev/fastrpc-sdsp -d sdsp -s -R <tree>`), enabled. - **Never kill/restart hexagonrpcd while the SLPI is up**: the DSP blocks on an RFS call → "SEE Sensor exceeded processing time limit" → SLPI fatal → SSR cascade also took the ADSP down (glink channel-migration assert; mainline SSR notify timeouts). Reboot instead. - Also: rmmod/modprobe of `fastrpc` on a live system oopses in `qcom_glink_send_open_req` (stale endpoint) — reboot for module swaps too. ### Open - [ ] **Light (VEML3328)**: SEE reports no `ambient_light` sensor. Registry entry exists (I2C SSC bus 6 @0x10, needs `sensor_vdd`+`sensor_vddio`). Maybe the rail isn't up, or hw_platform/socinfo gating. Gyro: ssccli has no gyro mode; check libssc API / iio-sensor-proxy. - [ ] Package it in gts6l-alarm: `hexagonrpcd` PKGBUILD, the served tree (gts6l-device), the unit, libssc + iio-sensor-proxy deps; `iio-sensor-proxy` needs `AF_QIPCRTR` allowed in its unit (`RestrictAddressFamilies`). - [ ] Upstreamable form of the fastrpc quirk (soc_data flag instead of DT bool? binding for `qcom,iova-cb-window`). - [ ] Orientation matrix check (registry: lsm `-x,+y,-z`, mag `-y,-x,-z`) once iio-sensor-proxy is on.
kit commented 2026-08-21 01:56:43 +00:00
Author
Owner
Copy link

2026-08-20: LIGHT WORKING too — all populated sensors now live

ssccli --sensor light → lux readings; SEE publishes ambient_light (veml3328) and light_cct ("Light CCT", Samsung-modified VEML driver).

Cause: power, not config. The VEML3328's VDD is pm8150 L13A (2.8 V) with no AP consumer; Samsung's board DT keeps it regulator-always-on (/* RGB Sensor */ in sm8150-sec-gts6lwifi-r02.dtsi), and the SLPI's /pmic/client/sensor_vdd is effectively a dummy. Our ldo13 was in bootloader-left state (off). Fix: commit 65560d86946f (always-on in the DTS). Golden image updated.

How it was pinned down: verbose hexagonrpcd (-Dhexagonrpcd_verbose=true) showed SEE bulk-loading every registry file and parsing all JSONs (incl. both VEML configs — identical single source: I2C SSC bus 6 @0x10), and the SLPI firmware's registry key set for the driver matches the reference — so config was complete and the failure had to be in the DSP's device probe → rail.

Bonus from a raw ssc_sensor_new() probe (/root/sscprobe on the tablet): gyro and sensor_temperature (both lsm6dso) are published as well — ssccli just has no mode for them. Full inventory now: accel, gyro, temp, mag/compass, ambient_light, light_cct. proximity/pressure: none, as expected.

Noted for the iio-sensor-proxy step: libssc warns "Mount matrix provided by firmware is all 0, falling back to identity" — the registry's *_platform.placement is all zeros; the real orientation lives in *_platform.orient (lsm -x,+y,-z, mag -y,-x,-z). Either populate placement in our served registry copy or map orient → libssc mount-matrix.

Remaining on this issue: packaging (hexagonrpcd PKGBUILD + served tree + unit + socinfo shim, libssc/iio-sensor-proxy with AF_QIPCRTR allowed), orientation, upstreamable form of the fastrpc quirk.

## 2026-08-20: LIGHT WORKING too — all populated sensors now live `ssccli --sensor light` → lux readings; SEE publishes `ambient_light` (veml3328) and `light_cct` ("Light CCT", Samsung-modified VEML driver). **Cause:** power, not config. The VEML3328's VDD is **pm8150 L13A (2.8 V)** with no AP consumer; Samsung's board DT keeps it `regulator-always-on` (`/* RGB Sensor */` in `sm8150-sec-gts6lwifi-r02.dtsi`), and the SLPI's `/pmic/client/sensor_vdd` is effectively a dummy. Our `ldo13` was in bootloader-left state (off). Fix: commit `65560d86946f` (always-on in the DTS). Golden image updated. **How it was pinned down:** verbose `hexagonrpcd` (`-Dhexagonrpcd_verbose=true`) showed SEE bulk-loading every registry file and parsing all JSONs (incl. both VEML configs — identical single source: I2C SSC bus 6 @0x10), and the SLPI firmware's registry key set for the driver matches the reference — so config was complete and the failure had to be in the DSP's device probe → rail. **Bonus from a raw `ssc_sensor_new()` probe (`/root/sscprobe` on the tablet):** `gyro` and `sensor_temperature` (both lsm6dso) are published as well — ssccli just has no mode for them. Full inventory now: accel, gyro, temp, mag/compass, ambient_light, light_cct. `proximity`/`pressure`: none, as expected. **Noted for the iio-sensor-proxy step:** libssc warns "Mount matrix provided by firmware is all 0, falling back to identity" — the registry's `*_platform.placement` is all zeros; the real orientation lives in `*_platform.orient` (lsm `-x,+y,-z`, mag `-y,-x,-z`). Either populate placement in our served registry copy or map orient → libssc mount-matrix. Remaining on this issue: packaging (hexagonrpcd PKGBUILD + served tree + unit + socinfo shim, libssc/iio-sensor-proxy with `AF_QIPCRTR` allowed), orientation, upstreamable form of the fastrpc quirk.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
gts6l/6.17
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
kit/linux-gts6l#5
No description provided.