Add device tree for Acer Swift Go Pro AI (SFA14-11)

The work started with x1-crd.dtsi as initial template. HDMI refers to ThinkPad T14s.
Bluetooth refers to x1-crd.dtsi from the ubuntu-concept kernel [1]. PWM brightness control refers to Ratizux's GitHub repository [2].

Tested on linux-next / Ubuntu 26.04 LTS.

Tested and working devices:

- NVMe
- Keyboard & Touchpad
- USB Type-A, Type-C
- Battery & charging status (broken under EL2 mode)
- Internal display & Backlight brightness control
- HDMI & Type-C display
- Bluetooth & Wi-Fi
- Webcam (usb_2)
- GPU

[1] https://git.launchpad.net/~ubuntu-concept/ubuntu/+source/linux/+git/resolute
[2] https://github.com/Ratizux/linux-device-acer-sfa14-11.git

---
Changelog:
V4:
- Add -el2-dtbs. (Sashiko)
- The "audio-routing" of "sound" is from x1-crd.dtsi, audio doesn't totally work, and I didn't see any improvements when I followed Sashiko's advice, so I just kept it the same as x1-crd.dtsi. (Sashiko)
- Tested in EL2 mode:
Successfully boots with the kernel parameter: "iommu.passthrough=1", The above features work as in EL1 mode except battery status.
- Fix missing newline before "wsa-dai-link". (Val Packett)

V3:
- Re-sort *-link and its sub-nodes. (Konrad Dybcio)
- Keep a '\n' before 'status'. (Konrad Dybcio)
- Remove 'output-low' from wcd_default. (Konrad Dybcio)

V2:
- Fix Makefile entry ordering. (Krzysztof Kozlowski)
- Use readable compatible string. (Krzysztof Kozlowski)
- Fix sound card model name for this device. (Krzysztof Kozlowski & Konrad Dybcio)
- Re-sort nodes, pinctrl-*. (Krzysztof Kozlowski & Konrad Dybcio)
- Remove those regulators without consumer and lack of a required value in DSDT. (Konrad Dybcio)
- Remove ADSP/CDSP fastrpc memory. (Konrad Dybcio)
- Add iris firmware path. (Konrad Dybcio)
- Delete usb_1_ss1_qmpphy/usb_1_ss2_qmpphy properties of Type-C. (Sashiko)
- Delete usb_1_ss2_hsphy. (Sashiko)
- Remove unused pmic-glink orientation-gpio. (Sashiko)
- Remove node related to WWAN.

- The Webcam is a USB device, can be probed without any additional node. (Sashiko)
- Using reset-gpios in swr* seems common in X1E devices, like Lenovo Yoga Slim7x, ThinkPad t14s and Microsoft Romulus. Because speakers do not completely work and I could not see any effect of changing it, just retain it. (Sashiko)
- Also, the HDMI audio is the same reason as above. (Sashiko)

- Link to V1: https://lore.kernel.org/linux-devicetree/[email protected]/

Kaipeng Zeng (2):
dt-bindings: arm: qcom: Add Acer Swift Go Pro AI (SFA14-11)
arm64: dts: qcom: Add support for Acer Swift Go Pro AI (SFA14-11)

 .../devicetree/bindings/arm/qcom.yaml         |    1 +
 arch/arm64/boot/dts/qcom/Makefile             |    2 +
 .../boot/dts/qcom/x1e78100-acer-sfa14-11.dts  | 1484 +++++++++++++++++
 3 files changed, 1487 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/x1e78100-acer-sfa14-11.dts

base-commit: 0d33d21e47d9dc66f91e44da3fc9220c74d93df7

2.53.0

Add Acer Swift Go Pro AI (SFA14-11), a laptop based on the Snapdragon X Elite (X1E78100) SoC.

---
 Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
 1 file changed, 1 insertion(+)

index c7c9a9279684..da653b787d4d 100644
@@ -1180,6 +1180,7 @@ properties:
 
       - items:
           - enum:
+              - acer,swift-go-sfa14-11
               - medion,sprchrgd14s1
               - tuxedo,elite14gen1
           - const: qcom,x1e78100

2.53.0

Introduce device tree for the Acer Swift Go Pro AI (SFA14-11). It is a laptop based on the Qualcomm Snapdragon X Elite (X1E78100) SoC. This device tree implementation references nodes from the x1-crd.dtsi.

Supported features:

- Internal display & Brightness control
- Keyboard & Touchpad
- USB Type-C, Type-A
- Wi-Fi & Bluetooth
- ADSP & CDSP
- Adreno X1-85 GPU
- HDMI & USB Type-C display
- Webcam

