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

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

[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

[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 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 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 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 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 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 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms

[Nayak, Rajendra]

>-----Original Message-----
>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>Sent: Wednesday, June 17, 2009 1:17 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
>
>Hi Rajendra,
>
>On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote:
>> 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.
>
>I did some measurements on RX-51 with this patch, and it seems it does
>not reduce latency, it increases it by few hundred us.
>
>Servicing an empty timer interrupt from off mode (measured from VDD1
>ramp up to start of VDD1 ramp down):
>
>with dpll4 patch : ~14100us
>without patch    : ~13600us
>
>I attached pictures of both situations.
>
>My kernel had only C7 state enabled.
>
>Have you measured the latency effects on SDP or some other board?

I haven't done the latency measurements on SDP yet, but David had done it
sometime back, using a different codebase though.

Can you explain more on how you are measuring the latency here, I am a bit
confused. This is supposed to bring down the OFF wakeup latency, the sleep latency
remains the same.

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

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

[Kalle Jokiniemi]

On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
> >-----Original Message-----
> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >Sent: Wednesday, June 17, 2009 1:17 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
> >
> >Hi Rajendra,
> >
> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote:
> >> 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.
> >
> >I did some measurements on RX-51 with this patch, and it seems it does
> >not reduce latency, it increases it by few hundred us.
> >
> >Servicing an empty timer interrupt from off mode (measured from VDD1
> >ramp up to start of VDD1 ramp down):
> >
> >with dpll4 patch : ~14100us
> >without patch    : ~13600us
> >
> >I attached pictures of both situations.
> >
> >My kernel had only C7 state enabled.
> >
> >Have you measured the latency effects on SDP or some other board?
> 
> I haven't done the latency measurements on SDP yet, but David had done it
> sometime back, using a different codebase though.

OK, I also used our internal code base. Though the PM functionality is
pretty much the same as in l-o:pm branch.

> 
> Can you explain more on how you are measuring the latency here, I am a bit
> confused. This is supposed to bring down the OFF wakeup latency, the sleep latency
> remains the same.

I'm doing a timer interrupt periodically. Servicing that timer interrupt
takes the same amount of time every time. What varies (with the patch)
is the transition times from off to active and back to off.

In the pictures the top graph shows current and bottom graph shows the
VDD1 and VDD2 voltages. I zoomed from the pictures the interval from
when VDD1 goes up, to the point when it starts to go down again.

So I measured: wakeup latency + interrupt service + sleep latency.

- Kalle

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

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

[Nayak, Rajendra]

 

>-----Original Message-----
>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>Sent: Wednesday, June 17, 2009 3:56 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
>
>On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
>> >-----Original Message-----
>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >Sent: Wednesday, June 17, 2009 1:17 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
>> >
>> >Hi Rajendra,
>> >
>> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote:
>> >> 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.
>> >
>> >I did some measurements on RX-51 with this patch, and it 
>seems it does
>> >not reduce latency, it increases it by few hundred us.
>> >
>> >Servicing an empty timer interrupt from off mode (measured from VDD1
>> >ramp up to start of VDD1 ramp down):
>> >
>> >with dpll4 patch : ~14100us
>> >without patch    : ~13600us
>> >
>> >I attached pictures of both situations.
>> >
>> >My kernel had only C7 state enabled.
>> >
>> >Have you measured the latency effects on SDP or some other board?
>> 
>> I haven't done the latency measurements on SDP yet, but 
>David had done it
>> sometime back, using a different codebase though.
>
>OK, I also used our internal code base. Though the PM functionality is
>pretty much the same as in l-o:pm branch.
>
>> 
>> Can you explain more on how you are measuring the latency 
>here, I am a bit
>> confused. This is supposed to bring down the OFF wakeup 
>latency, the sleep latency
>> remains the same.
>
>I'm doing a timer interrupt periodically. Servicing that timer 
>interrupt
>takes the same amount of time every time. What varies (with the patch)
>is the transition times from off to active and back to off.
>
>In the pictures the top graph shows current and bottom graph shows the
>VDD1 and VDD2 voltages. I zoomed from the pictures the interval from
>when VDD1 goes up, to the point when it starts to go down again.
>
>So I measured: wakeup latency + interrupt service + sleep latency.

Is the boot ROM different on the OMAP devices on nokia h/w or is it
the same as that on the SDP?

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

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

[Kalle Jokiniemi]

On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
> 
> >-----Original Message-----
> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >Sent: Wednesday, June 17, 2009 3:56 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
> >
> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
> >> >-----Original Message-----
> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >> >Sent: Wednesday, June 17, 2009 1:17 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
> >> >
> >> >Hi Rajendra,
> >> >
> >> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote:
> >> >> 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.
> >> >
> >> >I did some measurements on RX-51 with this patch, and it 
> >seems it does
> >> >not reduce latency, it increases it by few hundred us.
> >> >
> >> >Servicing an empty timer interrupt from off mode (measured from VDD1
> >> >ramp up to start of VDD1 ramp down):
> >> >
> >> >with dpll4 patch : ~14100us
> >> >without patch    : ~13600us
> >> >
> >> >I attached pictures of both situations.
> >> >
> >> >My kernel had only C7 state enabled.
> >> >
> >> >Have you measured the latency effects on SDP or some other board?
> >> 
> >> I haven't done the latency measurements on SDP yet, but 
> >David had done it
> >> sometime back, using a different codebase though.
> >
> >OK, I also used our internal code base. Though the PM functionality is
> >pretty much the same as in l-o:pm branch.
> >
> >> 
> >> Can you explain more on how you are measuring the latency 
> >here, I am a bit
> >> confused. This is supposed to bring down the OFF wakeup 
> >latency, the sleep latency
> >> remains the same.
> >
> >I'm doing a timer interrupt periodically. Servicing that timer 
> >interrupt
> >takes the same amount of time every time. What varies (with the patch)
> >is the transition times from off to active and back to off.
> >
> >In the pictures the top graph shows current and bottom graph shows the
> >VDD1 and VDD2 voltages. I zoomed from the pictures the interval from
> >when VDD1 goes up, to the point when it starts to go down again.
> >
> >So I measured: wakeup latency + interrupt service + sleep latency.
> 
> Is the boot ROM different on the OMAP devices on nokia h/w or is it
> the same as that on the SDP?

I have heard that our ROM version would be somehow older version, but I
really don't have any facts on that matter.

- Kalle

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

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

[Nayak, Rajendra]

 

>-----Original Message-----
>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>Sent: Wednesday, June 17, 2009 6:18 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
>
>On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
>> 
>> >-----Original Message-----
>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >Sent: Wednesday, June 17, 2009 3:56 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
>> >
>> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
>> >> >-----Original Message-----
>> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >> >Sent: Wednesday, June 17, 2009 1:17 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
>> >> >
>> >> >Hi Rajendra,
>> >> >
>> >> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote:
>> >> >> 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.
>> >> >
>> >> >I did some measurements on RX-51 with this patch, and it 
>> >seems it does
>> >> >not reduce latency, it increases it by few hundred us.
>> >> >
>> >> >Servicing an empty timer interrupt from off mode 
>(measured from VDD1
>> >> >ramp up to start of VDD1 ramp down):
>> >> >
>> >> >with dpll4 patch : ~14100us
>> >> >without patch    : ~13600us
>> >> >
>> >> >I attached pictures of both situations.
>> >> >
>> >> >My kernel had only C7 state enabled.
>> >> >
>> >> >Have you measured the latency effects on SDP or some other board?
>> >> 
>> >> I haven't done the latency measurements on SDP yet, but 
>> >David had done it
>> >> sometime back, using a different codebase though.
>> >
>> >OK, I also used our internal code base. Though the PM 
>functionality is
>> >pretty much the same as in l-o:pm branch.
>> >
>> >> 
>> >> Can you explain more on how you are measuring the latency 
>> >here, I am a bit
>> >> confused. This is supposed to bring down the OFF wakeup 
>> >latency, the sleep latency
>> >> remains the same.
>> >
>> >I'm doing a timer interrupt periodically. Servicing that timer 
>> >interrupt
>> >takes the same amount of time every time. What varies (with 
>the patch)
>> >is the transition times from off to active and back to off.
>> >
>> >In the pictures the top graph shows current and bottom 
>graph shows the
>> >VDD1 and VDD2 voltages. I zoomed from the pictures the interval from
>> >when VDD1 goes up, to the point when it starts to go down again.
>> >
>> >So I measured: wakeup latency + interrupt service + sleep latency.
>> 
>> Is the boot ROM different on the OMAP devices on nokia h/w or is it
>> the same as that on the SDP?
>
>I have heard that our ROM version would be somehow older version, but I
>really don't have any facts on that matter.

Oh.. it turns out that when the scratchpad save routine is called, the autoidle
for PER is not even set. Its only set some place later.
So the 20ms or so advantage was always there on l-o pm branch even without this
patch :)

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

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

[Kevin Hilman]

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

>  
>
>>-----Original Message-----
>>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>Sent: Wednesday, June 17, 2009 6:18 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
>>
>>On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
>>> 
>>> >-----Original Message-----
>>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>> >Sent: Wednesday, June 17, 2009 3:56 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
>>> >
>>> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
>>> >> >-----Original Message-----
>>> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>> >> >Sent: Wednesday, June 17, 2009 1:17 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
>>> >> >
>>> >> >Hi Rajendra,
>>> >> >
>>> >> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote:
>>> >> >> 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.
>>> >> >
>>> >> >I did some measurements on RX-51 with this patch, and it 
>>> >seems it does
>>> >> >not reduce latency, it increases it by few hundred us.
>>> >> >
>>> >> >Servicing an empty timer interrupt from off mode 
>>(measured from VDD1
>>> >> >ramp up to start of VDD1 ramp down):
>>> >> >
>>> >> >with dpll4 patch : ~14100us
>>> >> >without patch    : ~13600us
>>> >> >
>>> >> >I attached pictures of both situations.
>>> >> >
>>> >> >My kernel had only C7 state enabled.
>>> >> >
>>> >> >Have you measured the latency effects on SDP or some other board?
>>> >> 
>>> >> I haven't done the latency measurements on SDP yet, but 
>>> >David had done it
>>> >> sometime back, using a different codebase though.
>>> >
>>> >OK, I also used our internal code base. Though the PM 
>>functionality is
>>> >pretty much the same as in l-o:pm branch.
>>> >
>>> >> 
>>> >> Can you explain more on how you are measuring the latency 
>>> >here, I am a bit
>>> >> confused. This is supposed to bring down the OFF wakeup 
>>> >latency, the sleep latency
>>> >> remains the same.
>>> >
>>> >I'm doing a timer interrupt periodically. Servicing that timer 
>>> >interrupt
>>> >takes the same amount of time every time. What varies (with 
>>the patch)
>>> >is the transition times from off to active and back to off.
>>> >
>>> >In the pictures the top graph shows current and bottom 
>>graph shows the
>>> >VDD1 and VDD2 voltages. I zoomed from the pictures the interval from
>>> >when VDD1 goes up, to the point when it starts to go down again.
>>> >
>>> >So I measured: wakeup latency + interrupt service + sleep latency.
>>> 
>>> Is the boot ROM different on the OMAP devices on nokia h/w or is it
>>> the same as that on the SDP?
>>
>>I have heard that our ROM version would be somehow older version, but I
>>really don't have any facts on that matter.
>
> Oh.. it turns out that when the scratchpad save routine is called, the autoidle
> for PER is not even set. Its only set some place later.
> So the 20ms or so advantage was always there on l-o pm branch even without this
> patch :)
>

