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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 3/2/26 2:25 PM, Aleksandrs Vinarskis wrote:
> 
> On Monday, March 2nd, 2026 at 13:14, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> 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.

But I'm not 100% against this either

Konrad