---
 arch/arm64/boot/dts/qcom/Makefile             |    2 +
 .../boot/dts/qcom/x1e78100-acer-sfa14-11.dts  | 1484 +++++++++++++++++
 2 files changed, 1486 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/x1e78100-acer-sfa14-11.dts

index e05414290d8e..d20d65a99c63 100644
@@ -422,6 +422,8 @@ talos-evk-lvds-auo,g133han01-dtbs	:= \
 dtb-$(CONFIG_ARCH_QCOM)	+= talos-evk-lvds-auo,g133han01.dtb
 x1e001de-devkit-el2-dtbs	:= x1e001de-devkit.dtb x1-el2.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e001de-devkit.dtb x1e001de-devkit-el2.dtb
+x1e78100-acer-sfa14-11-el2-dtbs	:= x1e78100-acer-sfa14-11.dtb x1-el2.dtbo
+dtb-$(CONFIG_ARCH_QCOM)	+= x1e78100-acer-sfa14-11.dtb x1e78100-acer-sfa14-11-el2.dtb
 x1e78100-lenovo-thinkpad-t14s-el2-dtbs	:= x1e78100-lenovo-thinkpad-t14s.dtb x1-el2.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= x1e78100-lenovo-thinkpad-t14s.dtb x1e78100-lenovo-thinkpad-t14s-el2.dtb
 x1e78100-lenovo-thinkpad-t14s-oled-el2-dtbs	:= x1e78100-lenovo-thinkpad-t14s-oled.dtb x1-el2.dtbo

2.53.0

Hi Kaipeng,

Thanks for working on this device! I have also been working on a device tree for the same laptop; my series is currently on the list:

https://lore.kernel.org/linux-arm-msm/[email protected]/

Since we are both targeting the same hardware, I think it makes sense to consolidate the two efforts into a single series, as is the usual practice. Below is a summary of what I found while comparing our versions, hoping this helps us converge.

A few things I noticed in your v4:

