OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

PATCH In review Rajendra Nayak 5 participants 18 messages Jun 16, 2009 – Jun 29, 2009 1 message not in the archive

Subsystems (4)

Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP power management support

lore

Share & tools

lore

Rajendra Nayak

author

2009-06-16 11:52 UTC #0 lore raw

PATCH 1/4 OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored scratchpad value.

This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
This patch however does not optimize the C state threshold for CORE OFF states based on the new latency.

Signed-off-by Rajendra Nayak <[email protected]>

---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/control.c +7 -0

index c9407c0..a7159a9 100644
@@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void)
 			cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
 			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_AUTOIDLE_PLL);
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled before OFF.
+	 * Clear feature before sleep. The origional idle state is
+	 * restored by software as part of wake procedure.
+	 */
+	prcm_block_contents.cm_autoidle_pll &= ~OMAP3430_AUTO_PERIPH_DPLL_MASK;
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
 	prcm_block_contents.cm_clksel2_pll =

Signature · 1 line

1.5.4.7

Rajendra Nayak

author

2009-06-16 11:52 UTC #1 lore raw

PATCH 2/4 OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously

There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF should not be set together. The PRCM FSM has been coded assuming that SW will set either auto_ret or auto_off bit depending on whether the core has been programmed to go into open switched logic retention state or OFF state. They are mutually exclusive. A similar issue will exist if SW sets auto_ret= auto_off=1 and auto_sleep = 1 in the PRM voltage CTRL register

Signed-off-by Rajendra Nayak <[email protected]>

---
 arch/arm/mach-omap2/pm34xx.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

arch/arm/mach-omap2/pm34xx.c +8 -4

index a9ef670..d4225b4 100644
@@ -392,6 +392,10 @@ void omap_sram_idle(void)
 					     OMAP3_PRM_VOLTCTRL_OFFSET);
 			omap3_core_save_context();
 			omap3_prcm_save_context();
+		} else if (core_next_state == PWRDM_POWER_RET) {
+			prm_set_mod_reg_bits(OMAP3430_AUTO_RET,
+						OMAP3430_GR_MOD,
+						OMAP3_PRM_VOLTCTRL_OFFSET);
 		}
 		/* Enable IO-PAD and IO-CHAIN wakeups */
 		prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);

@@ -446,6 +450,10 @@ void omap_sram_idle(void)
 			prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF,
 					       OMAP3430_GR_MOD,
 					       OMAP3_PRM_VOLTCTRL_OFFSET);
+		else if (core_next_state == PWRDM_POWER_RET)
+			prm_clear_mod_reg_bits(OMAP3430_AUTO_RET,
+						OMAP3430_GR_MOD,
+						OMAP3_PRM_VOLTCTRL_OFFSET);
 		/* Enable smartreflex after WFI */
 		enable_smartreflex(SR1);
 		enable_smartreflex(SR2);

@@ -1128,10 +1136,6 @@ static void __init configure_vc(void)
 				OMAP3430_GR_MOD,
 				OMAP3_PRM_VC_I2C_CFG_OFFSET);
 
-	/* Setup value for voltctrl */
-	prm_write_mod_reg(OMAP3430_AUTO_RET,
-			  OMAP3430_GR_MOD, OMAP3_PRM_VOLTCTRL_OFFSET);
-
 	/* Write setup times */
 	prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
 			OMAP3_PRM_CLKSETUP_OFFSET);

Signature · 1 line

1.5.4.7

Rajendra Nayak

author

2009-06-16 11:52 UTC #2 lore raw

PATCH 3/4 OMAP3: PM: Fix I2C voltage levels send to T2 for different Power modes

The ONLP and ONOFF values programed for both VDD1
and VDD2 were not optimal.

New values used are
VDD1
ON - 1.2v
ONLP - 1.0v
ONRET - .975v
ONOFF - .6v

VDD2
ON - 1.15v
ONLP - 1.0v
ONRET - .975v
ONOFF - .6v

Signed-off-by Rajendra Nayak <[email protected]>

---
 arch/arm/mach-omap2/pm34xx.c |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

arch/arm/mach-omap2/pm34xx.c +8 -8

index d4225b4..c2d8b09 100644
@@ -87,14 +87,14 @@ static struct prm_setup_vc prm_setup = {
 	.voltsetup_time2 = 0xfff,
 	.voltoffset = 0xff,
 	.voltsetup2 = 0xff,
-	.vdd0_on = 0x30,
-	.vdd0_onlp = 0x1e,
-	.vdd0_ret = 0x1e,
-	.vdd0_off = 0x30,
-	.vdd1_on = 0x2c,
-	.vdd1_onlp = 0x1e,
-	.vdd1_ret = 0x1e,
-	.vdd1_off = 0x2c,
+	.vdd0_on = 0x30,	/* 1.2v */
+	.vdd0_onlp = 0x20,	/* 1.0v */
+	.vdd0_ret = 0x1e,	/* 0.975v */
+	.vdd0_off = 0x00,	/* 0.6v */
+	.vdd1_on = 0x2c,	/* 1.15v */
+	.vdd1_onlp = 0x20,	/* 1.0v */
+	.vdd1_ret = 0x1e,	/* .975v */
+	.vdd1_off = 0x00,	/* 0.6v */
 };
 
 static inline void omap3_per_save_context(void)

Signature · 1 line

1.5.4.7

Rajendra Nayak

author

2009-06-16 11:52 UTC #3 lore raw

PATCH 4/4 OMAP3: PM: Update sleep/wakeup sequence and device grp associations

