Qualcomm Suspend to Idle Support
cover Qualcomm Suspend to Idle Support
This set of patches adds suspend to idle support for the Qualcomm APQ8084 and MSM8916 platforms. The patches add a minimal set of suspend ops and init functions to properly configure the enter_freeze function.
This patch set is based on the work done in the following:
[RFC v3 00/12] PM: SoC idle support using PM domains
http://comments.gmane.org/gmane.linux.ports.arm.msm/17966
The relevant prerequisites are the PSCI enablement DT patches. PSCI based firmware is also required for the MSM8916 to work properly.
Andy Gross (5):
soc: qcom: Add suspend to idle support
arm: defconfig: Add Qualcomm Suspend options
arm64: dts: msm8916: Add spc compat tag
ARM: dts: qcom: Remove size elements from pmic reg
ARM: dts: qcom: pma8084: Add pwrkey entry
arch/arm/boot/dts/qcom-pma8084.dtsi | 20 ++++++--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- arch/arm64/configs/defconfig | 2 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/suspend.c | 77 +++++++++++++++++++++++++++++++++++ 5 files changed, 95 insertions(+), 7 deletions(-) create mode 100644 drivers/soc/qcom/suspend.c
Signature · 1 line
1.9.1
PATCH 1/5 soc: qcom: Add suspend to idle support
This patch adds suspend to idle support for Qualcomm processors. While suspend to memory will be a valid state, there won't be any special handling or power savings over the suspend to idle.
--- drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/suspend.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) create mode 100644 drivers/soc/qcom/suspend.c
drivers/soc/qcom/Makefile +1 -0
@@ -7,3 +7,4 @@ obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o obj-$(CONFIG_QCOM_SMP2P) += smp2p.o obj-$(CONFIG_QCOM_SMSM) += smsm.o obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o +obj-$(CONFIG_SUSPEND) += suspend.o
drivers/soc/qcom/suspend.c new file +77 -0
77 lines not on this page · raw message
Signature · 1 line
1.9.1
PATCH 1/5 soc: qcom: Add suspend to idle support
+ Daniel
Quoted 64 lines · Andy Gross
This patch adds suspend to idle support for Qualcomm processors. While suspend to memory will be a valid state, there won't be any special handling or power savings over the suspend to idle.
Signed-off-by Andy Gross <[email protected]>--- drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/suspend.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) create mode 100644 drivers/soc/qcom/suspend.cdrivers/soc/qcom/Makefile +1
-0@@ -7,3 +7,4 @@ obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o obj-$(CONFIG_QCOM_SMP2P) += smp2p.o obj-$(CONFIG_QCOM_SMSM) += smsm.o obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o +obj-$(CONFIG_SUSPEND) += suspend.odrivers/soc/qcom/suspend.c new file +38
-0@@ -0,0 +1,77 @@ +/* +* (C) Copyright 2016 Linaro Ltd. +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License +* as published by the Free Software Foundation; version 2 +* of the License. +*/ +#include <linux/module.h> +#include <linux/of.h> +#include <linux/cpuidle.h> +#include <linux/suspend.h> + + +static void qcom_pm_enter_freeze (struct cpuidle_device *dev, +struct cpuidle_driver *drv, +int index) +{ + drv->states[index].enter (dev, drv, index); +} + +static const struct of_device_id qcom_idle_state_match[] = { + { .compatible ="qcom,idle-state-spc" , }, + { }, +}; + +static const struct platform_suspend_ops qcom_suspend_ops = { + .valid = suspend_valid_only_mem, +}; + +static int __init qcom_pm_init (void ) +{ +struct cpuidle_device *cpu_dev; +struct cpuidle_driver *cpu_drv; +int state_count; +struct device_node *state_np, *cpu_np; +const struct of_device_id *match; +int i;
drivers/soc/qcom/suspend.c line 48
Quoted 10 lines
drivers/soc/qcom/suspend.c new file +10
-0+ +/* configure CPU enter_freeze if applicable */ +for_each_present_cpu (i) { + cpu_np =of_get_cpu_node (i,NULL ); + cpu_dev =per_cpu_ptr (cpuidle_devices, i); + cpu_drv =cpuidle_get_cpu_driver (cpu_dev); + +if (!cpu_dev || !cpu_drv) { +of_node_put (cpu_np); +return -EPROBE_DEFER ;
This isn't a driver, so returning -EPROBE_DEFER doesn't make sense.
Quoted 14 lines
drivers/soc/qcom/suspend.c new file +14
-0+ } + + state_count =0 ; + state_np =of_parse_phandle (cpu_np,"cpu-idle-states" , + state_count); + +while (state_np) { + match =of_match_node (qcom_idle_state_match, + state_np); + + state_count++; +if (match) + cpu_drv->states[state_count].enter_freeze = + &qcom_pm_enter_freeze;
drivers/soc/qcom/suspend.c line 72
Quoted 10 lines
drivers/soc/qcom/suspend.c new file +10
-0+of_node_put (state_np); + + state_np =of_parse_phandle (cpu_np,"cpu-idle-states" , + state_count); + } + +of_node_put (cpu_np); + } + +suspend_set_ops (&qcom_suspend_ops);
I don't think this will work!
When building a multi defconfig for ARM, you might overwrite the suspend_ops (there's only one set) as here you don't know that it's actually the QCOM platform that is running, right!?
Perhaps this code actually belongs closer to the cpuidle driver?
Quoted 7 lines
drivers/soc/qcom/suspend.c new file +5
-1+ +return 0 ; +} + +late_initcall (qcom_pm_init); --1.9.1
Kind regards
Uffe
PATCH 1/5 soc: qcom: Add suspend to idle support
Quoted 71 lines · Ulf Hansson
+ Daniel
Quoted 68 lines · Andy Gross
This patch adds suspend to idle support for Qualcomm processors. While suspend to memory will be a valid state, there won't be any special handling or power savings over the suspend to idle.
Signed-off-by Andy Gross <[email protected]>--- drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/suspend.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) create mode 100644 drivers/soc/qcom/suspend.cdrivers/soc/qcom/Makefile +1
-0@@ -7,3 +7,4 @@ obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o obj-$(CONFIG_QCOM_SMP2P) += smp2p.o obj-$(CONFIG_QCOM_SMSM) += smsm.o obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o +obj-$(CONFIG_SUSPEND) += suspend.odrivers/soc/qcom/suspend.c new file +42
-0@@ -0,0 +1,77 @@ +/* +* (C) Copyright 2016 Linaro Ltd. +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License +* as published by the Free Software Foundation; version 2 +* of the License. +*/ +#include <linux/module.h> +#include <linux/of.h> +#include <linux/cpuidle.h> +#include <linux/suspend.h> + + +static void qcom_pm_enter_freeze (struct cpuidle_device *dev, +struct cpuidle_driver *drv, +int index) +{ + drv->states[index].enter (dev, drv, index); +} + +static const struct of_device_id qcom_idle_state_match[] = { + { .compatible ="qcom,idle-state-spc" , }, + { }, +}; + +static const struct platform_suspend_ops qcom_suspend_ops = { + .valid = suspend_valid_only_mem, +}; + +static int __init qcom_pm_init (void ) +{ +struct cpuidle_device *cpu_dev; +struct cpuidle_driver *cpu_drv; +int state_count; +struct device_node *state_np, *cpu_np; +const struct of_device_id *match; +int i; + +/* configure CPU enter_freeze if applicable */ +for_each_present_cpu (i) { + cpu_np =of_get_cpu_node (i,NULL );
Quoted 8 lines
drivers/soc/qcom/suspend.c line 48
Quoted 6 lines
drivers/soc/qcom/suspend.c new file +6
-0+ cpu_dev =per_cpu_ptr (cpuidle_devices, i); + cpu_drv =cpuidle_get_cpu_driver (cpu_dev); + +if (!cpu_dev || !cpu_drv) { +of_node_put (cpu_np); +return -EPROBE_DEFER ;This isn't a driver, so returning -EPROBE_DEFER doesn't make sense.
Right. It's not like it'll get retried.
Quoted 27 lines
Quoted 14 lines
drivers/soc/qcom/suspend.c new file +14
-0+ } + + state_count =0 ; + state_np =of_parse_phandle (cpu_np,"cpu-idle-states" , + state_count); + +while (state_np) { + match =of_match_node (qcom_idle_state_match, + state_np); + + state_count++; +if (match) + cpu_drv->states[state_count].enter_freeze = + &qcom_pm_enter_freeze;drivers/soc/qcom/suspend.c line 72
Quoted 10 lines
drivers/soc/qcom/suspend.c new file +10
-0+of_node_put (state_np); + + state_np =of_parse_phandle (cpu_np,"cpu-idle-states" , + state_count); + } + +of_node_put (cpu_np); + } + +suspend_set_ops (&qcom_suspend_ops);I don't think this will work!
Quoted 5 lines
When building a multi defconfig for ARM, you might overwrite the
suspend_ops(there's only one set) as here you don't know that it's actually the QCOM platform that is running, right!?Perhaps this code actually belongs closer to the cpuidle driver?
Hmmmm, I might have to get creative. I originally had a DT entry for the pm, but that doesn't make sense as this is purely a software construct. The db410c uses the arm cpuidle driver so I can't really hook it in there. I'll have to come up with something else.
Andy
PATCH 1/5 soc: qcom: Add suspend to idle support
Quoted 114 lines · Andy Gross
Quoted 71 lines · Ulf Hansson
+ Daniel
Quoted 68 lines · Andy Gross
This patch adds suspend to idle support for Qualcomm processors. While suspend to memory will be a valid state, there won't be any special handling or power savings over the suspend to idle.
Signed-off-by Andy Gross <[email protected]>--- drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/suspend.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) create mode 100644 drivers/soc/qcom/suspend.cdrivers/soc/qcom/Makefile +1
-0@@ -7,3 +7,4 @@ obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o obj-$(CONFIG_QCOM_SMP2P) += smp2p.o obj-$(CONFIG_QCOM_SMSM) += smsm.o obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o +obj-$(CONFIG_SUSPEND) += suspend.odrivers/soc/qcom/suspend.c new file +42
-0@@ -0,0 +1,77 @@ +/* +* (C) Copyright 2016 Linaro Ltd. +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License +* as published by the Free Software Foundation; version 2 +* of the License. +*/ +#include <linux/module.h> +#include <linux/of.h> +#include <linux/cpuidle.h> +#include <linux/suspend.h> + + +static void qcom_pm_enter_freeze (struct cpuidle_device *dev, +struct cpuidle_driver *drv, +int index) +{ + drv->states[index].enter (dev, drv, index); +} + +static const struct of_device_id qcom_idle_state_match[] = { + { .compatible ="qcom,idle-state-spc" , }, + { }, +}; + +static const struct platform_suspend_ops qcom_suspend_ops = { + .valid = suspend_valid_only_mem, +}; + +static int __init qcom_pm_init (void ) +{ +struct cpuidle_device *cpu_dev; +struct cpuidle_driver *cpu_drv; +int state_count; +struct device_node *state_np, *cpu_np; +const struct of_device_id *match; +int i; + +/* configure CPU enter_freeze if applicable */ +for_each_present_cpu (i) { + cpu_np =of_get_cpu_node (i,NULL );Quoted 8 lines
drivers/soc/qcom/suspend.c line 48
Quoted 6 lines
drivers/soc/qcom/suspend.c new file +6
-0+ cpu_dev =per_cpu_ptr (cpuidle_devices, i); + cpu_drv =cpuidle_get_cpu_driver (cpu_dev); + +if (!cpu_dev || !cpu_drv) { +of_node_put (cpu_np); +return -EPROBE_DEFER ;This isn't a driver, so returning -EPROBE_DEFER doesn't make sense.
Right. It's not like it'll get retried.
Quoted 31 lines
Quoted 14 lines
drivers/soc/qcom/suspend.c new file +14
-0+ } + + state_count =0 ; + state_np =of_parse_phandle (cpu_np,"cpu-idle-states" , + state_count); + +while (state_np) { + match =of_match_node (qcom_idle_state_match, + state_np); + + state_count++; +if (match) + cpu_drv->states[state_count].enter_freeze = + &qcom_pm_enter_freeze;drivers/soc/qcom/suspend.c line 72
Quoted 10 lines
drivers/soc/qcom/suspend.c new file +10
-0+of_node_put (state_np); + + state_np =of_parse_phandle (cpu_np,"cpu-idle-states" , + state_count); + } + +of_node_put (cpu_np); + } + +suspend_set_ops (&qcom_suspend_ops);I don't think this will work!
When building a multi defconfig for ARM, you might overwrite the
suspend_ops(there's only one set) as here you don't know that it's actually the QCOM platform that is running, right!?
Quoted 6 lines
Quoted 1 line
Perhaps this code actually belongs closer to the cpuidle driver?
Hmmmm, I might have to get creative. I originally had a DT entry for the pm, but that doesn't make sense as this is purely a software construct. The db410c uses the arm cpuidle driver so I can't really hook it in there. I'll have to come up with something else.
I did a little research.
I think you should be able to use the struct cpuidle_ops->init() callback. This is being invoked when the arm cpuidle driver is initialized.
arm_idle_init()
->arm_cpuidle_init()
->cpuidle_ops->init()
In the QCOM case, it's the spm driver that registers these cpuidle_ops (drivers/soc/qcom/spm.c). If you fold in the code from $subject patch in qcom_cpuidle_init(), that should work I think.
Kind regards
Uffe
PATCH 1/5 soc: qcom: Add suspend to idle support
On Fri, Jun 10, 2016 at 10:47:35AM +0200, Ulf Hansson wrote:
<snip>
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines
I don't think this will work!
When building a multi defconfig for ARM, you might overwrite the
suspend_ops(there's only one set) as here you don't know that it's actually the QCOM platform that is running, right!?Quoted 6 lines
Quoted 1 line
Perhaps this code actually belongs closer to the cpuidle driver?
Hmmmm, I might have to get creative. I originally had a DT entry for the pm, but that doesn't make sense as this is purely a software construct. The db410c uses the arm cpuidle driver so I can't really hook it in there. I'll have to come up with something else.
I did a little research.
Quoted 7 lines
I think you should be able to use the struct
cpuidle_ops->init()callback. This is being invoked when the arm cpuidle driver is initialized.
arm_idle_init()
->arm_cpuidle_init()->cpuidle_ops->init()
Ah I'll see if I can get that to work. Thanks for the pointer.
Quoted 4 lines
In the QCOM case, it's the spm driver that registers these
cpuidle_ops(drivers/soc/qcom/spm.c). If you fold in the code from $subject patch inqcom_cpuidle_init(), that should work I think.
Only for the 32 bit processor case. The SPM is not used for the 64 bit procs.
Regards,
Andy
PATCH 1/5 soc: qcom: Add suspend to idle support
In reply to Andy GrossQuoted 4 lines · Andy Gross
Quoted 3 lines · Ulf Hansson
+ Daniel
On 19 May 2016 at 07:00, Andy Gross <[email protected]> wrote:
[ ... ]
Quoted 6 lines
Quoted 6 lines
I don't think this will work!
When building a multi defconfig for ARM, you might overwrite the
suspend_ops(there's only one set) as here you don't know that it's actually the QCOM platform that is running, right!?
Quoted 6 lines
Quoted 1 line
Perhaps this code actually belongs closer to the cpuidle driver?
Hmmmm, I might have to get creative. I originally had a DT entry for the pm, but that doesn't make sense as this is purely a software construct. The db410c uses the arm cpuidle driver so I can't really hook it in there. I'll have to come up with something else.
IMO, the generic ARM driver should be revisited to add support for suspend to idle.
PATCH 2/5 arm: defconfig: Enable PM8941 pwr key
In reply to Andy GrossThis patch enables the PM8941 pwr key driver.
--- arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/configs/defconfig +2 -0
@@ -142,6 +142,8 @@ CONFIG_WL18XX=m CONFIG_WLCORE_SDIO=m CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y +CONFIG_INPUT_MISC=y +CONFIG_INPUT_PM8941_PWRKEY=y # CONFIG_SERIO_SERPORT is not set CONFIG_SERIO_AMBAKMI=y CONFIG_LEGACY_PTY_COUNT=16
Signature · 1 line
1.9.1
PATCH 2/5 arm: defconfig: Enable PM8941 pwr key
Quoted 3 lines · Andy Gross
This patch enables the PM8941 pwr key driver.
Signed-off-by Andy Gross <[email protected]>
Quoted 25 lines
--- arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+)arch/arm64/configs/defconfig +2
-0@@ -142,6 +142,8 @@ CONFIG_WL18XX=m CONFIG_WLCORE_SDIO=m CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y +CONFIG_INPUT_MISC=y +CONFIG_INPUT_PM8941_PWRKEY=y # CONFIG_SERIO_SERPORT is not set CONFIG_SERIO_AMBAKMI=y CONFIG_LEGACY_PTY_COUNT=16Signature · 7 lines
1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
In reply to Andy GrossThis patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/qcom/msm8916.dtsi +1 -1
@@ -104,7 +104,7 @@ idle-states { CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;
Signature · 1 line
1.9.1
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Hi Andy,
Quoted 14 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0
arch/arm64/boot/dts/qcom/msm8916.dtsi line 105
Quoted 2 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0@@ -104,7 +104,7 @@ idle-states {
Is this change depends on some another patchset, I cannot find idle-states dt node on mainline nor linux-next ?
Quoted 7 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +1
-1CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 18 lines · Stanimir Varbanov
Hi Andy,
Quoted 15 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0@@ -104,7 +104,7 @@
Quoted 4 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi line 105
Quoted 1 line
arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0idle-states {Is this change depends on some another patchset, I cannot find idle-states dt node on mainline nor linux-next ?
The cover letter gives a link to the patchset that contains the basis for the changes. You can also check out my posted branch which merges in a part of those changes.
The link to the specific patch is:
http://www.spinics.net/lists/linux-arm-msm/msg19675.html
or you can look at this:
https://git.linaro.org/people/andy.gross/linux-pm.git/shortlog/refs/heads/for-pramod
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
In reply to Andy Gross[+ Lorenzo]
Quoted 14 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0
arch/arm64/boot/dts/qcom/msm8916.dtsi line 110
Quoted 8 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +1
-1@@ -104,7 +104,7 @@ idle-states { CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;
This looks suspicious.
This is a PSCI idle state, and we have a PSCI driver driven by the generic ARM cpuidle driver.
Why do we need a qcom-specific compatible here?
Surely we should be able to use the idle code in a generic fashion to driver suspend-to-idle?
Thank,
Mark.
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 28 lines · Mark Rutland
[+ Lorenzo]
Quoted 14 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0arch/arm64/boot/dts/qcom/msm8916.dtsi line 110
Quoted 8 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +1
-1@@ -104,7 +104,7 @@ idle-states { CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;This looks suspicious.
Quoted 7 lines
This is a PSCI idle state, and we have a PSCI driver driven by the generic ARM cpuidle driver.
Why do we need a qcom-specific compatible here?
Surely we should be able to use the idle code in a generic fashion to driver suspend-to-idle?
We need a way to identify specific idle states that support suspend-to-idle. In addition, when we have identified the states, we may have to configure the enter_freeze() function.
I chose to do this outside of the arm cpuidle driver because I didn't want to add any more DT information aside from the compatible, and I needed a separate place for the Qualcomm specific suspend code. With the compatible, this makes my 32 and 64 bit processor suspend code identical, as we have our own cpuidle driver for the 32 bit procs.
An alternative would be to add some facilities to communicate this to the arm cpuidle driver and configure the enter_freeze() function at some later point.
Regards,
Andy
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 32 lines · Andy Gross
Quoted 31 lines · Mark Rutland
[+ Lorenzo]
Quoted 14 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0arch/arm64/boot/dts/qcom/msm8916.dtsi line 110
Quoted 8 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +1
-1@@ -104,7 +104,7 @@ idle-states { CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;This looks suspicious.
This is a PSCI idle state, and we have a PSCI driver driven by the generic ARM cpuidle driver.
Quoted 8 lines
Quoted 4 lines
Why do we need a qcom-specific compatible here?
Surely we should be able to use the idle code in a generic fashion to driver suspend-to-idle?
We need a way to identify specific idle states that support suspend-to-idle. In addition, when we have identified the states, we may have to configure the
enter_freeze()function.
Could you elaborate on what you mean by a state supporting suspend-to-idle? It was my understanding that any idle state should function for suspend-to-idle (and the choice of state is potentially subjective).
Quoted 3 lines
I chose to do this outside of the arm cpuidle driver because I didn't want to add any more DT information aside from the compatible, and I needed a separate place for the Qualcomm specific suspend code.
Which suspend code is Qualcomm-specific? There shouldn't be anything on the PSCI side, so I can only imagine that device management is left. What am I missing?
Quoted 6 lines
With the compatible, this makes
my 32 and 64 bit processor suspend code identical, as we have our own cpuidle driver for the 32 bit procs.An alternative would be to add some facilities to communicate this to the arm cpuidle driver and configure the
enter_freeze()function at some later point.
I would prefer that suspend-to-idle using PSCI occurred via the generic PSCI and cpuidle code. I am happy to extend that code if there is something lacking, and I would prefer to not have platform-specific hooks.
Thanks,
Mark.
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 38 lines · Mark Rutland
Quoted 37 lines · Andy Gross
Quoted 35 lines · Mark Rutland
[+ Lorenzo]
Quoted 14 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0arch/arm64/boot/dts/qcom/msm8916.dtsi line 110
Quoted 8 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +1
-1@@ -104,7 +104,7 @@ idle-states { CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;This looks suspicious.
This is a PSCI idle state, and we have a PSCI driver driven by the generic ARM cpuidle driver.
Why do we need a qcom-specific compatible here?
Surely we should be able to use the idle code in a generic fashion to driver suspend-to-idle?
Quoted 8 lines
Quoted 3 lines
We need a way to identify specific idle states that support suspend-to-idle. In addition, when we have identified the states, we may have to configure the
enter_freeze()function.Could you elaborate on what you mean by a state supporting suspend-to-idle? It was my understanding that any idle state should function for suspend-to-idle (and the choice of state is potentially subjective).
when you freeze the system, cpuidle will try to find the deepest state which supports freeze (by checking if a enter_freeze() exists). If it does exist, then the tick is frozen and the enter_freeze is called as each cpu goes idle.
If no enter_freeze exists, the system will suspend, but will continue to have interrupts occur due to the tick and other bookkeeping stuff.
Quoted 8 lines
Quoted 4 lines
I chose to do this outside of the arm cpuidle driver because I didn't want to add any more DT information aside from the compatible, and I needed a separate place for the Qualcomm specific suspend code.
Which suspend code is Qualcomm-specific? There shouldn't be anything on the PSCI side, so I can only imagine that device management is left. What am I missing?
Qualcomm won't be supporting the psci suspend feature and will be doing their own thing. As such, they need their own suspend ops. In addition, we have platforms that don't use psci (32 bit).
Quoted 11 lines
Quoted 6 lines
With the compatible, this makes
my 32 and 64 bit processor suspend code identical, as we have our own cpuidle driver for the 32 bit procs.An alternative would be to add some facilities to communicate this to the arm cpuidle driver and configure the
enter_freeze()function at some later point.I would prefer that suspend-to-idle using PSCI occurred via the generic PSCI and cpuidle code. I am happy to extend that code if there is something lacking, and I would prefer to not have platform-specific hooks.
Right, I briefly looked at that in the beginning and decided against it. But if we can at least add some way to identify freezeable idle states and configure the freeze function, that'd cover all the requirements.
Regards,
Andy
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 6 lines · Andy Gross
Quoted 5 lines · Mark Rutland
Quoted 4 lines · Andy Gross
Quoted 3 lines · Mark Rutland
[+ Lorenzo]
On Thu, May 19, 2016 at 12:00:18AM -0500, Andy Gross wrote:
<...>
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
I chose to do this outside of the arm cpuidle driver because I didn't want to add any more DT information aside from the compatible, and I needed a separate place for the Qualcomm specific suspend code.
Quoted 9 lines
Quoted 3 lines
Which suspend code is Qualcomm-specific? There shouldn't be anything on the PSCI side, so I can only imagine that device management is left. What am I missing?
Qualcomm won't be supporting the psci suspend feature and will be doing their own thing. As such, they need their own suspend ops. In addition, we have platforms that don't use psci (32 bit).
Andy, which PSCI suspend feature are you referring to, here? On 8916, we do support CPU_SUSPEND in PSCI.
You don't want to call SYSTEM_SUSPEND, as it requires the other CPUs to be CPU_OFF (hotplugged off) before the last core calls this PSCI function.
Lina
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 31 lines · Lina Iyer
Quoted 8 lines · Andy Gross
Quoted 6 lines · Mark Rutland
Quoted 4 lines · Andy Gross
Quoted 3 lines · Mark Rutland
[+ Lorenzo]
On Thu, May 19, 2016 at 12:00:18AM -0500, Andy Gross wrote:
<...>
Quoted 14 lines
Quoted 11 lines
Quoted 7 lines
I chose to do this outside of the arm cpuidle driver because I didn't want to
add any more DT information aside from the compatible, and I needed a separate
place for the Qualcomm specific suspend code.Which suspend code is Qualcomm-specific? There shouldn't be anything on the PSCI side, so I can only imagine that device management is left. What am I missing?
Quoted 6 lines
Qualcomm won't be supporting the psci suspend feature and will be doing their
own thing. As such, they need their own suspend ops. In addition, we have
platforms that don't use psci (32 bit).
Quoted 6 lines
Andy, which PSCI suspend feature are you referring to, here? On 8916, we do support
CPU_SUSPENDin PSCI.You don't want to call
SYSTEM_SUSPEND, as it requires the other CPUs to beCPU_OFF(hotplugged off) before the last core calls this PSCI function.
I was referring to the SYSTEM_SUSPEND psci feature. It was my understanding that wouldn't be supported on the Qualcomm platforms.
Regards,
Andy
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
In reply to Andy GrossQuoted 43 lines · Andy Gross
Quoted 42 lines · Mark Rutland
Quoted 40 lines · Andy Gross
Quoted 28 lines · Mark Rutland
[+ Lorenzo]
Quoted 14 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0arch/arm64/boot/dts/qcom/msm8916.dtsi line 110
Quoted 8 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +1
-1@@ -104,7 +104,7 @@ idle-states { CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;This looks suspicious.
Quoted 7 lines
This is a PSCI idle state, and we have a PSCI driver driven by the generic ARM cpuidle driver.
Why do we need a qcom-specific compatible here?
Surely we should be able to use the idle code in a generic fashion to driver suspend-to-idle?
We need a way to identify specific idle states that support suspend-to-idle. In addition, when we have identified the states, we may have to configure the
enter_freeze()function.
Quoted 8 lines
Quoted 4 lines
Could you elaborate on what you mean by a state supporting suspend-to-idle? It was my understanding that any idle state should function for suspend-to-idle (and the choice of state is potentially subjective).
when you freeze the system, cpuidle will try to find the deepest state which supports freeze (by checking if a
enter_freeze()exists). If it does exist, then the tick is frozen and theenter_freezeis called as each cpu goes idle.
Per Lorenzo's replies in another thread, it sounds like this is a generic issue, and not specific to Qualcomm. My understanding is that the only issue is coupled idle states, and further, that issue is really an implementation detail within Linux w.r.t. IRQ management.
So it sounds like we need to rework things to be robust in the case of coupled idle states, and we can wire up enter_freeze for all states generically.
If there is some peroblem with making things robust, I assume we can identify coupled idle states today in some generic manner. I don't currently see the need for any DT binding.
Lorenzo, does the above make sense to you?
Quoted 11 lines
Quoted 7 lines
Quoted 3 lines
I chose to do this outside of the arm cpuidle driver because I didn't want to add any more DT information aside from the compatible, and I needed a separate place for the Qualcomm specific suspend code.
Which suspend code is Qualcomm-specific? There shouldn't be anything on the PSCI side, so I can only imagine that device management is left. What am I missing?
Qualcomm won't be supporting the psci suspend feature and will be doing their own thing. As such, they need their own suspend ops. In addition, we have platforms that don't use psci (32 bit).
That's orthogonal to suspend-to-idle, which can be handled in a generic fashion. It's also orthogonal to 32-bit !PSCI platforms, as my complaint was regarding the use of this with PSCI.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
With the compatible, this makes
my 32 and 64 bit processor suspend code identical, as we have our own cpuidle driver for the 32 bit procs.An alternative would be to add some facilities to communicate this to the arm cpuidle driver and configure the
enter_freeze()function at some later point.
Quoted 8 lines
Quoted 4 lines
I would prefer that suspend-to-idle using PSCI occurred via the generic PSCI and cpuidle code. I am happy to extend that code if there is something lacking, and I would prefer to not have platform-specific hooks.
Right, I briefly looked at that in the beginning and decided against it. But if we can at least add some way to identify freezeable idle states and configure the freeze function, that'd cover all the requirements.
Ok, per the above I believe that is covered.
Thanks,
Mark.
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 62 lines · Mark Rutland
Quoted 43 lines · Andy Gross
Quoted 42 lines · Mark Rutland
Quoted 40 lines · Andy Gross
Quoted 28 lines · Mark Rutland
[+ Lorenzo]
Quoted 14 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0arch/arm64/boot/dts/qcom/msm8916.dtsi line 110
Quoted 8 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +1
-1@@ -104,7 +104,7 @@ idle-states { CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;This looks suspicious.
Quoted 7 lines
This is a PSCI idle state, and we have a PSCI driver driven by the generic ARM cpuidle driver.
Why do we need a qcom-specific compatible here?
Surely we should be able to use the idle code in a generic fashion to driver suspend-to-idle?
We need a way to identify specific idle states that support suspend-to-idle. In addition, when we have identified the states, we may have to configure the
enter_freeze()function.Quoted 8 lines
Quoted 4 lines
Could you elaborate on what you mean by a state supporting suspend-to-idle? It was my understanding that any idle state should function for suspend-to-idle (and the choice of state is potentially subjective).
when you freeze the system, cpuidle will try to find the deepest state which supports freeze (by checking if a
enter_freeze()exists). If it does exist, then the tick is frozen and theenter_freezeis called as each cpu goes idle.Per Lorenzo's replies in another thread, it sounds like this is a generic issue, and not specific to Qualcomm. My understanding is that the only issue is coupled idle states, and further, that issue is really an implementation detail within Linux w.r.t. IRQ management.
So it sounds like we need to rework things to be robust in the case of coupled idle states, and we can wire up
enter_freezefor all states generically.
Quoted 5 lines
If there is some peroblem with making things robust, I assume we can identify coupled idle states today in some generic manner. I don't currently see the need for any DT binding.
Lorenzo, does the above make sense to you?
It does but I have a concern, let me summarize the problem here.
An idle state is freezeable if it can be entered with a function that does not enable IRQs and that's a kernel implementation detail; that function is used to initialize its enter_freeze() hook.
That's the case for all ARM platforms I am aware of, apart from the ones relying on coupled C-states that (by construction, in core CPUidle code) rely on IRQ enabling in their enter function body to work (NB: I do not handle coupled idle states in generic ARM CPUidle code, and I will never do so that's a non-existing problem).
The point is: while initializing the idle states in:
drivers/cpuidle/dt_idle_states.c (init_state_node())
we do not have all necessary information to know if we can safely initialize the enter_freeze() hook (because that's a property that depends on the CPUidle back-end).
We could add a DT property to report an idle state as "freezeable", but that's ugly and ill-defined, it is a kernel implementation detail, not sure a DT property makes sense here.
So, either:
(1) We consider all idle states to be "freezeable" and so I initialize their enter_freeze() pointer == enter() (and assume the idle back-end does NOT enable IRQs, I could add some documentation for that)
(2) I have to add code that probes the idle back-end (ie the arm_cpuidle_suspend() implementation) to detect which states require IRQs to be enabled.
(2) is ugly/convoluted (and solving a problem that does not exist at present). I am quite tempted to go for (1) and if we ever have some issues with that we blacklist the respective platforms enable-methods in the DT idle parsing code.
Thoughts appreciated.
Lorenzo
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 83 lines · Lorenzo Pieralisi
Quoted 62 lines · Mark Rutland
Quoted 43 lines · Andy Gross
Quoted 42 lines · Mark Rutland
Quoted 40 lines · Andy Gross
Quoted 28 lines · Mark Rutland
[+ Lorenzo]
Quoted 14 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0arch/arm64/boot/dts/qcom/msm8916.dtsi line 110
Quoted 8 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +1
-1@@ -104,7 +104,7 @@ idle-states { CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;This looks suspicious.
Quoted 7 lines
This is a PSCI idle state, and we have a PSCI driver driven by the generic ARM cpuidle driver.
Why do we need a qcom-specific compatible here?
Surely we should be able to use the idle code in a generic fashion to driver suspend-to-idle?
We need a way to identify specific idle states that support suspend-to-idle. In addition, when we have identified the states, we may have to configure the
enter_freeze()function.Quoted 8 lines
Quoted 4 lines
Could you elaborate on what you mean by a state supporting suspend-to-idle? It was my understanding that any idle state should function for suspend-to-idle (and the choice of state is potentially subjective).
when you freeze the system, cpuidle will try to find the deepest state which supports freeze (by checking if a
enter_freeze()exists). If it does exist, then the tick is frozen and theenter_freezeis called as each cpu goes idle.Per Lorenzo's replies in another thread, it sounds like this is a generic issue, and not specific to Qualcomm. My understanding is that the only issue is coupled idle states, and further, that issue is really an implementation detail within Linux w.r.t. IRQ management.
So it sounds like we need to rework things to be robust in the case of coupled idle states, and we can wire up
enter_freezefor all states generically.Quoted 5 lines
If there is some peroblem with making things robust, I assume we can identify coupled idle states today in some generic manner. I don't currently see the need for any DT binding.
Lorenzo, does the above make sense to you?
It does but I have a concern, let me summarize the problem here.
An idle state is freezeable if it can be entered with a function that does not enable IRQs and that's a kernel implementation detail; that function is used to initialize its
enter_freeze()hook.That's the case for all ARM platforms I am aware of, apart from the ones relying on coupled C-states that (by construction, in core CPUidle code) rely on IRQ enabling in their enter function body to work (NB: I do not handle coupled idle states in generic ARM CPUidle code, and I will never do so that's a non-existing problem).
Quoted 7 lines
The point is: while initializing the idle states in:
drivers/cpuidle/dt_idle_states.c(init_state_node())we do not have all necessary information to know if we can safely initialize the
enter_freeze()hook (because that's a property that depends on the CPUidle back-end).
And this is why I was modifying the enter_freeze after the cpuidle driver was loaded. And also why i was keying off the compat tag.
Quoted 6 lines
We could add a DT property to report an idle state as "freezeable", but that's ugly and ill-defined, it is a kernel implementation detail, not sure a DT property makes sense here.
Quoted 6 lines
So, either:
(1) We consider all idle states to be "freezeable" and so I initialize their
enter_freeze()pointer ==enter()(and assume the idle back-end does NOT enable IRQs, I could add some documentation for that)
The only issue at the moment with this is that the function prototypes are different. That is why I call the .enter function from withing my enter_freeze.
Otherwise I think this would work pretty well.
Quoted 5 lines
(2) I have to add code that probes the idle back-end (ie the
arm_cpuidle_suspend()implementation) to detect which states require IRQs to be enabled.
Quoted 8 lines
(2) is ugly/convoluted (and solving a problem that does not exist at present). I am quite tempted to go for (1) and if we ever have some issues with that we blacklist the respective platforms enable-methods in the DT idle parsing code.
Thoughts appreciated.
Lorenzo
Regards,
Andy
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
In reply to Andy GrossQuoted 47 lines · Andy Gross
Quoted 28 lines · Mark Rutland
[+ Lorenzo]
Quoted 14 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0arch/arm64/boot/dts/qcom/msm8916.dtsi line 110
Quoted 8 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +1
-1@@ -104,7 +104,7 @@ idle-states { CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;This looks suspicious.
Quoted 7 lines
This is a PSCI idle state, and we have a PSCI driver driven by the generic ARM cpuidle driver.
Why do we need a qcom-specific compatible here?
Surely we should be able to use the idle code in a generic fashion to driver suspend-to-idle?
We need a way to identify specific idle states that support suspend-to-idle. In addition, when we have identified the states, we may have to configure the
enter_freeze()function.I chose to do this outside of the arm cpuidle driver because I didn't want to add any more DT information aside from the compatible, and I needed a separate place for the Qualcomm specific suspend code. With the compatible, this makes my 32 and 64 bit processor suspend code identical, as we have our own cpuidle driver for the 32 bit procs.
Quoted 3 lines
An alternative would be to add some facilities to communicate this to the arm cpuidle driver and configure the
enter_freeze()function at some later point.
(1) enter_freeze() hooks are not strictly necessary to enable suspend-to-idle (they are if we want the tick to be frozen on suspend-to-idle, which is different)
(2) If I understand your code correctly you have to set the suspend ops hook to make sure suspend-to-idle is enabled. This is a core code issue rather than anything else, given that suspend-to-idle (hey it is based on CPUidle !) does NOT rely on suspend ops to function.
So the gist is: as far as I am concerned you do not need any of this code to enable (yes you need PSCI idle states but no qcom,idle-state-spc compatible string whatsoever) suspend-to-idle on ARM64 on top of PSCI, let me know what I am missing.
Thanks,
Lorenzo
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 48 lines · Lorenzo Pieralisi
Quoted 47 lines · Andy Gross
Quoted 28 lines · Mark Rutland
[+ Lorenzo]
Quoted 14 lines · Andy Gross
This patch adds the qcom,idle-state-spc compatible to the SPC idle state. This compatible indicates that the state is one which supports freeze.
Signed-off-by Andy Gross <[email protected]>--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm64/boot/dts/qcom/msm8916.dtsi +0
-0arch/arm64/boot/dts/qcom/msm8916.dtsi line 110
Quoted 8 lines
arch/arm64/boot/dts/qcom/msm8916.dtsi +1
-1@@ -104,7 +104,7 @@ idle-states { CPU_SPC: spc { - compatible = "arm,idle-state"; + compatible = "qcom,idle-state-spc", "arm,idle-state"; arm,psci-suspend-param = <0x40000002>; entry-latency-us = <130>; exit-latency-us = <150>;This looks suspicious.
Quoted 7 lines
This is a PSCI idle state, and we have a PSCI driver driven by the generic ARM cpuidle driver.
Why do we need a qcom-specific compatible here?
Surely we should be able to use the idle code in a generic fashion to driver suspend-to-idle?
We need a way to identify specific idle states that support suspend-to-idle. In addition, when we have identified the states, we may have to configure the
enter_freeze()function.I chose to do this outside of the arm cpuidle driver because I didn't want to add any more DT information aside from the compatible, and I needed a separate place for the Qualcomm specific suspend code. With the compatible, this makes my 32 and 64 bit processor suspend code identical, as we have our own cpuidle driver for the 32 bit procs.
Quoted 7 lines
Quoted 3 lines
An alternative would be to add some facilities to communicate this to the arm cpuidle driver and configure the
enter_freeze()function at some later point.(1)
enter_freeze()hooks are not strictly necessary to enable suspend-to-idle (they are if we want the tick to be frozen on suspend-to-idle, which is different)
I'd think that you'd want the tick frozen. Even if you are going to just call the deepest freezable idle state in your freeze_function, you don't want to keep getting woken up as this costs some power usage
Quoted 5 lines
(2) If I understand your code correctly you have to set the suspend ops hook to make sure suspend-to-idle is enabled. This is a core code issue rather than anything else, given that suspend-to-idle (hey it is based on CPUidle !) does NOT rely on suspend ops to function.
It only requires having suspend_ops and a valid function. Otherwise you can never suspend and never exercise the freeze portion of the cpuidle code.
Quoted 5 lines
So the gist is: as far as I am concerned you do not need any of this code to enable (yes you need PSCI idle states but no qcom,idle-state-spc compatible string whatsoever) suspend-to-idle on ARM64 on top of PSCI, let me know what I am missing.
If we had the facilities in the arm cpuidle driver then for 64 bit processors, I wouldn't have to do anything except provision my suspend_ops + valid function. For 32 bit, we actually already use this compat tag and I just have to add code in the spm driver (qcom cpuidle) to init the suspend_ops.
Regards,
Andy
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
On Fri, Jun 10, 2016 at 11:52:48AM -0500, Andy Gross wrote:
[...]
Quoted 7 lines
Quoted 3 lines
(1)
enter_freeze()hooks are not strictly necessary to enable suspend-to-idle (they are if we want the tick to be frozen on suspend-to-idle, which is different)I'd think that you'd want the tick frozen. Even if you are going to just call the deepest freezable idle state in your
freeze_function, you don't want to keep getting woken up as this costs some power usage
As I said, that's a separate issue from these bindings.
Quoted 9 lines
Quoted 5 lines
(2) If I understand your code correctly you have to set the suspend ops hook to make sure suspend-to-idle is enabled. This is a core code issue rather than anything else, given that suspend-to-idle (hey it is based on CPUidle !) does NOT rely on suspend ops to function.
It only requires having
suspend_opsand a valid function. Otherwise you can never suspend and never exercise the freeze portion of the cpuidle code.
As I said, *currently* you have to call suspend_set_ops() to set up the pm_states label for PM_SUSPEND_FREEZE, suspend_ops are irrelevant to make suspend-to-idle work and as I said that's related to core code rather than platform specific suspend ops.
We should solve issues, not work around them.
Quoted 10 lines
Quoted 4 lines
So the gist is: as far as I am concerned you do not need any of this code to enable (yes you need PSCI idle states but no qcom,idle-state-spc compatible string whatsoever) suspend-to-idle on ARM64 on top of PSCI, let me know what I am missing.
If we had the facilities in the arm cpuidle driver then for 64 bit processors, I wouldn't have to do anything except provision my
suspend_ops+ valid function. For 32 bit, we actually already use this compat tag and I just have to add code in the spm driver (qcom cpuidle) to init thesuspend_ops.
For 64-bit you do not have to have add any facility.
1) we should change core code to make PM_SUSPEND_FREEZE independent of suspend_set_ops()
2) we should define which idle states are freezable (99% of them are minus coupled idle states), through generic bindings
Lorenzo
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 8 lines · Lorenzo Pieralisi
On Fri, Jun 10, 2016 at 11:52:48AM -0500, Andy Gross wrote:
[...]
Quoted 4 lines
Quoted 3 lines
(1)
enter_freeze()hooks are not strictly necessary to enable suspend-to-idle (they are if we want the tick to be frozen on suspend-to-idle, which is different)
Quoted 5 lines
Quoted 3 lines
I'd think that you'd want the tick frozen. Even if you are going to just call the deepest freezable idle state in your
freeze_function, you don't want to keep getting woken up as this costs some power usageAs I said, that's a separate issue from these bindings.
I kind of see that coupled with the determination that a idle state supports freeze. Or are you wanting to have something else that decides whether or not to configure the enter_freeze?
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
(2) If I understand your code correctly you have to set the suspend ops hook to make sure suspend-to-idle is enabled. This is a core code issue rather than anything else, given that suspend-to-idle (hey it is based on CPUidle !) does NOT rely on suspend ops to function.
It only requires having
suspend_opsand a valid function. Otherwise you can never suspend and never exercise the freeze portion of the cpuidle code.
Quoted 6 lines
As I said, *currently* you have to call
suspend_set_ops()to set up thepm_stateslabel forPM_SUSPEND_FREEZE,suspend_opsare irrelevant to make suspend-to-idle work and as I said that's related to core code rather than platform specific suspend ops.We should solve issues, not work around them.
I wholeheartedly agree. I was just being more precise in my answer.
Quoted 12 lines
Quoted 11 lines
Quoted 5 lines
So the gist is: as far as I am concerned you do not need any of this code to enable (yes you need PSCI idle states but no qcom,idle-state-spc compatible string whatsoever) suspend-to-idle on ARM64 on top of PSCI, let me know what I am missing.
If we had the facilities in the arm cpuidle driver then for 64 bit processors, I wouldn't have to do anything except provision my
suspend_ops+ valid function. For 32 bit, we actually already use this compat tag and I just have to add code in the spm driver (qcom cpuidle) to init thesuspend_ops.
Quoted 4 lines
For 64-bit you do not have to have add any facility.
1) we should change core code to make
PM_SUSPEND_FREEZEindependent ofsuspend_set_ops()
So then, if cpuidle is active and you have idle states supporting freeze, then you can always implicitly freeze the system. This would infer then that the system will always indicate it can do freeze. I am good with that.
For now, we can get away with just implementing the changes you are suggesting.
Quoted 2 lines
2) we should define which idle states are freezable (99% of them are minus coupled idle states), through generic bindings
This would be in the form of a DT property? And given this property then we'd just assign a enter_freeze() function that calls the enter() for that state. Or would we have something else that we need to key off of to decide to configure the enter_freeze?
Regards,
Andy
PATCH 3/5 arm64: dts: msm8916: Add spc compat tag
Quoted 13 lines · Andy Gross
Quoted 12 lines · Lorenzo Pieralisi
On Fri, Jun 10, 2016 at 11:52:48AM -0500, Andy Gross wrote:
[...]
Quoted 7 lines
Quoted 3 lines
(1)
enter_freeze()hooks are not strictly necessary to enable suspend-to-idle (they are if we want the tick to be frozen on suspend-to-idle, which is different)I'd think that you'd want the tick frozen. Even if you are going to just call the deepest freezable idle state in your
freeze_function, you don't want to keep getting woken up as this costs some power usage
Quoted 5 lines
Quoted 1 line
As I said, that's a separate issue from these bindings.
I kind of see that coupled with the determination that a idle state supports freeze. Or are you wanting to have something else that decides whether or not to configure the
enter_freeze?
All PSCI based idle state support freeze, as long as most of the other idle routines for ARM 32-bit, I do not even think we should bother with defining DT bindings for it.
[...]
Quoted 5 lines
Quoted 4 lines
For 64-bit you do not have to have add any facility.
1) we should change core code to make
PM_SUSPEND_FREEZEindependent ofsuspend_set_ops()
Quoted 7 lines
So then, if cpuidle is active and you have idle states supporting freeze, then you can always implicitly freeze the system. This would infer then that the system will always indicate it can do freeze. I am good with that.
For now, we can get away with just implementing the changes you are suggesting.
Cracking.
Quoted 7 lines
Quoted 2 lines
2) we should define which idle states are freezable (99% of them are minus coupled idle states), through generic bindings
This would be in the form of a DT property? And given this property then we'd just assign a
enter_freeze()function that calls theenter()for that state. Or would we have something else that we need to key off of to decide to configure theenter_freeze?
See above, I will give it more thought. I take an action to change core code as per discussion above.
Thanks for raising the point.
Lorenzo
PATCH 4/5 ARM: dts: qcom: Remove size elements from pmic reg
In reply to Andy GrossThe #size-cells for the pmics are 0, but we specify a size in the reg property so that MPP and GPIO modules can figure out how many pins there are. Now that we've done that by counting irqs, we can remove the size elements in the reg properties and be DT compliant.
--- arch/arm/boot/dts/qcom-pma8084.dtsi | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
arch/arm/boot/dts/qcom-pma8084.dtsi +6 -6
@@ -12,15 +12,15 @@ rtc at 6000 { compatible = "qcom,pm8941-rtc"; - reg = <0x6000 0x100>, - <0x6100 0x100>; + reg = <0x6000>, + <0x6100>; reg-names = "rtc", "alarm"; interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>; }; pma8084_gpios: gpios at c000 { compatible = "qcom,pma8084-gpio", "qcom,spmi-gpio"; - reg = <0xc000 0x1600>; + reg = <0xc000>; gpio-controller; #gpio-cells = <2>; interrupts = <0 0xc0 0 IRQ_TYPE_NONE>,
@@ -49,7 +49,7 @@ pma8084_mpps: mpps at a000 { compatible = "qcom,pma8084-mpp", "qcom,spmi-mpp"; - reg = <0xa000 0x800>; + reg = <0xa000>; gpio-controller; #gpio-cells = <2>; interrupts = <0 0xa0 0 IRQ_TYPE_NONE>,
@@ -64,7 +64,7 @@ pma8084_temp: temp-alarm at 2400 { compatible = "qcom,spmi-temp-alarm"; - reg = <0x2400 0x100>; + reg = <0x2400>; interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>; #thermal-sensor-cells = <0>; io-channels = <&pma8084_vadc VADC_DIE_TEMP>;
@@ -73,7 +73,7 @@ pma8084_vadc: vadc at 3100 { compatible = "qcom,spmi-vadc"; - reg = <0x3100 0x100>; + reg = <0x3100>; interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; #address-cells = <1>; #size-cells = <0>;
Signature · 1 line
1.9.1
PATCH 4/5 ARM: dts: qcom: Remove size elements from pmic reg
Quoted 7 lines · Andy Gross
The #size-cells for the pmics are 0, but we specify a size in the reg property so that MPP and GPIO modules can figure out how many pins there are. Now that we've done that by counting irqs, we can remove the size elements in the reg properties and be DT compliant.
Signed-off-by Andy Gross <[email protected]>
Quoted 62 lines
--- arch/arm/boot/dts/qcom-pma8084.dtsi | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)arch/arm/boot/dts/qcom-pma8084.dtsi +6
-6@@ -12,15 +12,15 @@ rtc at 6000 { compatible = "qcom,pm8941-rtc"; - reg = <0x6000 0x100>, - <0x6100 0x100>; + reg = <0x6000>, + <0x6100>; reg-names = "rtc", "alarm"; interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>; }; pma8084_gpios: gpios at c000 { compatible = "qcom,pma8084-gpio", "qcom,spmi-gpio"; - reg = <0xc000 0x1600>; + reg = <0xc000>; gpio-controller; #gpio-cells = <2>; interrupts = <0 0xc0 0 IRQ_TYPE_NONE>,@@ -49,7 +49,7 @@ pma8084_mpps: mpps at a000 { compatible = "qcom,pma8084-mpp", "qcom,spmi-mpp"; - reg = <0xa000 0x800>; + reg = <0xa000>; gpio-controller; #gpio-cells = <2>; interrupts = <0 0xa0 0 IRQ_TYPE_NONE>,@@ -64,7 +64,7 @@ pma8084_temp: temp-alarm at 2400 { compatible = "qcom,spmi-temp-alarm"; - reg = <0x2400 0x100>; + reg = <0x2400>; interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>; #thermal-sensor-cells = <0>; io-channels = <&pma8084_vadc VADC_DIE_TEMP>;@@ -73,7 +73,7 @@ pma8084_vadc: vadc at 3100 { compatible = "qcom,spmi-vadc"; - reg = <0x3100 0x100>; + reg = <0x3100>; interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; #address-cells = <1>; #size-cells = <0>;Signature · 7 lines
1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 5/5 ARM: dts: qcom: pma8084: Add pwrkey entry
In reply to Andy GrossThis patch adds the power key device tree node.
--- arch/arm/boot/dts/qcom-pma8084.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/arm/boot/dts/qcom-pma8084.dtsi +8 -0
@@ -18,6 +18,14 @@ interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>; }; + pwrkey at 800 { + compatible = "qcom,pm8941-pwrkey"; + reg = <0x800>; + interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>; + debounce = <15625>; + bias-pull-up; + }; + pma8084_gpios: gpios at c000 { compatible = "qcom,pma8084-gpio", "qcom,spmi-gpio"; reg = <0xc000>;
Signature · 1 line
1.9.1
PATCH 5/5 ARM: dts: qcom: pma8084: Add pwrkey entry
Quoted 3 lines · Andy Gross
This patch adds the power key device tree node.
Signed-off-by Andy Gross <[email protected]>
Quoted 31 lines
--- arch/arm/boot/dts/qcom-pma8084.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm/boot/dts/qcom-pma8084.dtsi +8
-0@@ -18,6 +18,14 @@ interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>; }; + pwrkey at 800 { + compatible = "qcom,pm8941-pwrkey"; + reg = <0x800>; + interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>; + debounce = <15625>; + bias-pull-up; + }; + pma8084_gpios: gpios at c000 { compatible = "qcom,pma8084-gpio", "qcom,spmi-gpio"; reg = <0xc000>;Signature · 7 lines
1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
cover Qualcomm Suspend to Idle Support
In reply to Andy GrossQuoted 8 lines · Andy Gross
This set of patches adds suspend to idle support for the Qualcomm APQ8084 and MSM8916 platforms. The patches add a minimal set of suspend ops and init functions to properly configure the
enter_freezefunction.This patch set is based on the work done in the following:
[RFC v3 00/12] PM: SoC idle support using PM domains
http://comments.gmane.org/gmane.linux.ports.arm.msm/17966
Quoted 7 lines
The relevant prerequisites are the PSCI enablement DT patches. PSCI based firmware is also required for the MSM8916 to work properly.
Andy Gross (5):
soc: qcom: Add suspend to idle support
arm: defconfig: Add Qualcomm Suspend options
arm64: dts: msm8916: Add spc compat tag
Tested this series on DB410C. So for these three patches:
Quoted 18 lines
ARM: dts: qcom: Remove size elements from pmic reg
ARM: dts: qcom: pma8084: Add pwrkey entryarch/arm/boot/dts/qcom-pma8084.dtsi | 20 ++++++--- arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +- arch/arm64/configs/defconfig | 2 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/suspend.c | 77 +++++++++++++++++++++++++++++++++++ 5 files changed, 95 insertions(+), 7 deletions(-) create mode 100644 drivers/soc/qcom/suspend.c--
1.9.1--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html