The vdda-phy/vdda-pll supplies appear to be swapped on all four QMP PHYs (usb_1_ss0_qmpphy, usb_1_ss2_qmpphy, usb_mp_qmpphy0/1). The QMP PHY expects vdda-phy at ~0.88 V and vdda-pll at 1.2 V. The same issue was fixed recently on the Purwa boards in commit 7c1d0ef2969e1 ("arm64: dts: qcom:
purwa: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies"), which includes the reference mapping used by the other X1E boards.

The &tcsr QREF supplies are missing. The qcom,x1e80100-tcsr binding now requires the vdda-qref*/vdda-refgen* supplies, so DTBS_CHECK reports 18 warnings without them. All other Hamoa boards have been updated with this block.

The series is missing the QSEECOM allowlist entry for this machine (firmware: qcom: scm: Allow QSEECOM on ...), which is needed for uefisecapp / efivars access. I'm carrying that as a separate patch in my series.

The three PTN3222 eUSB2 repeaters on i2c5 (addresses 0x47/0x4b/0x4f) are not described. They are present on this board and feed usb_2 (webcam) and the usb_mp ports.

The displayport-2 DAI link is missing, so audio over the HDMI bridge doesn't work. My version also sets sound-name-prefix on mdss_dp0/mdss_dp2, which is needed for the DP audio links.

Two nodes look like they may have been carried over from x1-crd.dtsi without being verified on this laptop — could you double-check them?

- key-vol-up: as far as I can tell this laptop has no physical volume key (volume is an Fn combo on the keyboard).

- dmic23 / "VA DMIC2/3" routing: the mic array appears to be a dual-mic setup beside the camera — tap-testing around the chassis only shows mic response near the camera.

On the naming: upstream asked me to change my compatible to "acer,swift-sfa14-11" (my v1 used "acer,sfa14-11", following the DMI product name). Acer's support site calls the machine "Swift SFA14-11", and I couldn't find "Swift Go Pro AI" as an official product line anywhere. Since our series use different compatible strings, file names and models, we'll need to align on one either way — I'm happy to go with whatever the maintainers prefer.
One question: you enable usb_1_ss1 with its QMP PHY in USB3-only mode (DP input port deleted). Could you share what it is wired to on this machine? The only USB-C port is on usb_1_ss0 and the HDMI bridge is fed from usb_1_ss2_qmpphy, so I wasn't sure what ss1 connects to.

By the way, your EL2-mode testing is a valuable data point — I haven't tested that configuration. On my side the following is verified working on hardware: eDP display with PWM backlight, I2C keyboard and touchpad, USB-A ports, USB-C with DP alt mode (video + audio), HDMI video + audio, speakers and headphone jack, WiFi and Bluetooth (UART), webcam, NVMe, GPU and battery charging.

Happy to integrate any findings from your testing into my series, or to review and help with yours if you prefer to carry it forward — whichever way the maintainers would like to handle it.

Best regards,
Jianfeng

Hi Jianfeng,
Thanks for your review!

These are some updates in x1-crd.dtsi.
Since my first submission was earlier, and my work is based on x1-crd.dtsi, I didn't
rebase to newest Linux-next this version, because I am not sure if it's necessary.
Thank you for pointing out the differences.
I would rebase to the newest Linux-next in the future version.

I actually missed describing these repeaters.
When I started porting x1-crd.dtsi to SFA14-11, I encountered hangs or a black screen
during boot when some no-exist I2C device nodes were enabled, I remove them as possible.
In my testing, USB devices work well, without issue in this case. Maybe they are initialized by UEFI, and kept during Linux kernel boot? So, I missed describing these i2c devices.

After you point out, I found these i2c devices can be detected by i2cdetect. I would describe in the next version.

BTW, could you let me know, how can you know which usb devices use which repeater?
It would be very appreciated!

Currently, the audio of my dts can only work partially. I suspect there is something wrong in my ALSA configuration, and adding sound-name-prefix
can improve nothing in my case.
I still need time to try to solve this problem (also dmic23 / "VA DMIC2/3" routing problem
you point out).
I notice you list that your audio totally works, if your alsa-ucm-config is your customized or
just using X1E80100-CRD.conf?

I think this should be removed. I would remove it in the next version.

Acer had a page about "Acer Swift Go Pro AI" but it was deleted, fortunately here is
a snapshot:
https://web.archive.org/web/20260314171131/https://www.acer.com.cn/product_list.html?parentid=323
It's sold in China using the name "Acer 非凡 Go Pro AI". There is some discussion in the thread of my previous version:
https://lore.kernel.org/linux-devicetree/[email protected]/
I have no idea if your "swift SFA14-11" is the same as my "Acer swift Go Pro AI".

It may be an unused USB root hub device, can be found via lsusb or sysfs. I didn't verify if there is any device wired to it before.
I verified after you point out this, and I couldn't find any device is wired to it.
All USB devices I tested still worked when I disabled it.
If so, I think it could be removed.
But, I can't confirm if this USB device would be used by SoC internal.

Seems that your Makefile have the el2 as well, but you didn't test it under EL2-mode?
Please check my changelog, it includes my testing status and parameters of kernel.
I am not sure if you would run into the same problem, hope it can help you.

You have pointed out a lot details, which is very helpful for my work. Thanks very much!
I will fix the above issue and continue to send the next version. Your review would be very appreciated!

Hi Kaipeng,

Thanks for the detailed reply!

On the naming: you're right, and thanks for the pointer — the SFA14-11 series was indeed marketed in China as 宏碁非凡 Go Pro AI (my unit is an SFA14-11-QWU1; the retail listings I found, e.g. on Suning, are other SKUs like the SFA14-11-QGU1). One thing I noticed though: that retail page
has since been taken down, and Acer's support sites — global and China
alike [2] — identify the machine as plain "SFA14-11" within the Swift/非凡 series, matching the DMI and the model string shown in Windows. So it looks like "Swift SFA14-11" is the stable, support-level identity, while "Go Pro AI" was the transient retail name.

In my series the maintainers asked me to use "acer,swift-sfa14-11"; Ubuntu's stubble has also independently settled on that exact string as the hwid for this machine [1], so that is the string my series will keep unless the maintainers reconsider after seeing your evidence — happy to align either way.

I'm using the UCM configuration for this machine from Ratizux's downstream alsa-ucm-conf tree [3] (small world — your brightness work is based on their kernel repo [4]). Upstream alsa-ucm-conf doesn't have a profile for this machine yet, so if your Ubuntu 26.04 doesn't carry one either, that's likely a good part of your audio issues, on top of the missing displayport-2 DAI link. It would be nice to coordinate with Ratizux and get the profile submitted upstream.

On the dmic23 question: the array on my machine is a dual-mic setup next to the camera — I verified by tap-testing around the chassis (only the camera area shows mic response), and the VA capture device exposes 2 channels. The other X1E laptops in tree (T14s, Vivobook, EliteBook, ...) all use dmic01 only; dmic23 is only wired on the CRD, which made me suspect it was carried over from the template.

The repeater mapping mostly comes from the ThinkPad T14s device tree, which is the same reference design — it gives the i2c addresses, reset GPIOs and which hsphy each repeater feeds (0x43/0x47/0x4f on i2c5 with tlmm 7/6/184). On my board i2cdetect shows the repeaters at 0x47/0x4b/0x4f (the camera's repeater sits at 0x4b rather than T14s's 0x43), so I kept the T14s mapping with that one address adjusted, and verified functionally: webcam on usb_2, USB-A ports on usb_mp. Your UEFI hypothesis sounds right by the way — since Linux never touches the reset GPIOs when the nodes are absent, chips initialized by UEFI keep working; describing them is still the correct thing to do since it makes the boot-to-boot behaviour deterministic.

Thanks for checking! On this board the internal devices (webcam, the fingerprint hub) hang off usb_2 and usb_mp, so with nothing answering on ss1 I agree it can be dropped.

Since you're planning to send the next version, I'll keep my series updated in parallel and will of course review yours — I'll leave it to Bjorn and Konrad to pick whichever they prefer. Thanks also for the EL2 notes; I haven't tested that configuration yet and will give it a try with iommu.passthrough=1.

Best regards,
Jianfeng

[1] https://github.com/ubuntu/stubble/blob/main/hwids/json/x1e78100-acer-sfa14-11.json
[2] https://www.acer.com.cn/support.html?type=1
[3] https://github.com/Ratizux/alsa-ucm-conf
[4] https://github.com/Ratizux/linux-device-acer-sfa14-11.git

Hi,

I think we are about confusing the product name and the model name here?
It is clear that the product name is Acer Swift (aka '非凡' in Chinese) Go Pro AI; the link to Ubuntu stubble you provided also reveals this somehow.

Also, IMHO, I think we can't use 'stable' to describe this situation. As soon as the product is produced, it was given a product/model name; unless Acer renames it, this is it. The vendor can also remove the support page that you referred to sometime in the future, just like they removed the product page; this isn't rare; I think we always shouldn't depend on it.

As Kaipeng mentioned, there were more discussions about naming in the threads of his v1 and v2 to this mailing list in July, if you are interested.

Hi,

I agree the product name / model name distinction is the right frame. It turns out we can settle the product name fairly directly, though: if I look my machine up on Acer's support site by its SNID, it resolves to "Swift SFA14-11" in every region I tried — Japan, US, Australia, UK — and on the China support site as well. So within Acer's support database the product name is uniformly "Swift SFA14-11", and "非凡 Go Pro AI" was only the retail marketing name used on the Chinese storefront, whose page has since been taken down. It is not even a China-vs-global split — the support identification is the same everywhere.

I fully agree that web pages are not a sound basis — so I'm happy to drop page-based arguments altogether. That leaves the two sources that cannot be taken down: the DMI tables provided by the firmware (Product Name:
SFA14-11, which is also what Windows displays as the model) and the SNID label physically on the machine (SFA14-11-QWU1 on my unit). Both are model-name only.