This patch enables CONFIG_TWL4030_POWER in omap_3430sdp_pm_defconfig and updates the sleep and wake sequence for 3430sdp. Sleep sequence:
-1-Turn off HFCLKOUT
-2-Turn off Vdd1
-3-Turn off Vdd2
-4-Turn off VPLL1

Wakeup p3 sequence
-1-Turn on HFCLKOUT

Wakeup P12 sequence
-1-Turn on HFCLKOUT
-2-Turn on Vdd1
-3-Turn on Vdd2
-4-Turn on VPLL1

Also HFCLKOUT is associated to device group P3. This makes sure sys clk from PMIC to OMAP is cut during RET as well as OFF.

VDD1 and VDD2 are associated to device group P1 so that they are cut only during OFF.

CLKEN by default is assigned to all device groups and is left unchanged. This makes sure the oscillator is not shutdown in RET states.

Signed-off-by Rajendra Nayak <[email protected]>

---
 arch/arm/configs/omap_3430sdp_pm_defconfig |    2 +-
 arch/arm/mach-omap2/board-3430sdp.c        |   79 +++++++++++++++-------------
 2 files changed, 44 insertions(+), 37 deletions(-)

arch/arm/configs/omap_3430sdp_pm_defconfig +1 -1

index aefdb5b..8ec604c 100644
@@ -777,7 +777,7 @@ CONFIG_SSB_POSSIBLE=y
 # CONFIG_HTC_PASIC3 is not set
 # CONFIG_TPS65010 is not set
 CONFIG_TWL4030_CORE=y
-# CONFIG_TWL4030_POWER is not set
+CONFIG_TWL4030_POWER=y
 # CONFIG_MFD_TMIO is not set
 # CONFIG_MFD_T7L66XB is not set
 # CONFIG_MFD_TC6387XB is not set

arch/arm/mach-omap2/board-3430sdp.c +43 ~~-36~~

118 lines not on this page · raw message

Signature · 1 line

1.5.4.7

Kevin Hilman

2009-06-29 22:29 UTC #4 lore raw

Re: [PATCH 04/04] OMAP3: PM: Update sleep/wakeup sequence and device grp associations

Quoted 20 lines · Rajendra Nayak

This patch enables CONFIG_TWL4030_POWER in omap_3430sdp_pm_defconfig and updates the sleep and wake sequence for 3430sdp. Sleep sequence:
-1-Turn off HFCLKOUT
-2-Turn off Vdd1
-3-Turn off Vdd2
-4-Turn off VPLL1
Wakeup p3 sequence
-1-Turn on HFCLKOUT
Wakeup P12 sequence
-1-Turn on HFCLKOUT
-2-Turn on Vdd1
-3-Turn on Vdd2
-4-Turn on VPLL1
Also HFCLKOUT is associated to device group P3. This makes sure sys clk from PMIC to OMAP is cut during RET as well as OFF.

Quoted 8 lines

VDD1 and VDD2 are associated to device group P1 so that they are cut only during OFF.
CLKEN by default is assigned to all device groups and is left unchanged. This makes sure the oscillator is not shutdown in RET states.
Signed-off-by Rajendra Nayak <[email protected]>

Thanks, pushing to PM branch (and pm-2.6.29)

Kevin

Quoted 151 lines

---
 arch/arm/configs/omap_3430sdp_pm_defconfig |    2 +-
 arch/arm/mach-omap2/board-3430sdp.c        |   79 +++++++++++++++-------------
 2 files changed, 44 insertions(+), 37 deletions(-)

arch/arm/configs/omap_3430sdp_pm_defconfig +1 -1

index aefdb5b..8ec604c 100644
@@ -777,7 +777,7 @@ CONFIG_SSB_POSSIBLE=y
 # CONFIG_HTC_PASIC3 is not set
 # CONFIG_TPS65010 is not set
 CONFIG_TWL4030_CORE=y
-# CONFIG_TWL4030_POWER is not set
+CONFIG_TWL4030_POWER=y
 # CONFIG_MFD_TMIO is not set
 # CONFIG_MFD_T7L66XB is not set
 # CONFIG_MFD_TC6387XB is not set

arch/arm/mach-omap2/board-3430sdp.c +43 ~~-36~~

index 1f0aeb2..4587815 100644
@@ -47,8 +47,6 @@
 #include "pm.h"
 #include "omap3-opp.h"
 
-#define CONFIG_DISABLE_HFCLK 1
-
 #define SDP3430_ETHR_START		DEBUG_BASE
 #define SDP3430_ETHR_GPIO_IRQ_SDPV1	29
 #define SDP3430_ETHR_GPIO_IRQ_SDPV2	6

@@ -412,18 +410,14 @@ static struct twl4030_madc_platform_data sdp3430_madc_data = {
 
 
 static struct twl4030_ins __initdata sleep_on_seq[] = {
-/*
- * Turn off VDD1 and VDD2.
- */
-	{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 4},
+	/* Turn off HFCLKOUT */
+	{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_OFF), 2},
+	/* Turn OFF VDD1 */
+	{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 2},
+	/* Turn OFF VDD2 */
 	{MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_OFF), 2},
