[PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Nishanth Menon]

The following series are various fixes and improvements for
supporting suspend-to-ram. This depends on the following for basic functionality:
series 1/6 where powerdomain fixes were involved.
This will at least allow wake up from an internal source such as from a wakeup timer:
For example with https://github.com/nmenon/linux-2.6-playground/commit/92e5e7407aa707ad6be8ae3b5bf21cfc741daab6

pinctrl series allows for external wakeup event sources like pushbutton etc.

NOTE: OMAP5 and DRA7 definitions of power states and suspend targets
are almost identical (except for core power domain target state as part of suspend).

NOTE: This also needs missing hwmod and dts entries for various
peripherals that will eventually arrive over a period of time.

This is part 5/6 series which actually enables framework for
suspend-to-ram and cpuidle for OMAP5 and DRA7

Each of series is based on v3.17-rc1 and this specific series is available:
weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/v3.17/powerdomain-fixes

git repo: https://github.com/nmenon/linux-2.6-playground.git push/v3.17/powerdomain-fixes

An complete integrated branch is available here: https://github.com/nmenon/linux-2.6-playground/commits/testing/v3.17/cpu-idle-suspend-dra7-omap5-framework

Example test log:
DRA7 based BeagleBoard X15: http://slexy.org/view/s2jgsH8bos (wakeup from external using pinctrl wakeup).
OMAP5UEVM: http://slexy.org/view/s20MiQJQIq (external pinctrl not hooked)

Rajendra Nayak (3):
  ARM: OMAP5 / DRA7: PM: Avoid all SAR saves
  ARM: OMAP5 / DRA7: Enable CPU RET on suspend
  ARM: DRA7: Add hook in SoC initcalls to enable pm initialization

Santosh Shilimkar (7):
  ARM: OMAP5 / DRA7: PM: Update CPU context register offset
  ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency
  ARM: OMAP5 / DRA7: PM / wakeupgen: Enables ES2 PM mode by default
  ARM: OMAP5 / DRA7: PM: Enable Mercury retention mode on CPUx
    powerdomains
  ARM: OMAP5 / DRA7: PM: Provide a dummy startup function for CPU
    hotplug
  ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
  ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization

 arch/arm/mach-omap2/common.h              |    2 +-
 arch/arm/mach-omap2/cpuidle44xx.c         |   82 ++++++++++++++++++++++-
 arch/arm/mach-omap2/io.c                  |    6 ++
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |  102 ++++++++++++++++++++---------
 arch/arm/mach-omap2/omap-secure.h         |    1 +
 arch/arm/mach-omap2/omap-wakeupgen.c      |   19 +++++-
 arch/arm/mach-omap2/omap-wakeupgen.h      |    1 +
 arch/arm/mach-omap2/pm44xx.c              |   47 +++++++++++--
 8 files changed, 220 insertions(+), 40 deletions(-)

-- 
1.7.9.5

[PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Nishanth Menon]

The following series are various fixes and improvements for
supporting suspend-to-ram. This depends on the following for basic functionality:
series 1/6 where powerdomain fixes were involved.
This will at least allow wake up from an internal source such as from a wakeup timer:
For example with https://github.com/nmenon/linux-2.6-playground/commit/92e5e7407aa707ad6be8ae3b5bf21cfc741daab6

pinctrl series allows for external wakeup event sources like pushbutton etc.

NOTE: OMAP5 and DRA7 definitions of power states and suspend targets
are almost identical (except for core power domain target state as part of suspend).

NOTE: This also needs missing hwmod and dts entries for various
peripherals that will eventually arrive over a period of time.

This is part 5/6 series which actually enables framework for
suspend-to-ram and cpuidle for OMAP5 and DRA7

Each of series is based on v3.17-rc1 and this specific series is available:
weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/v3.17/powerdomain-fixes

git repo: https://github.com/nmenon/linux-2.6-playground.git push/v3.17/powerdomain-fixes

An complete integrated branch is available here: https://github.com/nmenon/linux-2.6-playground/commits/testing/v3.17/cpu-idle-suspend-dra7-omap5-framework

Example test log:
DRA7 based BeagleBoard X15: http://slexy.org/view/s2jgsH8bos (wakeup from external using pinctrl wakeup).
OMAP5UEVM: http://slexy.org/view/s20MiQJQIq (external pinctrl not hooked)

Rajendra Nayak (3):
  ARM: OMAP5 / DRA7: PM: Avoid all SAR saves
  ARM: OMAP5 / DRA7: Enable CPU RET on suspend
  ARM: DRA7: Add hook in SoC initcalls to enable pm initialization

Santosh Shilimkar (7):
  ARM: OMAP5 / DRA7: PM: Update CPU context register offset
  ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency
  ARM: OMAP5 / DRA7: PM / wakeupgen: Enables ES2 PM mode by default
  ARM: OMAP5 / DRA7: PM: Enable Mercury retention mode on CPUx
    powerdomains
  ARM: OMAP5 / DRA7: PM: Provide a dummy startup function for CPU
    hotplug
  ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
  ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization

 arch/arm/mach-omap2/common.h              |    2 +-
 arch/arm/mach-omap2/cpuidle44xx.c         |   82 ++++++++++++++++++++++-
 arch/arm/mach-omap2/io.c                  |    6 ++
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |  102 ++++++++++++++++++++---------
 arch/arm/mach-omap2/omap-secure.h         |    1 +
 arch/arm/mach-omap2/omap-wakeupgen.c      |   19 +++++-
 arch/arm/mach-omap2/omap-wakeupgen.h      |    1 +
 arch/arm/mach-omap2/pm44xx.c              |   47 +++++++++++--
 8 files changed, 220 insertions(+), 40 deletions(-)

-- 
1.7.9.5

[PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Nishanth Menon]

The following series are various fixes and improvements for
supporting suspend-to-ram. This depends on the following for basic functionality:
series 1/6 where powerdomain fixes were involved.
This will at least allow wake up from an internal source such as from a wakeup timer:
For example with https://github.com/nmenon/linux-2.6-playground/commit/92e5e7407aa707ad6be8ae3b5bf21cfc741daab6

pinctrl series allows for external wakeup event sources like pushbutton etc.

NOTE: OMAP5 and DRA7 definitions of power states and suspend targets
are almost identical (except for core power domain target state as part of suspend).

NOTE: This also needs missing hwmod and dts entries for various
peripherals that will eventually arrive over a period of time.

This is part 5/6 series which actually enables framework for
suspend-to-ram and cpuidle for OMAP5 and DRA7

Each of series is based on v3.17-rc1 and this specific series is available:
weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/v3.17/powerdomain-fixes

git repo: https://github.com/nmenon/linux-2.6-playground.git push/v3.17/powerdomain-fixes

An complete integrated branch is available here: https://github.com/nmenon/linux-2.6-playground/commits/testing/v3.17/cpu-idle-suspend-dra7-omap5-framework

Example test log:
DRA7 based BeagleBoard X15: http://slexy.org/view/s2jgsH8bos (wakeup from external using pinctrl wakeup).
OMAP5UEVM: http://slexy.org/view/s20MiQJQIq (external pinctrl not hooked)

Rajendra Nayak (3):
  ARM: OMAP5 / DRA7: PM: Avoid all SAR saves
  ARM: OMAP5 / DRA7: Enable CPU RET on suspend
  ARM: DRA7: Add hook in SoC initcalls to enable pm initialization

Santosh Shilimkar (7):
  ARM: OMAP5 / DRA7: PM: Update CPU context register offset
  ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency
  ARM: OMAP5 / DRA7: PM / wakeupgen: Enables ES2 PM mode by default
  ARM: OMAP5 / DRA7: PM: Enable Mercury retention mode on CPUx
    powerdomains
  ARM: OMAP5 / DRA7: PM: Provide a dummy startup function for CPU
    hotplug
  ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
  ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization

 arch/arm/mach-omap2/common.h              |    2 +-
 arch/arm/mach-omap2/cpuidle44xx.c         |   82 ++++++++++++++++++++++-
 arch/arm/mach-omap2/io.c                  |    6 ++
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |  102 ++++++++++++++++++++---------
 arch/arm/mach-omap2/omap-secure.h         |    1 +
 arch/arm/mach-omap2/omap-wakeupgen.c      |   19 +++++-
 arch/arm/mach-omap2/omap-wakeupgen.h      |    1 +
 arch/arm/mach-omap2/pm44xx.c              |   47 +++++++++++--
 8 files changed, 220 insertions(+), 40 deletions(-)

-- 
1.7.9.5

[PATCH 01/10] ARM: OMAP5 / DRA7: PM: Update CPU context register offset

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

On OMAP5, RM_CPUi_CPUi_CONTEXT offset has changed. Update the code
so that same code works for OMAP4+ devices. DRA7 and OMAP5 have the same
context offset as well.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[rnayak@ti.com: for DRA7]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: rebase, split/merge etc..]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 4001325..63a1dd7 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -56,6 +56,7 @@
 #include "omap4-sar-layout.h"
 #include "pm.h"
 #include "prcm_mpu44xx.h"
+#include "prcm_mpu54xx.h"
 #include "prminst44xx.h"
 #include "prcm44xx.h"
 #include "prm44xx.h"
@@ -89,6 +90,7 @@ struct cpu_pm_ops {
 static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
 static struct powerdomain *mpuss_pd;
 static void __iomem *sar_base;
+static u32 cpu_context_offset;
 
 static int default_finish_suspend(unsigned long cpu_state)
 {
@@ -161,14 +163,14 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
 
 	if (cpu_id) {
 		reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU1_INST,
-					OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+					cpu_context_offset);
 		omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU1_INST,
-					OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+					cpu_context_offset);
 	} else {
 		reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU0_INST,
-					OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+					cpu_context_offset);
 		omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU0_INST,
-					OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+					cpu_context_offset);
 	}
 }
 
@@ -392,6 +394,9 @@ int __init omap4_mpuss_init(void)
 		omap_pm_ops.finish_suspend = omap4_finish_suspend;
 		omap_pm_ops.resume = omap4_cpu_resume;
 		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
+	} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
+		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
 	}
 
 	return 0;
-- 
1.7.9.5

[PATCH 01/10] ARM: OMAP5 / DRA7: PM: Update CPU context register offset

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

On OMAP5, RM_CPUi_CPUi_CONTEXT offset has changed. Update the code
so that same code works for OMAP4+ devices. DRA7 and OMAP5 have the same
context offset as well.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[rnayak@ti.com: for DRA7]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: rebase, split/merge etc..]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 4001325..63a1dd7 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -56,6 +56,7 @@
 #include "omap4-sar-layout.h"
 #include "pm.h"
 #include "prcm_mpu44xx.h"
+#include "prcm_mpu54xx.h"
 #include "prminst44xx.h"
 #include "prcm44xx.h"
 #include "prm44xx.h"
@@ -89,6 +90,7 @@ struct cpu_pm_ops {
 static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
 static struct powerdomain *mpuss_pd;
 static void __iomem *sar_base;
+static u32 cpu_context_offset;
 
 static int default_finish_suspend(unsigned long cpu_state)
 {
@@ -161,14 +163,14 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
 
 	if (cpu_id) {
 		reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU1_INST,
-					OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+					cpu_context_offset);
 		omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU1_INST,
-					OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+					cpu_context_offset);
 	} else {
 		reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU0_INST,
-					OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+					cpu_context_offset);
 		omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU0_INST,
-					OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+					cpu_context_offset);
 	}
 }
 
@@ -392,6 +394,9 @@ int __init omap4_mpuss_init(void)
 		omap_pm_ops.finish_suspend = omap4_finish_suspend;
 		omap_pm_ops.resume = omap4_cpu_resume;
 		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
+	} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
+		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
 	}
 
 	return 0;
-- 
1.7.9.5

[PATCH 01/10] ARM: OMAP5 / DRA7: PM: Update CPU context register offset

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

On OMAP5, RM_CPUi_CPUi_CONTEXT offset has changed. Update the code
so that same code works for OMAP4+ devices. DRA7 and OMAP5 have the same
context offset as well.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[rnayak at ti.com: for DRA7]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm at ti.com: rebase, split/merge etc..]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 4001325..63a1dd7 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -56,6 +56,7 @@
 #include "omap4-sar-layout.h"
 #include "pm.h"
 #include "prcm_mpu44xx.h"
+#include "prcm_mpu54xx.h"
 #include "prminst44xx.h"
 #include "prcm44xx.h"
 #include "prm44xx.h"
@@ -89,6 +90,7 @@ struct cpu_pm_ops {
 static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
 static struct powerdomain *mpuss_pd;
 static void __iomem *sar_base;
+static u32 cpu_context_offset;
 
 static int default_finish_suspend(unsigned long cpu_state)
 {
@@ -161,14 +163,14 @@ static inline void cpu_clear_prev_logic_pwrst(unsigned int cpu_id)
 
 	if (cpu_id) {
 		reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU1_INST,
-					OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+					cpu_context_offset);
 		omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU1_INST,
-					OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET);
+					cpu_context_offset);
 	} else {
 		reg = omap4_prcm_mpu_read_inst_reg(OMAP4430_PRCM_MPU_CPU0_INST,
-					OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+					cpu_context_offset);
 		omap4_prcm_mpu_write_inst_reg(reg, OMAP4430_PRCM_MPU_CPU0_INST,
-					OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET);
+					cpu_context_offset);
 	}
 }
 
@@ -392,6 +394,9 @@ int __init omap4_mpuss_init(void)
 		omap_pm_ops.finish_suspend = omap4_finish_suspend;
 		omap_pm_ops.resume = omap4_cpu_resume;
 		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
+	} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
+		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
 	}
 
 	return 0;
-- 
1.7.9.5

[PATCH 02/10] ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

With EMIF clock-domain put under hardware supervised control, memory
corruption and untraceable crashes are observed on OMAP5. Further
investigation revealed that there is a weakness in the PRCM on this
specific dynamic depedency.

The recommendation is to set MPUSS static dependency towards EMIF
clock-domain to avoid issues. This recommendation holds good for DRA7
family of devices as well.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[rnayak@ti.com: DRA7]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: conflict resolution, dra7]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |   36 +++++++++++++++++++++++++++++++++---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 0dda6cf..b6f243d 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -203,6 +203,32 @@ static inline int omap4_init_static_deps(void)
 }
 
 /**
+ * omap5_dra7_init_static_deps - Init static clkdm dependencies on OMAP5 and
+ *				 DRA7
+ *
+ * The dynamic dependency between MPUSS -> EMIF is broken and has
+ * not worked as expected. The hardware recommendation is to
+ * enable static dependencies for these to avoid system
+ * lock ups or random crashes.
+ */
+static inline int omap5_dra7_init_static_deps(void)
+{
+	struct clockdomain *mpuss_clkdm, *emif_clkdm;
+	int ret;
+
+	mpuss_clkdm = clkdm_lookup("mpu_clkdm");
+	emif_clkdm = clkdm_lookup("emif_clkdm");
+	if (!mpuss_clkdm || !emif_clkdm)
+		return -EINVAL;
+
+	ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
+	if (ret)
+		pr_err("Failed to add MPUSS -> EMIF wakeup dependency\n");
+
+	return ret;
+}
+
+/**
  * omap4_pm_init_early - Does early initialization necessary for OMAP4+ devices
  *
  * Initializes basic stuff for power management functionality.
@@ -239,10 +265,14 @@ int __init omap4_pm_init(void)
 		goto err2;
 	}
 
-	if (cpu_is_omap44xx()) {
+	if (cpu_is_omap44xx())
 		ret = omap4_init_static_deps();
-		if (ret)
-			goto err2;
+	else if (soc_is_omap54xx() || soc_is_dra7xx())
+		ret = omap5_dra7_init_static_deps();
+
+	if (ret) {
+		pr_err("Failed to initialise static dependencies.\n");
+		goto err2;
 	}
 
 	ret = omap4_mpuss_init();
-- 
1.7.9.5

[PATCH 02/10] ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

With EMIF clock-domain put under hardware supervised control, memory
corruption and untraceable crashes are observed on OMAP5. Further
investigation revealed that there is a weakness in the PRCM on this
specific dynamic depedency.

The recommendation is to set MPUSS static dependency towards EMIF
clock-domain to avoid issues. This recommendation holds good for DRA7
family of devices as well.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[rnayak at ti.com: DRA7]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm at ti.com: conflict resolution, dra7]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |   36 +++++++++++++++++++++++++++++++++---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 0dda6cf..b6f243d 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -203,6 +203,32 @@ static inline int omap4_init_static_deps(void)
 }
 
 /**
+ * omap5_dra7_init_static_deps - Init static clkdm dependencies on OMAP5 and
+ *				 DRA7
+ *
+ * The dynamic dependency between MPUSS -> EMIF is broken and has
+ * not worked as expected. The hardware recommendation is to
+ * enable static dependencies for these to avoid system
+ * lock ups or random crashes.
+ */
+static inline int omap5_dra7_init_static_deps(void)
+{
+	struct clockdomain *mpuss_clkdm, *emif_clkdm;
+	int ret;
+
+	mpuss_clkdm = clkdm_lookup("mpu_clkdm");
+	emif_clkdm = clkdm_lookup("emif_clkdm");
+	if (!mpuss_clkdm || !emif_clkdm)
+		return -EINVAL;
+
+	ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
+	if (ret)
+		pr_err("Failed to add MPUSS -> EMIF wakeup dependency\n");
+
+	return ret;
+}
+
+/**
  * omap4_pm_init_early - Does early initialization necessary for OMAP4+ devices
  *
  * Initializes basic stuff for power management functionality.
@@ -239,10 +265,14 @@ int __init omap4_pm_init(void)
 		goto err2;
 	}
 
-	if (cpu_is_omap44xx()) {
+	if (cpu_is_omap44xx())
 		ret = omap4_init_static_deps();
-		if (ret)
-			goto err2;
+	else if (soc_is_omap54xx() || soc_is_dra7xx())
+		ret = omap5_dra7_init_static_deps();
+
+	if (ret) {
+		pr_err("Failed to initialise static dependencies.\n");
+		goto err2;
 	}
 
 	ret = omap4_mpuss_init();
-- 
1.7.9.5

[PATCH 03/10] ARM: OMAP5 / DRA7: PM / wakeupgen: Enables ES2 PM mode by default

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

Enables MPUSS ES2 power management mode using ES2_PM_MODE in
AMBA_IF_MODE register.

0x0: OMAP5 ES1 behavior, CPU cores would enter and exit OFF mode together.
     Broken! Fortunately, we do not support this anymore.
0x1: OMAP5 ES2, DRA7 behavior, CPU cores are allowed to enter/exit OFF mode
     independently.

This is one time settings thanks to always ON domain.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[nm@ti.com: minor conflict resolutions, consolidation for DRA7]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-secure.h    |    1 +
 arch/arm/mach-omap2/omap-wakeupgen.c |   17 +++++++++++++++++
 arch/arm/mach-omap2/omap-wakeupgen.h |    1 +
 3 files changed, 19 insertions(+)

diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 3e97c6c..dec2b05 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -45,6 +45,7 @@
 #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
 
 #define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX	0x109
+#define OMAP5_MON_AMBA_IF_INDEX		0x108
 
 /* Secure PPA(Primary Protected Application) APIs */
 #define OMAP4_PPA_L2_POR_INDEX		0x23
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index 37843a7..e844e16 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -406,6 +406,7 @@ int __init omap_wakeupgen_init(void)
 {
 	int i;
 	unsigned int boot_cpu = smp_processor_id();
+	u32 val;
 
 	/* Not supported on OMAP4 ES1.0 silicon */
 	if (omap_rev() == OMAP4430_REV_ES1_0) {
@@ -451,6 +452,22 @@ int __init omap_wakeupgen_init(void)
 	for (i = 0; i < max_irqs; i++)
 		irq_target_cpu[i] = boot_cpu;
 
+	/*
+	 * Enables OMAP5 ES2 PM Mode using ES2_PM_MODE in AMBA_IF_MODE
+	 * 0x0:	ES1 behavior, CPU cores would enter and exit OFF mode together.
+	 * 0x1:	ES2 behavior, CPU cores are allowed to enter/exit OFF mode
+	 * independently.
+	 * This needs to be set one time thanks to always ON domain.
+	 *
+	 * We do not support ES1 behavior anymore. OMAP5 is assumed to be
+	 * ES2.0, and the same is applicable for DRA7.
+	 */
+	if (soc_is_omap54xx() || soc_is_dra7xx()) {
+		val = __raw_readl(wakeupgen_base + OMAP_AMBA_IF_MODE);
+		val |= BIT(5);
+		omap_smc1(OMAP5_MON_AMBA_IF_INDEX, val);
+	}
+
 	irq_hotplug_init();
 	irq_pm_init();
 
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.h b/arch/arm/mach-omap2/omap-wakeupgen.h
index b0fd16f..b3c8ecc 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.h
+++ b/arch/arm/mach-omap2/omap-wakeupgen.h
@@ -27,6 +27,7 @@
 #define OMAP_WKG_ENB_E_1			0x420
 #define OMAP_AUX_CORE_BOOT_0			0x800
 #define OMAP_AUX_CORE_BOOT_1			0x804
+#define OMAP_AMBA_IF_MODE			0x80c
 #define OMAP_PTMSYNCREQ_MASK			0xc00
 #define OMAP_PTMSYNCREQ_EN			0xc04
 #define OMAP_TIMESTAMPCYCLELO			0xc08
-- 
1.7.9.5

[PATCH 03/10] ARM: OMAP5 / DRA7: PM / wakeupgen: Enables ES2 PM mode by default

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

Enables MPUSS ES2 power management mode using ES2_PM_MODE in
AMBA_IF_MODE register.

0x0: OMAP5 ES1 behavior, CPU cores would enter and exit OFF mode together.
     Broken! Fortunately, we do not support this anymore.
0x1: OMAP5 ES2, DRA7 behavior, CPU cores are allowed to enter/exit OFF mode
     independently.

This is one time settings thanks to always ON domain.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[nm at ti.com: minor conflict resolutions, consolidation for DRA7]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-secure.h    |    1 +
 arch/arm/mach-omap2/omap-wakeupgen.c |   17 +++++++++++++++++
 arch/arm/mach-omap2/omap-wakeupgen.h |    1 +
 3 files changed, 19 insertions(+)

diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 3e97c6c..dec2b05 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -45,6 +45,7 @@
 #define OMAP4_MON_L2X0_PREFETCH_INDEX	0x113
 
 #define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX	0x109
+#define OMAP5_MON_AMBA_IF_INDEX		0x108
 
 /* Secure PPA(Primary Protected Application) APIs */
 #define OMAP4_PPA_L2_POR_INDEX		0x23
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index 37843a7..e844e16 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -406,6 +406,7 @@ int __init omap_wakeupgen_init(void)
 {
 	int i;
 	unsigned int boot_cpu = smp_processor_id();
+	u32 val;
 
 	/* Not supported on OMAP4 ES1.0 silicon */
 	if (omap_rev() == OMAP4430_REV_ES1_0) {
@@ -451,6 +452,22 @@ int __init omap_wakeupgen_init(void)
 	for (i = 0; i < max_irqs; i++)
 		irq_target_cpu[i] = boot_cpu;
 
+	/*
+	 * Enables OMAP5 ES2 PM Mode using ES2_PM_MODE in AMBA_IF_MODE
+	 * 0x0:	ES1 behavior, CPU cores would enter and exit OFF mode together.
+	 * 0x1:	ES2 behavior, CPU cores are allowed to enter/exit OFF mode
+	 * independently.
+	 * This needs to be set one time thanks to always ON domain.
+	 *
+	 * We do not support ES1 behavior anymore. OMAP5 is assumed to be
+	 * ES2.0, and the same is applicable for DRA7.
+	 */
+	if (soc_is_omap54xx() || soc_is_dra7xx()) {
+		val = __raw_readl(wakeupgen_base + OMAP_AMBA_IF_MODE);
+		val |= BIT(5);
+		omap_smc1(OMAP5_MON_AMBA_IF_INDEX, val);
+	}
+
 	irq_hotplug_init();
 	irq_pm_init();
 
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.h b/arch/arm/mach-omap2/omap-wakeupgen.h
index b0fd16f..b3c8ecc 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.h
+++ b/arch/arm/mach-omap2/omap-wakeupgen.h
@@ -27,6 +27,7 @@
 #define OMAP_WKG_ENB_E_1			0x420
 #define OMAP_AUX_CORE_BOOT_0			0x800
 #define OMAP_AUX_CORE_BOOT_1			0x804
+#define OMAP_AMBA_IF_MODE			0x80c
 #define OMAP_PTMSYNCREQ_MASK			0xc00
 #define OMAP_PTMSYNCREQ_EN			0xc04
 #define OMAP_TIMESTAMPCYCLELO			0xc08
-- 
1.7.9.5

[PATCH 04/10] ARM: OMAP5 / DRA7: PM: Enable Mercury retention mode on CPUx powerdomains

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

In addition to the standard power-management technique, the OMAP5 / DRA7
MPU subsystem also employs an SR3-APG (mercury) power management
technology to reduce leakage.

It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
is controlled by the PRCM_MPU. Only "Fast-mode" is supported on the
OMAP5 and DRA7 family of processors.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[nm@ti.com: minor consolidation]
Signed-off-by: Nishanth Menon <nm@ti.com>
---

This has a minor checkpatch warning for aligning with '(', but that
when fixed results in over 80 char warning. So choose '(' check instead :D.

 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 63a1dd7..fad6e8c 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -321,6 +321,21 @@ int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
 
 
 /*
+ * Enable Mercury Fast HG retention mode by default.
+ */
+static void enable_mercury_retention_mode(void)
+{
+	u32 reg;
+
+	reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
+				  OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+	/* Enable HG_EN, HG_RAMPUP = fast mode */
+	reg |= BIT(24) | BIT(25);
+	omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
+				      OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+}
+
+/*
  * Initialise OMAP4 MPUSS
  */
 int __init omap4_mpuss_init(void)
@@ -397,6 +412,7 @@ int __init omap4_mpuss_init(void)
 		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
 	} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
 		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
+		enable_mercury_retention_mode();
 	}
 
 	return 0;
-- 
1.7.9.5

[PATCH 04/10] ARM: OMAP5 / DRA7: PM: Enable Mercury retention mode on CPUx powerdomains

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

In addition to the standard power-management technique, the OMAP5 / DRA7
MPU subsystem also employs an SR3-APG (mercury) power management
technology to reduce leakage.

It allows for full logic and memories retention on MPU_C0 and MPU_C1 and
is controlled by the PRCM_MPU. Only "Fast-mode" is supported on the
OMAP5 and DRA7 family of processors.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[nm at ti.com: minor consolidation]
Signed-off-by: Nishanth Menon <nm@ti.com>
---

This has a minor checkpatch warning for aligning with '(', but that
when fixed results in over 80 char warning. So choose '(' check instead :D.

 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 63a1dd7..fad6e8c 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -321,6 +321,21 @@ int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
 
 
 /*
+ * Enable Mercury Fast HG retention mode by default.
+ */
+static void enable_mercury_retention_mode(void)
+{
+	u32 reg;
+
+	reg = omap4_prcm_mpu_read_inst_reg(OMAP54XX_PRCM_MPU_DEVICE_INST,
+				  OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+	/* Enable HG_EN, HG_RAMPUP = fast mode */
+	reg |= BIT(24) | BIT(25);
+	omap4_prcm_mpu_write_inst_reg(reg, OMAP54XX_PRCM_MPU_DEVICE_INST,
+				      OMAP54XX_PRCM_MPU_PRM_PSCON_COUNT_OFFSET);
+}
+
+/*
  * Initialise OMAP4 MPUSS
  */
 int __init omap4_mpuss_init(void)
@@ -397,6 +412,7 @@ int __init omap4_mpuss_init(void)
 		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
 	} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
 		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
+		enable_mercury_retention_mode();
 	}
 
 	return 0;
-- 
1.7.9.5

[PATCH 05/10] ARM: OMAP5 / DRA7: PM: Avoid all SAR saves

[Nishanth Menon]

From: Rajendra Nayak <rnayak@ti.com>

Get rid of all assumptions about always having a sar base on *all*
OMAP4+ platforms. We dont need one on DRA7 and it is not necessary at
this point for OMAP5 either.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: Split and optimize]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   55 ++++++++++++++++++-----------
 1 file changed, 34 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index fad6e8c..53d8de5 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -118,7 +118,8 @@ static inline void set_cpu_wakeup_addr(unsigned int cpu_id, u32 addr)
 {
 	struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
 
-	writel_relaxed(addr, pm_info->wkup_sar_addr);
+	if (pm_info->wkup_sar_addr)
+		writel_relaxed(addr, pm_info->wkup_sar_addr);
 }
 
 /*
@@ -143,7 +144,8 @@ static void scu_pwrst_prepare(unsigned int cpu_id, unsigned int cpu_state)
 		break;
 	}
 
-	writel_relaxed(scu_pwr_st, pm_info->scu_sar_addr);
+	if (pm_info->scu_sar_addr)
+		writel_relaxed(scu_pwr_st, pm_info->scu_sar_addr);
 }
 
 /* Helper functions for MPUSS OSWR */
