From: Joonhoe Kim <26rote@gmail.com>
To: Vladyslav Tymoshchuk <tvlad744@gmail.com>
Cc: andersson@kernel.org, konradybcio@kernel.org,
abelvesa@kernel.org, heikki.krogerus@linux.intel.com,
gregkh@linuxfoundation.org, sre@kernel.org, krzk@kernel.org,
lumag@kernel.org, casey.connolly@linaro.org, johan@kernel.org,
jishnu.prakash@oss.qualcomm.com, kamal.wadhwa@oss.qualcomm.com,
daniel@quora.org, neil.armstrong@linaro.org, kees@kernel.org,
gustavoars@kernel.org, linux-arm-msm@vger.kernel.org,
linux-usb@vger.kernel.org, linux-pm@vger.kernel.org,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/4] soc: qcom: pmic_glink: Hold back notifications over system sleep
Date: Tue, 3 Nov 2026 07:05:09 +0900 [thread overview]
Message-ID: <20261102220510.1721-1-26rote@gmail.com> (raw)
In-Reply-To: <20261022164151.592-1-tvlad744@gmail.com>
I tried the series with suspend-to-idle on a Lenovo Y700 Gen 5
(TB323FU, Kaanapali/SM8850, FSA4480 on the SBU lines). This is v7.3
with out-of-tree board support. v7.3 does not have c7c56b6ec077, and
I left the UCSI connector work on system_wq as well. So only the
series kept the workers off the suspended devices. Without it, this
setup crashed on a DP sink unplugged during suspend, as in [3] of your
cover letter.
- Monitor (pin assignment C) unplugged during suspend, default wakeup
settings: the UCSI notification woke the system within a second.
The held-back notifications were passed on right after the tasks
were thawed. The altmode worker, fsa4480_set() and the UCSI
connector work ran only then. No I2C errors, no reset.
- The same with ucsi_glink wakeup disabled: no wakeup. The
notifications waited until the power key and were passed on after
resume.
- Charger plugged in during suspend, qcom_battmgr wakeup enabled and
ucsi_glink wakeup disabled: woke up 0.3 s after the plug-in.
Two things I saw on this board, both the same without the series:
- Plug-in of a DP sink during suspend (two runs with the series and
one without, each after an unplug during suspend in the same boot):
the firmware sends an altmode notification right away and a DP one
13 s later. The UCSI connector change only comes 13 s after that,
so the system wakes up 26 s after the plug-in.
- After an unplug during suspend, the DP controller is resumed before
the held-back altmode notification is passed on. It tries to train
the link to the monitor that is gone (about 10 s of timeouts), which
delays passing on the notifications by as much. It also leaves the
DP PHY initialised. So on the next resume the USB PHY init times out
and the dwc3 resume fails with -110. The plug-in runs above ended
that way, without USB.
A plug-in during suspend after a fresh boot, without the series, does
not hit the PHY problem. It still ends without a display, for another
reason in UCSI; I'll report that separately.
Tested-by: Joonhoe Kim <26rote@gmail.com> # SM8850
Thanks,
Joonhoe Kim
prev parent reply other threads:[~2026-11-02 22:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 16:41 Vladyslav Tymoshchuk
2026-10-22 16:41 ` [RFC PATCH 1/4] " Vladyslav Tymoshchuk
2026-10-22 16:41 ` [RFC PATCH 2/4] soc: qcom: pmic_glink: Report wakeup events on behalf of clients Vladyslav Tymoshchuk
2026-10-22 16:41 ` [RFC PATCH 3/4] usb: typec: ucsi: glink: Wake up the system on connector changes Vladyslav Tymoshchuk
2026-10-22 17:32 ` [RFC PATCH 4/4] power: supply: qcom_battmgr: Allow charger changes to wake up the system Vladyslav Tymoshchuk
2026-11-02 22:05 ` Joonhoe Kim [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=20261102220510.1721-1-26rote@gmail.com \
--to=26rote@gmail.com \
--cc=abelvesa@kernel.org \
--cc=andersson@kernel.org \
--cc=casey.connolly@linaro.org \
--cc=daniel@quora.org \
--cc=gregkh@linuxfoundation.org \
--cc=gustavoars@kernel.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=jishnu.prakash@oss.qualcomm.com \
--cc=johan@kernel.org \
--cc=kamal.wadhwa@oss.qualcomm.com \
--cc=kees@kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=sre@kernel.org \
--cc=tvlad744@gmail.com \
/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
all inboxes | Powered by JetHome®