-#ifdef CONFIG_DISABLE_HFCLK
-/*
- * And also turn off the OMAP3 PLLs and the sysclk output.
- */
-	{MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_OFF), 3},
-	{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_OFF), 3},
-#endif
+	/* Turn OFF VPLL1 */
+	{MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_OFF), 2},
 };
 
 static struct twl4030_script sleep_on_script __initdata = {

@@ -432,30 +426,31 @@ static struct twl4030_script sleep_on_script __initdata = {
 	.flags	= TRITON_SLEEP_SCRIPT,
 };
 
-static struct twl4030_ins wakeup_seq[] __initdata = {
-#ifndef CONFIG_DISABLE_HFCLK
-/*
- * Wakeup VDD1 and VDD2.
- */
-	{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_ACTIVE), 4},
+static struct twl4030_ins wakeup_p12_seq[] __initdata = {
+	/* Turn on HFCLKOUT */
+	{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+	/* Turn ON VDD1 */
+	{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_ACTIVE), 2},
+	/* Turn ON VDD2 */
 	{MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_ACTIVE), 2},
-#else
-/*
- * Reenable the OMAP3 PLLs.
- * Wakeup VDD1 and VDD2.
- * Reenable sysclk output.
- */
-	{MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_ACTIVE), 0x30},
-	{MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_ACTIVE), 0x30},
-	{MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_ACTIVE), 0x37},
-	{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 3},
-#endif /* #ifndef CONFIG_DISABLE_HFCLK */
+	/* Turn ON VPLL1 */
+	{MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_ACTIVE), 2},
 };
 
-static struct twl4030_script wakeup_script __initdata = {
-	.script	= wakeup_seq,
-	.size	= ARRAY_SIZE(wakeup_seq),
-	.flags	= TRITON_WAKEUP12_SCRIPT | TRITON_WAKEUP3_SCRIPT,
+static struct twl4030_script wakeup_p12_script __initdata = {
+	.script	= wakeup_p12_seq,
+	.size	= ARRAY_SIZE(wakeup_p12_seq),
+	.flags	= TRITON_WAKEUP12_SCRIPT,
+};
+
+static struct twl4030_ins wakeup_p3_seq[] __initdata = {
+	{MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wakeup_p3_script __initdata = {
+	.script = wakeup_p3_seq,
+	.size   = ARRAY_SIZE(wakeup_p3_seq),
+	.flags  = TRITON_WAKEUP3_SCRIPT,
 };
 
 static struct twl4030_ins wrst_seq[] __initdata = {

@@ -476,19 +471,31 @@ static struct twl4030_ins wrst_seq[] __initdata = {
 };
 static struct twl4030_script wrst_script __initdata = {
 	.script = wrst_seq,
-	.size   = ARRAY_SIZE(wakeup_seq),
+	.size   = ARRAY_SIZE(wrst_seq),
 	.flags  = TRITON_WRST_SCRIPT,
 };
 
 static struct twl4030_script *twl4030_scripts[] __initdata = {
 	&sleep_on_script,
-	&wakeup_script,
+	&wakeup_p12_script,
+	&wakeup_p3_script,
 	&wrst_script,
 };
 
+static struct twl4030_resconfig twl4030_rconfig[] = {
+	{ .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+		.type2 = -1 },
+	{ .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+		.type2 = -1 },
+	{ .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+		.type2 = -1 },
+	{ 0, 0},
+};
+
 static struct twl4030_power_data sdp3430_t2scripts_data __initdata = {
 	.scripts	= twl4030_scripts,
 	.size		= ARRAY_SIZE(twl4030_scripts),
+	.resource_config = twl4030_rconfig,
 };
 
 /*

Signature · 6 lines

1.5.4.7

--
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

Kevin Hilman

2009-06-29 21:48 UTC #5 lore raw

Re: [PATCH 03/04] OMAP3: PM: Fix I2C voltage levels send to T2 for different Power modes

In reply to Rajendra Nayak

Quoted 10 lines · Rajendra Nayak

The ONLP and ONOFF values programed for both VDD1
and VDD2 were not optimal.
New values used are
VDD1
ON - 1.2v
ONLP - 1.0v
ONRET - .975v
ONOFF - .6v

Quoted 7 lines

VDD2
ON - 1.15v
ONLP - 1.0v
ONRET - .975v
ONOFF - .6v
Signed-off-by Rajendra Nayak <[email protected]>

Thanks, pushing to PM branch (and pm-2.6.29)

Kevin

Quoted 38 lines

---
 arch/arm/mach-omap2/pm34xx.c |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

arch/arm/mach-omap2/pm34xx.c +8 -8

index d4225b4..c2d8b09 100644
@@ -87,14 +87,14 @@ static struct prm_setup_vc prm_setup = {
 	.voltsetup_time2 = 0xfff,
 	.voltoffset = 0xff,
 	.voltsetup2 = 0xff,
-	.vdd0_on = 0x30,
-	.vdd0_onlp = 0x1e,
-	.vdd0_ret = 0x1e,
-	.vdd0_off = 0x30,
-	.vdd1_on = 0x2c,
-	.vdd1_onlp = 0x1e,
-	.vdd1_ret = 0x1e,
-	.vdd1_off = 0x2c,
+	.vdd0_on = 0x30,	/* 1.2v */
+	.vdd0_onlp = 0x20,	/* 1.0v */
+	.vdd0_ret = 0x1e,	/* 0.975v */
+	.vdd0_off = 0x00,	/* 0.6v */
+	.vdd1_on = 0x2c,	/* 1.15v */
+	.vdd1_onlp = 0x20,	/* 1.0v */
+	.vdd1_ret = 0x1e,	/* .975v */
+	.vdd1_off = 0x00,	/* 0.6v */
 };
 
 static inline void omap3_per_save_context(void)

Signature · 6 lines

1.5.4.7

--
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

Högander Jouni

2009-06-16 12:41 UTC #6 lore raw

Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously

In reply to Rajendra Nayak

Quoted 5 lines · ext Rajendra Nayak

There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF should not be set together. The PRCM FSM has been coded assuming that SW will set either auto_ret or auto_off bit depending on whether the core has been programmed to go into open switched logic retention state or OFF state. They are mutually exclusive.

So we don't have to do this if closed switch retention is used? (This is what is currently used in linux-omap:pm)

Quoted 52 lines

A similar issue will exist if SW sets auto_ret= auto_off=1 and auto_sleep = 1 in the PRM voltage CTRL register

Signed-off-by Rajendra Nayak <[email protected]>

---
 arch/arm/mach-omap2/pm34xx.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

arch/arm/mach-omap2/pm34xx.c +8 -4

index a9ef670..d4225b4 100644
@@ -392,6 +392,10 @@ void omap_sram_idle(void)
 					     OMAP3_PRM_VOLTCTRL_OFFSET);
 			omap3_core_save_context();
 			omap3_prcm_save_context();
+		} else if (core_next_state == PWRDM_POWER_RET) {
+			prm_set_mod_reg_bits(OMAP3430_AUTO_RET,
+						OMAP3430_GR_MOD,
+						OMAP3_PRM_VOLTCTRL_OFFSET);
 		}
 		/* Enable IO-PAD and IO-CHAIN wakeups */
 		prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);

