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

[Aleksandrs Vinarskis]

On Monday, March 23rd, 2026 at 18:05, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:

> 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.

Thanks everyone for the input.

It sounds that long-term DSP is clearly a go-for solution, but at
the current state bit-banging is acceptable way to provide this
functionality. I will update my patch to reflect outcome of this
discussion in v2.

Regards,
Alex

> 
> --
> With best wishes
> Dmitry
>