@@ -181,7 +183,8 @@ static void l2x0_pwrst_prepare(unsigned int cpu_id, unsigned int save_state)
 {
 	struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
 
-	writel_relaxed(save_state, pm_info->l2x0_sar_addr);
+	if (pm_info->l2x0_sar_addr)
+		writel_relaxed(save_state, pm_info->l2x0_sar_addr);
 }
 
 /*
@@ -191,10 +194,14 @@ static void l2x0_pwrst_prepare(unsigned int cpu_id, unsigned int save_state)
 #ifdef CONFIG_CACHE_L2X0
 static void __init save_l2x0_context(void)
 {
-	writel_relaxed(l2x0_saved_regs.aux_ctrl,
-		     sar_base + L2X0_AUXCTRL_OFFSET);
-	writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
-		     sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+	void __iomem *l2x0_base = omap4_get_l2cache_base();
+
+	if (l2x0_base && sar_base) {
+		writel_relaxed(l2x0_saved_regs.aux_ctrl,
+			       sar_base + L2X0_AUXCTRL_OFFSET);
+		writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
+			       sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+	}
 }
 #else
 static void __init save_l2x0_context(void)
@@ -347,13 +354,17 @@ int __init omap4_mpuss_init(void)
 		return -ENODEV;
 	}
 
-	sar_base = omap4_get_sar_ram_base();
+	if (cpu_is_omap44xx())
+		sar_base = omap4_get_sar_ram_base();
 
 	/* Initilaise per CPU PM information */
 	pm_info = &per_cpu(omap4_pm_info, 0x0);
-	pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
-	pm_info->wkup_sar_addr = sar_base + CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
-	pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
+	if (sar_base) {
+		pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
+		pm_info->wkup_sar_addr = sar_base +
+					CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+		pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
+	}
 	pm_info->pwrdm = pwrdm_lookup("cpu0_pwrdm");
 	if (!pm_info->pwrdm) {
 		pr_err("Lookup failed for CPU0 pwrdm\n");
@@ -368,9 +379,12 @@ int __init omap4_mpuss_init(void)
 	pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
 
 	pm_info = &per_cpu(omap4_pm_info, 0x1);
-	pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
-	pm_info->wkup_sar_addr = sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
-	pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
+	if (sar_base) {
+		pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
+		pm_info->wkup_sar_addr = sar_base +
+					CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+		pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
+	}
 	if (cpu_is_omap446x())
 		pm_info->secondary_startup = omap4460_secondary_startup;
 	else
@@ -397,13 +411,12 @@ int __init omap4_mpuss_init(void)
 	pwrdm_clear_all_prev_pwrst(mpuss_pd);
 	mpuss_clear_prev_logic_pwrst();
 
-	/* Save device type on scratchpad for low level code to use */
-	if (omap_type() != OMAP2_DEVICE_TYPE_GP)
-		writel_relaxed(1, sar_base + OMAP_TYPE_OFFSET);
-	else
-		writel_relaxed(0, sar_base + OMAP_TYPE_OFFSET);
-
-	save_l2x0_context();
+	if (sar_base) {
+		/* Save device type on scratchpad for low level code to use */
+		writel_relaxed((omap_type() != OMAP2_DEVICE_TYPE_GP) ? 1 : 0,
+			       sar_base + OMAP_TYPE_OFFSET);
+		save_l2x0_context();
+	}
 
 	if (cpu_is_omap44xx()) {
 		omap_pm_ops.finish_suspend = omap4_finish_suspend;
-- 
1.7.9.5

[PATCH 05/10] ARM: OMAP5 / DRA7: PM: Avoid all SAR saves

[Nishanth Menon]

From: Rajendra Nayak <rnayak@ti.com>

Get rid of all assumptions about always having a sar base on *all*
OMAP4+ platforms. We dont need one on DRA7 and it is not necessary at
this point for OMAP5 either.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: Split and optimize]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   55 ++++++++++++++++++-----------
 1 file changed, 34 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index fad6e8c..53d8de5 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -118,7 +118,8 @@ static inline void set_cpu_wakeup_addr(unsigned int cpu_id, u32 addr)
 {
 	struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
 
-	writel_relaxed(addr, pm_info->wkup_sar_addr);
+	if (pm_info->wkup_sar_addr)
+		writel_relaxed(addr, pm_info->wkup_sar_addr);
 }
 
 /*
@@ -143,7 +144,8 @@ static void scu_pwrst_prepare(unsigned int cpu_id, unsigned int cpu_state)
 		break;
 	}
 
-	writel_relaxed(scu_pwr_st, pm_info->scu_sar_addr);
+	if (pm_info->scu_sar_addr)
+		writel_relaxed(scu_pwr_st, pm_info->scu_sar_addr);
 }
 
 /* Helper functions for MPUSS OSWR */
@@ -181,7 +183,8 @@ static void l2x0_pwrst_prepare(unsigned int cpu_id, unsigned int save_state)
 {
 	struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
 
-	writel_relaxed(save_state, pm_info->l2x0_sar_addr);
+	if (pm_info->l2x0_sar_addr)
+		writel_relaxed(save_state, pm_info->l2x0_sar_addr);
 }
 
 /*
@@ -191,10 +194,14 @@ static void l2x0_pwrst_prepare(unsigned int cpu_id, unsigned int save_state)
 #ifdef CONFIG_CACHE_L2X0
 static void __init save_l2x0_context(void)
 {
-	writel_relaxed(l2x0_saved_regs.aux_ctrl,
-		     sar_base + L2X0_AUXCTRL_OFFSET);
-	writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
-		     sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+	void __iomem *l2x0_base = omap4_get_l2cache_base();
+
+	if (l2x0_base && sar_base) {
+		writel_relaxed(l2x0_saved_regs.aux_ctrl,
+			       sar_base + L2X0_AUXCTRL_OFFSET);
+		writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
+			       sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+	}
 }
 #else
 static void __init save_l2x0_context(void)
@@ -347,13 +354,17 @@ int __init omap4_mpuss_init(void)
 		return -ENODEV;
 	}
 
-	sar_base = omap4_get_sar_ram_base();
+	if (cpu_is_omap44xx())
+		sar_base = omap4_get_sar_ram_base();
 
 	/* Initilaise per CPU PM information */
 	pm_info = &per_cpu(omap4_pm_info, 0x0);
-	pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
-	pm_info->wkup_sar_addr = sar_base + CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
-	pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
+	if (sar_base) {
+		pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
+		pm_info->wkup_sar_addr = sar_base +
+					CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+		pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
+	}
 	pm_info->pwrdm = pwrdm_lookup("cpu0_pwrdm");
 	if (!pm_info->pwrdm) {
 		pr_err("Lookup failed for CPU0 pwrdm\n");
@@ -368,9 +379,12 @@ int __init omap4_mpuss_init(void)
 	pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
 
 	pm_info = &per_cpu(omap4_pm_info, 0x1);
-	pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
-	pm_info->wkup_sar_addr = sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
-	pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
+	if (sar_base) {
+		pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
+		pm_info->wkup_sar_addr = sar_base +
+					CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+		pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
+	}
 	if (cpu_is_omap446x())
 		pm_info->secondary_startup = omap4460_secondary_startup;
 	else
@@ -397,13 +411,12 @@ int __init omap4_mpuss_init(void)
 	pwrdm_clear_all_prev_pwrst(mpuss_pd);
 	mpuss_clear_prev_logic_pwrst();
 
-	/* Save device type on scratchpad for low level code to use */
-	if (omap_type() != OMAP2_DEVICE_TYPE_GP)
-		writel_relaxed(1, sar_base + OMAP_TYPE_OFFSET);
-	else
-		writel_relaxed(0, sar_base + OMAP_TYPE_OFFSET);
-
-	save_l2x0_context();
+	if (sar_base) {
+		/* Save device type on scratchpad for low level code to use */
+		writel_relaxed((omap_type() != OMAP2_DEVICE_TYPE_GP) ? 1 : 0,
+			       sar_base + OMAP_TYPE_OFFSET);
+		save_l2x0_context();
+	}
 
 	if (cpu_is_omap44xx()) {
 		omap_pm_ops.finish_suspend = omap4_finish_suspend;
-- 
1.7.9.5

[PATCH 05/10] ARM: OMAP5 / DRA7: PM: Avoid all SAR saves

[Nishanth Menon]

From: Rajendra Nayak <rnayak@ti.com>

Get rid of all assumptions about always having a sar base on *all*
OMAP4+ platforms. We dont need one on DRA7 and it is not necessary at
this point for OMAP5 either.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm at ti.com: Split and optimize]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   55 ++++++++++++++++++-----------
 1 file changed, 34 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index fad6e8c..53d8de5 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -118,7 +118,8 @@ static inline void set_cpu_wakeup_addr(unsigned int cpu_id, u32 addr)
 {
 	struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
 
-	writel_relaxed(addr, pm_info->wkup_sar_addr);
+	if (pm_info->wkup_sar_addr)
+		writel_relaxed(addr, pm_info->wkup_sar_addr);
 }
 
 /*
@@ -143,7 +144,8 @@ static void scu_pwrst_prepare(unsigned int cpu_id, unsigned int cpu_state)
 		break;
 	}
 
-	writel_relaxed(scu_pwr_st, pm_info->scu_sar_addr);
+	if (pm_info->scu_sar_addr)
+		writel_relaxed(scu_pwr_st, pm_info->scu_sar_addr);
 }
 
 /* Helper functions for MPUSS OSWR */
@@ -181,7 +183,8 @@ static void l2x0_pwrst_prepare(unsigned int cpu_id, unsigned int save_state)
 {
 	struct omap4_cpu_pm_info *pm_info = &per_cpu(omap4_pm_info, cpu_id);
 
-	writel_relaxed(save_state, pm_info->l2x0_sar_addr);
+	if (pm_info->l2x0_sar_addr)
+		writel_relaxed(save_state, pm_info->l2x0_sar_addr);
 }
 
 /*
@@ -191,10 +194,14 @@ static void l2x0_pwrst_prepare(unsigned int cpu_id, unsigned int save_state)
 #ifdef CONFIG_CACHE_L2X0
 static void __init save_l2x0_context(void)
 {
-	writel_relaxed(l2x0_saved_regs.aux_ctrl,
-		     sar_base + L2X0_AUXCTRL_OFFSET);
-	writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
-		     sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+	void __iomem *l2x0_base = omap4_get_l2cache_base();
+
+	if (l2x0_base && sar_base) {
+		writel_relaxed(l2x0_saved_regs.aux_ctrl,
+			       sar_base + L2X0_AUXCTRL_OFFSET);
+		writel_relaxed(l2x0_saved_regs.prefetch_ctrl,
+			       sar_base + L2X0_PREFETCH_CTRL_OFFSET);
+	}
 }
 #else
 static void __init save_l2x0_context(void)
@@ -347,13 +354,17 @@ int __init omap4_mpuss_init(void)
 		return -ENODEV;
 	}
 
-	sar_base = omap4_get_sar_ram_base();
+	if (cpu_is_omap44xx())
+		sar_base = omap4_get_sar_ram_base();
 
 	/* Initilaise per CPU PM information */
 	pm_info = &per_cpu(omap4_pm_info, 0x0);
-	pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
-	pm_info->wkup_sar_addr = sar_base + CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
-	pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
+	if (sar_base) {
+		pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
+		pm_info->wkup_sar_addr = sar_base +
+					CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+		pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
+	}
 	pm_info->pwrdm = pwrdm_lookup("cpu0_pwrdm");
 	if (!pm_info->pwrdm) {
 		pr_err("Lookup failed for CPU0 pwrdm\n");
@@ -368,9 +379,12 @@ int __init omap4_mpuss_init(void)
 	pwrdm_set_next_pwrst(pm_info->pwrdm, PWRDM_POWER_ON);
 
 	pm_info = &per_cpu(omap4_pm_info, 0x1);
-	pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
-	pm_info->wkup_sar_addr = sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
-	pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
+	if (sar_base) {
+		pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
+		pm_info->wkup_sar_addr = sar_base +
+					CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+		pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
+	}
 	if (cpu_is_omap446x())
 		pm_info->secondary_startup = omap4460_secondary_startup;
 	else
@@ -397,13 +411,12 @@ int __init omap4_mpuss_init(void)
 	pwrdm_clear_all_prev_pwrst(mpuss_pd);
 	mpuss_clear_prev_logic_pwrst();
 
-	/* Save device type on scratchpad for low level code to use */
-	if (omap_type() != OMAP2_DEVICE_TYPE_GP)
-		writel_relaxed(1, sar_base + OMAP_TYPE_OFFSET);
-	else
-		writel_relaxed(0, sar_base + OMAP_TYPE_OFFSET);
-
-	save_l2x0_context();
+	if (sar_base) {
+		/* Save device type on scratchpad for low level code to use */
+		writel_relaxed((omap_type() != OMAP2_DEVICE_TYPE_GP) ? 1 : 0,
+			       sar_base + OMAP_TYPE_OFFSET);
+		save_l2x0_context();
+	}
 
 	if (cpu_is_omap44xx()) {
 		omap_pm_ops.finish_suspend = omap4_finish_suspend;
-- 
1.7.9.5

[PATCH 06/10] ARM: OMAP5 / DRA7: PM: Provide a dummy startup function for CPU hotplug

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

Dont assume that all OMAP4+ code will be able to use OMAP4 hotplug
logic. On OMAP5, DRA7, we do not need this in place yet, also,
currently the CPU startup pointer is located in omap4_cpu_pm_info
instead of cpu_pm_ops.

So, isolate the function to hotplug_restart pointer in cpu_pm_ops
where it should have belonged, initalize them as per valid startup
pointers for OMAP4430/60 as in current logic, however provide
dummy_cpu_resume to be the startup location as well.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[nm@ti.com: split this out of original code and isolate it]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 53d8de5..207fce2 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -69,7 +69,6 @@ struct omap4_cpu_pm_info {
 	void __iomem *scu_sar_addr;
 	void __iomem *wkup_sar_addr;
 	void __iomem *l2x0_sar_addr;
-	void (*secondary_startup)(void);
 };
 
 /**
@@ -77,6 +76,7 @@ struct omap4_cpu_pm_info {
  * @finish_suspend:	CPU suspend finisher function pointer
  * @resume:		CPU resume function pointer
  * @scu_prepare:	CPU Snoop Control program function pointer
+ * @hotplug_restart:	CPU restart function pointer
  *
  * Structure holds functions pointer for CPU low power operations like
  * suspend, resume and scu programming.
@@ -85,6 +85,7 @@ struct cpu_pm_ops {
 	int (*finish_suspend)(unsigned long cpu_state);
 	void (*resume)(void);
 	void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+	void (*hotplug_restart)(void);
 };
 
 static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
@@ -108,6 +109,7 @@ struct cpu_pm_ops omap_pm_ops = {
 	.finish_suspend		= default_finish_suspend,
 	.resume			= dummy_cpu_resume,
 	.scu_prepare		= dummy_scu_prepare,
+	.hotplug_restart	= dummy_cpu_resume,
 };
 
 /*
@@ -312,7 +314,7 @@ int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
 
 	pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
 	pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
-	set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
+	set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.hotplug_restart));
 	omap_pm_ops.scu_prepare(cpu, power_state);
 
 	/*
@@ -385,10 +387,6 @@ int __init omap4_mpuss_init(void)
 					CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
 		pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
 	}
-	if (cpu_is_omap446x())
-		pm_info->secondary_startup = omap4460_secondary_startup;
-	else
-		pm_info->secondary_startup = omap4_secondary_startup;
 
 	pm_info->pwrdm = pwrdm_lookup("cpu1_pwrdm");
 	if (!pm_info->pwrdm) {
@@ -422,12 +420,16 @@ int __init omap4_mpuss_init(void)
 		omap_pm_ops.finish_suspend = omap4_finish_suspend;
 		omap_pm_ops.resume = omap4_cpu_resume;
 		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+		omap_pm_ops.hotplug_restart = omap4_secondary_startup;
 		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
 	} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
 		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
 		enable_mercury_retention_mode();
 	}
 
+	if (cpu_is_omap446x())
+		omap_pm_ops.hotplug_restart = omap4460_secondary_startup;
+
 	return 0;
 }
 
-- 
1.7.9.5

[PATCH 06/10] ARM: OMAP5 / DRA7: PM: Provide a dummy startup function for CPU hotplug

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

Dont assume that all OMAP4+ code will be able to use OMAP4 hotplug
logic. On OMAP5, DRA7, we do not need this in place yet, also,
currently the CPU startup pointer is located in omap4_cpu_pm_info
instead of cpu_pm_ops.

So, isolate the function to hotplug_restart pointer in cpu_pm_ops
where it should have belonged, initalize them as per valid startup
pointers for OMAP4430/60 as in current logic, however provide
dummy_cpu_resume to be the startup location as well.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[nm@ti.com: split this out of original code and isolate it]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 53d8de5..207fce2 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -69,7 +69,6 @@ struct omap4_cpu_pm_info {
 	void __iomem *scu_sar_addr;
 	void __iomem *wkup_sar_addr;
 	void __iomem *l2x0_sar_addr;
-	void (*secondary_startup)(void);
 };
 
 /**
@@ -77,6 +76,7 @@ struct omap4_cpu_pm_info {
  * @finish_suspend:	CPU suspend finisher function pointer
  * @resume:		CPU resume function pointer
  * @scu_prepare:	CPU Snoop Control program function pointer
+ * @hotplug_restart:	CPU restart function pointer
  *
  * Structure holds functions pointer for CPU low power operations like
  * suspend, resume and scu programming.
@@ -85,6 +85,7 @@ struct cpu_pm_ops {
 	int (*finish_suspend)(unsigned long cpu_state);
 	void (*resume)(void);
 	void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+	void (*hotplug_restart)(void);
 };
 
 static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
@@ -108,6 +109,7 @@ struct cpu_pm_ops omap_pm_ops = {
 	.finish_suspend		= default_finish_suspend,
 	.resume			= dummy_cpu_resume,
 	.scu_prepare		= dummy_scu_prepare,
+	.hotplug_restart	= dummy_cpu_resume,
 };
 
 /*
@@ -312,7 +314,7 @@ int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
 
 	pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
 	pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
-	set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
+	set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.hotplug_restart));
 	omap_pm_ops.scu_prepare(cpu, power_state);
 
 	/*
@@ -385,10 +387,6 @@ int __init omap4_mpuss_init(void)
 					CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
 		pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
 	}
-	if (cpu_is_omap446x())
-		pm_info->secondary_startup = omap4460_secondary_startup;
-	else
-		pm_info->secondary_startup = omap4_secondary_startup;
 
 	pm_info->pwrdm = pwrdm_lookup("cpu1_pwrdm");
 	if (!pm_info->pwrdm) {
@@ -422,12 +420,16 @@ int __init omap4_mpuss_init(void)
 		omap_pm_ops.finish_suspend = omap4_finish_suspend;
 		omap_pm_ops.resume = omap4_cpu_resume;
 		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+		omap_pm_ops.hotplug_restart = omap4_secondary_startup;
 		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
 	} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
 		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
 		enable_mercury_retention_mode();
 	}
 
+	if (cpu_is_omap446x())
+		omap_pm_ops.hotplug_restart = omap4460_secondary_startup;
+
 	return 0;
 }
 
-- 
1.7.9.5

[PATCH 06/10] ARM: OMAP5 / DRA7: PM: Provide a dummy startup function for CPU hotplug

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

Dont assume that all OMAP4+ code will be able to use OMAP4 hotplug
logic. On OMAP5, DRA7, we do not need this in place yet, also,
currently the CPU startup pointer is located in omap4_cpu_pm_info
instead of cpu_pm_ops.

So, isolate the function to hotplug_restart pointer in cpu_pm_ops
where it should have belonged, initalize them as per valid startup
pointers for OMAP4430/60 as in current logic, however provide
dummy_cpu_resume to be the startup location as well.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[nm at ti.com: split this out of original code and isolate it]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 53d8de5..207fce2 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -69,7 +69,6 @@ struct omap4_cpu_pm_info {
 	void __iomem *scu_sar_addr;
 	void __iomem *wkup_sar_addr;
 	void __iomem *l2x0_sar_addr;
-	void (*secondary_startup)(void);
 };
 
 /**
@@ -77,6 +76,7 @@ struct omap4_cpu_pm_info {
  * @finish_suspend:	CPU suspend finisher function pointer
  * @resume:		CPU resume function pointer
  * @scu_prepare:	CPU Snoop Control program function pointer
+ * @hotplug_restart:	CPU restart function pointer
  *
  * Structure holds functions pointer for CPU low power operations like
  * suspend, resume and scu programming.
@@ -85,6 +85,7 @@ struct cpu_pm_ops {
 	int (*finish_suspend)(unsigned long cpu_state);
 	void (*resume)(void);
 	void (*scu_prepare)(unsigned int cpu_id, unsigned int cpu_state);
+	void (*hotplug_restart)(void);
 };
 
 static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
@@ -108,6 +109,7 @@ struct cpu_pm_ops omap_pm_ops = {
 	.finish_suspend		= default_finish_suspend,
 	.resume			= dummy_cpu_resume,
 	.scu_prepare		= dummy_scu_prepare,
+	.hotplug_restart	= dummy_cpu_resume,
 };
 
 /*
@@ -312,7 +314,7 @@ int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)
 
 	pwrdm_clear_all_prev_pwrst(pm_info->pwrdm);
 	pwrdm_set_next_pwrst(pm_info->pwrdm, power_state);
-	set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info->secondary_startup));
+	set_cpu_wakeup_addr(cpu, virt_to_phys(omap_pm_ops.hotplug_restart));
 	omap_pm_ops.scu_prepare(cpu, power_state);
 
 	/*
@@ -385,10 +387,6 @@ int __init omap4_mpuss_init(void)
 					CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
 		pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
 	}
-	if (cpu_is_omap446x())
-		pm_info->secondary_startup = omap4460_secondary_startup;
-	else
-		pm_info->secondary_startup = omap4_secondary_startup;
 
 	pm_info->pwrdm = pwrdm_lookup("cpu1_pwrdm");
 	if (!pm_info->pwrdm) {
@@ -422,12 +420,16 @@ int __init omap4_mpuss_init(void)
 		omap_pm_ops.finish_suspend = omap4_finish_suspend;
 		omap_pm_ops.resume = omap4_cpu_resume;
 		omap_pm_ops.scu_prepare = scu_pwrst_prepare;
+		omap_pm_ops.hotplug_restart = omap4_secondary_startup;
 		cpu_context_offset = OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET;
 	} else if (soc_is_omap54xx() || soc_is_dra7xx()) {
 		cpu_context_offset = OMAP54XX_RM_CPU0_CPU0_CONTEXT_OFFSET;
 		enable_mercury_retention_mode();
 	}
 
+	if (cpu_is_omap446x())
+		omap_pm_ops.hotplug_restart = omap4460_secondary_startup;
+
 	return 0;
 }
 
-- 
1.7.9.5

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

From: Rajendra Nayak <rnayak@ti.com>

On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
 arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
 arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
 		save_state = 1;
 		break;
 	case PWRDM_POWER_RET:
+		if (soc_is_omap54xx() || soc_is_dra7xx()) {
+			save_state = 0;
+			break;
+		}
 	default:
 		/*
 		 * CPUx CSWR is invalid hardware state. Also CPUx OSWR
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index e844e16..87c1c0d 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -381,7 +381,7 @@ static struct notifier_block irq_notifier_block = {
 static void __init irq_pm_init(void)
 {
 	/* FIXME: Remove this when MPU OSWR support is added */
-	if (!soc_is_omap54xx())
+	if (!soc_is_omap54xx() && !soc_is_dra7xx())
 		cpu_pm_register_notifier(&irq_notifier_block);
 }
 #else
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index b6f243d..c063833 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -36,6 +36,8 @@ struct power_state {
 	struct list_head node;
 };
 
+static u32 cpu_suspend_state = PWRDM_POWER_OFF;
+
 static LIST_HEAD(pwrst_list);
 
 #ifdef CONFIG_SUSPEND
@@ -66,7 +68,7 @@ static int omap4_pm_suspend(void)
 	 * domain CSWR is not supported by hardware.
 	 * More details can be found in OMAP4430 TRM section 4.3.4.2.
 	 */
-	omap4_enter_lowpower(cpu_id, PWRDM_POWER_OFF);
+	omap4_enter_lowpower(cpu_id, cpu_suspend_state);
 
 	/* Restore next powerdomain state */
 	list_for_each_entry(pwrst, &pwrst_list, node) {
@@ -112,8 +114,11 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 	 * through hotplug path and CPU0 explicitly programmed
 	 * further down in the code path
 	 */
-	if (!strncmp(pwrdm->name, "cpu", 3))
+	if (!strncmp(pwrdm->name, "cpu", 3)) {
+		if (soc_is_omap54xx() || soc_is_dra7xx())
+			cpu_suspend_state = PWRDM_POWER_RET;
 		return 0;
+	}
 
 	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
 	if (!pwrst)
-- 
1.7.9.5

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

From: Rajendra Nayak <rnayak@ti.com>

On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm at ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
 arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
 arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
 		save_state = 1;
 		break;
 	case PWRDM_POWER_RET:
+		if (soc_is_omap54xx() || soc_is_dra7xx()) {
+			save_state = 0;
+			break;
+		}
 	default:
 		/*
 		 * CPUx CSWR is invalid hardware state. Also CPUx OSWR
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index e844e16..87c1c0d 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -381,7 +381,7 @@ static struct notifier_block irq_notifier_block = {
 static void __init irq_pm_init(void)
 {
 	/* FIXME: Remove this when MPU OSWR support is added */
-	if (!soc_is_omap54xx())
+	if (!soc_is_omap54xx() && !soc_is_dra7xx())
 		cpu_pm_register_notifier(&irq_notifier_block);
 }
 #else
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index b6f243d..c063833 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -36,6 +36,8 @@ struct power_state {
 	struct list_head node;
 };
 
+static u32 cpu_suspend_state = PWRDM_POWER_OFF;
+
 static LIST_HEAD(pwrst_list);
 
 #ifdef CONFIG_SUSPEND
@@ -66,7 +68,7 @@ static int omap4_pm_suspend(void)
 	 * domain CSWR is not supported by hardware.
 	 * More details can be found in OMAP4430 TRM section 4.3.4.2.
 	 */
-	omap4_enter_lowpower(cpu_id, PWRDM_POWER_OFF);
+	omap4_enter_lowpower(cpu_id, cpu_suspend_state);
 
 	/* Restore next powerdomain state */
 	list_for_each_entry(pwrst, &pwrst_list, node) {
@@ -112,8 +114,11 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 	 * through hotplug path and CPU0 explicitly programmed
 	 * further down in the code path
 	 */
-	if (!strncmp(pwrdm->name, "cpu", 3))
+	if (!strncmp(pwrdm->name, "cpu", 3)) {
+		if (soc_is_omap54xx() || soc_is_dra7xx())
+			cpu_suspend_state = PWRDM_POWER_RET;
 		return 0;
+	}
 
 	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
 	if (!pwrst)
-- 
1.7.9.5

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

Add OMAP5/DRA74/72 CPUIDLE support.

This patch adds MPUSS low power states in cpuidle.

        C1 - CPU0 WFI + CPU1 WFI + MPU ON
        C2 - CPU0 RET + CPU1 RET + MPU CSWR

Tested on DRA74/72-EVM for C1 and C2 states.

NOTE: DRA7 does not do voltage scaling as part of retention transition
and has Mercury which speeds up transition paths - Latency numbers are
based on measurements done by toggling GPIOs.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[ j-keerthy@ti.com rework on 3.14]
Signed-off-by: Keerthy <j-keerthy@ti.com>
[nm@ti.com: updates based on profiling, OMAP5 squashed]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/cpuidle44xx.c |   82 ++++++++++++++++++++++++++++++++++++-
 arch/arm/mach-omap2/pm44xx.c      |    2 +-
 2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 2498ab0..8ad4f44 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,6 +22,7 @@
 #include "common.h"
 #include "pm.h"
 #include "prm.h"
+#include "soc.h"
 #include "clockdomain.h"
 
 #define MAX_CPUS	2
@@ -31,6 +32,7 @@ struct idle_statedata {
 	u32 cpu_state;
 	u32 mpu_logic_state;
 	u32 mpu_state;
+	u32 mpu_state_vote;
 };
 
 static struct idle_statedata omap4_idle_data[] = {
@@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
 	},
 };
 
+static struct idle_statedata dra7_idle_data[] = {
+	{
+		.cpu_state = PWRDM_POWER_ON,
+		.mpu_state = PWRDM_POWER_ON,
+		.mpu_logic_state = PWRDM_POWER_ON,
+	},
+	{
+		.cpu_state = PWRDM_POWER_RET,
+		.mpu_state = PWRDM_POWER_RET,
+		.mpu_logic_state = PWRDM_POWER_RET,
+	},
+};
+
 static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
 static struct clockdomain *cpu_clkdm[MAX_CPUS];
 
 static atomic_t abort_barrier;
 static bool cpu_done[MAX_CPUS];
 static struct idle_statedata *state_ptr = &omap4_idle_data[0];
+static DEFINE_RAW_SPINLOCK(mpu_lock);
 
 /* Private functions */
 
@@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
 	return index;
 }
 
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+			       struct cpuidle_driver *drv,
+			       int index)
+{
+	struct idle_statedata *cx = state_ptr + index;
+	unsigned long flag;
+
+	raw_spin_lock_irqsave(&mpu_lock, flag);
+	cx->mpu_state_vote++;
+	if (cx->mpu_state_vote == num_online_cpus()) {
+		pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
+		omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
+	}
+	raw_spin_unlock_irqrestore(&mpu_lock, flag);
+
+	omap4_enter_lowpower(dev->cpu, cx->cpu_state);
+
+	raw_spin_lock_irqsave(&mpu_lock, flag);
+	if (cx->mpu_state_vote == num_online_cpus())
+		omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+	cx->mpu_state_vote--;
+	raw_spin_unlock_irqrestore(&mpu_lock, flag);
+
+	return index;
+}
+
 static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 			struct cpuidle_driver *drv,
 			int index)
