[PATCH v2 0/5] arm64: dts: qcom: Support AYN QCS8550 Devices

[PATCH v2 0/5] arm64: dts: qcom: Support AYN QCS8550 Devices

[Aaron Kling via B4 Relay]

This specifically includes:
* Odin 2 Mini
* Odin 2 Portal
* Thor

The original Odin 2 dtso is not currently included as it has not yet
been verified.

The initial port was done by Teguh Sobirin for ROCKNIX and was made
available on the AYN github [0].

Support has been removed for things not yet supported by the upstream
kernel, these will be added later when the related drivers are submitted
and picked up. Such includes:

* All panels
* The Odin 2 Mini backlight and touch
* All rgb leds
* The built-in uart gamepad

This series depends on one other series as described in b4 deps. Namely,
the one adding the AYN vendor [1]. This must be merged first for schema
checks to succeed.

[0] https://github.com/AYNTechnologies/linux/commits/sm8550/v6.17.5/
[1] https://lore.kernel.org/all/20260220-ayn-vendor-v1-1-292cbbb682b3@gmail.com/

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
Changes in v2:
- Drop awinic bindings dep as a duplicated patch already exists
- Change Co-authored-by tags to Co-developed-by
- Drop alias to currently unused uart15 in patch 2
- Link to v1: https://lore.kernel.org/r/20260311-ayn-qcs8550-v1-0-fe8b2faad1ea@gmail.com

---
Aaron Kling (1):
      dt-bindings: arm: qcom: Add AYN QCS8550 Devices

Teguh Sobirin (4):
      arm64: dts: qcom: Add AYN QCS8550 Common
      arm64: dts: qcom: Add AYN Odin 2 Mini
      arm64: dts: qcom: Add AYN Odin 2 Portal
      arm64: dts: qcom: Add AYN Thor

 Documentation/devicetree/bindings/arm/qcom.yaml    |   10 +
 arch/arm64/boot/dts/qcom/Makefile                  |    7 +
 arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
 .../boot/dts/qcom/qcs8550-ayntec-odin2mini.dtso    |  147 ++
 .../boot/dts/qcom/qcs8550-ayntec-odin2portal.dtso  |   79 +
 arch/arm64/boot/dts/qcom/qcs8550-ayntec-thor.dtso  |  223 +++
 6 files changed, 2243 insertions(+)
---
base-commit: f90aadf1c67c8b4969d1e5e6d4fd7227adb6e4d7
change-id: 20260217-ayn-qcs8550-16c07b63de26
prerequisite-change-id: 20260220-ayn-vendor-a153168c29b2:v1
prerequisite-patch-id: 042cab8f04748207ba5395dd0f23c445955aaa2b

Best regards,
-- 
Aaron Kling <webgeek1234@gmail.com>

[PATCH v2 1/5] dt-bindings: arm: qcom: Add AYN QCS8550 Devices

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

Namely:
* Odin 2
* Odin 2 Mini
* Odin 2 Portal
* Thor

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index d054a8f5632d853509b7cd37f07f02473cf6bf71..d76c0b0a082e2ee1a2adaefdb4601048cb8e8a70 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1075,6 +1075,16 @@ properties:
           - const: qcom,qcs8550
           - const: qcom,sm8550
 
+      - items:
+          - enum:
+              - ayntec,odin2
+              - ayntec,odin2mini
+              - ayntec,odin2portal
+              - ayntec,qcs8550-common
+              - ayntec,thor
+          - const: qcom,qcs8550
+          - const: qcom,sm8550
+
       - items:
           - enum:
               - qcom,sm8650-hdk

-- 
2.53.0

Re: [PATCH v2 1/5] dt-bindings: arm: qcom: Add AYN QCS8550 Devices

[Krzysztof Kozlowski]

On Wed, Mar 11, 2026 at 12:44:37PM -0500, Aaron Kling wrote:
> Namely:
> * Odin 2
> * Odin 2 Mini
> * Odin 2 Portal
> * Thor
> 
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index d054a8f5632d853509b7cd37f07f02473cf6bf71..d76c0b0a082e2ee1a2adaefdb4601048cb8e8a70 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -1075,6 +1075,16 @@ properties:
>            - const: qcom,qcs8550
>            - const: qcom,sm8550
>  
> +      - items:
> +          - enum:
> +              - ayntec,odin2
> +              - ayntec,odin2mini
> +              - ayntec,odin2portal
> +              - ayntec,qcs8550-common