@@ -446,6 +450,10 @@ void omap_sram_idle(void)
 			prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF,
 					       OMAP3430_GR_MOD,
 					       OMAP3_PRM_VOLTCTRL_OFFSET);
+		else if (core_next_state == PWRDM_POWER_RET)
+			prm_clear_mod_reg_bits(OMAP3430_AUTO_RET,
+						OMAP3430_GR_MOD,
+						OMAP3_PRM_VOLTCTRL_OFFSET);
 		/* Enable smartreflex after WFI */
 		enable_smartreflex(SR1);
 		enable_smartreflex(SR2);

@@ -1128,10 +1136,6 @@ static void __init configure_vc(void)
 				OMAP3430_GR_MOD,
 				OMAP3_PRM_VC_I2C_CFG_OFFSET);
 
-	/* Setup value for voltctrl */
-	prm_write_mod_reg(OMAP3430_AUTO_RET,
-			  OMAP3430_GR_MOD, OMAP3_PRM_VOLTCTRL_OFFSET);
-
 	/* Write setup times */
 	prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
 			OMAP3_PRM_CLKSETUP_OFFSET);

Signature · 6 lines

1.5.4.7

--
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

Signature · 5 lines

Jouni Högander
--
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

Nayak, Rajendra

author

2009-06-16 13:16 UTC #7 lore raw

RE: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously

Quoted 12 lines

-----Original Message-----
From: Högander Jouni [mailto:[email protected]]
Sent: Tuesday, June 16, 2009 6:10 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously
ext Rajendra Nayak <[email protected]> writes:

Quoted 8 lines

Quoted 5 lines
There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF should not be set together. The PRCM FSM has been coded assuming that SW will set either auto_ret or auto_off bit depending on whether the core has been programmed to go into open switched logic retention state or OFF state. They are mutually exclusive.
So we don't have to do this if closed switch retention is used? (This is what is currently used in linux-omap:pm)

Currently in the pm branch AUTO_RET is enabled at init and kept enabled. While attempting a OFF state AUTO_OFF is enabled also leaving AUTO_RET and AUTO_OFF both enabled.

Quoted 63 lines

Review
Quoted 10 lines
A similar issue will exist if SW sets auto_ret= auto_off=1 and auto_sleep = 1 in the PRM voltage CTRL register
Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/pm34xx.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)
(quoted diff) +0 -0
b/arch/arm/mach-omap2/pm34xx.c
arch/arm/mach-omap2/pm34xx.c void omap_sram_idle(void) · line 398
Quoted 11 lines
index a9ef670..d4225b4 100644
arch/arm/mach-omap2/pm34xx.c +4 -0
@@ -392,6 +392,10 @@ void omap_sram_idle(void)
 					     OMAP3_PRM_VOLTCTRL_OFFSET);
 			omap3_core_save_context();
 			omap3_prcm_save_context();
+		} else if (core_next_state == PWRDM_POWER_RET) {
+			prm_set_mod_reg_bits(OMAP3430_AUTO_RET,
+						OMAP3430_GR_MOD,
+						
OMAP3_PRM_VOLTCTRL_OFFSET);
arch/arm/mach-omap2/pm34xx.c void omap_sram_idle(void) · line 452
Quoted 7 lines
arch/arm/mach-omap2/pm34xx.c +0 -0
 		}
 		/* Enable IO-PAD and IO-CHAIN wakeups */
 		prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
@@ -446,6 +450,10 @@ void omap_sram_idle(void)
 			prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF,
 					       OMAP3430_GR_MOD,
 
OMAP3_PRM_VOLTCTRL_OFFSET);
arch/arm/mach-omap2/pm34xx.c void omap_sram_idle(void)
Quoted 4 lines
arch/arm/mach-omap2/pm34xx.c +4 -0
+		else if (core_next_state == PWRDM_POWER_RET)
+			prm_clear_mod_reg_bits(OMAP3430_AUTO_RET,
+						OMAP3430_GR_MOD,
+						
OMAP3_PRM_VOLTCTRL_OFFSET);
Quoted 19 lines
arch/arm/mach-omap2/pm34xx.c +0 -4
 		/* Enable smartreflex after WFI */
 		enable_smartreflex(SR1);
 		enable_smartreflex(SR2);
@@ -1128,10 +1136,6 @@ static void __init configure_vc(void)
 				OMAP3430_GR_MOD,
 				OMAP3_PRM_VC_I2C_CFG_OFFSET);
 
