From: Zhang Rui <firstname.lastname@example.org>
To: email@example.com, firstname.lastname@example.org, email@example.com
Cc: firstname.lastname@example.org, email@example.com,
Subject: [PATCH 0/7] PM: Solution for S0ix failure caused by PCH overheating
Date: Thu, 5 May 2022 09:58:07 +0800 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On some Intel client platforms like SKL/KBL/CNL/CML, there is a
PCH thermal sensor that monitors the PCH temperature and blocks the system
from entering S0ix in case it overheats.
Commit ef63b043ac86 ("thermal: intel: pch: fix S0ix failure due to PCH
temperature above threshold") introduces a delay loop to cool the
temperature down for this purpose.
However, in practice, we found that the time it takes to cool the PCH down
below threshold highly depends on the initial PCH temperature when the
delay starts, as well as the ambient temperature.
For example, on a Dell XPS 9360 laptop, the problem can be triggered
1. when it is suspended with heavy workload running.
2. when it is moved from New Hampshire to Florida.
In these cases, the 1 second delay is not sufficient. As a result, the
system stays in a shallower power state like PCx instead of S0ix, and
drains the battery power, without user' notice.
In this patch series, we first fix the problem in patch 1/7 ~ 3/7, by
1. expand the default overall cooling delay timeout to 60 seconds.
2. make sure the temperature is below threshold rather than equal to it.
3. move the delay to .suspend_noirq phase instead, in order to
a) do the cooling when the system is in a more quiescent state
b) be aware of wakeup events during the long delay, because some wakeup
events (ACPI Power button Press, USB mouse, etc) become valid only
in .suspend_noirq phase and later.
However, this potential long delay introduces a problem to our suspend
stress automation test, because the delay makes it hard to predict how
much time it takes to suspend the system.
As we want to do as much suspend iterations as possible in limited time,
setting a 60+ seconds rtc alarm for suspend which usually takes shorter
than 1 second is far beyond overkill.
Thus, in patch 4/7 ~ 7/7, a rtc driver hook is introduced, which cancels
the armed rtc alarm in the beginning of suspend and then rearm the rtc
alarm with a short interval (say, 2 second) right before system suspended.
# echo 2 > /sys/module/rtc_cmos/parameters/rtc_wake_override_sec
before suspend, the system can be resumed by RTC alarm right after it is
suspended, no matter how much time the suspend really takes.
This patch series has been tested on the same Dell XPS 9360 laptop and
S0ix is 100% achieved across 1000+ s2idle iterations.
next reply other threads:[~2022-05-05 1:58 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-05 1:58 Zhang Rui [this message]
2022-05-05 1:58 ` [PATCH 1/7] PM: wakeup: expose pm_wakeup_pending to modules Zhang Rui
2022-05-05 1:58 ` [PATCH 2/7] thermal: intel: pch: enhance overheat handling Zhang Rui
2022-05-17 15:02 ` Rafael J. Wysocki
2022-05-05 1:58 ` [PATCH 3/7] thermal: intel: pch: improve the cooling delay log Zhang Rui
2022-05-05 1:58 ` [PATCH 4/7] ACPI: video: improve PM notifer callback Zhang Rui
2022-05-05 1:58 ` [PATCH 5/7] wil6210: remove debug message for unsupported PM event Zhang Rui
2022-05-05 4:38 ` Kalle Valo
2022-05-05 5:24 ` Zhang Rui
2022-05-06 14:04 ` Kalle Valo
2022-05-07 1:23 ` Zhang Rui
2022-05-05 1:58 ` [PATCH 6/7] PM: suspend: introduce PM_SUSPEND_LATE event Zhang Rui
2022-05-05 1:58 ` [PATCH 7/7] rtc: cmos: Add suspend/resume endurance testing hook Zhang Rui
2022-05-06 21:46 ` Alexandre Belloni
2022-05-07 2:00 ` Zhang Rui
2022-05-07 7:31 ` Alexandre Belloni
2022-05-07 7:41 ` Zhang Rui
2022-05-16 7:50 ` Zhang Rui
2022-05-17 15:14 ` Rafael J. Wysocki
2022-05-18 14:44 ` Zhang Rui
2022-05-18 15:02 ` Rafael J. Wysocki
2022-05-18 16:07 ` Zhang Rui
2022-05-19 2:33 ` Len Brown
2022-05-19 10:56 ` Rafael J. Wysocki
2022-05-05 8:22 ` [PATCH 0/7] PM: Solution for S0ix failure caused by PCH overheating Oliver Neukum
2022-05-05 12:02 ` Rafael J. Wysocki
2022-05-05 15:18 ` Zhang Rui
2022-05-17 15:11 ` Rafael J. Wysocki
2022-05-17 17:07 ` Alexandre Belloni
2022-05-18 14:11 ` Zhang Rui
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).