Skip to contentSkip to conversation

omap: pm34xx: Enable IO / IO-CHAIN wakeups for PER

PATCH Superseded Mike Chan 2 participants 4 messages May 3, 2010

Subsystems (4)

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Mike Chan

author
#0 lore raw

PATCH 1/2 omap: pm34xx: Enable IO / IO-CHAIN wakeups for PER

IO events can also come from GPIO modules, which reside in the PER domain. It is possible for the PER to enter RET while CORE is still in ON. If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not wakeup in this case, unless we enable it.

---
 arch/arm/mach-omap2/pm34xx.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)
arch/arm/mach-omap2/pm34xx.c +10 -4
index ea0000b..2b2eaaa 100644
@@ -371,6 +371,13 @@ void omap_sram_idle(void)
 	if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
 		pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
 
+	/* Enable IO-PAD and IO-CHAIN wakeups */
+	if (per_next_state < PWRDM_POWER_ON ||
+			core_next_state < PWRDM_POWER_ON) {
+		prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
+		omap3_enable_io_chain();
+	}
+
 	/* PER */
 	per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
 	core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
@@ -398,10 +405,8 @@ void omap_sram_idle(void)
 			omap3_core_save_context();
 			omap3_prcm_save_context();
 		}
-		/* Enable IO-PAD and IO-CHAIN wakeups */
-		prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
-		omap3_enable_io_chain();
 	}
+
 	omap3_intc_prepare_idle();
 
 	/*
@@ -463,7 +468,8 @@ void omap_sram_idle(void)
 	}
 
 	/* Disable IO-PAD and IO-CHAIN wakeup */
-	if (core_next_state < PWRDM_POWER_ON) {
+	if (per_next_state < PWRDM_POWER_ON ||
+			core_next_state < PWRDM_POWER_ON) {
 		prm_clear_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
 		omap3_disable_io_chain();
 	}
Signature · 1 line
1.7.0.1
author
#1 lore raw

PATCH 2/2 omap: pm34xx: Remove PER wakeup dependency on CORE.

We can remove this wakeup dependency since now, when GPIO2-6 are enabled for IO-pad wakeup, PER domain is gauranteed to be awake or be woken up to service.

The previous dependency did not handle all corner cases. Since there was no sleep dependency between CORE and PER domains, if PER enters RET and CORE is ON, PER will not be active for GPIO handling.

---
 arch/arm/mach-omap2/pm34xx.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)
arch/arm/mach-omap2/pm34xx.c +0 -8
index 2b2eaaa..acf180b 100644
@@ -1086,14 +1086,6 @@ static int __init omap3_pm_init(void)
 	omap3_idle_init();
 
 	clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
-	/*
-	 * REVISIT: This wkdep is only necessary when GPIO2-6 are enabled for
-	 * IO-pad wakeup.  Otherwise it will unnecessarily waste power
-	 * waking up PER with every CORE wakeup - see
-	 * http://marc.info/?l=linux-omap&m=121852150710062&w=2
-	*/
-	clkdm_add_wkdep(per_clkdm, core_clkdm);
-
 	if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
 		omap3_secure_ram_storage =
 			kmalloc(0x803F, GFP_KERNEL);
Signature · 1 line
1.7.0.1
#2 lore raw
In reply to Mike Chan
Quoted 6 lines · Mike Chan

IO events can also come from GPIO modules, which reside in the PER domain. It is possible for the PER to enter RET while CORE is still in ON. If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not wakeup in this case, unless we enable it.

Thanks for moving this up to before the potential transition of PER.

But...

Quoted 9 lines
---
 arch/arm/mach-omap2/pm34xx.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)
arch/arm/mach-omap2/pm34xx.c +0 -0
index ea0000b..2b2eaaa 100644

arch/arm/mach-omap2/pm34xx.c void omap_sram_idle(void) · line 380

Quoted 10 lines
arch/arm/mach-omap2/pm34xx.c +7 -0
@@ -371,6 +371,13 @@ void omap_sram_idle(void)
 	if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
 		pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
 
+	/* Enable IO-PAD and IO-CHAIN wakeups */
+	if (per_next_state < PWRDM_POWER_ON ||
+			core_next_state < PWRDM_POWER_ON) {
+		prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
+		omap3_enable_io_chain();
+	}
+

oops, both next_states will always be PWRDM_POWER_ON here as they haven't yet been read...

arch/arm/mach-omap2/pm34xx.c void omap_sram_idle(void) · line 383

Quoted 3 lines
arch/arm/mach-omap2/pm34xx.c +0 -0
 	/* PER */
 	per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
 	core_next_state = pwrdm_read_next_pwrst(core_pwrdm);

until here.

Kevin

author
#3 lore raw
Quoted 36 lines · Kevin Hilman
Quoted 6 lines · Mike Chan

IO events can also come from GPIO modules, which reside in the PER domain. It is possible for the PER to enter RET while CORE is still in ON. If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not wakeup in this case, unless we enable it.

Thanks for moving this up to before the potential transition of PER.

But...

Quoted 9 lines

---
 arch/arm/mach-omap2/pm34xx.c |   14 ++++++++++----

 1 files changed, 10 insertions(+), 4 deletions(-)
arch/arm/mach-omap2/pm34xx.c +0 -0
index ea0000b..2b2eaaa 100644

arch/arm/mach-omap2/pm34xx.c void omap_sram_idle(void) · line 380

Quoted 10 lines
arch/arm/mach-omap2/pm34xx.c +7 -0
@@ -371,6 +371,13 @@ void omap_sram_idle(void)
       if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
               pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
 
+     /* Enable IO-PAD and IO-CHAIN wakeups */
+     if (per_next_state < PWRDM_POWER_ON ||
+                     core_next_state < PWRDM_POWER_ON) {
+             prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
+             omap3_enable_io_chain();
+     }
+

oops, both next_states will always be PWRDM_POWER_ON here as they haven't yet been read...

Quoted 5 lines

arch/arm/mach-omap2/pm34xx.c void omap_sram_idle(void) · line 383

Quoted 3 lines
arch/arm/mach-omap2/pm34xx.c +0 -0
       /* PER */
       per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
       core_next_state = pwrdm_read_next_pwrst(core_pwrdm);

until here.

Sloppy me, I'll send out a v2 that fixes this. Thanks Kevin for catching this.

-- Mike

Quoted 4 lines

Kevin

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