There is no such product as qcs8550-common. Drop.

Best regards,
Krzysztof

[PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling via B4 Relay]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Val Packett]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Dmitry Baryshkov]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Krzysztof Kozlowski]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Krzysztof Kozlowski]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Dmitry Baryshkov]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Dmitry Baryshkov]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Val Packett]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Konrad Dybcio]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Konrad Dybcio]

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

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

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

Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Konrad Dybcio]

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

[PATCH v2 3/5] arm64: dts: qcom: Add AYN Odin 2 Mini

[Aaron Kling via B4 Relay]

From: Teguh Sobirin <teguh@sobir.in>

The AYN Odin 2 Mini is a high-performance Android-based handheld gaming
console powered by the Qualcomm Snapdragon 8 Gen 2 processor featuring a
5-inch mini-led touchscreen.

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                  |   2 +
 .../boot/dts/qcom/qcs8550-ayntec-odin2mini.dtso    | 147 +++++++++++++++++++++
 2 files changed, 149 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 5bb88dd7a31bbd8ee7078a880056cc1f35be494e..3dd5db42713b1d468d029518178a9df33af991c9 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -164,6 +164,8 @@ 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
+qcs8550-ayntec-odin2mini-dtbs := qcs8550-ayntec-common.dtb qcs8550-ayntec-odin2mini.dtbo
+dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-ayntec-odin2mini.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-odin2mini.dtso b/arch/arm64/boot/dts/qcom/qcs8550-ayntec-odin2mini.dtso
new file mode 100644
index 0000000000000000000000000000000000000000..60b402a6b98857f56b04c44b053d5a46faf8c0a6
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-ayntec-odin2mini.dtso
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025, Teguh Sobirin.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+	model = "AYN Odin 2 Mini";
+	compatible = "ayntec,odin2mini", "qcom,qcs8550", "qcom,sm8550";
+
+	hdmi-out {
+		compatible = "hdmi-connector";
+		type = "d";
+		hpd-gpios = <&tlmm 9 GPIO_ACTIVE_HIGH>;
+		hdmi-pwr-supply = <&vdd_hdmi_1v8>;
+
+		port {
+			hdmi_con: endpoint {
+				remote-endpoint = <&lt8912_out>;
+			};
+		};
+	};
+
+	vcc_hdmi_1v8: vcc-hdmi-1v8-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_hdmi_1v8";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		gpio = <&tlmm 10 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vdd_bl_5v0: vdd-bl-5v0-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_bl_5v0";
+
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+
+		gpio = <&tlmm 55 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vdd_disp_2v8: vdd-disp-2v8-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_disp_2v8";
+
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+
+		gpio = <&tlmm 142 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vdd_hdmi_1v8: vdd-hdmi-1v8-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_hdmi_1v8";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		gpio = <&tlmm 6 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+};
+
+&i2c_hub_0 {
+	clock-frequency = <100000>;
+	status = "okay";
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	lt8912_codec: hdmi-bridge@48 {
+		compatible = "lontium,lt8912b";
+		reg = <0x48> ;
+
+		reset-gpios = <&tlmm 7 GPIO_ACTIVE_LOW>;
+
+		vdd-supply = <&vdd_hdmi_1v8>;
+		vccmipirx-supply = <&vcc_hdmi_1v8>;
+		vccsysclk-supply = <&vcc_hdmi_1v8>;
+		vcclvdstx-supply = <&vcc_hdmi_1v8>;
+		vcchdmitx-supply = <&vcc_hdmi_1v8>;
+		vcclvdspll-supply = <&vcc_hdmi_1v8>;
+		vcchdmipll-supply = <&vcc_hdmi_1v8>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				hdmi_out_in: endpoint {
+					data-lanes = <1 2 3 4>;
+					remote-endpoint = <&mdss_dsi0_out>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+
+				lt8912_out: endpoint {
+					remote-endpoint = <&hdmi_con>;
+				};
+			};
+		};
+	};
+};
+
+&mdss_dsi0 {
+	vdda-supply = <&vreg_l3e_1p2>;
+	status = "okay";
+};
+
+&mdss_dsi0_out {
+	remote-endpoint = <&hdmi_out_in>;
+	data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi0_phy {
+	vdds-supply = <&vreg_l1e_0p88>;
+	status = "okay";
+};
+
+&remoteproc_adsp {
+	firmware-name = "qcom/sm8550/ayntec/odin2mini/adsp.mbn",
+			"qcom/sm8550/ayntec/odin2mini/adsp_dtb.mbn";
+	status = "okay";
+};
+
+&spk_amp_l {
+	firmware-name = "qcom/sm8550/ayntec/odin2mini/aw883xx_acf.bin";
+};
+
+&spk_amp_r {
+	firmware-name = "qcom/sm8550/ayntec/odin2mini/aw883xx_acf.bin";
+};
+

-- 
2.53.0

Re: [PATCH v2 3/5] arm64: dts: qcom: Add AYN Odin 2 Mini

[Krzysztof Kozlowski]

On Wed, Mar 11, 2026 at 12:44:39PM -0500, Aaron Kling wrote:
> From: Teguh Sobirin <teguh@sobir.in>
> 
> The AYN Odin 2 Mini is a high-performance Android-based handheld gaming
> console powered by the Qualcomm Snapdragon 8 Gen 2 processor featuring a
> 5-inch mini-led touchscreen.
> 
> 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                  |   2 +
>  .../boot/dts/qcom/qcs8550-ayntec-odin2mini.dtso    | 147 +++++++++++++++++++++

NAK

overlays are not for boards. I think I was clear in the past.

Please carry:

Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>


Best regards,
Krzysztof

Re: [PATCH v2 3/5] arm64: dts: qcom: Add AYN Odin 2 Mini

[Krzysztof Kozlowski]

On 13/03/2026 09:39, Krzysztof Kozlowski wrote:
> On Wed, Mar 11, 2026 at 12:44:39PM -0500, Aaron Kling wrote:
>> From: Teguh Sobirin <teguh@sobir.in>
>>
>> The AYN Odin 2 Mini is a high-performance Android-based handheld gaming
>> console powered by the Qualcomm Snapdragon 8 Gen 2 processor featuring a
>> 5-inch mini-led touchscreen.
>>
>> 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                  |   2 +
>>  .../boot/dts/qcom/qcs8550-ayntec-odin2mini.dtso    | 147 +++++++++++++++++++++
> 
> NAK
> 
> overlays are not for boards. I think I was clear in the past.


Here for example - response to your posting:

https://lore.kernel.org/all/487e4605-0a21-48d6-8b77-9ce2799ad212@kernel.org/

I don't accept changing known and widely accepted DTS style to match
broken Android boot processes. We don't take that downstream approach
here. We pushed against such Android crap in the past and we will be
pushing further, till Android finally starts working with upstream.

> 
> Please carry:
> 
> Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>


Best regards,
Krzysztof

[PATCH v2 4/5] arm64: dts: qcom: Add AYN Odin 2 Portal

[Aaron Kling via B4 Relay]

From: Teguh Sobirin <teguh@sobir.in>

The AYN Odin 2 Portal is a high-performance Android-based handheld gaming
console powered by the Qualcomm Snapdragon 8 Gen 2 processor featuring a
7-inch OLED touchscreen.

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                  |  2 +
 .../boot/dts/qcom/qcs8550-ayntec-odin2portal.dtso  | 79 ++++++++++++++++++++++
 2 files changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 3dd5db42713b1d468d029518178a9df33af991c9..c4226223203dfbbc5f9f79e88433398ca6a0307a 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -166,6 +166,8 @@ dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-ayntec-common.dtb
 qcs8550-ayntec-odin2mini-dtbs := qcs8550-ayntec-common.dtb qcs8550-ayntec-odin2mini.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-ayntec-odin2mini.dtb
+qcs8550-ayntec-odin2portal-dtbs := qcs8550-ayntec-common.dtb qcs8550-ayntec-odin2portal.dtbo
+dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-ayntec-odin2portal.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-odin2portal.dtso b/arch/arm64/boot/dts/qcom/qcs8550-ayntec-odin2portal.dtso
new file mode 100644
index 0000000000000000000000000000000000000000..4f15612430d9af2eb065d98fb3e4536f434d08d7
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-ayntec-odin2portal.dtso
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025, Teguh Sobirin.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+	model = "AYN Odin 2 Portal";
+	compatible = "ayntec,odin2portal", "qcom,qcs8550", "qcom,sm8550";
+
+	vdd_bl_5v0: vdd-bl-5v0-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_bl_5v0";
+
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+
+		gpio = <&tlmm 52 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vdd_disp_2v8: vdd-disp-2v8-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_disp_2v8";
+
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+
+		gpio = <&tlmm 142 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+};
+
+&i2c4 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	touchscreen@38 {
+		compatible = "focaltech,ft5426";
+		reg = <0x38>;
+
+		interrupt-parent = <&tlmm>;
+		interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+
+		reset-gpios = <&tlmm 24 GPIO_ACTIVE_LOW>;
+
+		vcc-supply = <&vreg_l14b_3p2>;
+		iovcc-supply = <&vreg_l12b_1p8>;
+
+		pinctrl-0 = <&ts_p_rst_default &ts_p_int_default>;
+		pinctrl-1 = <&ts_p_rst_sleep &ts_p_int_sleep>;
+		pinctrl-names = "default", "sleep";
+
+		touchscreen-size-x = <1080>;
+		touchscreen-size-y = <1920>;
+		touchscreen-swapped-x-y;
+		touchscreen-inverted-y;
+	};
+};
+
+&remoteproc_adsp {
+	firmware-name = "qcom/sm8550/ayntec/odin2portal/adsp.mbn",
+			"qcom/sm8550/ayntec/odin2portal/adsp_dtb.mbn";
+	status = "okay";
+};
+
+&spk_amp_l {
+	firmware-name = "qcom/sm8550/ayntec/odin2portal/aw883xx_acf.bin";
+};
+
+&spk_amp_r {
+	firmware-name = "qcom/sm8550/ayntec/odin2portal/aw883xx_acf.bin";
+};
+

