mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] PM / devfreq: Resume at the frequency from before suspend
@ 2026-11-10  5:57 Arun Iyengar via B4 Relay
  0 siblings, 0 replies; only message in thread
From: Arun Iyengar via B4 Relay @ 2026-11-10  5:57 UTC (permalink / raw)
  To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Dong Aisheng
  Cc: linux-pm, linux-kernel, Arun Iyengar

From: Arun Iyengar <aiyengar1990@gmail.com>

devfreq_suspend_device() moves a device that has a suspend OPP to that
frequency with devfreq_set_target(). Since commit 62453f1ba5d5 ("PM /
devfreq: Use more accurate returned new_freq as resume_freq"),
devfreq_set_target() records the frequency it has just set as
resume_freq, so the suspend transition itself overwrites the frequency
to resume at with the suspend frequency. devfreq_resume_device() then
"restores" the suspend frequency and the device stays there until the
governor next re-evaluates it.

For system suspend that only costs one polling interval. For a driver
that calls devfreq_suspend_device() from runtime PM, such as panthor,
every runtime resume starts at the lowest OPP: with a 50 ms autosuspend
delay and a 50 ms polling interval, short bursts of GPU work after an
idle period run at the suspend frequency.

Save the frequency the device ran at before the suspend transition and
use that as resume_freq, as the code did before that commit. Requests
made while the device is suspended still update resume_freq through
devfreq_set_target(), as before.

Fixes: 62453f1ba5d5 ("PM / devfreq: Use more accurate returned new_freq as resume_freq")
Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
The bug was found on an RK3588 board (panthor, runtime PM through
devfreq_suspend_device()). The patch runs in that board's v7.3-based
kernel. I could not test it on a second platform: my Allwinner H616
board has no suspend OPP, so the changed path is not taken there.

This patch was developed with Claude (Anthropic) as a coding
assistant: it wrote the code and the commit message.
I reviewed it and tested it as described above.
---
 drivers/devfreq/devfreq.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index f08fc6966eae..043cdc37bd0b 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -1146,6 +1146,7 @@ EXPORT_SYMBOL(devm_devfreq_remove_device);
  */
 int devfreq_suspend_device(struct devfreq *devfreq)
 {
+	unsigned long resume_freq;
 	int ret;
 
 	if (!devfreq)
@@ -1163,7 +1164,15 @@ int devfreq_suspend_device(struct devfreq *devfreq)
 
 	if (devfreq->suspend_freq) {
 		mutex_lock(&devfreq->lock);
+		/*
+		 * devfreq_set_target() records the frequency it sets as the
+		 * one to resume at. Keep the frequency from before suspend
+		 * instead, so that the device does not resume at its suspend
+		 * frequency.
+		 */
+		resume_freq = devfreq->previous_freq;
 		ret = devfreq_set_target(devfreq, devfreq->suspend_freq, 0);
+		devfreq->resume_freq = resume_freq;
 		mutex_unlock(&devfreq->lock);
 		if (ret)
 			return ret;

---
base-commit: 9a222650d9e70d0027126e4df5b00b1b5b678a97
change-id: 20261110-devfreq-resume-freq-e42eaeb6f8f8

Best regards,
--  
Arun Iyengar <aiyengar1990@gmail.com>



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2026-11-10  5:57 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-10  5:57 [PATCH] PM / devfreq: Resume at the frequency from before suspend Arun Iyengar via B4 Relay

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®