arm64: dts: qcom: add initial device-tree for Microsoft Surface Duo
PATCH 1/1 arm64: dts: qcom: add initial device-tree for Microsoft Surface Duo
From: Felipe Balbi <[email protected]>
Microsoft Surface Duo is based on SM8150 chipset. This new Device Tree is a copy of sm8150-mtp with a the addition of the volume up key and relevant i2c nodes.
---
arch/arm64/boot/dts/qcom/Makefile | 1 + .../dts/qcom/sm8150-microsoft-surface-duo.dts | 545 ++++++++++++++++++ 2 files changed, 546 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
arch/arm64/boot/dts/qcom/Makefile +1 -0
@@ -70,6 +70,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-oneplus-fajita.dtb dtb-$(CONFIG_ARCH_QCOM) += sdm845-xiaomi-beryllium.dtb dtb-$(CONFIG_ARCH_QCOM) += sdm850-lenovo-yoga-c630.dtb dtb-$(CONFIG_ARCH_QCOM) += sm8150-hdk.dtb +dtb-$(CONFIG_ARCH_QCOM) += sm8150-microsoft-surface-duo.dtb dtb-$(CONFIG_ARCH_QCOM) += sm8150-mtp.dtb dtb-$(CONFIG_ARCH_QCOM) += sm8250-hdk.dtb dtb-$(CONFIG_ARCH_QCOM) += sm8250-mtp.dtb
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +545 -0
545 lines not on this page · raw message
Signature · 1 line
2.31.1
Quoted 6 lines · Felipe Balbi
From: Felipe Balbi <[email protected]>
Microsoft Surface Duo is based on SM8150 chipset. This new Device Tree is a copy of sm8150-mtp with a the addition of the volume up key and relevant i2c nodes.
This is really nice to see. Some comments below.
[..]
Quoted 58 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +52
-0@@ -0,0 +1,545 @@ +// SPDX-License-Identifier: BSD-3-Clause +/* + * Copyright (C) 2021, Microsoft Corporation + */ + +/dts-v1/; + +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> +#include <dt-bindings/gpio/gpio.h> +#include "sm8150.dtsi" +#include "pm8150.dtsi" +#include "pm8150b.dtsi" +#include "pm8150l.dtsi" + +/ { + model = "Microsoft Surface Duo"; + compatible = "microsoft,surface-duo", "qcom,sm8150-mtp"; + + aliases { + serial0 = &uart2; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; + + vph_pwr: vph-pwr-regulator { + compatible = "regulator-fixed"; + regulator-name = "vph_pwr"; + regulator-min-microvolt = <3700000>; + regulator-max-microvolt = <3700000>; + }; + + /* + * Apparently RPMh does not provide support for PM8150 S4 because it + * is always-on; model it as a fixed regulator. + */ + vreg_s4a_1p8: pm8150-s4 { + compatible = "regulator-fixed"; + regulator-name = "vreg_s4a_1p8"; + + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + + regulator-always-on; + regulator-boot-on; + + vin-supply = <&vph_pwr>; + }; + + gpio_keys { + compatible = "gpio-keys";
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 62
Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +10
-0+ + vol_up { + label = "Volume Up"; + gpios = <&pm8150_gpios 6 GPIO_ACTIVE_LOW>; + linux,code = <KEY_VOLUMEUP>; + }; + }; +}; + +&tlmm {
Please sort all nodes alphabetically.
Quoted 7 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +7
-0+ da7280_intr_default: da7280-intr-default { + pins = "gpio42"; + function = "gpio"; + bias-pull-up; + input-enable; + }; +};
[..]
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
Quoted 3 lines
+&remoteproc_adsp {
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +2
-0+ status = "okay"; + firmware-name = "qcom/sm8150/adsp.mdt";
For platforms where we have a Dragonboard or similar we push the test-signed firmware to qcom/<platform>/. I presume that the Duo wouldn't run on the test-signed firmware.
So I think it's better to make this qcom/sm8150/ms-duo/adsp.mdt...from the start.
Quoted 6 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +6
-0+}; + +&remoteproc_cdsp { + status = "okay"; + firmware-name = "qcom/sm8150/cdsp.mdt"; +};
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 485
Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +10
-0+ +&remoteproc_mpss { + status = "okay"; + firmware-name = "qcom/sm8150/modem.mdt"; +}; + +&remoteproc_slpi { + status = "okay"; + firmware-name = "qcom/sm8150/slpi.mdt"; +};
Regards,
Bjorn
Hi,
Quoted 62 lines · Bjorn Andersson
Quoted 62 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +56
-0@@ -0,0 +1,545 @@ +// SPDX-License-Identifier: BSD-3-Clause +/* + * Copyright (C) 2021, Microsoft Corporation + */ + +/dts-v1/; + +#include <dt-bindings/regulator/qcom,rpmh-regulator.h> +#include <dt-bindings/gpio/gpio.h> +#include "sm8150.dtsi" +#include "pm8150.dtsi" +#include "pm8150b.dtsi" +#include "pm8150l.dtsi" + +/ { + model = "Microsoft Surface Duo"; + compatible = "microsoft,surface-duo", "qcom,sm8150-mtp"; + + aliases { + serial0 = &uart2; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; + + vph_pwr: vph-pwr-regulator { + compatible = "regulator-fixed"; + regulator-name = "vph_pwr"; + regulator-min-microvolt = <3700000>; + regulator-max-microvolt = <3700000>; + }; + + /* + * Apparently RPMh does not provide support for PM8150 S4 because it + * is always-on; model it as a fixed regulator. + */ + vreg_s4a_1p8: pm8150-s4 { + compatible = "regulator-fixed"; + regulator-name = "vreg_s4a_1p8"; + + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + + regulator-always-on; + regulator-boot-on; + + vin-supply = <&vph_pwr>; + }; + + gpio_keys { + compatible = "gpio-keys"; + + vol_up { + label = "Volume Up"; + gpios = <&pm8150_gpios 6 GPIO_ACTIVE_LOW>;
Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 62
Quoted 6 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +6
-0+ linux,code = <KEY_VOLUMEUP>; + }; + }; +}; + +&tlmm {Please sort all nodes alphabetically.
will do.
Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 469
Quoted 3 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +3
-0+&remoteproc_adsp { + status = "okay"; + firmware-name = "qcom/sm8150/adsp.mdt";For platforms where we have a Dragonboard or similar we push the test-signed firmware to qcom/<platform>/. I presume that the Duo wouldn't run on the test-signed firmware.
So I think it's better to make this qcom/sm8150/ms-duo/adsp.mdt...from the start.
ms-duo would look odd. How about qcom/sm8150/microsoft/adsp.mdt?
Signature · 1 line
balbi
Quoted 2 lines · Felipe Balbi
Quoted 1 line · Bjorn Andersson
Quoted 1 line
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +0
-0
[..]
Quoted 8 lines
Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
Quoted 3 lines
+&remoteproc_adsp {
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +2
-0+ status = "okay"; + firmware-name = "qcom/sm8150/adsp.mdt";For platforms where we have a Dragonboard or similar we push the test-signed firmware to qcom/<platform>/. I presume that the Duo wouldn't run on the test-signed firmware.
Quoted 5 lines
Quoted 2 lines
So I think it's better to make this qcom/sm8150/ms-duo/adsp.mdt...from the start.
ms-duo would look odd. How about qcom/sm8150/microsoft/adsp.mdt?
Sounds good to me.
I do prefer using the non-split firmware package though (i.e. .mbn), if you don't have it you can repack the .mdt + .bNN files using
https://github.com/andersson/pil-squasher
Regards,
Bjorn
Quoted 18 lines · Bjorn Andersson
Quoted 2 lines · Felipe Balbi
Quoted 1 line · Bjorn Andersson
Quoted 1 line
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +0
-0[..]
Quoted 8 lines
Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
Quoted 3 lines
+&remoteproc_adsp {
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +2
-0+ status = "okay"; + firmware-name = "qcom/sm8150/adsp.mdt";For platforms where we have a Dragonboard or similar we push the test-signed firmware to qcom/<platform>/. I presume that the Duo wouldn't run on the test-signed firmware.
Quoted 5 lines
Quoted 2 lines
So I think it's better to make this qcom/sm8150/ms-duo/adsp.mdt...from the start.
ms-duo would look odd. How about qcom/sm8150/microsoft/adsp.mdt?
Quoted 6 lines
Sounds good to me.
I do prefer using the non-split firmware package though (i.e. .mbn), if you don't have it you can repack the .mdt + .bNN files using
Cool, I'll check if we have the non-split version and rename the FW files.
Signature · 1 line
balbi
Quoted 22 lines · Felipe Balbi
Quoted 20 lines · Bjorn Andersson
Quoted 2 lines · Felipe Balbi
Quoted 1 line · Bjorn Andersson
Quoted 1 line
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +0
-0[..]
Quoted 8 lines
Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
Quoted 3 lines
+&remoteproc_adsp {
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +2
-0+ status = "okay"; + firmware-name = "qcom/sm8150/adsp.mdt";For platforms where we have a Dragonboard or similar we push the test-signed firmware to qcom/<platform>/. I presume that the Duo wouldn't run on the test-signed firmware.
Quoted 5 lines
Quoted 2 lines
So I think it's better to make this qcom/sm8150/ms-duo/adsp.mdt...from the start.
ms-duo would look odd. How about qcom/sm8150/microsoft/adsp.mdt?
Sounds good to me.
Quoted 7 lines
Quoted 4 lines
I do prefer using the non-split firmware package though (i.e. .mbn), if you don't have it you can repack the .mdt + .bNN files using
Cool, I'll check if we have the non-split version and rename the FW files.
doesn't seem like pil-squasher works with our slpi image. Gives me a 0-byte image :-)
I would rather not touch the binaries if I can avoid it, though. Is this a strong requirement to use mbn rather than mdt?
Signature · 1 line
balbi
Quoted 27 lines · Felipe Balbi
Quoted 25 lines · Felipe Balbi
Quoted 23 lines · Bjorn Andersson
Quoted 2 lines · Felipe Balbi
Quoted 1 line · Bjorn Andersson
Quoted 1 line
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +0
-0[..]
Quoted 8 lines
Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
Quoted 3 lines
+&remoteproc_adsp {
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +2
-0+ status = "okay"; + firmware-name = "qcom/sm8150/adsp.mdt";For platforms where we have a Dragonboard or similar we push the test-signed firmware to qcom/<platform>/. I presume that the Duo wouldn't run on the test-signed firmware.
Quoted 5 lines
Quoted 2 lines
So I think it's better to make this qcom/sm8150/ms-duo/adsp.mdt...from the start.
ms-duo would look odd. How about qcom/sm8150/microsoft/adsp.mdt?
Sounds good to me.
I do prefer using the non-split firmware package though (i.e. .mbn), if you don't have it you can repack the .mdt + .bNN files using
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Cool, I'll check if we have the non-split version and rename the FW files.
doesn't seem like pil-squasher works with our slpi image. Gives me a 0-byte image :-)
If your files are available somewhere I'd be happy to take a look, if not patches are definitely welcome :)
Quoted 3 lines
I would rather not touch the binaries if I can avoid it, though. Is this a strong requirement to use mbn rather than mdt?
I've had numerous problems with things such as people upgrading N-1 files and having issues with the signature check just indicating that "something" is wrong. Squashing the files avoid these kind of problems.
But it's not a requirement!
Regards,
Bjorn
Quoted 45 lines · Bjorn Andersson
Quoted 27 lines · Felipe Balbi
Quoted 25 lines · Felipe Balbi
Quoted 23 lines · Bjorn Andersson
Quoted 2 lines · Felipe Balbi
Quoted 1 line · Bjorn Andersson
Quoted 1 line
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +0
-0[..]
Quoted 8 lines
Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
Quoted 3 lines
+&remoteproc_adsp {
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts +2
-0+ status = "okay"; + firmware-name = "qcom/sm8150/adsp.mdt";For platforms where we have a Dragonboard or similar we push the test-signed firmware to qcom/<platform>/. I presume that the Duo wouldn't run on the test-signed firmware.
Quoted 5 lines
Quoted 2 lines
So I think it's better to make this qcom/sm8150/ms-duo/adsp.mdt...from the start.
ms-duo would look odd. How about qcom/sm8150/microsoft/adsp.mdt?
Sounds good to me.
I do prefer using the non-split firmware package though (i.e. .mbn), if you don't have it you can repack the .mdt + .bNN files using
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Cool, I'll check if we have the non-split version and rename the FW files.
doesn't seem like pil-squasher works with our slpi image. Gives me a 0-byte image :-)
If your files are available somewhere I'd be happy to take a look, if not patches are definitely welcome :)
Quoted 3 lines
I would rather not touch the binaries if I can avoid it, though. Is this a strong requirement to use mbn rather than mdt?
Quoted 5 lines
I've had numerous problems with things such as people upgrading N-1 files and having issues with the signature check just indicating that "something" is wrong. Squashing the files avoid these kind of problems.
But it's not a requirement!
fair enough, I'll send a v2 as soon as I test everything on top of -rc4.
Signature · 1 line
balbi
Hi!
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 18
Quoted 4 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +4
-0+/ { + model = "Microsoft Surface Duo"; + compatible = "microsoft,surface-duo", "qcom,sm8150-mtp"; +
Please remove the -mtp compatible, as the phone is not 1:1 compatible with the MTP design and replace it with the platform-generic "qcom,sm8150" (otherwise things like CPUFreq won't work!).
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 26
Quoted 9 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +9
-0+ + aliases { + serial0 = &uart2; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; +
Is the serial port exposed and enabled on production hardware?
Quoted 30 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +30
-0+ + bq27742@55 { + compatible = "ti,bq27742"; + reg = <0x55>; + }; + + da7280@4a { + compatible = "dlg,da7280"; + reg = <0x4a>; + interrupts-extended = <&tlmm 42 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "da7280_default"; + pinctrl-0 = <&da7280_intr_default>; + + dlg,actuator-type = "LRA"; + dlg,dlg,const-op-mode = <1>; + dlg,dlg,periodic-op-mode = <1>; + dlg,nom-microvolt = <2000000>; + dlg,abs-max-microvolt = <2000000>; + dlg,imax-microamp = <129000>; + dlg,resonant-freq-hz = <180>; + dlg,impd-micro-ohms = <14300000>; + dlg,freq-track-enable; + dlg,bemf-sens-enable; + dlg,mem-array = < + 0x06 0x08 0x10 0x11 0x12 0x13 0x14 0x15 0x1c 0x2a + 0x33 0x3c 0x42 0x4b 0x4c 0x4e 0x17 0x19 0x27 0x29 + 0x17 0x19 0x03 0x84 0x5e 0x04 0x08 0x84 0x5d 0x01 + 0x84 0x5e 0x02 0x00 0xa4 0x5d 0x03 0x84 0x5e 0x06 + 0x08 0x84 0x5d 0x05 0x84 0x5d 0x06 0x84 0x5e 0x08 + 0x84 0x5e 0x05 0x8c 0x5e 0x24 0x84 0x5f 0x10 0x84
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 117
Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +10
-0+ 0x5e 0x05 0x84 0x5e 0x08 0x84 0x5f 0x01 0x8c 0x5e + 0x04 0x84 0x5e 0x08 0x84 0x5f 0x11 0x19 0x88 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + >; + }; + + /* SMB1381 @ 0x44 */ + /* MAX34417 @ 0x1c */ +};
Please add generic labels to these peripherals, such as "vibrator: " or so.
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 113
Quoted 9 lines
+&i2c17 {
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +8
-0+ status = "okay"; + clock-frequency = <400000>; + + bq27742@55 { + compatible = "ti,bq27742"; + reg = <0x55>; + }; +};
Are there actually two of these TI ICs, presumably for the dual-batteries? If that's the case, could you add a comment specifying which one is in charge (pun intended) of which cell?
Aside from that, it generally looks good :)
Konrad
Hi,
(please break lines at 80-columns)
Quoted 6 lines · Konrad Dybcio
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 18
Quoted 3 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +3
-0+ model = "Microsoft Surface Duo"; + compatible = "microsoft,surface-duo", "qcom,sm8150-mtp"; +Please remove the -mtp compatible, as the phone is not 1:1 compatible with the MTP design and replace it with the platform-generic "qcom,sm8150" (otherwise things like CPUFreq won't work!).
will do
Quoted 10 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 26
Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +8
-0+ aliases { + serial0 = &uart2; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; +Is the serial port exposed and enabled on production hardware?
nope, but we also use the same DTS for devBoards.
Quoted 33 lines
Quoted 33 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +33
-0+ bq27742@55 { + compatible = "ti,bq27742"; + reg = <0x55>; + }; + + da7280@4a { + compatible = "dlg,da7280"; + reg = <0x4a>; + interrupts-extended = <&tlmm 42 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "da7280_default"; + pinctrl-0 = <&da7280_intr_default>; + + dlg,actuator-type = "LRA"; + dlg,dlg,const-op-mode = <1>; + dlg,dlg,periodic-op-mode = <1>; + dlg,nom-microvolt = <2000000>; + dlg,abs-max-microvolt = <2000000>; + dlg,imax-microamp = <129000>; + dlg,resonant-freq-hz = <180>; + dlg,impd-micro-ohms = <14300000>; + dlg,freq-track-enable; + dlg,bemf-sens-enable; + dlg,mem-array = < + 0x06 0x08 0x10 0x11 0x12 0x13 0x14 0x15 0x1c 0x2a + 0x33 0x3c 0x42 0x4b 0x4c 0x4e 0x17 0x19 0x27 0x29 + 0x17 0x19 0x03 0x84 0x5e 0x04 0x08 0x84 0x5d 0x01 + 0x84 0x5e 0x02 0x00 0xa4 0x5d 0x03 0x84 0x5e 0x06 + 0x08 0x84 0x5d 0x05 0x84 0x5d 0x06 0x84 0x5e 0x08 + 0x84 0x5e 0x05 0x8c 0x5e 0x24 0x84 0x5f 0x10 0x84 + 0x5e 0x05 0x84 0x5e 0x08 0x84 0x5f 0x01 0x8c 0x5e + 0x04 0x84 0x5e 0x08 0x84 0x5f 0x11 0x19 0x88 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Quoted 8 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 117
Quoted 6 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +6
-0+ >; + }; + + /* SMB1381 @ 0x44 */ + /* MAX34417 @ 0x1c */ +};Please add generic labels to these peripherals, such as "vibrator: " or so.
why? They haven't been added yet, they don't even have drivers available. What extra information will a comment bring?
Quoted 11 lines
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts line 113
Quoted 9 lines
+&i2c17 {
arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts new file +8
-0+ status = "okay"; + clock-frequency = <400000>; + + bq27742@55 { + compatible = "ti,bq27742"; + reg = <0x55>; + }; +};Are there actually two of these TI ICs, presumably for the
yes
Quoted 2 lines
dual-batteries? If that's the case, could you add a comment specifying which one is in charge (pun intended) of which cell?
that's detected, and reported, by the HW itself. Also, what's the point if SW isn't really doing anything with the batteries other than checking charge level and such?
Signature · 1 line
balbi