-- 
2.53.0

[PATCH v2 5/5] arm64: dts: qcom: Add AYN Thor

[Aaron Kling via B4 Relay]

From: Teguh Sobirin <teguh@sobir.in>

The AYN Thor is a high-performance Android-based handheld gaming console
powered by the Qualcomm Snapdragon 8 Gen 2 processor featuring dual
AMOLED touchscreens.

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                 |   2 +
 arch/arm64/boot/dts/qcom/qcs8550-ayntec-thor.dtso | 223 ++++++++++++++++++++++
 2 files changed, 225 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index c4226223203dfbbc5f9f79e88433398ca6a0307a..31759e49eb3ad661e0a0ded4f58bd61ec3f234aa 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -168,6 +168,8 @@ qcs8550-ayntec-odin2mini-dtbs := qcs8550-ayntec-common.dtb qcs8550-ayntec-odin2m
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-ayntec-odin2mini.dtb
 qcs8550-ayntec-odin2portal-dtbs := qcs8550-ayntec-common.dtb qcs8550-ayntec-odin2portal.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-ayntec-odin2portal.dtb
+qcs8550-ayntec-thor-dtbs := qcs8550-ayntec-common.dtb qcs8550-ayntec-thor.dtbo
+dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-ayntec-thor.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-thor.dtso b/arch/arm64/boot/dts/qcom/qcs8550-ayntec-thor.dtso
new file mode 100644
index 0000000000000000000000000000000000000000..65f2a820d08268671ac5beb959c1d79cde43015d
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-ayntec-thor.dtso
@@ -0,0 +1,223 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025, Teguh Sobirin.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+	model = "AYN Thor";
+	compatible = "ayntec,thor", "qcom,qcs8550", "qcom,sm8550";
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		pinctrl-0 = <&volume_up_n &key_ayn_n>;
+
+		key-ayn {
+			label = "AYN Key";
+			debounce-interval = <15>;
+			gpios = <&tlmm 41 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_F24>;
+			linux,can-disable;
+		};
+
+		switch-lid {
+			label = "Hall Lid Sensor";
+			gpios = <&tlmm 17 GPIO_ACTIVE_LOW>;
+			linux,input-type = <EV_SW>;
+			linux,code = <SW_LID>;
+			linux,can-disable;
+			wakeup-source;
+		};
+	};
+
+	vdd_bl_5v0: vdd-bl-5v0-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_bl_5v0";
+
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+
+		gpio = <&tlmm 52 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vdd_disp_1v8: vdd-disp-1v8-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_disp_1v8";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vdd_disp1_2v8: vdd-disp1-2v8-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_disp1_2v8";
+
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+
+		gpio = <&tlmm 142 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vdd_disp2_2v8: vdd-disp2-2v8-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_disp2_2v8";
+
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+
+		gpio = <&tlmm 143 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vdd_ts_3v0: vdd-ts-3v0-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_ts_3v0";
+
+		regulator-min-microvolt = <3000000>;
+		regulator-max-microvolt = <3000000>;
+
+		gpio = <&tlmm 144 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vdd_ts_1v8: vdd-ts-1v8-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_ts_1v8";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		gpio = <&tlmm 102 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+};
+
+&i2c4 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	touchscreen@38 {
+		compatible = "focaltech,ft5426";
+		reg = <0x38>;
+
+		interrupt-parent = <&tlmm>;
+		interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+
+		reset-gpios = <&tlmm 24 GPIO_ACTIVE_LOW>;
+
+		vcc-supply = <&vreg_l14b_3p2>;
+		iovcc-supply = <&vreg_l12b_1p8>;
+
+		pinctrl-0 = <&ts_p_rst_default &ts_p_int_default>;
+		pinctrl-1 = <&ts_p_rst_sleep &ts_p_int_sleep>;
+		pinctrl-names = "default", "sleep";
+
+		touchscreen-size-x = <1080>;
+		touchscreen-size-y = <1920>;
+		touchscreen-swapped-x-y;
+		touchscreen-inverted-x;
+	};
+};
+
+&i2c_hub_3 {
+	clock-frequency = <100000>;
+	status = "okay";
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	touchscreen@38 {
+		compatible = "focaltech,ft5452";
+		reg = <0x38>;
+
+		interrupt-parent = <&tlmm>;
+		interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
+
+		reset-gpios = <&tlmm 14 GPIO_ACTIVE_LOW>;
+
+		vcc-supply = <&vdd_ts_3v0>;
+		iovcc-supply = <&vdd_ts_1v8>;
+
+		pinctrl-0 = <&ts_s_rst_default &ts_s_int_default>;
+		pinctrl-1 = <&ts_s_rst_sleep &ts_s_int_sleep>;
+		pinctrl-names = "default", "sleep";
+
+		touchscreen-size-x = <1080>;
+		touchscreen-size-y = <1240>;
+		touchscreen-swapped-x-y;
+		touchscreen-inverted-x;
+	};
+};
+
+&mdss_dsi0 {
+	vdda-supply = <&vreg_l3e_1p2>;
+	status = "okay";
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	panel@0 {
+		reg = <0>;
+
+		port {
+			panel0_in: endpoint {
+				remote-endpoint = <&mdss_dsi0_out>;
+			};
+		};
+	};
+};
+
+&mdss_dsi0_out {
+	remote-endpoint = <&panel0_in>;
+	data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi0_phy {
+	vdds-supply = <&vreg_l1e_0p88>;
+	status = "okay";
+};
+
+&mdss_dsi1_out {
+	qcom,te-source = "mdp_vsync_s";
+};
+
+&pm8550_pwm {
+	multi-led {
+		status = "disabled";
+	};
+};
+
+&remoteproc_adsp {
+	firmware-name = "qcom/sm8550/ayntec/thor/adsp.mbn",
+			"qcom/sm8550/ayntec/thor/adsp_dtb.mbn";
+	status = "okay";
+};
+
+&spk_amp_l {
+	firmware-name = "qcom/sm8550/ayntec/thor/aw883xx_acf.bin";
+};
+
+&spk_amp_r {
+	firmware-name = "qcom/sm8550/ayntec/thor/aw883xx_acf.bin";
+};
+
+&tlmm {
+	key_ayn_n: key-ayn-n-state {
+		pins = "gpio41";
+		function = "gpio";
+		bias-pull-up;
+		output-disable;
+	};
+};

-- 
2.53.0

Re: [PATCH v2 5/5] arm64: dts: qcom: Add AYN Thor

[Konrad Dybcio]

On 3/11/26 6:44 PM, Aaron Kling via B4 Relay wrote:
> From: Teguh Sobirin <teguh@sobir.in>
> 
> The AYN Thor is a high-performance Android-based handheld gaming console
> powered by the Qualcomm Snapdragon 8 Gen 2 processor featuring dual
> AMOLED touchscreens.
> 
> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---

[...]

> +&spk_amp_r {
> +	firmware-name = "qcom/sm8550/ayntec/thor/aw883xx_acf.bin";

That's perhaps a dumb question, but are they actually different between
the devices?

Konrad

Re: [PATCH v2 5/5] arm64: dts: qcom: Add AYN Thor

[Aaron Kling]

On Thu, Mar 19, 2026 at 6:32 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>
> >
> > The AYN Thor is a high-performance Android-based handheld gaming console
> > powered by the Qualcomm Snapdragon 8 Gen 2 processor featuring dual
> > AMOLED touchscreens.
> >
> > Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> > Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
>
> [...]
>
> > +&spk_amp_r {
> > +     firmware-name = "qcom/sm8550/ayntec/thor/aw883xx_acf.bin";
>
> That's perhaps a dumb question, but are they actually different between
> the devices?

To my consternation, yes they are all different. Most of them are even
different file sizes, it's not just header or signature differences. I
am assuming they contain tuning differences per device, but I really
don't know much about what they're doing.

Aaron

Re: [PATCH v2 5/5] arm64: dts: qcom: Add AYN Thor

[Konrad Dybcio]

On 3/19/26 6:48 PM, Aaron Kling wrote:
> On Thu, Mar 19, 2026 at 6:32 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>
>>>
>>> The AYN Thor is a high-performance Android-based handheld gaming console
>>> powered by the Qualcomm Snapdragon 8 Gen 2 processor featuring dual
>>> AMOLED touchscreens.
>>>
>>> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>> ---
>>
>> [...]
>>
>>> +&spk_amp_r {
>>> +     firmware-name = "qcom/sm8550/ayntec/thor/aw883xx_acf.bin";
>>
>> That's perhaps a dumb question, but are they actually different between
>> the devices?
> 
> To my consternation, yes they are all different. Most of them are even
> different file sizes, it's not just header or signature differences. I
> am assuming they contain tuning differences per device, but I really
> don't know much about what they're doing.

Yeah I would assume they contain device-specific tuning or whatnot, but
I was curious whether the vendor actually did that

Konrad

Re: [PATCH v2 5/5] arm64: dts: qcom: Add AYN Thor

[Teguh Sobirin]

Yes the firmware contain DSP calibration for frequency response based on speaker type, dimension and size used in the device.

Regards,
Teguh.

> On 23 Mar 2026, at 16.38, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> 
> On 3/19/26 6:48 PM, Aaron Kling wrote:
>>> On Thu, Mar 19, 2026 at 6:32 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>
>>>> 
>>>> The AYN Thor is a high-performance Android-based handheld gaming console
>>>> powered by the Qualcomm Snapdragon 8 Gen 2 processor featuring dual
>>>> AMOLED touchscreens.
>>>> 
>>>> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
>>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
>>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>>> ---
>>> 
>>> [...]
>>> 
>>>> +&spk_amp_r {
>>>> +     firmware-name = "qcom/sm8550/ayntec/thor/aw883xx_acf.bin";
>>> 
>>> That's perhaps a dumb question, but are they actually different between
>>> the devices?
>> 
>> To my consternation, yes they are all different. Most of them are even
>> different file sizes, it's not just header or signature differences. I
>> am assuming they contain tuning differences per device, but I really
>> don't know much about what they're doing.
> 
> Yeah I would assume they contain device-specific tuning or whatnot, but
> I was curious whether the vendor actually did that
> 
> Konrad