@@ -224,6 +266,34 @@ static struct cpuidle_driver omap4_idle_driver = {
 	.safe_state_index = 0,
 };
 
+static struct cpuidle_driver dra7_idle_driver = {
+	.name				= "dra7_idle",
+	.owner				= THIS_MODULE,
+	.states = {
+		{
+			/* C1 - CPU0 ON + CPU1 ON + MPU ON */
+			.exit_latency = 2 + 2,
+			.target_residency = 5,
+			.flags = CPUIDLE_FLAG_TIME_VALID,
+			.enter = omap_enter_idle_simple,
+			.name = "C1",
+			.desc = "CPUx WFI, MPUSS ON"
+		},
+		{
+			/* C2 - CPU0 RET + CPU1 RET + MPU CSWR */
+			.exit_latency = 48 + 60,
+			.target_residency = 100,
+			.flags = CPUIDLE_FLAG_TIME_VALID
+					| CPUIDLE_FLAG_TIMER_STOP,
+			.enter = omap_enter_idle_smp,
+			.name = "C2",
+			.desc = "CPUx CSWR, MPUSS CSWR",
+		},
+	},
+	.state_count = ARRAY_SIZE(dra7_idle_data),
+	.safe_state_index = 0,
+};
+
 /* Public functions */
 
 /**
@@ -234,6 +304,16 @@ static struct cpuidle_driver omap4_idle_driver = {
  */
 int __init omap4_idle_init(void)
 {
+	struct cpuidle_driver *idle_driver;
+
+	if (soc_is_dra7xx() || soc_is_omap54xx()) {
+		state_ptr = &dra7_idle_data[0];
+		idle_driver = &dra7_idle_driver;
+	} else {
+		state_ptr = &omap4_idle_data[0];
+		idle_driver = &omap4_idle_driver;
+	}
+
 	mpu_pd = pwrdm_lookup("mpu_pwrdm");
 	cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
 	cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
@@ -248,5 +328,5 @@ int __init omap4_idle_init(void)
 	/* Configure the broadcast timer on each cpu */
 	on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
 
-	return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
+	return cpuidle_register(idle_driver, cpu_online_mask);
 }
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c063833..1d22162 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -293,7 +293,7 @@ int __init omap4_pm_init(void)
 	/* Overwrite the default cpu_do_idle() */
 	arm_pm_idle = omap_default_idle;
 
-	if (cpu_is_omap44xx())
+	if (cpu_is_omap44xx() || soc_is_dra7xx() || soc_is_omap54xx())
 		omap4_idle_init();
 
 err2:
-- 
1.7.9.5

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

Add OMAP5/DRA74/72 CPUIDLE support.

This patch adds MPUSS low power states in cpuidle.

        C1 - CPU0 WFI + CPU1 WFI + MPU ON
        C2 - CPU0 RET + CPU1 RET + MPU CSWR

Tested on DRA74/72-EVM for C1 and C2 states.

NOTE: DRA7 does not do voltage scaling as part of retention transition
and has Mercury which speeds up transition paths - Latency numbers are
based on measurements done by toggling GPIOs.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[ j-keerthy at ti.com rework on 3.14]
Signed-off-by: Keerthy <j-keerthy@ti.com>
[nm at ti.com: updates based on profiling, OMAP5 squashed]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/cpuidle44xx.c |   82 ++++++++++++++++++++++++++++++++++++-
 arch/arm/mach-omap2/pm44xx.c      |    2 +-
 2 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index 2498ab0..8ad4f44 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,6 +22,7 @@
 #include "common.h"
 #include "pm.h"
 #include "prm.h"
+#include "soc.h"
 #include "clockdomain.h"
 
 #define MAX_CPUS	2
@@ -31,6 +32,7 @@ struct idle_statedata {
 	u32 cpu_state;
 	u32 mpu_logic_state;
 	u32 mpu_state;
+	u32 mpu_state_vote;
 };
 
 static struct idle_statedata omap4_idle_data[] = {
@@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
 	},
 };
 
+static struct idle_statedata dra7_idle_data[] = {
+	{
+		.cpu_state = PWRDM_POWER_ON,
+		.mpu_state = PWRDM_POWER_ON,
+		.mpu_logic_state = PWRDM_POWER_ON,
+	},
+	{
+		.cpu_state = PWRDM_POWER_RET,
+		.mpu_state = PWRDM_POWER_RET,
+		.mpu_logic_state = PWRDM_POWER_RET,
+	},
+};
+
 static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
 static struct clockdomain *cpu_clkdm[MAX_CPUS];
 
 static atomic_t abort_barrier;
 static bool cpu_done[MAX_CPUS];
 static struct idle_statedata *state_ptr = &omap4_idle_data[0];
+static DEFINE_RAW_SPINLOCK(mpu_lock);
 
 /* Private functions */
 
@@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
 	return index;
 }
 
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+			       struct cpuidle_driver *drv,
+			       int index)
+{
+	struct idle_statedata *cx = state_ptr + index;
+	unsigned long flag;
+
+	raw_spin_lock_irqsave(&mpu_lock, flag);
+	cx->mpu_state_vote++;
+	if (cx->mpu_state_vote == num_online_cpus()) {
+		pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
+		omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
+	}
+	raw_spin_unlock_irqrestore(&mpu_lock, flag);
+
+	omap4_enter_lowpower(dev->cpu, cx->cpu_state);
+
+	raw_spin_lock_irqsave(&mpu_lock, flag);
+	if (cx->mpu_state_vote == num_online_cpus())
+		omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+	cx->mpu_state_vote--;
+	raw_spin_unlock_irqrestore(&mpu_lock, flag);
+
+	return index;
+}
+
 static int omap_enter_idle_coupled(struct cpuidle_device *dev,
 			struct cpuidle_driver *drv,
 			int index)
@@ -224,6 +266,34 @@ static struct cpuidle_driver omap4_idle_driver = {
 	.safe_state_index = 0,
 };
 
+static struct cpuidle_driver dra7_idle_driver = {
+	.name				= "dra7_idle",
+	.owner				= THIS_MODULE,
+	.states = {
+		{
+			/* C1 - CPU0 ON + CPU1 ON + MPU ON */
+			.exit_latency = 2 + 2,
+			.target_residency = 5,
+			.flags = CPUIDLE_FLAG_TIME_VALID,
+			.enter = omap_enter_idle_simple,
+			.name = "C1",
+			.desc = "CPUx WFI, MPUSS ON"
+		},
+		{
+			/* C2 - CPU0 RET + CPU1 RET + MPU CSWR */
+			.exit_latency = 48 + 60,
+			.target_residency = 100,
+			.flags = CPUIDLE_FLAG_TIME_VALID
+					| CPUIDLE_FLAG_TIMER_STOP,
+			.enter = omap_enter_idle_smp,
+			.name = "C2",
+			.desc = "CPUx CSWR, MPUSS CSWR",
+		},
+	},
+	.state_count = ARRAY_SIZE(dra7_idle_data),
+	.safe_state_index = 0,
+};
+
 /* Public functions */
 
 /**
@@ -234,6 +304,16 @@ static struct cpuidle_driver omap4_idle_driver = {
  */
 int __init omap4_idle_init(void)
 {
+	struct cpuidle_driver *idle_driver;
+
+	if (soc_is_dra7xx() || soc_is_omap54xx()) {
+		state_ptr = &dra7_idle_data[0];
+		idle_driver = &dra7_idle_driver;
+	} else {
+		state_ptr = &omap4_idle_data[0];
+		idle_driver = &omap4_idle_driver;
+	}
+
 	mpu_pd = pwrdm_lookup("mpu_pwrdm");
 	cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
 	cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
@@ -248,5 +328,5 @@ int __init omap4_idle_init(void)
 	/* Configure the broadcast timer on each cpu */
 	on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
 
-	return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
+	return cpuidle_register(idle_driver, cpu_online_mask);
 }
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c063833..1d22162 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -293,7 +293,7 @@ int __init omap4_pm_init(void)
 	/* Overwrite the default cpu_do_idle() */
 	arm_pm_idle = omap_default_idle;
 
-	if (cpu_is_omap44xx())
+	if (cpu_is_omap44xx() || soc_is_dra7xx() || soc_is_omap54xx())
 		omap4_idle_init();
 
 err2:
-- 
1.7.9.5

[PATCH 09/10] ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

With consolidated code, now we can add the required hooks for
OMAP5 to enable power management.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[nm@ti.com: minor rebase updates]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
/home/nmenon/tmp/upstream/v3.17/cpuidle-suspend-support/0009-ARM-OMAP5-Add-hook-in-SoC-initcalls-to-enable-pm-ini.patch
 arch/arm/mach-omap2/common.h |    2 +-
 arch/arm/mach-omap2/io.c     |    3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index dc571f1..5bb1592 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -60,7 +60,7 @@ static inline int omap3_pm_init(void)
 }
 #endif
 
-#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5))
 int omap4_pm_init(void);
 int omap4_pm_init_early(void);
 #else
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 5d0667c..2890c2d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -667,6 +667,7 @@ void __init omap5_init_early(void)
 	omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE),
 			     OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE));
 	omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
+	omap4_pm_init_early();
 	omap_prm_base_init();
 	omap_cm_base_init();
 	omap44xx_prm_init();
@@ -682,6 +683,8 @@ void __init omap5_init_early(void)
 void __init omap5_init_late(void)
 {
 	omap_common_late_init();
+	omap4_pm_init();
+	omap2_clk_enable_autoidle_all();
 }
 #endif
 
-- 
1.7.9.5

[PATCH 09/10] ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization

[Nishanth Menon]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

With consolidated code, now we can add the required hooks for
OMAP5 to enable power management.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[nm at ti.com: minor rebase updates]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
/home/nmenon/tmp/upstream/v3.17/cpuidle-suspend-support/0009-ARM-OMAP5-Add-hook-in-SoC-initcalls-to-enable-pm-ini.patch
 arch/arm/mach-omap2/common.h |    2 +-
 arch/arm/mach-omap2/io.c     |    3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index dc571f1..5bb1592 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -60,7 +60,7 @@ static inline int omap3_pm_init(void)
 }
 #endif
 
-#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5))
 int omap4_pm_init(void);
 int omap4_pm_init_early(void);
 #else
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 5d0667c..2890c2d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -667,6 +667,7 @@ void __init omap5_init_early(void)
 	omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_AON_BASE),
 			     OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE));
 	omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
+	omap4_pm_init_early();
 	omap_prm_base_init();
 	omap_cm_base_init();
 	omap44xx_prm_init();
@@ -682,6 +683,8 @@ void __init omap5_init_early(void)
 void __init omap5_init_late(void)
 {
 	omap_common_late_init();
+	omap4_pm_init();
+	omap2_clk_enable_autoidle_all();
 }
 #endif
 
-- 
1.7.9.5

[PATCH 10/10] ARM: DRA7: Add hook in SoC initcalls to enable pm initialization

[Nishanth Menon]

From: Rajendra Nayak <rnayak@ti.com>

With consolidated code, now we can add the required hooks for
DRA7 to enable power management.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: minor modifications]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Note: Minor checkpatch warning exists for 80 char limit that was ignored.

 arch/arm/mach-omap2/common.h |    2 +-
 arch/arm/mach-omap2/io.c     |    3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 5bb1592..b6d2989 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -60,7 +60,7 @@ static inline int omap3_pm_init(void)
 }
 #endif
 
-#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5))
+#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX))
 int omap4_pm_init(void);
 int omap4_pm_init_early(void);
 #else
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2890c2d..831805e 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -698,6 +698,7 @@ void __init dra7xx_init_early(void)
 	omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(DRA7XX_CM_CORE_AON_BASE),
 			     OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE));
 	omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
+	omap4_pm_init_early();
 	omap_prm_base_init();
 	omap_cm_base_init();
 	omap44xx_prm_init();
@@ -712,6 +713,8 @@ void __init dra7xx_init_early(void)
 void __init dra7xx_init_late(void)
 {
 	omap_common_late_init();
+	omap4_pm_init();
+	omap2_clk_enable_autoidle_all();
 }
 #endif
 
-- 
1.7.9.5

[PATCH 10/10] ARM: DRA7: Add hook in SoC initcalls to enable pm initialization

[Nishanth Menon]

From: Rajendra Nayak <rnayak@ti.com>

With consolidated code, now we can add the required hooks for
DRA7 to enable power management.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: minor modifications]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Note: Minor checkpatch warning exists for 80 char limit that was ignored.

 arch/arm/mach-omap2/common.h |    2 +-
 arch/arm/mach-omap2/io.c     |    3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 5bb1592..b6d2989 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -60,7 +60,7 @@ static inline int omap3_pm_init(void)
 }
 #endif
 
-#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5))
+#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX))
 int omap4_pm_init(void);
 int omap4_pm_init_early(void);
 #else
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2890c2d..831805e 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -698,6 +698,7 @@ void __init dra7xx_init_early(void)
 	omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(DRA7XX_CM_CORE_AON_BASE),
 			     OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE));
 	omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
+	omap4_pm_init_early();
 	omap_prm_base_init();
 	omap_cm_base_init();
 	omap44xx_prm_init();
@@ -712,6 +713,8 @@ void __init dra7xx_init_early(void)
 void __init dra7xx_init_late(void)
 {
 	omap_common_late_init();
+	omap4_pm_init();
+	omap2_clk_enable_autoidle_all();
 }
 #endif
 
-- 
1.7.9.5

[PATCH 10/10] ARM: DRA7: Add hook in SoC initcalls to enable pm initialization

[Nishanth Menon]

From: Rajendra Nayak <rnayak@ti.com>

With consolidated code, now we can add the required hooks for
DRA7 to enable power management.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm at ti.com: minor modifications]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Note: Minor checkpatch warning exists for 80 char limit that was ignored.

 arch/arm/mach-omap2/common.h |    2 +-
 arch/arm/mach-omap2/io.c     |    3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 5bb1592..b6d2989 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -60,7 +60,7 @@ static inline int omap3_pm_init(void)
 }
 #endif
 
-#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5))
+#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX))
 int omap4_pm_init(void);
 int omap4_pm_init_early(void);
 #else
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2890c2d..831805e 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -698,6 +698,7 @@ void __init dra7xx_init_early(void)
 	omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(DRA7XX_CM_CORE_AON_BASE),
 			     OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE));
 	omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
+	omap4_pm_init_early();
 	omap_prm_base_init();
 	omap_cm_base_init();
 	omap44xx_prm_init();
@@ -712,6 +713,8 @@ void __init dra7xx_init_early(void)
 void __init dra7xx_init_late(void)
 {
 	omap_common_late_init();
+	omap4_pm_init();
+	omap2_clk_enable_autoidle_all();
 }
 #endif
 
-- 
1.7.9.5

Re: [PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Nishanth Menon]

On 08/22/2014 09:02 AM, Nishanth Menon wrote:
[...]
> An complete integrated branch is available here: https://github.com/nmenon/linux-2.6-playground/commits/testing/v3.17/cpu-idle-suspend-dra7-omap5-framework
> 
> Example test log:
> DRA7 based BeagleBoard X15: http://slexy.org/view/s2jgsH8bos (wakeup from external using pinctrl wakeup).
> OMAP5UEVM: http://slexy.org/view/s20MiQJQIq (external pinctrl not hooked)

Tony wanted a slightly wider test coverage including OMAP4 platforms:
So using
https://github.com/nmenon/linux-2.6-playground/commit/92e5e7407aa707ad6be8ae3b5bf21cfc741daab6
wakeup timer as a wakeup source (remote boards):

am37x-evm: http://slexy.org/raw/s2l2vPAlBi
BeagleBoard-XM: http://slexy.org/raw/s2HvJHuZ8K
beagleboard-vanilla: http://slexy.org/raw/s2re4CjsVS
n900: http://slexy.org/raw/s21kRad9UC
sdp3430: http://slexy.org/raw/s217hjHveS
pandaboard-es: http://slexy.org/raw/s21Vhfl96g
pandaboard-vanilla: http://slexy.org/raw/s21uPHllrR
sdp4430: http://slexy.org/raw/s20Jl3cika

Vs:
3.17-rc1:
am37x-evm: http://slexy.org/raw/s21FKtfXlb
BeagleBoard-XM: http://slexy.org/raw/s2q3LCSDkd
beagleboard-vanilla: http://slexy.org/raw/s21ioe8utf
n900: http://slexy.org/raw/s20E3oQhCl
sdp3430: http://slexy.org/raw/s21XQDe1s3
pandaboard-es: http://slexy.org/raw/s21DcS0IIt
pandaboard-vanilla: http://slexy.org/raw/s25W1A4JsP
sdp4430: http://slexy.org/raw/s2019HPstN

-- 
Regards,
Nishanth Menon

[PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Nishanth Menon]

On 08/22/2014 09:02 AM, Nishanth Menon wrote:
[...]
> An complete integrated branch is available here: https://github.com/nmenon/linux-2.6-playground/commits/testing/v3.17/cpu-idle-suspend-dra7-omap5-framework
> 
> Example test log:
> DRA7 based BeagleBoard X15: http://slexy.org/view/s2jgsH8bos (wakeup from external using pinctrl wakeup).
> OMAP5UEVM: http://slexy.org/view/s20MiQJQIq (external pinctrl not hooked)

