From: Lina Iyer <lina.iyer@linaro.org>
To: Zhaoyang Huang <zhaoyang.huang@linaro.org>
Cc: Marc Titinger <mtitinger@baylibre.com>,
khilman@kernel.org, rjw@rjwysocki.net,
Axel Haslam <ahaslam@baylibre.com>,
Benoit Cousson <bcousson@baylibre.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC v2 5/6] arm: cpuidle: let genpd handle the cluster power transition with 'power-states'
Date: Wed, 11 Nov 2015 10:27:03 -0700 [thread overview]
Message-ID: <20151111172703.GD691@linaro.org> (raw)
In-Reply-To: <CAN2waFvgQUO4Mda3bHEwRDEPO2T36DWXXWKuW6G9+o7mQ854VQ@mail.gmail.com>
On Wed, Nov 11 2015 at 02:10 -0700, Zhaoyang Huang wrote:
>On 6 October 2015 at 22:27, Marc Titinger <mtitinger@baylibre.com> wrote:
>> From: Marc Titinger <mtitinger@baylibre.com>
>>
>> Cpuidle now handles c-states and power-states differently. c-states do not decrement
>> the reference count for the CPUs in the cluster, while power-states i.e.
>> cluster level states like 'CLUSTER_SLEEP_0' in the case of juno, will.
>>
>> The 'D1' fake device also registers intermediate power-state,
>> for experimentation.
>>
>> Signed-off-by: Marc Titinger <mtitinger@baylibre.com>
>> ---
>> arch/arm64/boot/dts/arm/juno.dts | 2 +-
>> drivers/cpuidle/cpuidle-arm.c | 52 ++++++++++++++++++++++++++++++++--------
>> 2 files changed, 43 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
>> index cadc5de..0bb0dd7 100644
>> --- a/arch/arm64/boot/dts/arm/juno.dts
>> +++ b/arch/arm64/boot/dts/arm/juno.dts
>> @@ -47,7 +47,7 @@
>> };
>>
>> CLUSTER_SLEEP_0: cluster-sleep-0 {
>> - compatible = "arm,idle-state","arm,power-state";
>> + compatible = "arm,power-state";
>> arm,psci-suspend-param = <0x1010000>;
>> local-timer-stop;
>> entry-latency-us = <800>;
>> diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
>> index 7c791f9..8dd5dc3 100644
>> --- a/drivers/cpuidle/cpuidle-arm.c
>> +++ b/drivers/cpuidle/cpuidle-arm.c
>> @@ -40,7 +40,6 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
>> struct cpuidle_driver *drv, int idx)
>> {
>> int ret;
>> - struct device *cpu_dev = get_cpu_device(dev->cpu);
>>
>> if (!idx) {
>> cpu_do_idle();
>> @@ -50,18 +49,49 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
>> ret = cpu_pm_enter();
>> if (!ret) {
>> /*
>> - * Notify runtime PM as well of this cpu powering down
>> - * TODO: Merge CPU_PM and runtime PM.
>> - */
>> - RCU_NONIDLE(pm_runtime_put_sync(cpu_dev));
>> -
>> - /*
>> * Pass idle state index to cpu_suspend which in turn will
>> * call the CPU ops suspend protocol with idle index as a
>> * parameter.
>> */
>> arm_cpuidle_suspend(idx);
>>
>> + cpu_pm_exit();
>> + }
>> +
>> + return ret ? -1 : idx;
>> +}
>> +
>> +/*
>> + * arm_enter_power_state - delegate state trasition to genpd
>> + *
>> + * dev: cpuidle device
>> + * drv: cpuidle driver
>> + * idx: state index
>> + *
>> + * Called from the CPUidle framework to delegate a state transition
>> + * to the generic domain. This will be a cluster poweroff state
>> + * the Domain will chose to actually turn off the cluster based on
>> + * the status of other CPUs, and devices and subdomains in the Cluster
>> + * domain.
>> +*/
>> +static int arm_enter_power_state(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv, int idx)
>> +{
>> + int ret;
>> + struct device *cpu_dev = get_cpu_device(dev->cpu);
>> +
>> + BUG_ON(idx == 0);
>> +
>> + ret = cpu_pm_enter();
>> + if (!ret) {
>> + /*
>> + * Notify runtime PM as well of this cpu powering down
>> + * TODO: Merge CPU_PM and runtime PM.
>> + */
>> + RCU_NONIDLE(pm_runtime_put_sync(cpu_dev));
>[question]: Does it mean that above function will use the gpd->rpm->idle?
Will end up at rpm_suspend() in runtime.c which will callinto genpd. Its
not a direct call to genpd.
Thanks,
Lina
>> +
>> + arm_cpuidle_suspend(idx);
>> +
>> RCU_NONIDLE(pm_runtime_get_sync(cpu_dev));
>> cpu_pm_exit();
>> }
>> @@ -69,6 +99,7 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
>> return ret ? -1 : idx;
>> }
>>
>> +
>> static struct cpuidle_driver arm_idle_driver = {
>> .name = "arm_idle",
>> .owner = THIS_MODULE,
>> @@ -90,9 +121,10 @@ static struct cpuidle_driver arm_idle_driver = {
>> };
>>
>> static const struct of_device_id arm_idle_state_match[] __initconst = {
>> - { .compatible = "arm,idle-state",
>> - .data = arm_enter_idle_state },
>> - { },
>> + {.compatible = "arm,idle-state",
>> + .data = arm_enter_idle_state},
>> + {.compatible = "arm,power-state",
>> + .data = arm_enter_power_state},
>> };
>>
>> /*
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-11-11 17:27 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 13:04 [RFC 0/7] Managing cluser-level c-states with generic power domains Marc Titinger
2015-09-25 13:04 ` [RFC 1/7] arm64: pm/domains: try mutualize CPU domains init between arm/arm64 Marc Titinger
2015-10-06 2:27 ` Lina Iyer
2015-10-06 8:52 ` Marc Titinger
2015-10-06 14:27 ` [RFC v2 0/6] Managing cluser-level c-states with generic power domains Marc Titinger
2015-10-06 14:27 ` [RFC v2 1/6] arm64: Juno: declare generic power domains for both clusters Marc Titinger
2015-10-06 14:27 ` [RFC v2 2/6] PM / Domains: prepare for devices that might register a power state Marc Titinger
2015-10-08 16:11 ` Lina Iyer
2015-10-09 9:39 ` Marc Titinger
2015-10-09 18:22 ` Lina Iyer
2015-10-13 10:29 ` Marc Titinger
2015-10-13 21:03 ` Kevin Hilman
2015-10-06 14:27 ` [RFC v2 3/6] PM / Domains: introduce power-states consistent with c-states Marc Titinger
2015-10-08 16:27 ` Lina Iyer
2015-10-09 10:04 ` Marc Titinger
2015-10-06 14:27 ` [RFC v2 4/6] PM / Domains: succeed & warn when attaching non-irqsafe devices to an irq-safe domain Marc Titinger
2015-10-06 14:27 ` [RFC v2 5/6] arm: cpuidle: let genpd handle the cluster power transition with 'power-states' Marc Titinger
2015-11-11 9:10 ` Zhaoyang Huang
2015-11-11 17:27 ` Lina Iyer [this message]
2015-10-06 14:27 ` [RFC v2 6/6] PM / Domains: add debugfs 'states' and 'timings' seq files Marc Titinger
2015-10-13 23:10 ` [RFC v2 0/6] Managing cluser-level c-states with generic power domains Kevin Hilman
2015-10-14 8:10 ` Axel Haslam
2015-10-19 20:58 ` Lina Iyer
2015-10-20 9:10 ` Marc Titinger
2015-10-27 17:40 ` [RFC v3 0/7] Managing cluser-level idle-states " Marc Titinger
2015-10-27 17:40 ` [RFC v3 1/7] PM / Domains: prepare for devices that might register a power state Marc Titinger
2015-10-27 17:40 ` [RFC v3 2/7] PM / Domains: support idle-states as genpd multiple-state Marc Titinger
2015-11-13 5:56 ` Zhaoyang Huang
2015-10-27 17:40 ` [RFC v3 3/7] arm64: dts: Add idle-states for Juno Marc Titinger
2015-10-27 17:40 ` [RFC v3 4/7] arm64: Juno: declare generic power domains for both clusters Marc Titinger
2015-10-27 17:40 ` [RFC v3 5/7] drivers: cpu-pd: allow calling of_cpu_pd_init from platform code Marc Titinger
2015-10-27 17:40 ` [RFC v3 6/7] arm64: PM /Domains: Initialize CPU-domains from DT Marc Titinger
2015-10-27 17:40 ` [RFC v3 7/7] arm64: Juno: declare idle-state cluster-sleep-0 as genpd state Marc Titinger
2015-09-25 13:04 ` [RFC 2/7] arm64: Juno: declare generic power domains for both clusters Marc Titinger
2015-09-25 13:04 ` [RFC 3/7] PM / Domains: prepare for devices that might register a power state Marc Titinger
2015-09-25 13:04 ` [RFC 4/7] PM / Domains: introduce power-states consistent with c-states Marc Titinger
2015-09-25 13:04 ` [RFC 5/7] PM / Domains: succeed & warn when attaching non-irqsafe devices to an irq-safe domain Marc Titinger
2015-09-25 13:04 ` [RFC 6/7] arm: cpuidle: let genpd handle the cluster power transition with 'power-states' Marc Titinger
2015-09-25 13:04 ` [RFC 7/7] PM / Domains: add debugfs 'states' and 'timings' seq files Marc Titinger
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=20151111172703.GD691@linaro.org \
--to=lina.iyer@linaro.org \
--cc=ahaslam@baylibre.com \
--cc=bcousson@baylibre.com \
--cc=khilman@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mtitinger@baylibre.com \
--cc=rjw@rjwysocki.net \
--cc=zhaoyang.huang@linaro.org \
/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;
as well as URLs for NNTP newsgroup(s).