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

[Dmitry Baryshkov]

On Mon, Mar 23, 2026 at 04:06:53PM +0100, Konrad Dybcio wrote:
> On 3/2/26 2:25 PM, Aleksandrs Vinarskis wrote:
> > 
> > On Monday, March 2nd, 2026 at 13:14, Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
> > 
> >> On 2/28/26 6:46 PM, Aleksandrs Vinarskis wrote:
> >>> 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