Tony wanted a slightly wider test coverage including OMAP4 platforms:
So using
https://github.com/nmenon/linux-2.6-playground/commit/92e5e7407aa707ad6be8ae3b5bf21cfc741daab6
wakeup timer as a wakeup source (remote boards):

am37x-evm: http://slexy.org/raw/s2l2vPAlBi
BeagleBoard-XM: http://slexy.org/raw/s2HvJHuZ8K
beagleboard-vanilla: http://slexy.org/raw/s2re4CjsVS
n900: http://slexy.org/raw/s21kRad9UC
sdp3430: http://slexy.org/raw/s217hjHveS
pandaboard-es: http://slexy.org/raw/s21Vhfl96g
pandaboard-vanilla: http://slexy.org/raw/s21uPHllrR
sdp4430: http://slexy.org/raw/s20Jl3cika

Vs:
3.17-rc1:
am37x-evm: http://slexy.org/raw/s21FKtfXlb
BeagleBoard-XM: http://slexy.org/raw/s2q3LCSDkd
beagleboard-vanilla: http://slexy.org/raw/s21ioe8utf
n900: http://slexy.org/raw/s20E3oQhCl
sdp3430: http://slexy.org/raw/s21XQDe1s3
pandaboard-es: http://slexy.org/raw/s21DcS0IIt
pandaboard-vanilla: http://slexy.org/raw/s25W1A4JsP
sdp4430: http://slexy.org/raw/s2019HPstN

-- 
Regards,
Nishanth Menon

Re: [PATCH 02/10] ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> With EMIF clock-domain put under hardware supervised control, memory
> corruption and untraceable crashes are observed on OMAP5. Further
> investigation revealed that there is a weakness in the PRCM on this
> specific dynamic depedency.

hmm, "weakness".  That's a rather polite way of saying bug. :)

Kevin

[PATCH 02/10] ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> With EMIF clock-domain put under hardware supervised control, memory
> corruption and untraceable crashes are observed on OMAP5. Further
> investigation revealed that there is a weakness in the PRCM on this
> specific dynamic depedency.

hmm, "weakness".  That's a rather polite way of saying bug. :)

Kevin

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> From: Rajendra Nayak <rnayak@ti.com>
>
> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> and instead attempt a CPU RET and side effect, MPU RET in suspend.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> [nm@ti.com: update to do save_state only on DRA7]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
>  3 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index 207fce2..0d640eb 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>  		save_state = 1;
>  		break;
>  	case PWRDM_POWER_RET:
> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {

Aren't we trying to get away from these soc_* checks for anything other
than init code?

Kevin

> +			save_state = 0;
> +			break;
> +		}
>  	default:
>  		/*
>  		 * CPUx CSWR is invalid hardware state. Also CPUx OSWR
> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
> index e844e16..87c1c0d 100644
> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
> @@ -381,7 +381,7 @@ static struct notifier_block irq_notifier_block = {
>  static void __init irq_pm_init(void)
>  {
>  	/* FIXME: Remove this when MPU OSWR support is added */
> -	if (!soc_is_omap54xx())
> +	if (!soc_is_omap54xx() && !soc_is_dra7xx())
>  		cpu_pm_register_notifier(&irq_notifier_block);
>  }
>  #else
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index b6f243d..c063833 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -36,6 +36,8 @@ struct power_state {
>  	struct list_head node;
>  };
>  
> +static u32 cpu_suspend_state = PWRDM_POWER_OFF;
> +
>  static LIST_HEAD(pwrst_list);
>  
>  #ifdef CONFIG_SUSPEND
> @@ -66,7 +68,7 @@ static int omap4_pm_suspend(void)
>  	 * domain CSWR is not supported by hardware.
>  	 * More details can be found in OMAP4430 TRM section 4.3.4.2.
>  	 */
> -	omap4_enter_lowpower(cpu_id, PWRDM_POWER_OFF);
> +	omap4_enter_lowpower(cpu_id, cpu_suspend_state);
>  
>  	/* Restore next powerdomain state */
>  	list_for_each_entry(pwrst, &pwrst_list, node) {
> @@ -112,8 +114,11 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
>  	 * through hotplug path and CPU0 explicitly programmed
>  	 * further down in the code path
>  	 */
> -	if (!strncmp(pwrdm->name, "cpu", 3))
> +	if (!strncmp(pwrdm->name, "cpu", 3)) {
> +		if (soc_is_omap54xx() || soc_is_dra7xx())
> +			cpu_suspend_state = PWRDM_POWER_RET;
>  		return 0;
> +	}
>  
>  	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
>  	if (!pwrst)

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> From: Rajendra Nayak <rnayak@ti.com>
>
> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> and instead attempt a CPU RET and side effect, MPU RET in suspend.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> [nm at ti.com: update to do save_state only on DRA7]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
>  3 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index 207fce2..0d640eb 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>  		save_state = 1;
>  		break;
>  	case PWRDM_POWER_RET:
> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {

Aren't we trying to get away from these soc_* checks for anything other
than init code?

Kevin

> +			save_state = 0;
> +			break;
> +		}
>  	default:
>  		/*
>  		 * CPUx CSWR is invalid hardware state. Also CPUx OSWR
> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
> index e844e16..87c1c0d 100644
> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
> @@ -381,7 +381,7 @@ static struct notifier_block irq_notifier_block = {
>  static void __init irq_pm_init(void)
>  {
>  	/* FIXME: Remove this when MPU OSWR support is added */
> -	if (!soc_is_omap54xx())
> +	if (!soc_is_omap54xx() && !soc_is_dra7xx())
>  		cpu_pm_register_notifier(&irq_notifier_block);
>  }
>  #else
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index b6f243d..c063833 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -36,6 +36,8 @@ struct power_state {
>  	struct list_head node;
>  };
>  
> +static u32 cpu_suspend_state = PWRDM_POWER_OFF;
> +
>  static LIST_HEAD(pwrst_list);
>  
>  #ifdef CONFIG_SUSPEND
> @@ -66,7 +68,7 @@ static int omap4_pm_suspend(void)
>  	 * domain CSWR is not supported by hardware.
>  	 * More details can be found in OMAP4430 TRM section 4.3.4.2.
>  	 */
> -	omap4_enter_lowpower(cpu_id, PWRDM_POWER_OFF);
> +	omap4_enter_lowpower(cpu_id, cpu_suspend_state);
>  
>  	/* Restore next powerdomain state */
>  	list_for_each_entry(pwrst, &pwrst_list, node) {
> @@ -112,8 +114,11 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
>  	 * through hotplug path and CPU0 explicitly programmed
>  	 * further down in the code path
>  	 */
> -	if (!strncmp(pwrdm->name, "cpu", 3))
> +	if (!strncmp(pwrdm->name, "cpu", 3)) {
> +		if (soc_is_omap54xx() || soc_is_dra7xx())
> +			cpu_suspend_state = PWRDM_POWER_RET;
>  		return 0;
> +	}
>  
>  	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
>  	if (!pwrst)

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

On 08/27/2014 01:58 PM, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
> 
>> From: Rajendra Nayak <rnayak@ti.com>
>>
>> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
>> and instead attempt a CPU RET and side effect, MPU RET in suspend.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> [nm@ti.com: update to do save_state only on DRA7]
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
>>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
>>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
>>  3 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index 207fce2..0d640eb 100644
>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>>  		save_state = 1;
>>  		break;
>>  	case PWRDM_POWER_RET:
>> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
> 
> Aren't we trying to get away from these soc_* checks for anything other
> than init code?

I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.


-- 
Regards,
Nishanth Menon

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

On 08/27/2014 01:58 PM, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
> 
>> From: Rajendra Nayak <rnayak@ti.com>
>>
>> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
>> and instead attempt a CPU RET and side effect, MPU RET in suspend.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> [nm at ti.com: update to do save_state only on DRA7]
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
>>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
>>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
>>  3 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> index 207fce2..0d640eb 100644
>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>>  		save_state = 1;
>>  		break;
>>  	case PWRDM_POWER_RET:
>> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
> 
> Aren't we trying to get away from these soc_* checks for anything other
> than init code?

I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.


-- 
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Kevin Hilman]

+ Daniel (cpuidle maintainer)

Nishanth Menon <nm@ti.com> writes:

> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Add OMAP5/DRA74/72 CPUIDLE support.
>
> This patch adds MPUSS low power states in cpuidle.
>
>         C1 - CPU0 WFI + CPU1 WFI + MPU ON
>         C2 - CPU0 RET + CPU1 RET + MPU CSWR
>
> Tested on DRA74/72-EVM for C1 and C2 states.
>
> NOTE: DRA7 does not do voltage scaling as part of retention transition
> and has Mercury which speeds up transition paths - Latency numbers are
> based on measurements done by toggling GPIOs.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> [ j-keerthy@ti.com rework on 3.14]
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> [nm@ti.com: updates based on profiling, OMAP5 squashed]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>  arch/arm/mach-omap2/cpuidle44xx.c |   82 ++++++++++++++++++++++++++++++++++++-
>  arch/arm/mach-omap2/pm44xx.c      |    2 +-
>  2 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 2498ab0..8ad4f44 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -22,6 +22,7 @@
>  #include "common.h"
>  #include "pm.h"
>  #include "prm.h"
> +#include "soc.h"
>  #include "clockdomain.h"
>  
>  #define MAX_CPUS	2
> @@ -31,6 +32,7 @@ struct idle_statedata {
>  	u32 cpu_state;
>  	u32 mpu_logic_state;
>  	u32 mpu_state;
> +	u32 mpu_state_vote;
>  };
>  
>  static struct idle_statedata omap4_idle_data[] = {
> @@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
>  	},
>  };
>  
> +static struct idle_statedata dra7_idle_data[] = {
> +	{
> +		.cpu_state = PWRDM_POWER_ON,
> +		.mpu_state = PWRDM_POWER_ON,
> +		.mpu_logic_state = PWRDM_POWER_ON,
> +	},
> +	{
> +		.cpu_state = PWRDM_POWER_RET,
> +		.mpu_state = PWRDM_POWER_RET,
> +		.mpu_logic_state = PWRDM_POWER_RET,
> +	},
> +};
> +
>  static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
>  static struct clockdomain *cpu_clkdm[MAX_CPUS];
>  
>  static atomic_t abort_barrier;
>  static bool cpu_done[MAX_CPUS];
>  static struct idle_statedata *state_ptr = &omap4_idle_data[0];
> +static DEFINE_RAW_SPINLOCK(mpu_lock);
>  
>  /* Private functions */
>  
> @@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
>  	return index;
>  }
>  
> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> +			       struct cpuidle_driver *drv,
> +			       int index)
> +{
> +	struct idle_statedata *cx = state_ptr + index;
> +	unsigned long flag;
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);
> +	cx->mpu_state_vote++;
> +	if (cx->mpu_state_vote == num_online_cpus()) {
> +		pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> +		omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> +	}
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +	omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);
> +	if (cx->mpu_state_vote == num_online_cpus())
> +		omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> +	cx->mpu_state_vote--;
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +	return index;
> +}

Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?

Kevin

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Kevin Hilman]

+ Daniel (cpuidle maintainer)

Nishanth Menon <nm@ti.com> writes:

> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Add OMAP5/DRA74/72 CPUIDLE support.
>
> This patch adds MPUSS low power states in cpuidle.
>
>         C1 - CPU0 WFI + CPU1 WFI + MPU ON
>         C2 - CPU0 RET + CPU1 RET + MPU CSWR
>
> Tested on DRA74/72-EVM for C1 and C2 states.
>
> NOTE: DRA7 does not do voltage scaling as part of retention transition
> and has Mercury which speeds up transition paths - Latency numbers are
> based on measurements done by toggling GPIOs.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> [ j-keerthy at ti.com rework on 3.14]
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> [nm at ti.com: updates based on profiling, OMAP5 squashed]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>  arch/arm/mach-omap2/cpuidle44xx.c |   82 ++++++++++++++++++++++++++++++++++++-
>  arch/arm/mach-omap2/pm44xx.c      |    2 +-
>  2 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 2498ab0..8ad4f44 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -22,6 +22,7 @@
>  #include "common.h"
>  #include "pm.h"
>  #include "prm.h"
> +#include "soc.h"
>  #include "clockdomain.h"
>  
>  #define MAX_CPUS	2
> @@ -31,6 +32,7 @@ struct idle_statedata {
>  	u32 cpu_state;
>  	u32 mpu_logic_state;
>  	u32 mpu_state;
> +	u32 mpu_state_vote;
>  };
>  
>  static struct idle_statedata omap4_idle_data[] = {
> @@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
>  	},
>  };
>  
> +static struct idle_statedata dra7_idle_data[] = {
> +	{
> +		.cpu_state = PWRDM_POWER_ON,
> +		.mpu_state = PWRDM_POWER_ON,
> +		.mpu_logic_state = PWRDM_POWER_ON,
> +	},
> +	{
> +		.cpu_state = PWRDM_POWER_RET,
> +		.mpu_state = PWRDM_POWER_RET,
> +		.mpu_logic_state = PWRDM_POWER_RET,
> +	},
> +};
> +
>  static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
>  static struct clockdomain *cpu_clkdm[MAX_CPUS];
>  
>  static atomic_t abort_barrier;
>  static bool cpu_done[MAX_CPUS];
>  static struct idle_statedata *state_ptr = &omap4_idle_data[0];
> +static DEFINE_RAW_SPINLOCK(mpu_lock);
>  
>  /* Private functions */
>  
> @@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
>  	return index;
>  }
>  
> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> +			       struct cpuidle_driver *drv,
> +			       int index)
> +{
> +	struct idle_statedata *cx = state_ptr + index;
> +	unsigned long flag;
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);
> +	cx->mpu_state_vote++;
> +	if (cx->mpu_state_vote == num_online_cpus()) {
> +		pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> +		omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> +	}
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +	omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);
> +	if (cx->mpu_state_vote == num_online_cpus())
> +		omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> +	cx->mpu_state_vote--;
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +	return index;
> +}

Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?

Kevin

Re: [PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> The following series are various fixes and improvements for
> supporting suspend-to-ram. This depends on the following for basic functionality:
> series 1/6 where powerdomain fixes were involved.

I had a look through this series, and it looks good overall.  I think Daniel
needs to weigh in on the CPUidle driver, otherwise.

Reviewed-by: Kevin Hilman <khilman@linaro.org>

I also tested on omap5uevm with the pm_debug/wakeup_timer_seconds patch.

Tested-by: Kevin Hilman <khilman@linaro.org>

Kevin

[PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> The following series are various fixes and improvements for
> supporting suspend-to-ram. This depends on the following for basic functionality:
> series 1/6 where powerdomain fixes were involved.

I had a look through this series, and it looks good overall.  I think Daniel
needs to weigh in on the CPUidle driver, otherwise.

Reviewed-by: Kevin Hilman <khilman@linaro.org>

I also tested on omap5uevm with the pm_debug/wakeup_timer_seconds patch.

Tested-by: Kevin Hilman <khilman@linaro.org>

Kevin

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> + Daniel (cpuidle maintainer)
[...]
>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>> +                            struct cpuidle_driver *drv,
>> +                            int index)
>> +{
>> +     struct idle_statedata *cx = state_ptr + index;
>> +     unsigned long flag;
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>> +     cx->mpu_state_vote++;
>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>> +     }
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>> +
>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>> +     if (cx->mpu_state_vote == num_online_cpus())
>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>> +     cx->mpu_state_vote--;
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>> +
>> +     return index;
>> +}
>
> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?

Trying to understand benefit of MCPM here - at least without a deeper
understanding of mcpm infrastructure benefits (first look seemed a
little heavy for OMAP5/DRA7 needs).

Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
"OFF" of CPU1/0, we have mercury hardware to help with context and
sync issues.

Being able to reuse most of existing OMAP4 infrastructure code is
useful as well to leave the existing omap4 framework as being lighter
in complexity -esp in a cpuidle like hot path?

The spin_lock is only for the programming of MPU power domain in a
consistent manner - I suppose might have been the trigger for
proposing mcpm?

---
Regards,
Nishanth Menon

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> + Daniel (cpuidle maintainer)
[...]
>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>> +                            struct cpuidle_driver *drv,
>> +                            int index)
>> +{
>> +     struct idle_statedata *cx = state_ptr + index;
>> +     unsigned long flag;
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>> +     cx->mpu_state_vote++;
>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>> +     }
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>> +
>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>> +     if (cx->mpu_state_vote == num_online_cpus())
>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>> +     cx->mpu_state_vote--;
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>> +
>> +     return index;
>> +}
>
> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?

Trying to understand benefit of MCPM here - at least without a deeper
understanding of mcpm infrastructure benefits (first look seemed a
little heavy for OMAP5/DRA7 needs).

Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
"OFF" of CPU1/0, we have mercury hardware to help with context and
sync issues.

Being able to reuse most of existing OMAP4 infrastructure code is
useful as well to leave the existing omap4 framework as being lighter
in complexity -esp in a cpuidle like hot path?

The spin_lock is only for the programming of MPU power domain in a
consistent manner - I suppose might have been the trigger for
proposing mcpm?

---
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Santosh Shilimkar]

On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> + Daniel (cpuidle maintainer)
> [...]
>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>> +                            struct cpuidle_driver *drv,
>>> +                            int index)
>>> +{
>>> +     struct idle_statedata *cx = state_ptr + index;
>>> +     unsigned long flag;
>>> +
>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>> +     cx->mpu_state_vote++;
>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>>> +     }
>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>> +
>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>>> +
>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>> +     if (cx->mpu_state_vote == num_online_cpus())
>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>>> +     cx->mpu_state_vote--;
>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>> +
>>> +     return index;
>>> +}
>>
>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
> 
> Trying to understand benefit of MCPM here - at least without a deeper
> understanding of mcpm infrastructure benefits (first look seemed a
> little heavy for OMAP5/DRA7 needs).
> 
> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
> "OFF" of CPU1/0, we have mercury hardware to help with context and
> sync issues.
> 
> Being able to reuse most of existing OMAP4 infrastructure code is
> useful as well to leave the existing omap4 framework as being lighter
> in complexity -esp in a cpuidle like hot path?
> 
> The spin_lock is only for the programming of MPU power domain in a
> consistent manner - I suppose might have been the trigger for
> proposing mcpm?
> 
Mostly not....

I think this is coming because last time Nicolas Pitre tried to convert
the OMAP CPUIdle into MCPM but because of various ordering requirements,
OMAP wasn't suitable and then the plan was dropped later.

Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
remains the same for deeper states. Its just the mercury retention state
which we are able to enter without ordering requirements and hence
the voting scheme.

Hope this clarifies to you as well as Kevin just in case he missed the
part of the deeper C-states requirements.

Regards,
Santosh

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Santosh Shilimkar]

On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> + Daniel (cpuidle maintainer)
> [...]
>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>> +                            struct cpuidle_driver *drv,
>>> +                            int index)
>>> +{
>>> +     struct idle_statedata *cx = state_ptr + index;
>>> +     unsigned long flag;
>>> +
>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>> +     cx->mpu_state_vote++;
>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>>> +     }
>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>> +
>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>>> +
>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>> +     if (cx->mpu_state_vote == num_online_cpus())
>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>>> +     cx->mpu_state_vote--;
>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>> +
>>> +     return index;
>>> +}
>>
>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
> 
> Trying to understand benefit of MCPM here - at least without a deeper
> understanding of mcpm infrastructure benefits (first look seemed a
> little heavy for OMAP5/DRA7 needs).
> 
> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
> "OFF" of CPU1/0, we have mercury hardware to help with context and
> sync issues.
> 
> Being able to reuse most of existing OMAP4 infrastructure code is
> useful as well to leave the existing omap4 framework as being lighter
> in complexity -esp in a cpuidle like hot path?
> 
> The spin_lock is only for the programming of MPU power domain in a
> consistent manner - I suppose might have been the trigger for
> proposing mcpm?
> 
Mostly not....

I think this is coming because last time Nicolas Pitre tried to convert
the OMAP CPUIdle into MCPM but because of various ordering requirements,
OMAP wasn't suitable and then the plan was dropped later.

Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
remains the same for deeper states. Its just the mercury retention state
which we are able to enter without ordering requirements and hence
the voting scheme.

Hope this clarifies to you as well as Kevin just in case he missed the
part of the deeper C-states requirements.

Regards,
Santosh

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [140827 12:05]:
> On 08/27/2014 01:58 PM, Kevin Hilman wrote:
> > Nishanth Menon <nm@ti.com> writes:
> > 
> >> From: Rajendra Nayak <rnayak@ti.com>
> >>
> >> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> >> and instead attempt a CPU RET and side effect, MPU RET in suspend.
> >>
> >> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> >> [nm@ti.com: update to do save_state only on DRA7]
> >> Signed-off-by: Nishanth Menon <nm@ti.com>
> >> ---
> >>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
> >>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
> >>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
> >>  3 files changed, 12 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >> index 207fce2..0d640eb 100644
> >> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
> >>  		save_state = 1;
> >>  		break;
> >>  	case PWRDM_POWER_RET:
> >> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
> > 
> > Aren't we trying to get away from these soc_* checks for anything other
> > than init code?
> 
> I would expect that to take place in stages as part of which the next
> level of cleanup is to move PRM into drivers. Currently our wakeupgen,
> prm code does have quiet a few needs of dealing with soc_is checks
> primarily from having to re-architect code in two different directions
> - we want to move into just one direction eventually - to prm drivers
> and as less code in mach-omap2 which is already in the works.

Why don't you just set some flag at init time based on the
soc_is check and then test that here? That limits the use of
soc_is to init code only which makes it easier to phase it
out completely eventually.

Regards,

Tony

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [140827 12:05]:
> On 08/27/2014 01:58 PM, Kevin Hilman wrote:
> > Nishanth Menon <nm@ti.com> writes:
> > 
> >> From: Rajendra Nayak <rnayak@ti.com>
> >>
> >> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> >> and instead attempt a CPU RET and side effect, MPU RET in suspend.
> >>
> >> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> >> [nm at ti.com: update to do save_state only on DRA7]
> >> Signed-off-by: Nishanth Menon <nm@ti.com>
> >> ---
> >>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
> >>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
> >>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
> >>  3 files changed, 12 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >> index 207fce2..0d640eb 100644
> >> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
> >>  		save_state = 1;
> >>  		break;
> >>  	case PWRDM_POWER_RET:
> >> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
> > 
> > Aren't we trying to get away from these soc_* checks for anything other
> > than init code?
> 
> I would expect that to take place in stages as part of which the next
> level of cleanup is to move PRM into drivers. Currently our wakeupgen,
> prm code does have quiet a few needs of dealing with soc_is checks
> primarily from having to re-architect code in two different directions
> - we want to move into just one direction eventually - to prm drivers
> and as less code in mach-omap2 which is already in the works.

Why don't you just set some flag at init time based on the
soc_is check and then test that here? That limits the use of
soc_is to init code only which makes it easier to phase it
out completely eventually.

Regards,

Tony

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Santosh Shilimkar]

On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [140827 12:05]:
>> On 08/27/2014 01:58 PM, Kevin Hilman wrote:
>>> Nishanth Menon <nm@ti.com> writes:
>>>
>>>> From: Rajendra Nayak <rnayak@ti.com>
>>>>
>>>> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
>>>> and instead attempt a CPU RET and side effect, MPU RET in suspend.
>>>>
>>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>>>> [nm@ti.com: update to do save_state only on DRA7]
>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>> ---
>>>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
>>>>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
>>>>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
>>>>  3 files changed, 12 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>> index 207fce2..0d640eb 100644
>>>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>>>>  		save_state = 1;
>>>>  		break;
>>>>  	case PWRDM_POWER_RET:
>>>> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
>>>
>>> Aren't we trying to get away from these soc_* checks for anything other
>>> than init code?
>>
>> I would expect that to take place in stages as part of which the next
>> level of cleanup is to move PRM into drivers. Currently our wakeupgen,
>> prm code does have quiet a few needs of dealing with soc_is checks
>> primarily from having to re-architect code in two different directions
>> - we want to move into just one direction eventually - to prm drivers
>> and as less code in mach-omap2 which is already in the works.
> 
> Why don't you just set some flag at init time based on the
> soc_is check and then test that here? That limits the use of
> soc_is to init code only which makes it easier to phase it
> out completely eventually.
> 
Indeed. Infact the version of the code I tried posting last year was
using a flag which was initialised during init. Same can be
done her.

Regards,
Santosh

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Santosh Shilimkar]

On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [140827 12:05]:
>> On 08/27/2014 01:58 PM, Kevin Hilman wrote:
>>> Nishanth Menon <nm@ti.com> writes:
>>>
>>>> From: Rajendra Nayak <rnayak@ti.com>
>>>>
>>>> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
>>>> and instead attempt a CPU RET and side effect, MPU RET in suspend.
>>>>
>>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>>>> [nm at ti.com: update to do save_state only on DRA7]
>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>> ---
>>>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
>>>>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
>>>>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
>>>>  3 files changed, 12 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>> index 207fce2..0d640eb 100644
>>>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>>>>  		save_state = 1;
>>>>  		break;
>>>>  	case PWRDM_POWER_RET:
>>>> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
>>>
>>> Aren't we trying to get away from these soc_* checks for anything other
>>> than init code?
>>
>> I would expect that to take place in stages as part of which the next
>> level of cleanup is to move PRM into drivers. Currently our wakeupgen,
>> prm code does have quiet a few needs of dealing with soc_is checks
>> primarily from having to re-architect code in two different directions
>> - we want to move into just one direction eventually - to prm drivers
>> and as less code in mach-omap2 which is already in the works.
> 
> Why don't you just set some flag at init time based on the
> soc_is check and then test that here? That limits the use of
> soc_is to init code only which makes it easier to phase it
> out completely eventually.
> 
Indeed. Infact the version of the code I tried posting last year was
using a flag which was initialised during init. Same can be
done her.

Regards,
Santosh

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
> On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
>> * Nishanth Menon <nm@ti.com> [140827 12:05]:
>>> On 08/27/2014 01:58 PM, Kevin Hilman wrote:
>>>> Nishanth Menon <nm@ti.com> writes:
>>>>
>>>>> From: Rajendra Nayak <rnayak@ti.com>
>>>>>
>>>>> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
>>>>> and instead attempt a CPU RET and side effect, MPU RET in suspend.
>>>>>
>>>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>>>>> [nm@ti.com: update to do save_state only on DRA7]
>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>> ---
>>>>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
>>>>>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
>>>>>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
>>>>>  3 files changed, 12 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>>> index 207fce2..0d640eb 100644
>>>>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>>> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>>>>>  		save_state = 1;
>>>>>  		break;
>>>>>  	case PWRDM_POWER_RET:
>>>>> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
>>>>
>>>> Aren't we trying to get away from these soc_* checks for anything other
>>>> than init code?
>>>
>>> I would expect that to take place in stages as part of which the next
>>> level of cleanup is to move PRM into drivers. Currently our wakeupgen,
>>> prm code does have quiet a few needs of dealing with soc_is checks
>>> primarily from having to re-architect code in two different directions
>>> - we want to move into just one direction eventually - to prm drivers
>>> and as less code in mach-omap2 which is already in the works.
>>
>> Why don't you just set some flag at init time based on the
>> soc_is check and then test that here? That limits the use of
>> soc_is to init code only which makes it easier to phase it
>> out completely eventually.
>>
> Indeed. Infact the version of the code I tried posting last year was
> using a flag which was initialised during init. Same can be
> done her.

OK. will try something along that line in the next rev.


-- 
Regards,
Nishanth Menon

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
> On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
>> * Nishanth Menon <nm@ti.com> [140827 12:05]:
>>> On 08/27/2014 01:58 PM, Kevin Hilman wrote:
>>>> Nishanth Menon <nm@ti.com> writes:
>>>>
>>>>> From: Rajendra Nayak <rnayak@ti.com>
>>>>>
>>>>> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
>>>>> and instead attempt a CPU RET and side effect, MPU RET in suspend.
>>>>>
>>>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>>>>> [nm at ti.com: update to do save_state only on DRA7]
>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>> ---
>>>>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
>>>>>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
>>>>>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
>>>>>  3 files changed, 12 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>>> index 207fce2..0d640eb 100644
>>>>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
>>>>> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
>>>>>  		save_state = 1;
>>>>>  		break;
>>>>>  	case PWRDM_POWER_RET:
>>>>> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
>>>>
>>>> Aren't we trying to get away from these soc_* checks for anything other
>>>> than init code?
>>>
>>> I would expect that to take place in stages as part of which the next
>>> level of cleanup is to move PRM into drivers. Currently our wakeupgen,
>>> prm code does have quiet a few needs of dealing with soc_is checks
>>> primarily from having to re-architect code in two different directions
>>> - we want to move into just one direction eventually - to prm drivers
>>> and as less code in mach-omap2 which is already in the works.
>>
>> Why don't you just set some flag at init time based on the
>> soc_is check and then test that here? That limits the use of
>> soc_is to init code only which makes it easier to phase it
>> out completely eventually.
>>
> Indeed. Infact the version of the code I tried posting last year was
> using a flag which was initialised during init. Same can be
> done her.

OK. will try something along that line in the next rev.


-- 
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Kevin Hilman]

Santosh Shilimkar <santosh.shilimkar@ti.com> writes:

> On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
>> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>> + Daniel (cpuidle maintainer)
>> [...]
>>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>>> +                            struct cpuidle_driver *drv,
>>>> +                            int index)
>>>> +{
>>>> +     struct idle_statedata *cx = state_ptr + index;
>>>> +     unsigned long flag;
>>>> +
>>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>>> +     cx->mpu_state_vote++;
>>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>>>> +     }
>>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>>> +
>>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>>>> +
>>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>>> +     if (cx->mpu_state_vote == num_online_cpus())
>>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>>>> +     cx->mpu_state_vote--;
>>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>>> +
>>>> +     return index;
>>>> +}
>>>
>>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
>> 
>> Trying to understand benefit of MCPM here - at least without a deeper
>> understanding of mcpm infrastructure benefits (first look seemed a
>> little heavy for OMAP5/DRA7 needs).
>> 
>> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
>> "OFF" of CPU1/0, we have mercury hardware to help with context and
>> sync issues.
>> 
>> Being able to reuse most of existing OMAP4 infrastructure code is
>> useful as well to leave the existing omap4 framework as being lighter
>> in complexity -esp in a cpuidle like hot path?
>> 
>> The spin_lock is only for the programming of MPU power domain in a
>> consistent manner - I suppose might have been the trigger for
>> proposing mcpm?
>> 
> Mostly not....
>
> I think this is coming because last time Nicolas Pitre tried to convert
> the OMAP CPUIdle into MCPM but because of various ordering requirements,
> OMAP wasn't suitable and then the plan was dropped later.
>
> Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
> remains the same for deeper states. Its just the mercury retention state
> which we are able to enter without ordering requirements and hence
> the voting scheme.

Ah, OK.  This is the part that I'm missing.  So for deeper states you'll
need to be using omap_enter_idle_coupled()

> Hope this clarifies to you as well as Kevin just in case he missed the
> part of the deeper C-states requirements.

Yes, thanks for clarifying.

That being said, I think MCPM can now do essentially what the coupled
states code is doing. Even so, that's probably not a reason to hold up
this patch, but Daniel gets to make that call.

Kevin

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Kevin Hilman]

Santosh Shilimkar <santosh.shilimkar@ti.com> writes:

> On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
>> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>> + Daniel (cpuidle maintainer)
>> [...]
>>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>>> +                            struct cpuidle_driver *drv,
>>>> +                            int index)
>>>> +{
>>>> +     struct idle_statedata *cx = state_ptr + index;
>>>> +     unsigned long flag;
>>>> +
>>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>>> +     cx->mpu_state_vote++;
>>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>>>> +     }
>>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>>> +
>>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>>>> +
>>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>>> +     if (cx->mpu_state_vote == num_online_cpus())
>>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>>>> +     cx->mpu_state_vote--;
>>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>>> +
>>>> +     return index;
>>>> +}
>>>
>>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
>> 
>> Trying to understand benefit of MCPM here - at least without a deeper
>> understanding of mcpm infrastructure benefits (first look seemed a
>> little heavy for OMAP5/DRA7 needs).
>> 
>> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
>> "OFF" of CPU1/0, we have mercury hardware to help with context and
>> sync issues.
>> 
>> Being able to reuse most of existing OMAP4 infrastructure code is
>> useful as well to leave the existing omap4 framework as being lighter
>> in complexity -esp in a cpuidle like hot path?
>> 
>> The spin_lock is only for the programming of MPU power domain in a
>> consistent manner - I suppose might have been the trigger for
>> proposing mcpm?
>> 
> Mostly not....
>
> I think this is coming because last time Nicolas Pitre tried to convert
> the OMAP CPUIdle into MCPM but because of various ordering requirements,
> OMAP wasn't suitable and then the plan was dropped later.
>
> Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
> remains the same for deeper states. Its just the mercury retention state
> which we are able to enter without ordering requirements and hence
> the voting scheme.

Ah, OK.  This is the part that I'm missing.  So for deeper states you'll
need to be using omap_enter_idle_coupled()

> Hope this clarifies to you as well as Kevin just in case he missed the
> part of the deeper C-states requirements.

Yes, thanks for clarifying.

That being said, I think MCPM can now do essentially what the coupled
states code is doing. Even so, that's probably not a reason to hold up
this patch, but Daniel gets to make that call.

Kevin

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

On 14:45-20140827, Nishanth Menon wrote:
> On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
> > On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
> >> * Nishanth Menon <nm@ti.com> [140827 12:05]:
> >>> On 08/27/2014 01:58 PM, Kevin Hilman wrote:
> >>>> Nishanth Menon <nm@ti.com> writes:
> >>>>
> >>>>> From: Rajendra Nayak <rnayak@ti.com>
> >>>>>
> >>>>> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> >>>>> and instead attempt a CPU RET and side effect, MPU RET in suspend.
> >>>>>
> >>>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> >>>>> [nm@ti.com: update to do save_state only on DRA7]
> >>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
> >>>>> ---
> >>>>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
> >>>>>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
> >>>>>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
> >>>>>  3 files changed, 12 insertions(+), 3 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >>>>> index 207fce2..0d640eb 100644
> >>>>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >>>>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >>>>> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
> >>>>>  		save_state = 1;
> >>>>>  		break;
> >>>>>  	case PWRDM_POWER_RET:
> >>>>> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
> >>>>
> >>>> Aren't we trying to get away from these soc_* checks for anything other
> >>>> than init code?
> >>>
> >>> I would expect that to take place in stages as part of which the next
> >>> level of cleanup is to move PRM into drivers. Currently our wakeupgen,
> >>> prm code does have quiet a few needs of dealing with soc_is checks
> >>> primarily from having to re-architect code in two different directions
> >>> - we want to move into just one direction eventually - to prm drivers
> >>> and as less code in mach-omap2 which is already in the works.
> >>
> >> Why don't you just set some flag at init time based on the
> >> soc_is check and then test that here? That limits the use of
> >> soc_is to init code only which makes it easier to phase it
> >> out completely eventually.
> >>
> > Indeed. Infact the version of the code I tried posting last year was
> > using a flag which was initialised during init. Same can be
> > done her.
> 
> OK. will try something along that line in the next rev.


Hi,

Updated patch below:
Do let me know if this is ok with folks.

---8<----
>From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@ti.com>
Date: Mon, 27 May 2013 15:46:44 +0530
Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.

NOTE: the hardware was originally designed to be capable of achieving
deep power states such as OFF and OSWR, however due to various issues
and risks, deepest valid state was determined to be CSWR - hence we use
the errata framework to handle this case.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm@ti.com: updates]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
 arch/arm/mach-omap2/omap-wakeupgen.c      |    3 ++-
 arch/arm/mach-omap2/pm.h                  |    1 +
 arch/arm/mach-omap2/pm44xx.c              |   12 ++++++++++--
 4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..297352f 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
 		save_state = 1;
 		break;
 	case PWRDM_POWER_RET:
+		if (IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE)) {
+			save_state = 0;
+			break;
+		}
 	default:
 		/*
 		 * CPUx CSWR is invalid hardware state. Also CPUx OSWR
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index e844e16..f961c46 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -32,6 +32,7 @@
 #include "soc.h"
 #include "omap4-sar-layout.h"
 #include "common.h"
+#include "pm.h"
 
 #define AM43XX_NR_REG_BANKS	7
 #define AM43XX_IRQS		224
@@ -381,7 +382,7 @@ static struct notifier_block irq_notifier_block = {
 static void __init irq_pm_init(void)
 {
 	/* FIXME: Remove this when MPU OSWR support is added */
-	if (!soc_is_omap54xx())
+	if (!IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE))
 		cpu_pm_register_notifier(&irq_notifier_block);
 }
 #else
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index e150102..425bfcd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -101,6 +101,7 @@ static inline void enable_omap3630_toggle_l2_on_restore(void) { }
 #endif		/* defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3) */
 
 #define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD	(1 << 0)
+#define PM_OMAP4_CPU_OSWR_DISABLE		(1 << 1)
 
 #if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
 extern u16 pm44xx_errata;
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index b6f243d..64df620 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -36,6 +36,8 @@ struct power_state {
 	struct list_head node;
 };
 
+static u32 cpu_suspend_state = PWRDM_POWER_OFF;
+
 static LIST_HEAD(pwrst_list);
 
 #ifdef CONFIG_SUSPEND
@@ -66,7 +68,7 @@ static int omap4_pm_suspend(void)
 	 * domain CSWR is not supported by hardware.
 	 * More details can be found in OMAP4430 TRM section 4.3.4.2.
 	 */
-	omap4_enter_lowpower(cpu_id, PWRDM_POWER_OFF);
+	omap4_enter_lowpower(cpu_id, cpu_suspend_state);
 
 	/* Restore next powerdomain state */
 	list_for_each_entry(pwrst, &pwrst_list, node) {
@@ -112,8 +114,11 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 	 * through hotplug path and CPU0 explicitly programmed
 	 * further down in the code path
 	 */
-	if (!strncmp(pwrdm->name, "cpu", 3))
+	if (!strncmp(pwrdm->name, "cpu", 3)) {
+		if (IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE))
+			cpu_suspend_state = PWRDM_POWER_RET;
 		return 0;
+	}
 
 	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
 	if (!pwrst)
@@ -238,6 +243,9 @@ int __init omap4_pm_init_early(void)
 	if (cpu_is_omap446x())
 		pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
 
+	if (soc_is_omap54xx() || soc_is_dra7xx())
+		pm44xx_errata |= PM_OMAP4_CPU_OSWR_DISABLE;
+
 	return 0;
 }
 
-- 
1.7.9.5

-- 
Regards,
Nishanth Menon

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

On 14:45-20140827, Nishanth Menon wrote:
> On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
> > On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
> >> * Nishanth Menon <nm@ti.com> [140827 12:05]:
> >>> On 08/27/2014 01:58 PM, Kevin Hilman wrote:
> >>>> Nishanth Menon <nm@ti.com> writes:
> >>>>
> >>>>> From: Rajendra Nayak <rnayak@ti.com>
> >>>>>
> >>>>> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> >>>>> and instead attempt a CPU RET and side effect, MPU RET in suspend.
> >>>>>
> >>>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> >>>>> [nm at ti.com: update to do save_state only on DRA7]
> >>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
> >>>>> ---
> >>>>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
> >>>>>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
> >>>>>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
> >>>>>  3 files changed, 12 insertions(+), 3 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >>>>> index 207fce2..0d640eb 100644
> >>>>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >>>>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> >>>>> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
> >>>>>  		save_state = 1;
> >>>>>  		break;
> >>>>>  	case PWRDM_POWER_RET:
> >>>>> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
> >>>>
> >>>> Aren't we trying to get away from these soc_* checks for anything other
> >>>> than init code?
> >>>
> >>> I would expect that to take place in stages as part of which the next
> >>> level of cleanup is to move PRM into drivers. Currently our wakeupgen,
> >>> prm code does have quiet a few needs of dealing with soc_is checks
> >>> primarily from having to re-architect code in two different directions
> >>> - we want to move into just one direction eventually - to prm drivers
> >>> and as less code in mach-omap2 which is already in the works.
> >>
> >> Why don't you just set some flag at init time based on the
> >> soc_is check and then test that here? That limits the use of
> >> soc_is to init code only which makes it easier to phase it
> >> out completely eventually.
> >>
> > Indeed. Infact the version of the code I tried posting last year was
> > using a flag which was initialised during init. Same can be
> > done her.
> 
> OK. will try something along that line in the next rev.


Hi,

Updated patch below:
Do let me know if this is ok with folks.

---8<----
>From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@ti.com>
Date: Mon, 27 May 2013 15:46:44 +0530
Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.

NOTE: the hardware was originally designed to be capable of achieving
deep power states such as OFF and OSWR, however due to various issues
and risks, deepest valid state was determined to be CSWR - hence we use
the errata framework to handle this case.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[nm at ti.com: updates]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
 arch/arm/mach-omap2/omap-wakeupgen.c      |    3 ++-
 arch/arm/mach-omap2/pm.h                  |    1 +
 arch/arm/mach-omap2/pm44xx.c              |   12 ++++++++++--
 4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..297352f 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
 		save_state = 1;
 		break;
 	case PWRDM_POWER_RET:
+		if (IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE)) {
+			save_state = 0;
+			break;
+		}
 	default:
 		/*
 		 * CPUx CSWR is invalid hardware state. Also CPUx OSWR
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index e844e16..f961c46 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -32,6 +32,7 @@
 #include "soc.h"
 #include "omap4-sar-layout.h"
 #include "common.h"
+#include "pm.h"
 
 #define AM43XX_NR_REG_BANKS	7
 #define AM43XX_IRQS		224
@@ -381,7 +382,7 @@ static struct notifier_block irq_notifier_block = {
 static void __init irq_pm_init(void)
 {
 	/* FIXME: Remove this when MPU OSWR support is added */
-	if (!soc_is_omap54xx())
+	if (!IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE))
 		cpu_pm_register_notifier(&irq_notifier_block);
 }
 #else
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index e150102..425bfcd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -101,6 +101,7 @@ static inline void enable_omap3630_toggle_l2_on_restore(void) { }
 #endif		/* defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3) */
 
 #define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD	(1 << 0)
+#define PM_OMAP4_CPU_OSWR_DISABLE		(1 << 1)
 
 #if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
 extern u16 pm44xx_errata;
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index b6f243d..64df620 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -36,6 +36,8 @@ struct power_state {
 	struct list_head node;
 };
 
+static u32 cpu_suspend_state = PWRDM_POWER_OFF;
+
 static LIST_HEAD(pwrst_list);
 
 #ifdef CONFIG_SUSPEND
@@ -66,7 +68,7 @@ static int omap4_pm_suspend(void)
 	 * domain CSWR is not supported by hardware.
 	 * More details can be found in OMAP4430 TRM section 4.3.4.2.
 	 */
-	omap4_enter_lowpower(cpu_id, PWRDM_POWER_OFF);
+	omap4_enter_lowpower(cpu_id, cpu_suspend_state);
 
 	/* Restore next powerdomain state */
 	list_for_each_entry(pwrst, &pwrst_list, node) {
@@ -112,8 +114,11 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 	 * through hotplug path and CPU0 explicitly programmed
 	 * further down in the code path
 	 */
-	if (!strncmp(pwrdm->name, "cpu", 3))
+	if (!strncmp(pwrdm->name, "cpu", 3)) {
+		if (IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE))
+			cpu_suspend_state = PWRDM_POWER_RET;
 		return 0;
+	}
 
 	pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
 	if (!pwrst)
@@ -238,6 +243,9 @@ int __init omap4_pm_init_early(void)
 	if (cpu_is_omap446x())
 		pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
 
+	if (soc_is_omap54xx() || soc_is_dra7xx())
+		pm44xx_errata |= PM_OMAP4_CPU_OSWR_DISABLE;
+
 	return 0;
 }
 
-- 
1.7.9.5

-- 
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

Daniel,

On 13:22-20140827, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 
> > On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
> >> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
> >> <khilman@deeprootsystems.com> wrote:
> >>> + Daniel (cpuidle maintainer)
> >> [...]
> >>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> >>>> +                            struct cpuidle_driver *drv,
> >>>> +                            int index)
> >>>> +{
> >>>> +     struct idle_statedata *cx = state_ptr + index;
> >>>> +     unsigned long flag;
> >>>> +
> >>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
> >>>> +     cx->mpu_state_vote++;
> >>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
> >>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> >>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> >>>> +     }
> >>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
> >>>> +
> >>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> >>>> +
> >>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
> >>>> +     if (cx->mpu_state_vote == num_online_cpus())
> >>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> >>>> +     cx->mpu_state_vote--;
> >>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
> >>>> +
> >>>> +     return index;
> >>>> +}
> >>>
> >>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
> >> 
> >> Trying to understand benefit of MCPM here - at least without a deeper
> >> understanding of mcpm infrastructure benefits (first look seemed a
> >> little heavy for OMAP5/DRA7 needs).
> >> 
> >> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
> >> "OFF" of CPU1/0, we have mercury hardware to help with context and
> >> sync issues.
> >> 
> >> Being able to reuse most of existing OMAP4 infrastructure code is
> >> useful as well to leave the existing omap4 framework as being lighter
> >> in complexity -esp in a cpuidle like hot path?
> >> 
> >> The spin_lock is only for the programming of MPU power domain in a
> >> consistent manner - I suppose might have been the trigger for
> >> proposing mcpm?
> >> 
> > Mostly not....
> >
> > I think this is coming because last time Nicolas Pitre tried to convert
> > the OMAP CPUIdle into MCPM but because of various ordering requirements,
> > OMAP wasn't suitable and then the plan was dropped later.
> >
> > Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
> > remains the same for deeper states. Its just the mercury retention state
> > which we are able to enter without ordering requirements and hence
> > the voting scheme.
> 
> Ah, OK.  This is the part that I'm missing.  So for deeper states you'll
> need to be using omap_enter_idle_coupled()
> 
> > Hope this clarifies to you as well as Kevin just in case he missed the
> > part of the deeper C-states requirements.
> 
> Yes, thanks for clarifying.
> 
> That being said, I think MCPM can now do essentially what the coupled
> states code is doing. Even so, that's probably not a reason to hold up
> this patch, but Daniel gets to make that call.


Gentle ping.. You can find the discussion and the patch here:
https://patchwork.kernel.org/patch/4764661/

-- 
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

Daniel,

On 13:22-20140827, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 
> > On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
> >> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
> >> <khilman@deeprootsystems.com> wrote:
> >>> + Daniel (cpuidle maintainer)
> >> [...]
> >>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> >>>> +                            struct cpuidle_driver *drv,
> >>>> +                            int index)
> >>>> +{
> >>>> +     struct idle_statedata *cx = state_ptr + index;
> >>>> +     unsigned long flag;
> >>>> +
> >>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
> >>>> +     cx->mpu_state_vote++;
> >>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
> >>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> >>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> >>>> +     }
> >>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
> >>>> +
> >>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> >>>> +
> >>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
> >>>> +     if (cx->mpu_state_vote == num_online_cpus())
> >>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> >>>> +     cx->mpu_state_vote--;
> >>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
> >>>> +
> >>>> +     return index;
> >>>> +}
> >>>
> >>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
> >> 
> >> Trying to understand benefit of MCPM here - at least without a deeper
> >> understanding of mcpm infrastructure benefits (first look seemed a
> >> little heavy for OMAP5/DRA7 needs).
> >> 
> >> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
> >> "OFF" of CPU1/0, we have mercury hardware to help with context and
> >> sync issues.
> >> 
> >> Being able to reuse most of existing OMAP4 infrastructure code is
> >> useful as well to leave the existing omap4 framework as being lighter
> >> in complexity -esp in a cpuidle like hot path?
> >> 
> >> The spin_lock is only for the programming of MPU power domain in a
> >> consistent manner - I suppose might have been the trigger for
> >> proposing mcpm?
> >> 
> > Mostly not....
> >
> > I think this is coming because last time Nicolas Pitre tried to convert
> > the OMAP CPUIdle into MCPM but because of various ordering requirements,
> > OMAP wasn't suitable and then the plan was dropped later.
> >
> > Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
> > remains the same for deeper states. Its just the mercury retention state
> > which we are able to enter without ordering requirements and hence
> > the voting scheme.
> 
> Ah, OK.  This is the part that I'm missing.  So for deeper states you'll
> need to be using omap_enter_idle_coupled()
> 
> > Hope this clarifies to you as well as Kevin just in case he missed the
> > part of the deeper C-states requirements.
> 
> Yes, thanks for clarifying.
> 
> That being said, I think MCPM can now do essentially what the coupled
> states code is doing. Even so, that's probably not a reason to hold up
> this patch, but Daniel gets to make that call.


Gentle ping.. You can find the discussion and the patch here:
https://patchwork.kernel.org/patch/4764661/

-- 
Regards,
Nishanth Menon

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

Daniel,

On 13:22-20140827, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 
> > On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
> >> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
> >> <khilman@deeprootsystems.com> wrote:
> >>> + Daniel (cpuidle maintainer)
> >> [...]
> >>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> >>>> +                            struct cpuidle_driver *drv,
> >>>> +                            int index)
> >>>> +{
> >>>> +     struct idle_statedata *cx = state_ptr + index;
> >>>> +     unsigned long flag;
> >>>> +
> >>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
> >>>> +     cx->mpu_state_vote++;
> >>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
> >>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> >>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> >>>> +     }
> >>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
> >>>> +
> >>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> >>>> +
> >>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
> >>>> +     if (cx->mpu_state_vote == num_online_cpus())
> >>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> >>>> +     cx->mpu_state_vote--;
> >>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
> >>>> +
> >>>> +     return index;
> >>>> +}
> >>>
> >>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
> >> 
> >> Trying to understand benefit of MCPM here - at least without a deeper
> >> understanding of mcpm infrastructure benefits (first look seemed a
> >> little heavy for OMAP5/DRA7 needs).
> >> 
> >> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
> >> "OFF" of CPU1/0, we have mercury hardware to help with context and
> >> sync issues.
> >> 
> >> Being able to reuse most of existing OMAP4 infrastructure code is
> >> useful as well to leave the existing omap4 framework as being lighter
> >> in complexity -esp in a cpuidle like hot path?
> >> 
> >> The spin_lock is only for the programming of MPU power domain in a
> >> consistent manner - I suppose might have been the trigger for
> >> proposing mcpm?
> >> 
> > Mostly not....
> >
> > I think this is coming because last time Nicolas Pitre tried to convert
> > the OMAP CPUIdle into MCPM but because of various ordering requirements,
> > OMAP wasn't suitable and then the plan was dropped later.
> >
> > Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
> > remains the same for deeper states. Its just the mercury retention state
> > which we are able to enter without ordering requirements and hence
> > the voting scheme.
> 
> Ah, OK.  This is the part that I'm missing.  So for deeper states you'll
> need to be using omap_enter_idle_coupled()
> 
> > Hope this clarifies to you as well as Kevin just in case he missed the
> > part of the deeper C-states requirements.
> 
> Yes, thanks for clarifying.
> 
> That being said, I think MCPM can now do essentially what the coupled
> states code is doing. Even so, that's probably not a reason to hold up
> this patch, but Daniel gets to make that call.


Gentle ping.. You can find the discussion and the patch here:
https://patchwork.kernel.org/patch/4764661/

-- 
Regards,
Nishanth Menon

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [140905 14:16]:
> On 14:45-20140827, Nishanth Menon wrote:
> > On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
> > > On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
> > >> * Nishanth Menon <nm@ti.com> [140827 12:05]:
> > >>> On 08/27/2014 01:58 PM, Kevin Hilman wrote:
> > >>>> Nishanth Menon <nm@ti.com> writes:
> > >>>>
> > >>>>> From: Rajendra Nayak <rnayak@ti.com>
> > >>>>>
> > >>>>> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> > >>>>> and instead attempt a CPU RET and side effect, MPU RET in suspend.
> > >>>>>
> > >>>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > >>>>> [nm@ti.com: update to do save_state only on DRA7]
> > >>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
> > >>>>> ---
> > >>>>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
> > >>>>>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
> > >>>>>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
> > >>>>>  3 files changed, 12 insertions(+), 3 deletions(-)
> > >>>>>
> > >>>>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > >>>>> index 207fce2..0d640eb 100644
> > >>>>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > >>>>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > >>>>> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
> > >>>>>  		save_state = 1;
> > >>>>>  		break;
> > >>>>>  	case PWRDM_POWER_RET:
> > >>>>> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
> > >>>>
> > >>>> Aren't we trying to get away from these soc_* checks for anything other
> > >>>> than init code?
> > >>>
> > >>> I would expect that to take place in stages as part of which the next
> > >>> level of cleanup is to move PRM into drivers. Currently our wakeupgen,
> > >>> prm code does have quiet a few needs of dealing with soc_is checks
> > >>> primarily from having to re-architect code in two different directions
> > >>> - we want to move into just one direction eventually - to prm drivers
> > >>> and as less code in mach-omap2 which is already in the works.
> > >>
> > >> Why don't you just set some flag at init time based on the
> > >> soc_is check and then test that here? That limits the use of
> > >> soc_is to init code only which makes it easier to phase it
> > >> out completely eventually.
> > >>
> > > Indeed. Infact the version of the code I tried posting last year was
> > > using a flag which was initialised during init. Same can be
> > > done her.
> > 
> > OK. will try something along that line in the next rev.
> 
> 
> Hi,
> 
> Updated patch below:

Looks OK to me thanks.

Tony

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [140905 14:16]:
> On 14:45-20140827, Nishanth Menon wrote:
> > On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
> > > On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
> > >> * Nishanth Menon <nm@ti.com> [140827 12:05]:
> > >>> On 08/27/2014 01:58 PM, Kevin Hilman wrote:
> > >>>> Nishanth Menon <nm@ti.com> writes:
> > >>>>
> > >>>>> From: Rajendra Nayak <rnayak@ti.com>
> > >>>>>
> > >>>>> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> > >>>>> and instead attempt a CPU RET and side effect, MPU RET in suspend.
> > >>>>>
> > >>>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > >>>>> [nm at ti.com: update to do save_state only on DRA7]
> > >>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
> > >>>>> ---
> > >>>>>  arch/arm/mach-omap2/omap-mpuss-lowpower.c |    4 ++++
> > >>>>>  arch/arm/mach-omap2/omap-wakeupgen.c      |    2 +-
> > >>>>>  arch/arm/mach-omap2/pm44xx.c              |    9 +++++++--
> > >>>>>  3 files changed, 12 insertions(+), 3 deletions(-)
> > >>>>>
> > >>>>> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > >>>>> index 207fce2..0d640eb 100644
> > >>>>> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > >>>>> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> > >>>>> @@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
> > >>>>>  		save_state = 1;
> > >>>>>  		break;
> > >>>>>  	case PWRDM_POWER_RET:
> > >>>>> +		if (soc_is_omap54xx() || soc_is_dra7xx()) {
> > >>>>
> > >>>> Aren't we trying to get away from these soc_* checks for anything other
> > >>>> than init code?
> > >>>
> > >>> I would expect that to take place in stages as part of which the next
> > >>> level of cleanup is to move PRM into drivers. Currently our wakeupgen,
> > >>> prm code does have quiet a few needs of dealing with soc_is checks
> > >>> primarily from having to re-architect code in two different directions
> > >>> - we want to move into just one direction eventually - to prm drivers
> > >>> and as less code in mach-omap2 which is already in the works.
> > >>
> > >> Why don't you just set some flag at init time based on the
> > >> soc_is check and then test that here? That limits the use of
> > >> soc_is to init code only which makes it easier to phase it
> > >> out completely eventually.
> > >>
> > > Indeed. Infact the version of the code I tried posting last year was
> > > using a flag which was initialised during init. Same can be
> > > done her.
> > 
> > OK. will try something along that line in the next rev.
> 
> 
> Hi,
> 
> Updated patch below:

Looks OK to me thanks.

Tony

Re: [PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Nishanth Menon]

On 08/27/2014 02:15 PM, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
> 
>> The following series are various fixes and improvements for
>> supporting suspend-to-ram. This depends on the following for basic functionality:
>> series 1/6 where powerdomain fixes were involved.
> 
> I had a look through this series, and it looks good overall.  I think Daniel
> needs to weigh in on the CPUidle driver, otherwise.
> 
> Reviewed-by: Kevin Hilman <khilman@linaro.org>
> 
> I also tested on omap5uevm with the pm_debug/wakeup_timer_seconds patch.
> 
> Tested-by: Kevin Hilman <khilman@linaro.org>
> 
> Kevin
> 

I am dropping cpuidle patch for the moment, and sending remaining
stuff to Tony for merge with Kevin's Reviewed and Tested. we will send
cpuidle once we have Daniel's response.

-- 
Regards,
Nishanth Menon

[PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Nishanth Menon]

On 08/27/2014 02:15 PM, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
> 
>> The following series are various fixes and improvements for
>> supporting suspend-to-ram. This depends on the following for basic functionality:
>> series 1/6 where powerdomain fixes were involved.
> 
> I had a look through this series, and it looks good overall.  I think Daniel
> needs to weigh in on the CPUidle driver, otherwise.
> 
> Reviewed-by: Kevin Hilman <khilman@linaro.org>
> 
> I also tested on omap5uevm with the pm_debug/wakeup_timer_seconds patch.
> 
> Tested-by: Kevin Hilman <khilman@linaro.org>
> 
> Kevin
> 

I am dropping cpuidle patch for the moment, and sending remaining
stuff to Tony for merge with Kevin's Reviewed and Tested. we will send
cpuidle once we have Daniel's response.

-- 
Regards,
Nishanth Menon

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Grazvydas Ignotas]

Hi,

On Sat, Sep 6, 2014 at 12:15 AM, Nishanth Menon <nm@ti.com> wrote:
>
> Hi,
>
> Updated patch below:
> Do let me know if this is ok with folks.
>
> ---8<----
> From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
> From: Rajendra Nayak <rnayak@ti.com>
> Date: Mon, 27 May 2013 15:46:44 +0530
> Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
>
> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> and instead attempt a CPU RET and side effect, MPU RET in suspend.
>
> NOTE: the hardware was originally designed to be capable of achieving
> deep power states such as OFF and OSWR, however due to various issues
> and risks, deepest valid state was determined to be CSWR - hence we use

Would be great to have some more details here..
So there is no hope for OFF mode on OMAP5?


-- 
Gražvydas

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Grazvydas Ignotas]

Hi,

On Sat, Sep 6, 2014 at 12:15 AM, Nishanth Menon <nm@ti.com> wrote:
>
> Hi,
>
> Updated patch below:
> Do let me know if this is ok with folks.
>
> ---8<----
> From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
> From: Rajendra Nayak <rnayak@ti.com>
> Date: Mon, 27 May 2013 15:46:44 +0530
> Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
>
> On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> and instead attempt a CPU RET and side effect, MPU RET in suspend.
>
> NOTE: the hardware was originally designed to be capable of achieving
> deep power states such as OFF and OSWR, however due to various issues
> and risks, deepest valid state was determined to be CSWR - hence we use

Would be great to have some more details here..
So there is no hope for OFF mode on OMAP5?


-- 
Gra?vydas

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

On 20:23-20140908, Grazvydas Ignotas wrote:
> On Sat, Sep 6, 2014 at 12:15 AM, Nishanth Menon <nm@ti.com> wrote:
> >
> > Hi,
> >
> > Updated patch below:
> > Do let me know if this is ok with folks.
> >
> > ---8<----
> > From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
> > From: Rajendra Nayak <rnayak@ti.com>
> > Date: Mon, 27 May 2013 15:46:44 +0530
> > Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
> >
> > On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> > and instead attempt a CPU RET and side effect, MPU RET in suspend.
> >
> > NOTE: the hardware was originally designed to be capable of achieving
> > deep power states such as OFF and OSWR, however due to various issues
> > and risks, deepest valid state was determined to be CSWR - hence we use
> 
> Would be great to have some more details here..

Sorry, I have no details that can be published publically. Lets say, "TI
refocus"?

> So there is no hope for OFF mode on OMAP5?

Yep, There is *NO* hope for OFF or OSWR on OMAP5/DRA7.

-- 
Regards,
Nishanth Menon

[PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

On 20:23-20140908, Grazvydas Ignotas wrote:
> On Sat, Sep 6, 2014 at 12:15 AM, Nishanth Menon <nm@ti.com> wrote:
> >
> > Hi,
> >
> > Updated patch below:
> > Do let me know if this is ok with folks.
> >
> > ---8<----
> > From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
> > From: Rajendra Nayak <rnayak@ti.com>
> > Date: Mon, 27 May 2013 15:46:44 +0530
> > Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
> >
> > On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
> > and instead attempt a CPU RET and side effect, MPU RET in suspend.
> >
> > NOTE: the hardware was originally designed to be capable of achieving
> > deep power states such as OFF and OSWR, however due to various issues
> > and risks, deepest valid state was determined to be CSWR - hence we use
> 
> Would be great to have some more details here..

Sorry, I have no details that can be published publically. Lets say, "TI
refocus"?

> So there is no hope for OFF mode on OMAP5?

Yep, There is *NO* hope for OFF or OSWR on OMAP5/DRA7.

-- 
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

Daniel,

On 09/05/2014 04:18 PM, Nishanth Menon wrote:
> Daniel,
> 
> On 13:22-20140827, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
>>>> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
>>>> <khilman@deeprootsystems.com> wrote:
>>>>> + Daniel (cpuidle maintainer)
>>>> [...]
>>>>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>>>>> +                            struct cpuidle_driver *drv,
>>>>>> +                            int index)
>>>>>> +{
>>>>>> +     struct idle_statedata *cx = state_ptr + index;
>>>>>> +     unsigned long flag;
>>>>>> +
>>>>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>>>>> +     cx->mpu_state_vote++;
>>>>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>>>>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>>>>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>>>>>> +     }
>>>>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>>>>> +
>>>>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>>>>>> +
>>>>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>>>>> +     if (cx->mpu_state_vote == num_online_cpus())
>>>>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>>>>>> +     cx->mpu_state_vote--;
>>>>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>>>>> +
>>>>>> +     return index;
>>>>>> +}
>>>>>
>>>>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
>>>>
>>>> Trying to understand benefit of MCPM here - at least without a deeper
>>>> understanding of mcpm infrastructure benefits (first look seemed a
>>>> little heavy for OMAP5/DRA7 needs).
>>>>
>>>> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
>>>> "OFF" of CPU1/0, we have mercury hardware to help with context and
>>>> sync issues.
>>>>
>>>> Being able to reuse most of existing OMAP4 infrastructure code is
>>>> useful as well to leave the existing omap4 framework as being lighter
>>>> in complexity -esp in a cpuidle like hot path?
>>>>
>>>> The spin_lock is only for the programming of MPU power domain in a
>>>> consistent manner - I suppose might have been the trigger for
>>>> proposing mcpm?
>>>>
>>> Mostly not....
>>>
>>> I think this is coming because last time Nicolas Pitre tried to convert
>>> the OMAP CPUIdle into MCPM but because of various ordering requirements,
>>> OMAP wasn't suitable and then the plan was dropped later.
>>>
>>> Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
>>> remains the same for deeper states. Its just the mercury retention state
>>> which we are able to enter without ordering requirements and hence
>>> the voting scheme.
>>
>> Ah, OK.  This is the part that I'm missing.  So for deeper states you'll
>> need to be using omap_enter_idle_coupled()
>>
>>> Hope this clarifies to you as well as Kevin just in case he missed the
>>> part of the deeper C-states requirements.
>>
>> Yes, thanks for clarifying.
>>
>> That being said, I think MCPM can now do essentially what the coupled
>> states code is doing. Even so, that's probably not a reason to hold up
>> this patch, but Daniel gets to make that call.
> 
> 
> Gentle ping.. You can find the discussion and the patch here:
> https://patchwork.kernel.org/patch/4764661/
> 

Ping on this again.. we are pretty close to approaching v3.18 merge
window and this discussion has'nt gotten further.

-- 
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

Daniel,

On 09/05/2014 04:18 PM, Nishanth Menon wrote:
> Daniel,
> 
> On 13:22-20140827, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
>>>> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
>>>> <khilman@deeprootsystems.com> wrote:
>>>>> + Daniel (cpuidle maintainer)
>>>> [...]
>>>>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>>>>> +                            struct cpuidle_driver *drv,
>>>>>> +                            int index)
>>>>>> +{
>>>>>> +     struct idle_statedata *cx = state_ptr + index;
>>>>>> +     unsigned long flag;
>>>>>> +
>>>>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>>>>> +     cx->mpu_state_vote++;
>>>>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>>>>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>>>>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>>>>>> +     }
>>>>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>>>>> +
>>>>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>>>>>> +
>>>>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>>>>> +     if (cx->mpu_state_vote == num_online_cpus())
>>>>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>>>>>> +     cx->mpu_state_vote--;
>>>>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>>>>> +
>>>>>> +     return index;
>>>>>> +}
>>>>>
>>>>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
>>>>
>>>> Trying to understand benefit of MCPM here - at least without a deeper
>>>> understanding of mcpm infrastructure benefits (first look seemed a
>>>> little heavy for OMAP5/DRA7 needs).
>>>>
>>>> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
>>>> "OFF" of CPU1/0, we have mercury hardware to help with context and
>>>> sync issues.
>>>>
>>>> Being able to reuse most of existing OMAP4 infrastructure code is
>>>> useful as well to leave the existing omap4 framework as being lighter
>>>> in complexity -esp in a cpuidle like hot path?
>>>>
>>>> The spin_lock is only for the programming of MPU power domain in a
>>>> consistent manner - I suppose might have been the trigger for
>>>> proposing mcpm?
>>>>
>>> Mostly not....
>>>
>>> I think this is coming because last time Nicolas Pitre tried to convert
>>> the OMAP CPUIdle into MCPM but because of various ordering requirements,
>>> OMAP wasn't suitable and then the plan was dropped later.
>>>
>>> Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
>>> remains the same for deeper states. Its just the mercury retention state
>>> which we are able to enter without ordering requirements and hence
>>> the voting scheme.
>>
>> Ah, OK.  This is the part that I'm missing.  So for deeper states you'll
>> need to be using omap_enter_idle_coupled()
>>
>>> Hope this clarifies to you as well as Kevin just in case he missed the
>>> part of the deeper C-states requirements.
>>
>> Yes, thanks for clarifying.
>>
>> That being said, I think MCPM can now do essentially what the coupled
>> states code is doing. Even so, that's probably not a reason to hold up
>> this patch, but Daniel gets to make that call.
> 
> 
> Gentle ping.. You can find the discussion and the patch here:
> https://patchwork.kernel.org/patch/4764661/
> 

Ping on this again.. we are pretty close to approaching v3.18 merge
window and this discussion has'nt gotten further.

-- 
Regards,
Nishanth Menon

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

Daniel,

On 09/05/2014 04:18 PM, Nishanth Menon wrote:
> Daniel,
> 
> On 13:22-20140827, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
>>>> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
>>>> <khilman@deeprootsystems.com> wrote:
>>>>> + Daniel (cpuidle maintainer)
>>>> [...]
>>>>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>>>>> +                            struct cpuidle_driver *drv,
>>>>>> +                            int index)
>>>>>> +{
>>>>>> +     struct idle_statedata *cx = state_ptr + index;
>>>>>> +     unsigned long flag;
>>>>>> +
>>>>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>>>>> +     cx->mpu_state_vote++;
>>>>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>>>>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>>>>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>>>>>> +     }
>>>>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>>>>> +
>>>>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>>>>>> +
>>>>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>>>>> +     if (cx->mpu_state_vote == num_online_cpus())
>>>>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>>>>>> +     cx->mpu_state_vote--;
>>>>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>>>>> +
>>>>>> +     return index;
>>>>>> +}
>>>>>
>>>>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
>>>>
>>>> Trying to understand benefit of MCPM here - at least without a deeper
>>>> understanding of mcpm infrastructure benefits (first look seemed a
>>>> little heavy for OMAP5/DRA7 needs).
>>>>
>>>> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
>>>> "OFF" of CPU1/0, we have mercury hardware to help with context and
>>>> sync issues.
>>>>
>>>> Being able to reuse most of existing OMAP4 infrastructure code is
>>>> useful as well to leave the existing omap4 framework as being lighter
>>>> in complexity -esp in a cpuidle like hot path?
>>>>
>>>> The spin_lock is only for the programming of MPU power domain in a
>>>> consistent manner - I suppose might have been the trigger for
>>>> proposing mcpm?
>>>>
>>> Mostly not....
>>>
>>> I think this is coming because last time Nicolas Pitre tried to convert
>>> the OMAP CPUIdle into MCPM but because of various ordering requirements,
>>> OMAP wasn't suitable and then the plan was dropped later.
>>>
>>> Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
>>> remains the same for deeper states. Its just the mercury retention state
>>> which we are able to enter without ordering requirements and hence
>>> the voting scheme.
>>
>> Ah, OK.  This is the part that I'm missing.  So for deeper states you'll
>> need to be using omap_enter_idle_coupled()
>>
>>> Hope this clarifies to you as well as Kevin just in case he missed the
>>> part of the deeper C-states requirements.
>>
>> Yes, thanks for clarifying.
>>
>> That being said, I think MCPM can now do essentially what the coupled
>> states code is doing. Even so, that's probably not a reason to hold up
>> this patch, but Daniel gets to make that call.
> 
> 
> Gentle ping.. You can find the discussion and the patch here:
> https://patchwork.kernel.org/patch/4764661/
> 

Ping on this again.. we are pretty close to approaching v3.18 merge
window and this discussion has'nt gotten further.

-- 
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Daniel Lezcano]

On 08/22/2014 07:02 AM, Nishanth Menon wrote:
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Add OMAP5/DRA74/72 CPUIDLE support.
>
> This patch adds MPUSS low power states in cpuidle.
>
>          C1 - CPU0 WFI + CPU1 WFI + MPU ON
>          C2 - CPU0 RET + CPU1 RET + MPU CSWR
>
> Tested on DRA74/72-EVM for C1 and C2 states.
>
> NOTE: DRA7 does not do voltage scaling as part of retention transition
> and has Mercury which speeds up transition paths - Latency numbers are
> based on measurements done by toggling GPIOs.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> [ j-keerthy@ti.com rework on 3.14]
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> [nm@ti.com: updates based on profiling, OMAP5 squashed]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>   arch/arm/mach-omap2/cpuidle44xx.c |   82 ++++++++++++++++++++++++++++++++++++-
>   arch/arm/mach-omap2/pm44xx.c      |    2 +-
>   2 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 2498ab0..8ad4f44 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -22,6 +22,7 @@
>   #include "common.h"
>   #include "pm.h"
>   #include "prm.h"
> +#include "soc.h"
>   #include "clockdomain.h"
>
>   #define MAX_CPUS	2
> @@ -31,6 +32,7 @@ struct idle_statedata {
>   	u32 cpu_state;
>   	u32 mpu_logic_state;
>   	u32 mpu_state;
> +	u32 mpu_state_vote;
>   };
>
>   static struct idle_statedata omap4_idle_data[] = {
> @@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
>   	},
>   };
>
> +static struct idle_statedata dra7_idle_data[] = {
> +	{
> +		.cpu_state = PWRDM_POWER_ON,
> +		.mpu_state = PWRDM_POWER_ON,
> +		.mpu_logic_state = PWRDM_POWER_ON,
> +	},
> +	{
> +		.cpu_state = PWRDM_POWER_RET,
> +		.mpu_state = PWRDM_POWER_RET,
> +		.mpu_logic_state = PWRDM_POWER_RET,
> +	},
> +};
> +
>   static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
>   static struct clockdomain *cpu_clkdm[MAX_CPUS];
>
>   static atomic_t abort_barrier;
>   static bool cpu_done[MAX_CPUS];
>   static struct idle_statedata *state_ptr = &omap4_idle_data[0];
> +static DEFINE_RAW_SPINLOCK(mpu_lock);
>
>   /* Private functions */
>
> @@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
>   	return index;
>   }
>
> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> +			       struct cpuidle_driver *drv,
> +			       int index)
> +{
> +	struct idle_statedata *cx = state_ptr + index;
> +	unsigned long flag;
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);

Why do you need this spin_lock_irqsave ? Aren't the local irqs already 
disabled ?

> +	cx->mpu_state_vote++;
> +	if (cx->mpu_state_vote == num_online_cpus()) {
> +		pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> +		omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> +	}
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +	omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);
> +	if (cx->mpu_state_vote == num_online_cpus())
> +		omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> +	cx->mpu_state_vote--;
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);

I am not sure that will work. What happens if a cpu exits idle and then 
re-enter idle immediately ?

Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c

> +	return index;
> +}
> +
>   static int omap_enter_idle_coupled(struct cpuidle_device *dev,
>   			struct cpuidle_driver *drv,
>   			int index)
> @@ -224,6 +266,34 @@ static struct cpuidle_driver omap4_idle_driver = {
>   	.safe_state_index = 0,
>   };
>
> +static struct cpuidle_driver dra7_idle_driver = {
> +	.name				= "dra7_idle",
> +	.owner				= THIS_MODULE,
> +	.states = {
> +		{
> +			/* C1 - CPU0 ON + CPU1 ON + MPU ON */
> +			.exit_latency = 2 + 2,
> +			.target_residency = 5,
> +			.flags = CPUIDLE_FLAG_TIME_VALID,
> +			.enter = omap_enter_idle_simple,
> +			.name = "C1",
> +			.desc = "CPUx WFI, MPUSS ON"
> +		},
> +		{
> +			/* C2 - CPU0 RET + CPU1 RET + MPU CSWR */
> +			.exit_latency = 48 + 60,
> +			.target_residency = 100,
> +			.flags = CPUIDLE_FLAG_TIME_VALID
> +					| CPUIDLE_FLAG_TIMER_STOP,
> +			.enter = omap_enter_idle_smp,
> +			.name = "C2",
> +			.desc = "CPUx CSWR, MPUSS CSWR",
> +		},
> +	},
> +	.state_count = ARRAY_SIZE(dra7_idle_data),
> +	.safe_state_index = 0,
> +};
> +
>   /* Public functions */
>
>   /**
> @@ -234,6 +304,16 @@ static struct cpuidle_driver omap4_idle_driver = {
>    */
>   int __init omap4_idle_init(void)
>   {
> +	struct cpuidle_driver *idle_driver;
> +
> +	if (soc_is_dra7xx() || soc_is_omap54xx()) {
> +		state_ptr = &dra7_idle_data[0];
> +		idle_driver = &dra7_idle_driver;
> +	} else {
> +		state_ptr = &omap4_idle_data[0];
> +		idle_driver = &omap4_idle_driver;
> +	}
> +
>   	mpu_pd = pwrdm_lookup("mpu_pwrdm");
>   	cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
>   	cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
> @@ -248,5 +328,5 @@ int __init omap4_idle_init(void)
>   	/* Configure the broadcast timer on each cpu */
>   	on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
>
> -	return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
> +	return cpuidle_register(idle_driver, cpu_online_mask);
>   }
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index c063833..1d22162 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -293,7 +293,7 @@ int __init omap4_pm_init(void)
>   	/* Overwrite the default cpu_do_idle() */
>   	arm_pm_idle = omap_default_idle;
>
> -	if (cpu_is_omap44xx())
> +	if (cpu_is_omap44xx() || soc_is_dra7xx() || soc_is_omap54xx())
>   		omap4_idle_init();
>
>   err2:
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Daniel Lezcano]

On 08/22/2014 07:02 AM, Nishanth Menon wrote:
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Add OMAP5/DRA74/72 CPUIDLE support.
>
> This patch adds MPUSS low power states in cpuidle.
>
>          C1 - CPU0 WFI + CPU1 WFI + MPU ON
>          C2 - CPU0 RET + CPU1 RET + MPU CSWR
>
> Tested on DRA74/72-EVM for C1 and C2 states.
>
> NOTE: DRA7 does not do voltage scaling as part of retention transition
> and has Mercury which speeds up transition paths - Latency numbers are
> based on measurements done by toggling GPIOs.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> [ j-keerthy@ti.com rework on 3.14]
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> [nm@ti.com: updates based on profiling, OMAP5 squashed]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>   arch/arm/mach-omap2/cpuidle44xx.c |   82 ++++++++++++++++++++++++++++++++++++-
>   arch/arm/mach-omap2/pm44xx.c      |    2 +-
>   2 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 2498ab0..8ad4f44 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -22,6 +22,7 @@
>   #include "common.h"
>   #include "pm.h"
>   #include "prm.h"
> +#include "soc.h"
>   #include "clockdomain.h"
>
>   #define MAX_CPUS	2
> @@ -31,6 +32,7 @@ struct idle_statedata {
>   	u32 cpu_state;
>   	u32 mpu_logic_state;
>   	u32 mpu_state;
> +	u32 mpu_state_vote;
>   };
>
>   static struct idle_statedata omap4_idle_data[] = {
> @@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
>   	},
>   };
>
> +static struct idle_statedata dra7_idle_data[] = {
> +	{
> +		.cpu_state = PWRDM_POWER_ON,
> +		.mpu_state = PWRDM_POWER_ON,
> +		.mpu_logic_state = PWRDM_POWER_ON,
> +	},
> +	{
> +		.cpu_state = PWRDM_POWER_RET,
> +		.mpu_state = PWRDM_POWER_RET,
> +		.mpu_logic_state = PWRDM_POWER_RET,
> +	},
> +};
> +
>   static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
>   static struct clockdomain *cpu_clkdm[MAX_CPUS];
>
>   static atomic_t abort_barrier;
>   static bool cpu_done[MAX_CPUS];
>   static struct idle_statedata *state_ptr = &omap4_idle_data[0];
> +static DEFINE_RAW_SPINLOCK(mpu_lock);
>
>   /* Private functions */
>
> @@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
>   	return index;
>   }
>
> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> +			       struct cpuidle_driver *drv,
> +			       int index)
> +{
> +	struct idle_statedata *cx = state_ptr + index;
> +	unsigned long flag;
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);

Why do you need this spin_lock_irqsave ? Aren't the local irqs already 
disabled ?

> +	cx->mpu_state_vote++;
> +	if (cx->mpu_state_vote == num_online_cpus()) {
> +		pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> +		omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> +	}
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +	omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);
> +	if (cx->mpu_state_vote == num_online_cpus())
> +		omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> +	cx->mpu_state_vote--;
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);

I am not sure that will work. What happens if a cpu exits idle and then 
re-enter idle immediately ?

Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c

> +	return index;
> +}
> +
>   static int omap_enter_idle_coupled(struct cpuidle_device *dev,
>   			struct cpuidle_driver *drv,
>   			int index)
> @@ -224,6 +266,34 @@ static struct cpuidle_driver omap4_idle_driver = {
>   	.safe_state_index = 0,
>   };
>
> +static struct cpuidle_driver dra7_idle_driver = {
> +	.name				= "dra7_idle",
> +	.owner				= THIS_MODULE,
> +	.states = {
> +		{
> +			/* C1 - CPU0 ON + CPU1 ON + MPU ON */
> +			.exit_latency = 2 + 2,
> +			.target_residency = 5,
> +			.flags = CPUIDLE_FLAG_TIME_VALID,
> +			.enter = omap_enter_idle_simple,
> +			.name = "C1",
> +			.desc = "CPUx WFI, MPUSS ON"
> +		},
> +		{
> +			/* C2 - CPU0 RET + CPU1 RET + MPU CSWR */
> +			.exit_latency = 48 + 60,
> +			.target_residency = 100,
> +			.flags = CPUIDLE_FLAG_TIME_VALID
> +					| CPUIDLE_FLAG_TIMER_STOP,
> +			.enter = omap_enter_idle_smp,
> +			.name = "C2",
> +			.desc = "CPUx CSWR, MPUSS CSWR",
> +		},
> +	},
> +	.state_count = ARRAY_SIZE(dra7_idle_data),
> +	.safe_state_index = 0,
> +};
> +
>   /* Public functions */
>
>   /**
> @@ -234,6 +304,16 @@ static struct cpuidle_driver omap4_idle_driver = {
>    */
>   int __init omap4_idle_init(void)
>   {
> +	struct cpuidle_driver *idle_driver;
> +
> +	if (soc_is_dra7xx() || soc_is_omap54xx()) {
> +		state_ptr = &dra7_idle_data[0];
> +		idle_driver = &dra7_idle_driver;
> +	} else {
> +		state_ptr = &omap4_idle_data[0];
> +		idle_driver = &omap4_idle_driver;
> +	}
> +
>   	mpu_pd = pwrdm_lookup("mpu_pwrdm");
>   	cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
>   	cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
> @@ -248,5 +328,5 @@ int __init omap4_idle_init(void)
>   	/* Configure the broadcast timer on each cpu */
>   	on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
>
> -	return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
> +	return cpuidle_register(idle_driver, cpu_online_mask);
>   }
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index c063833..1d22162 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -293,7 +293,7 @@ int __init omap4_pm_init(void)
>   	/* Overwrite the default cpu_do_idle() */
>   	arm_pm_idle = omap_default_idle;
>
> -	if (cpu_is_omap44xx())
> +	if (cpu_is_omap44xx() || soc_is_dra7xx() || soc_is_omap54xx())
>   		omap4_idle_init();
>
>   err2:
>


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Daniel Lezcano]

On 08/22/2014 07:02 AM, Nishanth Menon wrote:
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Add OMAP5/DRA74/72 CPUIDLE support.
>
> This patch adds MPUSS low power states in cpuidle.
>
>          C1 - CPU0 WFI + CPU1 WFI + MPU ON
>          C2 - CPU0 RET + CPU1 RET + MPU CSWR
>
> Tested on DRA74/72-EVM for C1 and C2 states.
>
> NOTE: DRA7 does not do voltage scaling as part of retention transition
> and has Mercury which speeds up transition paths - Latency numbers are
> based on measurements done by toggling GPIOs.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> [ j-keerthy at ti.com rework on 3.14]
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> [nm at ti.com: updates based on profiling, OMAP5 squashed]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>   arch/arm/mach-omap2/cpuidle44xx.c |   82 ++++++++++++++++++++++++++++++++++++-
>   arch/arm/mach-omap2/pm44xx.c      |    2 +-
>   2 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 2498ab0..8ad4f44 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -22,6 +22,7 @@
>   #include "common.h"
>   #include "pm.h"
>   #include "prm.h"
> +#include "soc.h"
>   #include "clockdomain.h"
>
>   #define MAX_CPUS	2
> @@ -31,6 +32,7 @@ struct idle_statedata {
>   	u32 cpu_state;
>   	u32 mpu_logic_state;
>   	u32 mpu_state;
> +	u32 mpu_state_vote;
>   };
>
>   static struct idle_statedata omap4_idle_data[] = {
> @@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
>   	},
>   };
>
> +static struct idle_statedata dra7_idle_data[] = {
> +	{
> +		.cpu_state = PWRDM_POWER_ON,
> +		.mpu_state = PWRDM_POWER_ON,
> +		.mpu_logic_state = PWRDM_POWER_ON,
> +	},
> +	{
> +		.cpu_state = PWRDM_POWER_RET,
> +		.mpu_state = PWRDM_POWER_RET,
> +		.mpu_logic_state = PWRDM_POWER_RET,
> +	},
> +};
> +
>   static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
>   static struct clockdomain *cpu_clkdm[MAX_CPUS];
>
>   static atomic_t abort_barrier;
>   static bool cpu_done[MAX_CPUS];
>   static struct idle_statedata *state_ptr = &omap4_idle_data[0];
> +static DEFINE_RAW_SPINLOCK(mpu_lock);
>
>   /* Private functions */
>
> @@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
>   	return index;
>   }
>
> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> +			       struct cpuidle_driver *drv,
> +			       int index)
> +{
> +	struct idle_statedata *cx = state_ptr + index;
> +	unsigned long flag;
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);

Why do you need this spin_lock_irqsave ? Aren't the local irqs already 
disabled ?

> +	cx->mpu_state_vote++;
> +	if (cx->mpu_state_vote == num_online_cpus()) {
> +		pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> +		omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> +	}
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +	omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> +	raw_spin_lock_irqsave(&mpu_lock, flag);
> +	if (cx->mpu_state_vote == num_online_cpus())
> +		omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> +	cx->mpu_state_vote--;
> +	raw_spin_unlock_irqrestore(&mpu_lock, flag);

I am not sure that will work. What happens if a cpu exits idle and then 
re-enter idle immediately ?

Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c

> +	return index;
> +}
> +
>   static int omap_enter_idle_coupled(struct cpuidle_device *dev,
>   			struct cpuidle_driver *drv,
>   			int index)
> @@ -224,6 +266,34 @@ static struct cpuidle_driver omap4_idle_driver = {
>   	.safe_state_index = 0,
>   };
>
> +static struct cpuidle_driver dra7_idle_driver = {
> +	.name				= "dra7_idle",
> +	.owner				= THIS_MODULE,
> +	.states = {
> +		{
> +			/* C1 - CPU0 ON + CPU1 ON + MPU ON */
> +			.exit_latency = 2 + 2,
> +			.target_residency = 5,
> +			.flags = CPUIDLE_FLAG_TIME_VALID,
> +			.enter = omap_enter_idle_simple,
> +			.name = "C1",
> +			.desc = "CPUx WFI, MPUSS ON"
> +		},
> +		{
> +			/* C2 - CPU0 RET + CPU1 RET + MPU CSWR */
> +			.exit_latency = 48 + 60,
> +			.target_residency = 100,
> +			.flags = CPUIDLE_FLAG_TIME_VALID
> +					| CPUIDLE_FLAG_TIMER_STOP,
> +			.enter = omap_enter_idle_smp,
> +			.name = "C2",
> +			.desc = "CPUx CSWR, MPUSS CSWR",
> +		},
> +	},
> +	.state_count = ARRAY_SIZE(dra7_idle_data),
> +	.safe_state_index = 0,
> +};
> +
>   /* Public functions */
>
>   /**
> @@ -234,6 +304,16 @@ static struct cpuidle_driver omap4_idle_driver = {
>    */
>   int __init omap4_idle_init(void)
>   {
> +	struct cpuidle_driver *idle_driver;
> +
> +	if (soc_is_dra7xx() || soc_is_omap54xx()) {
> +		state_ptr = &dra7_idle_data[0];
> +		idle_driver = &dra7_idle_driver;
> +	} else {
> +		state_ptr = &omap4_idle_data[0];
> +		idle_driver = &omap4_idle_driver;
> +	}
> +
>   	mpu_pd = pwrdm_lookup("mpu_pwrdm");
>   	cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
>   	cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
> @@ -248,5 +328,5 @@ int __init omap4_idle_init(void)
>   	/* Configure the broadcast timer on each cpu */
>   	on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
>
> -	return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
> +	return cpuidle_register(idle_driver, cpu_online_mask);
>   }
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index c063833..1d22162 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -293,7 +293,7 @@ int __init omap4_pm_init(void)
>   	/* Overwrite the default cpu_do_idle() */
>   	arm_pm_idle = omap_default_idle;
>
> -	if (cpu_is_omap44xx())
> +	if (cpu_is_omap44xx() || soc_is_dra7xx() || soc_is_omap54xx())
>   		omap4_idle_init();
>
>   err2:
>


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

RE: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Shilimkar, Santosh]

Sorry for the format. Emailing from webmail.
________________________________________
From: Daniel Lezcano [daniel.lezcano@linaro.org]
Sent: Wednesday, September 17, 2014 2:49 PM
To: Menon, Nishanth; Shilimkar, Santosh; Tony Lindgren; Kristo, Tero; Paul Walmsley
Cc: Kevin Hilman; linux-arm-kernel@lists.infradead.org; linux-omap@vger.kernel.org; linux-kernel@vger.kernel.org; J, KEERTHY; Benoît Cousson
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

On 08/22/2014 07:02 AM, Nishanth Menon wrote:
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Add OMAP5/DRA74/72 CPUIDLE support.
>
> This patch adds MPUSS low power states in cpuidle.
>
>          C1 - CPU0 WFI + CPU1 WFI + MPU ON
>          C2 - CPU0 RET + CPU1 RET + MPU CSWR
>
> Tested on DRA74/72-EVM for C1 and C2 states.
>
> NOTE: DRA7 does not do voltage scaling as part of retention transition
> and has Mercury which speeds up transition paths - Latency numbers are
> based on measurements done by toggling GPIOs.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> [ j-keerthy@ti.com rework on 3.14]
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> [nm@ti.com: updates based on profiling, OMAP5 squashed]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>   arch/arm/mach-omap2/cpuidle44xx.c |   82 ++++++++++++++++++++++++++++++++++++-
>   arch/arm/mach-omap2/pm44xx.c      |    2 +-
>   2 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 2498ab0..8ad4f44 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -22,6 +22,7 @@
>   #include "common.h"
>   #include "pm.h"
>   #include "prm.h"
> +#include "soc.h"
>   #include "clockdomain.h"
>
>   #define MAX_CPUS    2
> @@ -31,6 +32,7 @@ struct idle_statedata {
>       u32 cpu_state;
>       u32 mpu_logic_state;
>       u32 mpu_state;
> +     u32 mpu_state_vote;
>   };
>
>   static struct idle_statedata omap4_idle_data[] = {
> @@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
>       },
>   };
>
> +static struct idle_statedata dra7_idle_data[] = {
> +     {
> +             .cpu_state = PWRDM_POWER_ON,
> +             .mpu_state = PWRDM_POWER_ON,
> +             .mpu_logic_state = PWRDM_POWER_ON,
> +     },
> +     {
> +             .cpu_state = PWRDM_POWER_RET,
> +             .mpu_state = PWRDM_POWER_RET,
> +             .mpu_logic_state = PWRDM_POWER_RET,
> +     },
> +};
> +
>   static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
>   static struct clockdomain *cpu_clkdm[MAX_CPUS];
>
>   static atomic_t abort_barrier;
>   static bool cpu_done[MAX_CPUS];
>   static struct idle_statedata *state_ptr = &omap4_idle_data[0];
> +static DEFINE_RAW_SPINLOCK(mpu_lock);
>
>   /* Private functions */
>
> @@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
>       return index;
>   }
>
> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> +                            struct cpuidle_driver *drv,
> +                            int index)
> +{
> +     struct idle_statedata *cx = state_ptr + index;
> +     unsigned long flag;
> +
> +     raw_spin_lock_irqsave(&mpu_lock, flag);

Why do you need this spin_lock_irqsave ? Aren't the local irqs already
disabled ?

[Santosh] Actually at one point of time before the idle consolidation the local
irq disable was inside the idle drivers. Now with that moved to core layer,
I think plain spin_lock/unlock() should work.

> +     cx->mpu_state_vote++;
> +     if (cx->mpu_state_vote == num_online_cpus()) {
> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> +     }
> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> +     raw_spin_lock_irqsave(&mpu_lock, flag);
> +     if (cx->mpu_state_vote == num_online_cpus())
> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> +     cx->mpu_state_vote--;
> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);

I am not sure that will work. What happens if a cpu exits idle and then
re-enter idle immediately ?

[Santosh] It works and that case is already taken care. CPU exist the idle and then votes
out for cluster state and if it reenters with the right targeted state, the cluster state would
be picked.


Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c

[Santosh] I am sure there will not be any issue with the long run test case here.
Lets see if Nishant sees anything otherwise

Regards,
Santosh

RE: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Shilimkar, Santosh]

Sorry for the format. Emailing from webmail.
________________________________________
From: Daniel Lezcano [daniel.lezcano@linaro.org]
Sent: Wednesday, September 17, 2014 2:49 PM
To: Menon, Nishanth; Shilimkar, Santosh; Tony Lindgren; Kristo, Tero; Paul Walmsley
Cc: Kevin Hilman; linux-arm-kernel@lists.infradead.org; linux-omap@vger.kernel.org; linux-kernel@vger.kernel.org; J, KEERTHY; Benoît Cousson
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

On 08/22/2014 07:02 AM, Nishanth Menon wrote:
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Add OMAP5/DRA74/72 CPUIDLE support.
>
> This patch adds MPUSS low power states in cpuidle.
>
>          C1 - CPU0 WFI + CPU1 WFI + MPU ON
>          C2 - CPU0 RET + CPU1 RET + MPU CSWR
>
> Tested on DRA74/72-EVM for C1 and C2 states.
>
> NOTE: DRA7 does not do voltage scaling as part of retention transition
> and has Mercury which speeds up transition paths - Latency numbers are
> based on measurements done by toggling GPIOs.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> [ j-keerthy@ti.com rework on 3.14]
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> [nm@ti.com: updates based on profiling, OMAP5 squashed]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>   arch/arm/mach-omap2/cpuidle44xx.c |   82 ++++++++++++++++++++++++++++++++++++-
>   arch/arm/mach-omap2/pm44xx.c      |    2 +-
>   2 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 2498ab0..8ad4f44 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -22,6 +22,7 @@
>   #include "common.h"
>   #include "pm.h"
>   #include "prm.h"
> +#include "soc.h"
>   #include "clockdomain.h"
>
>   #define MAX_CPUS    2
> @@ -31,6 +32,7 @@ struct idle_statedata {
>       u32 cpu_state;
>       u32 mpu_logic_state;
>       u32 mpu_state;
> +     u32 mpu_state_vote;
>   };
>
>   static struct idle_statedata omap4_idle_data[] = {
> @@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
>       },
>   };
>
> +static struct idle_statedata dra7_idle_data[] = {
> +     {
> +             .cpu_state = PWRDM_POWER_ON,
> +             .mpu_state = PWRDM_POWER_ON,
> +             .mpu_logic_state = PWRDM_POWER_ON,
> +     },
> +     {
> +             .cpu_state = PWRDM_POWER_RET,
> +             .mpu_state = PWRDM_POWER_RET,
> +             .mpu_logic_state = PWRDM_POWER_RET,
> +     },
> +};
> +
>   static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
>   static struct clockdomain *cpu_clkdm[MAX_CPUS];
>
>   static atomic_t abort_barrier;
>   static bool cpu_done[MAX_CPUS];
>   static struct idle_statedata *state_ptr = &omap4_idle_data[0];
> +static DEFINE_RAW_SPINLOCK(mpu_lock);
>
>   /* Private functions */
>
> @@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
>       return index;
>   }
>
> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> +                            struct cpuidle_driver *drv,
> +                            int index)
> +{
> +     struct idle_statedata *cx = state_ptr + index;
> +     unsigned long flag;
> +
> +     raw_spin_lock_irqsave(&mpu_lock, flag);

Why do you need this spin_lock_irqsave ? Aren't the local irqs already
disabled ?

[Santosh] Actually at one point of time before the idle consolidation the local
irq disable was inside the idle drivers. Now with that moved to core layer,
I think plain spin_lock/unlock() should work.

> +     cx->mpu_state_vote++;
> +     if (cx->mpu_state_vote == num_online_cpus()) {
> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> +     }
> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> +     raw_spin_lock_irqsave(&mpu_lock, flag);
> +     if (cx->mpu_state_vote == num_online_cpus())
> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> +     cx->mpu_state_vote--;
> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);

I am not sure that will work. What happens if a cpu exits idle and then
re-enter idle immediately ?

[Santosh] It works and that case is already taken care. CPU exist the idle and then votes
out for cluster state and if it reenters with the right targeted state, the cluster state would
be picked.


Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c

[Santosh] I am sure there will not be any issue with the long run test case here.
Lets see if Nishant sees anything otherwise

Regards,
Santosh--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Shilimkar, Santosh]

Sorry for the format. Emailing from webmail.
________________________________________
From: Daniel Lezcano [daniel.lezcano at linaro.org]
Sent: Wednesday, September 17, 2014 2:49 PM
To: Menon, Nishanth; Shilimkar, Santosh; Tony Lindgren; Kristo, Tero; Paul Walmsley
Cc: Kevin Hilman; linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org; linux-kernel at vger.kernel.org; J, KEERTHY; Beno?t Cousson
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

On 08/22/2014 07:02 AM, Nishanth Menon wrote:
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Add OMAP5/DRA74/72 CPUIDLE support.
>
> This patch adds MPUSS low power states in cpuidle.
>
>          C1 - CPU0 WFI + CPU1 WFI + MPU ON
>          C2 - CPU0 RET + CPU1 RET + MPU CSWR
>
> Tested on DRA74/72-EVM for C1 and C2 states.
>
> NOTE: DRA7 does not do voltage scaling as part of retention transition
> and has Mercury which speeds up transition paths - Latency numbers are
> based on measurements done by toggling GPIOs.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> [ j-keerthy at ti.com rework on 3.14]
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> [nm at ti.com: updates based on profiling, OMAP5 squashed]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>   arch/arm/mach-omap2/cpuidle44xx.c |   82 ++++++++++++++++++++++++++++++++++++-
>   arch/arm/mach-omap2/pm44xx.c      |    2 +-
>   2 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index 2498ab0..8ad4f44 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -22,6 +22,7 @@
>   #include "common.h"
>   #include "pm.h"
>   #include "prm.h"
> +#include "soc.h"
>   #include "clockdomain.h"
>
>   #define MAX_CPUS    2
> @@ -31,6 +32,7 @@ struct idle_statedata {
>       u32 cpu_state;
>       u32 mpu_logic_state;
>       u32 mpu_state;
> +     u32 mpu_state_vote;
>   };
>
>   static struct idle_statedata omap4_idle_data[] = {
> @@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
>       },
>   };
>
> +static struct idle_statedata dra7_idle_data[] = {
> +     {
> +             .cpu_state = PWRDM_POWER_ON,
> +             .mpu_state = PWRDM_POWER_ON,
> +             .mpu_logic_state = PWRDM_POWER_ON,
> +     },
> +     {
> +             .cpu_state = PWRDM_POWER_RET,
> +             .mpu_state = PWRDM_POWER_RET,
> +             .mpu_logic_state = PWRDM_POWER_RET,
> +     },
> +};
> +
>   static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
>   static struct clockdomain *cpu_clkdm[MAX_CPUS];
>
>   static atomic_t abort_barrier;
>   static bool cpu_done[MAX_CPUS];
>   static struct idle_statedata *state_ptr = &omap4_idle_data[0];
> +static DEFINE_RAW_SPINLOCK(mpu_lock);
>
>   /* Private functions */
>
> @@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
>       return index;
>   }
>
> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
> +                            struct cpuidle_driver *drv,
> +                            int index)
> +{
> +     struct idle_statedata *cx = state_ptr + index;
> +     unsigned long flag;
> +
> +     raw_spin_lock_irqsave(&mpu_lock, flag);

Why do you need this spin_lock_irqsave ? Aren't the local irqs already
disabled ?

[Santosh] Actually at one point of time before the idle consolidation the local
irq disable was inside the idle drivers. Now with that moved to core layer,
I think plain spin_lock/unlock() should work.

> +     cx->mpu_state_vote++;
> +     if (cx->mpu_state_vote == num_online_cpus()) {
> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
> +     }
> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
> +
> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
> +
> +     raw_spin_lock_irqsave(&mpu_lock, flag);
> +     if (cx->mpu_state_vote == num_online_cpus())
> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
> +     cx->mpu_state_vote--;
> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);

I am not sure that will work. What happens if a cpu exits idle and then
re-enter idle immediately ?

[Santosh] It works and that case is already taken care. CPU exist the idle and then votes
out for cluster state and if it reenters with the right targeted state, the cluster state would
be picked.


Could you try a long run of this little program:

https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c

[Santosh] I am sure there will not be any issue with the long run test case here.
Lets see if Nishant sees anything otherwise

Regards,
Santosh

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Daniel Lezcano]

On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
> Sorry for the format. Emailing from webmail.
> ________________________________________

[ ... ]

>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>> +                            struct cpuidle_driver *drv,
>> +                            int index)
>> +{
>> +     struct idle_statedata *cx = state_ptr + index;
>> +     unsigned long flag;
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>
> Why do you need this spin_lock_irqsave ? Aren't the local irqs already
> disabled ?
>
> [Santosh] Actually at one point of time before the idle consolidation the local
> irq disable was inside the idle drivers. Now with that moved to core layer,
> I think plain spin_lock/unlock() should work.

ok.

>> +     cx->mpu_state_vote++;
>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>> +     }
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>> +
>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>> +     if (cx->mpu_state_vote == num_online_cpus())
>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>> +     cx->mpu_state_vote--;
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>
> I am not sure that will work. What happens if a cpu exits idle and then
> re-enter idle immediately ?
>
> [Santosh] It works and that case is already taken care. CPU exist the idle and then votes
> out for cluster state and if it reenters with the right targeted state, the cluster state would
> be picked.

It isn't possible to have one cpu disabling the coherency, while the 
other one is looking for a lock ? Or eg. cpu0 is on WFI then cpu1 is the 
last entering idle. While cpu1 is entering 'lowpower', cpu0 exits the 
wfi check the state vote and set the power domain on. In the meantime 
cpu1 disables the coherency and cpu0 decrease the vote and release the 
lock. Could be possible there is a very small racy window here ?

> Could you try a long run of this little program:
>
> https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c
>
> [Santosh] I am sure there will not be any issue with the long run test case here.
> Lets see if Nishant sees anything otherwise

Ok. Make sure the cpu is effectively entering your C2 state with the 
sleep duration in the test program.


-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Daniel Lezcano]

On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
> Sorry for the format. Emailing from webmail.
> ________________________________________

[ ... ]

>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>> +                            struct cpuidle_driver *drv,
>> +                            int index)
>> +{
>> +     struct idle_statedata *cx = state_ptr + index;
>> +     unsigned long flag;
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>
> Why do you need this spin_lock_irqsave ? Aren't the local irqs already
> disabled ?
>
> [Santosh] Actually at one point of time before the idle consolidation the local
> irq disable was inside the idle drivers. Now with that moved to core layer,
> I think plain spin_lock/unlock() should work.

ok.

>> +     cx->mpu_state_vote++;
>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>> +     }
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>> +
>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>> +     if (cx->mpu_state_vote == num_online_cpus())
>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>> +     cx->mpu_state_vote--;
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>
> I am not sure that will work. What happens if a cpu exits idle and then
> re-enter idle immediately ?
>
> [Santosh] It works and that case is already taken care. CPU exist the idle and then votes
> out for cluster state and if it reenters with the right targeted state, the cluster state would
> be picked.

It isn't possible to have one cpu disabling the coherency, while the 
other one is looking for a lock ? Or eg. cpu0 is on WFI then cpu1 is the 
last entering idle. While cpu1 is entering 'lowpower', cpu0 exits the 
wfi check the state vote and set the power domain on. In the meantime 
cpu1 disables the coherency and cpu0 decrease the vote and release the 
lock. Could be possible there is a very small racy window here ?

> Could you try a long run of this little program:
>
> https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c
>
> [Santosh] I am sure there will not be any issue with the long run test case here.
> Lets see if Nishant sees anything otherwise

Ok. Make sure the cpu is effectively entering your C2 state with the 
sleep duration in the test program.


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

RE: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Shilimkar, Santosh]

________________________________________
From: Daniel Lezcano [daniel.lezcano@linaro.org]
Sent: Wednesday, September 17, 2014 8:22 PM
To: Shilimkar, Santosh; Menon, Nishanth; Tony Lindgren; Kristo, Tero; Paul Walmsley
Cc: Kevin Hilman; linux-arm-kernel@lists.infradead.org; linux-omap@vger.kernel.org; linux-kernel@vger.kernel.org; J, KEERTHY; Benoît Cousson
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
> Sorry for the format. Emailing from webmail.
> ________________________________________

[ ... ]


>> +     cx->mpu_state_vote++;
>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>> +     }
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>> +
>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>> +     if (cx->mpu_state_vote == num_online_cpus())
>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>> +     cx->mpu_state_vote--;
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>
> I am not sure that will work. What happens if a cpu exits idle and then
> re-enter idle immediately ?
>
> [Santosh] It works and that case is already taken care. CPU exist the idle and then votes
> out for cluster state and if it reenters with the right targeted state, the cluster state would
> be picked.

It isn't possible to have one cpu disabling the coherency, while the
other one is looking for a lock ? Or eg. cpu0 is on WFI then cpu1 is the
last entering idle. While cpu1 is entering 'lowpower', cpu0 exits the
wfi check the state vote and set the power domain on. In the meantime
cpu1 disables the coherency and cpu0 decrease the vote and release the
lock. Could be possible there is a very small racy window here ?

[Santosh] The coherency isn't disable by CPU. Thats actually taken care by
hardware. CPU takes it own power domain down and takes itself out of
coherency. The Coherency is always ON as long as there is a CPU ON
and SMP bit on that CPU is enabled.

The scenario, you mentioned can never happen on this hardware thanks
to the inbuilt smart hardware.

If you have more questions, lets discuss. I am around here at connect. ;-)

Regards,
Santosh

RE: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Shilimkar, Santosh]

________________________________________
From: Daniel Lezcano [daniel.lezcano@linaro.org]
Sent: Wednesday, September 17, 2014 8:22 PM
To: Shilimkar, Santosh; Menon, Nishanth; Tony Lindgren; Kristo, Tero; Paul Walmsley
Cc: Kevin Hilman; linux-arm-kernel@lists.infradead.org; linux-omap@vger.kernel.org; linux-kernel@vger.kernel.org; J, KEERTHY; Benoît Cousson
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
> Sorry for the format. Emailing from webmail.
> ________________________________________

[ ... ]


>> +     cx->mpu_state_vote++;
>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>> +     }
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>> +
>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>> +     if (cx->mpu_state_vote == num_online_cpus())
>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>> +     cx->mpu_state_vote--;
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>
> I am not sure that will work. What happens if a cpu exits idle and then
> re-enter idle immediately ?
>
> [Santosh] It works and that case is already taken care. CPU exist the idle and then votes
> out for cluster state and if it reenters with the right targeted state, the cluster state would
> be picked.

It isn't possible to have one cpu disabling the coherency, while the
other one is looking for a lock ? Or eg. cpu0 is on WFI then cpu1 is the
last entering idle. While cpu1 is entering 'lowpower', cpu0 exits the
wfi check the state vote and set the power domain on. In the meantime
cpu1 disables the coherency and cpu0 decrease the vote and release the
lock. Could be possible there is a very small racy window here ?

[Santosh] The coherency isn't disable by CPU. Thats actually taken care by
hardware. CPU takes it own power domain down and takes itself out of
coherency. The Coherency is always ON as long as there is a CPU ON
and SMP bit on that CPU is enabled.

The scenario, you mentioned can never happen on this hardware thanks
to the inbuilt smart hardware.

If you have more questions, lets discuss. I am around here at connect. ;-)

Regards,
Santosh--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Shilimkar, Santosh]

________________________________________
From: Daniel Lezcano [daniel.lezcano at linaro.org]
Sent: Wednesday, September 17, 2014 8:22 PM
To: Shilimkar, Santosh; Menon, Nishanth; Tony Lindgren; Kristo, Tero; Paul Walmsley
Cc: Kevin Hilman; linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org; linux-kernel at vger.kernel.org; J, KEERTHY; Beno?t Cousson
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
> Sorry for the format. Emailing from webmail.
> ________________________________________

[ ... ]


>> +     cx->mpu_state_vote++;
>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>> +     }
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>> +
>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>> +
>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>> +     if (cx->mpu_state_vote == num_online_cpus())
>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>> +     cx->mpu_state_vote--;
>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>
> I am not sure that will work. What happens if a cpu exits idle and then
> re-enter idle immediately ?
>
> [Santosh] It works and that case is already taken care. CPU exist the idle and then votes
> out for cluster state and if it reenters with the right targeted state, the cluster state would
> be picked.

It isn't possible to have one cpu disabling the coherency, while the
other one is looking for a lock ? Or eg. cpu0 is on WFI then cpu1 is the
last entering idle. While cpu1 is entering 'lowpower', cpu0 exits the
wfi check the state vote and set the power domain on. In the meantime
cpu1 disables the coherency and cpu0 decrease the vote and release the
lock. Could be possible there is a very small racy window here ?

[Santosh] The coherency isn't disable by CPU. Thats actually taken care by
hardware. CPU takes it own power domain down and takes itself out of
coherency. The Coherency is always ON as long as there is a CPU ON
and SMP bit on that CPU is enabled.

The scenario, you mentioned can never happen on this hardware thanks
to the inbuilt smart hardware.

If you have more questions, lets discuss. I am around here at connect. ;-)

Regards,
Santosh

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

On 09/17/2014 07:22 PM, Daniel Lezcano wrote:
> On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
[...]
>> Could you try a long run of this little program:
>>
>> https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c
>>
>> [Santosh] I am sure there will not be any issue with the long run test case here.
>> Lets see if Nishant sees anything otherwise
> 
> Ok. Make sure the cpu is effectively entering your C2 state with the 
> sleep duration in the test program.

Test kernel:
https://github.com/nmenon/linux-2.6-playground/commits/testing/tmlind-test-suspend-resume
(I decided to merge in various send for pull branches from maintainers
and apply cpuidle on top)..

Controlled test run as follows on 4 different impacted platforms and 1
platform as legacy reference.

What we are looking for is
> cpu1_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
RET:2677 indicated CPU1 hit C2
> cpu0_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
RET:2677 indicated CPU0 hit C2
> mpu_pwrdm (ON),OFF:0,RET:2667,INA:0,ON:2668,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:2667,RET-MEMBANK2-OFF:0
RET:2667 indicates that CPU0 and CPU1 managed to achieve RET together,
else by hardware constraints in place, MPU power domain will fail to
transition.

What I see in all cases below is that transitions do take place (C2 is
successfully hit).

Test #1: 120 seconds:
CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
1;./cpuidle_killer_120;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x

OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
base test vector
http://fpaste.org/134547/14110454/

OMAP5 uEVM: (2 a15)
http://fpaste.org/134546/10454181/

DRA74x: (2 a15)
http://fpaste.org/134543/11045286/

DRA72: (2 a15)
http://fpaste.org/134544/11045335/

AM572x(DRA74x variant): (2 A15)
http://fpaste.org/134545/10453761/


Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/)
CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
1;./cpuidle_killer_1200;sleep 1;cat
/sys/kernel/debug/pm_debug/count;set +x

OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
base test vector
http://fpaste.org/134563/41104728/

OMAP5 uEVM: (2 a15)
http://fpaste.org/134562/47221141/

DRA74x EVM: (2 a15)
http://fpaste.org/134559/11047098/

DRA72 EVM: (2 a15)
http://fpaste.org/134560/11047151/

AM572x EVM: (2 A15)
http://fpaste.org/134561/47189141/


-- 
Regards,
Nishanth Menon

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

On 09/17/2014 07:22 PM, Daniel Lezcano wrote:
> On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
[...]
>> Could you try a long run of this little program:
>>
>> https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c
>>
>> [Santosh] I am sure there will not be any issue with the long run test case here.
>> Lets see if Nishant sees anything otherwise
> 
> Ok. Make sure the cpu is effectively entering your C2 state with the 
> sleep duration in the test program.

Test kernel:
https://github.com/nmenon/linux-2.6-playground/commits/testing/tmlind-test-suspend-resume
(I decided to merge in various send for pull branches from maintainers
and apply cpuidle on top)..

Controlled test run as follows on 4 different impacted platforms and 1
platform as legacy reference.

What we are looking for is
> cpu1_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
RET:2677 indicated CPU1 hit C2
> cpu0_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
RET:2677 indicated CPU0 hit C2
> mpu_pwrdm (ON),OFF:0,RET:2667,INA:0,ON:2668,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:2667,RET-MEMBANK2-OFF:0
RET:2667 indicates that CPU0 and CPU1 managed to achieve RET together,
else by hardware constraints in place, MPU power domain will fail to
transition.

What I see in all cases below is that transitions do take place (C2 is
successfully hit).

Test #1: 120 seconds:
CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
1;./cpuidle_killer_120;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x

OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
base test vector
http://fpaste.org/134547/14110454/

OMAP5 uEVM: (2 a15)
http://fpaste.org/134546/10454181/

DRA74x: (2 a15)
http://fpaste.org/134543/11045286/

DRA72: (2 a15)
http://fpaste.org/134544/11045335/

AM572x(DRA74x variant): (2 A15)
http://fpaste.org/134545/10453761/


Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/)
CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
1;./cpuidle_killer_1200;sleep 1;cat
/sys/kernel/debug/pm_debug/count;set +x

OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
base test vector
http://fpaste.org/134563/41104728/

OMAP5 uEVM: (2 a15)
http://fpaste.org/134562/47221141/

DRA74x EVM: (2 a15)
http://fpaste.org/134559/11047098/

DRA72 EVM: (2 a15)
http://fpaste.org/134560/11047151/

AM572x EVM: (2 A15)
http://fpaste.org/134561/47189141/


-- 
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

On 09/18/2014 08:41 AM, Nishanth Menon wrote:
> On 09/17/2014 07:22 PM, Daniel Lezcano wrote:
>> On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
> [...]
>>> Could you try a long run of this little program:
>>>
>>> https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c
>>>
>>> [Santosh] I am sure there will not be any issue with the long run test case here.
>>> Lets see if Nishant sees anything otherwise
>>
>> Ok. Make sure the cpu is effectively entering your C2 state with the 
>> sleep duration in the test program.
> 
> Test kernel:
> https://github.com/nmenon/linux-2.6-playground/commits/testing/tmlind-test-suspend-resume
> (I decided to merge in various send for pull branches from maintainers
> and apply cpuidle on top)..
> 
> Controlled test run as follows on 4 different impacted platforms and 1
> platform as legacy reference.
> 
> What we are looking for is
>> cpu1_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> RET:2677 indicated CPU1 hit C2
>> cpu0_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> RET:2677 indicated CPU0 hit C2
>> mpu_pwrdm (ON),OFF:0,RET:2667,INA:0,ON:2668,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:2667,RET-MEMBANK2-OFF:0
> RET:2667 indicates that CPU0 and CPU1 managed to achieve RET together,
> else by hardware constraints in place, MPU power domain will fail to
> transition.
> 
> What I see in all cases below is that transitions do take place (C2 is
> successfully hit).
> 
> Test #1: 120 seconds:
> CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
> 1;./cpuidle_killer_120;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x
> 
> OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
> base test vector
> http://fpaste.org/134547/14110454/
> 
> OMAP5 uEVM: (2 a15)
> http://fpaste.org/134546/10454181/
> 
> DRA74x: (2 a15)
> http://fpaste.org/134543/11045286/
> 
> DRA72: (2 a15)
	  ^^
Correction should have been 1 a15

> http://fpaste.org/134544/11045335/
> 
> AM572x(DRA74x variant): (2 A15)
> http://fpaste.org/134545/10453761/
> 
> 
> Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/)
> CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
> 1;./cpuidle_killer_1200;sleep 1;cat
> /sys/kernel/debug/pm_debug/count;set +x
> 
> OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
> base test vector
> http://fpaste.org/134563/41104728/
> 
> OMAP5 uEVM: (2 a15)
> http://fpaste.org/134562/47221141/
> 
> DRA74x EVM: (2 a15)
> http://fpaste.org/134559/11047098/
> 
> DRA72 EVM: (2 a15)
	      ^^
Correction should have been 1 a15

> http://fpaste.org/134560/11047151/
> 
> AM572x EVM: (2 A15)
> http://fpaste.org/134561/47189141/
> 
> 


-- 
Regards,
Nishanth Menon

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

On 09/18/2014 08:41 AM, Nishanth Menon wrote:
> On 09/17/2014 07:22 PM, Daniel Lezcano wrote:
>> On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
> [...]
>>> Could you try a long run of this little program:
>>>
>>> https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c
>>>
>>> [Santosh] I am sure there will not be any issue with the long run test case here.
>>> Lets see if Nishant sees anything otherwise
>>
>> Ok. Make sure the cpu is effectively entering your C2 state with the 
>> sleep duration in the test program.
> 
> Test kernel:
> https://github.com/nmenon/linux-2.6-playground/commits/testing/tmlind-test-suspend-resume
> (I decided to merge in various send for pull branches from maintainers
> and apply cpuidle on top)..
> 
> Controlled test run as follows on 4 different impacted platforms and 1
> platform as legacy reference.
> 
> What we are looking for is
>> cpu1_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> RET:2677 indicated CPU1 hit C2
>> cpu0_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
> RET:2677 indicated CPU0 hit C2
>> mpu_pwrdm (ON),OFF:0,RET:2667,INA:0,ON:2668,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:2667,RET-MEMBANK2-OFF:0
> RET:2667 indicates that CPU0 and CPU1 managed to achieve RET together,
> else by hardware constraints in place, MPU power domain will fail to
> transition.
> 
> What I see in all cases below is that transitions do take place (C2 is
> successfully hit).
> 
> Test #1: 120 seconds:
> CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
> 1;./cpuidle_killer_120;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x
> 
> OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
> base test vector
> http://fpaste.org/134547/14110454/
> 
> OMAP5 uEVM: (2 a15)
> http://fpaste.org/134546/10454181/
> 
> DRA74x: (2 a15)
> http://fpaste.org/134543/11045286/
> 
> DRA72: (2 a15)
	  ^^
Correction should have been 1 a15

> http://fpaste.org/134544/11045335/
> 
> AM572x(DRA74x variant): (2 A15)
> http://fpaste.org/134545/10453761/
> 
> 
> Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/)
> CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
> 1;./cpuidle_killer_1200;sleep 1;cat
> /sys/kernel/debug/pm_debug/count;set +x
> 
> OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
> base test vector
> http://fpaste.org/134563/41104728/
> 
> OMAP5 uEVM: (2 a15)
> http://fpaste.org/134562/47221141/
> 
> DRA74x EVM: (2 a15)
> http://fpaste.org/134559/11047098/
> 
> DRA72 EVM: (2 a15)
	      ^^
Correction should have been 1 a15

> http://fpaste.org/134560/11047151/
> 
> AM572x EVM: (2 A15)
> http://fpaste.org/134561/47189141/
> 
> 


-- 
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

On 09/18/2014 08:50 AM, Nishanth Menon wrote:
> On 09/18/2014 08:41 AM, Nishanth Menon wrote:
>> On 09/17/2014 07:22 PM, Daniel Lezcano wrote:
>>> On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
>> [...]
>>>> Could you try a long run of this little program:
>>>>
>>>> https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c
>>>>
>>>> [Santosh] I am sure there will not be any issue with the long run test case here.
>>>> Lets see if Nishant sees anything otherwise
>>>
>>> Ok. Make sure the cpu is effectively entering your C2 state with the
>>> sleep duration in the test program.
>>
>> Test kernel:
>> https://github.com/nmenon/linux-2.6-playground/commits/testing/tmlind-test-suspend-resume
>> (I decided to merge in various send for pull branches from maintainers
>> and apply cpuidle on top)..
>>
>> Controlled test run as follows on 4 different impacted platforms and 1
>> platform as legacy reference.
>>
>> What we are looking for is
>>> cpu1_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
>> RET:2677 indicated CPU1 hit C2
>>> cpu0_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
>> RET:2677 indicated CPU0 hit C2
>>> mpu_pwrdm (ON),OFF:0,RET:2667,INA:0,ON:2668,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:2667,RET-MEMBANK2-OFF:0
>> RET:2667 indicates that CPU0 and CPU1 managed to achieve RET together,
>> else by hardware constraints in place, MPU power domain will fail to
>> transition.
>>
>> What I see in all cases below is that transitions do take place (C2 is
>> successfully hit).
>>
>> Test #1: 120 seconds:
>> CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
>> 1;./cpuidle_killer_120;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x
>>
>> OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
>> base test vector
>> http://fpaste.org/134547/14110454/
>>
>> OMAP5 uEVM: (2 a15)
>> http://fpaste.org/134546/10454181/
>>
>> DRA74x: (2 a15)
>> http://fpaste.org/134543/11045286/
>>
>> DRA72: (2 a15)
> 	  ^^
> Correction should have been 1 a15
>
>> http://fpaste.org/134544/11045335/
>>
>> AM572x(DRA74x variant): (2 A15)
>> http://fpaste.org/134545/10453761/
>>
>>
>> Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/)
>> CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
>> 1;./cpuidle_killer_1200;sleep 1;cat
>> /sys/kernel/debug/pm_debug/count;set +x
>>
>> OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
>> base test vector
>> http://fpaste.org/134563/41104728/
>>
>> OMAP5 uEVM: (2 a15)
>> http://fpaste.org/134562/47221141/
>>
>> DRA74x EVM: (2 a15)
>> http://fpaste.org/134559/11047098/
>>
>> DRA72 EVM: (2 a15)
> 	      ^^
> Correction should have been 1 a15
>
>> http://fpaste.org/134560/11047151/
>>
>> AM572x EVM: (2 A15)
>> http://fpaste.org/134561/47189141/
>>
>>

Daniel, Santosh: Gentle ping:

Any further comments? OR are we ok for this for being merged?


---
Regards,
Nishanth Menon

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

On 09/18/2014 08:50 AM, Nishanth Menon wrote:
> On 09/18/2014 08:41 AM, Nishanth Menon wrote:
>> On 09/17/2014 07:22 PM, Daniel Lezcano wrote:
>>> On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
>> [...]
>>>> Could you try a long run of this little program:
>>>>
>>>> https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c
>>>>
>>>> [Santosh] I am sure there will not be any issue with the long run test case here.
>>>> Lets see if Nishant sees anything otherwise
>>>
>>> Ok. Make sure the cpu is effectively entering your C2 state with the
>>> sleep duration in the test program.
>>
>> Test kernel:
>> https://github.com/nmenon/linux-2.6-playground/commits/testing/tmlind-test-suspend-resume
>> (I decided to merge in various send for pull branches from maintainers
>> and apply cpuidle on top)..
>>
>> Controlled test run as follows on 4 different impacted platforms and 1
>> platform as legacy reference.
>>
>> What we are looking for is
>>> cpu1_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
>> RET:2677 indicated CPU1 hit C2
>>> cpu0_pwrdm (ON),OFF:0,RET:2677,INA:0,ON:2678,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
>> RET:2677 indicated CPU0 hit C2
>>> mpu_pwrdm (ON),OFF:0,RET:2667,INA:0,ON:2668,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:2667,RET-MEMBANK2-OFF:0
>> RET:2667 indicates that CPU0 and CPU1 managed to achieve RET together,
>> else by hardware constraints in place, MPU power domain will fail to
>> transition.
>>
>> What I see in all cases below is that transitions do take place (C2 is
>> successfully hit).
>>
>> Test #1: 120 seconds:
>> CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
>> 1;./cpuidle_killer_120;sleep 1;cat /sys/kernel/debug/pm_debug/count;set +x
>>
>> OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
>> base test vector
>> http://fpaste.org/134547/14110454/
>>
>> OMAP5 uEVM: (2 a15)
>> http://fpaste.org/134546/10454181/
>>
>> DRA74x: (2 a15)
>> http://fpaste.org/134543/11045286/
>>
>> DRA72: (2 a15)
> 	  ^^
> Correction should have been 1 a15
>
>> http://fpaste.org/134544/11045335/
>>
>> AM572x(DRA74x variant): (2 A15)
>> http://fpaste.org/134545/10453761/
>>
>>
>> Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/)
>> CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
>> 1;./cpuidle_killer_1200;sleep 1;cat
>> /sys/kernel/debug/pm_debug/count;set +x
>>
>> OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
>> base test vector
>> http://fpaste.org/134563/41104728/
>>
>> OMAP5 uEVM: (2 a15)
>> http://fpaste.org/134562/47221141/
>>
>> DRA74x EVM: (2 a15)
>> http://fpaste.org/134559/11047098/
>>
>> DRA72 EVM: (2 a15)
> 	      ^^
> Correction should have been 1 a15
>
>> http://fpaste.org/134560/11047151/
>>
>> AM572x EVM: (2 A15)
>> http://fpaste.org/134561/47189141/
>>
>>

Daniel, Santosh: Gentle ping:

Any further comments? OR are we ok for this for being merged?


---
Regards,
Nishanth Menon

Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

Daniel,
On 08:02-20140922, Nishanth Menon wrote:
[...]
> >>Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/)

Santosh wanted me to make certain that the following is noted;
^^ -> is around 20 mins. -> So highlighting again.. I assume this is
long enough test duration you requested for.

> >>CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
> >>1;./cpuidle_killer_1200;sleep 1;cat
> >>/sys/kernel/debug/pm_debug/count;set +x
> >>
> >>OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
> >>base test vector
> >>http://fpaste.org/134563/41104728/
> >>
> >>OMAP5 uEVM: (2 a15)
> >>http://fpaste.org/134562/47221141/
> >>
> >>DRA74x EVM: (2 a15)
> >>http://fpaste.org/134559/11047098/
> >>
> >>DRA72 EVM: (2 a15)
> >	      ^^
> >Correction should have been 1 a15
> >
> >>http://fpaste.org/134560/11047151/
> >>
> >>AM572x EVM: (2 A15)
> >>http://fpaste.org/134561/47189141/
> >>
> >>
> 
> Daniel, Santosh: Gentle ping:
> 
> Any further comments? OR are we ok for this for being merged?
> 
-- 
Regards,
Nishanth Menon

[PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

[Nishanth Menon]

Daniel,
On 08:02-20140922, Nishanth Menon wrote:
[...]
> >>Test #2: 1200 seconds: (http://fpaste.org/134564/47289141/)

Santosh wanted me to make certain that the following is noted;
^^ -> is around 20 mins. -> So highlighting again.. I assume this is
long enough test duration you requested for.

> >>CMD: set -x;uname -a;cat /sys/kernel/debug/pm_debug/count;sleep
> >>1;./cpuidle_killer_1200;sleep 1;cat
> >>/sys/kernel/debug/pm_debug/count;set +x
> >>
> >>OMAP4 Panda-ES: (2 a9) - not impacted as part of this patch - just
> >>base test vector
> >>http://fpaste.org/134563/41104728/
> >>
> >>OMAP5 uEVM: (2 a15)
> >>http://fpaste.org/134562/47221141/
> >>
> >>DRA74x EVM: (2 a15)
> >>http://fpaste.org/134559/11047098/
> >>
> >>DRA72 EVM: (2 a15)
> >	      ^^
> >Correction should have been 1 a15
> >
> >>http://fpaste.org/134560/11047151/
> >>
> >>AM572x EVM: (2 A15)
> >>http://fpaste.org/134561/47189141/
> >>
> >>
> 
> Daniel, Santosh: Gentle ping:
> 
> Any further comments? OR are we ok for this for being merged?
> 
-- 
Regards,
Nishanth Menon