From: Teguh Sobirin <teguh@sobir.in>
This adds a base dtb of everything common between the AYN QCS8550
devices. It is intended to be extended by device specific overlays.
Signed-off-by: Teguh Sobirin <teguh@sobir.in>
Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
2 files changed, 1778 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 02921a495b2cbabcbacc74fbbb99eafe1f6478ac..5bb88dd7a31bbd8ee7078a880056cc1f35be494e 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -163,6 +163,7 @@ qcs8300-ride-el2-dtbs := qcs8300-ride.dtb monaco-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride-el2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs8550-ayntec-common.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts b/arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts
new file mode 100644
index 0000000000000000000000000000000000000000..23135606c812d0b1e8de828e286c3702dc781783
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts
@@ -0,0 +1,1777 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025, Teguh Sobirin.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "qcs8550.dtsi"
+#include "pm8550.dtsi"
+#include "pm8550b.dtsi"
+#define PMK8550VE_SID 5
+#include "pm8550ve.dtsi"
+#include "pm8550vs.dtsi"
+#include "pmk8550.dtsi"
+
+/delete-node/ &aop_image_mem;
+/delete-node/ &aop_config_mem;
+/delete-node/ &camera_mem;
+/delete-node/ &ipa_fw_mem;
+/delete-node/ &ipa_gsi_mem;
+/delete-node/ &mpss_dsm_mem;
+/delete-node/ &mpss_mem;
+/delete-node/ &q6_mpss_dtb_mem;
+/delete-node/ &remoteproc_mpss;
+
+/ {
+ model = "AYN QCS8550 Common";
+ compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
+ chassis-type = "handset";
+
+ aliases {
+ serial0 = &uart7;
+ serial1 = &uart14;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&volume_up_n>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ debounce-interval = <15>;
+ gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ linux,can-disable;
+ wakeup-source;
+ };
+ };
+
+ pmic-glink {
+ compatible = "qcom,sm8550-pmic-glink", "qcom,pmic-glink";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ orientation-gpios = <&tlmm 11 GPIO_ACTIVE_HIGH>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in: endpoint {
+ remote-endpoint = <&usb_1_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss_in: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ pmic_glink_sbu: endpoint {
+ remote-endpoint = <&usb0_sbu_mux>;
+ };
+ };
+ };
+ };
+ };
+
+ pwm_fan: pwm-fan {
+ compatible = "pwm-fan";
+
+ fan-supply = <&vdd_fan_5v0>;
+ pwms = <&pm8550_pwm 3 50000>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&fan_pwm_active>, <&fan_int>;
+
+ pulses-per-revolution = <4>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+
+ cooling-levels = <0 40 65 75 90 100 120 150 175>;
+ #cooling-cells = <2>;
+ };
+
+ reserved-memory {
+ hyp_mem: hyp-region@80000000 {
+ reg = <0 0x80000000 0 0xa00000>;
+ no-map;
+ };
+
+ cpusys_vm_mem: cpusys-vm-region@80a00000 {
+ reg = <0 0x80a00000 0 0x400000>;
+ no-map;
+ };
+
+ hyp_tags_mem: hyp-tags-region@80e00000 {
+ reg = <0 0x80e00000 0 0x3d0000>;
+ no-map;
+ };
+
+ xbl_sc_mem: xbl-sc-region@d8100000 {
+ reg = <0 0xd8100000 0 0x40000>;
+ no-map;
+ };
+
+ hyp_tags_reserved_mem: hyp-tags-reserved-region@811d0000 {
+ reg = <0 0x811d0000 0 0x30000>;
+ no-map;
+ };
+
+ xbl_dt_log_merged_mem: xbl-dt-log-merged-region@81a00000 {
+ reg = <0 0x81a00000 0 0x260000>;
+ no-map;
+ };
+
+ aop_config_merged_mem: aop-config-merged-region@81c80000 {
+ reg = <0 0x81c80000 0 0x74000>;
+ no-map;
+ };
+
+ chipinfo_mem: chipinfo-region@81cf4000 {
+ reg = <0 0x81cf4000 0 0x1000>;
+ no-map;
+ };
+
+ global_sync_mem: global-sync-region@82600000 {
+ reg = <0 0x82600000 0 0x100000>;
+ no-map;
+ };
+
+ tz_stat_mem: tz-stat-region@82700000 {
+ reg = <0 0x82700000 0 0x100000>;
+ no-map;
+ };
+
+ cpucp_fw_mem: cpucp-fw-region@d8140000 {
+ reg = <0 0xd8140000 0 0x1c0000>;
+ no-map;
+ };
+
+ qtee_mem: qtee-region@d8300000 {
+ reg = <0 0xd8300000 0 0x500000>;
+ no-map;
+ };
+
+ hwfence_shbuf: hwfence-shbuf-region@e6440000 {
+ reg = <0 0xe6440000 0 0x2dd000>;
+ no-map;
+ };
+
+ hyp_ext_reserved_mem: hyp-ext-reserved-region@ff700000 {
+ reg = <0 0xff700000 0 0x100000>;
+ no-map;
+ };
+
+ llcc_lpi_mem: llcc_lpi_region@ff800000 {
+ reg = <0 0xff800000 0 0x600000>;
+ no-map;
+ };
+
+ hyp_ext_tags_mem: hyp-ext-tags-region@fce00000 {
+ reg = <0 0xfce00000 0 0x2900000>;
+ no-map;
+ };
+ };
+
+ sound {
+ compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
+ pinctrl-0 = <&lpi_i2s3_active>;
+ pinctrl-names = "default";
+
+ model = "AYN-Odin2";
+ audio-routing =
+ "IN1_HPHL", "HPHL_OUT",
+ "IN2_HPHR", "HPHR_OUT",
+ "AMIC2", "MIC BIAS2",
+ "TX SWR_INPUT1", "ADC2_OUTPUT";
+
+ speaker-i2s-dai-link {
+ link-name = "Primary MI2S Playback";
+
+ cpu {
+ sound-dai = <&q6apmbedai PRIMARY_MI2S_RX>;
+ };
+
+ codec {
+ sound-dai = <&spk_amp_l>, <&spk_amp_r>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ wcd-playback-dai-link {
+ link-name = "WCD Playback";
+
+ cpu {
+ sound-dai = <&q6apmbedai RX_CODEC_DMA_RX_0>;
+ };
+
+ codec {
+ sound-dai = <&wcd938x 0>, <&swr1 0>, <&lpass_rxmacro 0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ wcd-capture-dai-link {
+ link-name = "WCD Capture";
+
+ cpu {
+ sound-dai = <&q6apmbedai TX_CODEC_DMA_TX_3>;
+ };
+
+ codec {
+ sound-dai = <&wcd938x 1>, <&swr2 0>, <&lpass_txmacro 0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ dp0-dai-link {
+ link-name = "DP0 Playback";
+ cpu {
+ sound-dai = <&q6apmbedai DISPLAY_PORT_RX_0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+
+ codec {
+ sound-dai = <&mdss_dp0>;
+ };
+ };
+ };
+
+ thermal-zones {
+ cpu0-thermal {
+ polling-delay = <200>;
+
+ trips {
+ cpuss0_active0: cpu-active0 {
+ temperature = <50000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss0_active1: cpu-active1 {
+ temperature = <55000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss0_active2: cpu-active2 {
+ temperature = <60000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss0_active3: cpu-active3 {
+ temperature = <65000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss0_active4: cpu-active4 {
+ temperature = <70000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss0_active5: cpu-active5 {
+ temperature = <75000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss0_active6: cpu-active6 {
+ temperature = <80000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss0_active7: cpu-active7 {
+ temperature = <85000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ cooling-device = <&pwm_fan 0 1>;
+ trip = <&cpuss0_active0>;
+ };
+
+ map1 {
+ cooling-device = <&pwm_fan 1 2>;
+ trip = <&cpuss0_active1>;
+ };
+
+ map2 {
+ cooling-device = <&pwm_fan 2 3>;
+ trip = <&cpuss0_active2>;
+ };
+
+ map3 {
+ cooling-device = <&pwm_fan 3 4>;
+ trip = <&cpuss0_active3>;
+ };
+
+ map4 {
+ cooling-device = <&pwm_fan 4 5>;
+ trip = <&cpuss0_active4>;
+ };
+
+ map5 {
+ cooling-device = <&pwm_fan 5 6>;
+ trip = <&cpuss0_active5>;
+ };
+
+ map6 {
+ cooling-device = <&pwm_fan 6 7>;
+ trip = <&cpuss0_active6>;
+ };
+
+ map7 {
+ cooling-device = <&pwm_fan 7 8>;
+ trip = <&cpuss0_active7>;
+ };
+ };
+ };
+
+ cpu3-bottom-thermal {
+ polling-delay = <200>;
+
+ trips {
+ cpuss3_active0: cpu-active0 {
+ temperature = <50000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss3_active1: cpu-active1 {
+ temperature = <55000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss3_active2: cpu-active2 {
+ temperature = <60000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss3_active3: cpu-active3 {
+ temperature = <65000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss3_active4: cpu-active4 {
+ temperature = <70000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss3_active5: cpu-active5 {
+ temperature = <75000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss3_active6: cpu-active6 {
+ temperature = <80000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss3_active7: cpu-active7 {
+ temperature = <85000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ cooling-device = <&pwm_fan 0 1>;
+ trip = <&cpuss3_active0>;
+ };
+
+ map1 {
+ cooling-device = <&pwm_fan 1 2>;
+ trip = <&cpuss3_active1>;
+ };
+
+ map2 {
+ cooling-device = <&pwm_fan 2 3>;
+ trip = <&cpuss3_active2>;
+ };
+
+ map3 {
+ cooling-device = <&pwm_fan 3 4>;
+ trip = <&cpuss3_active3>;
+ };
+
+ map4 {
+ cooling-device = <&pwm_fan 4 5>;
+ trip = <&cpuss3_active4>;
+ };
+
+ map5 {
+ cooling-device = <&pwm_fan 5 6>;
+ trip = <&cpuss3_active5>;
+ };
+
+ map6 {
+ cooling-device = <&pwm_fan 6 7>;
+ trip = <&cpuss3_active6>;
+ };
+
+ map7 {
+ cooling-device = <&pwm_fan 7 8>;
+ trip = <&cpuss3_active7>;
+ };
+ };
+ };
+
+ cpu7-bottom-thermal {
+ polling-delay = <200>;
+
+ trips {
+ cpuss7_active0: cpu-active0 {
+ temperature = <50000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss7_active1: cpu-active1 {
+ temperature = <55000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss7_active2: cpu-active2 {
+ temperature = <60000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss7_active3: cpu-active3 {
+ temperature = <65000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss7_active4: cpu-active4 {
+ temperature = <70000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss7_active5: cpu-active5 {
+ temperature = <75000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss7_active6: cpu-active6 {
+ temperature = <80000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ cpuss7_active7: cpu-active7 {
+ temperature = <85000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ cooling-device = <&pwm_fan 0 1>;
+ trip = <&cpuss7_active0>;
+ };
+
+ map1 {
+ cooling-device = <&pwm_fan 1 2>;
+ trip = <&cpuss7_active1>;
+ };
+
+ map2 {
+ cooling-device = <&pwm_fan 2 3>;
+ trip = <&cpuss7_active2>;
+ };
+
+ map3 {
+ cooling-device = <&pwm_fan 3 4>;
+ trip = <&cpuss7_active3>;
+ };
+
+ map4 {
+ cooling-device = <&pwm_fan 4 5>;
+ trip = <&cpuss7_active4>;
+ };
+
+ map5 {
+ cooling-device = <&pwm_fan 5 6>;
+ trip = <&cpuss7_active5>;
+ };
+
+ map6 {
+ cooling-device = <&pwm_fan 6 7>;
+ trip = <&cpuss7_active6>;
+ };
+
+ map7 {
+ cooling-device = <&pwm_fan 7 8>;
+ trip = <&cpuss7_active7>;
+ };
+ };
+ };
+
+ gpuss-0-thermal {
+ polling-delay = <200>;
+
+ trips {
+ gpuss0_active0: gpu-active0 {
+ temperature = <50000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ gpuss0_active1: gpu-active1 {
+ temperature = <55000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ gpuss0_active2: gpu-active2 {
+ temperature = <60000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ gpuss0_active3: gpu-active3 {
+ temperature = <65000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ gpuss0_active4: gpu-active4 {
+ temperature = <70000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ gpuss0_active5: gpu-active5 {
+ temperature = <75000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ gpuss0_active6: gpu-active6 {
+ temperature = <80000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+
+ gpuss0_active7: gpu-active7 {
+ temperature = <85000>;
+ hysteresis = <4000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ cooling-device = <&pwm_fan 0 1>;
+ trip = <&gpuss0_active0>;
+ };
+
+ map1 {
+ cooling-device = <&pwm_fan 1 2>;
+ trip = <&gpuss0_active1>;
+ };
+
+ map2 {
+ cooling-device = <&pwm_fan 2 3>;
+ trip = <&gpuss0_active2>;
+ };
+
+ map3 {
+ cooling-device = <&pwm_fan 3 4>;
+ trip = <&gpuss0_active3>;
+ };
+
+ map4 {
+ cooling-device = <&pwm_fan 4 5>;
+ trip = <&gpuss0_active4>;
+ };
+
+ map5 {
+ cooling-device = <&pwm_fan 5 6>;
+ trip = <&gpuss0_active5>;
+ };
+
+ map6 {
+ cooling-device = <&pwm_fan 6 7>;
+ trip = <&gpuss0_active6>;
+ };
+
+ map7 {
+ cooling-device = <&pwm_fan 7 8>;
+ trip = <&gpuss0_active7>;
+ };
+ };
+ };
+ };
+
+ usb0-sbu-mux {
+ compatible = "pericom,pi3usb102", "gpio-sbu-mux";
+
+ enable-gpios = <&tlmm 140 GPIO_ACTIVE_LOW>;
+ select-gpios = <&tlmm 141 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_sbu_default>;
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ usb0_sbu_mux: endpoint {
+ remote-endpoint = <&pmic_glink_sbu>;
+ };
+ };
+ };
+
+ vdd_fan_5v0: vdd-fan-5v0-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_fan_5v0";
+
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+
+ gpio = <&tlmm 109 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&fan_pwr_active>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_mcu_3v3: vdd-mcu-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_mcu_3v3";
+
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+ };
+
+ vph_pwr: regulator-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ wcd938x: audio-codec {
+ compatible = "qcom,wcd9385-codec";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&wcd_default>;
+
+ qcom,micbias1-microvolt = <1800000>;
+ qcom,micbias2-microvolt = <1800000>;
+ qcom,micbias3-microvolt = <1800000>;
+ qcom,micbias4-microvolt = <1800000>;
+ qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000
+ 500000 500000 500000 500000>;
+ qcom,mbhc-headset-vthreshold-microvolt = <1700000>;
+ qcom,mbhc-headphone-vthreshold-microvolt = <50000>;
+ qcom,rx-device = <&wcd_rx>;
+ qcom,tx-device = <&wcd_tx>;
+
+ reset-gpios = <&tlmm 108 GPIO_ACTIVE_LOW>;
+
+ vdd-buck-supply = <&vreg_l15b_1p8>;
+ vdd-rxtx-supply = <&vreg_l15b_1p8>;
+ vdd-io-supply = <&vreg_l15b_1p8>;
+ vdd-mic-bias-supply = <&vreg_bob1>;
+
+ #sound-dai-cells = <1>;
+ };
+
+ wcn7850-pmu {
+ compatible = "qcom,wcn7850-pmu";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_en>, <&bt_default>, <&pmk8550_sleep_clk>;
+
+ wlan-enable-gpios = <&tlmm 80 GPIO_ACTIVE_HIGH>;
+ bt-enable-gpios = <&tlmm 81 GPIO_ACTIVE_HIGH>;
+
+ vdd-supply = <&vreg_s5g_0p8>;
+ vddio-supply = <&vreg_l15b_1p8>;
+ vddaon-supply = <&vreg_s2g_0p8>;
+ vdddig-supply = <&vreg_s4e_0p95>;
+ vddrfa1p2-supply = <&vreg_s4g_1p3>;
+ vddrfa1p8-supply = <&vreg_s6g_1p8>;
+
+ regulators {
+ vreg_pmu_rfa_cmn: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn";
+ };
+
+ vreg_pmu_aon_0p59: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p59";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p85: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p85";
+ };
+
+ vreg_pmu_btcmx_0p85: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p85";
+ };
+
+ vreg_pmu_rfa_0p8: ldo5 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo6 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p8: ldo7 {
+ regulator-name = "vreg_pmu_rfa_1p8";
+ };
+
+ vreg_pmu_pcie_0p9: ldo8 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_pcie_1p8: ldo9 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm8550-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd-bob1-supply = <&vph_pwr>;
+ vdd-bob2-supply = <&vph_pwr>;
+ vdd-l1-l4-l10-supply = <&vreg_s6g_1p8>;
+ vdd-l2-l13-l14-supply = <&vreg_bob1>;
+ vdd-l3-supply = <&vreg_s4g_1p3>;
+ vdd-l5-l16-supply = <&vreg_bob1>;
+ vdd-l6-l7-supply = <&vreg_bob1>;
+ vdd-l8-l9-supply = <&vreg_bob1>;
+ vdd-l11-supply = <&vreg_s4g_1p3>;
+ vdd-l12-supply = <&vreg_s6g_1p8>;
+ vdd-l15-supply = <&vreg_s6g_1p8>;
+ vdd-l17-supply = <&vreg_bob2>;
+
+ vreg_bob1: bob1 {
+ regulator-name = "vreg_bob1";
+ regulator-min-microvolt = <3296000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_bob2: bob2 {
+ regulator-name = "vreg_bob2";
+ regulator-min-microvolt = <2720000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2b_3p0: ldo2 {
+ regulator-name = "vreg_l2b_3p0";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5b_3p1: ldo5 {
+ regulator-name = "vreg_l5b_3p1";
+ regulator-min-microvolt = <3104000>;
+ regulator-max-microvolt = <3104000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6b_1p8: ldo6 {
+ regulator-name = "vreg_l6b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_1p8: ldo7 {
+ regulator-name = "vreg_l7b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8b_1p8: ldo8 {
+ regulator-name = "vreg_l8b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_2p9: ldo9 {
+ regulator-name = "vreg_l9b_2p9";
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11b_1p2: ldo11 {
+ regulator-name = "vreg_l11b_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1504000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12b_1p8: ldo12 {
+ regulator-name = "vreg_l12b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l13b_3p0: ldo13 {
+ regulator-name = "vreg_l13b_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l14b_3p2: ldo14 {
+ regulator-name = "vreg_l14b_3p2";
+ regulator-min-microvolt = <3200000>;
+ regulator-max-microvolt = <3200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_1p8: ldo15 {
+ regulator-name = "vreg_l15b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l16b_2p8: ldo16 {
+ regulator-name = "vreg_l16b_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_2p5: ldo17 {
+ regulator-name = "vreg_l17b_2p5";
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <2504000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vdd-l1-supply = <&vreg_s4g_1p3>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+
+ vreg_l3c_0p9: ldo3 {
+ regulator-name = "vreg_l3c_0p9";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-2 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "d";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+
+ vreg_l1d_0p88: ldo1 {
+ regulator-name = "vreg_l1d_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-3 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "e";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4g_1p3>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+
+ vreg_s4e_0p95: smps4 {
+ regulator-name = "vreg_s4e_0p95";
+ regulator-min-microvolt = <904000>;
+ regulator-max-microvolt = <984000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5e_1p08: smps5 {
+ regulator-name = "vreg_s5e_1p08";
+ regulator-min-microvolt = <1010000>;
+ regulator-max-microvolt = <1120000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1e_0p88: ldo1 {
+ regulator-name = "vreg_l1e_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2e_0p9: ldo2 {
+ regulator-name = "vreg_l2e_0p9";
+ regulator-min-microvolt = <870000>;
+ regulator-max-microvolt = <970000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3e_1p2: ldo3 {
+ regulator-name = "vreg_l3e_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-4 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+ qcom,pmic-id = "f";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+ vdd-s4-supply = <&vph_pwr>;
+
+ vreg_s4f_0p5: smps4 {
+ regulator-name = "vreg_s4f_0p5";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <700000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1f_0p9: ldo1 {
+ regulator-name = "vreg_l1f_0p9";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2f_0p88: ldo2 {
+ regulator-name = "vreg_l2f_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3f_0p88: ldo3 {
+ regulator-name = "vreg_l3f_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-5 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "g";
+
+ vdd-l1-supply = <&vreg_s4g_1p3>;
+ vdd-l2-supply = <&vreg_s4g_1p3>;
+ vdd-l3-supply = <&vreg_s4g_1p3>;
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s6-supply = <&vph_pwr>;
+
+ vreg_s1g_1p2: smps1 {
+ regulator-name = "vreg_s1g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s2g_0p8: smps2 {
+ regulator-name = "vreg_s2g_0p8";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s3g_0p7: smps3 {
+ regulator-name = "vreg_s3g_0p7";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1004000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4g_1p3: smps4 {
+ regulator-name = "vreg_s4g_1p3";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1352000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5g_0p8: smps5 {
+ regulator-name = "vreg_s5g_0p8";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1004000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s6g_1p8: smps6 {
+ regulator-name = "vreg_s6g_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1g_1p2: ldo1 {
+ regulator-name = "vreg_l1g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3g_1p2: ldo3 {
+ regulator-name = "vreg_l3g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&gpi_dma2 {
+ status = "okay";
+};
+
+&gpu {
+ status = "okay";
+
+ zap-shader {
+ firmware-name = "qcom/sm8550/a740_zap.mbn";
+ };
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ status = "okay";
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+ status = "okay";
+};
+
+&i2c12 {
+ clock-frequency = <400000>;
+ status = "okay";
+};
+
+&i2c_master_hub_0 {
+ status = "okay";
+};
+
+&i2c_hub_2 {
+ clock-frequency = <400000>;
+ status = "okay";
+
+ spk_amp_l: spk_amp_l@34 {
+ compatible = "awinic,aw88166";
+ reg = <0x34>;
+ #sound-dai-cells = <0>;
+ reset-gpios = <&tlmm 103 GPIO_ACTIVE_LOW>;
+ awinic,audio-channel = <0>;
+ awinic,sync-flag;
+ sound-name-prefix = "SPK_L";
+ };
+
+ spk_amp_r: spk_amp_r@35 {
+ compatible = "awinic,aw88166";
+ reg = <0x35>;
+ #sound-dai-cells = <0>;
+ reset-gpios = <&tlmm 100 GPIO_ACTIVE_LOW>;
+ awinic,audio-channel = <1>;
+ awinic,sync-flag;
+ sound-name-prefix = "SPK_R";
+ };
+};
+
+&iris {
+ status = "okay";
+};
+
+&lpass_tlmm {
+ lpi_i2s3_active: lpi_i2s3-active-state {
+ sck-pins {
+ pins = "gpio12";
+ function = "i2s3_clk";
+ drive-strength = <8>;
+ bias-disable;
+ output-high;
+ };
+
+ ws-pins {
+ pins = "gpio13";
+ function = "i2s3_ws";
+ drive-strength = <8>;
+ bias-disable;
+ output-high;
+ };
+
+ data0-pins {
+ pins = "gpio17";
+ function = "i2s3_data";
+ drive-strength = <8>;
+ bias-disable;
+ output-high;
+ };
+
+ data1-pins {
+ pins = "gpio18";
+ function = "i2s3_data";
+ drive-strength = <8>;
+ bias-disable;
+ output-high;
+ };
+ };
+};
+
+&lpass_vamacro {
+ qcom,dmic-sample-rate = <4800000>;
+};
+
+&lpass_wsamacro {
+ status = "disabled";
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_dp0 {
+ status = "okay";
+};
+
+&mdss_dsi1 {
+ vdda-supply = <&vreg_l3e_1p2>;
+ status = "okay";
+
+ display_panel: panel@0 {
+ reg = <0>;
+
+ port {
+ panel1_in: endpoint {
+ remote-endpoint = <&mdss_dsi1_out>;
+ };
+ };
+ };
+};
+
+&mdss_dsi1_out {
+ remote-endpoint = <&panel1_in>;
+ data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi1_phy {
+ vdds-supply = <&vreg_l1e_0p88>;
+ status = "okay";
+};
+
+&pcie0 {
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcieport0 {
+ wifi@0 {
+ compatible = "pci17cb,1107";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+ vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+ vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+ };
+};
+
+&pcie0_phy {
+ vdda-phy-supply = <&vreg_l1e_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&pm8550_gpios {
+ fan_pwm_active: fan-pwm-active-state {
+ pins = "gpio8";
+ function = "func1";
+ input-disable;
+ output-enable;
+ output-low;
+ bias-disable;
+ power-source = <1>;
+ };
+
+ sdc2_card_det_n: sdc2-card-det-n-state {
+ pins = "gpio12";
+ function = "normal";
+ input-enable;
+ output-disable;
+ bias-pull-up;
+ power-source = <1>;
+ };
+
+ volume_up_n: volume-up-n-state {
+ pins = "gpio6";
+ function = "normal";
+ power-source = <1>;
+ bias-pull-up;
+ input-enable;
+ };
+};
+
+&pm8550_pwm {
+ status = "okay";
+
+ multi-led {
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_STATUS;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@3 {
+ reg = <3>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+};
+
+&pm8550b_eusb2_repeater {
+ qcom,tune-usb2-disc-thres = /bits/ 8 <0x6>;
+ qcom,tune-usb2-amplitude = /bits/ 8 <0xb>;
+ qcom,tune-usb2-preem = /bits/ 8 <0x3>;
+ vdd18-supply = <&vreg_l15b_1p8>;
+ vdd3-supply = <&vreg_l5b_3p1>;
+};
+
+&pmk8550_gpios {
+ pmk8550_sleep_clk: sleep-clk-state {
+ pins = "gpio3";
+ function = "func1";
+ input-disable;
+ output-enable;
+ bias-disable;
+ power-source = <0>;
+ };
+
+ pwm_backlight_default: pwm-backlight-default-state {
+ pins = "gpio5";
+ function = "func3";
+ input-disable;
+ output-low;
+ output-enable;
+ bias-disable;
+ power-source = <0>;
+ qcom,drive-strength = <2>;
+ };
+};
+
+&pmk8550_rtc {
+ nvmem-cells = <&rtc_offset>;
+ nvmem-cell-names = "offset";
+};
+
+&pmk8550_sdam_2 {
+ rtc_offset: rtc-offset@bc {
+ reg = <0xbc 0x4>;
+ };
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+
+ status = "okay";
+};
+
+&qupv3_id_0 {
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm8550/ayntec/cdsp.mbn",
+ "qcom/sm8550/ayntec/cdsp_dtb.mbn";
+ status = "okay";
+};
+
+&sdhc_2 {
+ cd-gpios = <&pm8550_gpios 12 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&sdc2_default &sdc2_card_det_n>;
+ pinctrl-1 = <&sdc2_sleep &sdc2_card_det_n>;
+ vmmc-supply = <&vreg_l9b_2p9>;
+ vqmmc-supply = <&vreg_l8b_1p8>;
+ max-sd-hs-hz = <37500000>;
+ no-sdio;
+ no-mmc;
+
+ qcom,dll-config = <0x0007442c>;
+
+ status = "okay";
+};
+
+&sleep_clk {
+ clock-frequency = <32764>;
+};
+
+&swr1 {
+ status = "okay";
+ wcd_rx: codec@0,4 {
+ compatible = "sdw20217010d00";
+ reg = <0 4>;
+ qcom,rx-port-mapping = <1 2 3 4 5>;
+ };
+};
+
+&swr2 {
+ status = "okay";
+ wcd_tx: codec@0,3 {
+ compatible = "sdw20217010d00";
+ reg = <0 3>;
+ qcom,tx-port-mapping = <2 2 3 4>;
+ };
+};
+
+&tlmm {
+ gpio-reserved-ranges = <32 8>;
+
+ dsi_p_rst_active: dsi-p-rst-active-state {
+ pins = "gpio133";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ dsi_p_rst_suspend: dsi-p-rst-suspend-state {
+ pins = "gpio133";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ dsi_p_te_active: dsi-p-te-active-state {
+ pins = "gpio86";
+ function = "mdp_vsync";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ dsi_p_te_suspend: dsi-s-te-suspend-state {
+ pins = "gpio86";
+ function = "mdp_vsync";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ dsi_s_rst_active: dsi-s-rst-active-state {
+ pins = "gpio137";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ dsi_s_rst_suspend: dsi-s-rst-suspend-state {
+ pins = "gpio137";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ dsi_s_te_active: dsi-s-te-active-state {
+ pins = "gpio87";
+ function = "mdp_vsync";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ dsi_s_te_suspend: dsi-s-te-suspend-state {
+ pins = "gpio87";
+ function = "mdp_vsync";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ bt_default: bt-default-state {
+ bt-en-pins {
+ pins = "gpio81";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ sw-ctrl-pins {
+ pins = "gpio82";
+ function = "gpio";
+ bias-pull-down;
+ };
+ };
+
+ fan_pwr_active: fan-pwr-active-state {
+ pins = "gpio109";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-low;
+ };
+
+ fan_int: fan-int-state {
+ pins = "gpio13";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ mcu_en_active: mcu-en-active-state {
+ pins = "gpio12";
+ function = "gpio";
+ bias-pull-down;
+ };
+
+ ts_p_rst_default: ts-p-rst-default-state {
+ pins = "gpio24";
+ function = "gpio";
+ bias-pull-up;
+ drive-strength = <8>;
+ };
+
+ ts_p_rst_sleep: ts-p-rst-sleep-state {
+ pins = "gpio24";
+ function = "gpio";
+ bias-pull-down;
+ drive-strength = <2>;
+ };
+
+ ts_p_int_default: ts-p-int-default-state {
+ pins = "gpio25";
+ function = "gpio";
+ bias-pull-up;
+ drive-strength = <8>;
+ };
+
+ ts_p_int_sleep: ts-p-int-sleep-state {
+ pins = "gpio25";
+ function = "gpio";
+ bias-pull-down;
+ drive-strength = <2>;
+ };
+
+ ts_s_rst_default: ts-s-rst-default-state {
+ pins = "gpio14";
+ function = "gpio";
+ bias-pull-up;
+ drive-strength = <8>;
+ };
+
+ ts_s_rst_sleep: ts-s-rst-sleep-state {
+ pins = "gpio14";
+ function = "gpio";
+ bias-pull-down;
+ drive-strength = <2>;
+ };
+
+ ts_s_int_default: ts-s-int-default-state {
+ pins = "gpio15";
+ function = "gpio";
+ bias-pull-up;
+ drive-strength = <8>;
+ };
+
+ ts_s_int_sleep: ts-s-int-sleep-state {
+ pins = "gpio15";
+ function = "gpio";
+ bias-pull-down;
+ drive-strength = <2>;
+ };
+
+ usb0_sbu_default: usb0-sbu-state {
+ oe-n-pins {
+ pins = "gpio140";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <16>;
+ output-high;
+ };
+
+ sel-pins {
+ pins = "gpio141";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <16>;
+ };
+ };
+
+ wcd_default: wcd-reset-n-active-state {
+ pins = "gpio108";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ output-low;
+ };
+
+ wlan_en: wlan-en-state {
+ pins = "gpio80";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-down;
+ };
+};
+
+&uart7 {
+ status = "okay";
+};
+
+&uart14 {
+ status = "okay";
+
+ bluetooth {
+ compatible = "qcom,wcn7850-bt";
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+
+ max-speed = <3200000>;
+ };
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l17b_2p5>;
+ vcc-max-microamp = <1300000>;
+ vccq-supply = <&vreg_l1g_1p2>;
+ vccq-max-microamp = <1200000>;
+ vdd-hba-supply = <&vreg_l3g_1p2>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l1d_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&usb_1 {
+ status = "okay";
+};
+
+&usb_1_dwc3_hs {
+ remote-endpoint = <&pmic_glink_hs_in>;
+};
+
+&usb_1_hsphy {
+ phys = <&pm8550b_eusb2_repeater>;
+
+ vdd-supply = <&vreg_l1e_0p88>;
+ vdda12-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy {
+ vdda-phy-supply = <&vreg_l3e_1p2>;
+ vdda-pll-supply = <&vreg_l3f_0p88>;
+
+ mode-switch;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss_in>;
+};
+
+&xo_board {
+ clock-frequency = <76800000>;
+};
--
2.53.0On 3/11/26 6:44 PM, Aaron Kling via B4 Relay wrote:
> From: Teguh Sobirin <teguh@sobir.in>
>
> This adds a base dtb of everything common between the AYN QCS8550
> devices. It is intended to be extended by device specific overlays.
>
> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
[...]
> + pwm_fan: pwm-fan {
> + compatible = "pwm-fan";
> +
> + fan-supply = <&vdd_fan_5v0>;
> + pwms = <&pm8550_pwm 3 50000>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&fan_pwm_active>, <&fan_int>;
property-n
property-names
in this order, everywhere, please
> +
> + pulses-per-revolution = <4>;
> + interrupt-parent = <&tlmm>;
> + interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
interrupts-extended = <&tlmm 13 IRQ_...>;
[...]
> + model = "AYN-Odin2";
> + audio-routing =
> + "IN1_HPHL", "HPHL_OUT",
Let's drop this empty linebreak
> + "IN2_HPHR", "HPHR_OUT",
> + "AMIC2", "MIC BIAS2",
> + "TX SWR_INPUT1", "ADC2_OUTPUT";
> +
> + speaker-i2s-dai-link {
> + link-name = "Primary MI2S Playback";
> +
> + cpu {
> + sound-dai = <&q6apmbedai PRIMARY_MI2S_RX>;
> + };
'co'dec < 'cp'u, please resort
[...]
> + vdd_fan_5v0: vdd-fan-5v0-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_fan_5v0";
> +
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> +
> + gpio = <&tlmm 109 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&fan_pwr_active>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
oh, I didn't know this binding existed.. but it seems valid indeed!
[...]
> +&i2c12 {
> + clock-frequency = <400000>;
> + status = "okay";
Let's uniformly keep a \n before status
> +};
> +
> +&i2c_master_hub_0 {
> + status = "okay";
Please add a clock-frequency
(you can read it back at runtime running a vendor kernel if you don't have a
better source)
[...]
> + spk_amp_l: spk_amp_l@34 {
underscores are no bueno in node names (between ':' and '@'), and they should
be generic, let's try amplifier@
[...]
> +&iris {
> + status = "okay";
firmware-name?
[...]
> +&sdhc_2 {
> + cd-gpios = <&pm8550_gpios 12 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&sdc2_default &sdc2_card_det_n>;
> + pinctrl-1 = <&sdc2_sleep &sdc2_card_det_n>;
> + vmmc-supply = <&vreg_l9b_2p9>;
> + vqmmc-supply = <&vreg_l8b_1p8>;
> + max-sd-hs-hz = <37500000>;
It's already in 8550.dtsi, you can drop it
> + no-sdio;
> + no-mmc;
> +
> + qcom,dll-config = <0x0007442c>;
Is that changed in your downstream tree?
[...]
> +&swr1 {
> + status = "okay";
> + wcd_rx: codec@0,4 {
Let's keep a \n between properties and the subsequent subnodes,
also file-wide
[...]
> +&tlmm {
> + gpio-reserved-ranges = <32 8>;
> +
> + dsi_p_rst_active: dsi-p-rst-active-state {
> + pins = "gpio133";
https://docs.kernel.org/devicetree/bindings/dts-coding-style.html
Let's order them by the pin index (it's a fairly new development so other
8550 devices don't really have that)
[...]
> +&usb_dp_qmpphy {
> + vdda-phy-supply = <&vreg_l3e_1p2>;
> + vdda-pll-supply = <&vreg_l3f_0p88>;
> +
> + mode-switch;
Already present in sm8550.dtsi
Konrad
On Thu, Mar 19, 2026 at 6:40 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 3/11/26 6:44 PM, Aaron Kling via B4 Relay wrote:
> > From: Teguh Sobirin <teguh@sobir.in>
> >
> > This adds a base dtb of everything common between the AYN QCS8550
> > devices. It is intended to be extended by device specific overlays.
> >
> > Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> > Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
>
> [...]
>
> > + pwm_fan: pwm-fan {
> > + compatible = "pwm-fan";
> > +
> > + fan-supply = <&vdd_fan_5v0>;
> > + pwms = <&pm8550_pwm 3 50000>;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&fan_pwm_active>, <&fan_int>;
>
> property-n
> property-names
>
> in this order, everywhere, please
Ack
> > +
> > + pulses-per-revolution = <4>;
> > + interrupt-parent = <&tlmm>;
> > + interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
>
> interrupts-extended = <&tlmm 13 IRQ_...>;
Ack
> [...]
>
> > + model = "AYN-Odin2";
> > + audio-routing =
> > + "IN1_HPHL", "HPHL_OUT",
>
> Let's drop this empty linebreak
Ack
>
> > + "IN2_HPHR", "HPHR_OUT",
> > + "AMIC2", "MIC BIAS2",
> > + "TX SWR_INPUT1", "ADC2_OUTPUT";
> > +
> > + speaker-i2s-dai-link {
> > + link-name = "Primary MI2S Playback";
> > +
> > + cpu {
> > + sound-dai = <&q6apmbedai PRIMARY_MI2S_RX>;
> > + };
>
> 'co'dec < 'cp'u, please resort
Ack
> [...]
>
> > + vdd_fan_5v0: vdd-fan-5v0-regulator {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vdd_fan_5v0";
> > +
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > +
> > + gpio = <&tlmm 109 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&fan_pwr_active>;
> > +
> > + regulator-state-mem {
> > + regulator-off-in-suspend;
> > + };
>
> oh, I didn't know this binding existed.. but it seems valid indeed!
>
> [...]
>
> > +&i2c12 {
> > + clock-frequency = <400000>;
> > + status = "okay";
>
> Let's uniformly keep a \n before status
Ack
> > +};
> > +
> > +&i2c_master_hub_0 {
> > + status = "okay";
>
> Please add a clock-frequency
> (you can read it back at runtime running a vendor kernel if you don't have a
> better source)
Mmm. I'll see if I can find that. But I don't see any of the existing
sm8550 devices setting this either.
> [...]
>
> > + spk_amp_l: spk_amp_l@34 {
>
> underscores are no bueno in node names (between ':' and '@'), and they should
> be generic, let's try amplifier@
Ack
> [...]
>
> > +&iris {
> > + status = "okay";
>
> firmware-name?
Not needed. These devices are unfused and can use the generic firmware
like the devkits. I have verified this as noted in another response on
this change.
> [...]
>
> > +&sdhc_2 {
> > + cd-gpios = <&pm8550_gpios 12 GPIO_ACTIVE_LOW>;
> > + pinctrl-names = "default", "sleep";
> > + pinctrl-0 = <&sdc2_default &sdc2_card_det_n>;
> > + pinctrl-1 = <&sdc2_sleep &sdc2_card_det_n>;
> > + vmmc-supply = <&vreg_l9b_2p9>;
> > + vqmmc-supply = <&vreg_l8b_1p8>;
> > + max-sd-hs-hz = <37500000>;
>
> It's already in 8550.dtsi, you can drop it
Ack
> > + no-sdio;
> > + no-mmc;
> > +
> > + qcom,dll-config = <0x0007442c>;
>
> Is that changed in your downstream tree?
I honestly don't know. This existed in the mainline port dtsi mirrored
by the vendor and I picked it up as-is. I grepped the downstream
source release and I don't see anything named 'dll-config' in the
sm8550 dt at all, only in older soc's brought in by the kernel fork. I
know the fork I based on was chasing the issues with high speed sd
cards that seem to have been recently fixed upstream. Maybe this was
part of that. I can drop it given no one knows why it's here.
>
> [...]
>
> > +&swr1 {
> > + status = "okay";
> > + wcd_rx: codec@0,4 {
>
> Let's keep a \n between properties and the subsequent subnodes,
> also file-wide
Ack
> [...]
>
> > +&tlmm {
> > + gpio-reserved-ranges = <32 8>;
> > +
> > + dsi_p_rst_active: dsi-p-rst-active-state {
> > + pins = "gpio133";
>
> https://docs.kernel.org/devicetree/bindings/dts-coding-style.html
>
> Let's order them by the pin index (it's a fairly new development so other
> 8550 devices don't really have that)
Ack
> [...]
>
> > +&usb_dp_qmpphy {
> > + vdda-phy-supply = <&vreg_l3e_1p2>;
> > + vdda-pll-supply = <&vreg_l3f_0p88>;
> > +
> > + mode-switch;
>
> Already present in sm8550.dtsi
Ack
Aaron
On 3/19/26 7:39 PM, Aaron Kling wrote: > On Thu, Mar 19, 2026 at 6:40 AM Konrad Dybcio > <konrad.dybcio@oss.qualcomm.com> wrote: >> >> On 3/11/26 6:44 PM, Aaron Kling via B4 Relay wrote: >>> From: Teguh Sobirin <teguh@sobir.in> >>> >>> This adds a base dtb of everything common between the AYN QCS8550 >>> devices. It is intended to be extended by device specific overlays. >>> >>> Signed-off-by: Teguh Sobirin <teguh@sobir.in> >>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com> >>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> >>> --- [...] >>> + qcom,dll-config = <0x0007442c>; >> >> Is that changed in your downstream tree? > > I honestly don't know. This existed in the mainline port dtsi mirrored > by the vendor and I picked it up as-is. I grepped the downstream > source release and I don't see anything named 'dll-config' in the > sm8550 dt at all, only in older soc's brought in by the kernel fork. I > know the fork I based on was chasing the issues with high speed sd > cards that seem to have been recently fixed upstream. Maybe this was > part of that. I can drop it given no one knows why it's here. FWIW downstream has this data under the qcom,dll-hsr-list property Konrad
On 3/11/26 2:44 PM, Aaron Kling wrote:
> From: Teguh Sobirin <teguh@sobir.in>
>
> This adds a base dtb of everything common between the AYN QCS8550
> devices. It is intended to be extended by device specific overlays.
>
> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
> 2 files changed, 1778 insertions(+)
> […]
> +/ {
> + model = "AYN QCS8550 Common";
> + compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
Huh?.. All existing -common files are .dtsi includes without their own
model/compatible, and the compile-time "dtbo" support is only used for
EL2 where we want to apply the same thing to many many devices without
polluting the tree with extra glue files. I don't see why this should be
a "common device" with its own compatible string, and not just a dtsi.
> […]
> +&gpu {
> + status = "okay";
> +
> + zap-shader {
> + firmware-name = "qcom/sm8550/a740_zap.mbn";
> + };
> +};
Please use the &gpu_zap_shader label.
And does the generic zap actually just work?
> […]
> +&i2c0 {
> + clock-frequency = <400000>;
> + status = "okay";
> +};
> +
> +&i2c4 {
> + clock-frequency = <400000>;
> + status = "okay";
> +};
> +
> +&i2c12 {
> + clock-frequency = <400000>;
> + status = "okay";
> +};
If the individual devices actually use these busses, better to enable
them inside of their .dts as well I think?
> +&iris {
> + status = "okay";
> +};
Works with generic firmware?
> […]
> +&pcie0 {
> + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
Current binding is to put these inside of the &pcieportN (renaming
'perst' to 'reset' which I just noticed I failed to do for one of my own
files :D), see x1e78100-lenovo-thinkpad-t14s.dtsi for an example.
> […]
Thanks for this work, very cool overall!
~val
On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote:
>
> On 3/11/26 2:44 PM, Aaron Kling wrote:
>
> > From: Teguh Sobirin <teguh@sobir.in>
> >
> > This adds a base dtb of everything common between the AYN QCS8550
> > devices. It is intended to be extended by device specific overlays.
> >
> > Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> > Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
> > 2 files changed, 1778 insertions(+)
> > […]
> > +/ {
> > + model = "AYN QCS8550 Common";
> > + compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
>
> Huh?.. All existing -common files are .dtsi includes without their own
> model/compatible, and the compile-time "dtbo" support is only used for
> EL2 where we want to apply the same thing to many many devices without
> polluting the tree with extra glue files. I don't see why this should be
> a "common device" with its own compatible string, and not just a dtsi.
>
> > […]
> > +&gpu {
> > + status = "okay";
> > +
> > + zap-shader {
> > + firmware-name = "qcom/sm8550/a740_zap.mbn";
> > + };
> > +};
>
> Please use the &gpu_zap_shader label.
>
> And does the generic zap actually just work?
>
> > […]
> > +&i2c0 {
> > + clock-frequency = <400000>;
> > + status = "okay";
> > +};
> > +
> > +&i2c4 {
> > + clock-frequency = <400000>;
> > + status = "okay";
> > +};
> > +
> > +&i2c12 {
> > + clock-frequency = <400000>;
> > + status = "okay";
> > +};
> If the individual devices actually use these busses, better to enable
> them inside of their .dts as well I think?
> > +&iris {
> > + status = "okay";
> > +};
> Works with generic firmware?
> > […]
> > +&pcie0 {
> > + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> > + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> Current binding is to put these inside of the &pcieportN (renaming
> 'perst' to 'reset' which I just noticed I failed to do for one of my own
> files :D), see x1e78100-lenovo-thinkpad-t14s.dtsi for an example.
I tried making this change, but the pcie port failed to probe. I also
notice that all existing sm8550 devices still use the 'old' syntax.
Aaron
On 3/19/26 11:31 PM, Aaron Kling wrote:
> On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote:
>>
>> On 3/11/26 2:44 PM, Aaron Kling wrote:
>>
>>> From: Teguh Sobirin <teguh@sobir.in>
>>>
>>> This adds a base dtb of everything common between the AYN QCS8550
>>> devices. It is intended to be extended by device specific overlays.
>>>
>>> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/Makefile | 1 +
>>> arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
>>> 2 files changed, 1778 insertions(+)
>>> […]
>>> +/ {
>>> + model = "AYN QCS8550 Common";
>>> + compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
>>
>> Huh?.. All existing -common files are .dtsi includes without their own
>> model/compatible, and the compile-time "dtbo" support is only used for
>> EL2 where we want to apply the same thing to many many devices without
>> polluting the tree with extra glue files. I don't see why this should be
>> a "common device" with its own compatible string, and not just a dtsi.
>>
>>> […]
>>> +&gpu {
>>> + status = "okay";
>>> +
>>> + zap-shader {
>>> + firmware-name = "qcom/sm8550/a740_zap.mbn";
>>> + };
>>> +};
>>
>> Please use the &gpu_zap_shader label.
>>
>> And does the generic zap actually just work?
>>
>>> […]
>>> +&i2c0 {
>>> + clock-frequency = <400000>;
>>> + status = "okay";
>>> +};
>>> +
>>> +&i2c4 {
>>> + clock-frequency = <400000>;
>>> + status = "okay";
>>> +};
>>> +
>>> +&i2c12 {
>>> + clock-frequency = <400000>;
>>> + status = "okay";
>>> +};
>> If the individual devices actually use these busses, better to enable
>> them inside of their .dts as well I think?
>>> +&iris {
>>> + status = "okay";
>>> +};
>> Works with generic firmware?
>>> […]
>>> +&pcie0 {
>>> + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
>>> + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
>> Current binding is to put these inside of the &pcieportN (renaming
>> 'perst' to 'reset' which I just noticed I failed to do for one of my own
>> files :D), see x1e78100-lenovo-thinkpad-t14s.dtsi for an example.
>
> I tried making this change, but the pcie port failed to probe. I also
> notice that all existing sm8550 devices still use the 'old' syntax.
There's a ""feature"" in the parsing code that will only let this work if
both 'phys' and 'xxx-gpios' are under the same node (i.e. both under PCIe
OR both under the root port), I think this may be changed by a single big
change later on
Konrad
On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote:
>
> On 3/11/26 2:44 PM, Aaron Kling wrote:
>
> > From: Teguh Sobirin <teguh@sobir.in>
> >
> > This adds a base dtb of everything common between the AYN QCS8550
> > devices. It is intended to be extended by device specific overlays.
> >
> > Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> > Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
> > 2 files changed, 1778 insertions(+)
> > […]
> > +/ {
> > + model = "AYN QCS8550 Common";
> > + compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
>
> Huh?.. All existing -common files are .dtsi includes without their own
> model/compatible, and the compile-time "dtbo" support is only used for
> EL2 where we want to apply the same thing to many many devices without
> polluting the tree with extra glue files. I don't see why this should be
> a "common device" with its own compatible string, and not just a dtsi.
My use case for these devices is Android, using a single base dtb and
variant dtbo's in a single software build. Given the aosp boot image
v4 setup, using individual dtb's would require different vendor_boot
images, which would require multiple build targets. This setup allows
for my use case, while also having individual dtb targets for a
standard Linux use case. To my knowledge, the final device specific
dtb from this is the same as a dtb using a common dtsi.
> > […]
> > +&gpu {
> > + status = "okay";
> > +
> > + zap-shader {
> > + firmware-name = "qcom/sm8550/a740_zap.mbn";
> > + };
> > +};
>
> Please use the &gpu_zap_shader label.
Ack.
> And does the generic zap actually just work?
The devices boot and the gpu works, so whatever code path is being
used works. These devices are unfused, and based on what I understand
a zap shader to be, switching a gpu from secure mode to non-secure,
I'm not sure it's needed at all. I have not tested just not setting,
though.
> > […]
> > +&i2c0 {
> > + clock-frequency = <400000>;
> > + status = "okay";
> > +};
> > +
> > +&i2c4 {
> > + clock-frequency = <400000>;
> > + status = "okay";
> > +};
> > +
> > +&i2c12 {
> > + clock-frequency = <400000>;
> > + status = "okay";
> > +};
> If the individual devices actually use these busses, better to enable
> them inside of their .dts as well I think?
I can move them. I think the idea was that all variants do use these,
but for different hardware, so might as well commonize this part. This
part existed before I started working on the devices, so I can't say
for sure.
> > +&iris {
> > + status = "okay";
> > +};
> Works with generic firmware?
I have not been able to verify this. Unfortunately, there is not an
aidl v4l2 c2 hal for aosp. If the expectation is that device specific
firmware is needed, even for unfused devices, I can drop this section
until I am able to use it. Or maybe Teguh could chime in if this works
on ROCKNIX.
> > […]
> > +&pcie0 {
> > + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> > + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> Current binding is to put these inside of the &pcieportN (renaming
> 'perst' to 'reset' which I just noticed I failed to do for one of my own
> files :D), see x1e78100-lenovo-thinkpad-t14s.dtsi for an example.
Ack.
> > […]
>
> Thanks for this work, very cool overall!
>
> ~val
Aaron
On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote:
> On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote:
> >
> > On 3/11/26 2:44 PM, Aaron Kling wrote:
> >
> > > From: Teguh Sobirin <teguh@sobir.in>
> > >
> > > This adds a base dtb of everything common between the AYN QCS8550
> > > devices. It is intended to be extended by device specific overlays.
> > >
> > > Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> > > Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
> > > 2 files changed, 1778 insertions(+)
> > > […]
> > > +/ {
> > > + model = "AYN QCS8550 Common";
> > > + compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
> >
> > Huh?.. All existing -common files are .dtsi includes without their own
> > model/compatible, and the compile-time "dtbo" support is only used for
> > EL2 where we want to apply the same thing to many many devices without
> > polluting the tree with extra glue files. I don't see why this should be
> > a "common device" with its own compatible string, and not just a dtsi.
>
> My use case for these devices is Android, using a single base dtb and
> variant dtbo's in a single software build. Given the aosp boot image
> v4 setup, using individual dtb's would require different vendor_boot
> images, which would require multiple build targets. This setup allows
> for my use case, while also having individual dtb targets for a
> standard Linux use case. To my knowledge, the final device specific
> dtb from this is the same as a dtb using a common dtsi.
This needs to be explained in the commit message. But do you need then a
model/compatible in the default dtb?
>
> > > […]
> > > +&i2c0 {
> > > + clock-frequency = <400000>;
> > > + status = "okay";
> > > +};
> > > +
> > > +&i2c4 {
> > > + clock-frequency = <400000>;
> > > + status = "okay";
> > > +};
> > > +
> > > +&i2c12 {
> > > + clock-frequency = <400000>;
> > > + status = "okay";
> > > +};
> > If the individual devices actually use these busses, better to enable
> > them inside of their .dts as well I think?
>
> I can move them. I think the idea was that all variants do use these,
> but for different hardware, so might as well commonize this part. This
> part existed before I started working on the devices, so I can't say
> for sure.
Well, the only common part is the frequency & status, so not so much.
BTW: could you please uniformly add an empty line before the status
properties?
>
> > > +&iris {
> > > + status = "okay";
> > > +};
> > Works with generic firmware?
>
> I have not been able to verify this. Unfortunately, there is not an
> aidl v4l2 c2 hal for aosp. If the expectation is that device specific
> firmware is needed, even for unfused devices, I can drop this section
> until I am able to use it. Or maybe Teguh could chime in if this works
> on ROCKNIX.
You can use ffmpeg to verify the unit. It has v4l2m2m codecs.
--
With best wishes
Dmitry
On Thu, Mar 12, 2026 at 10:19 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote:
> > On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote:
> > >
> > > On 3/11/26 2:44 PM, Aaron Kling wrote:
> > >
> > > > From: Teguh Sobirin <teguh@sobir.in>
> > > >
> > > > This adds a base dtb of everything common between the AYN QCS8550
> > > > devices. It is intended to be extended by device specific overlays.
> > > >
> > > > Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> > > > Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > ---
> > > > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > > > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
> > > > 2 files changed, 1778 insertions(+)
> > > > […]
> > > > +/ {
> > > > + model = "AYN QCS8550 Common";
> > > > + compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
> > >
> > > Huh?.. All existing -common files are .dtsi includes without their own
> > > model/compatible, and the compile-time "dtbo" support is only used for
> > > EL2 where we want to apply the same thing to many many devices without
> > > polluting the tree with extra glue files. I don't see why this should be
> > > a "common device" with its own compatible string, and not just a dtsi.
> >
> > My use case for these devices is Android, using a single base dtb and
> > variant dtbo's in a single software build. Given the aosp boot image
> > v4 setup, using individual dtb's would require different vendor_boot
> > images, which would require multiple build targets. This setup allows
> > for my use case, while also having individual dtb targets for a
> > standard Linux use case. To my knowledge, the final device specific
> > dtb from this is the same as a dtb using a common dtsi.
>
> This needs to be explained in the commit message. But do you need then a
> model/compatible in the default dtb?
>
> >
> > > > […]
> > > > +&i2c0 {
> > > > + clock-frequency = <400000>;
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > +&i2c4 {
> > > > + clock-frequency = <400000>;
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > +&i2c12 {
> > > > + clock-frequency = <400000>;
> > > > + status = "okay";
> > > > +};
> > > If the individual devices actually use these busses, better to enable
> > > them inside of their .dts as well I think?
> >
> > I can move them. I think the idea was that all variants do use these,
> > but for different hardware, so might as well commonize this part. This
> > part existed before I started working on the devices, so I can't say
> > for sure.
>
> Well, the only common part is the frequency & status, so not so much.
>
> BTW: could you please uniformly add an empty line before the status
> properties?
>
> >
> > > > +&iris {
> > > > + status = "okay";
> > > > +};
> > > Works with generic firmware?
> >
> > I have not been able to verify this. Unfortunately, there is not an
> > aidl v4l2 c2 hal for aosp. If the expectation is that device specific
> > firmware is needed, even for unfused devices, I can drop this section
> > until I am able to use it. Or maybe Teguh could chime in if this works
> > on ROCKNIX.
>
> You can use ffmpeg to verify the unit. It has v4l2m2m codecs.
I did get a static ffmpeg binary to run and transcoding using v4l2m2m
hw codecs were working. So the generic firmware is fine.
Aaron
On Fri, Mar 13, 2026 at 05:19:27AM +0200, Dmitry Baryshkov wrote:
> On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote:
> > On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote:
> > >
> > > On 3/11/26 2:44 PM, Aaron Kling wrote:
> > >
> > > > From: Teguh Sobirin <teguh@sobir.in>
> > > >
> > > > This adds a base dtb of everything common between the AYN QCS8550
> > > > devices. It is intended to be extended by device specific overlays.
> > > >
> > > > Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> > > > Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > ---
> > > > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > > > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
Common is not a board, NAK. This could only be DTSI if you provide some
sort of HARDWARE arguments explaining the common parts of schematics or
hardware design.
> > > > 2 files changed, 1778 insertions(+)
> > > > […]
> > > > +/ {
> > > > + model = "AYN QCS8550 Common";
> > > > + compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
> > >
> > > Huh?.. All existing -common files are .dtsi includes without their own
> > > model/compatible, and the compile-time "dtbo" support is only used for
> > > EL2 where we want to apply the same thing to many many devices without
> > > polluting the tree with extra glue files. I don't see why this should be
> > > a "common device" with its own compatible string, and not just a dtsi.
> >
> > My use case for these devices is Android, using a single base dtb and
> > variant dtbo's in a single software build. Given the aosp boot image
> > v4 setup, using individual dtb's would require different vendor_boot
> > images, which would require multiple build targets. This setup allows
> > for my use case, while also having individual dtb targets for a
> > standard Linux use case. To my knowledge, the final device specific
> > dtb from this is the same as a dtb using a common dtsi.
>
> This needs to be explained in the commit message. But do you need then a
> model/compatible in the default dtb?
Not enough. We do not add compatibles not representing actual hardware,
just to streamline boot image handling.
Plus this code is not even truly correct.
We do not write DTS to fulfill broken Android boot process.
Best regards,
Krzysztof
On Fri, Mar 13, 2026 at 3:37 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Fri, Mar 13, 2026 at 05:19:27AM +0200, Dmitry Baryshkov wrote:
> > On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote:
> > > On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote:
> > > >
> > > > On 3/11/26 2:44 PM, Aaron Kling wrote:
> > > >
> > > > > From: Teguh Sobirin <teguh@sobir.in>
> > > > >
> > > > > This adds a base dtb of everything common between the AYN QCS8550
> > > > > devices. It is intended to be extended by device specific overlays.
> > > > >
> > > > > Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> > > > > Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > ---
> > > > > arch/arm64/boot/dts/qcom/Makefile | 1 +
> > > > > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
>
> Common is not a board, NAK. This could only be DTSI if you provide some
> sort of HARDWARE arguments explaining the common parts of schematics or
> hardware design.
>
> > > > > 2 files changed, 1778 insertions(+)
> > > > > […]
> > > > > +/ {
> > > > > + model = "AYN QCS8550 Common";
> > > > > + compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
> > > >
> > > > Huh?.. All existing -common files are .dtsi includes without their own
> > > > model/compatible, and the compile-time "dtbo" support is only used for
> > > > EL2 where we want to apply the same thing to many many devices without
> > > > polluting the tree with extra glue files. I don't see why this should be
> > > > a "common device" with its own compatible string, and not just a dtsi.
> > >
> > > My use case for these devices is Android, using a single base dtb and
> > > variant dtbo's in a single software build. Given the aosp boot image
> > > v4 setup, using individual dtb's would require different vendor_boot
> > > images, which would require multiple build targets. This setup allows
> > > for my use case, while also having individual dtb targets for a
> > > standard Linux use case. To my knowledge, the final device specific
> > > dtb from this is the same as a dtb using a common dtsi.
> >
> > This needs to be explained in the commit message. But do you need then a
> > model/compatible in the default dtb?
This was added because schema checks failed without model and compatible.
> Not enough. We do not add compatibles not representing actual hardware,
> just to streamline boot image handling.
>
> Plus this code is not even truly correct.
>
> We do not write DTS to fulfill broken Android boot process.
I have been trying rather hard to find a reasonable compromise between
mainline requirements and a normal Android use case, something I can
actually ship to normal users. This seemed fairly reasonable to me,
since it can generate standalone dtb's transparently. But if my use
case can never meet submission requirements, then why am I even here,
getting shamed for working on Android? If I have to fork the
device-tree anyways to fit my requirements, then there's no reason for
me to put the time and effort in to submitting something I can't use.
I'd be better off just keeping everything out of tree as googles
kernel-platform supports. And never look at mainline qcom again.
Frustratedly,
Aaron
On Fri, Mar 13, 2026 at 12:34:21PM -0500, Aaron Kling wrote: > On Fri, Mar 13, 2026 at 3:37 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > On Fri, Mar 13, 2026 at 05:19:27AM +0200, Dmitry Baryshkov wrote: > > > On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote: > > > > On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote: > > > > > > > > > > On 3/11/26 2:44 PM, Aaron Kling wrote: > > > > > > > > > > > From: Teguh Sobirin <teguh@sobir.in> > > > > > > > > > > > > This adds a base dtb of everything common between the AYN QCS8550 > > > > > > devices. It is intended to be extended by device specific overlays. > > > > > > > > > > > > Signed-off-by: Teguh Sobirin <teguh@sobir.in> > > > > > > Co-developed-by: Aaron Kling <webgeek1234@gmail.com> > > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com> > > > > > > --- > > > > > > arch/arm64/boot/dts/qcom/Makefile | 1 + > > > > > > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++ > > > > Common is not a board, NAK. This could only be DTSI if you provide some > > sort of HARDWARE arguments explaining the common parts of schematics or > > hardware design. > > > > > Not enough. We do not add compatibles not representing actual hardware, > > just to streamline boot image handling. > > > > Plus this code is not even truly correct. > > > > We do not write DTS to fulfill broken Android boot process. > > I have been trying rather hard to find a reasonable compromise between > mainline requirements and a normal Android use case, something I can > actually ship to normal users. This seemed fairly reasonable to me, > since it can generate standalone dtb's transparently. But if my use > case can never meet submission requirements, then why am I even here, > getting shamed for working on Android? If I have to fork the > device-tree anyways to fit my requirements, then there's no reason for > me to put the time and effort in to submitting something I can't use. > I'd be better off just keeping everything out of tree as googles > kernel-platform supports. And never look at mainline qcom again. Well... It's a tough argument. Getting your DTs into mainline would help occasional users that would like to run something else than Android (PmOS or some other distro). Also it ensures that you can run Android even when Google (Qualcomm) EOL the current SM8550 msm-something tree. Speaking about the boot process. I remember that historically it was possible to pass several DTBs in the the Android boot image. Is it no longer the case? Is there any way to identify the boards (I think historical code was using qcom,board-id for that)? Then you would be able to squash all your DTBs in a single boot image. -- With best wishes Dmitry
On Fri, Mar 13, 2026 at 12:48 PM Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote: > > On Fri, Mar 13, 2026 at 12:34:21PM -0500, Aaron Kling wrote: > > On Fri, Mar 13, 2026 at 3:37 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > On Fri, Mar 13, 2026 at 05:19:27AM +0200, Dmitry Baryshkov wrote: > > > > On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote: > > > > > On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote: > > > > > > > > > > > > On 3/11/26 2:44 PM, Aaron Kling wrote: > > > > > > > > > > > > > From: Teguh Sobirin <teguh@sobir.in> > > > > > > > > > > > > > > This adds a base dtb of everything common between the AYN QCS8550 > > > > > > > devices. It is intended to be extended by device specific overlays. > > > > > > > > > > > > > > Signed-off-by: Teguh Sobirin <teguh@sobir.in> > > > > > > > Co-developed-by: Aaron Kling <webgeek1234@gmail.com> > > > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com> > > > > > > > --- > > > > > > > arch/arm64/boot/dts/qcom/Makefile | 1 + > > > > > > > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++ > > > > > > Common is not a board, NAK. This could only be DTSI if you provide some > > > sort of HARDWARE arguments explaining the common parts of schematics or > > > hardware design. > > > > > > > > Not enough. We do not add compatibles not representing actual hardware, > > > just to streamline boot image handling. > > > > > > Plus this code is not even truly correct. > > > > > > We do not write DTS to fulfill broken Android boot process. > > > > I have been trying rather hard to find a reasonable compromise between > > mainline requirements and a normal Android use case, something I can > > actually ship to normal users. This seemed fairly reasonable to me, > > since it can generate standalone dtb's transparently. But if my use > > case can never meet submission requirements, then why am I even here, > > getting shamed for working on Android? If I have to fork the > > device-tree anyways to fit my requirements, then there's no reason for > > me to put the time and effort in to submitting something I can't use. > > I'd be better off just keeping everything out of tree as googles > > kernel-platform supports. And never look at mainline qcom again. > > Well... It's a tough argument. Getting your DTs into mainline would help > occasional users that would like to run something else than Android > (PmOS or some other distro). Also it ensures that you can run Android > even when Google (Qualcomm) EOL the current SM8550 msm-something tree. Oh, I'm not working on the downstream kernel either way. The question is whether device support gets mainlined or if I keep all support out of tree and only update when Google forks the ack from a new lts. > Speaking about the boot process. I remember that historically it was > possible to pass several DTBs in the the Android boot image. Is it no > longer the case? Is there any way to identify the boards (I think > historical code was using qcom,board-id for that)? Then you would be > able to squash all your DTBs in a single boot image. That functionality is still there, the concatenated dtb slot in the vendor_boot image. Unfortunately for this context, the odm did not change those ids per hardware variant. I think they just left them at the hdk or qrd default that came with the bsp. I do have to jump some software hoops to slot in the correct dtbo to the dtbo partition during inline updates because of this, but it's not terrible. And that's not something I can reasonably do for the vendor_boot image. To my knowledge, there is no way for the bootloader to tell these devices apart and any attempt to do so would require a custom abl build, probably per variant, which would then desync the boot firmware from the official OS, plus make first install more difficult for users, both of which I'm trying not to do. Aaron
On 3/13/26 3:21 PM, Aaron Kling wrote: > On Fri, Mar 13, 2026 at 12:48 PM Dmitry Baryshkov > <dmitry.baryshkov@oss.qualcomm.com> wrote: >> On Fri, Mar 13, 2026 at 12:34:21PM -0500, Aaron Kling wrote: >>> On Fri, Mar 13, 2026 at 3:37 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>> On Fri, Mar 13, 2026 at 05:19:27AM +0200, Dmitry Baryshkov wrote: >>>>> On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote: >>>>>> On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote: >>>>>>> On 3/11/26 2:44 PM, Aaron Kling wrote: >>>>>>> >>>>>>>> From: Teguh Sobirin <teguh@sobir.in> >>>>>>>> >>>>>>>> This adds a base dtb of everything common between the AYN QCS8550 >>>>>>>> devices. It is intended to be extended by device specific overlays. >>>>>>>> >>>>>>>> Signed-off-by: Teguh Sobirin <teguh@sobir.in> >>>>>>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com> >>>>>>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> >>>>>>>> --- >>>>>>>> arch/arm64/boot/dts/qcom/Makefile | 1 + >>>>>>>> arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++ >>>> Common is not a board, NAK. This could only be DTSI if you provide some >>>> sort of HARDWARE arguments explaining the common parts of schematics or >>>> hardware design. >>>> >>>> Not enough. We do not add compatibles not representing actual hardware, >>>> just to streamline boot image handling. >>>> >>>> Plus this code is not even truly correct. >>>> >>>> We do not write DTS to fulfill broken Android boot process. >>> I have been trying rather hard to find a reasonable compromise between >>> mainline requirements and a normal Android use case, something I can >>> actually ship to normal users. This seemed fairly reasonable to me, >>> since it can generate standalone dtb's transparently. But if my use >>> case can never meet submission requirements, then why am I even here, >>> getting shamed for working on Android? If I have to fork the >>> device-tree anyways to fit my requirements, then there's no reason for >>> me to put the time and effort in to submitting something I can't use. >>> I'd be better off just keeping everything out of tree as googles >>> kernel-platform supports. And never look at mainline qcom again. >> Well... It's a tough argument. Getting your DTs into mainline would help >> occasional users that would like to run something else than Android >> (PmOS or some other distro). Also it ensures that you can run Android >> even when Google (Qualcomm) EOL the current SM8550 msm-something tree. > Oh, I'm not working on the downstream kernel either way. The question > is whether device support gets mainlined or if I keep all support out > of tree and only update when Google forks the ack from a new lts. IMO landing everything with proper upstream style and having minimal customization/patching during your Android build process to convert it into a base dtb + dtbos setup (or a blank base + everything as dtbos one?) during would already be really valuable. >> Speaking about the boot process. I remember that historically it was >> possible to pass several DTBs in the the Android boot image. Is it no >> longer the case? Is there any way to identify the boards (I think >> historical code was using qcom,board-id for that)? Then you would be >> able to squash all your DTBs in a single boot image. > That functionality is still there, the concatenated dtb slot in the > vendor_boot image. Unfortunately for this context, the odm did not > change those ids per hardware variant. I think they just left them at > the hdk or qrd default that came with the bsp. I do have to jump some > software hoops to slot in the correct dtbo to the dtbo partition > during inline updates because of this, but it's not terrible. And > that's not something I can reasonably do for the vendor_boot image. To > my knowledge, there is no way for the bootloader to tell these devices > apart and any attempt to do so would require a custom abl build, > probably per variant, which would then desync the boot firmware from > the official OS, plus make first install more difficult for users, > both of which I'm trying not to do. Leaving the default board ID is a classic… but on many old Android phones you (read: an intermediate bootloader) can use the cmdline injected by ABL to distinguish between models. Nothing like that here? ~val
On Fri, Mar 13, 2026 at 7:11 PM Val Packett <val@packett.cool> wrote: > > > On 3/13/26 3:21 PM, Aaron Kling wrote: > > On Fri, Mar 13, 2026 at 12:48 PM Dmitry Baryshkov > > <dmitry.baryshkov@oss.qualcomm.com> wrote: > >> On Fri, Mar 13, 2026 at 12:34:21PM -0500, Aaron Kling wrote: > >>> On Fri, Mar 13, 2026 at 3:37 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > >>>> On Fri, Mar 13, 2026 at 05:19:27AM +0200, Dmitry Baryshkov wrote: > >>>>> On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote: > >>>>>> On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote: > >>>>>>> On 3/11/26 2:44 PM, Aaron Kling wrote: > >>>>>>> > >>>>>>>> From: Teguh Sobirin <teguh@sobir.in> > >>>>>>>> > >>>>>>>> This adds a base dtb of everything common between the AYN QCS8550 > >>>>>>>> devices. It is intended to be extended by device specific overlays. > >>>>>>>> > >>>>>>>> Signed-off-by: Teguh Sobirin <teguh@sobir.in> > >>>>>>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com> > >>>>>>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> > >>>>>>>> --- > >>>>>>>> arch/arm64/boot/dts/qcom/Makefile | 1 + > >>>>>>>> arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++ > >>>> Common is not a board, NAK. This could only be DTSI if you provide some > >>>> sort of HARDWARE arguments explaining the common parts of schematics or > >>>> hardware design. > >>>> > >>>> Not enough. We do not add compatibles not representing actual hardware, > >>>> just to streamline boot image handling. > >>>> > >>>> Plus this code is not even truly correct. > >>>> > >>>> We do not write DTS to fulfill broken Android boot process. > >>> I have been trying rather hard to find a reasonable compromise between > >>> mainline requirements and a normal Android use case, something I can > >>> actually ship to normal users. This seemed fairly reasonable to me, > >>> since it can generate standalone dtb's transparently. But if my use > >>> case can never meet submission requirements, then why am I even here, > >>> getting shamed for working on Android? If I have to fork the > >>> device-tree anyways to fit my requirements, then there's no reason for > >>> me to put the time and effort in to submitting something I can't use. > >>> I'd be better off just keeping everything out of tree as googles > >>> kernel-platform supports. And never look at mainline qcom again. > >> Well... It's a tough argument. Getting your DTs into mainline would help > >> occasional users that would like to run something else than Android > >> (PmOS or some other distro). Also it ensures that you can run Android > >> even when Google (Qualcomm) EOL the current SM8550 msm-something tree. > > Oh, I'm not working on the downstream kernel either way. The question > > is whether device support gets mainlined or if I keep all support out > > of tree and only update when Google forks the ack from a new lts. > > IMO landing everything with proper upstream style and having minimal > customization/patching during your Android build process to convert it > into a base dtb + dtbos setup (or a blank base + everything as dtbos > one?) during would already be really valuable. The end goal was to get everything possible merged before the 7.x lts and use Googles Android Common Kernel repo as-is from that version on, no vendor specific fork. Perhaps overly idealistic, but still the goal. There would be a few android specific device tree things needed in out of tree extensions, but that's trivial with the kernel-platform build setup. Including a common dtsi and extending that out of tree to a base dtb is trivial, if said dtsi doesn't get nack'ed as was already threatened if I don't provide documentation I can't possibly obtain. But if the device specific parts are a dts that already include the common dtsi, extending those, cutting out the common include, and turning it into a dtso is potentially not possible. And even if it is, the method would probably be approaching a crime against humanity. And if I have to fork the main kernel anyways, I'm losing a large piece of why I'm trying to upstream things in the first place: cutting direct maintenance of that repo out of my workflow and only needing to push fixes when new issues are found. An empty base dtb is an interesting thought, but I don't think it will work with abl. There's been this whole back and forth in other threads about how abl will fail to apply any dtbo, even an empty one, if it can't find certain labels in the base dtb to apply changes to. I would expect even more of those to pop up if I tried to minimize the base dtb. And then there's still the issue of extending a dts into a dtso that might not be possible. Which brings things back around to having to fork at least the device specific parts out of tree to make dtso's, if they can't be a dtso in-tree. > >> Speaking about the boot process. I remember that historically it was > >> possible to pass several DTBs in the the Android boot image. Is it no > >> longer the case? Is there any way to identify the boards (I think > >> historical code was using qcom,board-id for that)? Then you would be > >> able to squash all your DTBs in a single boot image. > > That functionality is still there, the concatenated dtb slot in the > > vendor_boot image. Unfortunately for this context, the odm did not > > change those ids per hardware variant. I think they just left them at > > the hdk or qrd default that came with the bsp. I do have to jump some > > software hoops to slot in the correct dtbo to the dtbo partition > > during inline updates because of this, but it's not terrible. And > > that's not something I can reasonably do for the vendor_boot image. To > > my knowledge, there is no way for the bootloader to tell these devices > > apart and any attempt to do so would require a custom abl build, > > probably per variant, which would then desync the boot firmware from > > the official OS, plus make first install more difficult for users, > > both of which I'm trying not to do. > > Leaving the default board ID is a classic… but on many old Android > phones you (read: an intermediate bootloader) can use the cmdline > injected by ABL to distinguish between models. Nothing like that here? Maybe something like the panel params, but two of the variants share a ddic, so that might not even be sufficient. But if I add u-boot to the boot sequence, then I lose a lot of things that abl handles and have to set them up in u-boot. Things like loading init_boot and vendor_boot ramdisks, handling bootconfig, avb parameters, etc etc. Or drastically change the aosp device tree configs to disable those things and in doing so become non-compliant with current aosp expectations. Long story short: chainloading another bootloader and staying compliant with vts is a *lot* of effort I really don't want to do. Booting android on qcom via u-boot is certainly possible and I've seen others doing so, but those have deviated a lot from the OS expectations, and the more deviations there are, the larger the chance that unexpected things go horribly wrong. Aaron
On Fri, Mar 13, 2026 at 01:21:39PM -0500, Aaron Kling wrote: > On Fri, Mar 13, 2026 at 12:48 PM Dmitry Baryshkov > <dmitry.baryshkov@oss.qualcomm.com> wrote: > > > > On Fri, Mar 13, 2026 at 12:34:21PM -0500, Aaron Kling wrote: > > > On Fri, Mar 13, 2026 at 3:37 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > > > On Fri, Mar 13, 2026 at 05:19:27AM +0200, Dmitry Baryshkov wrote: > > > > > On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote: > > > > > > On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@packett.cool> wrote: > > > > > > > > > > > > > > On 3/11/26 2:44 PM, Aaron Kling wrote: > > > > > > > > > > > > > > > From: Teguh Sobirin <teguh@sobir.in> > > > > > > > > > > > > > > > > This adds a base dtb of everything common between the AYN QCS8550 > > > > > > > > devices. It is intended to be extended by device specific overlays. > > > > > > > > > > > > > > > > Signed-off-by: Teguh Sobirin <teguh@sobir.in> > > > > > > > > Co-developed-by: Aaron Kling <webgeek1234@gmail.com> > > > > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com> > > > > > > > > --- > > > > > > > > arch/arm64/boot/dts/qcom/Makefile | 1 + > > > > > > > > arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++ > > > > > > > > Common is not a board, NAK. This could only be DTSI if you provide some > > > > sort of HARDWARE arguments explaining the common parts of schematics or > > > > hardware design. > > > > > > > > > > > Not enough. We do not add compatibles not representing actual hardware, > > > > just to streamline boot image handling. > > > > > > > > Plus this code is not even truly correct. > > > > > > > > We do not write DTS to fulfill broken Android boot process. > > > > > > I have been trying rather hard to find a reasonable compromise between > > > mainline requirements and a normal Android use case, something I can > > > actually ship to normal users. This seemed fairly reasonable to me, > > > since it can generate standalone dtb's transparently. But if my use > > > case can never meet submission requirements, then why am I even here, > > > getting shamed for working on Android? If I have to fork the > > > device-tree anyways to fit my requirements, then there's no reason for > > > me to put the time and effort in to submitting something I can't use. > > > I'd be better off just keeping everything out of tree as googles > > > kernel-platform supports. And never look at mainline qcom again. > > > > Well... It's a tough argument. Getting your DTs into mainline would help > > occasional users that would like to run something else than Android > > (PmOS or some other distro). Also it ensures that you can run Android > > even when Google (Qualcomm) EOL the current SM8550 msm-something tree. > > Oh, I'm not working on the downstream kernel either way. The question > is whether device support gets mainlined or if I keep all support out > of tree and only update when Google forks the ack from a new lts. > > > Speaking about the boot process. I remember that historically it was > > possible to pass several DTBs in the the Android boot image. Is it no > > longer the case? Is there any way to identify the boards (I think > > historical code was using qcom,board-id for that)? Then you would be > > able to squash all your DTBs in a single boot image. > > That functionality is still there, the concatenated dtb slot in the > vendor_boot image. Unfortunately for this context, the odm did not > change those ids per hardware variant. I think they just left them at > the hdk or qrd default that came with the bsp. I do have to jump some > software hoops to slot in the correct dtbo to the dtbo partition > during inline updates because of this, but it's not terrible. And > that's not something I can reasonably do for the vendor_boot image. To > my knowledge, there is no way for the bootloader to tell these devices > apart and any attempt to do so would require a custom abl build, > probably per variant, which would then desync the boot firmware from > the official OS, plus make first install more difficult for users, > both of which I'm trying not to do. Adding Amit to cc, maybe he'd have any recommendations. -- With best wishes Dmitry
On 13/03/2026 18:34, Aaron Kling wrote: >> >> We do not write DTS to fulfill broken Android boot process. > > I have been trying rather hard to find a reasonable compromise between > mainline requirements and a normal Android use case, something I can > actually ship to normal users. This seemed fairly reasonable to me, > since it can generate standalone dtb's transparently. But if my use > case can never meet submission requirements, then why am I even here, > getting shamed for working on Android? If I have to fork the > device-tree anyways to fit my requirements, then there's no reason for > me to put the time and effort in to submitting something I can't use. > I'd be better off just keeping everything out of tree as googles > kernel-platform supports. And never look at mainline qcom again. In one of the previous threads there were ideas how to solve it, e.g. chain loading bootloader or ditching ABL. The true problem is here Google and its Android policy which hinders any real world upstream usage. The solution is to Android to change (yeah, good luck :) ) or ditch Android in favor of other modern solutions. I think you want to have cookie and eat cookie... Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.