I think the resolution follows from the product/model split itself: the model property is human-readable free text, and per the conventions in tree (e.g. "Dell XPS 13 9345", "Lenovo ThinkPad T14s Gen 6") it is free to carry the marketing name — so something like "Acer Swift Go Pro AI (SFA14-11)" works fine there, and users who bought it as 非凡 Go Pro AI can recognize their machine by it. The compatible, on the other hand, is the machine identifier, and it should correspond to what the firmware reports — either the model-only "acer,sfa14-11" (my v1, following the DMI) or family
+ model "acer,swift-sfa14-11" (what the maintainers asked me to use on my series). I'd rather not embed a retail marketing name in the compatible. I'll leave the final call to the maintainers.

Best regards,
Jianfeng

This makes it sound like the retailer made up / confused some names, let's just go with what the manufacturer says

Konrad

Hi Konrad,

Thanks for your reply.

Just want to make sure I don't misunderstand anything, if this is what you preferred:

```
model = "Acer Swift Go Pro AI (SFA14-11)";
compatible = "acer,swift-sfa14-11", "qcom,x1e78100", "qcom,x1e80100";
```

Thanks.

My reading of Jianfeng's email is that the "Go Pro AI" part does not appear on the Acer sites

Konrad

Thanks for the explanation!

It does? https://web.archive.org/web/20260314171131/https://www.acer.com.cn/product_list.html?parentid=323
("非凡Go Pro AI" on this page, '非凡' is the Chinese translation of Swift)

I don't think the name (Swift SFA14-11) on the support page is the official product name; for example, you can find Acer Swift 14 AI[1] is named as Swift SF14-11 in there:
https://www.acer.com/us-en/support/product-support/SF14-11
If we are going to call 'Acer Swift Go Pro AI' as 'Swift SFA14-11', will we call 'Acer Swift 14 AI' as 'Swift SF14-11' in the future? In order to make the naming rule consistent.
Sure, we can name 'Acer Swift 14 AI' as 'Swift SF14-11' in the future; then we lose recognizability?

It is awkward that Acer only sells Swift Go Pro AI (SFA14-11) in the Chinese market; so we can only find it from the Chinese website, and we don't know what product name will be given to this machine when it is sold in the global market.

[1] https://store.acer.com/en-us/swift-14-ai-laptop-sf14-11-x128

Okay then let's go with this

Konrad