[PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[shweta gulati]

From: Vishwanath Sripathy <vishwanath.bs@ti.com>

OMAP3430/3630 has a Silicon bug because of which SDRC is
released from IDLE even before Core DPLL has locked. This leads
to undefined behaviour of SDRC DLL. 

This patch has workaround for the same.

Description of WA for 3430:
Initialization:
	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 
	is always locked.

Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode:
1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency 
	(by changing M2 Divider value). This is increasing the period duration of 
	one L3 clock cycle.
	o	In case of CORE is at OPP3 (166MHz@1.15V):
	"	Lower the frequency to 83MHz.

	o	In case of CORE is at OPP2 (83MHz@1.05V):
	"	Keep the frequency as it is (83MHz).

2.	Increase CORE Voltage to 1.2V. This is reducing the timing duration of the
	critical path signal which will now fit to one L3 clock cycle.

3.	Enable DPLL3 Automatic mode. This will ensure proper transition to 
	RETENTION or OFF mode.

After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
1.	Disable DPLL3 Automatic mode.
2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.

Description of WA for 3630:
Initialization:
	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is always locked.

Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode:
1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency 
	(by changing M2 Divider value) and set VDD2 Voltage for OPP100. 
	This is increasing the period duration of one L3 clock cycle and reducing
	the timing duration of the critical path signal which will now fit to one 
	L3 clock cycle.
	o	In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
		"	Lower the frequency to 100MHz.
		"	Keep the voltage as it is (1.1375V).

	o	In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
		"	Keep the frequency as it is (100MHz).
		"	Increase the voltage to 1.1375V.

2.	Enable DPLL3 Automatic mode. This will ensure proper transition to 
	RETENTION or OFF mode.

After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
1.	Disable DPLL3 Automatic mode.
2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.

Also OSWR should not be attempted if DPLL3 has locked. This should be done as part of OSWR patch series.

Patch tested on 3430SDP and 3630 ZOOM3.

Signed-off-by: Vishwanath Sripathy <vishwanath.bs@ti.com> 
Signed-off-by: Shweta Gulati <shweta.gulati@ti.com> 
---


Index: linux-omap-pm/arch/arm/mach-omap2/pm.h
===================================================================
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm.h
+++ linux-omap-pm/arch/arm/mach-omap2/pm.h
@@ -60,6 +60,10 @@ struct prm_setup_vc {
 
 extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
 extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
+extern int program_vdd2_opp_3430(void);
+extern int reprogram_vdd2_opp_3430(int restore);
+extern int program_vdd2_opp_3630(void);
+extern int reprogram_vdd2_opp_3630(int restore);
 
 extern u32 wakeup_timer_seconds;
 extern struct omap_dm_timer *gptimer_wakeup;
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
===================================================================
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
@@ -56,6 +56,7 @@
 #include "sdrc.h"
 #include "omap3-opp.h"
 
+
 #ifdef CONFIG_SUSPEND
 static suspend_state_t suspend_state = PM_SUSPEND_ON;
 static inline bool is_suspending(void)
@@ -363,6 +364,8 @@ void omap_sram_idle(void)
 	u32 sdrc_pwr = 0;
 	int per_state_modified = 0;
 	unsigned int start =0, end = 0;
+	u32 fclk_status = 0;
+	int restore = 1;
 	if (!_omap_sram_idle)
 		return;
 
@@ -415,15 +418,6 @@ void omap_sram_idle(void)
 	if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
 		omap2_clkdm_deny_idle(mpu_pwrdm->pwrdm_clkdms[0]);
 
-	/*
-	 * Disable smartreflex before entering WFI.
-	 * Only needed if we are going to enter retention or off.
-	 */
-	if (mpu_next_state <= PWRDM_POWER_RET)
-		omap_smartreflex_disable(VDD1, 1);
-	if (core_next_state <= PWRDM_POWER_RET)
-		omap_smartreflex_disable(VDD2, 1);
-
 	/* CORE */
 	if (core_next_state < PWRDM_POWER_ON) {
 		omap_uart_prepare_idle(0);
@@ -447,6 +441,31 @@ void omap_sram_idle(void)
 		prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
 		omap3_enable_io_chain();
 	}
+	/*
+	 * Disable smartreflex before entering WFI.
+	 * Only needed if we are going to enter retention or off.
+	 */
+	if (mpu_next_state <= PWRDM_POWER_RET)
+		omap_smartreflex_disable(VDD1, 1);
+	if (core_next_state <= PWRDM_POWER_RET) {
+		fclk_status = cm_read_mod_reg(OMAP3430_PER_MOD, CM_FCLKEN) |
+			cm_read_mod_reg(CORE_MOD, CM_FCLKEN1) |
+			cm_read_mod_reg(CORE_MOD, OMAP3430ES2_CM_FCLKEN3) |
+			cm_read_mod_reg(OMAP3430_DSS_MOD, CM_FCLKEN) |
+			cm_read_mod_reg(OMAP3430_CAM_MOD, CM_FCLKEN) |
+			cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_FCLKEN) |
+			cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD, CM_FCLKEN);
+		if (!fclk_status) {
+			omap_smartreflex_disable(VDD2, 1);
+			if (cpu_is_omap3630())
+				program_vdd2_opp_3630();
+			else if (cpu_is_omap3430())
+				program_vdd2_opp_3430();
+			cm_rmw_mod_reg_bits(OMAP3430_AUTO_CORE_DPLL_MASK,
+					0x1, PLL_MOD, CM_AUTOIDLE);
+		}
+	}
+
 	omap3_intc_prepare_idle();
 
 	/*
@@ -488,6 +507,7 @@ void omap_sram_idle(void)
 	if (core_next_state < PWRDM_POWER_ON) {
 		core_prev_state = pwrdm_read_prev_pwrst(core_pwrdm);
 		if (core_prev_state == PWRDM_POWER_OFF) {
+			restore = 0;
 			omap3_core_restore_context();
 			omap3_prcm_restore_context();
 			omap3_sram_restore_context();
@@ -522,9 +542,18 @@ void omap_sram_idle(void)
 	 */
 	if (mpu_next_state <= PWRDM_POWER_RET)
 		omap_smartreflex_enable(VDD1);