-	/* Setup value for voltctrl */
-	prm_write_mod_reg(OMAP3430_AUTO_RET,
-			  OMAP3430_GR_MOD, OMAP3_PRM_VOLTCTRL_OFFSET);
-
 	/* Write setup times */
 	prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
 			OMAP3_PRM_CLKSETUP_OFFSET);
Signature · 4 lines
1.5.4.7

--
To unsubscribe from this list: send the line "unsubscribe 
linux-omap" in
Quoted 2 lines
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Jouni Högander

Kevin Hilman

2009-06-16 14:28 UTC #8 lore raw

Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously

Quoted 10 lines · Rajendra

From: Högander Jouni [mailto:[email protected]]
Quoted 9 lines
Quoted 5 lines · ext Rajendra Nayak
There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF should not be set together. The PRCM FSM has been coded assuming that SW will set either auto_ret or auto_off bit depending on whether the core has been programmed to go into open switched logic retention state or OFF state. They are mutually exclusive.

Quoted 6 lines

Quoted 2 lines
So we don't have to do this if closed switch retention is used? (This is what is currently used in linux-omap:pm)
Currently in the pm branch AUTO_RET is enabled at init and kept enabled. While attempting a OFF state AUTO_OFF is enabled also leaving AUTO_RET and AUTO_OFF both enabled.

A little more clarification needed, in particular whether or how this affects closed-switch retention.

The description above states that this problem affects OSWR and OFF. linux-omap PM only uses CSWR, so based on the description of the PRCM FSM above, for CSWR, we should never be setting AUTO_RET when using CSWR.

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Kevin Hilman

2009-06-16 17:28 UTC #10 lore raw

Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously

Hi David,

Thanks for the extra clarifications. Is this Table you sent in the TRM somewhere? I don't find it in my ES3.1 NDA TRM ver. P.

For the various C-states in CPUidle, we do indeed have various combinations of MPU and CORE state, from cpuidle34xx.c:

/* omap3_init_power_states - Initialises the OMAP3 specific C states.
*
* Below is the desciption of each C state.
* C1 . MPU WFI + Core active
* C2 . MPU WFI + Core inactive
* C3 . MPU CSWR + Core inactive
* C4 . MPU OFF + Core inactive
* C5 . MPU CSWR + Core CSWR
* C6 . MPU OFF + Core CSWR
* C7 . MPU OFF + Core OFF
*/

Maybe the right solution is to have the PRM_VOLTCTRL value associated with the C-state so we minimize the amount of conditional logic we have to do in idle loop itself. Otherwise tracking all these combinations in the idle loop could get ugly. We also don't currently do anything with AUTO_SLEEP, and it looks like we should.

But, getting back to the original patch, based on the table you sent, the description in the original patch makes even less sense to me. It says basically that AUTO_RET and AUTO_OFF are mutually exclusive. The table suggests otherwise, and shows that you'll never hit 0V unless both are set.

So I still think the original patch description needs an update.

Kevin

Quoted 115 lines · David

Kevin,
Not sure this change has been done yet. But basically when you have mis-matched power states between the MPU and CORE, you may run into a situation where the voltage does not scale. As long as both MPU and CORE go into the same power state then there is not a problem. See the following table to better understand:
Table 1. AUTO Voltage Scaling
+----------------------------------------------------------------------------------------------------+
|MPU  Power     |CORE Power State |AUTO_OFF    |AUTO_RETENTION    |AUTO_SLEEP    |VDD1    |VDD2      |
|State          |                 |            |                  |              |        |          |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |       OFF       |     0      |        1         |      1       |  1.0V  |   0.9V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |       OFF       |     0      |        1         |      0       |  0.9V  |   0.9V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |       OFF       |     1      |        1         |      1       |0V/0.6V*|0V/0.6mV* |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |  OSWR or CSWR   |     0      |        1         |      1       |  1.0V  |   0.9V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |  OSWR or CSWR   |     0      |        1         |      0       |  0.9V  |   0.9V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |  OSWR or CSWR   |     1      |        1         |      1       |  1.2V  |  1.15V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|     CSWR      |  ON (INACTIVE)  |     0      |        1         |      0       |  0.9V  |  1.15V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|     CSWR      |  ON (INACTIVE)  |     0      |        1         |      1       |  0.9V  |   1.0V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|     CSWR      |  ON (INACTIVE)  |     0      |        0         |      1       |  1.0V  |   1.0V   |
+----------------------------------------------------------------------------------------------------+
* Using SYS_OFFMODE / Using I2C4
You need to dynamically enable and disable the auto voltage scaling (AUTO_OFF, AUTO_RET and AUTO_SLEEP) based on which sleep configuration you are going into for MPU and CORE.
Regards,
David
-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, June 16, 2009 9:28 AM
To: Nayak, Rajendra
Cc: Högander Jouni; [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously
Quoted 26 lines · Rajendra
From: Högander Jouni [mailto:[email protected]]
Quoted 14 lines
Quoted 7 lines · ext Rajendra Nayak
There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF
should not be set together. The PRCM FSM has been coded assuming
that SW will set either auto_ret or auto_off bit depending on
whether the core has been programmed to go into open switched
Quoted 7 lines
Quoted 1 line
logic retention state or OFF state. They are mutually exclusive.
So we don't have to do this if closed switch retention is used? (This
is what is currently used in linux-omap:pm)
Quoted 5 lines
Currently in the pm branch AUTO_RET is enabled at init and kept
enabled. While attempting a OFF state AUTO_OFF is enabled also
leaving AUTO_RET and AUTO_OFF both enabled.
A little more clarification needed, in particular whether or how
this affects closed-switch retention.
The description above states that this problem affects OSWR and OFF.
linux-omap PM only uses CSWR, so based on the description of the PRCM

