Re: cpuidle and SW sleep
On Wed, Oct 15, 2014 at 10:25 AM, Ran Shalit ransha...@gmail.com wrote: Hello, Is there anyone who can please explain the relation between SW sleep (such as udelay), to change of C-state as done by cpuidle ? These are two different things, Ran. udelay is a way to put simple delay between two functions. The cpu will continue to perform other operations in a multithreded platform. CPUIdle sleep states are mainly to achieve power saving by programming cpus to difference states depending on how much time (estimated) a cpu is going to be idle with algorithm. So each state will have latency associated with it - enter, exit latency. If the cpu idle time falls within any of C-state's latency that will be programmed. In different state cpu will be programmed with different modes to achieve diff power saving. How is wakeup done ? As far as I understand udelay is sw delay not HW. System Wake up can be achieved by programming a wakeup source such as keypad. Thanks for you comments, Ran -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks and Regards Pramod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS
From: Pramod Gurav pramod.gu...@ti.com The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. By using the dynamic method the dependency on the type of cache being used is removed. Formula to calculate the DVFS latency for 3430 and 3630 are different. The second patch implements the formula for later. This Version of patches adds optimisation to the formula implementation. Teerth Reddy (1): OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS Pramod Gurav (1): OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630 arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 71 +++- arch/arm/mach-omap2/clock34xx.h|2 + arch/arm/mach-omap2/clock3xxx.c|2 +- arch/arm/mach-omap2/clock3xxx.h|1 + arch/arm/mach-omap2/clock3xxx_data.c | 13 ++ arch/arm/mach-omap2/sram34xx.S |8 arch/arm/plat-omap/include/plat/sram.h |4 ++ arch/arm/plat-omap/sram.c | 51 +++ 8 files changed, 140 insertions(+), 12 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS
From: Teerth Reddy tee...@ti.com
The patch has the changes to calculate the dpll3 clock stabilization
delay dynamically. The SRAM delay is calibrated during bootup using the
gptimers and used while calculating the stabilization delay. By using
the dynamic method the dependency on the type of cache being used is
removed. Hence there is no need of loop based calculation.
The wait time for L3 clock stabilization is calculated using the formula
= 4*REFCLK + 8*CLKOUTX2,
which uses the M, N and M2 read from the registers.
Since this gives slightly less value, 2us is added as buffer for safety.
This works fine for omap3.
Signed-off-by: Teerth Reddy tee...@ti.com
Signed-off-by: Romit Dasgupta ro...@ti.com
Signed-off-by: Pramod Gurav pramod.gu...@ti.com
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Ambresh K ambr...@ti.com
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 56 +--
arch/arm/mach-omap2/clock34xx.h|2 +
arch/arm/mach-omap2/clock3xxx.c|2 +-
arch/arm/mach-omap2/clock3xxx.h|1 +
arch/arm/mach-omap2/clock3xxx_data.c | 13 +++
arch/arm/mach-omap2/sram34xx.S |8
arch/arm/plat-omap/include/plat/sram.h |4 ++
arch/arm/plat-omap/sram.c | 51 +
8 files changed, 125 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index b2b1e37..6ad18f2 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -24,13 +24,22 @@
#include plat/clock.h
#include plat/sram.h
#include plat/sdrc.h
+#include plat/prcm.h
#include clock.h
#include clock3xxx.h
#include clock34xx.h
#include sdrc.h
-#define CYCLES_PER_MHZ 100
+#defineCYCLES_PER_MHZ 100
+
+#defineDPLL_M_MASK 0x7ff
+#defineDPLL_N_MASK 0x7f
+#defineDPLL_M2_MASK0x1f
+#defineSHIFT_DPLL_M16
+#defineSHIFT_DPLL_N8
+#defineSHIFT_DPLL_M2 27
+#defineSCALING_FACTOR 10
/*
* CORE DPLL (DPLL3) M2 divider rate programming functions
@@ -51,10 +60,14 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
{
u32 new_div = 0;
u32 unlock_dll = 0;
- u32 c;
- unsigned long validrate, sdrcrate, _mpurate;
+ u32 c, delay_sram;
+ u32 clk_sel_regval, sys_clk;
+ u32 m, n, m2;
+ u32 sys_clk_rate, sdrc_clk_stab;
+ u32 refclk, clkoutx2, switch_latency;
struct omap_sdrc_params *sdrc_cs0;
struct omap_sdrc_params *sdrc_cs1;
+ unsigned long validrate, sdrcrate, _mpurate;
int ret;
if (!clk || !rate)
@@ -79,16 +92,37 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
unlock_dll = 1;
}
+ clk_sel_regval = __raw_readl(clk-clksel_reg);
+
+ /* Get the M, N and M2 values required for getting sdrc clk stab */
+ m = (clk_sel_regval SHIFT_DPLL_M) DPLL_M_MASK;
+ n = (clk_sel_regval SHIFT_DPLL_N) DPLL_N_MASK;
+ m2 = (clk_sel_regval SHIFT_DPLL_M2) DPLL_M2_MASK;
+
+ sys_clk_rate = (sys_ck_p-rate) / CYCLES_PER_MHZ;
+
+ _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ;
+
+ delay_sram = delay_sram_val();
+ sys_clk = (1 SCALING_FACTOR) / sys_clk_rate;
+ clkoutx2 = (sys_clk * (n + 1) * m2) / (2 * m);
+
+ /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
+ refclk = (n + 1) * sys_clk;
+ switch_latency = (4 * refclk) + (8 * clkoutx2);
+
+ /* Adding 2000 ns to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2000;
+
/*
-* XXX This only needs to be done when the CPU frequency changes
+* Calculate the number of MPU cycles
+* to wait for SDRC to stabilize
*/
- _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ;
- c = (_mpurate SDRC_MPURATE_SCALE) SDRC_MPURATE_BASE_SHIFT;
- c += 1; /* for safety */
- c *= SDRC_MPURATE_LOOPS;
- c = SDRC_MPURATE_SCALE;
- if (c == 0)
- c = 1;
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2)) SCALING_FACTOR;
+
+ pr_debug(m = %d, n = %d, m2 =%d\n, m, n, m2);
+ pr_debug(switch_latency = %d, sys_clk_rate = %d, cycles = %d\n,
+ switch_latency, sys_clk_rate, c);
pr_debug(clock: changing CORE DPLL rate from %lu to %lu\n, clk-rate,
validrate);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 628e8de..a9f2204 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -12,4 +12,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait;
extern const struct clkops
[PATCH v1 2/2] OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630
To calculate the dpll3 M2 clock stabilization delay dynamically and wait
time for L3 M2 clock stabilization are different for 3430 3630 and is
as follows:
3430: 4*REFCLK + 8*CLKOUTX2
3630: 2*SYS_CLK + 10*CLKOUTX2
REFCLK CLKOUTX2 are derived from M, N, M2 and DPLL reference clock.
Incase of 3430 a 2usec and 3630 1usec buffer time is added for safety.
Signed-off-by: Pramod Gurav pramod.gu...@ti.com
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Ambresh K ambr...@ti.com
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 6ad18f2..af0807a 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -39,6 +39,12 @@
#defineSHIFT_DPLL_M16
#defineSHIFT_DPLL_N8
#defineSHIFT_DPLL_M2 27
+
+/*
+ * While calculating M2 stabilization delay, especially the formula
+ * used for 3630 computes to zero. So to avoid calculation truncating to
+ * zero, SCALING_FACTOR is used appropriately.
+ */
#defineSCALING_FACTOR 10
/*
@@ -107,12 +113,21 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
sys_clk = (1 SCALING_FACTOR) / sys_clk_rate;
clkoutx2 = (sys_clk * (n + 1) * m2) / (2 * m);
- /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
- refclk = (n + 1) * sys_clk;
- switch_latency = (4 * refclk) + (8 * clkoutx2);
-
- /* Adding 2000 ns to sdrc clk stab */
- sdrc_clk_stab = switch_latency + 2000;
+ /*
+* wait time for L3 clk stabilization
+* for OMAP3430 = 4*REFCLK + 8*CLKOUTX2
+* for OMAP3630 = 2*REFCLK + 8*CLKOUTX2
+*/
+ if (cpu_is_omap3630()) {
+ switch_latency = (2 * sys_clk) + (10 * clkoutx2);
+ /* Adding 1000 nano seconds to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 1000;
+ } else {
+ refclk = (n + 1) * sys_clk;
+ switch_latency = (4 * refclk) + (8 * clkoutx2);
+ /* Adding 2000 ns to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2000;
+ }
/*
* Calculate the number of MPU cycles
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS
The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. By using the dynamic method the dependency on the type of cache being used is removed. To calculate the dpll3 M2 clock stabilization delay dynamically and wait time for L3 M2 clock stabilization are different for 3430 3630 and is as follows: 3430: 4*REFCLK + 8*CLKOUTX2 3630: 2*SYS_CLK + 10*CLKOUTX2 REFCLK CLKOUTX2 are derived from M, N, M2 and DPLL reference clock. Incase of 3430 a 2usec and 3630 1usec buffer time is added for safety. Below is the summery of the comments from the commumnity, those are addressed in this version of patch: 1. Change in ASM code to reduce overhead of a instruction 2. Replaced magic numbers with proper macros 3. Code style changes Teerth Reddy (1): OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS Pramod Gurav (2): OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630 arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 80 arch/arm/mach-omap2/clock34xx.h|2 + arch/arm/mach-omap2/clock3xxx.c|2 +- arch/arm/mach-omap2/clock3xxx.h|1 + arch/arm/mach-omap2/clock3xxx_data.c | 13 + arch/arm/mach-omap2/sram34xx.S |8 +++ arch/arm/plat-omap/include/plat/sram.h |4 ++ arch/arm/plat-omap/sram.c | 51 8 files changed, 150 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS
From: Teerth Reddy tee...@ti.com The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. By using the dynamic method the dependency on the type of cache being used is removed. The wait time for L3 clock stabilization is calculated using the formula = 4*REFCLK + 8*CLKOUTX2, which uses the M, N and M2 read from the registers. Since this gives slightly less value, 2us is added as buffer for safety. This works fine for omap3. Signed-off-by: Teerth Reddy tee...@ti.com Signed-off-by: Pramod Gurav pramod.gu...@ti.com Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com --- arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 54 +++- arch/arm/mach-omap2/clock34xx.h|2 + arch/arm/mach-omap2/clock3xxx.c|2 +- arch/arm/mach-omap2/clock3xxx.h|1 + arch/arm/mach-omap2/clock3xxx_data.c | 13 arch/arm/mach-omap2/sram34xx.S |8 + arch/arm/plat-omap/include/plat/sram.h |4 ++ arch/arm/plat-omap/sram.c | 51 ++ 8 files changed, 126 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c index b2b1e37..29421b1 100644 --- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c +++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c @@ -24,13 +24,21 @@ #include plat/clock.h #include plat/sram.h #include plat/sdrc.h +#include plat/prcm.h #include clock.h #include clock3xxx.h #include clock34xx.h #include sdrc.h -#define CYCLES_PER_MHZ 100 +#defineCYCLES_PER_MHZ 100 + +#defineDPLL_M_MASK 0x7ff +#defineDPLL_N_MASK 0x7f +#defineDPLL_M2_MASK0x1f +#defineSHIFT_DPLL_M16 +#defineSHIFT_DPLL_N8 +#defineSHIFT_DPLL_M2 27 /* * CORE DPLL (DPLL3) M2 divider rate programming functions @@ -56,6 +64,11 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) struct omap_sdrc_params *sdrc_cs0; struct omap_sdrc_params *sdrc_cs1; int ret; + u32 clk_sel_regval; + u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2; + u32 sys_clk_rate, sdrc_clk_stab; + u32 refclk, clkoutx2, switch_latency; + unsigned int delay_sram; if (!clk || !rate) return -EINVAL; @@ -79,16 +92,41 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) unlock_dll = 1; } + clk_sel_regval = __raw_readl(clk-clksel_reg); + + /* Get the M, N and M2 values required for getting sdrc clk stab */ + core_dpll_mul_m = (clk_sel_regval SHIFT_DPLL_M) DPLL_M_MASK; + core_dpll_div_n = (clk_sel_regval SHIFT_DPLL_N) DPLL_N_MASK; + core_dpll_clkoutdiv_m2 = (clk_sel_regval SHIFT_DPLL_M2) + DPLL_M2_MASK; + sys_clk_rate = clk_get_rate(sys_ck_p); + + sys_clk_rate = sys_clk_rate / CYCLES_PER_MHZ; + + /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */ + refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate; + clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) / + (sys_clk_rate * core_dpll_mul_m * 2); + switch_latency = refclk + 8 * clkoutx2; + + /* Adding 2us to sdrc clk stab */ + sdrc_clk_stab = switch_latency + 2; + + delay_sram = delay_sram_val(); + /* -* XXX This only needs to be done when the CPU frequency changes +* Calculate the number of MPU cycles +* to wait for SDRC to stabilize */ + _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ; - c = (_mpurate SDRC_MPURATE_SCALE) SDRC_MPURATE_BASE_SHIFT; - c += 1; /* for safety */ - c *= SDRC_MPURATE_LOOPS; - c = SDRC_MPURATE_SCALE; - if (c == 0) - c = 1; + + c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2)); + + pr_debug(m = %d, n = %d, m2 =%d\n, core_dpll_mul_m, core_dpll_div_n, + core_dpll_clkoutdiv_m2); + pr_debug(switch_latency = %d, sys_clk_rate = %d, cycles = %d\n, + switch_latency, sys_clk_rate, c); pr_debug(clock: changing CORE DPLL rate from %lu to %lu\n, clk-rate, validrate); diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h index 628e8de..a9f2204 100644 --- a/arch/arm/mach-omap2/clock34xx.h +++ b/arch/arm/mach-omap2/clock34xx.h @@ -12,4 +12,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait; extern const struct clkops clkops_omap3430es2_hsotgusb_wait; extern const struct clkops
[PATCH v2 2/2] OMAP3630 SDRC: Change in DVFS Latency Formula for OMAP3630
This patch uses new formula to derive the dpll3 clock Stabilization
delay during DVFS for OMAP3630. The formula used is :
Latency = 2 * SYS_CLK + 10 * CLKOUTX2
1usec buffer time is added for safety.
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Pramod Gurav pramod.gu...@ti.com
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 60 ++--
1 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 29421b1..58979ec 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -40,6 +40,9 @@
#defineSHIFT_DPLL_N8
#defineSHIFT_DPLL_M2 27
+#defineAVOID_TRUNC_10001000
+#defineAVOID_TRUNC_100 100
+
/*
* CORE DPLL (DPLL3) M2 divider rate programming functions
*
@@ -67,7 +70,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
u32 clk_sel_regval;
u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2;
u32 sys_clk_rate, sdrc_clk_stab;
- u32 refclk, clkoutx2, switch_latency;
+ u32 refclk, clkoutx2, switch_latency, dpll_lock_freq;
unsigned int delay_sram;
if (!clk || !rate)
@@ -100,28 +103,47 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
core_dpll_clkoutdiv_m2 = (clk_sel_regval SHIFT_DPLL_M2)
DPLL_M2_MASK;
sys_clk_rate = clk_get_rate(sys_ck_p);
-
sys_clk_rate = sys_clk_rate / CYCLES_PER_MHZ;
- /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
- refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
- clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
- (sys_clk_rate * core_dpll_mul_m * 2);
- switch_latency = refclk + 8 * clkoutx2;
-
- /* Adding 2us to sdrc clk stab */
- sdrc_clk_stab = switch_latency + 2;
-
- delay_sram = delay_sram_val();
-
- /*
-* Calculate the number of MPU cycles
-* to wait for SDRC to stabilize
-*/
-
_mpurate = arm_fck_p-rate / CYCLES_PER_MHZ;
+ delay_sram = delay_sram_val();
- c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
+ if (cpu_is_omap3630()) {
+ /*
+* wait time for L3 clk stabilization =
+* 2*SYS_CLK + 10*CLKOUTX2
+*/
+ /*
+* To avoid truncation of floating values, AVOID_TRUNC_1000
+* AVOID_TRUNC_100 are multiplied and divided appropriately
+*/
+ refclk = 2 * (AVOID_TRUNC_1000 / sys_clk_rate);
+ dpll_lock_freq = (AVOID_TRUNC_1000 * AVOID_TRUNC_100 *
+ (core_dpll_div_n + 1))/
+ (2 * sys_clk_rate * core_dpll_mul_m);
+ clkoutx2 = 10 * (dpll_lock_freq * core_dpll_clkoutdiv_m2) /
+ AVOID_TRUNC_100;
+ switch_latency = refclk + clkoutx2;
+
+ /* Adding 1000 nano seconds to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 1000;
+ c = ((sdrc_clk_stab * _mpurate) /
+ (delay_sram * 2 * AVOID_TRUNC_1000));
+ } else {
+ /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
+ refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
+ clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
+ (sys_clk_rate * core_dpll_mul_m * 2);
+ switch_latency = refclk + 8 * clkoutx2;
+
+ /* Adding 2us to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2;
+ /*
+* Calculate the number of MPU cycles to wait for
+* SDRC to stabilize
+*/
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
+ }
pr_debug(m = %d, n = %d, m2 =%d\n, core_dpll_mul_m, core_dpll_div_n,
core_dpll_clkoutdiv_m2);
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS
The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. By using the dynamic method the dependency on the type of cache being used is removed. Formula to calculate the DVFS latency for 3430 and 3630 are different. The second patch implements the formula for later. Below is the summery of the comments from the commumnity, those are addressed by these patches: 1. Subject of the patch mentioned as OMAP3: SDRC: instead of OMAP3: PM. 2. The first available dmtimer is requested dynamically instead of statically requesting a dmtimer. Thus hardcoding is avoided. 3. Excluded use of direct physical address of dmtimer. Instead used dmtimer APIs. 3. Only the counter loop is run in ASM. 4. Restructuring of formula for DVFS latency for 3430. 5. Adding new implementation for DVFS latency for 3630. Teerth Reddy (1): OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS Pramod Gurav (2): OMAP3630: SDRC: Change in DVFS Latency Formula for OMAP3630 arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 83 arch/arm/mach-omap2/clock34xx.h|2 + arch/arm/mach-omap2/clock3xxx_data.c | 12 + arch/arm/mach-omap2/sram34xx.S | 11 arch/arm/plat-omap/include/plat/sram.h |4 ++ arch/arm/plat-omap/sram.c | 49 +++ 6 files changed, 151 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS
From: Teerth Reddy tee...@ti.com The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. By using the dynamic method the dependency on the type of cache being used is removed. The wait time for L3 clock stabilization is calculated using the formula = 4*REFCLK + 8*CLKOUTX2, which uses the M, N and M2 read from the registers. Since this gives slightly less value, 2us is added as buffer for safety. This works fine for omap3. Signed-off-by: Teerth Reddy tee...@ti.com Signed-off-by: Romit Dasgupta ro...@ti.com Signed-off-by: Pramod Gurav pramod.gu...@ti.com Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com --- arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 52 +++ arch/arm/mach-omap2/clock34xx.h|2 + arch/arm/mach-omap2/clock3xxx_data.c | 12 +++ arch/arm/mach-omap2/sram34xx.S | 11 +++ arch/arm/plat-omap/include/plat/sram.h |4 ++ arch/arm/plat-omap/sram.c | 49 ++ 6 files changed, 123 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c index b2b1e37..3f61eb2 100644 --- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c +++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c @@ -24,6 +24,7 @@ #include plat/clock.h #include plat/sram.h #include plat/sdrc.h +#include plat/prcm.h #include clock.h #include clock3xxx.h @@ -32,6 +33,13 @@ #define CYCLES_PER_MHZ 100 +#defineDPLL_M_MASK 0x7ff +#defineDPLL_N_MASK 0x7f +#defineDPLL_M2_MASK0x1f +#defineSHIFT_DPLL_M16 +#defineSHIFT_DPLL_N8 +#defineSHIFT_DPLL_M2 27 + /* * CORE DPLL (DPLL3) M2 divider rate programming functions * @@ -56,6 +64,11 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) struct omap_sdrc_params *sdrc_cs0; struct omap_sdrc_params *sdrc_cs1; int ret; + u32 clk_sel_regval; + u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2; + u32 sys_clk_rate, sdrc_clk_stab; + u32 refclk, clkoutx2, switch_latency; + unsigned int delay_sram; if (!clk || !rate) return -EINVAL; @@ -79,16 +92,41 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) unlock_dll = 1; } + clk_sel_regval = __raw_readl(clk-clksel_reg); + + /* Get the M, N and M2 values required for getting sdrc clk stab */ + core_dpll_mul_m = (clk_sel_regval SHIFT_DPLL_M) DPLL_M_MASK; + core_dpll_div_n = (clk_sel_regval SHIFT_DPLL_N) DPLL_N_MASK; + core_dpll_clkoutdiv_m2 = (clk_sel_regval SHIFT_DPLL_M2) + DPLL_M2_MASK; + sys_clk_rate = clk_get_rate(clk_get(NULL, sys_ck)); + + sys_clk_rate = sys_clk_rate / CYCLES_PER_MHZ; + + /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */ + refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate; + clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) / + (sys_clk_rate * core_dpll_mul_m * 2); + switch_latency = refclk + 8 * clkoutx2; + + /* Adding 2us to sdrc clk stab */ + sdrc_clk_stab = switch_latency + 2; + + delay_sram = delay_sram_val(); + /* -* XXX This only needs to be done when the CPU frequency changes +* Calculate the number of MPU cycles +* to wait for SDRC to stabilize */ + _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ; - c = (_mpurate SDRC_MPURATE_SCALE) SDRC_MPURATE_BASE_SHIFT; - c += 1; /* for safety */ - c *= SDRC_MPURATE_LOOPS; - c = SDRC_MPURATE_SCALE; - if (c == 0) - c = 1; + + c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2)); + + pr_debug(m = %d, n = %d, m2 =%d\n, core_dpll_mul_m, core_dpll_div_n, + core_dpll_clkoutdiv_m2); + pr_debug(switch_latency = %d, sys_clk_rate = %d, cycles = %d\n, + switch_latency, sys_clk_rate, c); pr_debug(clock: changing CORE DPLL rate from %lu to %lu\n, clk-rate, validrate); diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h index 628e8de..a9f2204 100644 --- a/arch/arm/mach-omap2/clock34xx.h +++ b/arch/arm/mach-omap2/clock34xx.h @@ -12,4 +12,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait; extern const struct clkops clkops_omap3430es2_hsotgusb_wait; extern const struct clkops clkops_omap3430es2_dss_usbhost_wait; +unsigned int delay_sram_val(void); + #endif diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c index 57522de..9726f4b 100644 --- a/arch/arm
[PATCH 2/2] OMAP3630: SDRC: Change in DVFS Latency Formula for OMAP3630
This patch uses new formula to derive the dpll3 clock Stabilization
delay during DVFS for OMAP3630. The formula used is :
Latency = 2 * SYS_CLK + 10 * CLKOUTX2
Signed-off-by: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Pramod Gurav pramod.gu...@ti.com
---
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 53 +++
1 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 3f61eb2..eee0332 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -67,7 +67,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
u32 clk_sel_regval;
u32 core_dpll_mul_m, core_dpll_div_n, core_dpll_clkoutdiv_m2;
u32 sys_clk_rate, sdrc_clk_stab;
- u32 refclk, clkoutx2, switch_latency;
+ u32 refclk, clkoutx2, switch_latency, dpll_lock_freq;
unsigned int delay_sram;
if (!clk || !rate)
@@ -103,25 +103,50 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned
long rate)
sys_clk_rate = sys_clk_rate / CYCLES_PER_MHZ;
- /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2 */
- refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
- clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
+ if (cpu_is_omap3630()) {
+ /*
+* wait time for L3 clk stabilization =
+* 2*SYS_CLK + 10*CLKOUTX2
+*/
+ /* Avoid truncation of float values */
+ refclk = 2000 / sys_clk_rate;
+ dpll_lock_freq = (1000 * 100 * (core_dpll_div_n + 1))/
+ (2 * sys_clk_rate * core_dpll_mul_m);
+ clkoutx2 = 10 * (dpll_lock_freq * core_dpll_clkoutdiv_m2) / 100;
+ switch_latency = refclk + clkoutx2;
+
+ /* Adding 1000 nano seconds to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 1000;
+
+ delay_sram = delay_sram_val();
+ /*
+* Calculate the number of MPU cycles to wait for
+* SDRC to stabilize
+*/
+ _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ;
+
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2 * 1000));
+ } else {
+ /* wait time for L3 clk stabilization = 4*REFCLK + 8*CLKOUTX2*/
+ refclk = (4 * (core_dpll_div_n + 1)) / sys_clk_rate;
+ clkoutx2 = ((core_dpll_div_n + 1) * core_dpll_clkoutdiv_m2) /
(sys_clk_rate * core_dpll_mul_m * 2);
- switch_latency = refclk + 8 * clkoutx2;
+ switch_latency = refclk + 8 * clkoutx2;
- /* Adding 2us to sdrc clk stab */
- sdrc_clk_stab = switch_latency + 2;
+ /* Adding 2us to sdrc clk stab */
+ sdrc_clk_stab = switch_latency + 2;
- delay_sram = delay_sram_val();
+ delay_sram = delay_sram_val();
- /*
-* Calculate the number of MPU cycles
-* to wait for SDRC to stabilize
-*/
+ /*
+* Calculate the number of MPU cycles
+* to wait for SDRC to stabilize
+*/
+ _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ;
- _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ;
+ c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
- c = ((sdrc_clk_stab * _mpurate) / (delay_sram * 2));
+ }
pr_debug(m = %d, n = %d, m2 =%d\n, core_dpll_mul_m, core_dpll_div_n,
core_dpll_clkoutdiv_m2);
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB charging over TPS65950 BCI
hi gregoire, i did not mention about charge current. the sysfs entry charge_current always returns 360. -- Best Regards Pramod On Fri, Sep 11, 2009 at 7:21 PM, pramod gurav pramodfo...@gmail.com wrote: Hello gregoire, Really sorry I could not reply to your mail as I was busy with some other work. I applied your above patch tested. The sysfs entries return correct values for status, charger device(online), voltage_now. But the current across the battery is reported wrong. I compared the values returned by current_now sysfs entry with multimeter values across the battery. The values were varying whenever I remove AC and plug it back. But what I could see was the current_now value was approximately double the actual current across the battery. Without your patch the twl4030_bci gives wrong values for current_now, voltage_now, capacity etc. But your patch fixes this issue. But the USB charging did not work. Is USB charging functional with TWL4030 on any of the OMAP boards? Don't mind for the late reply. Thanks for your help. -- Thanks and Best Regards Pramod On Wed, Aug 5, 2009 at 9:48 PM, Gregoire Gentil grego...@gentil.com wrote: Hello, Any feed-back on the patch I sent? Have you tried it? Have you fixed your problem? Grégoire On Fri, 2009-07-31 at 23:41 -0700, Gregoire Gentil wrote: On Fri, 2009-07-31 at 19:19 +0530, pramod gurav wrote: Hi All, I was trying to get the USB battery charging working over TPS65950 BCI on the OMAP3430 custom board. I am working with linux-omap-2.6 v2.6.28-omap1 tag. I enabled the TWL4030 MADC and TWL4030 BCI drivers. I passed interrupt details to these drivers from platform_device structure from my board file. I could get the AC charging working. The AC and USB detection worked. However the USB charging is not happening. I read through the TPS TRM and took the dumps of the registers from BCI and some from TWL USB module and BOOT_BCI whenever I plug in the USB charger between host and the board. The register settings seem to be fine. But the battery is not charging. I am using BQ27000 chip for battery monitoring and I can see the battery voltage is decreasing. Following are the register dumps of TWL with and without USB plugged in: These are the register contents when USB charger is plugged in: BCIMDEN = 0x11 REG_BOOT_BCI = 0x37 REG_POWER_CTRL = 0x20 REG_BCIMFSTS4 = 0xf4 REG_BCIMFSTS1 = 0x13 REG_BCIIREF1 = 0x68 REG_BCIIREF2 = 0x3 REG_BCIMFEN4 = 0x6f REG_BCIMFSTS2 = 0x0 REG_BCIMSTATEC = 0x12 REG_STS_HW_CONDITIONS= 0x90 These are the register contents when USB charger is plugged out: BCIMDEN = 0x0 REG_BOOT_BCI = 0x35 REG_POWER_CTRL = 0x20 REG_BCIMFSTS4 = 0xf0 REG_BCIMFSTS1 = 0xaa REG_BCIIREF1 = 0x68 REG_BCIIREF2 = 0x3 REG_BCIMFEN4 = 0x68 REG_BCIMFSTS2 = 0x0 REG_BCIMSTATEC =0x0 REG_STS_HW_CONDITIONS= 0x10 Is there anything more I need to support to get BCI USB charging working? Need I follow any USB Communication protocol between Host and the board. I have pasted the kernel boot logs for reference at the end. Can any one please guide me to some pointers? -- Best Regards Pramod I'm experiencing some problems with TWL4030 DC charging and I'm interested by this kind of problem. Basically, the values reported by our patch is different from the current going to the battery. We wrote the attached enhanced patch so as to edit at run-time the charging mode and various values including charge_current. It's against 2.6.29 but I think that it should work again 2.6.28. Unfortunately, starting 2.6.30, Tony has removed all the BCI battery code and has asked for updated code against mainline but I've not seen anything so far. Pramod, can you try the attached patch (perhaps, it will help you) and can you tell if you see the exact current going to the battery reported by the driver? Grégoire --- a/drivers/power/twl4030_bci_battery.c 2009-07-22 18:27:16.0 -0700 +++ b/drivers/power/twl4030_bci_battery.c 2009-07-22 18:30:22.0 -0700 @@ -15,6 +15,9 @@ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ +/* Boot with automatic charge */ +#define CHARGE_MODE 1 + #include linux/init.h #include linux/module.h #include linux/device.h @@ -50,6 +53,7 @@ /* Boot BCI flag bits */ #define BCIAUTOWEN 0x020 #define CONFIG_DONE 0x010 +#define CVENAC 0x004 #define BCIAUTOUSB 0x002 #define BCIAUTOAC 0x001 #define BCIMSTAT_MASK 0x03F @@ -81,6 +85,11 @@ #define REG_BB_CFG 0x012 #define BBCHEN 0x010 +/* GPBR */ +#define REG_GPBR1 0x0c +#define MADC_HFCLK_EN 0x80 +#define DEFAULT_MADC_CLK_EN 0x10 + /* Power supply charge interrupt */ #define REG_PWR_ISR1 0x00 #define
USB charging over TPS65950 BCI
Hi All, I was trying to get the USB battery charging working over TPS65950 BCI on the OMAP3430 custom board. I am working with linux-omap-2.6 v2.6.28-omap1 tag. I enabled the TWL4030 MADC and TWL4030 BCI drivers. I passed interrupt details to these drivers from platform_device structure from my board file. I could get the AC charging working. The AC and USB detection worked. However the USB charging is not happening. I read through the TPS TRM and took the dumps of the registers from BCI and some from TWL USB module and BOOT_BCI whenever I plug in the USB charger between host and the board. The register settings seem to be fine. But the battery is not charging. I am using BQ27000 chip for battery monitoring and I can see the battery voltage is decreasing. Following are the register dumps of TWL with and without USB plugged in: These are the register contents when USB charger is plugged in: BCIMDEN = 0x11 REG_BOOT_BCI= 0x37 REG_POWER_CTRL = 0x20 REG_BCIMFSTS4 = 0xf4 REG_BCIMFSTS1 = 0x13 REG_BCIIREF1= 0x68 REG_BCIIREF2= 0x3 REG_BCIMFEN4= 0x6f REG_BCIMFSTS2 = 0x0 REG_BCIMSTATEC = 0x12 REG_STS_HW_CONDITIONS= 0x90 These are the register contents when USB charger is plugged out: BCIMDEN = 0x0 REG_BOOT_BCI= 0x35 REG_POWER_CTRL = 0x20 REG_BCIMFSTS4 = 0xf0 REG_BCIMFSTS1 = 0xaa REG_BCIIREF1= 0x68 REG_BCIIREF2= 0x3 REG_BCIMFEN4= 0x68 REG_BCIMFSTS2 = 0x0 REG_BCIMSTATEC =0x0 REG_STS_HW_CONDITIONS= 0x10 Is there anything more I need to support to get BCI USB charging working? Need I follow any USB Communication protocol between Host and the board. I have pasted the kernel boot logs for reference at the end. Can any one please guide me to some pointers? -- Best Regards Pramod Starting kernel ... Uncompressing Linux... done, boo. Linux version 2.6.28-omap1-(gpra...@gpramod.mistral.in) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #25 Fri Jul 31 15:48:37 I9 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3430 Main Board Memory policy: ECC disabled, Data cache writeback OMAP3430 Unknown revision SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 Reserving 4194304 bytes SDRAM for VRAM Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootfstype=ext3 rootdelay=3 android.ril=pts/0 init=/init Unknown boot option `android.ril=pts/0': ignoring Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz Reprogramming SDRC GPMC revision 5.0 IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP34xx GPIO hardware version 2.5 PID hash table entries: 1024 (order: 10, 4096 bytes) OMAP clockevent source: GPTIMER12 at 32768 Hz Console: colour dummy device 80x30 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 128MB 128MB = 256MB total Memory: 250880KB available (3580K code, 755K data, 300K init) Calibrating delay loop... 494.72 BogoMIPS (lpj=1933312) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok net_namespace: 312 bytes NET: Registered protocol family 16 Found NAND on CS0 Registering NAND on CS0 OMAP DMA hardware revision 4.0 USB: No board-specific platform config found OMAP DSS rev 2.0 OMAP DISPC rev 3.0 OMAP VENC rev 2 i2c_omap i2c_omap.1: bus 1 rev3.12 at 400 kHz Skipping twl4030 internal clock init and using bootloader value (unknown osc rate) twl4030: PIH (irq 7) chaining IRQs 368..375 twl4030: power (irq 373) chaining IRQs 376..383 twl4030: gpio (irq 368) chaining IRQs 384..401 i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz SCSI subsystem initialized twl4030_usb twl4030_usb: Initialized TWL4030 USB module usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 musb_hdrc: USB OTG mode controller at d80ab000 using DMA, IRQ 92 NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered NET: Registered protocol family 1 NetWinder Floating Point Emulator V0.97 (double precision) ashmem: initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) JFFS2 version 2.2. (NAND) �© 2001-2006 Red Hat, Inc. msgmni has been set to 490 alg: No test for stdrng (krng) io scheduler noop registered io scheduler
I2C1 controller timed out with twl4030-powerbutton
Hi all, I am working on omap3430 custom board with linux-omap-2.6 (2.6.28-omap1 tag) on it. I am using twl4030 power buttom. Whenever I press the power key I get i2c controller timed out. I am seeing following logs and the keypad stops responding and I have to remove the board supply completely. i2c_omap i2c_omap.1: controller timed out i2c_omap i2c_omap.1: controller timed out twl4030: I2C error -110 reading PIH ISR i2c_omap i2c_omap.1: controller timed out twl4030: I2C error -110 reading PIH ISR i2c_omap i2c_omap.1: controller timed out twl4030: I2C error -110 reading PIH ISR i2c_omap i2c_omap.1: controller timed out When I enabled the logs I could see twl4030: i2c error -110 while reading TWL4030 PM_MASTER STS_HW_CONDITIONS register The behavior is seen mostly with power-button key. Is there any fix that has gone into the kernel for this(after 2.6.28-omap1)? -- Best Regards Pramod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dma_alloc_coherent fragmentation
Hi Nishant, I am facing the same problem to allocate a chunk of 4MB on omap3evm using dma_alloc_coherent. I used the test driver mentioned here http://www.mail-archive.com/linux-omap@vger.kernel.org/msg11074.html I applied the patch for ioremap(24f11ec001920f1cfaeeed8e8b55725d900bbb56) suggested by Russell, but stiill seeing the error saying coherent allocation too big (requested 0x40 mask 0x) alloc[0] - virt=0x phy=0x size=0x0040 Allocation failed idx=0 insmod: cannot insert `dummy.ko': Cannot allocate memory (-1): Cannot allocate memory I changed the GFP_KERNEL to GFP_TEMPORARY and also to (GFP_KERNEL | __GFP_RECLAIMABLE), but failed to insmod the module. I am working on linux-omap 2.6.28 kernel. Even I could not allocate memory size greater than 1MB. Has this been fixed? Are there any patches to fix this issue? On Thu, Mar 19, 2009 at 2:36 PM, Menon, Nishanth n...@ti.com wrote: Hi Hiroshi, -Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Thursday, March 19, 2009 8:43 AM What would happen with __GFP_RECLAIMABLE for dma_alloc_coherent()? As per [1], GFP_TEMPORARY might be the right approach.. but yes, Changing dummy to do: dma_alloc_coherent(NULL, b[i].size, b[i].phy, GFP_TEMPORARY); Seems to resolve the issue with the dummy driver. The question however still remains: For a driver to allocate a memory which is not temporary in nature we'd recommend GFP_KERNEL. But as part of the exit sequence the driver will deallocate that memory and as part of init sequence, reallocate. Given that the memory is not reclaimed immediately, it looks like the only way to ensure that would be to do GFP_KERNEL | __GFP_RECLAIMABLE (which essentially is the definition of GFP_TEMPORARY). Regards, Nishanth Menon Ref: [1] http://lkml.indiana.edu/hypermail/linux/kernel/0705.2/0638.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Pramod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dma_alloc_coherent fragmentation
Thanks for the quick reply. Can you please point me to some links on DMA pools. I am just blank on this. :( I will still search for this in net. -- Best Regards Pramod On Wed, Apr 22, 2009 at 1:20 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: DMA pool is better solution for such usecases. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of pramod gurav Sent: Wednesday, April 22, 2009 1:17 PM To: Menon, Nishanth Cc: linux-omap@vger.kernel.org Subject: Re: dma_alloc_coherent fragmentation Hi Nishant, I am facing the same problem to allocate a chunk of 4MB on omap3evm using dma_alloc_coherent. I used the test driver mentioned here http://www.mail-archive.com/linux-omap@vger.kernel.org/msg11074.html I applied the patch for ioremap(24f11ec001920f1cfaeeed8e8b55725d900bbb56) suggested by Russell, but stiill seeing the error saying coherent allocation too big (requested 0x40 mask 0x) alloc[0] - virt=0x phy=0x size=0x0040 Allocation failed idx=0 insmod: cannot insert `dummy.ko': Cannot allocate memory (-1): Cannot allocate memory I changed the GFP_KERNEL to GFP_TEMPORARY and also to (GFP_KERNEL | __GFP_RECLAIMABLE), but failed to insmod the module. I am working on linux-omap 2.6.28 kernel. Even I could not allocate memory size greater than 1MB. Has this been fixed? Are there any patches to fix this issue? On Thu, Mar 19, 2009 at 2:36 PM, Menon, Nishanth n...@ti.com wrote: -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dma_alloc_coherent fragmentation
Hi Ramesh, This worked. Thanks a lot. -- Best Regards Pramod On Wed, Apr 22, 2009 at 2:44 PM, Gupta, Ramesh grgu...@ti.com wrote: Hi Pramod, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of pramod gurav Sent: Wednesday, April 22, 2009 1:17 PM To: Menon, Nishanth Cc: linux-omap@vger.kernel.org Subject: Re: dma_alloc_coherent fragmentation Hi Nishant, I am facing the same problem to allocate a chunk of 4MB on omap3evm using dma_alloc_coherent. I used the test driver mentioned here http://www.mail-archive.com/linux-omap@vger.kernel.org/msg11074.html I applied the patch for ioremap(24f11ec001920f1cfaeeed8e8b55725d900bbb56) suggested by Russell, but stiill seeing the error saying coherent allocation too big (requested 0x40 mask 0x) alloc[0] - virt=0x phy=0x size=0x0040 Allocation failed idx=0 insmod: cannot insert `dummy.ko': Cannot allocate memory (-1): Cannot allocate memory I changed the GFP_KERNEL to GFP_TEMPORARY and also to (GFP_KERNEL | __GFP_RECLAIMABLE), but failed to insmod the module. I am working on linux-omap 2.6.28 kernel. Even I could not allocate memory size greater than 1MB. Has this been fixed? Are there any patches to fix this issue? What is the value for 'CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE' (default is 2 in omap_3430sdp_defconfig), Can you please try increasing to 8? Regards Ramesh Gupta G -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
i2c-probe in 2.6.28 returns -EOPNOTSUPP
Hi All I am trying to port the i2c client drivers from linux-omap-2.6.26 to 2.6.28. The i2c client drivers are old styled. The i2c-probe function called by attach_adapter function returns -EOPNOTSUPP. This states adapter does not support SMBUS_QUICK command. Same driver on linux-omap-2.6.26 works well. The omap_i2c_func in i2c-omap.c driver doesn't seem to be returning this support. What changes have gone into i2c-omap driver that are causing i2c-probe function to return this error value? -- Best Regards Pramod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C1 controller timed out issue
Hi, I am using current linux-omap git sources. Can you please post the patch to fix this timeout issue. On Sat, Dec 20, 2008 at 7:39 PM, Felipe Balbi m...@felipebalbi.com wrote: On Sat, Dec 20, 2008 at 03:34:00PM +0530, pramod gurav wrote: Hi, I am working on OMAP3430 board. The kernel is linux-omap-2.6. The twl5030 module is sitting on i2c1. I often come across a error saying i2c_omap i2c_omap.1: controller timed out i2c_omap i2c_omap.1: controller timed out This is all what appears in logs when i2c1 times out and all the other slave devices on i2c1 stop responding. Other i2c busses(2) work properly. if try to reboot the I2C fails to respnd in u-boot also saying timed out in wait_for_pin: I2C_STAT=0 I2C read failed timed out in wait_for_pin: I2C_STAT=0 I2C read failed timed out in wait_for_pin: I2C_STAT=0 I2C read failed I have to to do hard reset to progress with the boot. I gone through the changes happened to i2-omap driver in between and tried applying the patches manually. The problem still persists. May be I am missing some more changes. The i2-omap.c source is attached herewith this mail. Somebody please suggest me on this issue if this has been seen as a issue and if fixed. Are you using current linux-omap from git ? This problem is long gone. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C1 controller timed out issue
Hi, The kernel is from the tag v2.6.26-omap2. And I applied the patch http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff; h=663715fc55ea5d292171c6934a2b91d8f4874171;hp=3c0134484bd5fe3c3d9611aab1983881efc894c0 But it did not work for me. Pramod On Mon, Dec 22, 2008 at 10:44 AM, pramod gurav pramodfo...@gmail.com wrote: Hi, I am using current linux-omap git sources. Can you please post the patch to fix this timeout issue. On Sat, Dec 20, 2008 at 7:39 PM, Felipe Balbi m...@felipebalbi.com wrote: On Sat, Dec 20, 2008 at 03:34:00PM +0530, pramod gurav wrote: Hi, I am working on OMAP3430 board. The kernel is linux-omap-2.6. The twl5030 module is sitting on i2c1. I often come across a error saying i2c_omap i2c_omap.1: controller timed out i2c_omap i2c_omap.1: controller timed out This is all what appears in logs when i2c1 times out and all the other slave devices on i2c1 stop responding. Other i2c busses(2) work properly. if try to reboot the I2C fails to respnd in u-boot also saying timed out in wait_for_pin: I2C_STAT=0 I2C read failed timed out in wait_for_pin: I2C_STAT=0 I2C read failed timed out in wait_for_pin: I2C_STAT=0 I2C read failed I have to to do hard reset to progress with the boot. I gone through the changes happened to i2-omap driver in between and tried applying the patches manually. The problem still persists. May be I am missing some more changes. The i2-omap.c source is attached herewith this mail. Somebody please suggest me on this issue if this has been seen as a issue and if fixed. Are you using current linux-omap from git ? This problem is long gone. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bluetooth SHUTDOWN GPIO on omap3430 labrador
Hi All I have a omap3430 logic zoom board. I want to configure bluetooth on it(BRF6300) which will interfaced to UART2. I gone through the schematics and could find that the BT_SHUTDOWN is controlled through GPIO.8 coming from TWL4030. Is that wright? I tried using that GPIO but the hci interface did not respond. I am using linux-2.6.24 with all bluetooth kernel support. What is correct GPIO to BT_SHUTDOWN. Reply is much awaited. Thanks for time and consideration. Pramod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
bluetooth GPIO on logic zoom omap3430 (labrador) board
Hi All I have a omap3430 logic zoom board. I want to configure bluetooth on it(BRF6300) which will interfaced to UART2. I gone through the schematics and could find that the BT_SHUTDOWN is controlled through GPIO.8 coming from TWL4030. Is that wright? I tried using that GPIO but the hci interface did not respond. I am using linux-2.6.24 with all bluetooth kernel support. What is correct GPIO to BT_SHUTDOWN. Reply is much awaited. Thanks for time and consideration. Pramod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
