Re: [PATCH 3/3] arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console
On 1/22/26 10:25 AM, Neil Armstrong wrote:
> On 1/22/26 10:15, Konrad Dybcio wrote:
>> On 1/21/26 5:40 PM, Neil Armstrong wrote:
>>> From: KancyJoe
>>>
>>> Add initial Device Tree for the Ayaneo Pocket S2 gaming console based
>>> on the Qualcomm Snapdragon 8 Gen 3 platform.
>>>
>>> The design is similar to a phone wihout the modem, the game control
>>> is handled via a standalone controller connected to a PCIe USB
>>> controller.
>>>
>>> Display support will be added in a second time.
>>>
>>> Signed-off-by: KancyJoe
>>> Signed-off-by: Neil Armstrong
>>> ---
[...]
>>> +&pcieport1 {
>>> + pinctrl-0 = <&upd720201_active>;
>>
>> Is this a regulator?
>
> There's s 3 gpios, the 3 are required to have the controller to show up,
> it could be 3 regulators and a reset line, I don't know. The controller
> needs 1.05v and 3.3v plus a reset signal, but I don't know which one
> is which and if it's really regulators...
I'm not going to make you.. but if you would like to open the device
and poke at it with a multimeter while toggling GPIOs... the footprint
for this controller is freely accessible
Konrad
Re: [PATCH 3/3] arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console
On 1/22/2026 9:30 AM, Dmitry Baryshkov wrote:
On Wed, Jan 21, 2026 at 05:40:28PM +0100, Neil Armstrong wrote:
From: KancyJoe
Add initial Device Tree for the Ayaneo Pocket S2 gaming console based
on the Qualcomm Snapdragon 8 Gen 3 platform.
The design is similar to a phone wihout the modem, the game control
is handled via a standalone controller connected to a PCIe USB
controller.
Display support will be added in a second time.
Signed-off-by: KancyJoe
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/Makefile |1 +
.../boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts | 1445
arch/arm64/boot/dts/qcom/sm8650.dtsi |2 +-
drivers/gpu/drm/msm/dsi/dsi.c |4 +-
4 files changed, 1449 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 6f34d5ed331c..1ba29755e5ba 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -313,6 +313,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8550-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-samsung-q5q.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-sony-xperia-yodo-pdx234.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sm8650-ayaneo-pocket-s2.dtb
sm8650-hdk-display-card-dtbs := sm8650-hdk.dtb sm8650-hdk-display-card.dtbo
diff --git a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
new file mode 100644
index ..141d92933957
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
+
+&i2c3 {
clock-frequency?
+ status = "okay";
+
+ wcd_usbss: typec-mux@e {
+ compatible = "qcom,wcd9395-usbss", "qcom,wcd9390-usbss";
+ reg = <0xe>;
+
+ vdd-supply = <&vreg_l15b_1p8>;
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_HIGH>;
+
+ mode-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ wcd_usbss_sbu_mux: endpoint {
+ remote-endpoint = <&pmic_glink_sbu>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ wcd_usbss_headset_out: endpoint {
+ remote-endpoint =
<&wcd_codec_headset_in>;
+ };
+ };
+ };
+ };
+};
+
+&i2c6 {
clock-frequency?
The clock frequency properties are not defined in the qcom reference
devices' devicetrees. The default frequency 100khz works. If they are
required we can add them in next patch version.
+ status = "okay";
+
+ typec-mux@1c {
+ compatible = "onnn,nb7vpq904m";
+ reg = <0x1c>;
+
+ vcc-supply = <&vreg_l15b_1p8>;
+
+ retimer-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ redriver_ss_out: endpoint {
+ remote-endpoint = <&pmic_glink_ss_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ redriver_ss_in: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_out>;
+ };
+ };
+ };
+ };
+};
+
+&iris {
+ status = "okay";
With the default firmware?
Yes. The soc in the game console is unfused.
+&remoteproc_adsp {
+ firmware-name = "qcom/sm8650/ayaneo/ps2/adsp.mbn",
+ "qcom/sm8650/ayaneo/ps2/adsp_dtb.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm8650/ayaneo/ps2/cdsp.mbn",
+ "qcom/sm8650/ayaneo/ps2/cdsp_dtb.mbn";
Is it fused?
It's unfused. For adsp it contains battery/charging configurations so
it's required to be the vendor's one here.
I'm not familiar with cdsp or what cdsp does but for stability i used
the fw from vendor. Additionally, the default cdsp/adsp/vpu firmwares
are not uploaded to upstream linux-firmware repo so I was not able to
test the default fw. (See
https://gitlab.com/kernel-firmware/linux-firmware/-/tree/20260110/qcom/sm8650?ref_type=tags).
We will use the default one here instead if cdsp is not device-specific
or the default fw works on it.
+
+ status = "okay";
+};
+
diff --git a/arch/arm64/
Re: [PATCH 3/3] arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console
On 1/22/2026 5:25 PM, Neil Armstrong wrote:
On 1/22/26 10:15, Konrad Dybcio wrote:
On 1/21/26 5:40 PM, Neil Armstrong wrote:
From: KancyJoe
Add initial Device Tree for the Ayaneo Pocket S2 gaming console based
on the Qualcomm Snapdragon 8 Gen 3 platform.
The design is similar to a phone wihout the modem, the game control
is handled via a standalone controller connected to a PCIe USB
controller.
Display support will be added in a second time.
Signed-off-by: KancyJoe
Signed-off-by: Neil Armstrong
---
[...]
+ fan: pwm-fan {
I'd call it fan {} but gray/grey
+ status = "okay";
You can drop this line (nothing disables it)
Oops will remove
+ compatible = "pwm-fan";
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
interrupts-extended looks neater
Ack
+
+ pinctrl-0 = <&fan_pwr_active>,
+ <&pwm_fan_ctrl_default>,
+ <&fan_int_active>;
+ pinctrl-1 = <&fan_pwr_sleep>;
fan-pwr looks like an EN pin of a GPIO-controlled regulator
Probably, will model it as a regulator
+ pinctrl-names = "default",
+ "sleep";
+
+ pwms = <&pm8550_pwm 3 5>;
+
+ #cooling-cells = <2>;
+ cooling-levels = <0 16 32 45 60 80 105 130 155 180 205 230
255>;
Does this come from a preexisting map?
Kancy ?
No it is not a preexisting map. I add it(and the thermal part) myself to
get dynamic fan speed control work. Perhaps you can also use userspace
fan control daemon instead of hardcode it here. In android the vendor
control the fan speed in userspace too.
Following block is what the stock fw defined. I changed the granularity
to make fan speed (or noise actually) sounds more "smooth".
```
cooling-levels = <0 64 128 255>;
```
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&volume_up_n>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
+ debounce-interval = <15>;
+ linux,can-disable;
+ wakeup-source;
+ };
+ };
+
+ pmic-glink {
+ compatible = "qcom,sm8650-pmic-glink",
+ "qcom,sm8550-pmic-glink",
+ "qcom,pmic-glink";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ orientation-gpios = <&tlmm 29 GPIO_ACTIVE_HIGH>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+
+ power-role = "dual";
+ data-role = "dual";
+ self-powered;
Is this property interpreted at all by our setup?
Kancy did add self-powered, but it does charging so it should be dropped.
[...]
+ sound {
+ compatible = "qcom,sm8650-sndcard", "qcom,sm8450-sndcard";
+ model = "SM8650-APS2";
+ audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
+ "SpkrRight IN", "WSA_SPK2 OUT",
+ "IN1_HPHL", "HPHL_OUT",
+ "IN2_HPHR", "HPHR_OUT",
+ "DMIC1", "MIC BIAS1",
+ "DMIC2", "MIC BIAS2",
+ "AMIC2", "MIC BIAS2",
+ "TX SWR_INPUT1", "ADC2_OUTPUT",
+ "TX SWR_INPUT7", "DMIC1_OUTPUT",
+ "TX SWR_INPUT8", "DMIC2_OUTPUT";
+
+ wcd-playback-dai-link {
+ link-name = "WCD Playback";
+
+ cpu {
+ sound-dai = <&q6apmbedai RX_CODEC_DMA_RX_0>;
+ };
+
+ codec {
+ sound-dai = <&wcd939x 0>,
+ <&swr1 0>,
+ <&lpass_rxmacro 0>;
+ };
'co'dec < 'cp'u
[...]
+ wcd939x: audio-codec {
'a'udio-codec should be way higher
ack
[...]
+ thermal-zones {
+ cpu2-top-thermal {
+ trips {
+ cpu2_active: cpu2-active {
+ temperature = <38000>;
+ hysteresis = <2000>;
+ type = "active";
This is shaky.. let's perhaps reference each thermal zone that you want
to extend with a label.. Or maybe a pair of labels for
trips/cooling-maps
per zone?
Yep, will clean that by adding labels
[...]
+&pcieport1 {
+ pinctrl-0 = <&upd720201_active>;
Is this a regulator?
There's s 3 gpios, the 3 are required to have the controller to show up,
it could be 3 regulators and a reset line, I don't know. The controller
needs 1.05v and 3.3v plus a reset signal, but I don't know which one
is which and if it's really regulators...
+ pinctrl-names = "default";
+
+ /* Renesas μPD720201 PCIe USB3.0 HOST CONTROLLER */
DON'T SCREAM! :P
+ usb-controller@0 {
+ compatible = "pci1912,0014";
+ reg = <0x1 0x0 0x0 0x0 0x0>;
+
+ pinctrl-0 = <&gamepad_pwr_en>;
+ pinctrl-names = "default";
Is there a hub connected to it? Or does it go directly to the
aforementioned (game) c
Re: [PATCH 3/3] arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console
On 1/22/26 13:34, Konrad Dybcio wrote: On 1/22/26 10:34 AM, Kancy Joe wrote: On 1/22/2026 5:25 PM, Neil Armstrong wrote: On 1/22/26 10:15, Konrad Dybcio wrote: On 1/21/26 5:40 PM, Neil Armstrong wrote: From: KancyJoe Add initial Device Tree for the Ayaneo Pocket S2 gaming console based on the Qualcomm Snapdragon 8 Gen 3 platform. The design is similar to a phone wihout the modem, the game control is handled via a standalone controller connected to a PCIe USB controller. Display support will be added in a second time. Signed-off-by: KancyJoe Signed-off-by: Neil Armstrong --- [...] + pinctrl-names = "default", + "sleep"; + + pwms = <&pm8550_pwm 3 5>; + + #cooling-cells = <2>; + cooling-levels = <0 16 32 45 60 80 105 130 155 180 205 230 255>; Does this come from a preexisting map? Kancy ? No it is not a preexisting map. I add it(and the thermal part) myself to get dynamic fan speed control work. Perhaps you can also use userspace fan control daemon instead of hardcode it here. In android the vendor control the fan speed in userspace too. Following block is what the stock fw defined. I changed the granularity to make fan speed (or noise actually) sounds more "smooth". ``` cooling-levels = <0 64 128 255>; ``` FWIW the corresponding pwm-backlight driver has this num-interpolated-steps property which computes a smooth map.. not sure how many cooling levels are resonable for a PWM fan, but then I would intuitively not object to having more as opposed to less.. Good suggestion ! Neil Konrad
Re: [PATCH 3/3] arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console
On 1/22/26 10:34 AM, Kancy Joe wrote: > > On 1/22/2026 5:25 PM, Neil Armstrong wrote: >> On 1/22/26 10:15, Konrad Dybcio wrote: >>> On 1/21/26 5:40 PM, Neil Armstrong wrote: From: KancyJoe Add initial Device Tree for the Ayaneo Pocket S2 gaming console based on the Qualcomm Snapdragon 8 Gen 3 platform. The design is similar to a phone wihout the modem, the game control is handled via a standalone controller connected to a PCIe USB controller. Display support will be added in a second time. Signed-off-by: KancyJoe Signed-off-by: Neil Armstrong --- [...] + pinctrl-names = "default", + "sleep"; + + pwms = <&pm8550_pwm 3 5>; + + #cooling-cells = <2>; + cooling-levels = <0 16 32 45 60 80 105 130 155 180 205 230 255>; >>> >>> Does this come from a preexisting map? >> >> Kancy ? > > No it is not a preexisting map. I add it(and the thermal part) myself to get > dynamic fan speed control work. Perhaps you can also use userspace fan > control daemon instead of hardcode it here. In android the vendor control the > fan speed in userspace too. > > Following block is what the stock fw defined. I changed the granularity to > make fan speed (or noise actually) sounds more "smooth". > > ``` > > cooling-levels = <0 64 128 255>; > > ``` FWIW the corresponding pwm-backlight driver has this num-interpolated-steps property which computes a smooth map.. not sure how many cooling levels are resonable for a PWM fan, but then I would intuitively not object to having more as opposed to less.. Konrad
Re: [PATCH 3/3] arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console
On 1/22/26 10:15, Konrad Dybcio wrote:
On 1/21/26 5:40 PM, Neil Armstrong wrote:
From: KancyJoe
Add initial Device Tree for the Ayaneo Pocket S2 gaming console based
on the Qualcomm Snapdragon 8 Gen 3 platform.
The design is similar to a phone wihout the modem, the game control
is handled via a standalone controller connected to a PCIe USB
controller.
Display support will be added in a second time.
Signed-off-by: KancyJoe
Signed-off-by: Neil Armstrong
---
[...]
+ fan: pwm-fan {
I'd call it fan {} but gray/grey
+ status = "okay";
You can drop this line (nothing disables it)
Oops will remove
+ compatible = "pwm-fan";
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
interrupts-extended looks neater
Ack
+
+ pinctrl-0 = <&fan_pwr_active>,
+ <&pwm_fan_ctrl_default>,
+ <&fan_int_active>;
+ pinctrl-1 = <&fan_pwr_sleep>;
fan-pwr looks like an EN pin of a GPIO-controlled regulator
Probably, will model it as a regulator
+ pinctrl-names = "default",
+ "sleep";
+
+ pwms = <&pm8550_pwm 3 5>;
+
+ #cooling-cells = <2>;
+ cooling-levels = <0 16 32 45 60 80 105 130 155 180 205 230 255>;
Does this come from a preexisting map?
Kancy ?
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&volume_up_n>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
+ debounce-interval = <15>;
+ linux,can-disable;
+ wakeup-source;
+ };
+ };
+
+ pmic-glink {
+ compatible = "qcom,sm8650-pmic-glink",
+"qcom,sm8550-pmic-glink",
+"qcom,pmic-glink";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ orientation-gpios = <&tlmm 29 GPIO_ACTIVE_HIGH>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+
+ power-role = "dual";
+ data-role = "dual";
+ self-powered;
Is this property interpreted at all by our setup?
Kancy did add self-powered, but it does charging so it should be dropped.
[...]
+ sound {
+ compatible = "qcom,sm8650-sndcard", "qcom,sm8450-sndcard";
+ model = "SM8650-APS2";
+ audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
+ "SpkrRight IN", "WSA_SPK2 OUT",
+ "IN1_HPHL", "HPHL_OUT",
+ "IN2_HPHR", "HPHR_OUT",
+ "DMIC1", "MIC BIAS1",
+ "DMIC2", "MIC BIAS2",
+ "AMIC2", "MIC BIAS2",
+ "TX SWR_INPUT1", "ADC2_OUTPUT",
+ "TX SWR_INPUT7", "DMIC1_OUTPUT",
+ "TX SWR_INPUT8", "DMIC2_OUTPUT";
+
+ wcd-playback-dai-link {
+ link-name = "WCD Playback";
+
+ cpu {
+ sound-dai = <&q6apmbedai RX_CODEC_DMA_RX_0>;
+ };
+
+ codec {
+ sound-dai = <&wcd939x 0>,
+ <&swr1 0>,
+ <&lpass_rxmacro 0>;
+ };
'co'dec < 'cp'u
[...]
+ wcd939x: audio-codec {
'a'udio-codec should be way higher
ack
[...]
+ thermal-zones {
+ cpu2-top-thermal {
+ trips {
+ cpu2_active: cpu2-active {
+ temperature = <38000>;
+ hysteresis = <2000>;
+ type = "active";
This is shaky.. let's perhaps reference each thermal zone that you want
to extend with a label.. Or maybe a pair of labels for trips/cooling-maps
per zone?
Yep, will clean that by adding labels
[...]
+&pcieport1 {
+ pinctrl-0 = <&upd720201_active>;
Is this a regulator?
There's s 3 gpios, the 3 are required to have the controller to show up,
it could be 3 regulators and a reset line, I don't know. The controller
needs 1.05v and 3.3v plus a reset signal, but I don't know which one
is which and if it's really regulators...
+ pinctrl-names = "default";
+
+ /* Renesas μPD720201 PCIe USB3.0 HOST CONTROLLER */
DON'T SCREAM! :P
+ usb-controller@0 {
+
Re: [PATCH 3/3] arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console
On 1/21/26 5:40 PM, Neil Armstrong wrote:
> From: KancyJoe
>
> Add initial Device Tree for the Ayaneo Pocket S2 gaming console based
> on the Qualcomm Snapdragon 8 Gen 3 platform.
>
> The design is similar to a phone wihout the modem, the game control
> is handled via a standalone controller connected to a PCIe USB
> controller.
>
> Display support will be added in a second time.
>
> Signed-off-by: KancyJoe
> Signed-off-by: Neil Armstrong
> ---
[...]
> + fan: pwm-fan {
I'd call it fan {} but gray/grey
> + status = "okay";
You can drop this line (nothing disables it)
> + compatible = "pwm-fan";
> +
> + interrupt-parent = <&tlmm>;
> + interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
interrupts-extended looks neater
> +
> + pinctrl-0 = <&fan_pwr_active>,
> + <&pwm_fan_ctrl_default>,
> + <&fan_int_active>;
> + pinctrl-1 = <&fan_pwr_sleep>;
fan-pwr looks like an EN pin of a GPIO-controlled regulator
> + pinctrl-names = "default",
> + "sleep";
> +
> + pwms = <&pm8550_pwm 3 5>;
> +
> + #cooling-cells = <2>;
> + cooling-levels = <0 16 32 45 60 80 105 130 155 180 205 230 255>;
Does this come from a preexisting map?
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + pinctrl-0 = <&volume_up_n>;
> + pinctrl-names = "default";
> +
> + key-volume-up {
> + label = "Volume Up";
> + linux,code = ;
> + gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
> + debounce-interval = <15>;
> + linux,can-disable;
> + wakeup-source;
> + };
> + };
> +
> + pmic-glink {
> + compatible = "qcom,sm8650-pmic-glink",
> + "qcom,sm8550-pmic-glink",
> + "qcom,pmic-glink";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + orientation-gpios = <&tlmm 29 GPIO_ACTIVE_HIGH>;
> +
> + connector@0 {
> + compatible = "usb-c-connector";
> + reg = <0>;
> +
> + power-role = "dual";
> + data-role = "dual";
> + self-powered;
Is this property interpreted at all by our setup?
[...]
> + sound {
> + compatible = "qcom,sm8650-sndcard", "qcom,sm8450-sndcard";
> + model = "SM8650-APS2";
> + audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
> + "SpkrRight IN", "WSA_SPK2 OUT",
> + "IN1_HPHL", "HPHL_OUT",
> + "IN2_HPHR", "HPHR_OUT",
> + "DMIC1", "MIC BIAS1",
> + "DMIC2", "MIC BIAS2",
> + "AMIC2", "MIC BIAS2",
> + "TX SWR_INPUT1", "ADC2_OUTPUT",
> + "TX SWR_INPUT7", "DMIC1_OUTPUT",
> + "TX SWR_INPUT8", "DMIC2_OUTPUT";
> +
> + wcd-playback-dai-link {
> + link-name = "WCD Playback";
> +
> + cpu {
> + sound-dai = <&q6apmbedai RX_CODEC_DMA_RX_0>;
> + };
> +
> + codec {
> + sound-dai = <&wcd939x 0>,
> + <&swr1 0>,
> + <&lpass_rxmacro 0>;
> + };
'co'dec < 'cp'u
[...]
> + wcd939x: audio-codec {
'a'udio-codec should be way higher
[...]
> + thermal-zones {
> + cpu2-top-thermal {
> + trips {
> + cpu2_active: cpu2-active {
> + temperature = <38000>;
> + hysteresis = <2000>;
> + type = "active";
This is shaky.. let's perhaps reference each thermal zone that you want
to extend with a label.. Or maybe a pair of labels for trips/cooling-maps
per zone?
[...]
> +&pcieport1 {
> + pinctrl-0 = <&upd720201_active>;
Is this a regulator?
> + pinctrl-names = "default";
> +
> + /* Renesas μPD720201 PCIe USB3.0 HOST CONTROLLER */
DON'T SCREAM! :P
> + usb-controller@0 {
> + compatible = "pci1912,0014";
> + reg = <0x1 0x0 0x0 0x0 0x0>;
> +
> + pinctrl-0 = <&gamepad_pwr_en>;
> + pinctrl-names = "default";
Is there a hub connected to it? Or does it go directly to the
aforementioned (game) controller?
[...]
> +&pm8550_pwm {
> + status = "okay";
> +
> + multi-led {
> + color = ;
> + function = LED_FUNCTION_STATUS;
> +
> + #address-cells = <1>;
> +
Re: [PATCH 3/3] arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console
On 1/22/26 9:38 AM, Neil Armstrong wrote:
> On 1/22/26 02:30, Dmitry Baryshkov wrote:
>> On Wed, Jan 21, 2026 at 05:40:28PM +0100, Neil Armstrong wrote:
>>> From: KancyJoe
>>>
>>> Add initial Device Tree for the Ayaneo Pocket S2 gaming console based
>>> on the Qualcomm Snapdragon 8 Gen 3 platform.
>>>
>>> The design is similar to a phone wihout the modem, the game control
>>> is handled via a standalone controller connected to a PCIe USB
>>> controller.
>>>
>>> Display support will be added in a second time.
>>>
>>> Signed-off-by: KancyJoe
>>> Signed-off-by: Neil Armstrong
>>> ---
>>> arch/arm64/boot/dts/qcom/Makefile | 1 +
>>> .../boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts | 1445
>>>
>>> arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +-
>>> drivers/gpu/drm/msm/dsi/dsi.c | 4 +-
>>> 4 files changed, 1449 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/Makefile
>>> b/arch/arm64/boot/dts/qcom/Makefile
>>> index 6f34d5ed331c..1ba29755e5ba 100644
>>> --- a/arch/arm64/boot/dts/qcom/Makefile
>>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>>> @@ -313,6 +313,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8550-mtp.dtb
>>> dtb-$(CONFIG_ARCH_QCOM) += sm8550-qrd.dtb
>>> dtb-$(CONFIG_ARCH_QCOM) += sm8550-samsung-q5q.dtb
>>> dtb-$(CONFIG_ARCH_QCOM) += sm8550-sony-xperia-yodo-pdx234.dtb
>>> +dtb-$(CONFIG_ARCH_QCOM) += sm8650-ayaneo-pocket-s2.dtb
>>> sm8650-hdk-display-card-dtbs := sm8650-hdk.dtb
>>> sm8650-hdk-display-card.dtbo
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
>>> b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
>>> new file mode 100644
>>> index ..141d92933957
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
>>> +
>>> +&i2c3 {
>>
>> clock-frequency?
>
> We never did so far we we didn't need more than 100KHz
Let's at least make it explicit then
If you have the original vendor firwmare, you can read back some
registers to know what they're set to
Konrad
Re: [PATCH 3/3] arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console
On 1/22/26 02:30, Dmitry Baryshkov wrote:
On Wed, Jan 21, 2026 at 05:40:28PM +0100, Neil Armstrong wrote:
From: KancyJoe
Add initial Device Tree for the Ayaneo Pocket S2 gaming console based
on the Qualcomm Snapdragon 8 Gen 3 platform.
The design is similar to a phone wihout the modem, the game control
is handled via a standalone controller connected to a PCIe USB
controller.
Display support will be added in a second time.
Signed-off-by: KancyJoe
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/Makefile |1 +
.../boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts | 1445
arch/arm64/boot/dts/qcom/sm8650.dtsi |2 +-
drivers/gpu/drm/msm/dsi/dsi.c |4 +-
4 files changed, 1449 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 6f34d5ed331c..1ba29755e5ba 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -313,6 +313,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8550-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-samsung-q5q.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8550-sony-xperia-yodo-pdx234.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sm8650-ayaneo-pocket-s2.dtb
sm8650-hdk-display-card-dtbs := sm8650-hdk.dtb sm8650-hdk-display-card.dtbo
diff --git a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
new file mode 100644
index ..141d92933957
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
+
+&i2c3 {
clock-frequency?
We never did so far we we didn't need more than 100KHz
+ status = "okay";
+
+ wcd_usbss: typec-mux@e {
+ compatible = "qcom,wcd9395-usbss", "qcom,wcd9390-usbss";
+ reg = <0xe>;
+
+ vdd-supply = <&vreg_l15b_1p8>;
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_HIGH>;
+
+ mode-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ wcd_usbss_sbu_mux: endpoint {
+ remote-endpoint = <&pmic_glink_sbu>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ wcd_usbss_headset_out: endpoint {
+ remote-endpoint =
<&wcd_codec_headset_in>;
+ };
+ };
+ };
+ };
+};
+
+&i2c6 {
clock-frequency?
+ status = "okay";
+
+ typec-mux@1c {
+ compatible = "onnn,nb7vpq904m";
+ reg = <0x1c>;
+
+ vcc-supply = <&vreg_l15b_1p8>;
+
+ retimer-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ redriver_ss_out: endpoint {
+ remote-endpoint = <&pmic_glink_ss_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ redriver_ss_in: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_out>;
+ };
+ };
+ };
+ };
+};
+
+&iris {
+ status = "okay";
With the default firmware?
Yes
+&remoteproc_adsp {
+ firmware-name = "qcom/sm8650/ayaneo/ps2/adsp.mbn",
+ "qcom/sm8650/ayaneo/ps2/adsp_dtb.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm8650/ayaneo/ps2/cdsp.mbn",
+ "qcom/sm8650/ayaneo/ps2/cdsp_dtb.mbn";
Is it fused?
No but as Kancy reported, it's usual vendord provides their own
version with battery & features tuning.
+
+ status = "okay";
+};
+
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi
b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 07ae74851621..fcd5a1a45803 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -3917,7 +3917,7 @@ opp-3200-4 {
};
};
- pcie@0 {
+ pcieport1: pcie@0 {
device_type = "pci";
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index d8bb40ef820e
Re: [PATCH 3/3] arm64: dts: qcom: add basic devicetree for Ayaneo Pocket S2 gaming console
On Wed, Jan 21, 2026 at 05:40:28PM +0100, Neil Armstrong wrote:
> From: KancyJoe
>
> Add initial Device Tree for the Ayaneo Pocket S2 gaming console based
> on the Qualcomm Snapdragon 8 Gen 3 platform.
>
> The design is similar to a phone wihout the modem, the game control
> is handled via a standalone controller connected to a PCIe USB
> controller.
>
> Display support will be added in a second time.
>
> Signed-off-by: KancyJoe
> Signed-off-by: Neil Armstrong
> ---
> arch/arm64/boot/dts/qcom/Makefile |1 +
> .../boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts | 1445
>
> arch/arm64/boot/dts/qcom/sm8650.dtsi |2 +-
> drivers/gpu/drm/msm/dsi/dsi.c |4 +-
> 4 files changed, 1449 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile
> b/arch/arm64/boot/dts/qcom/Makefile
> index 6f34d5ed331c..1ba29755e5ba 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -313,6 +313,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8550-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm8550-qrd.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm8550-samsung-q5q.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm8550-sony-xperia-yodo-pdx234.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += sm8650-ayaneo-pocket-s2.dtb
>
> sm8650-hdk-display-card-dtbs := sm8650-hdk.dtb sm8650-hdk-display-card.dtbo
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
> b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
> new file mode 100644
> index ..141d92933957
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sm8650-ayaneo-pocket-s2.dts
> +
> +&i2c3 {
clock-frequency?
> + status = "okay";
> +
> + wcd_usbss: typec-mux@e {
> + compatible = "qcom,wcd9395-usbss", "qcom,wcd9390-usbss";
> + reg = <0xe>;
> +
> + vdd-supply = <&vreg_l15b_1p8>;
> + reset-gpios = <&tlmm 152 GPIO_ACTIVE_HIGH>;
> +
> + mode-switch;
> + orientation-switch;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + wcd_usbss_sbu_mux: endpoint {
> + remote-endpoint = <&pmic_glink_sbu>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + wcd_usbss_headset_out: endpoint {
> + remote-endpoint =
> <&wcd_codec_headset_in>;
> + };
> + };
> + };
> + };
> +};
> +
> +&i2c6 {
clock-frequency?
> + status = "okay";
> +
> + typec-mux@1c {
> + compatible = "onnn,nb7vpq904m";
> + reg = <0x1c>;
> +
> + vcc-supply = <&vreg_l15b_1p8>;
> +
> + retimer-switch;
> + orientation-switch;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + redriver_ss_out: endpoint {
> + remote-endpoint = <&pmic_glink_ss_in>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + redriver_ss_in: endpoint {
> + remote-endpoint = <&usb_dp_qmpphy_out>;
> + };
> + };
> + };
> + };
> +};
> +
> +&iris {
> + status = "okay";
With the default firmware?
> +&remoteproc_adsp {
> + firmware-name = "qcom/sm8650/ayaneo/ps2/adsp.mbn",
> + "qcom/sm8650/ayaneo/ps2/adsp_dtb.mbn";
> +
> + status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> + firmware-name = "qcom/sm8650/ayaneo/ps2/cdsp.mbn",
> + "qcom/sm8650/ayaneo/ps2/cdsp_dtb.mbn";
Is it fused?
> +
> + status = "okay";
> +};
> +
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index 07ae74851621..fcd5a1a45803 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> @@ -3917,7 +3917,7 @@ opp-3200-4 {
> };
> };
>
> - pcie@0 {
> + pcieport1: pcie@0 {
> device_type = "pci";
> reg = <0x0 0x0 0x0 0x0 0x0>;
> bus-range = <0x01 0xff>;
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
> index d8bb40ef820e..0781dce7cda2 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.c
> +++