Quoted 9 lines

FSM above, for CSWR, we should never be setting AUTO_RET when using
CSWR.
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

Derrick, David

2009-06-17 16:52 UTC #11 lore raw

RE: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously

Hi Kevin,

Setting auto voltage scaling with C-states is good idea.

AUTO_SLEEP is when you idle with power state set to "ON" - otherwise known as INACTIVE.

Sorry for the confusion on the table. I did not show all combinations. You will get 0V in OFF mode with just AUTO_OFF set, the other 2 (AUTO_RET and AUTO_SLEEP don't have to be set but do not hurt if they are set). My point was to show that when MPU and CORE do not have the same power state settings then you need to pay attention to the AUTO voltage settings otherwise you may not get voltage scaling. If MPU and CORE have the same power state then you are OK setting all three (AUTO_OFF, AUTO_RET and AUTO_SLEEP).

Regards,
David

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, June 16, 2009 12:28 PM
To: Derrick, David
Cc: Nayak, Rajendra; Högander Jouni; [email protected]; Woodruff, Richard
Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously

Hi David,

Thanks for the extra clarifications. Is this Table you sent in the TRM somewhere? I don't find it in my ES3.1 NDA TRM ver. P.

For the various C-states in CPUidle, we do indeed have various combinations of MPU and CORE state, from cpuidle34xx.c:

So I still think the original patch description needs an update.

Kevin

Quoted 115 lines · David

Kevin,
Not sure this change has been done yet. But basically when you have mis-matched power states between the MPU and CORE, you may run into a situation where the voltage does not scale. As long as both MPU and CORE go into the same power state then there is not a problem. See the following table to better understand:
Table 1. AUTO Voltage Scaling
+----------------------------------------------------------------------------------------------------+
|MPU  Power     |CORE Power State |AUTO_OFF    |AUTO_RETENTION    |AUTO_SLEEP    |VDD1    |VDD2      |
|State          |                 |            |                  |              |        |          |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |       OFF       |     0      |        1         |      1       |  1.0V  |   0.9V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |       OFF       |     0      |        1         |      0       |  0.9V  |   0.9V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |       OFF       |     1      |        1         |      1       |0V/0.6V*|0V/0.6mV* |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |  OSWR or CSWR   |     0      |        1         |      1       |  1.0V  |   0.9V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |  OSWR or CSWR   |     0      |        1         |      0       |  0.9V  |   0.9V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|      OFF      |  OSWR or CSWR   |     1      |        1         |      1       |  1.2V  |  1.15V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|     CSWR      |  ON (INACTIVE)  |     0      |        1         |      0       |  0.9V  |  1.15V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|     CSWR      |  ON (INACTIVE)  |     0      |        1         |      1       |  0.9V  |   1.0V   |
|---------------+-----------------+------------+------------------+--------------+--------+----------|
|     CSWR      |  ON (INACTIVE)  |     0      |        0         |      1       |  1.0V  |   1.0V   |
+----------------------------------------------------------------------------------------------------+
* Using SYS_OFFMODE / Using I2C4
You need to dynamically enable and disable the auto voltage scaling (AUTO_OFF, AUTO_RET and AUTO_SLEEP) based on which sleep configuration you are going into for MPU and CORE.
Regards,
David
-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, June 16, 2009 9:28 AM
To: Nayak, Rajendra
Cc: Högander Jouni; [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously
Quoted 26 lines · Rajendra
From: Högander Jouni [mailto:[email protected]]
Quoted 14 lines
Quoted 7 lines · ext Rajendra Nayak
There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF
should not be set together. The PRCM FSM has been coded assuming
that SW will set either auto_ret or auto_off bit depending on
whether the core has been programmed to go into open switched
Quoted 7 lines
Quoted 1 line
logic retention state or OFF state. They are mutually exclusive.
So we don't have to do this if closed switch retention is used? (This
is what is currently used in linux-omap:pm)
Quoted 5 lines
Currently in the pm branch AUTO_RET is enabled at init and kept
enabled. While attempting a OFF state AUTO_OFF is enabled also
leaving AUTO_RET and AUTO_OFF both enabled.
A little more clarification needed, in particular whether or how
this affects closed-switch retention.
The description above states that this problem affects OSWR and OFF.
linux-omap PM only uses CSWR, so based on the description of the PRCM

Quoted 9 lines

FSM above, for CSWR, we should never be setting AUTO_RET when using
CSWR.
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

Nayak, Rajendra

author

2009-06-17 06:27 UTC #12 lore raw

RE: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously

In reply to Kevin Hilman

Quoted 26 lines

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, June 16, 2009 7:58 PM
To: Nayak, Rajendra
Cc: Högander Jouni; [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously
Quoted 13 lines · Rajendra
From: Högander Jouni [mailto:[email protected]]
Quoted 11 lines
Quoted 5 lines · ext Rajendra Nayak
There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF should not be set together. The PRCM FSM has been coded assuming that SW will set either auto_ret or auto_off bit depending on whether the core has been programmed to go into open switched logic retention state or OFF state. They are mutually exclusive.
So we don't have to do this if closed switch retention is used? (This is what is currently used in linux-omap:pm)

Quoted 6 lines

Quoted 3 lines
Currently in the pm branch AUTO_RET is enabled at init and kept enabled. While attempting a OFF state AUTO_OFF is enabled also leaving AUTO_RET and AUTO_OFF both enabled.
A little more clarification needed, in particular whether or how this affects closed-switch retention.

Sorry, that was a wrong description. AUTO_RET could be used to scale the voltage down even in case of CSWR and not just OSWR.

The idea of this patch was to enable auto voltage scaling only for the last 3 C states.

* C5 . MPU CSWR + Core CSWR - AUTO RET enabled
* C6 . MPU OFF + Core CSWR - AUTO RET enabled
* C7 . MPU OFF + Core OFF - AUTO OFF enabled.

For the rest of the Lower C states the decision of not enabling AUTO RET/OFF was to keep the latency for such states down.

Especially with SR enabled having AUTO RET/OFF enabled for say a MPU RET/CORE inactive state would mean a 2 level voltage change. First to scale from SR autocompensated level to the actual OPP voltage level (That's done when you disable SR) and then from the there to the AUTO RET level.
So say you hit MPU RET/CORE inactive state at OPP3 (1.2v) which has a SR autocompensated voltage to 1.08v, then you would scale from 1.08->1.2->0.975.
That might be too much of additional latency to incure in case of a MPU RET/CORE inactive state.

Quoted 9 lines

The description above states that this problem affects OSWR and OFF. linux-omap PM only uses CSWR, so based on the description of the PRCM FSM above, for CSWR, we should never be setting AUTO_RET when using CSWR.
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

Kevin Hilman

2009-06-29 21:45 UTC #13 lore raw

Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously

Quoted 34 lines · Rajendra

Quoted 15 lines
Quoted 13 lines · Rajendra
From: Högander Jouni [mailto:[email protected]]
Quoted 11 lines
Quoted 5 lines · ext Rajendra Nayak
There is a design requirement in OMAP3 that Auto_RET and AUTO_OFF should not be set together. The PRCM FSM has been coded assuming that SW will set either auto_ret or auto_off bit depending on whether the core has been programmed to go into open switched logic retention state or OFF state. They are mutually exclusive.
So we don't have to do this if closed switch retention is used? (This is what is currently used in linux-omap:pm)
Quoted 6 lines
Quoted 3 lines
Currently in the pm branch AUTO_RET is enabled at init and kept enabled. While attempting a OFF state AUTO_OFF is enabled also leaving AUTO_RET and AUTO_OFF both enabled.
A little more clarification needed, in particular whether or how this affects closed-switch retention.
Sorry, that was a wrong description. AUTO_RET could be used to scale the voltage down even in case of CSWR and not just OSWR.
The idea of this patch was to enable auto voltage scaling only for the last 3 C states.
* C5 . MPU CSWR + Core CSWR - AUTO RET enabled
* C6 . MPU OFF + Core CSWR - AUTO RET enabled
* C7 . MPU OFF + Core OFF - AUTO OFF enabled.
For the rest of the Lower C states the decision of not enabling AUTO RET/OFF was to keep the latency for such states down.

Quoted 10 lines

Especially with SR enabled having AUTO RET/OFF enabled for say a MPU RET/CORE inactive state would mean a 2 level voltage change. First to scale from SR autocompensated level to the actual OPP voltage level (That's done when you disable SR) and then from the there to the AUTO RET level. So say you hit MPU RET/CORE inactive state at OPP3 (1.2v) which has a SR autocompensated voltage to 1.08v, then you would scale from 1.08->1.2->0.975. That might be too much of additional latency to incure in case of a MPU RET/CORE inactive state.

OK, I've updated the patch description on this one and will push to PM branch (and pm-2.6.29)

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

Högander Jouni

2009-06-16 12:54 UTC #14 lore raw

In reply to Rajendra Nayak

Quoted 10 lines · ext Rajendra Nayak

If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored scratchpad value.
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
This patch however does not optimize the C state threshold for CORE OFF states based on the new latency.

Do you have any numbers to give on what is the impact to consumption?

Quoted 31 lines

Signed-off-by Rajendra Nayak <[email protected]>

---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/control.c +7 -0

index c9407c0..a7159a9 100644
@@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void)
 			cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
 			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_AUTOIDLE_PLL);
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled before OFF.
+	 * Clear feature before sleep. The origional idle state is
+	 * restored by software as part of wake procedure.
+	 */
+	prcm_block_contents.cm_autoidle_pll &= ~OMAP3430_AUTO_PERIPH_DPLL_MASK;
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
 	prcm_block_contents.cm_clksel2_pll =

Signature · 6 lines

1.5.4.7

--
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

Signature · 5 lines

Jouni Högander
--
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

Nayak, Rajendra

author

2009-06-16 13:17 UTC #15 lore raw

Quoted 16 lines

-----Original Message-----
From: Högander Jouni [mailto:[email protected]]
Sent: Tuesday, June 16, 2009 6:23 PM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Quoted 5 lines · ext Rajendra Nayak
If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored scratchpad value.

Quoted 7 lines

Quoted 5 lines
This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
This patch however does not optimize the C state threshold for CORE OFF states based on the new latency.
Do you have any numbers to give on what is the impact to consumption?

Not yet, I will post some after some profiling.

Quoted 43 lines

Review
Quoted 8 lines
Signed-off-by Rajendra Nayak <[email protected]>
---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
(quoted diff) +0 -0
b/arch/arm/mach-omap2/control.c
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 240
Quoted 7 lines
index c9407c0..a7159a9 100644
arch/arm/mach-omap2/control.c +0 -0
@@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void)
 			cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_AUTOIDLE_PLL);
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void) · line 242
Quoted 2 lines
arch/arm/mach-omap2/control.c +2 -0
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled 
before OFF.
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void)
Quoted 4 lines
arch/arm/mach-omap2/control.c +4 -0
+	 * Clear feature before sleep. The origional idle state is
+	 * restored by software as part of wake procedure.
+	 */
+	prcm_block_contents.cm_autoidle_pll &= 
~OMAP3430_AUTO_PERIPH_DPLL_MASK;
arch/arm/mach-omap2/control.c void omap3_save_scratchpad_contents(void)
Quoted 3 lines
arch/arm/mach-omap2/control.c +1 -0
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, 
OMAP3430_CM_CLKSEL1_PLL);
Quoted 6 lines
arch/arm/mach-omap2/control.c +0 -0
 	prcm_block_contents.cm_clksel2_pll =
