From: hanjun.guo@linaro•org (Hanjun Guo)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v7 1/8] arm64: kernel: refactor the CPU suspend API for retention states
Date: Mon, 18 Aug 2014 15:47:51 +0800 [thread overview]
Message-ID: <53F1AFA7.5040003@linaro.org> (raw)
In-Reply-To: <1407945127-27554-2-git-send-email-lorenzo.pieralisi@arm.com>
On 2014-8-13 23:52, Lorenzo Pieralisi wrote:
> CPU suspend is the standard kernel interface to be used to enter
> low-power states on ARM64 systems. Current cpu_suspend implementation
> by default assumes that all low power states are losing the CPU context,
> so the CPU registers must be saved and cleaned to DRAM upon state
> entry. Furthermore, the current cpu_suspend() implementation assumes
> that if the CPU suspend back-end method returns when called, this has
> to be considered an error regardless of the return code (which can be
> successful) since the CPU was not expected to return from a code path that
> is different from cpu_resume code path - eg returning from the reset vector.
>
> All in all this means that the current API does not cope well with low-power
> states that preserve the CPU context when entered (ie retention states),
> since first of all the context is saved for nothing on state entry for
> those states and a successful state entry can return as a normal function
> return, which is considered an error by the current CPU suspend
> implementation.
>
> This patch refactors the cpu_suspend() API so that it can be split in
> two separate functionalities. The arm64 cpu_suspend API just provides
> a wrapper around CPU suspend operation hook. A new function is
> introduced (for architecture code use only) for states that require
> context saving upon entry:
>
> __cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>
> __cpu_suspend() saves the context on function entry and calls the
> so called suspend finisher (ie fn) to complete the suspend operation.
> The finisher is not expected to return, unless it fails in which case
> the error is propagated back to the __cpu_suspend caller.
>
> The API refactoring results in the following pseudo code call sequence for a
> suspending CPU, when triggered from a kernel subsystem:
>
> /*
> * int cpu_suspend(unsigned long idx)
> * @idx: idle state index
> */
> {
> -> cpu_suspend(idx)
> |---> CPU operations suspend hook called, if present
> |--> if (retention_state)
> |--> direct suspend back-end call (eg PSCI suspend)
> else
> |--> __cpu_suspend(idx, &back_end_finisher);
> }
>
> By refactoring the cpu_suspend API this way, the CPU operations back-end
> has a chance to detect whether idle states require state saving or not
> and can call the required suspend operations accordingly either through
> simple function call or indirectly through __cpu_suspend() which carries out
> state saving and suspend finisher dispatching to complete idle state entry.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm•com>
This patch is pretty fine to me,
Reviewed-by: Hanjun Guo <hanjun.guo@linaro•org>
Thanks
Hanjun
next prev parent reply other threads:[~2014-08-18 7:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 15:51 [PATCH v7 0/8] ARM generic idle states Lorenzo Pieralisi
2014-08-13 15:52 ` [PATCH v7 1/8] arm64: kernel: refactor the CPU suspend API for retention states Lorenzo Pieralisi
2014-08-18 7:47 ` Hanjun Guo [this message]
2014-08-18 14:20 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 2/8] Documentation: arm: define DT idle states bindings Lorenzo Pieralisi
2014-08-13 19:25 ` Lina Iyer
2014-08-13 22:11 ` Lorenzo Pieralisi
2014-08-15 17:20 ` Lina Iyer
2014-08-15 17:51 ` Lorenzo Pieralisi
2014-08-18 14:20 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 3/8] drivers: cpuidle: implement DT based idle states infrastructure Lorenzo Pieralisi
2014-08-13 16:31 ` Nicolas Pitre
2014-08-13 17:04 ` Lorenzo Pieralisi
2014-08-13 17:29 ` Nicolas Pitre
2014-08-14 11:29 ` Lorenzo Pieralisi
2014-08-14 15:47 ` Nicolas Pitre
2014-08-14 16:02 ` Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 4/8] arm64: kernel: introduce cpu_init_idle CPU operation Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 5/8] arm64: add PSCI CPU_SUSPEND based cpu_suspend support Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 6/8] drivers: cpuidle: CPU idle ARM64 driver Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-18 22:30 ` Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-18 22:25 ` Lorenzo Pieralisi
2014-08-13 15:52 ` [PATCH v7 7/8] drivers: cpuidle: initialize big.LITTLE driver through DT Lorenzo Pieralisi
2014-08-18 14:21 ` Catalin Marinas
2014-08-13 15:52 ` [PATCH v7 8/8] drivers: cpuidle: initialize Exynos " Lorenzo Pieralisi
2014-08-15 21:12 ` Lina Iyer
2014-08-15 21:40 ` Lorenzo Pieralisi
2014-08-15 21:45 ` Lina Iyer
2014-08-15 21:52 ` Lorenzo Pieralisi
2014-08-18 14:22 ` Catalin Marinas
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=53F1AFA7.5040003@linaro.org \
--to=hanjun.guo@linaro$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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