From: Kazuki <kazukih0205@gmail.com> To: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Sudeep Holla <sudeep.holla@arm.com>, "Rafael J. Wysocki" <rafael@kernel.org>, Daniel Lezcano <daniel.lezcano@linaro.org>, Lorenzo Pieralisi <lpieralisi@kernel.org>, Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>, Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz> Subject: s2idle breaks on machines without cpuidle support Date: Sun, 5 Feb 2023 00:27:47 +0900 [thread overview] Message-ID: <20230204152747.drte4uitljzngdt6@kazuki-mac> (raw) Hi everyone, s2idle is blocked on machines without proper cpuidle support here in kernel/sched/idle.c: > if (cpuidle_not_available(drv, dev)) { > tick_nohz_idle_stop_tick(); > default_idle_call(); > goto exit_idle; > } > /* > * Suspend-to-idle ("s2idle") is a system state in which all user space > * has been frozen, all I/O devices have been suspended and the only However, there are 2 problems with this approach: 1. The suspend framework does not expect this, and continues to suspend the machine, which causes machines without proper cpuidle support to break when suspending 2. Suspend actually works on ARM64 machines even without proper cpuidle (PSCI cpuidle) since they support wfi, so the assumption here is wrong on such machines I'm not exactly sure how to figure this out, and my attempts have all led to an unbootable kernel, so I've cc'ed the relevant people and hopefully we can find a solution to this problem. Thanks, Kazuki
WARNING: multiple messages have this Message-ID (diff)
From: Kazuki <kazukih0205@gmail.com> To: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Sudeep Holla <sudeep.holla@arm.com>, "Rafael J. Wysocki" <rafael@kernel.org>, Daniel Lezcano <daniel.lezcano@linaro.org>, Lorenzo Pieralisi <lpieralisi@kernel.org>, Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>, Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz> Subject: s2idle breaks on machines without cpuidle support Date: Sun, 5 Feb 2023 00:27:47 +0900 [thread overview] Message-ID: <20230204152747.drte4uitljzngdt6@kazuki-mac> (raw) Hi everyone, s2idle is blocked on machines without proper cpuidle support here in kernel/sched/idle.c: > if (cpuidle_not_available(drv, dev)) { > tick_nohz_idle_stop_tick(); > default_idle_call(); > goto exit_idle; > } > /* > * Suspend-to-idle ("s2idle") is a system state in which all user space > * has been frozen, all I/O devices have been suspended and the only However, there are 2 problems with this approach: 1. The suspend framework does not expect this, and continues to suspend the machine, which causes machines without proper cpuidle support to break when suspending 2. Suspend actually works on ARM64 machines even without proper cpuidle (PSCI cpuidle) since they support wfi, so the assumption here is wrong on such machines I'm not exactly sure how to figure this out, and my attempts have all led to an unbootable kernel, so I've cc'ed the relevant people and hopefully we can find a solution to this problem. Thanks, Kazuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2023-02-04 15:27 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-04 15:27 Kazuki [this message] 2023-02-04 15:27 ` s2idle breaks on machines without cpuidle support Kazuki 2023-02-06 10:12 ` Sudeep Holla 2023-02-06 10:12 ` Sudeep Holla 2023-02-07 19:48 ` Kazuki 2023-02-07 19:48 ` Kazuki 2023-02-08 10:35 ` Sudeep Holla 2023-02-08 10:35 ` Sudeep Holla 2023-02-08 11:20 ` Kazuki 2023-02-08 11:20 ` Kazuki 2023-02-08 14:16 ` Sudeep Holla 2023-02-08 14:16 ` Sudeep Holla 2023-02-08 14:43 ` Kazuki 2023-02-08 14:43 ` Kazuki 2023-02-08 15:03 ` Sudeep Holla 2023-02-08 15:03 ` Sudeep Holla 2023-02-08 15:19 ` Kazuki 2023-02-08 15:19 ` Kazuki 2023-02-08 15:34 ` Sudeep Holla 2023-02-08 15:34 ` Sudeep Holla 2023-02-08 15:42 ` Kazuki 2023-02-08 15:42 ` Kazuki 2023-02-08 14:52 ` Kazuki 2023-02-08 14:52 ` Kazuki 2023-02-08 15:42 ` Hector Martin 2023-02-08 15:42 ` Hector Martin 2023-02-08 16:18 ` Sudeep Holla 2023-02-08 16:18 ` Sudeep Holla 2023-02-08 16:45 ` Hector Martin 2023-02-08 16:45 ` Hector Martin 2023-09-07 19:11 ` Florian Fainelli 2023-09-07 19:11 ` Florian Fainelli
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=20230204152747.drte4uitljzngdt6@kazuki-mac \ --to=kazukih0205@gmail.com \ --cc=daniel.lezcano@linaro.org \ --cc=len.brown@intel.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=lpieralisi@kernel.org \ --cc=marcan@marcan.st \ --cc=pavel@ucw.cz \ --cc=rafael@kernel.org \ --cc=sudeep.holla@arm.com \ --cc=sven@svenpeter.dev \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.