So for the benefit of the archives... 

I'm dropping this patch since the equivalent is alrady in PM branch.

Kevin

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

[Nayak, Rajendra]

>-----Original Message-----
>From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>Sent: Tuesday, June 30, 2009 12:28 AM
>To: Nayak, Rajendra
>Cc: Kalle Jokiniemi; 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
>
>"Nayak, Rajendra" <rnayak@ti.com> writes:
>
>>  
>>
>>>-----Original Message-----
>>>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>>Sent: Wednesday, June 17, 2009 6:18 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
>>>
>>>On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
>>>> 
>>>> >-----Original Message-----
>>>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>>> >Sent: Wednesday, June 17, 2009 3:56 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
>>>> >
>>>> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
>>>> >> >-----Original Message-----
>>>> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>>>> >> >Sent: Wednesday, June 17, 2009 1:17 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
>>>> >> >
>>>> >> >Hi Rajendra,
>>>> >> >
>>>> >> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote:
>>>> >> >> 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.
>>>> >> >
>>>> >> >I did some measurements on RX-51 with this patch, and it 
>>>> >seems it does
>>>> >> >not reduce latency, it increases it by few hundred us.
>>>> >> >
>>>> >> >Servicing an empty timer interrupt from off mode 
>>>(measured from VDD1
>>>> >> >ramp up to start of VDD1 ramp down):
>>>> >> >
>>>> >> >with dpll4 patch : ~14100us
>>>> >> >without patch    : ~13600us
>>>> >> >
>>>> >> >I attached pictures of both situations.
>>>> >> >
>>>> >> >My kernel had only C7 state enabled.
>>>> >> >
>>>> >> >Have you measured the latency effects on SDP or some 
>other board?
>>>> >> 
>>>> >> I haven't done the latency measurements on SDP yet, but 
>>>> >David had done it
>>>> >> sometime back, using a different codebase though.
>>>> >
>>>> >OK, I also used our internal code base. Though the PM 
>>>functionality is
>>>> >pretty much the same as in l-o:pm branch.
>>>> >
>>>> >> 
>>>> >> Can you explain more on how you are measuring the latency 
>>>> >here, I am a bit
>>>> >> confused. This is supposed to bring down the OFF wakeup 
>>>> >latency, the sleep latency
>>>> >> remains the same.
>>>> >
>>>> >I'm doing a timer interrupt periodically. Servicing that timer 
>>>> >interrupt
>>>> >takes the same amount of time every time. What varies (with 
>>>the patch)
>>>> >is the transition times from off to active and back to off.
>>>> >
>>>> >In the pictures the top graph shows current and bottom 
>>>graph shows the
>>>> >VDD1 and VDD2 voltages. I zoomed from the pictures the 
>interval from
>>>> >when VDD1 goes up, to the point when it starts to go down again.
>>>> >
>>>> >So I measured: wakeup latency + interrupt service + sleep latency.
>>>> 
>>>> Is the boot ROM different on the OMAP devices on nokia h/w or is it
>>>> the same as that on the SDP?
>>>
>>>I have heard that our ROM version would be somehow older 
>version, but I
>>>really don't have any facts on that matter.
>>
>> Oh.. it turns out that when the scratchpad save routine is 
>called, the autoidle
>> for PER is not even set. Its only set some place later.
>> So the 20ms or so advantage was always there on l-o pm 
>branch even without this
>> patch :)
>>
>
>So for the benefit of the archives... 
>
>I'm dropping this patch since the equivalent is alrady in PM branch.

