[PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

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

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/control.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index c9407c0..a7159a9 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -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 =
-- 
1.5.4.7

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

[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.
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 <rnayak@ti.com>
---
 arch/arm/mach-omap2/pm34xx.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a9ef670..d4225b4 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -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);
-- 
1.5.4.7

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

[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

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

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/pm34xx.c |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index d4225b4..c2d8b09 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -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)
-- 
1.5.4.7

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

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

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 <rnayak@ti.com>
---
 arch/arm/configs/omap_3430sdp_pm_defconfig |    2 +-
 arch/arm/mach-omap2/board-3430sdp.c        |   79 +++++++++++++++-------------
 2 files changed, 44 insertions(+), 37 deletions(-)

diff --git a/arch/arm/configs/omap_3430sdp_pm_defconfig b/arch/arm/configs/omap_3430sdp_pm_defconfig
index aefdb5b..8ec604c 100644
--- a/arch/arm/configs/omap_3430sdp_pm_defconfig
+++ b/arch/arm/configs/omap_3430sdp_pm_defconfig
@@ -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
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 1f0aeb2..4587815 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -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,
 };
 
 /*
-- 
1.5.4.7

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

[Högander Jouni]

ext Rajendra Nayak <rnayak@ti.com> writes:

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

> 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 <rnayak@ti.com>
> ---
>  arch/arm/mach-omap2/pm34xx.c |   12 ++++++++----
>  1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index a9ef670..d4225b4 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -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);
> -- 
> 1.5.4.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Högander Jouni]

ext Rajendra Nayak <rnayak@ti.com> writes:

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

>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
>  arch/arm/mach-omap2/control.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> index c9407c0..a7159a9 100644
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -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 =
> -- 
> 1.5.4.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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

[Nayak, Rajendra]

 

>-----Original Message-----
>From: Högander Jouni [mailto:jouni.hogander@nokia.com] 
>Sent: Tuesday, June 16, 2009 6:10 PM
>To: Nayak, Rajendra
>Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and 
>AUTO_OFF being enabled simultaneously
>
>ext Rajendra Nayak <rnayak@ti.com> writes:
>
>> 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.

>
>> 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 <rnayak@ti.com>
>> ---
>>  arch/arm/mach-omap2/pm34xx.c |   12 ++++++++----
>>  1 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c 
>b/arch/arm/mach-omap2/pm34xx.c
>> index a9ef670..d4225b4 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -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);
>> -- 
>> 1.5.4.7
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe 
>linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>-- 
>Jouni Högander
>
>

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Nayak, Rajendra]

>-----Original Message-----
>From: Högander Jouni [mailto:jouni.hogander@nokia.com] 
>Sent: Tuesday, June 16, 2009 6:23 PM
>To: Nayak, Rajendra
>Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
>Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle 
>before OFF, reduces OFF latency by 20ms
>
>ext Rajendra Nayak <rnayak@ti.com> writes:
>
>> 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?

Not yet, I will post some after some profiling.

>
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> ---
>>  arch/arm/mach-omap2/control.c |    7 +++++++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/control.c 
>b/arch/arm/mach-omap2/control.c
>> index c9407c0..a7159a9 100644
>> --- a/arch/arm/mach-omap2/control.c
>> +++ b/arch/arm/mach-omap2/control.c
>> @@ -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 =
>> -- 
>> 1.5.4.7
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe 
>linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>-- 
>Jouni Högander
>
>

Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Kevin Hilman]

Rajendra Nayak <rnayak@ti.com> writes:

> 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 <rnayak@ti.com>

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.

>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

> ---
>  arch/arm/mach-omap2/control.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> index c9407c0..a7159a9 100644
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -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 =
> -- 
> 1.5.4.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>From: Högander Jouni [mailto:jouni.hogander@nokia.com] 
>>
>>ext Rajendra Nayak <rnayak@ti.com> writes:
>>
>>> 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.

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Derrick, David]

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:khilman@deeprootsystems.com] 
Sent: Tuesday, June 16, 2009 9:21 AM
To: Nayak, Rajendra
Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard
Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

Rajendra Nayak <rnayak@ti.com> writes:

> 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 <rnayak@ti.com>

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.

>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

> ---
>  arch/arm/mach-omap2/control.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
> index c9407c0..a7159a9 100644
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -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 =
> -- 
> 1.5.4.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kevin Hilman]

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

"Derrick, David" <dderrick@ti.com> writes:

> 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:khilman@deeprootsystems.com]
> Sent: Tuesday, June 16, 2009 9:28 AM
> To: Nayak, Rajendra
> Cc: Högander Jouni; linux-omap@vger.kernel.org; Derrick, David; Woodruff,
> Richard
> Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being
> enabled simultaneously
>
>  
>
> "Nayak, Rajendra" <rnayak@ti.com> writes:
>
>  
>
>>From: Högander Jouni [mailto:jouni.hogander@nokia.com]
>
>>> 
>
>>>ext Rajendra Nayak <rnayak@ti.com> writes:
>
>>> 
>
>>>> 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.
>
>  
>
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Nayak, Rajendra]

 

>-----Original Message-----
>From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>Sent: Tuesday, June 16, 2009 7:58 PM
>To: Nayak, Rajendra
>Cc: Högander Jouni; linux-omap@vger.kernel.org; Derrick, 
>David; Woodruff, Richard
>Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and 
>AUTO_OFF being enabled simultaneously
>
>"Nayak, Rajendra" <rnayak@ti.com> writes:
>
>>From: Högander Jouni [mailto:jouni.hogander@nokia.com] 
>>>
>>>ext Rajendra Nayak <rnayak@ti.com> writes:
>>>
>>>> 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.
>
>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. 

>
>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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Paul Walmsley]

Hello David,

On Tue, 16 Jun 2009, Derrick, David wrote:

> 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

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

[Derrick, David]

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:khilman@deeprootsystems.com] 
Sent: Tuesday, June 16, 2009 12:28 PM
To: Derrick, David
Cc: Nayak, Rajendra; Högander Jouni; linux-omap@vger.kernel.org; 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:

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

"Derrick, David" <dderrick@ti.com> writes:

> 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:khilman@deeprootsystems.com]
> Sent: Tuesday, June 16, 2009 9:28 AM
> To: Nayak, Rajendra
> Cc: Högander Jouni; linux-omap@vger.kernel.org; Derrick, David; Woodruff,
> Richard
> Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being
> enabled simultaneously
>
>  
>
> "Nayak, Rajendra" <rnayak@ti.com> writes:
>
>  
>
>>From: Högander Jouni [mailto:jouni.hogander@nokia.com]
>
>>> 
>
>>>ext Rajendra Nayak <rnayak@ti.com> writes:
>
>>> 
>
>>>> 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.
>
>  
>
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>>"Nayak, Rajendra" <rnayak@ti.com> writes:
>>
>>>From: Högander Jouni [mailto:jouni.hogander@nokia.com] 
>>>>
>>>>ext Rajendra Nayak <rnayak@ti.com> writes:
>>>>
>>>>> 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.
>>
>>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.
>

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kevin Hilman]

Rajendra Nayak <rnayak@ti.com> writes:

> 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 <rnayak@ti.com>

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

Kevin

> ---
>  arch/arm/mach-omap2/pm34xx.c |   16 ++++++++--------
>  1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index d4225b4..c2d8b09 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -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)
> -- 
> 1.5.4.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kevin Hilman]

Rajendra Nayak <rnayak@ti.com> writes:

> 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 <rnayak@ti.com>

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

Kevin

> ---
>  arch/arm/configs/omap_3430sdp_pm_defconfig |    2 +-
>  arch/arm/mach-omap2/board-3430sdp.c        |   79 +++++++++++++++-------------
>  2 files changed, 44 insertions(+), 37 deletions(-)
>
> diff --git a/arch/arm/configs/omap_3430sdp_pm_defconfig b/arch/arm/configs/omap_3430sdp_pm_defconfig
> index aefdb5b..8ec604c 100644
> --- a/arch/arm/configs/omap_3430sdp_pm_defconfig
> +++ b/arch/arm/configs/omap_3430sdp_pm_defconfig
> @@ -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
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
> index 1f0aeb2..4587815 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -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,
>  };
>  
>  /*
> -- 
> 1.5.4.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html