Add device tree for Acer Swift Go Pro AI (SFA14-11)
v5 cover 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 (next-20261021: 9a482184) / Ubuntu 26.04 LTS.
Tested and working devices:
- NVMe
- Keyboard & Touchpad
- USB Type-A, Type-C
- Battery & charging status
- Internal display & Backlight brightness control
- HDMI & Type-C display (with audio)
- Bluetooth & Wi-Fi
- Webcam (usb_2)
- GPU
- Audio: speaker (partial), mic, headphone.
Known issues:
- Four internal speakers are detected, but only three work. I use Ratizux's tplg [3] and alsa configuration [4] on my desktop. I also use amixer & speaker-test to verify them.
- EL2-mode:
- EL2-mode can only work with kernel parameter: "iommu.passthrough=1".
- Audio and Battery status are broken under EL2 mode.
- Bluetooth is broken under EL2 mode.
Also, some notes about eusb*_repeater and EC; hopefully, this can help others understand why I configured these nodes this way:
- eusb*_repeater conflict between the DSDT and my testing:
By using i2ctransfer to sequentially set the modes of 'eusb3/5/6_repeater', I can observe the corresponding connection or disconnection state changes for the right-side USB-A port ('usb_mp_hsphy0'), the left-side USB-A port ('usb_mp_hsphy1'), and the webcam ('usb_2'). Using gpioset, it can be verified that 'eusb6_repeater' is affected by tlmm's GPIO 184, while setting GPIO 6/7 has no effect. And webcam can be shut down and reset by toggling GPIO 184. The DSDT places GPIO 6/184 as a 'ResourceTemplate' under 'USB3'(usb_mp), GPIO 7 under USB4(usb_2), and webcam is under USB4. This conflicts with my testing. So, I didn't add the unverified GPIO, and the connection between USB and repeater follows my testing rather than DSDT.
- There is an EC device under i2c5 at address 0x76, with driver probe failed. But using i2ctransfer I can observe some data changes related to fan. The EC driver appears to require additional work, and it couldn't be included in this patch. So, I didn't add that node.
[1] https://git.launchpad.net/~ubuntu-concept/ubuntu/+source/linux/+git/resolute
[2] https://github.com/Ratizux/linux-device-acer-sfa14-11.git
[3] https://github.com/Ratizux/audioreach-topology/
[4] https://github.com/Ratizux/alsa-ucm-conf
---
Changelog:
V5:
- Rebase to next-20261021, pick up the following upstream changes:
arm64: dts: qcom: x1-crd: Mark the EC reset gpio as reserved (099cd579).
arm64: dts: qcom: hamoa/purwa: Add QREF regulator supplies (d9d07e23).
arm64: dts: qcom: hamoa: Fix swapped USB QMP PHY vdda-phy/vdda-pll supplies (4458dcd3).
- Add 'eusb*_repeater'. (Jianfeng Liu)
- Add 'displayport-2-dai-link'. (Jianfeng Liu)
- Remove 'usb_1_ss1' and 'mdss_dp1'. (Jianfeng Liu)
- Remove unused 'audio-routing'. (Jianfeng Liu)
- Remove 'kypd_vol_up_n'. (Jianfeng Liu)
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)
- Link to V4: https://lore.kernel.org/linux-devicetree/[email protected]/
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)
- Link to V3: https://lore.kernel.org/linux-devicetree/[email protected]/
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 V2: https://lore.kernel.org/linux-devicetree/[email protected]/
- 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 | 1541 +++++++++++++++++ 3 files changed, 1544 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/x1e78100-acer-sfa14-11.dts
base-commit: 9a482184d910775cf648863148944945b74e2815
Signature · 1 line
2.53.0
PATCH v5 1/2 dt-bindings: arm: qcom: Add Acer Swift Go Pro AI (SFA14-11)
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(+)
Documentation/devicetree/bindings/arm/qcom.yaml +1 -0
@@ -1240,6 +1240,7 @@ properties: - items: - enum: + - acer,swift-go-sfa14-11 - medion,sprchrgd14s1 - tuxedo,elite14gen1 - const: qcom,x1e78100
Signature · 1 line
2.53.0
PATCH v5 2/2 arm64: dts: qcom: Add support for Acer Swift Go Pro AI (SFA14-11)
In reply to Kaipeng ZengIntroduce 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
- Audio
--- arch/arm64/boot/dts/qcom/Makefile | 2 + .../boot/dts/qcom/x1e78100-acer-sfa14-11.dts | 1541 +++++++++++++++++ 2 files changed, 1543 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/x1e78100-acer-sfa14-11.dts
arch/arm64/boot/dts/qcom/Makefile +2 -0
@@ -473,6 +473,8 @@ talos-evk-rpi-display-2-5in-dtbs := \ dtb-$(CONFIG_ARCH_QCOM) += talos-evk-rpi-display-2-5in.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
arch/arm64/boot/dts/qcom/x1e78100-acer-sfa14-11.dts new file +1541 -0
1,541 lines not on this page · raw message
Signature · 1 line
2.53.0
[email protected]
AI reviewRe: [PATCH v5 2/2] arm64: dts: qcom: Add support for Acer Swift Go Pro AI (SFA14-11)
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] arm64: dts: qcom: x1e78100-acer-sfa14-11: inverted backlight turns full on at 0 --
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] arm64: dts: qcom: x1e78100-acer-sfa14-11: inverted backlight turns full on at 0 --
commit 66fa11a1de0967d5bc8b8fce1f271477c9fa4b31
Author: Kaipeng Zeng <[email protected]>
arm64: dts: qcom: Add support for Acer Swift Go Pro AI (SFA14-11)
This commit adds the device tree for the Acer Swift Go Pro AI (SFA14-11) laptop based on the Qualcomm Snapdragon X Elite (X1E78100) SoC.
Quoted 6 lines
arch/arm64/boot/dts/qcom/x1e78100-acer-sfa14-11.dts new file +0
-0@@ -0,0 +1,1541 @@
[ ... ]
Quoted 10 lines
arch/arm64/boot/dts/qcom/x1e78100-acer-sfa14-11.dts new file +10
-0+ backlight: backlight { + compatible = "pwm-backlight"; + + pwms = <&pm8550_pwm 3 5000000>; + + brightness-levels = <254 225 200 175 150 125 100 75 65 60 55>; + default-brightness-level = <8>; + + power-supply = <&vreg_edp_bl>; + };
[ ... ]
arch/arm64/boot/dts/qcom/x1e78100-acer-sfa14-11.dts line 323
Quoted 10 lines
arch/arm64/boot/dts/qcom/x1e78100-acer-sfa14-11.dts new file +10
-0+ vreg_edp_bl: regulator-edp-bl { + compatible = "regulator-fixed"; + + regulator-name = "VBL9"; + regulator-min-microvolt = <3600000>; + regulator-max-microvolt = <3600000>; + + regulator-always-on; + regulator-boot-on; + };
[Severity: Medium]
Does setting the backlight brightness to 0, blanking the display, or suspending the system cause this active-low backlight to jump to full brightness instead of turning off?
The backlight node uses descending brightness-levels from 254 (off) down to 55 (maximum brightness) without PWM_POLARITY_INVERTED, has no enable-gpios, and points power-supply at vreg_edp_bl, which has no GPIO and is marked regulator-always-on.
In drivers/video/backlight/pwm_bl.c, pwm_backlight_update_status() only consults pb->levels[brightness] via compute_duty_cycle() when brightness > 0. When brightness is 0, it ignores pb->levels[0] and instead disables the regulator and sets duty_cycle = 0:
drivers/video/backlight/pwm_bl.c:pwm_backlight_update_status() {
if (brightness > 0) {
pwm_get_state(pb->pwm, &state);
state.duty_cycle = compute_duty_cycle(pb, brightness, &state);
state.enabled = true;
pwm_apply_might_sleep(pb->pwm, &state);
pwm_backlight_power_on(pb);
} else {
pwm_backlight_power_off(pb);
pwm_get_state(pb->pwm, &state);
state.duty_cycle = 0;
state.enabled = !pb->power_supply && !pb->enable_gpio;
pwm_apply_might_sleep(pb->pwm, &state);
}
}Because vreg_edp_bl is a GPIO-less fixed regulator with regulator-always-on, regulator_disable() in pwm_backlight_power_off() does not cut power to the backlight, while lpg_pwm_apply() in drivers/leds/rgb/leds-qcom-lpg.c disables the PWM output channel and drives it to a constant logical 0 (0% duty cycle), which corresponds to full brightness on an active-low backlight.
In addition, having descending values in brightness-levels causes unsigned integer wraparound in pwm_backlight_is_linear():
drivers/video/backlight/pwm_bl.c:pwm_backlight_is_linear() {
unsigned int nlevels = data->max_brightness + 1;
unsigned int min_val = data->levels[0];
unsigned int max_val = data->levels[nlevels - 1];
unsigned int slope = (128 * (max_val - min_val)) / nlevels;
unsigned int margin = (max_val - min_val) / 20; /* 5% */
...
}With min_val = 254 and max_val = 55, max_val - min_val wraps around in unsigned arithmetic, inflating margin and misreporting the non-linear table as BACKLIGHT_SCALE_LINEAR.
Note that pm8550_pwm in hamoa-pmics.dtsi uses #pwm-cells = <2>, which does not accept a third PWM_POLARITY_INVERTED flag cell unless #pwm-cells is overridden to <3> or the driver/DT handling is adjusted.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
Hi Kaipeng,
Thanks for v5 and for the detailed notes on the eUSB repeaters and the EC — those are very useful.
Two points from my side.
On the naming: I'm fine with the model string carrying the retail name, i.e.
model = "Acer Swift Go Pro AI (SFA14-11)";
For the compatible, though, I think we should choose a name that can be found on the hardware or in the firmware itself, and "acer,swift-sfa14-11" does that: it matches the DMI product name (SFA14-11) combined with the family name Acer itself uses on its support site ("Swift SFA14-11"). The archived retail page lists the Chinese product name, but it doesn't show the device configuration or images, and in practice users identify their machine by the name Windows shows (which comes from the DMI) or through Acer's support site. So my suggestion is: model = "Acer Swift Go Pro AI (SFA14-11)", compatible = "acer,swift-sfa14-11". Note this is also the string quoted earlier in this thread, while v5 uses "acer,swift-go-sfa14-11" in both the binding and the DTS — could we align on one?
Second, please add the machine to the QSEECOM allowlist (qcom_scm_qseecom_allowlist) as a separate "firmware: qcom: scm" patch. This device's firmware does not accept keyboard input, so the EFI boot order cannot be configured from the setup UI: without QSEECOM/efivars, the only way to boot Linux is to press F12 and select the entry on every boot. With the allowlist entry, efibootmgr can make Linux the default boot entry. This is the same kind of change other boards carry, e.g. the recent addition by Srinivas [1]. My series has it as a third patch; I'm happy to have it folded into whichever series moves forward.
[1] https://lore.kernel.org/all/[email protected]/
Best regards,
Jianfeng