Thread (7 messages) 7 messages, 3 authors, 2026-04-14

Re: [PATCH] arm64: dts: qcom: x1e80100-dell-xps13-9345: enable onboard accelerometers

From: Dmitry Baryshkov <hidden>
Date: 2026-03-23 17:05:41
Also in: linux-arm-msm, lkml

On Mon, Mar 23, 2026 at 04:06:53PM +0100, Konrad Dybcio wrote:
On 3/2/26 2:25 PM, Aleksandrs Vinarskis wrote:
quoted
On Monday, March 2nd, 2026 at 13:14, Konrad Dybcio [off-list ref] wrote:
quoted
On 2/28/26 6:46 PM, Aleksandrs Vinarskis wrote:
quoted
Particular laptop comes with two sets of sensors:
1. Motherboard: accelerometer
2. Display/Camera module: accelerometer, ambient ligth (and more)
   sensor

Define both i2c busses (bitbanged), sensors and respective rotation
matrices.
These GPIOs correspond to ADSP/SSC-bound QUPs. It may be that you're
poking at the same bus as the DSP is, concurrently.
Indeed, Val already pointed out that there is hexagonrpcd to access
sensors behind Sensor Core from DSP. I found corresponding .json sensor
files in Windows for all x3 sensors, but could not make it work yet.

Without these additional things in userspace it does not cause any
conflicts: I've been using this for a week now, no i2c communication
issues and device orientation information is present.

The question is then if we want to keep this series which ignores DSP
capabilities with the advantage that it will work for everyone with
the new kernel vs doing it 'correct' way over DSP which requires
additional json (and binary blobs?) and userpsace configuration,
meaning that most users will never have these sensors?
I don't know what's the endgame for sensors. Maybe +Dmitry knows whether
there's any action on that point.

Going through the DSP allows you to keep aggregating the data at close
to no power cost (""low power island""), notably without waking up the
CPUs if there's no other work. That, plus I'm somewhat skeptical about
going behind its back, since it may be that a firmware update or some
other trigger makes it start trying to communicate with them.
The sensors story would require DSP libraries matching the firmware,
sensors descriptions and several still-closed-source libraries to work.
There is an open-source libssc project, but I don't know if anybody has
tested it on this platform (and it will still require DSP libs to
function).
But I'm not 100% against this either
I guess it is a necessary evil until we get libssc to work on it.

-- 
With best wishes
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help