Signature · 4 lines
1.5.4.7

--
To unsubscribe from this list: send the line "unsubscribe 
linux-omap" in
Quoted 2 lines
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Jouni Högander

Kevin Hilman

2009-06-16 14:21 UTC #16 lore raw

In reply to Rajendra Nayak

Quoted 5 lines · Rajendra Nayak

If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored scratchpad value.

Quoted 7 lines

This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
This patch however does not optimize the C state threshold for CORE OFF states based on the new latency.
Signed-off-by Rajendra Nayak <[email protected]>

Please forgive the DPLL ignorance here, but I think a little more verbose description is needed here, especially for those of use who don't understand all the voodoo involved with DPLLs and ROM code interaction.

Quoted 1 line

From this description, it's not clear what the resulting state of

DPLL4 will be and thus what the impact might be on power consumption.

IOW, Does this leave the DPLL in a locked, or is ROM code is doing a software-programmed transition to low-power stop? or is there some other automatic disable when PER goes to OFF?

Can you clarify and update the description. Thanks.

Kevin

Quoted 29 lines

---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/control.c +7 -0

index c9407c0..a7159a9 100644
@@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void)
 			cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
 			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_AUTOIDLE_PLL);
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled before OFF.
+	 * Clear feature before sleep. The origional idle state is
+	 * restored by software as part of wake procedure.
+	 */
+	prcm_block_contents.cm_autoidle_pll &= ~OMAP3430_AUTO_PERIPH_DPLL_MASK;
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
 	prcm_block_contents.cm_clksel2_pll =