Kevin,

Today the sequence is such that the PER dpll autoidle is set only after the first
scratchpad save (so this patch has no affect). Sometime in future, if with some change
in function sequencing we end up enabling the PER dpll autoidle early on, we might have 
an additional 20ms or so OFF latency without anyone really noticing.
Would'nt it be good to just have this patch to take care of any sequencing changes later?

regards,
Rajendra

>
>Kevin
>
>

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

[Kevin Hilman]

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

[...]

>>>
>>> Oh.. it turns out that when the scratchpad save routine is called,
>>> the autoidle for PER is not even set. Its only set some place
>>> later.  So the 20ms or so advantage was always there on l-o pm
>>> branch even without this patch :)
>>>
>>
>>So for the benefit of the archives... 
>>
>>I'm dropping this patch since the equivalent is alrady in PM branch.
>
> Today the sequence is such that the PER dpll autoidle is set only
> after the first scratchpad save (so this patch has no
> affect). Sometime in future, if with some change in function
> sequencing we end up enabling the PER dpll autoidle early on, we
> might have an additional 20ms or so OFF latency without anyone
> really noticing.  Would'nt it be good to just have this patch to
> take care of any sequencing changes later?

Yes, I think you're right.  This change could indeed prevent some
future problmes down the road.  I'll merge it.