-	if (core_next_state <= PWRDM_POWER_RET)
-		omap_smartreflex_enable(VDD2);
-
+	if (core_next_state <= PWRDM_POWER_RET) {
+		if (restore)
+			cm_rmw_mod_reg_bits(OMAP3430_AUTO_CORE_DPLL_MASK,
+					0x0, PLL_MOD, CM_AUTOIDLE);
+		if (!fclk_status) {
+			if (cpu_is_omap3630())
+				reprogram_vdd2_opp_3630(restore);
+			else if (cpu_is_omap3430())
+				reprogram_vdd2_opp_3430(restore);
+			omap_smartreflex_enable(VDD2);
+		}
+	}
 	/* PER */
 	if (per_next_state < PWRDM_POWER_ON) {
 		if (per_next_state == PWRDM_POWER_OFF) {
@@ -948,9 +977,8 @@ static void __init prcm_setup_regs(void)
 	cm_write_mod_reg(1 << OMAP3430_AUTO_MPU_DPLL_SHIFT,
 			 MPU_MOD,
 			 CM_AUTOIDLE2);
-	cm_write_mod_reg((1 << OMAP3430_AUTO_PERIPH_DPLL_SHIFT) |
-			 (1 << OMAP3430_AUTO_CORE_DPLL_SHIFT),
-			 PLL_MOD,
+	cm_write_mod_reg((1 << OMAP3430_AUTO_PERIPH_DPLL_SHIFT),
+			  PLL_MOD,
 			 CM_AUTOIDLE);
 	cm_write_mod_reg(1 << OMAP3430ES2_AUTO_PERIPH2_DPLL_SHIFT,
 			 PLL_MOD,
@@ -1124,7 +1152,6 @@ static int __init omap3_pm_init(void)
 	struct power_state *pwrst, *tmp;
 	struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm;
 	int ret;
-
 	if (!cpu_is_omap34xx())
 		return -ENODEV;
 
Index: linux-omap-pm/arch/arm/mach-omap2/resource34xx.c
===================================================================
--- linux-omap-pm.orig/arch/arm/mach-omap2/resource34xx.c
+++ linux-omap-pm/arch/arm/mach-omap2/resource34xx.c
@@ -38,6 +38,7 @@
 #warning MPU latency constraints require CONFIG_CPU_IDLE to function!
 #endif
 
+
 /**
  * init_latency - Initializes the mpu/core latency resource.
  * @resp: Latency resource to be initalized
@@ -147,6 +148,9 @@ int set_pd_latency(struct shared_resourc
 	return 0;
 }
 
+unsigned long freq = 0, min_freq;
+struct omap_opp *min_opp, *max_opp;
+
 static struct shared_resource *vdd1_resp;
 static struct shared_resource *vdd2_resp;
 static struct device dummy_mpu_dev;
@@ -154,7 +158,7 @@ static struct device dummy_dsp_dev;
 static struct device vdd2_dev;
 static int vdd1_lock;
 static int vdd2_lock;
-static struct clk *dpll1_clk, *dpll2_clk, *dpll3_clk;
+static struct clk *dpll1_clk, *dpll2_clk, *dpll3_clk, *l3_clk;
 static int curr_vdd1_opp;
 static int curr_vdd2_opp;
 static DEFINE_MUTEX(dvfs_mutex);
@@ -214,7 +218,6 @@ static int __deprecated freq_to_opp(u8 *
  */
 void init_opp(struct shared_resource *resp)
 {
-	struct clk *l3_clk;
 	int ret;
 	u8 opp_id;
 	resp->no_of_users = 0;
@@ -238,6 +241,15 @@ void init_opp(struct shared_resource *re
 		curr_vdd2_opp = opp_id;
 	}
 	resp->curr_level = opp_id;
+	if (cpu_is_omap3630()) {
+		min_opp = opp_find_freq_ceil(OPP_L3, &freq);
+		min_freq = opp_get_freq(min_opp);
+		freq = ULONG_MAX;
+		max_opp = opp_find_freq_floor(OPP_L3, &freq);
+	} else if (cpu_is_omap3430()) {
+		min_opp = opp_find_freq_ceil(OPP_L3, &freq);
+		min_freq = opp_get_freq(min_opp);
+	}
 	return;
 }
 
@@ -553,3 +565,97 @@ int validate_freq(struct shared_resource
 		return freq_to_opp(&x, OPP_DSP, target_level);
 	return 0;
 }
+
+static struct omap_opp *c_vdd2_opp;
+int program_vdd2_opp_3430()
+{
+	int ret = 0, div;
+	struct omap_opp *c_opp;
+	unsigned long vc, vt;
+
+
+	c_vdd2_opp = c_opp = opp_find_freq_exact(OPP_L3, l3_clk->rate, true);
+
+	if (opp_get_freq(c_opp) != min_freq) {
+		div = cm_read_mod_reg(CORE_MOD, CM_CLKSEL) &
+			OMAP3430_CLKSEL_L3_MASK;
+		ret = clk_set_rate(dpll3_clk, min_freq * div);
+	}
+	/* for omap3430, VDD2 should be at 1.2V */
+	vt = 1200000;
+	vc = opp_get_voltage(c_opp);
+	ret = omap_voltage_scale(VDD2, vt, vc);
+	return ret;
+}
+
+int reprogram_vdd2_opp_3430(int restore)
+{
+	int ret = 0, div;
+	unsigned long freq = 0;
+	struct omap_opp *c_opp;
+	unsigned long  vc, vt;
+	c_opp = opp_find_freq_exact(OPP_L3, l3_clk->rate, true);
+	if (restore) {
+		if (opp_get_freq(c_opp) != opp_get_freq(c_vdd2_opp)) {
+			freq = opp_get_freq(c_vdd2_opp);
+			div = cm_read_mod_reg(CORE_MOD, CM_CLKSEL) &
+				OMAP3430_CLKSEL_L3_MASK;
+			ret = clk_set_rate(dpll3_clk, freq * div);
+		}
+	}
+	vc = 1200000;
+	vt = opp_get_voltage(c_vdd2_opp);
+	ret = omap_voltage_scale(VDD2, vt, vc);
+	return ret;
+
+}
+
+
+int program_vdd2_opp_3630()
+{
+	int ret = 0, div;
+	struct omap_opp *c_opp;
+	unsigned long vc, vt;
+
+	c_vdd2_opp = c_opp = opp_find_freq_exact(OPP_L3, l3_clk->rate, true);
+
+	if (opp_get_freq(c_opp) == min_freq) {
+		vc = opp_get_voltage(c_opp);
+		vt = opp_get_voltage(max_opp);
+		ret = omap_voltage_scale(VDD2, vt, vc);
+	} else {
+		div = cm_read_mod_reg(CORE_MOD, CM_CLKSEL) &
+			OMAP3430_CLKSEL_L3_MASK;
+		ret = clk_set_rate(dpll3_clk, min_freq * div);
+	}
+
+	return ret;
+}
+
+int reprogram_vdd2_opp_3630(int restore)
+{
+	int ret = 0, div;
+	unsigned long freq = 0;
+	struct omap_opp *c_opp;
+	unsigned long  vc, vt;
+
+	c_opp = opp_find_freq_exact(OPP_L3, l3_clk->rate, true);
+
+	if (opp_get_freq(c_opp) == opp_get_freq(c_vdd2_opp)) {
+			vc = opp_get_voltage(max_opp);
+			vt = opp_get_voltage(c_vdd2_opp);
+			/* ok to scale.. */
+			ret = omap_voltage_scale(VDD2, vt, vc);
+	} else {
+		if (restore) {
+			freq = opp_get_freq(max_opp);
+			div = cm_read_mod_reg(CORE_MOD, CM_CLKSEL) &
+				OMAP3430_CLKSEL_L3_MASK;
+			ret = clk_set_rate(dpll3_clk, freq * div);
+		}
+	}
+
+	return ret;
+}
+
+
Index: linux-omap-pm/arch/arm/mach-omap2/voltage.c
===================================================================
--- linux-omap-pm.orig/arch/arm/mach-omap2/voltage.c
+++ linux-omap-pm/arch/arm/mach-omap2/voltage.c
@@ -479,7 +479,6 @@ static int vc_bypass_scale_voltage(u32 v
 			pr_warning("Unable to get voltage table for VDD%d \
 				during voltage scaling. Some really Wrong!",
 				vdd + 1);
-			return false;
 		}
 		vp_reg[vdd].vp_errorgain = volt_data.vp_errorgain <<
 			OMAP3430_ERRORGAIN_SHIFT;
@@ -584,7 +583,6 @@ static int vp_forceupdate_scale_voltage(
 			pr_warning("Unable to get voltage table for VDD%d \
 				during voltage scaling. Some really Wrong!",
 				vdd + 1);
-			return false;
 		}
 		vp_reg[vdd].vp_errorgain = (volt_data.vp_errorgain <<
 				OMAP3430_ERRORGAIN_SHIFT);

Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[Kevin Hilman]

shweta gulati <shweta.gulati@ti.com> writes:

> From: Vishwanath Sripathy <vishwanath.bs@ti.com>
>
> OMAP3430/3630 has a Silicon bug because of which SDRC is
> released from IDLE even before Core DPLL has locked. This leads
> to undefined behaviour of SDRC DLL. 
>
> This patch has workaround for the same.
>
> Description of WA for 3430:
> Initialization:
> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 
> 	is always locked.
>
> Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode:
> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency 
> 	(by changing M2 Divider value). This is increasing the period duration of 
> 	one L3 clock cycle.
> 	o	In case of CORE is at OPP3 (166MHz@1.15V):
> 	"	Lower the frequency to 83MHz.
>
> 	o	In case of CORE is at OPP2 (83MHz@1.05V):
> 	"	Keep the frequency as it is (83MHz).
>
> 2.	Increase CORE Voltage to 1.2V. This is reducing the timing duration of the
> 	critical path signal which will now fit to one L3 clock cycle.
>
> 3.	Enable DPLL3 Automatic mode. This will ensure proper transition to 
> 	RETENTION or OFF mode.
>
> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> 1.	Disable DPLL3 Automatic mode.
> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
>
> Description of WA for 3630:
> Initialization:
> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is always locked.
>
> Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode:
> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency 
> 	(by changing M2 Divider value) and set VDD2 Voltage for OPP100. 
> 	This is increasing the period duration of one L3 clock cycle and reducing
> 	the timing duration of the critical path signal which will now fit to one 
> 	L3 clock cycle.
> 	o	In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
> 		"	Lower the frequency to 100MHz.
> 		"	Keep the voltage as it is (1.1375V).
>
> 	o	In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
> 		"	Keep the frequency as it is (100MHz).
> 		"	Increase the voltage to 1.1375V.
>
> 2.	Enable DPLL3 Automatic mode. This will ensure proper transition to 
> 	RETENTION or OFF mode.
>
> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> 1.	Disable DPLL3 Automatic mode.
> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
>
> Also OSWR should not be attempted if DPLL3 has locked. This should be done as part of OSWR patch series.
>
> Patch tested on 3430SDP and 3630 ZOOM3.
>
> Signed-off-by: Vishwanath Sripathy <vishwanath.bs@ti.com> 
> Signed-off-by: Shweta Gulati <shweta.gulati@ti.com> 
> ---

This patch appears to depend on Thara's SR series.  Please state
dependencies here.


>
> Index: linux-omap-pm/arch/arm/mach-omap2/pm.h
> ===================================================================
> --- linux-omap-pm.orig/arch/arm/mach-omap2/pm.h
> +++ linux-omap-pm/arch/arm/mach-omap2/pm.h
> @@ -60,6 +60,10 @@ struct prm_setup_vc {
>  
>  extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
>  extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
> +extern int program_vdd2_opp_3430(void);
> +extern int reprogram_vdd2_opp_3430(int restore);
> +extern int program_vdd2_opp_3630(void);
> +extern int reprogram_vdd2_opp_3630(int restore);
>  
>  extern u32 wakeup_timer_seconds;
>  extern struct omap_dm_timer *gptimer_wakeup;
> Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
> ===================================================================
> --- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
> +++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
> @@ -56,6 +56,7 @@
>  #include "sdrc.h"
>  #include "omap3-opp.h"
>  
> +

stray whitespace change

>  #ifdef CONFIG_SUSPEND
>  static suspend_state_t suspend_state = PM_SUSPEND_ON;
>  static inline bool is_suspending(void)
> @@ -363,6 +364,8 @@ void omap_sram_idle(void)
>  	u32 sdrc_pwr = 0;
>  	int per_state_modified = 0;
>  	unsigned int start =0, end = 0;
> +	u32 fclk_status = 0;
> +	int restore = 1;
>  	if (!_omap_sram_idle)
>  		return;
>  
> @@ -415,15 +418,6 @@ void omap_sram_idle(void)
>  	if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
>  		omap2_clkdm_deny_idle(mpu_pwrdm->pwrdm_clkdms[0]);
>  
> -	/*
> -	 * Disable smartreflex before entering WFI.
> -	 * Only needed if we are going to enter retention or off.
> -	 */
> -	if (mpu_next_state <= PWRDM_POWER_RET)
> -		omap_smartreflex_disable(VDD1, 1);
> -	if (core_next_state <= PWRDM_POWER_RET)
> -		omap_smartreflex_disable(VDD2, 1);
> -
>  	/* CORE */
>  	if (core_next_state < PWRDM_POWER_ON) {
>  		omap_uart_prepare_idle(0);
> @@ -447,6 +441,31 @@ void omap_sram_idle(void)
>  		prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
>  		omap3_enable_io_chain();
>  	}
> +	/*
> +	 * Disable smartreflex before entering WFI.
> +	 * Only needed if we are going to enter retention or off.
> +	 */
> +	if (mpu_next_state <= PWRDM_POWER_RET)
> +		omap_smartreflex_disable(VDD1, 1);
> +	if (core_next_state <= PWRDM_POWER_RET) {
> +		fclk_status = cm_read_mod_reg(OMAP3430_PER_MOD, CM_FCLKEN) |
> +			cm_read_mod_reg(CORE_MOD, CM_FCLKEN1) |
> +			cm_read_mod_reg(CORE_MOD, OMAP3430ES2_CM_FCLKEN3) |
> +			cm_read_mod_reg(OMAP3430_DSS_MOD, CM_FCLKEN) |
> +			cm_read_mod_reg(OMAP3430_CAM_MOD, CM_FCLKEN) |
> +			cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_FCLKEN) |
> +			cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD, CM_FCLKEN);

Doing this fclk checking here has already been rejected and Tero has
solved it in a different way in the CPUidle logic.  Please see the series
beginning here: https://patchwork.kernel.org/patch/85268/

> +		if (!fclk_status) {
> +			omap_smartreflex_disable(VDD2, 1);
> +			if (cpu_is_omap3630())
> +				program_vdd2_opp_3630();
> +			else if (cpu_is_omap3430())
> +				program_vdd2_opp_3430();

Please don't use cpu_is_* checks for errata.  Use errata flags.

> +			cm_rmw_mod_reg_bits(OMAP3430_AUTO_CORE_DPLL_MASK,
> +					0x1, PLL_MOD, CM_AUTOIDLE);
> +		}
> +	}
> +

All that being said, why is the voltage level being programmed here?

It seems to me that all of this errata handling should be
self-contained in the voltage layer.

Kevin

RE: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[Sripathy, Vishwanath]

Kevin,

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Friday, May 14, 2010 11:28 PM
> To: Gulati, Shweta
> Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
> Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
> 
> shweta gulati <shweta.gulati@ti.com> writes:
> 
> > From: Vishwanath Sripathy <vishwanath.bs@ti.com>
> >
> > OMAP3430/3630 has a Silicon bug because of which SDRC is
> > released from IDLE even before Core DPLL has locked. This leads
> > to undefined behaviour of SDRC DLL.
> >
> > This patch has workaround for the same.
> >
> > Description of WA for 3430:
> > Initialization:
> > 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3
> > 	is always locked.
> >
> > Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode:
> > 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
> > 	(by changing M2 Divider value). This is increasing the period duration of
> > 	one L3 clock cycle.
> > 	o	In case of CORE is at OPP3 (166MHz@1.15V):
> > 	"	Lower the frequency to 83MHz.
> >
> > 	o	In case of CORE is at OPP2 (83MHz@1.05V):
> > 	"	Keep the frequency as it is (83MHz).
> >
> > 2.	Increase CORE Voltage to 1.2V. This is reducing the timing duration of the
> > 	critical path signal which will now fit to one L3 clock cycle.
> >
> > 3.	Enable DPLL3 Automatic mode. This will ensure proper transition to
> > 	RETENTION or OFF mode.
> >
> > After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> > 1.	Disable DPLL3 Automatic mode.
> > 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
> >
> > Description of WA for 3630:
> > Initialization:
> > 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is
> always locked.
> >
> > Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode:
> > 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
> > 	(by changing M2 Divider value) and set VDD2 Voltage for OPP100.
> > 	This is increasing the period duration of one L3 clock cycle and reducing
> > 	the timing duration of the critical path signal which will now fit to one
> > 	L3 clock cycle.
> > 	o	In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
> > 		"	Lower the frequency to 100MHz.
> > 		"	Keep the voltage as it is (1.1375V).
> >
> > 	o	In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
> > 		"	Keep the frequency as it is (100MHz).
> > 		"	Increase the voltage to 1.1375V.
> >
> > 2.	Enable DPLL3 Automatic mode. This will ensure proper transition to
> > 	RETENTION or OFF mode.
> >
> > After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> > 1.	Disable DPLL3 Automatic mode.
> > 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
> >
> > Also OSWR should not be attempted if DPLL3 has locked. This should be done as
> part of OSWR patch series.
> >
> > Patch tested on 3430SDP and 3630 ZOOM3.
> >
> > Signed-off-by: Vishwanath Sripathy <vishwanath.bs@ti.com>
> > Signed-off-by: Shweta Gulati <shweta.gulati@ti.com>
> > ---
> 
> This patch appears to depend on Thara's SR series.  Please state
> dependencies here.
OK
> 
> 
> >
> > Index: linux-omap-pm/arch/arm/mach-omap2/pm.h
> >
> =====================================================
> ==============
> > --- linux-omap-pm.orig/arch/arm/mach-omap2/pm.h
> > +++ linux-omap-pm/arch/arm/mach-omap2/pm.h
> > @@ -60,6 +60,10 @@ struct prm_setup_vc {
> >
> >  extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
> >  extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
> > +extern int program_vdd2_opp_3430(void);
> > +extern int reprogram_vdd2_opp_3430(int restore);
> > +extern int program_vdd2_opp_3630(void);
> > +extern int reprogram_vdd2_opp_3630(int restore);
> >
> >  extern u32 wakeup_timer_seconds;
> >  extern struct omap_dm_timer *gptimer_wakeup;
> > Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
> >
> =====================================================
> ==============
> > --- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
> > +++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
> > @@ -56,6 +56,7 @@
> >  #include "sdrc.h"
> >  #include "omap3-opp.h"
> >
> > +
> 
> stray whitespace change
> 
> >  #ifdef CONFIG_SUSPEND
> >  static suspend_state_t suspend_state = PM_SUSPEND_ON;
> >  static inline bool is_suspending(void)
> > @@ -363,6 +364,8 @@ void omap_sram_idle(void)
> >  	u32 sdrc_pwr = 0;
> >  	int per_state_modified = 0;
> >  	unsigned int start =0, end = 0;
> > +	u32 fclk_status = 0;
> > +	int restore = 1;
> >  	if (!_omap_sram_idle)
> >  		return;
> >
> > @@ -415,15 +418,6 @@ void omap_sram_idle(void)
> >  	if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
> >  		omap2_clkdm_deny_idle(mpu_pwrdm->pwrdm_clkdms[0]);
> >
> > -	/*
> > -	 * Disable smartreflex before entering WFI.
> > -	 * Only needed if we are going to enter retention or off.
> > -	 */
> > -	if (mpu_next_state <= PWRDM_POWER_RET)
> > -		omap_smartreflex_disable(VDD1, 1);
> > -	if (core_next_state <= PWRDM_POWER_RET)
> > -		omap_smartreflex_disable(VDD2, 1);
> > -
> >  	/* CORE */
> >  	if (core_next_state < PWRDM_POWER_ON) {
> >  		omap_uart_prepare_idle(0);
> > @@ -447,6 +441,31 @@ void omap_sram_idle(void)
> >  		prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
> >  		omap3_enable_io_chain();
> >  	}
> > +	/*
> > +	 * Disable smartreflex before entering WFI.
> > +	 * Only needed if we are going to enter retention or off.
> > +	 */
> > +	if (mpu_next_state <= PWRDM_POWER_RET)
> > +		omap_smartreflex_disable(VDD1, 1);
> > +	if (core_next_state <= PWRDM_POWER_RET) {
> > +		fclk_status = cm_read_mod_reg(OMAP3430_PER_MOD, CM_FCLKEN) |
> > +			cm_read_mod_reg(CORE_MOD, CM_FCLKEN1) |
> > +			cm_read_mod_reg(CORE_MOD, OMAP3430ES2_CM_FCLKEN3) |
> > +			cm_read_mod_reg(OMAP3430_DSS_MOD, CM_FCLKEN) |
> > +			cm_read_mod_reg(OMAP3430_CAM_MOD, CM_FCLKEN) |
> > +			cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_FCLKEN) |
> > +			cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD,
> CM_FCLKEN);
> 
> Doing this fclk checking here has already been rejected and Tero has
> solved it in a different way in the CPUidle logic.  Please see the series
> beginning here: https://patchwork.kernel.org/patch/85268/
OK, will incorporate this in next version.

> 
> > +		if (!fclk_status) {
> > +			omap_smartreflex_disable(VDD2, 1);
> > +			if (cpu_is_omap3630())
> > +				program_vdd2_opp_3630();
> > +			else if (cpu_is_omap3430())
> > +				program_vdd2_opp_3430();
> 
> Please don't use cpu_is_* checks for errata.  Use errata flags.
OK
> 
> > +			cm_rmw_mod_reg_bits(OMAP3430_AUTO_CORE_DPLL_MASK,
> > +					0x1, PLL_MOD, CM_AUTOIDLE);
> > +		}
> > +	}
> > +
> 
> All that being said, why is the voltage level being programmed here?
> 
> It seems to me that all of this errata handling should be
> self-contained in the voltage layer.
I am not sure if entire errata can be contained in voltage layer. This is because we are performing DVFS operation in CPU Idle path which involves both Frequency and Voltage scaling. So currently this has been done in resource34xx.c where DVFS is implemented. 

Vishwa
> 
> Kevin

Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[Kevin Hilman]

"Sripathy, Vishwanath" <vishwanath.bs@ti.com> writes:

>> All that being said, why is the voltage level being programmed here?
>> 
>> It seems to me that all of this errata handling should be
>> self-contained in the voltage layer.
>
> I am not sure if entire errata can be contained in voltage
> layer. This is because we are performing DVFS operation in CPU Idle
> path which involves both Frequency and Voltage scaling. So currently
> this has been done in resource34xx.c where DVFS is implemented.

What I mean is that there seems to be no good reason to be calling
these from pm34xx.c, they should be called where voltage scaling is
done.

Kevin

RE: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[Sripathy, Vishwanath]

Kevin,

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Tuesday, May 18, 2010 10:07 PM
> To: Sripathy, Vishwanath
> Cc: Gulati, Shweta; linux-omap@vger.kernel.org
> Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
> 
> "Sripathy, Vishwanath" <vishwanath.bs@ti.com> writes:
> 
> >> All that being said, why is the voltage level being programmed here?
> >>
> >> It seems to me that all of this errata handling should be
> >> self-contained in the voltage layer.
> >
> > I am not sure if entire errata can be contained in voltage
> > layer. This is because we are performing DVFS operation in CPU Idle
> > path which involves both Frequency and Voltage scaling. So currently
> > this has been done in resource34xx.c where DVFS is implemented.
> 
> What I mean is that there seems to be no good reason to be calling
> these from pm34xx.c, they should be called where voltage scaling is
> done.
Sorry I still do not understand how errata can be invoked from Voltage scaling. Pls note that errata has to be applied only when Core is entering retention or off which can be detected only in omap_sram_idle function. Errata is tightly coupled with CPU idle path. 

Vishwa
> 
> Kevin

Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[Benoit Cousson]

Hi Vishwa,

On 5/13/2010 12:12 PM, shweta gulati wrote:
> From: Vishwanath Sripathy<vishwanath.bs@ti.com>
>
> OMAP3430/3630 has a Silicon bug because of which SDRC is
> released from IDLE even before Core DPLL has locked. This leads
> to undefined behaviour of SDRC DLL.
>
> This patch has workaround for the same.
>
> Description of WA for 3430:
> Initialization:
> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3
> 	is always locked.
>
> Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode:
> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
> 	(by changing M2 Divider value). This is increasing the period duration of
> 	one L3 clock cycle.
> 	o	In case of CORE is at OPP3 (166MHz@1.15V):
> 	"	Lower the frequency to 83MHz.
>
> 	o	In case of CORE is at OPP2 (83MHz@1.05V):
> 	"	Keep the frequency as it is (83MHz).
>
> 2.	Increase CORE Voltage to 1.2V. This is reducing the timing duration of the
> 	critical path signal which will now fit to one L3 clock cycle.
>
> 3.	Enable DPLL3 Automatic mode. This will ensure proper transition to
> 	RETENTION or OFF mode.
>
> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> 1.	Disable DPLL3 Automatic mode.
> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
>
> Description of WA for 3630:
> Initialization:
> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is always locked.
>
> Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode:
> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
> 	(by changing M2 Divider value) and set VDD2 Voltage for OPP100.
> 	This is increasing the period duration of one L3 clock cycle and reducing
> 	the timing duration of the critical path signal which will now fit to one
> 	L3 clock cycle.
> 	o	In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
> 		"	Lower the frequency to 100MHz.
> 		"	Keep the voltage as it is (1.1375V).
>
> 	o	In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
> 		"	Keep the frequency as it is (100MHz).
> 		"	Increase the voltage to 1.1375V.
>
> 2.	Enable DPLL3 Automatic mode. This will ensure proper transition to
> 	RETENTION or OFF mode.
>
> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> 1.	Disable DPLL3 Automatic mode.
> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
>
> Also OSWR should not be attempted if DPLL3 has locked. This should be done as part of OSWR patch series.
>
> Patch tested on 3430SDP and 3630 ZOOM3.
>

Do you have a more accurate description of the bug? What is the defect ID?

The subject is about DPLL3 lock issue, and the description is all about 
the transition to CORE RET or OFF and playing with voltage... and why 
OSWR is affected as well?
I'm a little bit confused by that...

Is this bug dependent of the target power state? What about INACTIVE?

Why setting the CORE at 1.2v when the description is only considering 
1.1375v?

Thanks,
Benoit

RE: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[Sripathy, Vishwanath]

Hi Benoit,

> -----Original Message-----
> From: Cousson, Benoit
> Sent: Wednesday, May 19, 2010 5:28 PM
> To: Gulati, Shweta
> Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
> Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
> 
> Hi Vishwa,
> 
> On 5/13/2010 12:12 PM, shweta gulati wrote:
> > From: Vishwanath Sripathy<vishwanath.bs@ti.com>
> >
> > OMAP3430/3630 has a Silicon bug because of which SDRC is
> > released from IDLE even before Core DPLL has locked. This leads
> > to undefined behaviour of SDRC DLL.
> >
> > This patch has workaround for the same.
> >
> > Description of WA for 3430:
> > Initialization:
> > 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3
> > 	is always locked.
> >
> > Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode:
> > 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
> > 	(by changing M2 Divider value). This is increasing the period duration of
> > 	one L3 clock cycle.
> > 	o	In case of CORE is at OPP3 (166MHz@1.15V):
> > 	"	Lower the frequency to 83MHz.
> >
> > 	o	In case of CORE is at OPP2 (83MHz@1.05V):
> > 	"	Keep the frequency as it is (83MHz).
> >
> > 2.	Increase CORE Voltage to 1.2V. This is reducing the timing duration of the
> > 	critical path signal which will now fit to one L3 clock cycle.
> >
> > 3.	Enable DPLL3 Automatic mode. This will ensure proper transition to
> > 	RETENTION or OFF mode.
> >
> > After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> > 1.	Disable DPLL3 Automatic mode.
> > 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
> >
> > Description of WA for 3630:
> > Initialization:
> > 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is
> always locked.
> >
> > Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode:
> > 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
> > 	(by changing M2 Divider value) and set VDD2 Voltage for OPP100.
> > 	This is increasing the period duration of one L3 clock cycle and reducing
> > 	the timing duration of the critical path signal which will now fit to one
> > 	L3 clock cycle.
> > 	o	In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
> > 		"	Lower the frequency to 100MHz.
> > 		"	Keep the voltage as it is (1.1375V).
> >
> > 	o	In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
> > 		"	Keep the frequency as it is (100MHz).
> > 		"	Increase the voltage to 1.1375V.
> >
> > 2.	Enable DPLL3 Automatic mode. This will ensure proper transition to
> > 	RETENTION or OFF mode.
> >
> > After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> > 1.	Disable DPLL3 Automatic mode.
> > 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
> >
> > Also OSWR should not be attempted if DPLL3 has locked. This should be done as
> part of OSWR patch series.
> >
> > Patch tested on 3430SDP and 3630 ZOOM3.
> >
> 
> Do you have a more accurate description of the bug? What is the defect ID?
> 
Defect Id is i581. 
> The subject is about DPLL3 lock issue, and the description is all about
> the transition to CORE RET or OFF and playing with voltage... and why
> OSWR is affected as well?
> I'm a little bit confused by that...
> 
> Is this bug dependent of the target power state? What about INACTIVE?
The root cause of the issue is that SDRC IDLEREQ is deasserted before DPLL3 has locked. Because of this DLL may/may not lock based on Process Voltage Temperature conditions. The bug can occur when DPLL3 automatic transition is enabled. So DPLL3 automatic transition is disabled by default and it is enabled only when system is entering ret/off state (to facilitate voltage scaling). So when system is entering ret/off state, WA is applied (since DPLL3 autoidle is enabled, we can possibly hit the issue; hence the WA)

Regarding OSWR, as per errata i580, DPLL3 cannot be kept Locked when CORE is in OSWR state if DPLL3 is set in Manual Lock mode. So if DPLL3 autoidle is not enabled (manual lock mode), then we should not attempt to goto Core OSWR. 

> 
> Why setting the CORE at 1.2v when the description is only considering
> 1.1375v?
> 
For OMAP3430, as per errata VDD2 should be set to 1.2V before attempting off/retention. 1.1375V applies for OMAP3630.

Regards
Vishwa
> Thanks,
> Benoit

Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[Benoit Cousson]

On 5/19/2010 3:50 PM, Sripathy, Vishwanath wrote:
> Hi Benoit,
>
>> -----Original Message-----
>> From: Cousson, Benoit
>> Sent: Wednesday, May 19, 2010 5:28 PM
>> To: Gulati, Shweta
>> Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
>> Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
>>
>> Hi Vishwa,
>>
>> On 5/13/2010 12:12 PM, shweta gulati wrote:
>>> From: Vishwanath Sripathy<vishwanath.bs@ti.com>
>>>
>>> OMAP3430/3630 has a Silicon bug because of which SDRC is
>>> released from IDLE even before Core DPLL has locked. This leads
>>> to undefined behaviour of SDRC DLL.
>>>
>>> This patch has workaround for the same.
>>>
>>> Description of WA for 3430:
>>> Initialization:
>>> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3
>>> 	is always locked.
>>>
>>> Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF mode:
>>> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
>>> 	(by changing M2 Divider value). This is increasing the period duration of
>>> 	one L3 clock cycle.
>>> 	o	In case of CORE is at OPP3 (166MHz@1.15V):
>>> 	"	Lower the frequency to 83MHz.
>>>
>>> 	o	In case of CORE is at OPP2 (83MHz@1.05V):
>>> 	"	Keep the frequency as it is (83MHz).
>>>
>>> 2.	Increase CORE Voltage to 1.2V. This is reducing the timing duration of the
>>> 	critical path signal which will now fit to one L3 clock cycle.
>>>
>>> 3.	Enable DPLL3 Automatic mode. This will ensure proper transition to
>>> 	RETENTION or OFF mode.
>>>
>>> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
>>> 1.	Disable DPLL3 Automatic mode.
>>> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
>>>
>>> Description of WA for 3630:
>>> Initialization:
>>> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is
>> always locked.
>>>
>>> Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF mode:
>>> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
>>> 	(by changing M2 Divider value) and set VDD2 Voltage for OPP100.
>>> 	This is increasing the period duration of one L3 clock cycle and reducing
>>> 	the timing duration of the critical path signal which will now fit to one
>>> 	L3 clock cycle.
>>> 	o	In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
>>> 		"	Lower the frequency to 100MHz.
>>> 		"	Keep the voltage as it is (1.1375V).
>>>
>>> 	o	In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
>>> 		"	Keep the frequency as it is (100MHz).
>>> 		"	Increase the voltage to 1.1375V.
>>>
>>> 2.	Enable DPLL3 Automatic mode. This will ensure proper transition to
>>> 	RETENTION or OFF mode.
>>>
>>> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
>>> 1.	Disable DPLL3 Automatic mode.
>>> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
>>>
>>> Also OSWR should not be attempted if DPLL3 has locked. This should be done as
>> part of OSWR patch series.
>>>
>>> Patch tested on 3430SDP and 3630 ZOOM3.
>>>
>>
>> Do you have a more accurate description of the bug? What is the defect ID?
>>
> Defect Id is i581.
>> The subject is about DPLL3 lock issue, and the description is all about
>> the transition to CORE RET or OFF and playing with voltage... and why
>> OSWR is affected as well?
>> I'm a little bit confused by that...
>>
>> Is this bug dependent of the target power state? What about INACTIVE?
> The root cause of the issue is that SDRC IDLEREQ is deasserted before DPLL3 has locked. Because of this DLL may/may not lock based on Process Voltage Temperature conditions. The bug can occur when DPLL3 automatic transition is enabled. So DPLL3 automatic transition is disabled by default and it is enabled only when system is entering ret/off state (to facilitate voltage scaling). So when system is entering ret/off state, WA is applied (since DPLL3 autoidle is enabled, we can possibly hit the issue; hence the WA)

Thanks, but that still not explain why this WA is considered only for 
device transition to RET or OFF. The DPLL3 can got to idle as soon as 
the CORE is INACTIVE. How this case is handled?
Why is it depend of the voltage?
Am I missing something?

After checking the errata, it looks like there is no further explanation 
than this one: "These cases cannot be executed if only Power Domain 
transition is targeted."... which does not explain anything:-(

I'll check that with Hayati.

> Regarding OSWR, as per errata i580, DPLL3 cannot be kept Locked when CORE is in OSWR state if DPLL3 is set in Manual Lock mode. So if DPLL3 autoidle is not enabled (manual lock mode), then we should not attempt to goto Core OSWR.

>> Why setting the CORE at 1.2v when the description is only considering
>> 1.1375v?
>>
> For OMAP3430, as per errata VDD2 should be set to 1.2V before attempting off/retention. 1.1375V applies for OMAP3630.

Oops, I missed the 3430 vs 3630 different paragraphs, you should maybe 
improve the readability of the description... or maybe it is just me:-)


Thanks,
Benoit

RE: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[Sripathy, Vishwanath]

Hi Benoit,

> -----Original Message-----
> From: Cousson, Benoit
> Sent: Wednesday, May 19, 2010 8:00 PM
> To: Sripathy, Vishwanath
> Cc: Gulati, Shweta; linux-omap@vger.kernel.org
> Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
> 
> On 5/19/2010 3:50 PM, Sripathy, Vishwanath wrote:
> > Hi Benoit,
> >
> >> -----Original Message-----
> >> From: Cousson, Benoit
> >> Sent: Wednesday, May 19, 2010 5:28 PM
> >> To: Gulati, Shweta
> >> Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
> >> Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
> >>
> >> Hi Vishwa,
> >>
> >> On 5/13/2010 12:12 PM, shweta gulati wrote:
> >>> From: Vishwanath Sripathy<vishwanath.bs@ti.com>
> >>>
> >>> OMAP3430/3630 has a Silicon bug because of which SDRC is
> >>> released from IDLE even before Core DPLL has locked. This leads
> >>> to undefined behaviour of SDRC DLL.
> >>>
> >>> This patch has workaround for the same.
> >>>
> >>> Description of WA for 3430:
> >>> Initialization:
> >>> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3
> >>> 	is always locked.
> >>>
> >>> Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF
> mode:
> >>> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
> >>> 	(by changing M2 Divider value). This is increasing the period duration of
> >>> 	one L3 clock cycle.
> >>> 	o	In case of CORE is at OPP3 (166MHz@1.15V):
> >>> 	"	Lower the frequency to 83MHz.
> >>>
> >>> 	o	In case of CORE is at OPP2 (83MHz@1.05V):
> >>> 	"	Keep the frequency as it is (83MHz).
> >>>
> >>> 2.	Increase CORE Voltage to 1.2V. This is reducing the timing duration of
> the
> >>> 	critical path signal which will now fit to one L3 clock cycle.
> >>>
> >>> 3.	Enable DPLL3 Automatic mode. This will ensure proper transition to
> >>> 	RETENTION or OFF mode.
> >>>
> >>> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> >>> 1.	Disable DPLL3 Automatic mode.
> >>> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
> >>>
> >>> Description of WA for 3630:
> >>> Initialization:
> >>> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is
> >> always locked.
> >>>
> >>> Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF
> mode:
> >>> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
> >>> 	(by changing M2 Divider value) and set VDD2 Voltage for OPP100.
> >>> 	This is increasing the period duration of one L3 clock cycle and reducing
> >>> 	the timing duration of the critical path signal which will now fit to one
> >>> 	L3 clock cycle.
> >>> 	o	In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
> >>> 		"	Lower the frequency to 100MHz.
> >>> 		"	Keep the voltage as it is (1.1375V).
> >>>
> >>> 	o	In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
> >>> 		"	Keep the frequency as it is (100MHz).
> >>> 		"	Increase the voltage to 1.1375V.
> >>>
> >>> 2.	Enable DPLL3 Automatic mode. This will ensure proper transition to
> >>> 	RETENTION or OFF mode.
> >>>
> >>> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> >>> 1.	Disable DPLL3 Automatic mode.
> >>> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
> >>>
> >>> Also OSWR should not be attempted if DPLL3 has locked. This should be done as
> >> part of OSWR patch series.
> >>>
> >>> Patch tested on 3430SDP and 3630 ZOOM3.
> >>>
> >>
> >> Do you have a more accurate description of the bug? What is the defect ID?
> >>
> > Defect Id is i581.
> >> The subject is about DPLL3 lock issue, and the description is all about
> >> the transition to CORE RET or OFF and playing with voltage... and why
> >> OSWR is affected as well?
> >> I'm a little bit confused by that...
> >>
> >> Is this bug dependent of the target power state? What about INACTIVE?
> > The root cause of the issue is that SDRC IDLEREQ is deasserted before DPLL3 has
> locked. Because of this DLL may/may not lock based on Process Voltage Temperature
> conditions. The bug can occur when DPLL3 automatic transition is enabled. So DPLL3
> automatic transition is disabled by default and it is enabled only when system is
> entering ret/off state (to facilitate voltage scaling). So when system is entering ret/off
> state, WA is applied (since DPLL3 autoidle is enabled, we can possibly hit the issue;
> hence the WA)
> 
> Thanks, but that still not explain why this WA is considered only for
> device transition to RET or OFF. The DPLL3 can got to idle as soon as
> the CORE is INACTIVE. How this case is handled?
DPLL3 auto idle is disabled when Core is in ON or INACTIVE state. So DPLL3 cannot goto idle state. We enable DPPL3 auto idle only when Core is about to enter RET or OFF state (otherwise VDD2 will not be able to scale the voltage down). 
> Why is it depend of the voltage?
> Am I missing something?
> 
> After checking the errata, it looks like there is no further explanation
> than this one: "These cases cannot be executed if only Power Domain
> transition is targeted."... which does not explain anything:-(
> 
> I'll check that with Hayati.
Apparently by increasing the voltage, it is reducing the timing duration of the critical path signal which will now fit to one L3 clock cycle. Hayati should be able to give better explanation.

Vishwa
.
> 
> > Regarding OSWR, as per errata i580, DPLL3 cannot be kept Locked when CORE is in
> OSWR state if DPLL3 is set in Manual Lock mode. So if DPLL3 autoidle is not enabled
> (manual lock mode), then we should not attempt to goto Core OSWR.
> 
> >> Why setting the CORE at 1.2v when the description is only considering
> >> 1.1375v?
> >>
> > For OMAP3430, as per errata VDD2 should be set to 1.2V before attempting
> off/retention. 1.1375V applies for OMAP3630.
> 
> Oops, I missed the 3430 vs 3630 different paragraphs, you should maybe
> improve the readability of the description... or maybe it is just me:-)
> 
> 
> Thanks,
> Benoit

Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[Benoit Cousson]

