.../boot/dts/qcom/x1e80100-dell-xps13-9345.dts | 94 ++++++++++++++++++++++ 1 file changed, 94 insertions(+)
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.
Both accelerometers were tested individually via `monitor-sensor`.
Display accelerometer is defined first, as it appears automatic
screen rotation tools simply pick the 1st iio device.
Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
---
Enable two accelerometers, one on the motherboard, one in display.
In combination with userland screen rotation tools such as Gnome's
'screen rotate' [1] this allows for automatic screen rotation depending
on device orientation.
There appears to be an ALS, a "True Color Sensor with Flicker Detection"
AMS TCS3530 at 0x39. Out-of-tree driver from OSRAM is available [2].
Document bus, address, IRQ such that it could be added in the future.
There is an issue with st_sensors which prevents initializing two
sensors at the time, fix submitted [3]. It is not blocking this series,
as without it, 2nd currently unused accelerometer on the motherboard
will simply fail to probe.
[1] https://extensions.gnome.org/extension/5389/screen-rotate
[2] https://ams-osram.com/support/download-center?search=TCS3530&type=software&subtype=driver
[3] https://lore.kernel.org/all/20260228-st-iio-trigger-v1-1-abf5909e547f@vinarskis.com/
---
.../boot/dts/qcom/x1e80100-dell-xps13-9345.dts | 94 ++++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts b/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
index 4c95b1af2c64432967dc1e8b1d1c8bfe5a59cc34..42829a7e7c407add12560c75ede9bf02bcc0d9f8 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
@@ -40,6 +40,67 @@ switch-lid {
};
};
+ /* Display-mounted sensors */
+ i2c-sensors-display {
+ compatible = "i2c-gpio";
+ i2c-gpio,delay-us = <2>;
+
+ scl-gpios = <&tlmm 232 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&tlmm 231 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+ pinctrl-0 = <&sensors_i2c_display_default>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@18 {
+ compatible = "st,lis2dw12";
+ reg = <0x18>;
+
+ interrupts-extended = <&tlmm 29 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&acc_display_int_n_default>;
+ pinctrl-names = "default";
+
+ mount-matrix = "-1", "0", "0",
+ "0", "1", "0",
+ "0", "0", "-1";
+ };
+
+ /* AMS TCS3530 @ 0x39, IRQ 93 */
+ };
+
+ /* Motherboard-mounted sensors */
+ i2c-sensors-mobo {
+ compatible = "i2c-gpio";
+ i2c-gpio,delay-us = <2>;
+
+ scl-gpios = <&tlmm 216 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&tlmm 215 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+ pinctrl-0 = <&sensors_i2c_mobo_default>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@18 {
+ compatible = "st,lis2dw12";
+ reg = <0x18>;
+
+ interrupts-extended = <&tlmm 28 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&acc_mobo_int_n_default>;
+ pinctrl-names = "default";
+
+ vdd-supply = <&vreg_l10b_1p8>;
+ vddio-supply = <&vreg_l10b_1p8>;
+
+ mount-matrix = "0", "1", "0",
+ "0", "0", "1",
+ "1", "0", "0";
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -450,6 +511,13 @@ vreg_l9b_2p9: ldo9 {
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
+ vreg_l10b_1p8: ldo10 {
+ regulator-name = "vreg_l10b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
vreg_l12b_1p2: ldo12 {
regulator-name = "vreg_l12b_1p2";
regulator-min-microvolt = <1200000>;
@@ -1074,6 +1142,18 @@ &tlmm {
<76 4>, /* SPI19 (TZ Protected) */
<238 1>; /* UFS Reset */
+ acc_display_int_n_default: acc-display-int-n-state {
+ pins = "gpio29";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ acc_mobo_int_n_default: acc-mobo-int-n-state {
+ pins = "gpio28";
+ function = "gpio";
+ bias-pull-up;
+ };
+
cam_indicator_en: cam-indicator-en-state {
pins = "gpio110";
function = "gpio";
@@ -1197,6 +1277,20 @@ rtmr1_default: rtmr1-reset-n-active-state {
bias-disable;
};
+ sensors_i2c_display_default: sensors-i2c-display-state {
+ pins = "gpio231", "gpio232";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sensors_i2c_mobo_default: sensors-i2c-mobo-state {
+ pins = "gpio215", "gpio216";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
tpad_default: tpad-default-state {
disable-pins {
pins = "gpio38";
---
base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
change-id: 20260228-dell-xps-9345-accel-4ab40ed9c827
Best regards,
--
Aleksandrs Vinarskis <alex@vinarskis.com>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. Konrad
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? Alex P.S. rechecking my own series, it seems i2c node names I picked are illegal, will fix in v2. > > Konrad >
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
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@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.
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
On 3/23/26 6:05 PM, Dmitry Baryshkov 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@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.
>
> 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.
Aleksandrs, if you're interested in trying that one out:
https://codeberg.org/DylanVanAssche/libssc.git
Konrad
On Monday, March 23rd, 2026 at 18:05, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 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@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.
>
> 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
>
© 2016 - 2026 Red Hat, Inc.