Thanks,

Kevin

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

[Paul Walmsley]

On Tue, 30 Jun 2009, Nayak, Rajendra wrote:

> >-----Original Message-----
> >From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
> >Sent: Tuesday, June 30, 2009 12:28 AM
> >To: Nayak, Rajendra
> >Cc: Kalle Jokiniemi; 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
> >
> >"Nayak, Rajendra" <rnayak@ti.com> writes:
> >
> >>  
> >>
> >>>-----Original Message-----
> >>>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >>>Sent: Wednesday, June 17, 2009 6:18 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
> >>>
> >>>On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
> >>>> 
> >>>> >-----Original Message-----
> >>>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >>>> >Sent: Wednesday, June 17, 2009 3:56 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
> >>>> >
> >>>> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
> >>>> >> >-----Original Message-----
> >>>> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
> >>>> >> >Sent: Wednesday, June 17, 2009 1:17 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
> >>>> >> >
> >>>> >> >Hi Rajendra,
> >>>> >> >
> >>>> >> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote:
> >>>> >> >> 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.
> >>>> >> >
> >>>> >> >I did some measurements on RX-51 with this patch, and it 
> >>>> >seems it does
> >>>> >> >not reduce latency, it increases it by few hundred us.
> >>>> >> >
> >>>> >> >Servicing an empty timer interrupt from off mode 
> >>>(measured from VDD1
> >>>> >> >ramp up to start of VDD1 ramp down):
> >>>> >> >
> >>>> >> >with dpll4 patch : ~14100us
> >>>> >> >without patch    : ~13600us
> >>>> >> >
> >>>> >> >I attached pictures of both situations.
> >>>> >> >
> >>>> >> >My kernel had only C7 state enabled.
> >>>> >> >
> >>>> >> >Have you measured the latency effects on SDP or some 
> >other board?
> >>>> >> 
> >>>> >> I haven't done the latency measurements on SDP yet, but 
> >>>> >David had done it
> >>>> >> sometime back, using a different codebase though.
> >>>> >
> >>>> >OK, I also used our internal code base. Though the PM 
> >>>functionality is
> >>>> >pretty much the same as in l-o:pm branch.
> >>>> >
> >>>> >> 
> >>>> >> Can you explain more on how you are measuring the latency 
> >>>> >here, I am a bit
> >>>> >> confused. This is supposed to bring down the OFF wakeup 
> >>>> >latency, the sleep latency
> >>>> >> remains the same.
> >>>> >
> >>>> >I'm doing a timer interrupt periodically. Servicing that timer 
> >>>> >interrupt
> >>>> >takes the same amount of time every time. What varies (with 
> >>>the patch)
> >>>> >is the transition times from off to active and back to off.
> >>>> >
> >>>> >In the pictures the top graph shows current and bottom 
> >>>graph shows the
> >>>> >VDD1 and VDD2 voltages. I zoomed from the pictures the 
> >interval from
> >>>> >when VDD1 goes up, to the point when it starts to go down again.
> >>>> >
> >>>> >So I measured: wakeup latency + interrupt service + sleep latency.
> >>>> 
> >>>> Is the boot ROM different on the OMAP devices on nokia h/w or is it
> >>>> the same as that on the SDP?
> >>>
> >>>I have heard that our ROM version would be somehow older 
> >version, but I
> >>>really don't have any facts on that matter.
> >>
> >> Oh.. it turns out that when the scratchpad save routine is 
> >called, the autoidle
> >> for PER is not even set. Its only set some place later.
> >> So the 20ms or so advantage was always there on l-o pm 
> >branch even without this
> >> patch :)
> >>
> >
> >So for the benefit of the archives... 
> >
> >I'm dropping this patch since the equivalent is alrady in PM branch.
> 
> Kevin,
> 
> Today the sequence is such that the PER dpll autoidle is set only after the first
> scratchpad save (so this patch has no affect). Sometime in future, if with some change
> in function sequencing we end up enabling the PER dpll autoidle early on, we might have 
> an additional 20ms or so OFF latency without anyone really noticing.
> Would'nt it be good to just have this patch to take care of any sequencing changes later?

