From: Jianfeng Liu <liujianfeng1994@gmail.com>
To: kaipeng94@gmail.com
Cc: andersson@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, konradybcio@kernel.org,
krzk+dt@kernel.org, linux-arm-msm@vger.kernel.org,
robh@kernel.org
Subject: Re: [PATCH v4 0/2] Add device tree for Acer Swift Go Pro AI (SFA14-11)
Date: Thu, 8 Oct 2026 18:34:11 +0800 [thread overview]
Message-ID: <20261008103414.6170-1-liujianfeng1994@gmail.com> (raw)
In-Reply-To: <20261006085425.40450-1-kaipeng94@gmail.com>
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/20260929103053.10241-1-liujianfeng1994@gmail.com/
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
prev parent reply other threads:[~2026-10-08 10:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 8:54 [PATCH v4 0/2] Add device tree for Acer Swift Go Pro AI (SFA14-11) Kaipeng Zeng
2026-10-06 8:54 ` [PATCH v4 1/2] dt-bindings: arm: qcom: Add " Kaipeng Zeng
2026-10-06 8:54 ` [PATCH v4 2/2] arm64: dts: qcom: Add support for " Kaipeng Zeng
2026-10-06 9:07 ` sashiko-bot
2026-10-08 10:34 ` Jianfeng Liu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261008103414.6170-1-liujianfeng1994@gmail.com \
--to=liujianfeng1994@gmail.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kaipeng94@gmail.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox