Skip to contentSkip to conversation

OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

PATCH Superseded Santosh Shilimkar 2 participants 42 messages Mar 10, 2011 – Mar 28, 2011

Subsystems (4)

v2 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

V2 updates:
Rebased on latest pm-core branch and fixes below comments
from Kevin Hilman <[email protected]>.
- All acronym fixes
- Use WARN_ON() instead of BUG_ON() with graceful exit.
- Export omap4_get_base*() rather than global address pointers
- CPUidle prepare() hook + hotplug notifier to manage C-state dynamically.
- Dropped debugfs way of changing C-state valid flags in favor of above.

Full series with cherry-picked dependencies are available on below git branch.

git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_for-next_v2

This series adds OMAP4 suspend and cpuidle support till MPU subsystem (MPUSS) off-mode. The suspend on SMP machines uses cpu-hotplug infrastructure to take down the non-boot CPUs. We put secondary CPU(CPU1 in OMAP4) to OFF state via cpu-hotplug.
In cpuidle too, low power states are attempted only when the CPU1 is put to OFF state via cpu-hotplug because of hardware constraints.

Timer wakeup from suspend, debug pm counters and enable_off_mode provisions are supported as well.

Special thanks to Kevin Hilman <[email protected]> for doing detail off-the list reviews.

The patches are generated against mainline 2.6.38-rc5 and tested with OMAP4430 SDP and OMAP4 PANDA board. Any OMAP4 board with ES2.X silicon, below features should work with this series. On ES1.0, these PM features are not supported.
1. CPU hotplug (CPU is put into off-mode)
2. Suspend (Both CPUs put to off-mode and MPUSS to OFF/RET)
3. CPUILDE with below C-states.
C1 - CPU0 ON + CPU1 ON/OFF + MPU ON + CORE ON C2 - CPU0 ON + CPU1 OFF + MPU ON + CORE ON C3 - CPU0 OFF + CPU1 OFF + MPU CSWR + CORE ON C4 - CPU0 OFF + CPU1 OFF + MPU OFF + CORE ON

In OMAP4 mpuss consist of dual Cortex-A9 with per-cpu local timers GIC(Generic Interrupt Controller), SCU(Snoop Control Unit) and PL310 L2 cache controller and CPU0/CPU1 LPRM modules.
CPU0, CPU1 and MPUSS have there own power domain and hence multiple low power state combinations are possible. The CPU10 and CPU1 Close switch Retention(CSWR) isn't supported by hardware. Based on various studies, measurements, hardware constraints and recommendations from hardware team, only below low power modes are supported on OMAP4.
----------------------------------------
CPU0 CPU1 MPUSS
----------------------------------------
ON ON ON
OFF OFF CSWR
OFF OFF OSWR
OFF OFF OFF
-----------------------------------------
Note: CPU0 is the master core and it is the last CPU to go down and first to wake-up when MPUSS low power states are attempted

OSWR(Open Switch Retention) is not added as part of this series because it needs some power domain level support which isn't ready yet.
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg38667.html

Powerdomain INACTIVE support is also dropped because of its inconsistency between OMAP4 and OMAP3.
More information on this thread -

	http://www.spinics.net/lists/linux-omap/msg45370.html

This series has a dependency on few patches from below series.
- GIC and SCU patches from [1] (queued up in RMK's for-next)
- Local Timer patches from [2] (queued up in RMK's for-next)
- Not clearing the static deps hack which is getting sorted out.

The cpu-hotplug and suspend works with omap2plus_defconfig. Not to damage your file system with current omap2plus_defconfig, disable ARCH_OMAP2 so that V6 and V7 support is not built together with SMP.
To tryout cpuidle, CONFIG_CPU_IDLE needs to be enabled in the build.

CPU-HOTPLUG commands :
offline : $echo 0 > /sys/devices/system/cpu/cpu1/online online : $echo 1 > /sys/devices/system/cpu/cpu1/online

Suspend :$echo mem > /sys/power/state

cpuilde : To trigger cpuidle deeper C-states on OMAP4, CPU1 needs
to be offlied
$echo 0 > /sys/devices/system/cpu/cpu1/online

To see PM debug counters,
$mount -t debugfs debugfs /proc/sys/debug/
$cat /proc/sys/debug/pm_debug/count
off-mode debugfs control:
enable: $echo 1 > /proc/sys/debug/pm_debug/enable_off_mode
disable: $echo 0 > /proc/sys/debug/pm_debug/enable_off_mode

Summary:

Rajendra Nayak (1):
OMAP4: cpuidle: Basic CPUidle support

Santosh Shilimkar (18):
OMAP4: PM: Add omap WakeupGen module support
OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
OMAP4: PM: Export omap4_get_base*() rather than global address
pointers
OMAP4: PM: Add SAR RAM support
OMAP4: PM: Add CPUX OFF mode support
OMAP4: PM: Initialise all the clockdomains to supported states
OMAP4: PM: Program CPU1 to hit OFF when off-lined
OMAP4: PM: CPU1 wakeup workaround from Low power modes
OMAP4: PM: Add GIC distributor and interface enable/disable accessory
api
OMAP4: PM: Add GIC save/restore support
OMAP4: PM: Add WakeupGen save/restore support
OMAP4: PM: Add L2 cache lowpower support
OMAP4: suspend: Add MPUSS RET and OFF support
OMAP4: pm-debug: Add wakeup timer and debug counters
OMAP4: cpuidle: Add MPUSS RET OFF states
OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states.
OMAP4: cpuidle: Add CPU hotplug notifier and prepare() hook.
OMAP4: Remove un-used do_wfi() macro.

 arch/arm/mach-omap2/Makefile                      |    8 +-
 arch/arm/mach-omap2/cpuidle44xx.c                 |  352 ++++++++++++++++
 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |   41 ++
 arch/arm/mach-omap2/include/mach/omap4-common.h   |   73 +++-
 arch/arm/mach-omap2/omap-hotplug.c                |   30 ++-
 arch/arm/mach-omap2/omap-smp.c                    |   32 ++-
 arch/arm/mach-omap2/omap-wakeupgen.c              |  319 +++++++++++++++
 arch/arm/mach-omap2/omap4-common.c                |   85 ++++-
 arch/arm/mach-omap2/omap4-mpuss-lowpower.c        |  451 +++++++++++++++++++++
 arch/arm/mach-omap2/omap4-sar-layout.h            |   66 +++
 arch/arm/mach-omap2/pm-debug.c                    |   12 +-
 arch/arm/mach-omap2/pm.h                          |    2 +
 arch/arm/mach-omap2/pm44xx.c                      |  119 ++++++-
 arch/arm/mach-omap2/sleep44xx.S                   |  400 ++++++++++++++++++
 arch/arm/plat-omap/include/plat/omap44xx.h        |    1 +
 15 files changed, 1958 insertions(+), 33 deletions(-)
 create mode 100644 arch/arm/mach-omap2/cpuidle44xx.c
 create mode 100644 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
 create mode 100644 arch/arm/mach-omap2/omap-wakeupgen.c
 create mode 100644 arch/arm/mach-omap2/omap4-mpuss-lowpower.c
 create mode 100644 arch/arm/mach-omap2/omap4-sar-layout.h
 create mode 100644 arch/arm/mach-omap2/sleep44xx.S

Regrads,
Santosh
[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42939.html
[2] http://www.spinics.net/lists/linux-omap/msg45710.html

#1 lore raw

PATCH v2 1/19 OMAP4: PM: Add omap WakeupGen module support

This patch adds OMAP WakeupGen support. The WakeupGen unit is responsible for generating wakeup event from the incoming interrupts and enable bits. The WakeupGen is implemented in MPU Always-On power domain. During normal operation, WakeupGen delivers external interrupts directly to the GIC. When the CPUx asserts StandbyWFI, indicating it wants to enter lowpower state, the Standby Controller checks with the WakeupGen unit using the idlereq/idleack handshake to make sure there is no incoming interrupts. The GIC and WakeupGen needs to be kept in synchronisation for proper interrupt functioning.

Hence this patch hooks up the omap WakeupGen mask/unmask along with GIC using architecture specific hooks.

---
 arch/arm/mach-omap2/Makefile                      |    3 +-
 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |   40 ++++
 arch/arm/mach-omap2/omap-wakeupgen.c              |  238 +++++++++++++++++++++
 arch/arm/mach-omap2/omap4-common.c                |    3 +
 4 files changed, 283 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
 create mode 100644 arch/arm/mach-omap2/omap-wakeupgen.c
arch/arm/mach-omap2/Makefile +2 -1
index 4edac5d..1bf9cd2 100644
@@ -24,7 +24,8 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
 obj-$(CONFIG_SMP)			+= omap-smp.o omap-headsmp.o
 obj-$(CONFIG_LOCAL_TIMERS)		+= timer-mpu.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= omap-hotplug.o
-obj-$(CONFIG_ARCH_OMAP4)		+= omap44xx-smc.o omap4-common.o
+obj-$(CONFIG_ARCH_OMAP4)		+= omap44xx-smc.o omap4-common.o \
+					   omap-wakeupgen.o
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
arch/arm/mach-omap2/include/mach/omap-wakeupgen.h new file +40 -0
new file mode 100644
index 0000000..f10d106
@@ -0,0 +1,40 @@
+/*
+ * OMAP WakeupGen header file
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Written by Santosh Shilimkar <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef OMAP_ARCH_WAKEUPGEN_H
+#define OMAP_ARCH_WAKEUPGEN_H
+
+#define OMAP_WKG_CONTROL_0			0x00
+#define OMAP_WKG_ENB_A_0			0x10
+#define OMAP_WKG_ENB_B_0			0x14
+#define OMAP_WKG_ENB_C_0			0x18
+#define OMAP_WKG_ENB_D_0			0x1c
+#define OMAP_WKG_ENB_SECURE_A_0			0x20
+#define OMAP_WKG_ENB_SECURE_B_0			0x24
+#define OMAP_WKG_ENB_SECURE_C_0			0x28
+#define OMAP_WKG_ENB_SECURE_D_0			0x2c
+#define OMAP_WKG_ENB_A_1			0x410
+#define OMAP_WKG_ENB_B_1			0x414
+#define OMAP_WKG_ENB_C_1			0x418
+#define OMAP_WKG_ENB_D_1			0x41c
+#define OMAP_WKG_ENB_SECURE_A_1			0x420
+#define OMAP_WKG_ENB_SECURE_B_1			0x424
+#define OMAP_WKG_ENB_SECURE_C_1			0x428
+#define OMAP_WKG_ENB_SECURE_D_1			0x42c
+#define OMAP_AUX_CORE_BOOT_0			0x800
+#define OMAP_AUX_CORE_BOOT_1			0x804
+#define OMAP_PTMSYNCREQ_MASK			0xc00
+#define OMAP_PTMSYNCREQ_EN			0xc04
+#define OMAP_TIMESTAMPCYCLELO			0xc08
+#define OMAP_TIMESTAMPCYCLEHI			0xc0c
+
+extern int __init omap_wakeupgen_init(void);
+extern void omap_wakeupgen_irqmask_all(unsigned int cpu, unsigned int set);
+#endif
arch/arm/mach-omap2/omap-wakeupgen.c new file +238 -0

238 lines not on this page · raw message

arch/arm/mach-omap2/omap4-common.c +3 -0
index 1926864..559d227 100644
@@ -21,6 +21,7 @@
 
 #include <mach/hardware.h>
 #include <mach/omap4-common.h>
+#include <mach/omap-wakeupgen.h>
 
 #ifdef CONFIG_CACHE_L2X0
 void __iomem *l2cache_base;
@@ -41,6 +42,8 @@ void __init gic_init_irq(void)
 	gic_cpu_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512);
 	BUG_ON(!gic_cpu_base);
 
+	omap_wakeupgen_init();
+
 	gic_init(0, 29, gic_dist_base_addr, gic_cpu_base);
 }
 
Signature · 1 line
1.6.0.4
#2 lore raw

PATCH v2 2/19 OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit

In reply to Santosh Shilimkar

OMAP L2X0 and GIC initialisation code uses BUG_ON() for the ioremap() failure scenarios.

Use WARN_ON() instead and allow graceful function exits.

This was suggsted by Kevin Hilman <[email protected]> during OMAP4 PM code review.

---
 arch/arm/mach-omap2/omap4-common.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)
arch/arm/mach-omap2/omap4-common.c +6 -3
index 559d227..8f9b97d 100644
@@ -36,11 +36,13 @@ void __init gic_init_irq(void)
 
 	/* Static mapping, never released */
 	gic_dist_base_addr = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K);
-	BUG_ON(!gic_dist_base_addr);
+	if (WARN_ON(!gic_dist_base_addr))
+		return;
 
 	/* Static mapping, never released */
 	gic_cpu_base = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512);
-	BUG_ON(!gic_cpu_base);
+	if (WARN_ON(!gic_cpu_base))
+		return;
 
 	omap_wakeupgen_init();
 
@@ -68,7 +70,8 @@ static int __init omap_l2_cache_init(void)
 
 	/* Static mapping, never released */
 	l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K);
-	BUG_ON(!l2cache_base);
+	if (WARN_ON(!l2cache_base))
+		return -ENODEV;
 
 	/*
 	 * 16-way associativity, parity disabled
Signature · 1 line
1.6.0.4
#3 lore raw

PATCH v2 3/19 OMAP4: PM: Export omap4_get_base*() rather than global address pointers

In reply to Santosh Shilimkar

This patch exports APIs to get base address for GIC distributor, CPU interface, SCU and PL310 L2 Cache which are used in OMAP4 PM code.

This was suggested by Kevin Hilman <[email protected]> during OMAP4 PM code review.

---
 arch/arm/mach-omap2/include/mach/omap4-common.h |   13 +++++++++++--
 arch/arm/mach-omap2/omap-smp.c                  |    6 ++++++
 arch/arm/mach-omap2/omap4-common.c              |   21 ++++++++++++++++++---
 3 files changed, 35 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/include/mach/omap4-common.h +11 -2
index de441c0..106edef 100644
@@ -25,11 +25,20 @@
 #endif
 
 #ifdef CONFIG_CACHE_L2X0
-extern void __iomem *l2cache_base;
+extern void __iomem *omap4_get_l2cache_base(void);
 #endif
 
-extern void __iomem *gic_dist_base_addr;
+#ifdef CONFIG_SMP
+extern void __iomem *omap4_get_scu_base(void);
+#else
+static inline void __iomem *omap4_get_scu_base(void)
+{
+	return NULL;
+}
+#endif
 
+extern void __iomem *omap4_get_gic_dist_base(void);
+extern void __iomem *omap4_get_gic_cpu_base(void);
 extern void __init gic_init_irq(void);
 extern void omap_smc1(u32 fn, u32 arg);
 
arch/arm/mach-omap2/omap-smp.c +6 -0
index b66cfe8..4fcaa4a 100644
@@ -30,6 +30,12 @@ static void __iomem *scu_base;
 
 static DEFINE_SPINLOCK(boot_lock);
 
+
+void __iomem *omap4_get_scu_base(void)
+{
+	return scu_base;
+}
+
 void __cpuinit platform_secondary_init(unsigned int cpu)
 {
 	/*
arch/arm/mach-omap2/omap4-common.c +18 -3
index 8f9b97d..fdacb9e 100644
@@ -24,15 +24,25 @@
 #include <mach/omap-wakeupgen.h>
 
 #ifdef CONFIG_CACHE_L2X0
-void __iomem *l2cache_base;
+static void __iomem *l2cache_base;
 #endif
 
-void __iomem *gic_dist_base_addr;
+static void __iomem *gic_dist_base_addr;
+static void __iomem *gic_cpu_base;
 
 
+void __iomem *omap4_get_gic_dist_base(void)
+{
+	return gic_dist_base_addr;
+}
+
+void __iomem *omap4_get_gic_cpu_base(void)
+{
+	return gic_cpu_base;
+}
+
 void __init gic_init_irq(void)
 {
-	void __iomem *gic_cpu_base;
 
 	/* Static mapping, never released */
 	gic_dist_base_addr = ioremap(OMAP44XX_GIC_DIST_BASE, SZ_4K);
@@ -51,6 +61,11 @@ void __init gic_init_irq(void)
 
 #ifdef CONFIG_CACHE_L2X0
 
+void __iomem *omap4_get_l2cache_base(void)
+{
+	return l2cache_base;
+}
+
 static void omap4_l2x0_disable(void)
 {
 	/* Disable PL310 L2 Cache controller */
Signature · 1 line
1.6.0.4
#4 lore raw

PATCH v2 4/19 OMAP4: PM: Add SAR RAM support

In reply to Santosh Shilimkar

This patch adds SAR RAM support on OMAP4430. SAR RAM used to save and restore the HW context in low power modes.

---
 arch/arm/mach-omap2/include/mach/omap4-common.h |    1 +
 arch/arm/mach-omap2/omap4-common.c              |   31 ++++++++++++++++++++++-
 arch/arm/mach-omap2/omap4-sar-layout.h          |   22 ++++++++++++++++
 arch/arm/plat-omap/include/plat/omap44xx.h      |    1 +
 4 files changed, 54 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/omap4-sar-layout.h
arch/arm/mach-omap2/include/mach/omap4-common.h +1 -0
index 106edef..284180c 100644
@@ -39,6 +39,7 @@ static inline void __iomem *omap4_get_scu_base(void)
 
 extern void __iomem *omap4_get_gic_dist_base(void);
 extern void __iomem *omap4_get_gic_cpu_base(void);
+extern void __iomem *omap4_get_sar_ram_base(void);
 extern void __init gic_init_irq(void);
 extern void omap_smc1(u32 fn, u32 arg);
 
arch/arm/mach-omap2/omap4-common.c +30 -1
index fdacb9e..97d7d8a 100644
@@ -23,13 +23,15 @@
 #include <mach/omap4-common.h>
 #include <mach/omap-wakeupgen.h>
 
+#include "omap4-sar-layout.h"
+
 #ifdef CONFIG_CACHE_L2X0
 static void __iomem *l2cache_base;
 #endif
 
 static void __iomem *gic_dist_base_addr;
 static void __iomem *gic_cpu_base;
-
+static void __iomem *sar_ram_base;
 
 void __iomem *omap4_get_gic_dist_base(void)
 {
@@ -125,3 +127,30 @@ static int __init omap_l2_cache_init(void)
 }
 early_initcall(omap_l2_cache_init);
 #endif
+
+void __iomem *omap4_get_sar_ram_base(void)
+{
+	return sar_ram_base;
+}
+
+/*
+ * SAR RAM used to save and restore the HW
+ * context in low power modes
+ */
+static int __init omap4_sar_ram_init(void)
+{
+	/*
+	 * To avoid code running on other OMAPs in
+	 * multi-omap builds
+	 */
+	if (!cpu_is_omap44xx())
+		return -ENODEV;
+
+	/* Static mapping, never released */
+	sar_ram_base = ioremap(OMAP44XX_SAR_RAM_BASE, SZ_8K);
+	if (WARN_ON(!sar_ram_base))
+		return -ENODEV;
+
+	return 0;
+}
+early_initcall(omap4_sar_ram_init);
arch/arm/mach-omap2/omap4-sar-layout.h new file +22 -0
new file mode 100644
index 0000000..1cfb4dd
@@ -0,0 +1,22 @@
+/*
+ * omap4-sar-layout.h: OMAP4 SAR RAM layout header file
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Santosh Shilimkar <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef OMAP_ARCH_OMAP4_SAR_LAYOUT_H
+#define OMAP_ARCH_OMAP4_SAR_LAYOUT_H
+
+/*
+ * SAR BANK offsets from base address OMAP44XX_SAR_RAM_BASE
+ */
+#define SAR_BANK1_OFFSET		0x0000
+#define SAR_BANK2_OFFSET		0x1000
+#define SAR_BANK3_OFFSET		0x2000
+#define SAR_BANK4_OFFSET		0x3000
+
+#endif
arch/arm/plat-omap/include/plat/omap44xx.h +1 -0
index ea2b8a6..c0d478e 100644
@@ -45,6 +45,7 @@
 #define OMAP44XX_WKUPGEN_BASE		0x48281000
 #define OMAP44XX_MCPDM_BASE		0x40132000
 #define OMAP44XX_MCPDM_L3_BASE		0x49032000
+#define OMAP44XX_SAR_RAM_BASE		0x4a326000
 
 #define OMAP44XX_MAILBOX_BASE		(L4_44XX_BASE + 0xF4000)
 #define OMAP44XX_HSUSB_OTG_BASE		(L4_44XX_BASE + 0xAB000)
Signature · 1 line
1.6.0.4
#5 lore raw

PATCH v2 5/19 OMAP4: PM: Add CPUX OFF mode support

In reply to Santosh Shilimkar

This patch adds the CPU0 and CPU1 off mode support. CPUX close switch retention (CSWR) is not supported by hardware design.

The CPUx OFF mode isn't supported on OMAP4430 ES1.0

CPUx sleep code is common for hotplug, suspend and CPUilde.

---
 arch/arm/mach-omap2/Makefile                    |    4 +-
 arch/arm/mach-omap2/include/mach/omap4-common.h |   46 +++
 arch/arm/mach-omap2/omap4-mpuss-lowpower.c      |  240 ++++++++++++++++
 arch/arm/mach-omap2/omap4-sar-layout.h          |   11 +
 arch/arm/mach-omap2/pm44xx.c                    |    6 +
 arch/arm/mach-omap2/sleep44xx.S                 |  335 +++++++++++++++++++++++
 6 files changed, 641 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/omap4-mpuss-lowpower.c
 create mode 100644 arch/arm/mach-omap2/sleep44xx.S
arch/arm/mach-omap2/Makefile +3 -1
index 1bf9cd2..04b97bb 100644
@@ -63,13 +63,15 @@ obj-$(CONFIG_ARCH_OMAP2)		+= pm24xx.o
 obj-$(CONFIG_ARCH_OMAP2)		+= sleep24xx.o pm_bus.o
 obj-$(CONFIG_ARCH_OMAP3)		+= pm34xx.o sleep34xx.o \
 					   cpuidle34xx.o pm_bus.o
-obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o pm_bus.o
+obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o pm_bus.o \
+					   omap4-mpuss-lowpower.o sleep44xx.o
 obj-$(CONFIG_PM_DEBUG)			+= pm-debug.o
 obj-$(CONFIG_OMAP_SMARTREFLEX)          += sr_device.o smartreflex.o
 obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)	+= smartreflex-class3.o
 
 AFLAGS_sleep24xx.o			:=-Wa,-march=armv6
 AFLAGS_sleep34xx.o			:=-Wa,-march=armv7-a
+AFLAGS_sleep44xx.o			:=-Wa,-march=armv7-a
 
 ifeq ($(CONFIG_PM_VERBOSE),y)
 CFLAGS_pm_bus.o				+= -DDEBUG
arch/arm/mach-omap2/include/mach/omap4-common.h +46 -0

56 lines not on this page · raw message

arch/arm/mach-omap2/omap4-mpuss-lowpower.c new file +240 -0

240 lines not on this page · raw message

arch/arm/mach-omap2/omap4-sar-layout.h +11 -0
index 1cfb4dd..8b71b1e 100644
@@ -19,4 +19,15 @@
 #define SAR_BANK3_OFFSET		0x2000
 #define SAR_BANK4_OFFSET		0x3000
 
+/* Scratch pad memory offsets from SAR_BANK1 */
+#define CPU0_SAVE_OFFSET			0xb00
+#define CPU1_SAVE_OFFSET			0xc00
+#define MMU_OFFSET				0xd00
+#define SCU_OFFSET0				0xd20
+#define SCU_OFFSET1				0xd24
+
+/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
+#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET		0xa04
+#define CPU1_WAKEUP_NS_PA_ADDR_OFFSET		0xa08
+
 #endif
arch/arm/mach-omap2/pm44xx.c +6 -0
index 76cfff2..7502723 100644
@@ -111,6 +111,12 @@ static int __init omap4_pm_init(void)
 		pr_err("Failed to setup powerdomains\n");
 		goto err2;
 	}
+
+	ret = omap4_mpuss_init();
+	if (ret) {
+		pr_err("Failed to initialise OMAP4 MPUSS\n");
+		goto err2;
+	}
 #endif
 
 #ifdef CONFIG_SUSPEND
arch/arm/mach-omap2/sleep44xx.S new file +335 -0

335 lines not on this page · raw message

Signature · 1 line
1.6.0.4
#6 lore raw

PATCH v2 6/19 OMAP4: PM: Initialise all the clockdomains to supported states

In reply to Santosh Shilimkar

Initialise hardware supervised mode for all clockdomains if it's supported. Initiate sleep transition for other clockdomains, if they are not being used.

---
 arch/arm/mach-omap2/pm44xx.c |   22 +++++++++++++++++++++-
 1 files changed, 21 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/pm44xx.c +21 -1
index 7502723..d55a9b8 100644
@@ -16,9 +16,11 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 
-#include "powerdomain.h"
 #include <mach/omap4-common.h>
 
+#include "powerdomain.h"
+#include "clockdomain.h"
+
 struct power_state {
 	struct powerdomain *pwrdm;
 	u32 next_state;
@@ -73,6 +75,22 @@ static const struct platform_suspend_ops omap_pm_ops = {
 };
 #endif /* CONFIG_SUSPEND */
 
+/*
+ * Enable hardware supervised mode for all clockdomains if it's
+ * supported. Initiate sleep transition for other clockdomains, if
+ * they are not used
+ */
+static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
+{
+	if (clkdm->flags & CLKDM_CAN_ENABLE_AUTO)
+		clkdm_allow_idle(clkdm);
+	else if (clkdm->flags & CLKDM_CAN_FORCE_SLEEP &&
+			atomic_read(&clkdm->usecount) == 0)
+		clkdm_sleep(clkdm);
+	return 0;
+}
+
+
 static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 {
 	struct power_state *pwrst;
@@ -112,6 +130,8 @@ static int __init omap4_pm_init(void)
 		goto err2;
 	}
 
+	(void) clkdm_for_each(clkdms_setup, NULL);
+
 	ret = omap4_mpuss_init();
 	if (ret) {
 		pr_err("Failed to initialise OMAP4 MPUSS\n");
Signature · 1 line
1.6.0.4
#7 lore raw

PATCH v2 7/19 OMAP4: PM: Program CPU1 to hit OFF when off-lined

In reply to Santosh Shilimkar

Program non-boot CPUs to hit lowest supported power state when it is off-lined using cpu hotplug framework.

---
 arch/arm/mach-omap2/omap-hotplug.c |   18 +++++++++++++-----
 1 files changed, 13 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/omap-hotplug.c +13 -5
index 4976b93..9f8f097 100644
@@ -20,6 +20,9 @@
 
 #include <asm/cacheflush.h>
 #include <mach/omap4-common.h>
+#include <mach/omap-wakeupgen.h>
+
+#include "powerdomain.h"
 
 int platform_cpu_kill(unsigned int cpu)
 {
@@ -32,6 +35,8 @@ int platform_cpu_kill(unsigned int cpu)
  */
 void platform_cpu_die(unsigned int cpu)
 {
+	unsigned int this_cpu;
+
 	flush_cache_all();
 	dsb();
 
@@ -39,18 +44,21 @@ void platform_cpu_die(unsigned int cpu)
 	 * we're ready for shutdown now, so do it
 	 */
 	if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
-		printk(KERN_CRIT "Secure clear status failed\n");
+		pr_err("Secure clear status failed\n");
 
 	for (;;) {
 		/*
-		 * Execute WFI
+		 * Enter into low power state
+		 * clear all interrupt wakeup sources
 		 */
-		do_wfi();
-
-		if (omap_read_auxcoreboot0() == cpu) {
+		omap_wakeupgen_irqmask_all(cpu, 1);
+		omap4_enter_lowpower(cpu, PWRDM_POWER_OFF);
+		this_cpu = hard_smp_processor_id();
+		if (omap_read_auxcoreboot0() == this_cpu) {
 			/*
 			 * OK, proper wakeup, we're done
 			 */
+			omap_wakeupgen_irqmask_all(this_cpu, 0);
 			break;
 		}
 		pr_debug("CPU%u: spurious wakeup call\n", cpu);
Signature · 1 line
1.6.0.4
#8 lore raw

PATCH v2 8/19 OMAP4: PM: CPU1 wakeup workaround from Low power modes

In reply to Santosh Shilimkar

The SGI(Software Generated Interrupts) are not wakeup capable from low power states. This is known limitation on OMAP4 and needs to be worked around by using software forced clockdomain wake-up. CPU0 forces the CPU1 clockdomain to software force wakeup. After the wakeup, CPU1 restores its clockdomain hardware supervised mode.

More details can be found in OMAP4430 TRM - Version J Section :
4.3.4.2 Power States of CPU0 and CPU1

---
 arch/arm/mach-omap2/omap-hotplug.c |    8 ++++++++
 arch/arm/mach-omap2/omap-smp.c     |   26 +++++++++++++++++++++++++-
 2 files changed, 33 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/omap-hotplug.c +8 -0
index 9f8f097..fe2dae1 100644
@@ -23,6 +23,7 @@
 #include <mach/omap-wakeupgen.h>
 
 #include "powerdomain.h"
+#include "clockdomain.h"
 
 int platform_cpu_kill(unsigned int cpu)
 {
@@ -36,6 +37,10 @@ int platform_cpu_kill(unsigned int cpu)
 void platform_cpu_die(unsigned int cpu)
 {
 	unsigned int this_cpu;
+	static struct clockdomain *cpu1_clkdm;
+
+	if (!cpu1_clkdm)
+		cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
 
 	flush_cache_all();
 	dsb();
@@ -59,6 +64,9 @@ void platform_cpu_die(unsigned int cpu)
 			 * OK, proper wakeup, we're done
 			 */
 			omap_wakeupgen_irqmask_all(this_cpu, 0);
+
+			/* Restore clockdomain to hardware supervised */
+			clkdm_allow_idle(cpu1_clkdm);
 			break;
 		}
 		pr_debug("CPU%u: spurious wakeup call\n", cpu);
arch/arm/mach-omap2/omap-smp.c +25 -1
index 4fcaa4a..1230c4e 100644
@@ -25,6 +25,8 @@
 #include <mach/hardware.h>
 #include <mach/omap4-common.h>
 
+#include "clockdomain.h"
+
 /* SCU base address */
 static void __iomem *scu_base;
 
@@ -54,6 +56,8 @@ void __cpuinit platform_secondary_init(unsigned int cpu)
 
 int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
+	static struct clockdomain *cpu1_clkdm;
+	static bool booted;
 	/*
 	 * Set synchronisation state between this boot processor
 	 * and the secondary one
@@ -69,7 +73,27 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 	omap_modify_auxcoreboot0(0x200, 0xfffffdff);
 	flush_cache_all();
 	smp_wmb();
-	smp_cross_call(cpumask_of(cpu), 1);
+
+	if (!cpu1_clkdm)
+		cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
+
+	/*
+	 * The SGI(Software Generated Interrupts) are not wakeup capable
+	 * from low power states. This is known limitation on OMAP4 and
+	 * needs to be worked around by using software forced clockdomain
+	 * wake-up. To wakeup CPU1, CPU0 forces the CPU1 clockdomain to
+	 * software force wakeup. After the wakeup, CPU1 restores its
+	 * clockdomain hardware supervised mode.
+	 * More details can be found in OMAP4430 TRM - Version J
+	 * Section :
+	 *	4.3.4.2 Power States of CPU0 and CPU1
+	 */
+	if (booted) {
+		clkdm_wakeup(cpu1_clkdm);
+	} else {
+		dsb_sev();
+		booted = true;
+	}
 
 	/*
 	 * Now the secondary core is starting up let it run its
Signature · 1 line
1.6.0.4
#9 lore raw

PATCH v2 9/19 OMAP4: PM: Add GIC distributor and interface enable/disable accessory API

In reply to Santosh Shilimkar

The power management code needs to have access to enable/disable the gic cpu interface and distributor based on targetted low power states.

These APIs are suppose to me moved to common ARM GIC library and patch for the same was posted earlier. The GIC code refactoring is ongoing and hence for time being this is kept under OMAP code so that OMAP4 PM can continue to work.

Discussion thread:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42940.html

Cc Kevin Hilman <[email protected]>
Cc Russell King <[email protected]>
---
 arch/arm/mach-omap2/include/mach/omap4-common.h |    5 +++-
 arch/arm/mach-omap2/omap4-common.c              |   24 +++++++++++++++++++++++
 2 files changed, 28 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/include/mach/omap4-common.h +4 -1
index a6ce905..a4b3beb 100644
@@ -44,6 +44,10 @@ extern void __iomem *omap4_get_gic_dist_base(void);
 extern void __iomem *omap4_get_gic_cpu_base(void);
 extern void __iomem *omap4_get_sar_ram_base(void);
 extern void __init gic_init_irq(void);
+extern void gic_cpu_enable(void);
+extern void gic_cpu_disable(void);
+extern void gic_dist_enable(void);
+extern void gic_dist_disable(void);
 extern void omap_smc1(u32 fn, u32 arg);
 
 /*
@@ -64,7 +68,6 @@ extern int omap4_mpuss_init(void);
 extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
 extern void omap4_cpu_suspend(unsigned int cpu, unsigned int save_state);
 extern void omap4_cpu_resume(void);
-
 #else
 
 static inline int omap4_enter_lowpower(unsigned int cpu,
arch/arm/mach-omap2/omap4-common.c +24 -0
index 97d7d8a..9dd50b7 100644
@@ -61,6 +61,30 @@ void __init gic_init_irq(void)
 	gic_init(0, 29, gic_dist_base_addr, gic_cpu_base);
 }
 
+/*
+ * FIXME: Remove this GIC APIs once common GIG library starts
+ * supporting it.
+ */
+void gic_cpu_enable(void)
+{
+	__raw_writel(0xf0, gic_cpu_base + GIC_CPU_PRIMASK);
+	__raw_writel(1, gic_cpu_base + GIC_CPU_CTRL);
+}
+
+void gic_cpu_disable(void)
+{
+	__raw_writel(0, gic_cpu_base + GIC_CPU_CTRL);
+}
+
+void gic_dist_enable(void)
+{
+	__raw_writel(0x1, gic_dist_base_addr + GIC_DIST_CTRL);
+}
+void gic_dist_disable(void)
+{
+	__raw_writel(0, gic_dist_base_addr + GIC_CPU_CTRL);
+}
+
 #ifdef CONFIG_CACHE_L2X0
 
 void __iomem *omap4_get_l2cache_base(void)
Signature · 1 line
1.6.0.4
#10 lore raw

PATCH v2 10/19 OMAP4: PM: Add GIC save/restore support

In reply to Santosh Shilimkar

On OMAP4 when attempting MPU off-mode or OSWR, the GIC context is lost. This patch adds GIC context save and restore support.

The context save is done by software and restore is done by ROM code from predefined SAR locations where the context supposed to be saved. Refer to OMAP4430 TRM for the SAR RAM layout.

---
 arch/arm/mach-omap2/omap-hotplug.c         |    4 +
 arch/arm/mach-omap2/omap4-mpuss-lowpower.c |  195 +++++++++++++++++++++++++++-
 arch/arm/mach-omap2/omap4-sar-layout.h     |   20 +++
 3 files changed, 213 insertions(+), 6 deletions(-)
arch/arm/mach-omap2/omap-hotplug.c +4 -0
index fe2dae1..f69cd5c 100644
@@ -19,6 +19,8 @@
 #include <linux/smp.h>
 
 #include <asm/cacheflush.h>
+#include <asm/hardware/gic.h>
+
 #include <mach/omap4-common.h>
 #include <mach/omap-wakeupgen.h>
 
@@ -57,6 +59,7 @@ void platform_cpu_die(unsigned int cpu)
 		 * clear all interrupt wakeup sources
 		 */
 		omap_wakeupgen_irqmask_all(cpu, 1);
+		gic_cpu_disable();
 		omap4_enter_lowpower(cpu, PWRDM_POWER_OFF);
 		this_cpu = hard_smp_processor_id();
 		if (omap_read_auxcoreboot0() == this_cpu) {
@@ -64,6 +67,7 @@ void platform_cpu_die(unsigned int cpu)
 			 * OK, proper wakeup, we're done
 			 */
 			omap_wakeupgen_irqmask_all(this_cpu, 0);
+			gic_cpu_enable();
 
 			/* Restore clockdomain to hardware supervised */
 			clkdm_allow_idle(cpu1_clkdm);
arch/arm/mach-omap2/omap4-mpuss-lowpower.c +189 -6

267 lines not on this page · raw message

arch/arm/mach-omap2/omap4-sar-layout.h +20 -0
index 8b71b1e..baac4c0 100644
@@ -30,4 +30,24 @@
 #define CPU0_WAKEUP_NS_PA_ADDR_OFFSET		0xa04
 #define CPU1_WAKEUP_NS_PA_ADDR_OFFSET		0xa08
 
+/* GIC save restore offset from SAR_BANK3 */
+#define SAR_BACKUP_STATUS_OFFSET		(SAR_BANK3_OFFSET + 0x500)
+#define SAR_SECURE_RAM_SIZE_OFFSET		(SAR_BANK3_OFFSET + 0x504)
+#define SAR_SECRAM_SAVED_AT_OFFSET		(SAR_BANK3_OFFSET + 0x508)
+#define ICDISR_CPU0_OFFSET			(SAR_BANK3_OFFSET + 0x50c)
+#define ICDISR_CPU1_OFFSET			(SAR_BANK3_OFFSET + 0x510)
+#define ICDISR_SPI_OFFSET			(SAR_BANK3_OFFSET + 0x514)
+#define ICDISER_CPU0_OFFSET			(SAR_BANK3_OFFSET + 0x524)
+#define ICDISER_CPU1_OFFSET			(SAR_BANK3_OFFSET + 0x528)
+#define ICDISER_SPI_OFFSET			(SAR_BANK3_OFFSET + 0x52c)
+#define ICDIPR_SFI_CPU0_OFFSET			(SAR_BANK3_OFFSET + 0x53c)
+#define ICDIPR_PPI_CPU0_OFFSET			(SAR_BANK3_OFFSET + 0x54c)
+#define ICDIPR_SFI_CPU1_OFFSET			(SAR_BANK3_OFFSET + 0x550)
+#define ICDIPR_PPI_CPU1_OFFSET			(SAR_BANK3_OFFSET + 0x560)
+#define ICDIPR_SPI_OFFSET			(SAR_BANK3_OFFSET + 0x564)
+#define ICDIPTR_SPI_OFFSET			(SAR_BANK3_OFFSET + 0x5e4)
+#define ICDICFR_OFFSET				(SAR_BANK3_OFFSET + 0x664)
+#define SAR_BACKUP_STATUS_GIC_CPU0		0x1
+#define SAR_BACKUP_STATUS_GIC_CPU1		0x2
+
 #endif
Signature · 1 line
1.6.0.4
#11 lore raw

PATCH v2 11/19 OMAP4: PM: Add WakeupGen save/restore support

In reply to Santosh Shilimkar

WakeupGen IP is integrated along with GIC to manage the interrupt wakeups from CPU low power states. It's located in always ON power domain. It manages masking/unmasking of Shared peripheral interrupts(SPI).So the interrupt enable/disable control should be in sync and consistent at WakeupGen and GIC so that interrupts are not lost.

Considering this GIC and WakeupGen save and restore is done together.

---
 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |    1 +
 arch/arm/mach-omap2/omap-wakeupgen.c              |   81 +++++++++++++++++++++
 arch/arm/mach-omap2/omap4-mpuss-lowpower.c        |    2 +
 arch/arm/mach-omap2/omap4-sar-layout.h            |   11 +++
 4 files changed, 95 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/include/mach/omap-wakeupgen.h +1 -0
index f10d106..66f31c3 100644
@@ -37,4 +37,5 @@
 
 extern int __init omap_wakeupgen_init(void);
 extern void omap_wakeupgen_irqmask_all(unsigned int cpu, unsigned int set);
+extern void omap_wakeupgen_save(void);
 #endif
arch/arm/mach-omap2/omap-wakeupgen.c +81 -0

102 lines not on this page · raw message

arch/arm/mach-omap2/omap4-mpuss-lowpower.c +2 -0
index 446b956..ddf5b72 100644
@@ -52,6 +52,7 @@
 
 #include <plat/omap44xx.h>
 #include <mach/omap4-common.h>
+#include <mach/omap-wakeupgen.h>
 
 #include "omap4-sar-layout.h"
 #include "pm.h"
@@ -292,6 +293,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
 	 * GIC lost during MPU OFF and OSWR
 	 */
 	if (pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_OFF) {
+		omap_wakeupgen_save();
 		gic_save_context();
 		save_state = 3;
 	}
arch/arm/mach-omap2/omap4-sar-layout.h +11 -0
index baac4c0..3f3e3c9 100644
@@ -50,4 +50,15 @@
 #define SAR_BACKUP_STATUS_GIC_CPU0		0x1
 #define SAR_BACKUP_STATUS_GIC_CPU1		0x2
 
+/* WakeUpGen save restore offset from OMAP44XX_SAR_RAM_BASE */
+#define WAKEUPGENENB_OFFSET_CPU0		(SAR_BANK3_OFFSET + 0x684)
+#define WAKEUPGENENB_SECURE_OFFSET_CPU0		(SAR_BANK3_OFFSET + 0x694)
+#define WAKEUPGENENB_OFFSET_CPU1		(SAR_BANK3_OFFSET + 0x6a4)
+#define WAKEUPGENENB_SECURE_OFFSET_CPU1		(SAR_BANK3_OFFSET + 0x6b4)
+#define AUXCOREBOOT0_OFFSET			(SAR_BANK3_OFFSET + 0x6c4)
+#define AUXCOREBOOT1_OFFSET			(SAR_BANK3_OFFSET + 0x6c8)
+#define PTMSYNCREQ_MASK_OFFSET			(SAR_BANK3_OFFSET + 0x6cc)
+#define PTMSYNCREQ_EN_OFFSET			(SAR_BANK3_OFFSET + 0x6d0)
+#define SAR_BACKUP_STATUS_WAKEUPGEN		0x10
+
 #endif
Signature · 1 line
1.6.0.4
#12 lore raw

PATCH v2 12/19 OMAP4: PM: Add L2 cache lowpower support

In reply to Santosh Shilimkar

When MPUSS hits off-mode e, L2 cache is lost. This patch adds L2X0 necessary maintenance operations and context restoration in the low power code.

---
 arch/arm/mach-omap2/omap4-mpuss-lowpower.c |   18 ++++++++
 arch/arm/mach-omap2/omap4-sar-layout.h     |    2 +
 arch/arm/mach-omap2/sleep44xx.S            |   65 ++++++++++++++++++++++++++++
 3 files changed, 85 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/omap4-mpuss-lowpower.c +18 -0
index ddf5b72..026c955 100644
@@ -49,6 +49,7 @@
 #include <asm/system.h>
 #include <asm/irq.h>
 #include <asm/hardware/gic.h>
+#include <asm/hardware/cache-l2x0.h>
 
 #include <plat/omap44xx.h>
 #include <mach/omap4-common.h>
@@ -336,6 +337,21 @@ ret:
 	return 0;
 }
 
+static void save_l2x0_auxctrl(void)
+{
+#ifdef CONFIG_CACHE_L2X0
+	/*
+	 * Save the L2X0 AUXCTRL value to SAR memory. Its used to
+	 * in every restore patch MPUSS OFF path.
+	 */
+	void __iomem *l2x0_base = omap4_get_l2cache_base();
+	u32 val;
+
+	val = __raw_readl(l2x0_base + L2X0_AUX_CTRL);
+	__raw_writel(val, sar_base + L2X0_AUXCTRL_OFFSET);
+#endif
+}
+
 /*
  * Initialise OMAP4 MPUSS
  */
@@ -418,6 +434,8 @@ int __init omap4_mpuss_init(void)
 	for (i = 0; i < max_spi_reg; i++)
 		sar_writel(GIC_ISR_NON_SECURE, ICDISR_SPI_OFFSET, i);
 
+	save_l2x0_auxctrl();
+
 	return 0;
 }
 
arch/arm/mach-omap2/omap4-sar-layout.h +2 -0
index 3f3e3c9..c72c0c5 100644
@@ -25,6 +25,8 @@
 #define MMU_OFFSET				0xd00
 #define SCU_OFFSET0				0xd20
 #define SCU_OFFSET1				0xd24
+#define L2X0_OFFSET				0xd28
+#define L2X0_AUXCTRL_OFFSET			0xd2c
 
 /* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
 #define CPU0_WAKEUP_NS_PA_ADDR_OFFSET		0xa04
arch/arm/mach-omap2/sleep44xx.S +65 -0

91 lines not on this page · raw message

Signature · 1 line
1.6.0.4
#13 lore raw

PATCH v2 13/19 OMAP4: suspend: Add MPUSS RET and OFF support

In reply to Santosh Shilimkar

This patch adds MPUSS(MPU Sub System) RET and OFF mode support to suspend path. For both MPUSS RET and OFF support, CPUs are programmed to OFF state.

Only MPUSS RET and OFF supported at this point of time. CORE RET will be added subsequently.

---
 arch/arm/mach-omap2/omap4-mpuss-lowpower.c |    6 ++-
 arch/arm/mach-omap2/pm-debug.c             |    2 +
 arch/arm/mach-omap2/pm.h                   |    1 +
 arch/arm/mach-omap2/pm44xx.c               |   84 ++++++++++++++++++++++++++-
 4 files changed, 88 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/omap4-mpuss-lowpower.c +5 -1
index 026c955..7348d29 100644
@@ -25,7 +25,7 @@
  *	ON(Inactive)	OFF		ON(Inactive)
  *	OFF		OFF		CSWR
  *	OFF		OFF		OSWR (*TBD)
- *	OFF		OFF		OFF* (*TBD)
+ *	OFF		OFF		OFF
  *	----------------------------------------------
  *
  * Note: CPU0 is the master core and it is the last CPU to go down
@@ -293,6 +293,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
 	 * Check MPUSS next state and save GIC if needed
 	 * GIC lost during MPU OFF and OSWR
 	 */
+	pwrdm_clear_all_prev_pwrst(mpuss_pd);
 	if (pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_OFF) {
 		omap_wakeupgen_save();
 		gic_save_context();
@@ -414,6 +415,9 @@ int __init omap4_mpuss_init(void)
 		return -ENODEV;
 	}
 
+	/* Clear CPU previous power domain state */
+	pwrdm_clear_all_prev_pwrst(mpuss_pd);
+
 	/*
 	 * Find out how many interrupts are supported.
 	 * OMAP4 supports max of 128 SPIs where as GIC can support
arch/arm/mach-omap2/pm-debug.c +2 -0
index a5a83b3..34f0e5d 100644
@@ -588,6 +588,8 @@ static int option_set(void *data, u64 val)
 			omap_pm_disable_off_mode();
 		if (cpu_is_omap34xx())
 			omap3_pm_off_mode_enable(val);
+		else if (cpu_is_omap44xx())
+			omap4_pm_off_mode_enable(val);
 	}
 
 	return 0;
arch/arm/mach-omap2/pm.h +1 -0
index 797bfd1..ec5a36f 100644
@@ -17,6 +17,7 @@
 
 extern void *omap3_secure_ram_storage;
 extern void omap3_pm_off_mode_enable(int);
+extern void omap4_pm_off_mode_enable(int);
 extern void omap_sram_idle(void);
 extern int omap3_can_sleep(void);
 extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
arch/arm/mach-omap2/pm44xx.c +80 -4

115 lines not on this page · raw message

Signature · 1 line
1.6.0.4
#14 lore raw

PATCH v2 14/19 OMAP4: pm-debug: Add wakeup timer and debug counters

In reply to Santosh Shilimkar

This patch adds configurable wakeup timer support in suspend. Also for statistics pm counter support is added.

---
 arch/arm/mach-omap2/omap4-mpuss-lowpower.c |    4 ++++
 arch/arm/mach-omap2/pm-debug.c             |   10 ++++++++--
 arch/arm/mach-omap2/pm44xx.c               |    5 +++++
 3 files changed, 17 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/omap4-mpuss-lowpower.c +4 -0
index 7348d29..3cd9e8b 100644
@@ -289,6 +289,8 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
 	if (cpu)
 		goto cpu_prepare;
 
+	pwrdm_pre_transition();
+
 	/*
 	 * Check MPUSS next state and save GIC if needed
 	 * GIC lost during MPU OFF and OSWR
@@ -334,6 +336,8 @@ cpu_prepare:
 		gic_dist_enable();
 	}
 
+	pwrdm_post_transition();
+
 ret:
 	return 0;
 }
arch/arm/mach-omap2/pm-debug.c +8 -2
index 34f0e5d..c83a0f6 100644
@@ -606,9 +606,11 @@ static int __init pm_dbg_init(void)
 	if (pm_dbg_init_done)
 		return 0;
 
-	if (cpu_is_omap34xx())
+	if (cpu_is_omap34xx()) {
 		pm_dbg_reg_modules = omap3_pm_reg_modules;
-	else {
+	} else if (cpu_is_omap44xx()) {
+		/* Allow pm_dbg_init on OMAP4. */
+	} else {
 		printk(KERN_ERR "%s: only OMAP3 supported\n", __func__);
 		return -ENODEV;
 	}
@@ -624,6 +626,9 @@ static int __init pm_dbg_init(void)
 
 	pwrdm_for_each(pwrdms_setup, (void *)d);
 
+	if (cpu_is_omap44xx())
+		goto skip_reg_debufs;
+
 	pm_dbg_dir = debugfs_create_dir("registers", d);
 	if (IS_ERR(pm_dbg_dir))
 		return PTR_ERR(pm_dbg_dir);
@@ -638,6 +643,7 @@ static int __init pm_dbg_init(void)
 				pm_dbg_dir, (void *)(i+1), &debug_reg_fops);
 
 		}
+skip_reg_debufs:
 
 	(void) debugfs_create_file("enable_off_mode", S_IRUGO | S_IWUSR, d,
 				   &enable_off_mode, &pm_dbg_option_fops);
arch/arm/mach-omap2/pm44xx.c +5 -0
index 0d1f33a..14d4229 100644
@@ -41,6 +41,11 @@ static int omap4_pm_suspend(void)
 	int state, ret = 0;
 	u32 cpu_id = smp_processor_id();
 
+	/* Wakeup timer from suspend */
+	if (wakeup_timer_seconds || wakeup_timer_milliseconds)
+		omap2_pm_wakeup_on_timer(wakeup_timer_seconds,
+					 wakeup_timer_milliseconds);
+
 	/* Save current powerdomain state */
 	list_for_each_entry(pwrst, &pwrst_list, node) {
 		pwrst->saved_state = pwrdm_read_next_pwrst(pwrst->pwrdm);
Signature · 1 line
1.6.0.4
#15 lore raw

PATCH v2 15/19 OMAP4: cpuidle: Basic CPUidle support

In reply to Santosh Shilimkar

From: Rajendra Nayak <[email protected]>

The patch adds a basic CPUidle driver for OMAP4. Just one C state is registered for CPU0 which does a WFI. CPU1 is left with defualt idle and the low power state for it is managed via cpu-hotplug.

---
 arch/arm/mach-omap2/Makefile      |    3 +-
 arch/arm/mach-omap2/cpuidle44xx.c |  161 +++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/pm.h          |    1 +
 arch/arm/mach-omap2/pm44xx.c      |    2 +
 4 files changed, 166 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-omap2/cpuidle44xx.c
arch/arm/mach-omap2/Makefile +2 -1
index 04b97bb..c003435 100644
@@ -64,7 +64,8 @@ obj-$(CONFIG_ARCH_OMAP2)		+= sleep24xx.o pm_bus.o
 obj-$(CONFIG_ARCH_OMAP3)		+= pm34xx.o sleep34xx.o \
 					   cpuidle34xx.o pm_bus.o
 obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o pm_bus.o \
-					   omap4-mpuss-lowpower.o sleep44xx.o
+					   omap4-mpuss-lowpower.o sleep44xx.o \
+					   cpuidle44xx.o
 obj-$(CONFIG_PM_DEBUG)			+= pm-debug.o
 obj-$(CONFIG_OMAP_SMARTREFLEX)          += sr_device.o smartreflex.o
 obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)	+= smartreflex-class3.o
arch/arm/mach-omap2/cpuidle44xx.c new file +161 -0

161 lines not on this page · raw message

arch/arm/mach-omap2/pm.h +1 -0
index ec5a36f..36cc2cf 100644
@@ -22,6 +22,7 @@ extern void omap_sram_idle(void);
 extern int omap3_can_sleep(void);
 extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
 extern int omap3_idle_init(void);
+extern int omap4_idle_init(void);
 
 #if defined(CONFIG_PM_OPP)
 extern int omap3_opp_init(void);
arch/arm/mach-omap2/pm44xx.c +2 -0
index 14d4229..d4ad31e 100644
@@ -224,6 +224,8 @@ static int __init omap4_pm_init(void)
 	suspend_set_ops(&omap_pm_ops);
 #endif /* CONFIG_SUSPEND */
 
+	omap4_idle_init();
+
 err2:
 	return ret;
 }
Signature · 1 line
1.6.0.4
#16 lore raw

PATCH v2 16/19 OMAP4: cpuidle: Add MPUSS RET OFF states

In reply to Santosh Shilimkar

This patch adds MPUSS low power states in cpuidle.

C1 - CPU0 ON + CPU1 ON + MPU ON
C2 - CPU0 ON + CPU1 OFF + MPU ON
C3 - CPU0 OFF + CPU1 OFF + MPU CSWR
C4 - CPU0 OFF + CPU1 OFF + MPU OFF

MPU OSWR isn't supported yet. To support OSWR, power domain context registers needs to be managed which are not supported yet. A patch to address this was submitted but it's not ready for merge yet because it was not addressing all OMAP4 power domain context registers. More info on this issue:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg38667.html

OMAP4 powerdomain INACTIVE support is also dropped because of inconsistency of it with OMAP3. More information on this thread.

	http://www.spinics.net/lists/linux-omap/msg45370.html

CORE low power states and associated latencies will be updated as part along with chip retention support.

On OMAP4 because of hardware constraints, no low power states are targeted when both CPUs are online and in SMP mode. The low power states are attempted only when secondary CPU gets offline to OFF through hotplug infrastructure.

Thanks to Nicole Chalhoub <[email protected]> for doing exhaustive C-state latency profiling.

---
 arch/arm/mach-omap2/cpuidle44xx.c |  129 +++++++++++++++++++++++++++++++++++--
 1 files changed, 124 insertions(+), 5 deletions(-)
arch/arm/mach-omap2/cpuidle44xx.c +124 -5
index 270404f..19a405c 100644
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2011 Texas Instruments, Inc.
  * Rajendra Nayak <[email protected]>
+ * Santosh Shilimkar <[email protected]>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -17,12 +18,20 @@
 #include <mach/omap4-common.h>
 
 #include "pm.h"
+#include "prm.h"
 
 #ifdef CONFIG_CPU_IDLE
 
-#define OMAP4_MAX_STATES	1
+#define OMAP4_MAX_STATES	4
+
 /* C1 - CPU0 ON + + CPU1 ON + MPU ON + CORE ON */
 #define OMAP4_STATE_C1		0
+/* C2 - CPU0 ON + CPU1 OFF + MPU ON + CORE ON */
+#define OMAP4_STATE_C2		1
+/* C3 - CPU0 OFF + CPU1 OFF + MPU CSWR + CORE ON */
+#define OMAP4_STATE_C3		2
+/* C4 - CPU0 OFF + CPU1 OFF + MPU OFF + CORE ON */
+#define OMAP4_STATE_C4		3
 
 struct omap4_processor_cx {
 	u8 valid;
@@ -31,16 +40,34 @@ struct omap4_processor_cx {
 	u32 wakeup_latency;
 	u32 cpu0_state;
 	u32 mpu_state;
+	u32 mpu_logic_state;
 	u32 core_state;
+	u32 core_logic_state;
 	u32 threshold;
 	u32 flags;
+	const char *desc;
 };
 
 struct omap4_processor_cx omap4_power_states[OMAP4_MAX_STATES];
+static struct powerdomain *mpu_pd, *cpu1_pd, *core_pd;
 
+/*
+ * FIXME: Full latency numbers needs to be updated as part of
+ * cpuidle CORE retention support.
+ * Currently only MPUSS latency numbers are added based on
+ * measurements done internally. The numbers for MPUSS are
+ * not board dependent and hence set directly here instead of
+ * passing it from board files.
+ */
 static struct cpuidle_params cpuidle_params_table[] = {
-	/* C1 */
-	{1, 2, 2, 5},
+	/* C1 - CPU0 ON + CPU1 ON + MPU ON  + CORE ON */
+	{1,	2,	2,	5},
+	/* C2 - CPU0 ON + CPU1 OFF + MPU ON  + CORE ON */
+	{1,	140,	160,	300},
+	/* C3 - CPU0 OFF + CPU1 OFF + MPU CSWR + CORE ON */
+	{1,	200,	300,	700},
+	/* C4 - CPU0 OFF + CPU1 OFF + MPU OFF + CORE ON */
+	{1,	1400,	600,	5000},
 };
 
 /**
@@ -55,7 +82,9 @@ static struct cpuidle_params cpuidle_params_table[] = {
 static int omap4_enter_idle(struct cpuidle_device *dev,
 			struct cpuidle_state *state)
 {
+	struct omap4_processor_cx *cx = cpuidle_get_statedata(state);
 	struct timespec ts_preidle, ts_postidle, ts_idle;
+	u32 cpu1_state;
 
 	/* Used to keep track of the total time in idle */
 	getnstimeofday(&ts_preidle);
@@ -63,7 +92,26 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
 	local_irq_disable();
 	local_fiq_disable();
 
-	cpu_do_idle();
+	/*
+	 * Continue to do only WFI on CPU0 till CPU1 hits OFF state.
+	 * This is necessary to honour hardware recommondation
+	 * of triggeing all the possible low power modes once CPU1 is
+	 * out of coherency and in OFF mode.
+	 * Update dev->last_state so that governor stats reflects right
+	 * data.
+	 */
+	cpu1_state = pwrdm_read_pwrst(cpu1_pd);
+	if ((cpu1_state != PWRDM_POWER_OFF) || (!cx->valid)) {
+		dev->last_state = dev->safe_state;
+		cx = cpuidle_get_statedata(dev->safe_state);
+	}
+
+	pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
+	omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
+	pwrdm_set_logic_retst(core_pd, cx->core_logic_state);
+	omap_set_pwrdm_state(core_pd, cx->core_state);
+
+	omap4_enter_lowpower(dev->cpu, cx->cpu0_state);
 
 	getnstimeofday(&ts_postidle);
 	ts_idle = timespec_sub(ts_postidle, ts_preidle);
@@ -96,9 +144,73 @@ void omap4_init_power_states(void)
 			cpuidle_params_table[OMAP4_STATE_C1].wake_latency;
 	omap4_power_states[OMAP4_STATE_C1].threshold =
 			cpuidle_params_table[OMAP4_STATE_C1].threshold;
+	omap4_power_states[OMAP4_STATE_C1].cpu0_state = PWRDM_POWER_ON;
 	omap4_power_states[OMAP4_STATE_C1].mpu_state = PWRDM_POWER_ON;
+	omap4_power_states[OMAP4_STATE_C1].mpu_logic_state = PWRDM_POWER_RET;
 	omap4_power_states[OMAP4_STATE_C1].core_state = PWRDM_POWER_ON;
+	omap4_power_states[OMAP4_STATE_C1].core_logic_state = PWRDM_POWER_RET;
 	omap4_power_states[OMAP4_STATE_C1].flags = CPUIDLE_FLAG_TIME_VALID;
+	omap4_power_states[OMAP4_STATE_C1].desc = "MPU ON + CORE ON";
+
+	/*
+	 * C2 - CPU0 ON + CPU1 OFF + MPU ON + CORE ON
+	 */
+	omap4_power_states[OMAP4_STATE_C2].valid =
+			cpuidle_params_table[OMAP4_STATE_C2].valid;
+	omap4_power_states[OMAP4_STATE_C2].type = OMAP4_STATE_C2;
+	omap4_power_states[OMAP4_STATE_C2].sleep_latency =
+			cpuidle_params_table[OMAP4_STATE_C2].sleep_latency;
+	omap4_power_states[OMAP4_STATE_C2].wakeup_latency =
+			cpuidle_params_table[OMAP4_STATE_C2].wake_latency;
+	omap4_power_states[OMAP4_STATE_C2].threshold =
+			cpuidle_params_table[OMAP4_STATE_C2].threshold;
+	omap4_power_states[OMAP4_STATE_C2].cpu0_state = PWRDM_POWER_ON;
+	omap4_power_states[OMAP4_STATE_C2].mpu_state = PWRDM_POWER_ON;
+	omap4_power_states[OMAP4_STATE_C2].mpu_logic_state = PWRDM_POWER_RET;
+	omap4_power_states[OMAP4_STATE_C2].core_state = PWRDM_POWER_ON;
+	omap4_power_states[OMAP4_STATE_C2].core_logic_state = PWRDM_POWER_RET;
+	omap4_power_states[OMAP4_STATE_C2].flags = CPUIDLE_FLAG_IGNORE;
+	omap4_power_states[OMAP4_STATE_C2].desc = "MPU ON + CORE ON";
+
+	/*
+	 * C3 - CPU0 OFF + CPU1 OFF + MPU CSWR + CORE ON
+	 */
+	omap4_power_states[OMAP4_STATE_C3].valid =
+			cpuidle_params_table[OMAP4_STATE_C3].valid;
+	omap4_power_states[OMAP4_STATE_C3].type = OMAP4_STATE_C3;
+	omap4_power_states[OMAP4_STATE_C3].sleep_latency =
+			cpuidle_params_table[OMAP4_STATE_C3].sleep_latency;
+	omap4_power_states[OMAP4_STATE_C3].wakeup_latency =
+			cpuidle_params_table[OMAP4_STATE_C3].wake_latency;
+	omap4_power_states[OMAP4_STATE_C3].threshold =
+			cpuidle_params_table[OMAP4_STATE_C3].threshold;
+	omap4_power_states[OMAP4_STATE_C3].cpu0_state = PWRDM_POWER_OFF;
+	omap4_power_states[OMAP4_STATE_C3].mpu_state = PWRDM_POWER_RET;
+	omap4_power_states[OMAP4_STATE_C3].mpu_logic_state = PWRDM_POWER_RET;
+	omap4_power_states[OMAP4_STATE_C3].core_state = PWRDM_POWER_ON;
+	omap4_power_states[OMAP4_STATE_C3].core_logic_state = PWRDM_POWER_RET;
+	omap4_power_states[OMAP4_STATE_C3].flags = CPUIDLE_FLAG_IGNORE;
+	omap4_power_states[OMAP4_STATE_C3].desc = "MPU CSWR + CORE ON";
+
+	/*
+	 * C4 - CPU0 OFF + CPU1 OFF + MPU OFF + CORE ON
+	 */
+	omap4_power_states[OMAP4_STATE_C4].valid =
+			cpuidle_params_table[OMAP4_STATE_C4].valid;
+	omap4_power_states[OMAP4_STATE_C4].type = OMAP4_STATE_C4;
+	omap4_power_states[OMAP4_STATE_C4].sleep_latency =
+			cpuidle_params_table[OMAP4_STATE_C4].sleep_latency;
+	omap4_power_states[OMAP4_STATE_C4].wakeup_latency =
+			cpuidle_params_table[OMAP4_STATE_C4].wake_latency;
+	omap4_power_states[OMAP4_STATE_C4].threshold =
+			cpuidle_params_table[OMAP4_STATE_C4].threshold;
+	omap4_power_states[OMAP4_STATE_C4].cpu0_state = PWRDM_POWER_OFF;
+	omap4_power_states[OMAP4_STATE_C4].mpu_state = PWRDM_POWER_OFF;
+	omap4_power_states[OMAP4_STATE_C4].mpu_logic_state = PWRDM_POWER_OFF;
+	omap4_power_states[OMAP4_STATE_C4].core_state = PWRDM_POWER_ON;
+	omap4_power_states[OMAP4_STATE_C4].core_logic_state = PWRDM_POWER_RET;
+	omap4_power_states[OMAP4_STATE_C4].flags = CPUIDLE_FLAG_IGNORE;
+	omap4_power_states[OMAP4_STATE_C4].desc = "MPU OFF + CORE ON";
 
 }
 
@@ -115,11 +227,15 @@ struct cpuidle_driver omap4_idle_driver = {
  */
 int __init omap4_idle_init(void)
 {
-	int cpu_id = 0, i, count = 0;
+	int cpu_id = 0, i, count = 0, ret;
 	struct omap4_processor_cx *cx;
 	struct cpuidle_state *state;
 	struct cpuidle_device *dev;
 
+	mpu_pd = pwrdm_lookup("mpu_pwrdm");
+	cpu1_pd = pwrdm_lookup("cpu1_pwrdm");
+	core_pd = pwrdm_lookup("core_pwrdm");
+
 	omap4_init_power_states();
 	cpuidle_register_driver(&omap4_idle_driver);
 
@@ -137,8 +253,11 @@ int __init omap4_idle_init(void)
 						cx->wakeup_latency;
 		state->target_residency = cx->threshold;
 		state->flags = cx->flags;
+		if (cx->type == OMAP4_STATE_C1)
+			dev->safe_state = state;
 		state->enter = omap4_enter_idle;
 		sprintf(state->name, "C%d", count+1);
+		strncpy(state->desc, cx->desc, CPUIDLE_DESC_LEN);
 		count++;
 	}
 
Signature · 1 line
1.6.0.4
#17 lore raw

PATCH v2 17/19 OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states.

In reply to Santosh Shilimkar

CPU local timer(TWD) stops when the CPU is transitioning into deeper C-States. Since these timers are not wakeup capable, we need the wakeup capable global timer to program the wakeup time depending on the next timer expiry.

It can be handled by registering a global wakeup capable timer along with local timers marked with (mis)feature flag CLOCK_EVT_FEAT_C3STOP. Then notify the clock events layer from idle code using CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT).

---
 arch/arm/mach-omap2/cpuidle44xx.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/cpuidle44xx.c +8 -0
index 19a405c..daf41e1 100644
@@ -12,6 +12,7 @@
 
 #include <linux/sched.h>
 #include <linux/cpuidle.h>
+#include <linux/clockchips.h>
 
 #include <asm/proc-fns.h>
 
@@ -85,6 +86,7 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
 	struct omap4_processor_cx *cx = cpuidle_get_statedata(state);
 	struct timespec ts_preidle, ts_postidle, ts_idle;
 	u32 cpu1_state;
+	int cpu_id = smp_processor_id();
 
 	/* Used to keep track of the total time in idle */
 	getnstimeofday(&ts_preidle);
@@ -111,8 +113,14 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
 	pwrdm_set_logic_retst(core_pd, cx->core_logic_state);
 	omap_set_pwrdm_state(core_pd, cx->core_state);
 
+	if (cx->type > OMAP4_STATE_C1)
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
+
 	omap4_enter_lowpower(dev->cpu, cx->cpu0_state);
 
+	if (cx->type > OMAP4_STATE_C1)
+		clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
+
 	getnstimeofday(&ts_postidle);
 	ts_idle = timespec_sub(ts_postidle, ts_preidle);
 
Signature · 1 line
1.6.0.4
#18 lore raw

PATCH v2 18/19 OMAP4: cpuidle: Add CPU hotplug notifier and prepare() hook.

In reply to Santosh Shilimkar

On OMAP4 CPUidle, the low power states are triggered when CPU1 is offlined to OFF power state. When the CPU1 is online, no low power states are supported.

The patch adds CPU hotplug notifier to manage the C-state states using CPUidle prepare() hook and CPUIDLE_FLAG_IGNORE c-state flag.

This was suggested by Kevin Hilman <[email protected]> during OMAP4 PM code review.

---
 arch/arm/mach-omap2/cpuidle44xx.c |   64 +++++++++++++++++++++++++++++++++++++
 1 files changed, 64 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/cpuidle44xx.c +64 -0
index daf41e1..83b7f95 100644
@@ -13,6 +13,8 @@
 #include <linux/sched.h>
 #include <linux/cpuidle.h>
 #include <linux/clockchips.h>
+#include <linux/notifier.h>
+#include <linux/cpu.h>
 
 #include <asm/proc-fns.h>
 
@@ -51,6 +53,8 @@ struct omap4_processor_cx {
 
 struct omap4_processor_cx omap4_power_states[OMAP4_MAX_STATES];
 static struct powerdomain *mpu_pd, *cpu1_pd, *core_pd;
+static int needs_state_data_update;
+static unsigned int state_flags = CPUIDLE_FLAG_IGNORE;
 
 /*
  * FIXME: Full latency numbers needs to be updated as part of
@@ -72,6 +76,31 @@ static struct cpuidle_params cpuidle_params_table[] = {
 };
 
 /**
+ * omap4_prepare_idle - Update C-state parameters dynamically
+ * @dev: cpuidle device
+ *
+ * Called from the CPUidle framework to prepare the device
+ * for idle before before calling the governor's select function.
+ */
+static int omap4_prepare_idle(struct cpuidle_device *dev)
+{
+	int i, ret = 0;
+
+	if (!needs_state_data_update)
+		return ret;
+
+	/*
+	 * Update the C-state flags based on CPU1 online
+	 * or offline state. On OMAP4, the low power C-states
+	 * are made available when only CPU1 is offline.
+	 */
+	for (i = OMAP4_STATE_C2; i < OMAP4_MAX_STATES; i++)
+		dev->states[i].flags = state_flags;
+
+	return ret;
+}
+
+/**
  * omap4_enter_idle - Programs OMAP4 to enter the specified state
  * @dev: cpuidle device
  * @state: The target state to be programmed
@@ -227,6 +256,36 @@ struct cpuidle_driver omap4_idle_driver = {
 	.owner =	THIS_MODULE,
 };
 
+/*
+ * CPU hotplug notifier to update the C-states when
+ * CPU1 is offline or onine. While updating C-state flag,
+ * keep the cpuidle disabled.
+ */
+static int __cpuinit omap_cpu_hotplug_notify(struct notifier_block *self,
+					 unsigned long action, void *unused)
+{
+	switch (action) {
+	case CPU_ONLINE:
+		disable_hlt();
+		needs_state_data_update = 1;
+		state_flags = CPUIDLE_FLAG_IGNORE;
+		enable_hlt();
+		break;
+	case CPU_DEAD:
+		disable_hlt();
+		needs_state_data_update = 1;
+		state_flags = CPUIDLE_FLAG_TIME_VALID;
+		enable_hlt();
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block __refdata omap_ilde_hotplug_notifier = {
+	.notifier_call = omap_cpu_hotplug_notify,
+};
+
 /**
  * omap4_idle_init - Init routine for OMAP4 idle
  *
@@ -272,12 +331,17 @@ int __init omap4_idle_init(void)
 	if (!count)
 		return -EINVAL;
 	dev->state_count = count;
+	dev->prepare = omap4_prepare_idle;
 
 	if (cpuidle_register_device(dev)) {
 		pr_err("%s: CPUidle register device failed\n", __func__);
 			return -EIO;
 		}
 
+	ret = register_hotcpu_notifier(&omap_ilde_hotplug_notifier);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 #else
Signature · 1 line
1.6.0.4
#19 lore raw

PATCH v2 19/19 OMAP4: Remove un-used do_wfi() macro.

In reply to Santosh Shilimkar

With OMAP4 suspend, idle and hotplug series, we no longer need do_wfi() macro.

Remove the same.

---
 arch/arm/mach-omap2/include/mach/omap4-common.h |   10 ----------
 1 files changed, 0 insertions(+), 10 deletions(-)
arch/arm/mach-omap2/include/mach/omap4-common.h +0 -10
index a4b3beb..33fa3d3 100644
@@ -16,16 +16,6 @@
 #include <asm/proc-fns.h>
 
 #ifndef __ASSEMBLER__
-/*
- * wfi used in low power code. Directly opcode is used instead
- * of instruction to avoid mulit-omap build break
- */
-#ifdef CONFIG_THUMB2_KERNEL
-#define do_wfi() __asm__ __volatile__ ("wfi" : : : "memory")
-#else
-#define do_wfi()			\
-		__asm__ __volatile__ (".word	0xe320f003" : : : "memory")
-#endif
 
 #ifdef CONFIG_CACHE_L2X0
 extern void __iomem *omap4_get_l2cache_base(void);
Signature · 1 line
1.6.0.4
#20 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

In reply to Santosh Shilimkar
Quoted 11 lines · Santosh Shilimkar

V2 updates:
Rebased on latest pm-core branch and fixes below comments
from Kevin Hilman <[email protected]>.
- All acronym fixes
- Use WARN_ON() instead of BUG_ON() with graceful exit.
- Export omap4_get_base*() rather than global address pointers
- CPUidle prepare() hook + hotplug notifier to manage C-state dynamically.
- Dropped debugfs way of changing C-state valid flags in favor of above.

Full series with cherry-picked dependencies are available on below git branch.

Can you summarize the status of the dependencies and when they will
merge? IOW, aside from the static dependency hack, is Russell merging
all of the others?

Kevin

Quoted 140 lines

git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_for-next_v2

This series adds OMAP4 suspend and cpuidle support till MPU subsystem (MPUSS) off-mode. The suspend on SMP machines uses cpu-hotplug infrastructure to take down the non-boot CPUs. We put secondary CPU(CPU1 in OMAP4) to OFF state via cpu-hotplug.
In cpuidle too, low power states are attempted only when the CPU1 is put to OFF state via cpu-hotplug because of hardware constraints.

Timer wakeup from suspend, debug pm counters and enable_off_mode provisions are supported as well.

Special thanks to Kevin Hilman <[email protected]> for doing detail off-the list reviews.

The patches are generated against mainline 2.6.38-rc5 and tested with OMAP4430 SDP and OMAP4 PANDA board. Any OMAP4 board with ES2.X silicon, below features should work with this series. On ES1.0, these PM features are not supported.
1. CPU hotplug (CPU is put into off-mode)
2. Suspend (Both CPUs put to off-mode and MPUSS to OFF/RET)
3. CPUILDE with below C-states.
C1 - CPU0 ON + CPU1 ON/OFF + MPU ON + CORE ON C2 - CPU0 ON + CPU1 OFF + MPU ON + CORE ON C3 - CPU0 OFF + CPU1 OFF + MPU CSWR + CORE ON C4 - CPU0 OFF + CPU1 OFF + MPU OFF + CORE ON

In OMAP4 mpuss consist of dual Cortex-A9 with per-cpu local timers GIC(Generic Interrupt Controller), SCU(Snoop Control Unit) and PL310 L2 cache controller and CPU0/CPU1 LPRM modules.
CPU0, CPU1 and MPUSS have there own power domain and hence multiple low power state combinations are possible. The CPU10 and CPU1 Close switch Retention(CSWR) isn't supported by hardware. Based on various studies, measurements, hardware constraints and recommendations from hardware team, only below low power modes are supported on OMAP4.
----------------------------------------
CPU0 CPU1 MPUSS
----------------------------------------
ON ON ON
OFF OFF CSWR
OFF OFF OSWR
OFF OFF OFF
-----------------------------------------
Note: CPU0 is the master core and it is the last CPU to go down and first to wake-up when MPUSS low power states are attempted

OSWR(Open Switch Retention) is not added as part of this series because it needs some power domain level support which isn't ready yet.
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg38667.html

Powerdomain INACTIVE support is also dropped because of its inconsistency between OMAP4 and OMAP3.
More information on this thread -

	http://www.spinics.net/lists/linux-omap/msg45370.html

This series has a dependency on few patches from below series.
- GIC and SCU patches from [1] (queued up in RMK's for-next)
- Local Timer patches from [2] (queued up in RMK's for-next)
- Not clearing the static deps hack which is getting sorted out.

The cpu-hotplug and suspend works with omap2plus_defconfig. Not to damage your file system with current omap2plus_defconfig, disable ARCH_OMAP2 so that V6 and V7 support is not built together with SMP.
To tryout cpuidle, CONFIG_CPU_IDLE needs to be enabled in the build.

CPU-HOTPLUG commands :
offline : $echo 0 > /sys/devices/system/cpu/cpu1/online online : $echo 1 > /sys/devices/system/cpu/cpu1/online

Suspend :$echo mem > /sys/power/state

cpuilde : To trigger cpuidle deeper C-states on OMAP4, CPU1 needs
to be offlied
$echo 0 > /sys/devices/system/cpu/cpu1/online

To see PM debug counters,
$mount -t debugfs debugfs /proc/sys/debug/
$cat /proc/sys/debug/pm_debug/count
off-mode debugfs control:
enable: $echo 1 > /proc/sys/debug/pm_debug/enable_off_mode
disable: $echo 0 > /proc/sys/debug/pm_debug/enable_off_mode

Summary:

Rajendra Nayak (1):
OMAP4: cpuidle: Basic CPUidle support

Santosh Shilimkar (18):
OMAP4: PM: Add omap WakeupGen module support
OMAP4: Use WARN_ON() instead of BUG_ON() with graceful exit
OMAP4: PM: Export omap4_get_base*() rather than global address
pointers
OMAP4: PM: Add SAR RAM support
OMAP4: PM: Add CPUX OFF mode support
OMAP4: PM: Initialise all the clockdomains to supported states
OMAP4: PM: Program CPU1 to hit OFF when off-lined
OMAP4: PM: CPU1 wakeup workaround from Low power modes
OMAP4: PM: Add GIC distributor and interface enable/disable accessory
api
OMAP4: PM: Add GIC save/restore support
OMAP4: PM: Add WakeupGen save/restore support
OMAP4: PM: Add L2 cache lowpower support
OMAP4: suspend: Add MPUSS RET and OFF support
OMAP4: pm-debug: Add wakeup timer and debug counters
OMAP4: cpuidle: Add MPUSS RET OFF states
OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states.
OMAP4: cpuidle: Add CPU hotplug notifier and prepare() hook.
OMAP4: Remove un-used do_wfi() macro.

 arch/arm/mach-omap2/Makefile                      |    8 +-
 arch/arm/mach-omap2/cpuidle44xx.c                 |  352 ++++++++++++++++
 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |   41 ++
 arch/arm/mach-omap2/include/mach/omap4-common.h   |   73 +++-
 arch/arm/mach-omap2/omap-hotplug.c                |   30 ++-
 arch/arm/mach-omap2/omap-smp.c                    |   32 ++-
 arch/arm/mach-omap2/omap-wakeupgen.c              |  319 +++++++++++++++
 arch/arm/mach-omap2/omap4-common.c                |   85 ++++-
 arch/arm/mach-omap2/omap4-mpuss-lowpower.c        |  451 +++++++++++++++++++++
 arch/arm/mach-omap2/omap4-sar-layout.h            |   66 +++
 arch/arm/mach-omap2/pm-debug.c                    |   12 +-
 arch/arm/mach-omap2/pm.h                          |    2 +
 arch/arm/mach-omap2/pm44xx.c                      |  119 ++++++-
 arch/arm/mach-omap2/sleep44xx.S                   |  400 ++++++++++++++++++
 arch/arm/plat-omap/include/plat/omap44xx.h        |    1 +
 15 files changed, 1958 insertions(+), 33 deletions(-)
 create mode 100644 arch/arm/mach-omap2/cpuidle44xx.c
 create mode 100644 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
 create mode 100644 arch/arm/mach-omap2/omap-wakeupgen.c
 create mode 100644 arch/arm/mach-omap2/omap4-mpuss-lowpower.c
 create mode 100644 arch/arm/mach-omap2/omap4-sar-layout.h
 create mode 100644 arch/arm/mach-omap2/sleep44xx.S

Regrads,
Santosh
[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg42939.html
[2] http://www.spinics.net/lists/linux-omap/msg45710.html

#21 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

In reply to Santosh Shilimkar

Hi Santosh,

Quoted 11 lines · Santosh Shilimkar

V2 updates:
Rebased on latest pm-core branch and fixes below comments
from Kevin Hilman <[email protected]>.
- All acronym fixes
- Use WARN_ON() instead of BUG_ON() with graceful exit.
- Export omap4_get_base*() rather than global address pointers
- CPUidle prepare() hook + hotplug notifier to manage C-state dynamically.
- Dropped debugfs way of changing C-state valid flags in favor of above.

Full series with cherry-picked dependencies are available on below git branch.

Ignore my previous comment about these dependencies, I didn't read far enough to see you mentioned them below, and I also found them in RMK's devel branch.

Quoted 22 lines

git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_for-next_v2

This series adds OMAP4 suspend and cpuidle support till MPU subsystem (MPUSS) off-mode. The suspend on SMP machines uses cpu-hotplug infrastructure to take down the non-boot CPUs. We put secondary CPU(CPU1 in OMAP4) to OFF state via cpu-hotplug.
In cpuidle too, low power states are attempted only when the CPU1 is put to OFF state via cpu-hotplug because of hardware constraints.

Timer wakeup from suspend, debug pm counters and enable_off_mode provisions are supported as well.

Special thanks to Kevin Hilman <[email protected]> for doing detail off-the list reviews.

The patches are generated against mainline 2.6.38-rc5 and tested with OMAP4430 SDP and OMAP4 PANDA board. Any OMAP4 board with ES2.X silicon, below features should work with this series. On ES1.0, these PM features are not supported.

Quoted 7 lines

1. CPU hotplug (CPU is put into off-mode)
2. Suspend (Both CPUs put to off-mode and MPUSS to OFF/RET)
3. CPUILDE with below C-states.
C1 - CPU0 ON + CPU1 ON/OFF + MPU ON + CORE ON C2 - CPU0 ON + CPU1 OFF + MPU ON + CORE ON C3 - CPU0 OFF + CPU1 OFF + MPU CSWR + CORE ON C4 - CPU0 OFF + CPU1 OFF + MPU OFF + CORE ON

This series doesn't boot on ES1 (boot log below.) Do we need to totally prevent WFI on ES1?

Also, if we want a CPUidle enabled kernel to boot on all silicon, it will need a omap_rev() check during init to ensure it doesn't override the default idle path.

[    2.973999] VFP support v0.3: implementor 41 architecture 3 part 30 variant 0
[    2.986083] ThumbEE CPU extension supported.                                 
[    3.000183] omap2_set_init_voltage: Invalid parameters!                      
[    3.005676] omap2_set_init_voltage: Unable to put vdd_iva to its init voltage
[    3.005676]                                                                  
[    3.014831] Power Management for TI OMAP4.                                   
[    3.019256] ------------[ cut here ]------------                             
[    3.069824] WARNING: at /work/kernel/omap/pm/arch/arm/mach-omap2/omap4-mpuss)
[    3.171417] Power Management not supported on OMAP4430 ES1.0                 
[    3.179290] Modules linked in:                                               
[    3.210571] [<c0062004>] (unwind_backtrace+0x0/0xe0) from [<c0094f34>] (warn)
[    3.233947] [<c0094f34>] (warn_slowpath_common+0x4c/0x64) from [<c0094fcc>] )
[    3.257415] [<c0094fcc>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0012cc0>] (om)
[    3.343261] [<c0012cc0>] (omap4_mpuss_init+0x38/0x1a4) from [<c0012b4c>] (om)
[    3.366790] [<c0012b4c>] (omap4_pm_init+0x48/0x88) from [<c005168c>] (do_one)
[    3.444885] [<c005168c>] (do_one_initcall+0xb4/0x18c) from [<c0008b2c>] (ker)
[    3.468353] [<c0008b2c>] (kernel_init+0x150/0x218) from [<c005c1d8>] (kernel)
[    3.507385] ---[ end trace 1b75b31a2719ed1e ]---                             
[    3.546447] Failed to initialise OMAP4 MPUSS                                 
[    6.187103] clock: disabling unused clocks to save power                     
[   23.187072] BUG: spinlock lockup on CPU#0, swapper/1, c0f698e0               
[   23.193237] [<c0062004>] (unwind_backtrace+0x0/0xe0) from [<c0246e18>] (do_r)
[   23.202941] [<c0246e18>] (do_raw_spin_lock+0x130/0x14c) from [<c0086af0>] (t)
[   23.212341] [<c0086af0>] (task_rq_lock+0x40/0x78) from [<c008e390>] (try_to_)
[   23.221496] [<c008e390>] (try_to_wake_up+0x38/0x438) from [<c00ac370>] (__qu)
[   23.230804] [<c00ac370>] (__queue_work+0x34c/0x374) from [<c00ac3fc>] (queue)
[   23.239959] [<c00ac3fc>] (queue_work_on+0x34/0x44) from [<c00a9828>] (call_u)
[   23.250091] [<c00a9828>] (call_usermodehelper_exec+0xb8/0x13c) from [<c023d7)
[   23.260864] [<c023d77c>] (kobject_uevent_env+0x3b8/0x428) from [<c028bce4>] )
[   23.270446] [<c028bce4>] (device_add+0x36c/0x4fc) from [<c028bf04>] (device_)
[   23.279937] [<c028bf04>] (device_create_vargs+0x78/0xc0) from [<c028bf68>] ()
[   23.289550] [<c028bf68>] (device_create+0x1c/0x24) from [<c02891a8>] (misc_r)
[   23.298706] [<c02891a8>] (misc_register+0xc4/0x134) from [<c001c580>] (pm_qo)
[   23.308135] [<c001c580>] (pm_qos_power_init+0xc/0x64) from [<c005168c>] (do_)
[   23.317718] [<c005168c>] (do_one_initcall+0xb4/0x18c) from [<c0008b2c>] (ker)
[   23.327056] [<c0008b2c>] (kernel_init+0x150/0x218) from [<c005c1d8>] (kernel)
Quoted 51 lines

In OMAP4 mpuss consist of dual Cortex-A9 with per-cpu local timers GIC(Generic Interrupt Controller), SCU(Snoop Control Unit) and PL310 L2 cache controller and CPU0/CPU1 LPRM modules.
CPU0, CPU1 and MPUSS have there own power domain and hence multiple low power state combinations are possible. The CPU10 and CPU1 Close switch Retention(CSWR) isn't supported by hardware. Based on various studies, measurements, hardware constraints and recommendations from hardware team, only below low power modes are supported on OMAP4.
----------------------------------------
CPU0 CPU1 MPUSS
----------------------------------------
ON ON ON
OFF OFF CSWR
OFF OFF OSWR
OFF OFF OFF
-----------------------------------------
Note: CPU0 is the master core and it is the last CPU to go down and first to wake-up when MPUSS low power states are attempted

OSWR(Open Switch Retention) is not added as part of this series because it needs some power domain level support which isn't ready yet.
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg38667.html

Powerdomain INACTIVE support is also dropped because of its inconsistency between OMAP4 and OMAP3.
More information on this thread -

	http://www.spinics.net/lists/linux-omap/msg45370.html

This series has a dependency on few patches from below series.
- GIC and SCU patches from [1] (queued up in RMK's for-next)
- Local Timer patches from [2] (queued up in RMK's for-next)
- Not clearing the static deps hack which is getting sorted out.

The cpu-hotplug and suspend works with omap2plus_defconfig. Not to damage your file system with current omap2plus_defconfig, disable ARCH_OMAP2 so that V6 and V7 support is not built together with SMP.
To tryout cpuidle, CONFIG_CPU_IDLE needs to be enabled in the build.

CPU-HOTPLUG commands :
offline : $echo 0 > /sys/devices/system/cpu/cpu1/online online : $echo 1 > /sys/devices/system/cpu/cpu1/online

Suspend :$echo mem > /sys/power/state

cpuilde : To trigger cpuidle deeper C-states on OMAP4, CPU1 needs
to be offlied
$echo 0 > /sys/devices/system/cpu/cpu1/online

Quoted 6 lines

To see PM debug counters,
$mount -t debugfs debugfs /proc/sys/debug/
$cat /proc/sys/debug/pm_debug/count
off-mode debugfs control:
enable: $echo 1 > /proc/sys/debug/pm_debug/enable_off_mode
disable: $echo 0 > /proc/sys/debug/pm_debug/enable_off_mode

Without enabling off-mode, I took CPU1 offline and see that it immediatly goes off. This makes sense based on the HW, but not in light of the enable_off_mode flag. For OMAP4, maybe it makes sense to not
have the enable_off_mode flag at all? We'll be getting rid of it on
OMAP3 as soon as the constraints framework is ready, so maybe it makes sense to just go without it for OMAP4?

More confusion: another test (also with CPUidle enabled), I see that the MPU and DSS are also hitting off-mode:

# echo 0 > /sys/devices/system/cpu/cpu1/online
# cat /debug/pm_debug/count                                                   
cefuse_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0                       
always_on_core_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0               
l4per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0                                                                   
l3init_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0     
cam_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0       
ivahd_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0                             
mpu_pwrdm (ON),OFF:90,RET:230,INA:0,ON:321,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0                                             
cpu1_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0      
cpu0_pwrdm (ON),OFF:320,RET:0,INA:0,ON:321,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0   
tesla_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0                                                
dss_pwrdm (OFF),OFF:30,RET:0,INA:0,ON:29,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0     
abe_pwrdm (OFF),OFF:2,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0                                                                    
gfx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0       
core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0,RET-MEMBANK5-OFF:0   

Kevin

#22 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Quoted 12 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 11, 2011 7:13 AM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; rnayak at ti.com; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Hi Santosh,

Santosh Shilimkar <[email protected]> writes:

[....]

Quoted 8 lines

This series doesn't boot on ES1 (boot log below.) Do we need to totally prevent WFI on ES1?

Also, if we want a CPUidle enabled kernel to boot on all silicon, it will need a omap_rev() check during init to ensure it doesn't override the default idle path.

Make sense. Will try it on ES1.0 silicon.

[....]

Quoted 4 lines
Quoted 3 lines

off-mode debugfs control:
enable: $echo 1 > /proc/sys/debug/pm_debug/enable_off_mode
disable: $echo 0 > /proc/sys/debug/pm_debug/enable_off_mode

Quoted 8 lines

Without enabling off-mode, I took CPU1 offline and see that it immediatly goes off. This makes sense based on the HW, but not in light
of the enable_off_mode flag. For OMAP4, maybe it makes sense to not
have the enable_off_mode flag at all? We'll be getting rid of it
on OMAP3 as soon as the constraints framework is ready, so maybe it makes sense to just go without it for OMAP4?

Actually that's expected since enable_off_mode flag doesn't manage CPUX power domain states and they are always hit OFF. CSWR isn't supported on CPUX power domains as captured in the series. But I agree with you that it might be confusing.

[...]

Quoted 3 lines

More confusion: another test (also with CPUidle enabled), I see that the MPU and DSS are also hitting off-mode:

This behavior changed when we dropped enable_off_mode flag to updated C-states in favor of prepare() hooks. DSS showing OFF mode is because of debug counter issue. DSS PD doesn't support previous power state which these counter code is trying to read. There are couple of patches from Rajendra and Thara do address this counter issues but they are bit of hacky. May be we can get them on the list to discuss further.

So just to summaries, on OMAP$ 'enable_off_mode' flag is used __only__ in Suspend. CPUx power domain always hit OFF mode no matter what is state of this flag because CSWR isn't supported on these PD's.

We could remove this flag as well but thought that this might be useful especially when we add CORE RET, DEVICE OFF support.

May be we keep this till the constraint frameworks comes in and then drop it once for all. I am ok with whatever direction you decide here.

Regards,
Santosh

#23 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Kevin,

Quoted 18 lines

-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Friday, March 11, 2011 11:22 AM
To: Kevin Hilman
Cc: 'linux-omap at vger.kernel.org'; Rajendra Nayak; 'linux-arm- kernel at lists.infradead.org'
Subject: RE: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Quoted 9 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 11, 2011 7:13 AM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; rnayak at ti.com; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Quoted 9 lines
Quoted 3 lines

Hi Santosh,

Santosh Shilimkar <[email protected]> writes:

[....]

Quoted 4 lines

This series doesn't boot on ES1 (boot log below.) Do we need to totally prevent WFI on ES1?

Nope. WFI is ok.
The ES1.0 boot issue on pm-core branch doesn't seems to be related to this series. Without this series as well OMAP4 ES1.0 is not booting for me. When I disable CONFIG_PM + WATCHDOG fix, it booted ok. I will git-bisect this later on pm-core branch.

Quoted 4 lines
Quoted 4 lines

Also, if we want a CPUidle enabled kernel to boot on all silicon, it will need a omap_rev() check during init to ensure it doesn't override the default idle path.

OMAP4 PM series already takes care of not overriding the default idle path for ES1.0. The omap4_mpuss_init() fails on ES1.0 and hence the CPUidle init is skipped in that case.

Just to further check, I pulled the latest omap-for-linus branch and merged Paul's pull-request into it. Then applied OMAP4 PM series and I got a boot crash, a different one. This was again related to clock-domain initialization and static deps. I fixed this issue by avoiding omap4_pm_init() code running on ES1.0. With this boot on ES1.0 works fine now with OMAP4 PM series.

Posted the patch for the same.
https://patchwork.kernel.org/patch/628231/

The rebased series against
Latest 'omap-for-linus + Paul's pull-request'
have pushed to below branch.

git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_for-next_v3

Regards,
Santosh

#24 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Santosh Shilimkar <[email protected]> writes:

[...]

Quoted 20 lines
Quoted 4 lines
Quoted 4 lines

This series doesn't boot on ES1 (boot log below.) Do we need to totally prevent WFI on ES1?

Nope. WFI is ok.
The ES1.0 boot issue on pm-core branch doesn't seems to be related to this series. Without this series as well OMAP4 ES1.0 is not booting for me. When I disable CONFIG_PM + WATCHDOG fix, it booted ok. I will git-bisect this later on pm-core branch.

Quoted 4 lines
Quoted 4 lines

Also, if we want a CPUidle enabled kernel to boot on all silicon, it will need a omap_rev() check during init to ensure it doesn't override the default idle path.

OMAP4 PM series already takes care of not overriding the default idle path for ES1.0. The omap4_mpuss_init() fails on ES1.0 and hence the CPUidle init is skipped in that case.

Quoted 7 lines

Just to further check, I pulled the latest omap-for-linus branch and merged Paul's pull-request into it. Then applied OMAP4 PM series and I got a boot crash, a different one. This was again related to clock-domain initialization and static deps. I fixed this issue by avoiding omap4_pm_init() code running on ES1.0. With this boot on ES1.0 works fine now with OMAP4 PM series.

Thanks for finding this. I just tested your v3 branch together with my pm-core and it's now booting fine on ES1.

Kevin

Quoted 13 lines

Posted the patch for the same.
https://patchwork.kernel.org/patch/628231/

The rebased series against
Latest 'omap-for-linus + Paul's pull-request'
have pushed to below branch.

git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_for-next_v3

Regards,
Santosh

#25 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Quoted 44 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 11, 2011 9:26 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Rajendra Nayak; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Santosh Shilimkar <[email protected]> writes:

[...]

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

This series doesn't boot on ES1 (boot log below.) Do we need

to

Quoted 10 lines
Quoted 2 lines
Quoted 2 lines

totally prevent WFI on ES1?

Nope. WFI is ok.
The ES1.0 boot issue on pm-core branch doesn't seems to be related to this series. Without this series as well OMAP4 ES1.0 is not booting for me. When I disable CONFIG_PM + WATCHDOG fix, it booted ok. I will git-bisect this later on pm-core branch.

Quoted 1 line
Quoted 1 line

Also, if we want a CPUidle enabled kernel to boot on all

silicon,

Quoted 1 line
Quoted 1 line
Quoted 1 line

it will need a omap_rev() check during init to ensure it

doesn't

Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

override the default idle path.

OMAP4 PM series already takes care of not overriding the default idle path for ES1.0. The omap4_mpuss_init() fails on ES1.0 and hence the CPUidle init is skipped in that case.

Quoted 7 lines

Just to further check, I pulled the latest omap-for-linus branch and merged Paul's pull-request into it. Then applied OMAP4 PM series and I got a boot crash, a different one. This was again related to clock-domain initialization and static deps. I fixed this issue by avoiding omap4_pm_init() code running on ES1.0. With this boot on ES1.0 works fine now with OMAP4 PM series.

Quoted 3 lines

Thanks for finding this. I just tested your v3 branch together with my pm-core and it's now booting fine on ES1.

Thanks Kevin for test.

Regards,
Santosh

#26 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

In reply to Kevin Hilman
Quoted 32 lines · Kevin Hilman

Santosh Shilimkar <[email protected]> writes:

[...]

Quoted 20 lines
Quoted 4 lines
Quoted 4 lines

This series doesn't boot on ES1 (boot log below.) Do we need to totally prevent WFI on ES1?

Nope. WFI is ok.
The ES1.0 boot issue on pm-core branch doesn't seems to be related to this series. Without this series as well OMAP4 ES1.0 is not booting for me. When I disable CONFIG_PM + WATCHDOG fix, it booted ok. I will git-bisect this later on pm-core branch.

Quoted 4 lines
Quoted 4 lines

Also, if we want a CPUidle enabled kernel to boot on all silicon, it will need a omap_rev() check during init to ensure it doesn't override the default idle path.

OMAP4 PM series already takes care of not overriding the default idle path for ES1.0. The omap4_mpuss_init() fails on ES1.0 and hence the CPUidle init is skipped in that case.

Quoted 7 lines

Just to further check, I pulled the latest omap-for-linus branch and merged Paul's pull-request into it. Then applied OMAP4 PM series and I got a boot crash, a different one. This was again related to clock-domain initialization and static deps. I fixed this issue by avoiding omap4_pm_init() code running on ES1.0. With this boot on ES1.0 works fine now with OMAP4 PM series.

Quoted 3 lines

Thanks for finding this. I just tested your v3 branch together with my pm-core and it's now booting fine on ES1.

Hi Santosh,

Can you rebase and repost your v3 series, I'd like to get this queued up early in the 2.6.40 dev cycle.

You can base on my current pm-core branch, which also has Russell's devel-stable branch merged in.

Thanks,

Kevin

#27 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Kevin,

Quoted 9 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Thursday, March 24, 2011 8:40 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Rajendra Nayak; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

[...]

Quoted 9 lines

Hi Santosh,

Can you rebase and repost your v3 series, I'd like to get this queued up early in the 2.6.40 dev cycle.

You can base on my current pm-core branch, which also has Russell's devel-stable branch merged in.

I pulled your latest pm-core branch
------
commit 61cbb3172176b84c106bf0f4c32317c472932ab5
Merge: d0cf394... da19719...
Author: Kevin Hilman <[email protected]>
Date: Wed Mar 23 16:33:01 2011 -0700

    Merge branch 'for_2.6.40/pm-misc' into pm-reset

-----------------
Looks like Russell's devel branch isn't merged in pm-core. I didn't find the relevant patches.

By the way the relevant ARM patches are already in mainline. So if the pm-core is rebased against latest mainline, we can get those changes as well.

Regards,
Santosh

#28 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Hi Santosh,

Santosh Shilimkar <[email protected]> writes:

[...]

Quoted 13 lines
Quoted 6 lines

Can you rebase and repost your v3 series, I'd like to get this queued up early in the 2.6.40 dev cycle.

You can base on my current pm-core branch, which also has Russell's devel-stable branch merged in.

I pulled your latest pm-core branch
------
commit 61cbb3172176b84c106bf0f4c32317c472932ab5
Merge: d0cf394... da19719...
Author: Kevin Hilman <[email protected]>
Date: Wed Mar 23 16:33:01 2011 -0700

Quoted 4 lines
    Merge branch 'for_2.6.40/pm-misc' into pm-reset

-----------------
Looks like Russell's devel branch isn't merged in pm-core. I didn't find the relevant patches.

hmm, you're right. I'm actually pulling Russell's devel-stable branch not his devel branch. I assumed they were in devel-stable as well.

Quoted 3 lines

By the way the relevant ARM patches are already in mainline. So if the pm-core is rebased against latest mainline, we can get those changes as well.

Before I rebase, I'll wait at least until -rc1 and/or Tony rebases to mainline.

In the mean time, can you create two branches? One with the dependencies and another with the OMAP4 PM series. After some final review and testing, I'll merge the latter series and by then we'll probably have an -rc1 baseline.

Kevin

#29 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Quoted 12 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 25, 2011 8:54 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Rajendra Nayak; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Hi Santosh,

Santosh Shilimkar <[email protected]> writes:

[....]

Quoted 7 lines
Quoted 7 lines

I pulled your latest pm-core branch
------
commit 61cbb3172176b84c106bf0f4c32317c472932ab5
Merge: d0cf394... da19719...
Author: Kevin Hilman <[email protected]>
Date: Wed Mar 23 16:33:01 2011 -0700

Quoted 9 lines
Quoted 4 lines
    Merge branch 'for_2.6.40/pm-misc' into pm-reset

-----------------
Looks like Russell's devel branch isn't merged in pm-core. I didn't find the relevant patches.

hmm, you're right. I'm actually pulling Russell's devel-stable branch
not his devel branch. I assumed they were in devel-stable as well.

Ok.

Quoted 7 lines
Quoted 3 lines

By the way the relevant ARM patches are already in mainline. So if the pm-core is rebased against latest mainline, we can get those changes as well.

Before I rebase, I'll wait at least until -rc1 and/or Tony rebases to mainline.

Ok.

Quoted 5 lines

In the mean time, can you create two branches? One with the dependencies and another with the OMAP4 PM series. After some final review and testing, I'll merge the latter series and by then we'll probably have an -rc1 baseline.

Will do.

Regards,
Santosh

#30 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

In reply to Kevin Hilman

Kevin

Quoted 13 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 25, 2011 8:54 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Rajendra Nayak; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Hi Santosh,

Santosh Shilimkar <[email protected]> writes:

[....]

Quoted 6 lines

In the mean time, can you create two branches? One with the dependencies and another with the OMAP4 PM series. After some final review and testing, I'll merge the latter series and by then we'll probably have an -rc1 baseline.

Have created two branches as you suggested.

#31 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

In reply to Kevin Hilman

Kevin,

Quoted 13 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 25, 2011 8:54 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Rajendra Nayak; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Hi Santosh,

Santosh Shilimkar <[email protected]> writes:

[...]

Quoted 9 lines

Before I rebase, I'll wait at least until -rc1 and/or Tony rebases to mainline.

In the mean time, can you create two branches? One with the dependencies and another with the OMAP4 PM series. After some final review and testing, I'll merge the latter series and by then we'll probably have an -rc1 baseline.

Have created two branches as you suggested against latest pm-core.

1) OMAP4-PM series:
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_pmcore_v3

2) Dependent patches
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_pmcore_dep

Also created an integration branch which merges 1) and 2)

git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_pmcore_int

Regards,
Santosh

#32 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Hi Santosh,

Santosh Shilimkar <[email protected]> writes:

[...]

Quoted 2 lines

Have created two branches as you suggested against latest pm-core.

Thanks!

Quoted 3 lines

1) OMAP4-PM series:
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_pmcore_v3

Also, can you post this version of the series to the list, w/linux-arm-kernel Cc'd.

Quoted 8 lines

2) Dependent patches
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_pmcore_dep

Also created an integration branch which merges 1) and 2)

git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_pmcore_int

Excellent.

Thanks

Kevin

#33 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Quoted 18 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Monday, March 28, 2011 9:27 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Rajendra Nayak; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Hi Santosh,

Santosh Shilimkar <[email protected]> writes:

[...]

Quoted 2 lines

Have created two branches as you suggested against latest pm-core.

Quoted 8 lines

Thanks!

Quoted 3 lines

1) OMAP4-PM series:
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_pmcore_v3

Also, can you post this version of the series to the list, w/linux-arm-kernel Cc'd.

Done that as well. Patches are on the list

Regards,
Santosh

#34 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

In reply to Kevin Hilman

On Mon, 2011-03-28 at 08:56 -0700, Kevin Hilman wrote:
[...]

Quoted 6 lines
Quoted 3 lines

1) OMAP4-PM series:
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_pmcore_v3

Also, can you post this version of the series to the list, w/linux-arm-kernel Cc'd.

Oops, sorry. I see it's already posted to the list.

Thanks,

Kevin

#35 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

In reply to Santosh Shilimkar
Quoted 56 lines · Santosh Shilimkar
Quoted 12 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 11, 2011 7:13 AM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; rnayak at ti.com; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Hi Santosh,

Santosh Shilimkar <[email protected]> writes:

[....]

Quoted 8 lines

This series doesn't boot on ES1 (boot log below.) Do we need to totally prevent WFI on ES1?

Also, if we want a CPUidle enabled kernel to boot on all silicon, it will need a omap_rev() check during init to ensure it doesn't override the default idle path.

Make sense. Will try it on ES1.0 silicon.

[....]

Quoted 4 lines
Quoted 3 lines

off-mode debugfs control:
enable: $echo 1 > /proc/sys/debug/pm_debug/enable_off_mode
disable: $echo 0 > /proc/sys/debug/pm_debug/enable_off_mode

Quoted 8 lines

Without enabling off-mode, I took CPU1 offline and see that it immediatly goes off. This makes sense based on the HW, but not in light
of the enable_off_mode flag. For OMAP4, maybe it makes sense to not
have the enable_off_mode flag at all? We'll be getting rid of it
on OMAP3 as soon as the constraints framework is ready, so maybe it makes sense to just go without it for OMAP4?

Actually that's expected since enable_off_mode flag doesn't manage CPUX power domain states and they are always hit OFF. CSWR isn't supported on CPUX power domains as captured in the series. But I agree with you that it might be confusing.

[...]

Quoted 3 lines

More confusion: another test (also with CPUidle enabled), I see that the MPU and DSS are also hitting off-mode:

This behavior changed when we dropped enable_off_mode flag to updated C-states in favor of prepare() hooks. DSS showing OFF mode is because of debug counter issue. DSS PD doesn't support previous power state which these counter code is trying to read. There are couple of patches from Rajendra and Thara do address this counter issues but they are bit of hacky. May be we can get them on the list to discuss further.

Quoted 4 lines

So just to summaries, on OMAP$ 'enable_off_mode' flag is used __only__ in Suspend. CPUx power domain always hit OFF mode no matter what is state of this flag because CSWR isn't supported on these PD's.

If it's useful only in suspend, then it's redundant with the <debugfs>/pm_debug/*_pwrdm/suspend controls which allow per-pwrdm control over next states.

Quoted 2 lines

We could remove this flag as well but thought that this might be useful especially when we add CORE RET, DEVICE OFF support.

I'd rather see working off-mode be a requirement for getting OMAP4 drivers supported.

Also, we can still test suspend/resume with off-mode disabled by using the above debugfs controls.

Quoted 3 lines

May be we keep this till the constraint frameworks comes in and then drop it once for all. I am ok with whatever direction you decide here.

I prefer to drop it completely for OMAP4.

Kevin

#36 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Kevin,

Quoted 10 lines

-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux- arm-kernel-bounces at lists.infradead.org] On Behalf Of Kevin Hilman
Sent: Friday, March 11, 2011 9:22 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; linux-arm-
kernel at lists.infradead.org; Rajendra Nayak
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend,CPU-hotplug and CPUilde support.

[....]

Quoted 16 lines
Quoted 5 lines

So just to summaries, on OMAP$ 'enable_off_mode' flag is used __only__ in Suspend. CPUx power domain always hit OFF mode no matter what is state of this flag because CSWR isn't supported on these PD's.

If it's useful only in suspend, then it's redundant with the <debugfs>/pm_debug/*_pwrdm/suspend controls which allow per-pwrdm control over next states.

Quoted 2 lines

We could remove this flag as well but thought that this might be useful especially when we add CORE RET, DEVICE OFF support.

I'd rather see working off-mode be a requirement for getting OMAP4 drivers supported.

Quoted 9 lines

Also, we can still test suspend/resume with off-mode disabled by using the above debugfs controls.

Quoted 3 lines

May be we keep this till the constraint frameworks comes in and then drop it once for all. I am ok with whatever direction you decide here.

I prefer to drop it completely for OMAP4.

OK. Lets do that.

Just to not miss your point here, what I understood here is default suspend state on OMAP$B will be off mode.

We still keep "enable_off_mode" flag for testing so that we can disable off mode to debug regressions.

Is that right?
If yes then only below update is needed.

arch/arm/mach-omap2/pm44xx.c +0 -0
index 2e18c1d..1a8cbdd 100644
@@ -167,7 +167,7 @@ static int __init pwrdms_setup(struct powerdomain

*pwrdm, void *unused)
return -ENOMEM;

pwrst->pwrdm = pwrdm;
- pwrst->next_state = PWRDM_POWER_RET;
+ pwrst->next_state = PWRDM_POWER_OFF;
list_add(&pwrst->node, &pwrst_list);

return omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
@@ -253,6 +253,8 @@ static int __init omap4_pm_init(void)
pr_err("Failed to initialise OMAP4 MPUSS\n"); goto err2;
}
+
+ enable_off_mode = 1;
#endif

#ifdef CONFIG_SUSPEND

#37 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Quoted 42 lines · Santosh Shilimkar

Kevin,

Quoted 10 lines

-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux- arm-kernel-bounces at lists.infradead.org] On Behalf Of Kevin Hilman
Sent: Friday, March 11, 2011 9:22 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; linux-arm-
kernel at lists.infradead.org; Rajendra Nayak
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend,CPU-hotplug and CPUilde support.

[....]

Quoted 16 lines
Quoted 5 lines

So just to summaries, on OMAP$ 'enable_off_mode' flag is used __only__ in Suspend. CPUx power domain always hit OFF mode no matter what is state of this flag because CSWR isn't supported on these PD's.

If it's useful only in suspend, then it's redundant with the <debugfs>/pm_debug/*_pwrdm/suspend controls which allow per-pwrdm control over next states.

Quoted 2 lines

We could remove this flag as well but thought that this might be useful especially when we add CORE RET, DEVICE OFF support.

I'd rather see working off-mode be a requirement for getting OMAP4 drivers supported.

Quoted 9 lines

Also, we can still test suspend/resume with off-mode disabled by using the above debugfs controls.

Quoted 3 lines

May be we keep this till the constraint frameworks comes in and then drop it once for all. I am ok with whatever direction you decide here.

I prefer to drop it completely for OMAP4.

OK. Lets do that.

Quoted 7 lines

Just to not miss your point here, what I understood here is default suspend state on OMAP$B will be off mode.

We still keep "enable_off_mode" flag for testing so that we can disable off mode to debug regressions.

Is that right?

No, I want to drop "enable_off_mode" all together for OMAP4.

If you want to change any powerdomain's default next_state, you can use the <debugfs>/pm_debug/*_pwrdm/suspend controls.

Kevin

#38 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Quoted 11 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 11, 2011 11:20 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; linux-arm-
kernel at lists.infradead.org; Rajendra Nayak
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend,CPU-hotplug and CPUilde support.

Santosh Shilimkar <[email protected]> writes:

[...]

Quoted 10 lines
Quoted 10 lines
Quoted 2 lines

I prefer to drop it completely for OMAP4.

OK. Lets do that.

Just to not miss your point here, what I understood here is default suspend state on OMAP$B will be off mode.

We still keep "enable_off_mode" flag for testing so that we can disable off mode to debug regressions.

Quoted 8 lines
Quoted 1 line

Is that right?

No, I want to drop "enable_off_mode" all together for OMAP4.

If you want to change any powerdomain's default next_state, you can use
the <debugfs>/pm_debug/*_pwrdm/suspend controls.

Thanks for clarification. The change is quite trivial. Will update the branch with this change.
After testing it, will intimate you

Regards
Santosh

#39 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Quoted 27 lines · Santosh Shilimkar
Quoted 11 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 11, 2011 11:20 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; linux-arm-
kernel at lists.infradead.org; Rajendra Nayak
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend,CPU-hotplug and CPUilde support.

Santosh Shilimkar <[email protected]> writes:

[...]

Quoted 14 lines
Quoted 11 lines
Quoted 2 lines

I prefer to drop it completely for OMAP4.

OK. Lets do that.

Just to not miss your point here, what I understood here is default suspend state on OMAP$B will be off mode.

We still keep "enable_off_mode" flag for testing so that we can disable off mode to debug regressions.

Is that right?

No, I want to drop "enable_off_mode" all together for OMAP4.

Quoted 7 lines
Quoted 4 lines

If you want to change any powerdomain's default next_state, you can use
the <debugfs>/pm_debug/*_pwrdm/suspend controls.

Thanks for clarification. The change is quite trivial. Will update the branch with this change.
After testing it, will intimate you

One other thing to check...

I've now included Russell's devel branch into my pm-core branch. Can you rebase your series there? I did a test rebase of v3 and it rebased fine (after dropping the patches that are already in devel.)

After doing that, I get a compile error:

arch/arm/mach-omap2/built-in.o: In function `mmu_on_label':
/work/kernel/omap/pm/arch/arm/mach-omap2/sleep44xx.S:394: undefined reference to `PHYS_OFFSET' make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2

It looks like there might be some other changes in Russell's queue that you need to take into consideration.

Kevin

#40 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

Quoted 11 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 11, 2011 11:34 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; linux-arm-
kernel at lists.infradead.org; Rajendra Nayak
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend,CPU-hotplug and CPUilde support.

Santosh Shilimkar <[email protected]> writes:

[...]

Quoted 10 lines
Quoted 3 lines

Thanks for clarification. The change is quite trivial. Will update the branch with this change.
After testing it, will intimate you

One other thing to check...

I've now included Russell's devel branch into my pm-core branch. Can you rebase your series there? I did a test rebase of v3 and it rebased fine (after dropping the patches that are already in devel.)

Great.

Quoted 11 lines

After doing that, I get a compile error:

arch/arm/mach-omap2/built-in.o: In function `mmu_on_label':
/work/kernel/omap/pm/arch/arm/mach-omap2/sleep44xx.S:394: undefined reference to `PHYS_OFFSET'
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2

It looks like there might be some other changes in Russell's queue that you need to take into consideration.

Ok. Will check that.

Regards,
Santosh

#41 lore raw

v2 cover OMAP4: PM: Suspend, CPU-hotplug and CPUilde support.

In reply to Kevin Hilman

Kevin,

Quoted 9 lines

-----Original Message-----
From: Kevin Hilman [mailto:khilman at ti.com]
Sent: Friday, March 11, 2011 11:34 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; linux-arm-
kernel at lists.infradead.org; Rajendra Nayak
Subject: Re: [PATCH v2 00/19] OMAP4: PM: Suspend,CPU-hotplug and CPUilde support.

[...]

Quoted 12 lines
Quoted 3 lines

Thanks for clarification. The change is quite trivial. Will update the branch with this change.
After testing it, will intimate you

One other thing to check...

I've now included Russell's devel branch into my pm-core branch. Can you rebase your series there? I did a test rebase of v3 and it rebased fine (after dropping the patches that are already in devel.)

After doing that, I get a compile error:

Quoted 9 lines

arch/arm/mach-omap2/built-in.o: In function `mmu_on_label':
/work/kernel/omap/pm/arch/arm/mach-omap2/sleep44xx.S:394: undefined reference to `PHYS_OFFSET'
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2

It looks like there might be some other changes in Russell's queue that you need to take into consideration.

The PHYS_OFFSET error was trivial too. It's being replaced with PLAT_PHYS_OFFSET. Have rebased the OMAP4 PM series against latest pm-core branch. Dropped enable_off_mode flag use as well.

Now there is only one dependent patch left for this series. "[PATCH] OMAP4: clockdomain: Follow recommended enable sequence"
http://www.spinics.net/lists/arm-kernel/msg117956.html

Have pushed updated branch:
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git
omap4_pm_for-next_v3-rebased

Regards
Santosh