I don't think we should merge this until David can tell us more about the 
instability that is caused by this patch.



- Paul

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

[Nayak, Rajendra]

>-----Original Message-----
>From: Paul Walmsley [mailto:paul@pwsan.com] 
>Sent: Wednesday, July 01, 2009 4:02 AM
>To: Nayak, Rajendra
>Cc: Kevin Hilman; Kalle Jokiniemi; 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
>
>On Tue, 30 Jun 2009, Nayak, Rajendra wrote:
>
>> >-----Original Message-----
>> >From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>> >Sent: Tuesday, June 30, 2009 12:28 AM
>> >To: Nayak, Rajendra
>> >Cc: Kalle Jokiniemi; 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
>> >
>> >"Nayak, Rajendra" <rnayak@ti.com> writes:
>> >
>> >>  
>> >>
>> >>>-----Original Message-----
>> >>>From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >>>Sent: Wednesday, June 17, 2009 6:18 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
>> >>>
>> >>>On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote:
>> >>>> 
>> >>>> >-----Original Message-----
>> >>>> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >>>> >Sent: Wednesday, June 17, 2009 3:56 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
>> >>>> >
>> >>>> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote:
>> >>>> >> >-----Original Message-----
>> >>>> >> >From: Kalle Jokiniemi [mailto:kalle.jokiniemi@digia.com] 
>> >>>> >> >Sent: Wednesday, June 17, 2009 1:17 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
>> >>>> >> >
>> >>>> >> >Hi Rajendra,
>> >>>> >> >
>> >>>> >> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote:
>> >>>> >> >> 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.
>> >>>> >> >
>> >>>> >> >I did some measurements on RX-51 with this patch, and it 
>> >>>> >seems it does
>> >>>> >> >not reduce latency, it increases it by few hundred us.
>> >>>> >> >
>> >>>> >> >Servicing an empty timer interrupt from off mode 
>> >>>(measured from VDD1
>> >>>> >> >ramp up to start of VDD1 ramp down):
>> >>>> >> >
>> >>>> >> >with dpll4 patch : ~14100us
>> >>>> >> >without patch    : ~13600us
>> >>>> >> >
>> >>>> >> >I attached pictures of both situations.
>> >>>> >> >
>> >>>> >> >My kernel had only C7 state enabled.
>> >>>> >> >
>> >>>> >> >Have you measured the latency effects on SDP or some 
>> >other board?
>> >>>> >> 
>> >>>> >> I haven't done the latency measurements on SDP yet, but 
>> >>>> >David had done it
>> >>>> >> sometime back, using a different codebase though.
>> >>>> >
>> >>>> >OK, I also used our internal code base. Though the PM 
>> >>>functionality is
>> >>>> >pretty much the same as in l-o:pm branch.
>> >>>> >
>> >>>> >> 
>> >>>> >> Can you explain more on how you are measuring the latency 
>> >>>> >here, I am a bit
>> >>>> >> confused. This is supposed to bring down the OFF wakeup 
>> >>>> >latency, the sleep latency
>> >>>> >> remains the same.
>> >>>> >
>> >>>> >I'm doing a timer interrupt periodically. Servicing that timer 
>> >>>> >interrupt
>> >>>> >takes the same amount of time every time. What varies (with 
>> >>>the patch)
>> >>>> >is the transition times from off to active and back to off.
>> >>>> >
>> >>>> >In the pictures the top graph shows current and bottom 
>> >>>graph shows the
>> >>>> >VDD1 and VDD2 voltages. I zoomed from the pictures the 
>> >interval from
>> >>>> >when VDD1 goes up, to the point when it starts to go 
>down again.
>> >>>> >
>> >>>> >So I measured: wakeup latency + interrupt service + 
>sleep latency.
>> >>>> 
>> >>>> Is the boot ROM different on the OMAP devices on nokia 
>h/w or is it
>> >>>> the same as that on the SDP?
>> >>>
>> >>>I have heard that our ROM version would be somehow older 
>> >version, but I
>> >>>really don't have any facts on that matter.
>> >>
>> >> Oh.. it turns out that when the scratchpad save routine is 
>> >called, the autoidle
>> >> for PER is not even set. Its only set some place later.
>> >> So the 20ms or so advantage was always there on l-o pm 
>> >branch even without this
>> >> patch :)
>> >>
>> >
>> >So for the benefit of the archives... 
>> >
>> >I'm dropping this patch since the equivalent is alrady in PM branch.
>> 
>> Kevin,
>> 
>> Today the sequence is such that the PER dpll autoidle is set 
>only after the first
>> scratchpad save (so this patch has no affect). Sometime in 
>future, if with some change
>> in function sequencing we end up enabling the PER dpll 
>autoidle early on, we might have 
>> an additional 20ms or so OFF latency without anyone really noticing.
>> Would'nt it be good to just have this patch to take care of 
>any sequencing changes later?
>
>I don't think we should merge this until David can tell us 
>more about the 
>instability that is caused by this patch.

Paul,

Even without this patch we have always had PER DPLL autoidle
disabled in scratchpad in l-o base.
This patch does not have any affect today as I said and if there
were instabilities to be seen we should have already seen them.

regards,
Rajendra

>
>
>
>- Paul
>
>

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

[Woodruff, Richard]

> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Wednesday, July 01, 2009 9:19 AM

> David, did you see stability problems when using this patch on top of
> linux-omap PM branch?  Or did you see problems on some internal tree?

Issue was on one internal tree.  Tests need to be re-applied to current trees.

Regards,
Richard W.

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

[Kevin Hilman]

"Woodruff, Richard" <r-woodruff2@ti.com> writes:

>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Wednesday, July 01, 2009 9:19 AM
>
>> David, did you see stability problems when using this patch on top of
>> linux-omap PM branch?  Or did you see problems on some internal tree?
>
> Issue was on one internal tree.  Tests need to be re-applied to current trees.
>

OK, then presumably the same problems already exist in linux-omap
since we've had this feature for awhile.

I'm going to apply this patch to the PM branch.

A more detailed report of the test and the instability against the current
tree would be very helpful.

Kevin