Signature · 6 lines

1.5.4.7

--
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

Derrick, David

2009-06-16 16:10 UTC #17 lore raw

Kevin,

There is a feature to auto idle DPLLs.
The DPLLs will go into a bypass mode when not needed.

The boot ROM restores some PRCM registers from scratchpad memory when waking up from the OFF power mode.
The procedure in the boot ROM is to restore the DPLL4 settings and then poll until the DPLL4 has locked. There is a timeout on the poll of 20ms.

If you store into scratchpad the register such that the autoidle is enabled, then as soon as the boot ROM locks DPLL4 it will immediately go into bypass. Therefore the poll on the DPLL4 locking will time out (20ms).

If you store into scratchpad the register such that the autoidle is not enabled, then the boot ROM will lock DPLL4 and poll until the DPLL4 is locked - which happens in the usec range.

You need to ensure that you re-enable the autoidle of DPLL4 after you get back to user code - which is already done in our base port so you shouldn't have to worry with it unless you have removed this code.

This change allows the wake up latency from OFF mode to be reduced by 20msec.

Note that we have seen some instability with this change so use with caution.

Regards,
David

-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: Tuesday, June 16, 2009 9:21 AM
To: Nayak, Rajendra
Cc: [email protected]; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

Quoted 5 lines · Rajendra Nayak

If autoidle for DPLL4 is enabled in the stored scratchpad value of CM_AUTOIDLE_PLL then there is an added delay by the boot ROM when coming out of OFF mode.
The patch disables this bitfield in the stored scratchpad value.

Quoted 7 lines

This should significantly reduce CORE OFF latency and also bring down the threshold for CORE OFF, making OFF affordable even with smaller sleep times.
This patch however does not optimize the C state threshold for CORE OFF states based on the new latency.
Signed-off-by Rajendra Nayak <[email protected]>

Quoted 1 line

From this description, it's not clear what the resulting state of

DPLL4 will be and thus what the impact might be on power consumption.

IOW, Does this leave the DPLL in a locked, or is ROM code is doing a software-programmed transition to low-power stop? or is there some other automatic disable when PER goes to OFF?

Can you clarify and update the description. Thanks.

Kevin

Quoted 29 lines

---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/control.c +7 -0

index c9407c0..a7159a9 100644
@@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void)
 			cm_read_mod_reg(PLL_MOD, CM_CLKEN);
 	prcm_block_contents.cm_autoidle_pll =
 			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_AUTOIDLE_PLL);
+	/*
+	 * ROM restore takes 20mS longer if PER idle is enabled before OFF.
+	 * Clear feature before sleep. The origional idle state is
+	 * restored by software as part of wake procedure.
+	 */
+	prcm_block_contents.cm_autoidle_pll &= ~OMAP3430_AUTO_PERIPH_DPLL_MASK;
+
 	prcm_block_contents.cm_clksel1_pll =
 			cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
 	prcm_block_contents.cm_clksel2_pll =

Signature · 6 lines

1.5.4.7

--
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

Paul Walmsley

2009-06-17 08:33 UTC #18 lore raw

Hello David,

Quoted 1 line · David

Note that we have seen some instability with this change so use with caution.

Could you please expand on this? Presumably we should not merge this if it will cause instability, no?

- Paul