On 5/19/2010 4:37 PM, Sripathy, Vishwanath wrote:
> Hi Benoit,
>
>> -----Original Message-----
>> From: Cousson, Benoit
>> Sent: Wednesday, May 19, 2010 8:00 PM
>> To: Sripathy, Vishwanath
>> Cc: Gulati, Shweta; linux-omap@vger.kernel.org
>> Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
>>
>> On 5/19/2010 3:50 PM, Sripathy, Vishwanath wrote:
>>> Hi Benoit,
>>>
>>>> -----Original Message-----
>>>> From: Cousson, Benoit
>>>> Sent: Wednesday, May 19, 2010 5:28 PM
>>>> To: Gulati, Shweta
>>>> Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
>>>> Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
>>>>
>>>> Hi Vishwa,
>>>>
>>>> On 5/13/2010 12:12 PM, shweta gulati wrote:
>>>>> From: Vishwanath Sripathy<vishwanath.bs@ti.com>
>>>>>
>>>>> OMAP3430/3630 has a Silicon bug because of which SDRC is
>>>>> released from IDLE even before Core DPLL has locked. This leads
>>>>> to undefined behaviour of SDRC DLL.
>>>>>
>>>>> This patch has workaround for the same.
>>>>>
>>>>> Description of WA for 3430:
>>>>> Initialization:
>>>>> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3
>>>>> 	is always locked.
>>>>>
>>>>> Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF
>> mode:
>>>>> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
>>>>> 	(by changing M2 Divider value). This is increasing the period duration of
>>>>> 	one L3 clock cycle.
>>>>> 	o	In case of CORE is at OPP3 (166MHz@1.15V):
>>>>> 	"	Lower the frequency to 83MHz.
>>>>>
>>>>> 	o	In case of CORE is at OPP2 (83MHz@1.05V):
>>>>> 	"	Keep the frequency as it is (83MHz).
>>>>>
>>>>> 2.	Increase CORE Voltage to 1.2V. This is reducing the timing duration of
>> the
>>>>> 	critical path signal which will now fit to one L3 clock cycle.
>>>>>
>>>>> 3.	Enable DPLL3 Automatic mode. This will ensure proper transition to
>>>>> 	RETENTION or OFF mode.
>>>>>
>>>>> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
>>>>> 1.	Disable DPLL3 Automatic mode.
>>>>> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
>>>>>
>>>>> Description of WA for 3630:
>>>>> Initialization:
>>>>> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is
>>>> always locked.
>>>>>
>>>>> Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF
>> mode:
>>>>> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
>>>>> 	(by changing M2 Divider value) and set VDD2 Voltage for OPP100.
>>>>> 	This is increasing the period duration of one L3 clock cycle and reducing
>>>>> 	the timing duration of the critical path signal which will now fit to one
>>>>> 	L3 clock cycle.
>>>>> 	o	In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
>>>>> 		"	Lower the frequency to 100MHz.
>>>>> 		"	Keep the voltage as it is (1.1375V).
>>>>>
>>>>> 	o	In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
>>>>> 		"	Keep the frequency as it is (100MHz).
>>>>> 		"	Increase the voltage to 1.1375V.
>>>>>
>>>>> 2.	Enable DPLL3 Automatic mode. This will ensure proper transition to
>>>>> 	RETENTION or OFF mode.
>>>>>
>>>>> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
>>>>> 1.	Disable DPLL3 Automatic mode.
>>>>> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
>>>>>
>>>>> Also OSWR should not be attempted if DPLL3 has locked. This should be done as
>>>> part of OSWR patch series.
>>>>>
>>>>> Patch tested on 3430SDP and 3630 ZOOM3.
>>>>>
>>>>
>>>> Do you have a more accurate description of the bug? What is the defect ID?
>>>>
>>> Defect Id is i581.
>>>> The subject is about DPLL3 lock issue, and the description is all about
>>>> the transition to CORE RET or OFF and playing with voltage... and why
>>>> OSWR is affected as well?
>>>> I'm a little bit confused by that...
>>>>
>>>> Is this bug dependent of the target power state? What about INACTIVE?
>>> The root cause of the issue is that SDRC IDLEREQ is deasserted before DPLL3 has
>> locked. Because of this DLL may/may not lock based on Process Voltage Temperature
>> conditions. The bug can occur when DPLL3 automatic transition is enabled. So DPLL3
>> automatic transition is disabled by default and it is enabled only when system is
>> entering ret/off state (to facilitate voltage scaling). So when system is entering ret/off
>> state, WA is applied (since DPLL3 autoidle is enabled, we can possibly hit the issue;
>> hence the WA)
>>
>> Thanks, but that still not explain why this WA is considered only for
>> device transition to RET or OFF. The DPLL3 can got to idle as soon as
>> the CORE is INACTIVE. How this case is handled?
> DPLL3 auto idle is disabled when Core is in ON or INACTIVE state. So DPLL3 cannot goto idle state. We enable DPPL3 auto idle only when Core is about to enter RET or OFF state (otherwise VDD2 will not be able to scale the voltage down).

Why did you prevent that mode for INACTIVE? If I remember well, during 
the early measurement we did on 3430, the DPLL consumption in locked 
mode is around 5mw, so you can save a good amount of power for very low 
load use cases.

Did you try to enable that in CPUIdle to check the power saving you can 
achieve with that mode?

Benoit

RE: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue

[Girish S G]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Benoit
> Cousson

> >>>> Hi Vishwa,
> >>>>
> >>>> On 5/13/2010 12:12 PM, shweta gulati wrote:
> >>>>> From: Vishwanath Sripathy<vishwanath.bs@ti.com>
> >>>>>
> >>>>> OMAP3430/3630 has a Silicon bug because of which SDRC is
> >>>>> released from IDLE even before Core DPLL has locked. This leads
> >>>>> to undefined behaviour of SDRC DLL.
> >>>>>
> >>>>> This patch has workaround for the same.
> >>>>>
> >>>>> Description of WA for 3430:
> >>>>> Initialization:
> >>>>> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3
> >>>>> 	is always locked.
> >>>>>
> >>>>> Before CORE Voltage Domain (VDD2) Sleep Transition to RETENTION or OFF
> >> mode:
> >>>>> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP2 Frequency
> >>>>> 	(by changing M2 Divider value). This is increasing the period duration of
> >>>>> 	one L3 clock cycle.
> >>>>> 	o	In case of CORE is at OPP3 (166MHz@1.15V):
> >>>>> 	"	Lower the frequency to 83MHz.
> >>>>>
> >>>>> 	o	In case of CORE is at OPP2 (83MHz@1.05V):
> >>>>> 	"	Keep the frequency as it is (83MHz).
> >>>>>
> >>>>> 2.	Increase CORE Voltage to 1.2V. This is reducing the timing duration of
> >> the
> >>>>> 	critical path signal which will now fit to one L3 clock cycle.
> >>>>>
> >>>>> 3.	Enable DPLL3 Automatic mode. This will ensure proper transition to
> >>>>> 	RETENTION or OFF mode.
> >>>>>
> >>>>> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> >>>>> 1.	Disable DPLL3 Automatic mode.
> >>>>> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
> >>>>>
> >>>>> Description of WA for 3630:
> >>>>> Initialization:
> >>>>> 	Disable DPLL3 automatic mode by default. Issue will not be faced as DPLL3 is
> >>>> always locked.
> >>>>>
> >>>>> Before CORE Voltage Domain(VDD2) Sleep Transition to RETENTION or OFF
> >> mode:
> >>>>> 1.	Reduce DPLL3 M2 Frequency to get L3 running at OPP50 Frequency
> >>>>> 	(by changing M2 Divider value) and set VDD2 Voltage for OPP100.
> >>>>> 	This is increasing the period duration of one L3 clock cycle and reducing
> >>>>> 	the timing duration of the critical path signal which will now fit to one
> >>>>> 	L3 clock cycle.
> >>>>> 	o	In case of CORE is at OPP100 (L3=200MHz, VDD2=1.1375V):
> >>>>> 		"	Lower the frequency to 100MHz.
> >>>>> 		"	Keep the voltage as it is (1.1375V).
> >>>>>
> >>>>> 	o	In case of CORE is at OPP50 (L3=100MHz, VDD2=0.93V):
> >>>>> 		"	Keep the frequency as it is (100MHz).
> >>>>> 		"	Increase the voltage to 1.1375V.
> >>>>>
> >>>>> 2.	Enable DPLL3 Automatic mode. This will ensure proper transition to
> >>>>> 	RETENTION or OFF mode.
> >>>>>
> >>>>> After CORE Voltage Domain Wakeup Transition from RETENTION or OFF mode:
> >>>>> 1.	Disable DPLL3 Automatic mode.
> >>>>> 2.	Restore previous DPLL3 M2 Frequency and CORE Voltage values.
> >>>>>
> >>>>> Also OSWR should not be attempted if DPLL3 has locked. This should be done as
> >>>> part of OSWR patch series.
> >>>>>
> >>>>> Patch tested on 3430SDP and 3630 ZOOM3.
> >>>>>
> >>>>
> >>>> Do you have a more accurate description of the bug? What is the defect ID?
> >>>>
> >>> Defect Id is i581.
> >>>> The subject is about DPLL3 lock issue, and the description is all about
> >>>> the transition to CORE RET or OFF and playing with voltage... and why
> >>>> OSWR is affected as well?
> >>>> I'm a little bit confused by that...
> >>>>
> >>>> Is this bug dependent of the target power state? What about INACTIVE?
> >>> The root cause of the issue is that SDRC IDLEREQ is deasserted before DPLL3 has
> >> locked. Because of this DLL may/may not lock based on Process Voltage Temperature
> >> conditions. The bug can occur when DPLL3 automatic transition is enabled. So DPLL3
> >> automatic transition is disabled by default and it is enabled only when system is
> >> entering ret/off state (to facilitate voltage scaling). So when system is entering ret/off
> >> state, WA is applied (since DPLL3 autoidle is enabled, we can possibly hit the issue;
> >> hence the WA)
> >>
> >> Thanks, but that still not explain why this WA is considered only for
> >> device transition to RET or OFF. The DPLL3 can got to idle as soon as
> >> the CORE is INACTIVE. How this case is handled?
> > DPLL3 auto idle is disabled when Core is in ON or INACTIVE state. So DPLL3 cannot goto idle state.
> We enable DPPL3 auto idle only when Core is about to enter RET or OFF state (otherwise VDD2 will not
> be able to scale the voltage down).
> 
> Why did you prevent that mode for INACTIVE? If I remember well, during
> the early measurement we did on 3430, the DPLL consumption in locked
> mode is around 5mw, so you can save a good amount of power for very low
> load use cases.
> 
> Did you try to enable that in CPUIdle to check the power saving you can
> achieve with that mode?

I partially agree here, definitely there will be savings of the order ~5mW if DPLL3 is idled in CORE INA state. However, if this
done then WA will be applied in all these states increasing the latency(there will be case were l3 is held high by some usecase
whilst this c-state is hit; then 200->100->200 MHz transition might cause some latency and eventually hampering the functionality of
the usecase). 

-Girish

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