* [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-09-24 10:47 [PATCH 0/2] OMAP3 PM: sleep code clean up Vishwanath BS
@ 2010-09-24 10:47 ` Vishwanath BS
0 siblings, 0 replies; 37+ messages in thread
From: Vishwanath BS @ 2010-09-24 10:47 UTC (permalink / raw)
To: linux-omap; +Cc: Vishwanath BS, Kevin Hillman
There is no need to keep omap3 sleep code in SRAM. This code can be run very
well on DDR. This would help us to instrument CPUIdle latencies.
Tested on ZOOM3.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Cc: Kevin Hillman <khilman@deeprootsystems.com>
---
arch/arm/mach-omap2/pm34xx.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 85ef245..ed9d12c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -79,8 +79,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -360,9 +358,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -438,7 +433,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
if (is_suspending())
@@ -995,8 +990,6 @@ static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 0/2] OMAP3 PM: sleep code clean up
@ 2010-09-24 10:56 Vishwanath BS
2010-09-24 10:56 ` [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr Vishwanath BS
2010-09-24 10:56 ` [PATCH 2/2] OMAP3 PM: sleep code clean up Vishwanath BS
0 siblings, 2 replies; 37+ messages in thread
From: Vishwanath BS @ 2010-09-24 10:56 UTC (permalink / raw)
To: linux-omap; +Cc: linaro-dev, Vishwanath BS
This patch series has some clean up in OMAP3 sleep code.
Patches have been rebased to latest kevin's pm branch.
Vishwanath BS (2):
OMAP3 PM: move omap3 sleep to ddr
OMAP3 PM: sleep code clean up
arch/arm/mach-omap2/pm34xx.c | 9 +-
arch/arm/mach-omap2/sleep34xx.S | 377 ++++++++++++++---------------
arch/arm/plat-omap/include/plat/control.h | 2 +
3 files changed, 190 insertions(+), 198 deletions(-)
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-09-24 10:56 [PATCH 0/2] OMAP3 PM: sleep code clean up Vishwanath BS
@ 2010-09-24 10:56 ` Vishwanath BS
2010-09-24 19:01 ` Tony Lindgren
2010-09-24 19:57 ` Kevin Hilman
2010-09-24 10:56 ` [PATCH 2/2] OMAP3 PM: sleep code clean up Vishwanath BS
1 sibling, 2 replies; 37+ messages in thread
From: Vishwanath BS @ 2010-09-24 10:56 UTC (permalink / raw)
To: linux-omap; +Cc: linaro-dev, Vishwanath BS, Kevin Hillman
There is no need to keep omap3 sleep code in SRAM. This code can be run very
well on DDR. This would help us to instrument CPUIdle latencies.
Tested on ZOOM3.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Cc: Kevin Hillman <khilman@deeprootsystems.com>
Cc: <Linaro> linaro-dev@lists.linaro.org
---
arch/arm/mach-omap2/pm34xx.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 85ef245..ed9d12c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -79,8 +79,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -360,9 +358,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -438,7 +433,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
if (is_suspending())
@@ -995,8 +990,6 @@ static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
1.7.0.4
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 2/2] OMAP3 PM: sleep code clean up
2010-09-24 10:56 [PATCH 0/2] OMAP3 PM: sleep code clean up Vishwanath BS
2010-09-24 10:56 ` [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr Vishwanath BS
@ 2010-09-24 10:56 ` Vishwanath BS
[not found] ` <1285325785-6163-3-git-send-email-vishwanath.bs-l0cyMroinI0@public.gmane.org>
1 sibling, 1 reply; 37+ messages in thread
From: Vishwanath BS @ 2010-09-24 10:56 UTC (permalink / raw)
To: linux-omap; +Cc: linaro-dev, Vishwanath BS, Kevin Hillman
This patch has done some clean up of omap3 sleep code.
Basically all possible hardcodings are removed and code is Reorganized
into more logical buckets for better readability and instrumentation.
Tested on ZOOM3.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Cc: Kevin Hillman <khilman@deeprootsystems.com>
Cc: <Linaro> linaro-dev@lists.linaro.org
---
arch/arm/mach-omap2/sleep34xx.S | 377 ++++++++++++++---------------
arch/arm/plat-omap/include/plat/control.h | 2 +
2 files changed, 189 insertions(+), 190 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index ba53191..734f82a
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -33,17 +33,20 @@
#include "prm.h"
#include "sdrc.h"
-#define SDRC_SCRATCHPAD_SEM_V 0xfa00291c
+#define SDRC_SCRATCHPAD_SEM_OFFS 0xc
+#define SDRC_SCRATCHPAD_SEM_V OMAP343X_SCRATCHPAD_REGADDR \
+ (SDRC_SCRATCHPAD_SEM_OFFS)
#define PM_PREPWSTST_CORE_V OMAP34XX_PRM_REGADDR(CORE_MOD, \
- OMAP3430_PM_PREPWSTST)
-#define PM_PREPWSTST_CORE_P 0x48306AE8
+ OMAP3430_PM_PREPWSTST)
+#define PM_PREPWSTST_CORE_P OMAP3430_PRM_BASE + CORE_MOD + \
+ OMAP3430_PM_PREPWSTST
#define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \
OMAP3430_PM_PREPWSTST)
#define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL
#define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1)
-#define SRAM_BASE_P 0x40200000
-#define CONTROL_STAT 0x480022F0
+#define SRAM_BASE_P 0x40200000
+#define CONTROL_STAT OMAP343X_CTRL_BASE + OMAP343X_CONTROL_STATUS
#define SCRATCHPAD_MEM_OFFS 0x310 /* Move this as correct place is
* available */
#define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\
@@ -184,29 +187,16 @@ api_params:
ENTRY(save_secure_ram_context_sz)
.word . - save_secure_ram_context
-/*
- * Forces OMAP into idle state
- *
- * omap34xx_suspend() - This bit of code just executes the WFI
- * for normal idles.
- *
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- * wakes up it continues execution at the point it went to sleep.
- */
-ENTRY(omap34xx_cpu_suspend)
+/* Function to execute WFI. When the MPU wakes up from retention
+ * or inactive mode, it continues execution just after wfi */
+ENTRY(omap34xx_do_wfi)
stmfd sp!, {r0-r12, lr} @ save registers on stack
-loop:
- /*b loop*/ @Enable to debug by stepping through code
- /* r0 contains restore pointer in sdram */
- /* r1 contains information about saving context */
+
ldr r4, sdrc_power @ read the SDRC_POWER register
ldr r5, [r4] @ read the contents of SDRC_POWER
orr r5, r5, #0x40 @ enable self refresh on idle req
str r5, [r4] @ write back to SDRC_POWER register
- cmp r1, #0x0
- /* If context save is required, do that and execute wfi */
- bne save_context_wfi
/* Data memory barrier and Data sync barrier */
mov r1, #0
mcr p15, 0, r1, c7, c10, 4
@@ -225,8 +215,182 @@ loop:
nop
nop
bl wait_sdrc_ok
+ ldmfd sp!, {r0-r12, pc} @ restore regs and return
+
+/*
+ * Forces OMAP into idle state
+ *
+ * omap34xx_cpu_suspend() - This bit of code just executes the WFI
+ * for normal idles and saves the context before WFI on off modes.
+ *
+ */
+
+ENTRY(omap34xx_cpu_suspend)
+ stmfd sp!, {r0-r12, lr} @ save registers on stack
+loop:
+ /*b loop*/ @Enable to debug by stepping through code
+ /* r0 contains restore pointer in sdram */
+ /* r1 contains information about saving context */
+
+ cmp r1, #0x0
+ /* If context save is required, do that and execute wfi */
+ bne save_context_wfi
+ bl omap34xx_do_wfi
ldmfd sp!, {r0-r12, pc} @ restore regs and return
+
+save_context_wfi:
+ /*b save_context_wfi*/ @ enable to debug save code
+ mov r8, r0 /* Store SDRAM address in r8 */
+ mrc p15, 0, r5, c1, c0, 1 @ Read Auxiliary Control Register
+ mov r4, #0x1 @ Number of parameters for restore call
+ stmia r8!, {r4-r5} @ Push parameters for restore call
+ mrc p15, 1, r5, c9, c0, 2 @ Read L2 AUX ctrl register
+ stmia r8!, {r4-r5} @ Push parameters for restore call
+ /* Check what that target sleep state is:stored in r1*/
+ /* 1 - Only L1 and logic lost */
+ /* 2 - Only L2 lost */
+ /* 3 - Both L1 and L2 lost */
+ cmp r1, #0x2 /* Only L2 lost */
+ beq clean_l2
+ cmp r1, #0x1 /* L2 retained */
+ /* r9 stores whether to clean L2 or not*/
+ moveq r9, #0x0 /* Dont Clean L2 */
+ movne r9, #0x1 /* Clean L2 */
+l1_logic_lost:
+ /* Store sp and spsr to SDRAM */
+ mov r4, sp
+ mrs r5, spsr
+ mov r6, lr
+ stmia r8!, {r4-r6}
+ /* Save all ARM registers */
+ /* Coprocessor access control register */
+ mrc p15, 0, r6, c1, c0, 2
+ stmia r8!, {r6}
+ /* TTBR0, TTBR1 and Translation table base control */
+ mrc p15, 0, r4, c2, c0, 0
+ mrc p15, 0, r5, c2, c0, 1
+ mrc p15, 0, r6, c2, c0, 2
+ stmia r8!, {r4-r6}
+ /* Domain access control register, data fault status register,
+ and instruction fault status register */
+ mrc p15, 0, r4, c3, c0, 0
+ mrc p15, 0, r5, c5, c0, 0
+ mrc p15, 0, r6, c5, c0, 1
+ stmia r8!, {r4-r6}
+ /* Data aux fault status register, instruction aux fault status,
+ datat fault address register and instruction fault address register*/
+ mrc p15, 0, r4, c5, c1, 0
+ mrc p15, 0, r5, c5, c1, 1
+ mrc p15, 0, r6, c6, c0, 0
+ mrc p15, 0, r7, c6, c0, 2
+ stmia r8!, {r4-r7}
+ /* user r/w thread and process ID, user r/o thread and process ID,
+ priv only thread and process ID, cache size selection */
+ mrc p15, 0, r4, c13, c0, 2
+ mrc p15, 0, r5, c13, c0, 3
+ mrc p15, 0, r6, c13, c0, 4
+ mrc p15, 2, r7, c0, c0, 0
+ stmia r8!, {r4-r7}
+ /* Data TLB lockdown, instruction TLB lockdown registers */
+ mrc p15, 0, r5, c10, c0, 0
+ mrc p15, 0, r6, c10, c0, 1
+ stmia r8!, {r5-r6}
+ /* Secure or non secure vector base address, FCSE PID, Context PID*/
+ mrc p15, 0, r4, c12, c0, 0
+ mrc p15, 0, r5, c13, c0, 0
+ mrc p15, 0, r6, c13, c0, 1
+ stmia r8!, {r4-r6}
+ /* Primary remap, normal remap registers */
+ mrc p15, 0, r4, c10, c2, 0
+ mrc p15, 0, r5, c10, c2, 1
+ stmia r8!,{r4-r5}
+
+ /* Store current cpsr*/
+ mrs r2, cpsr
+ stmia r8!, {r2}
+
+ mrc p15, 0, r4, c1, c0, 0
+ /* save control register */
+ stmia r8!, {r4}
+clean_caches:
+ /* Clean Data or unified cache to POU*/
+ /* How to invalidate only L1 cache???? - #FIX_ME# */
+ /* mcr p15, 0, r11, c7, c11, 1 */
+ cmp r9, #1 /* Check whether L2 inval is required or not*/
+ bne skip_l2_inval
+clean_l2:
+ /* read clidr */
+ mrc p15, 1, r0, c0, c0, 1
+ /* extract loc from clidr */
+ ands r3, r0, #0x7000000
+ /* left align loc bit field */
+ mov r3, r3, lsr #23
+ /* if loc is 0, then no need to clean */
+ beq finished
+ /* start clean at cache level 0 */
+ mov r10, #0
+loop1:
+ /* work out 3x current cache level */
+ add r2, r10, r10, lsr #1
+ /* extract cache type bits from clidr*/
+ mov r1, r0, lsr r2
+ /* mask of the bits for current cache only */
+ and r1, r1, #7
+ /* see what cache we have at this level */
+ cmp r1, #2
+ /* skip if no cache, or just i-cache */
+ blt skip
+ /* select current cache level in cssr */
+ mcr p15, 2, r10, c0, c0, 0
+ /* isb to sych the new cssr&csidr */
+ isb
+ /* read the new csidr */
+ mrc p15, 1, r1, c0, c0, 0
+ /* extract the length of the cache lines */
+ and r2, r1, #7
+ /* add 4 (line length offset) */
+ add r2, r2, #4
+ ldr r4, assoc_mask
+ /* find maximum number on the way size */
+ ands r4, r4, r1, lsr #3
+ /* find bit position of way size increment */
+ clz r5, r4
+ ldr r7, numset_mask
+ /* extract max number of the index size*/
+ ands r7, r7, r1, lsr #13
+loop2:
+ mov r9, r4
+ /* create working copy of max way size*/
+loop3:
+ /* factor way and cache number into r11 */
+ orr r11, r10, r9, lsl r5
+ /* factor index number into r11 */
+ orr r11, r11, r7, lsl r2
+ /*clean & invalidate by set/way */
+ mcr p15, 0, r11, c7, c10, 2
+ /* decrement the way*/
+ subs r9, r9, #1
+ bge loop3
+ /*decrement the index */
+ subs r7, r7, #1
+ bge loop2
+skip:
+ add r10, r10, #2
+ /* increment cache number */
+ cmp r3, r10
+ bgt loop1
+finished:
+ /*swith back to cache level 0 */
+ mov r10, #0
+ /* select current cache level in cssr */
+ mcr p15, 2, r10, c0, c0, 0
+ isb
+skip_l2_inval:
+ bl omap34xx_do_wfi
+ ldmfd sp!, {r0-r12, pc}
+
+/* This is where ROM code jumps when MPU comes out of off mode */
restore_es3:
/*b restore_es3*/ @ Enable to debug restore code
ldr r5, pm_prepwstst_core_p
@@ -437,175 +601,8 @@ usettbr0:
ldr r2, cache_pred_disable_mask
and r4, r2
mcr p15, 0, r4, c1, c0, 0
-
ldmfd sp!, {r0-r12, pc} @ restore regs and return
-save_context_wfi:
- /*b save_context_wfi*/ @ enable to debug save code
- mov r8, r0 /* Store SDRAM address in r8 */
- mrc p15, 0, r5, c1, c0, 1 @ Read Auxiliary Control Register
- mov r4, #0x1 @ Number of parameters for restore call
- stmia r8!, {r4-r5} @ Push parameters for restore call
- mrc p15, 1, r5, c9, c0, 2 @ Read L2 AUX ctrl register
- stmia r8!, {r4-r5} @ Push parameters for restore call
- /* Check what that target sleep state is:stored in r1*/
- /* 1 - Only L1 and logic lost */
- /* 2 - Only L2 lost */
- /* 3 - Both L1 and L2 lost */
- cmp r1, #0x2 /* Only L2 lost */
- beq clean_l2
- cmp r1, #0x1 /* L2 retained */
- /* r9 stores whether to clean L2 or not*/
- moveq r9, #0x0 /* Dont Clean L2 */
- movne r9, #0x1 /* Clean L2 */
-l1_logic_lost:
- /* Store sp and spsr to SDRAM */
- mov r4, sp
- mrs r5, spsr
- mov r6, lr
- stmia r8!, {r4-r6}
- /* Save all ARM registers */
- /* Coprocessor access control register */
- mrc p15, 0, r6, c1, c0, 2
- stmia r8!, {r6}
- /* TTBR0, TTBR1 and Translation table base control */
- mrc p15, 0, r4, c2, c0, 0
- mrc p15, 0, r5, c2, c0, 1
- mrc p15, 0, r6, c2, c0, 2
- stmia r8!, {r4-r6}
- /* Domain access control register, data fault status register,
- and instruction fault status register */
- mrc p15, 0, r4, c3, c0, 0
- mrc p15, 0, r5, c5, c0, 0
- mrc p15, 0, r6, c5, c0, 1
- stmia r8!, {r4-r6}
- /* Data aux fault status register, instruction aux fault status,
- datat fault address register and instruction fault address register*/
- mrc p15, 0, r4, c5, c1, 0
- mrc p15, 0, r5, c5, c1, 1
- mrc p15, 0, r6, c6, c0, 0
- mrc p15, 0, r7, c6, c0, 2
- stmia r8!, {r4-r7}
- /* user r/w thread and process ID, user r/o thread and process ID,
- priv only thread and process ID, cache size selection */
- mrc p15, 0, r4, c13, c0, 2
- mrc p15, 0, r5, c13, c0, 3
- mrc p15, 0, r6, c13, c0, 4
- mrc p15, 2, r7, c0, c0, 0
- stmia r8!, {r4-r7}
- /* Data TLB lockdown, instruction TLB lockdown registers */
- mrc p15, 0, r5, c10, c0, 0
- mrc p15, 0, r6, c10, c0, 1
- stmia r8!, {r5-r6}
- /* Secure or non secure vector base address, FCSE PID, Context PID*/
- mrc p15, 0, r4, c12, c0, 0
- mrc p15, 0, r5, c13, c0, 0
- mrc p15, 0, r6, c13, c0, 1
- stmia r8!, {r4-r6}
- /* Primary remap, normal remap registers */
- mrc p15, 0, r4, c10, c2, 0
- mrc p15, 0, r5, c10, c2, 1
- stmia r8!,{r4-r5}
-
- /* Store current cpsr*/
- mrs r2, cpsr
- stmia r8!, {r2}
- mrc p15, 0, r4, c1, c0, 0
- /* save control register */
- stmia r8!, {r4}
-clean_caches:
- /* Clean Data or unified cache to POU*/
- /* How to invalidate only L1 cache???? - #FIX_ME# */
- /* mcr p15, 0, r11, c7, c11, 1 */
- cmp r9, #1 /* Check whether L2 inval is required or not*/
- bne skip_l2_inval
-clean_l2:
- /* read clidr */
- mrc p15, 1, r0, c0, c0, 1
- /* extract loc from clidr */
- ands r3, r0, #0x7000000
- /* left align loc bit field */
- mov r3, r3, lsr #23
- /* if loc is 0, then no need to clean */
- beq finished
- /* start clean at cache level 0 */
- mov r10, #0
-loop1:
- /* work out 3x current cache level */
- add r2, r10, r10, lsr #1
- /* extract cache type bits from clidr*/
- mov r1, r0, lsr r2
- /* mask of the bits for current cache only */
- and r1, r1, #7
- /* see what cache we have at this level */
- cmp r1, #2
- /* skip if no cache, or just i-cache */
- blt skip
- /* select current cache level in cssr */
- mcr p15, 2, r10, c0, c0, 0
- /* isb to sych the new cssr&csidr */
- isb
- /* read the new csidr */
- mrc p15, 1, r1, c0, c0, 0
- /* extract the length of the cache lines */
- and r2, r1, #7
- /* add 4 (line length offset) */
- add r2, r2, #4
- ldr r4, assoc_mask
- /* find maximum number on the way size */
- ands r4, r4, r1, lsr #3
- /* find bit position of way size increment */
- clz r5, r4
- ldr r7, numset_mask
- /* extract max number of the index size*/
- ands r7, r7, r1, lsr #13
-loop2:
- mov r9, r4
- /* create working copy of max way size*/
-loop3:
- /* factor way and cache number into r11 */
- orr r11, r10, r9, lsl r5
- /* factor index number into r11 */
- orr r11, r11, r7, lsl r2
- /*clean & invalidate by set/way */
- mcr p15, 0, r11, c7, c10, 2
- /* decrement the way*/
- subs r9, r9, #1
- bge loop3
- /*decrement the index */
- subs r7, r7, #1
- bge loop2
-skip:
- add r10, r10, #2
- /* increment cache number */
- cmp r3, r10
- bgt loop1
-finished:
- /*swith back to cache level 0 */
- mov r10, #0
- /* select current cache level in cssr */
- mcr p15, 2, r10, c0, c0, 0
- isb
-skip_l2_inval:
- /* Data memory barrier and Data sync barrier */
- mov r1, #0
- mcr p15, 0, r1, c7, c10, 4
- mcr p15, 0, r1, c7, c10, 5
-
- wfi @ wait for interrupt
- nop
- nop
- nop
- nop
- nop
- nop
- nop
- nop
- nop
- nop
- bl wait_sdrc_ok
- /* restore regs and return */
- ldmfd sp!, {r0-r12, pc}
/* Make sure SDRC accesses are ok */
wait_sdrc_ok:
@@ -669,4 +666,4 @@ cache_pred_disable_mask:
control_stat:
.word CONTROL_STAT
ENTRY(omap34xx_cpu_suspend_sz)
- .word . - omap34xx_cpu_suspend
+ .word . - omap34xx_cpu_suspend
diff --git a/arch/arm/plat-omap/include/plat/control.h b/arch/arm/plat-omap/include/plat/control.h
index 46e166d..306259e 100644
--- a/arch/arm/plat-omap/include/plat/control.h
+++ b/arch/arm/plat-omap/include/plat/control.h
@@ -314,6 +314,8 @@
#define OMAP343X_SCRATCHPAD_ROM (OMAP343X_CTRL_BASE + 0x860)
#define OMAP343X_SCRATCHPAD (OMAP343X_CTRL_BASE + 0x910)
#define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C
+#define OMAP343X_SCRATCHPAD_REGADDR(reg) \
+ OMAP2_L4_IO_ADDRESS(OMAP343X_SCRATCHPAD + reg)
/* AM35XX_CONTROL_IPSS_CLK_CTRL bits */
#define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0
--
1.7.0.4
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-09-24 10:56 ` [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr Vishwanath BS
@ 2010-09-24 19:01 ` Tony Lindgren
2010-09-24 19:09 ` Tony Lindgren
2010-09-24 19:57 ` Kevin Hilman
1 sibling, 1 reply; 37+ messages in thread
From: Tony Lindgren @ 2010-09-24 19:01 UTC (permalink / raw)
To: Vishwanath BS; +Cc: linux-omap, linaro-dev, Kevin Hillman
* Vishwanath BS <vishwanath.bs@ti.com> [100924 03:50]:
> There is no need to keep omap3 sleep code in SRAM. This code can be run very
> well on DDR. This would help us to instrument CPUIdle latencies.
Uhh, are you sure about this? To me it sounds like you're then
relying on the code running from the cache for off-idle?
What about CONFIG_CPU_ICACHE_DISABLE?
Regards,
Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-09-24 19:01 ` Tony Lindgren
@ 2010-09-24 19:09 ` Tony Lindgren
[not found] ` <20100924190930.GH4211-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
0 siblings, 1 reply; 37+ messages in thread
From: Tony Lindgren @ 2010-09-24 19:09 UTC (permalink / raw)
To: Vishwanath BS; +Cc: linux-omap, linaro-dev, Kevin Hillman
* Tony Lindgren <tony@atomide.com> [100924 11:53]:
> * Vishwanath BS <vishwanath.bs@ti.com> [100924 03:50]:
> > There is no need to keep omap3 sleep code in SRAM. This code can be run very
> > well on DDR. This would help us to instrument CPUIdle latencies.
>
> Uhh, are you sure about this? To me it sounds like you're then
> relying on the code running from the cache for off-idle?
Actually the caches are off too for off-idle..
Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-09-24 10:56 ` [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr Vishwanath BS
2010-09-24 19:01 ` Tony Lindgren
@ 2010-09-24 19:57 ` Kevin Hilman
2010-10-04 7:26 ` Sripathy, Vishwanath
1 sibling, 1 reply; 37+ messages in thread
From: Kevin Hilman @ 2010-09-24 19:57 UTC (permalink / raw)
To: Vishwanath BS; +Cc: linux-omap, linaro-dev
Vishwanath BS <vishwanath.bs@ti.com> writes:
> There is no need to keep omap3 sleep code in SRAM.
> This code can be run very well on DDR.
/me remains skeptical
> This would help us to instrument CPUIdle latencies.
Indeed, but...
I'm afraid we will need a much more descriptive changelog here,
describing in detail why this will still work, and what about the
previous motiviations for running SRAM has changed such that this will
work out of SRAM.
> Tested on ZOOM3.
Tested in what way? This path is used for both idle and suspend, and
needs to be validated for retention and off mode.
Kevin
> Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
> Cc: Kevin Hillman <khilman@deeprootsystems.com>
> Cc: <Linaro> linaro-dev@lists.linaro.org
> ---
> arch/arm/mach-omap2/pm34xx.c | 9 +--------
> 1 files changed, 1 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 85ef245..ed9d12c 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -79,8 +79,6 @@ struct power_state {
>
> static LIST_HEAD(pwrst_list);
>
> -static void (*_omap_sram_idle)(u32 *addr, int save_state);
> -
> static int (*_omap_save_secure_sram)(u32 *addr);
>
> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> @@ -360,9 +358,6 @@ void omap_sram_idle(void)
> int core_prev_state, per_prev_state;
> u32 sdrc_pwr = 0;
>
> - if (!_omap_sram_idle)
> - return;
> -
> pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
> pwrdm_clear_all_prev_pwrst(neon_pwrdm);
> pwrdm_clear_all_prev_pwrst(core_pwrdm);
> @@ -438,7 +433,7 @@ void omap_sram_idle(void)
> * get saved. The restore path then reads from this
> * location and restores them back.
> */
> - _omap_sram_idle(omap3_arm_context, save_state);
> + omap34xx_cpu_suspend(omap3_arm_context, save_state);
> cpu_init();
>
> if (is_suspending())
> @@ -995,8 +990,6 @@ static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
>
> void omap_push_sram_idle(void)
> {
> - _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
> - omap34xx_cpu_suspend_sz);
> if (omap_type() != OMAP2_DEVICE_TYPE_GP)
> _omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
> save_secure_ram_context_sz);
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 2/2] OMAP3 PM: sleep code clean up
[not found] ` <1285325785-6163-3-git-send-email-vishwanath.bs-l0cyMroinI0@public.gmane.org>
@ 2010-09-24 20:05 ` Kevin Hilman
2010-10-04 8:44 ` Sripathy, Vishwanath
0 siblings, 1 reply; 37+ messages in thread
From: Kevin Hilman @ 2010-09-24 20:05 UTC (permalink / raw)
To: Vishwanath BS
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linaro-dev-cunTk1MwBs8s++Sfvej+rw
Vishwanath BS <vishwanath.bs-l0cyMroinI0@public.gmane.org> writes:
> This patch has done some clean up of omap3 sleep code.
> Basically all possible hardcodings are removed and code is Reorganized
> into more logical buckets for better readability and instrumentation.
>
> Tested on ZOOM3.
Again, please describe more about how it was tested. idle? suspend?
retention? off?
Also please fix long-line checkpatch warnings.
While breaking this up in to subroutines, why not just call them all
from the C-code instead of assembly?
But this also makes me wonder, if we're going to clean this up, the bulk
of it could be re-written in C, with some inline asm helpers as needed.
Kevin
> Signed-off-by: Vishwanath BS <vishwanath.bs-l0cyMroinI0@public.gmane.org>
> Cc: Kevin Hillman <khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
> Cc: <Linaro> linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
> ---
> arch/arm/mach-omap2/sleep34xx.S | 377 ++++++++++++++---------------
> arch/arm/plat-omap/include/plat/control.h | 2 +
> 2 files changed, 189 insertions(+), 190 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
> index ba53191..734f82a
> --- a/arch/arm/mach-omap2/sleep34xx.S
> +++ b/arch/arm/mach-omap2/sleep34xx.S
> @@ -33,17 +33,20 @@
> #include "prm.h"
> #include "sdrc.h"
>
> -#define SDRC_SCRATCHPAD_SEM_V 0xfa00291c
> +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc
> +#define SDRC_SCRATCHPAD_SEM_V OMAP343X_SCRATCHPAD_REGADDR \
> + (SDRC_SCRATCHPAD_SEM_OFFS)
>
> #define PM_PREPWSTST_CORE_V OMAP34XX_PRM_REGADDR(CORE_MOD, \
> - OMAP3430_PM_PREPWSTST)
> -#define PM_PREPWSTST_CORE_P 0x48306AE8
> + OMAP3430_PM_PREPWSTST)
> +#define PM_PREPWSTST_CORE_P OMAP3430_PRM_BASE + CORE_MOD + \
> + OMAP3430_PM_PREPWSTST
> #define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \
> OMAP3430_PM_PREPWSTST)
> #define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL
> #define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1)
> -#define SRAM_BASE_P 0x40200000
> -#define CONTROL_STAT 0x480022F0
> +#define SRAM_BASE_P 0x40200000
> +#define CONTROL_STAT OMAP343X_CTRL_BASE + OMAP343X_CONTROL_STATUS
> #define SCRATCHPAD_MEM_OFFS 0x310 /* Move this as correct place is
> * available */
> #define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\
> @@ -184,29 +187,16 @@ api_params:
> ENTRY(save_secure_ram_context_sz)
> .word . - save_secure_ram_context
>
> -/*
> - * Forces OMAP into idle state
> - *
> - * omap34xx_suspend() - This bit of code just executes the WFI
> - * for normal idles.
> - *
> - * Note: This code get's copied to internal SRAM at boot. When the OMAP
> - * wakes up it continues execution at the point it went to sleep.
> - */
> -ENTRY(omap34xx_cpu_suspend)
> +/* Function to execute WFI. When the MPU wakes up from retention
> + * or inactive mode, it continues execution just after wfi */
fix multi-line comment style
> +ENTRY(omap34xx_do_wfi)
> stmfd sp!, {r0-r12, lr} @ save registers on stack
> -loop:
> - /*b loop*/ @Enable to debug by stepping through code
> - /* r0 contains restore pointer in sdram */
> - /* r1 contains information about saving context */
> +
> ldr r4, sdrc_power @ read the SDRC_POWER register
> ldr r5, [r4] @ read the contents of SDRC_POWER
> orr r5, r5, #0x40 @ enable self refresh on idle req
> str r5, [r4] @ write back to SDRC_POWER register
>
> - cmp r1, #0x0
> - /* If context save is required, do that and execute wfi */
> - bne save_context_wfi
> /* Data memory barrier and Data sync barrier */
> mov r1, #0
> mcr p15, 0, r1, c7, c10, 4
> @@ -225,8 +215,182 @@ loop:
> nop
> nop
> bl wait_sdrc_ok
> + ldmfd sp!, {r0-r12, pc} @ restore regs and return
> +
> +/*
> + * Forces OMAP into idle state
> + *
> + * omap34xx_cpu_suspend() - This bit of code just executes the WFI
> + * for normal idles and saves the context before WFI on off modes.
> + *
> + */
> +
> +ENTRY(omap34xx_cpu_suspend)
> + stmfd sp!, {r0-r12, lr} @ save registers on stack
> +loop:
> + /*b loop*/ @Enable to debug by stepping through code
> + /* r0 contains restore pointer in sdram */
> + /* r1 contains information about saving context */
> +
> + cmp r1, #0x0
> + /* If context save is required, do that and execute wfi */
> + bne save_context_wfi
> + bl omap34xx_do_wfi
>
> ldmfd sp!, {r0-r12, pc} @ restore regs and return
> +
> +save_context_wfi:
> + /*b save_context_wfi*/ @ enable to debug save code
> + mov r8, r0 /* Store SDRAM address in r8 */
> + mrc p15, 0, r5, c1, c0, 1 @ Read Auxiliary Control Register
> + mov r4, #0x1 @ Number of parameters for restore call
> + stmia r8!, {r4-r5} @ Push parameters for restore call
> + mrc p15, 1, r5, c9, c0, 2 @ Read L2 AUX ctrl register
> + stmia r8!, {r4-r5} @ Push parameters for restore call
> + /* Check what that target sleep state is:stored in r1*/
> + /* 1 - Only L1 and logic lost */
> + /* 2 - Only L2 lost */
> + /* 3 - Both L1 and L2 lost */
> + cmp r1, #0x2 /* Only L2 lost */
> + beq clean_l2
> + cmp r1, #0x1 /* L2 retained */
> + /* r9 stores whether to clean L2 or not*/
> + moveq r9, #0x0 /* Dont Clean L2 */
> + movne r9, #0x1 /* Clean L2 */
> +l1_logic_lost:
> + /* Store sp and spsr to SDRAM */
> + mov r4, sp
> + mrs r5, spsr
> + mov r6, lr
> + stmia r8!, {r4-r6}
> + /* Save all ARM registers */
> + /* Coprocessor access control register */
> + mrc p15, 0, r6, c1, c0, 2
> + stmia r8!, {r6}
> + /* TTBR0, TTBR1 and Translation table base control */
> + mrc p15, 0, r4, c2, c0, 0
> + mrc p15, 0, r5, c2, c0, 1
> + mrc p15, 0, r6, c2, c0, 2
> + stmia r8!, {r4-r6}
> + /* Domain access control register, data fault status register,
> + and instruction fault status register */
> + mrc p15, 0, r4, c3, c0, 0
> + mrc p15, 0, r5, c5, c0, 0
> + mrc p15, 0, r6, c5, c0, 1
> + stmia r8!, {r4-r6}
> + /* Data aux fault status register, instruction aux fault status,
> + datat fault address register and instruction fault address register*/
> + mrc p15, 0, r4, c5, c1, 0
> + mrc p15, 0, r5, c5, c1, 1
> + mrc p15, 0, r6, c6, c0, 0
> + mrc p15, 0, r7, c6, c0, 2
> + stmia r8!, {r4-r7}
> + /* user r/w thread and process ID, user r/o thread and process ID,
> + priv only thread and process ID, cache size selection */
> + mrc p15, 0, r4, c13, c0, 2
> + mrc p15, 0, r5, c13, c0, 3
> + mrc p15, 0, r6, c13, c0, 4
> + mrc p15, 2, r7, c0, c0, 0
> + stmia r8!, {r4-r7}
> + /* Data TLB lockdown, instruction TLB lockdown registers */
> + mrc p15, 0, r5, c10, c0, 0
> + mrc p15, 0, r6, c10, c0, 1
> + stmia r8!, {r5-r6}
> + /* Secure or non secure vector base address, FCSE PID, Context PID*/
> + mrc p15, 0, r4, c12, c0, 0
> + mrc p15, 0, r5, c13, c0, 0
> + mrc p15, 0, r6, c13, c0, 1
> + stmia r8!, {r4-r6}
> + /* Primary remap, normal remap registers */
> + mrc p15, 0, r4, c10, c2, 0
> + mrc p15, 0, r5, c10, c2, 1
> + stmia r8!,{r4-r5}
> +
> + /* Store current cpsr*/
> + mrs r2, cpsr
> + stmia r8!, {r2}
> +
> + mrc p15, 0, r4, c1, c0, 0
> + /* save control register */
> + stmia r8!, {r4}
> +clean_caches:
> + /* Clean Data or unified cache to POU*/
> + /* How to invalidate only L1 cache???? - #FIX_ME# */
> + /* mcr p15, 0, r11, c7, c11, 1 */
> + cmp r9, #1 /* Check whether L2 inval is required or not*/
> + bne skip_l2_inval
> +clean_l2:
> + /* read clidr */
> + mrc p15, 1, r0, c0, c0, 1
> + /* extract loc from clidr */
> + ands r3, r0, #0x7000000
> + /* left align loc bit field */
> + mov r3, r3, lsr #23
> + /* if loc is 0, then no need to clean */
> + beq finished
> + /* start clean at cache level 0 */
> + mov r10, #0
> +loop1:
> + /* work out 3x current cache level */
> + add r2, r10, r10, lsr #1
> + /* extract cache type bits from clidr*/
> + mov r1, r0, lsr r2
> + /* mask of the bits for current cache only */
> + and r1, r1, #7
> + /* see what cache we have at this level */
> + cmp r1, #2
> + /* skip if no cache, or just i-cache */
> + blt skip
> + /* select current cache level in cssr */
> + mcr p15, 2, r10, c0, c0, 0
> + /* isb to sych the new cssr&csidr */
> + isb
> + /* read the new csidr */
> + mrc p15, 1, r1, c0, c0, 0
> + /* extract the length of the cache lines */
> + and r2, r1, #7
> + /* add 4 (line length offset) */
> + add r2, r2, #4
> + ldr r4, assoc_mask
> + /* find maximum number on the way size */
> + ands r4, r4, r1, lsr #3
> + /* find bit position of way size increment */
> + clz r5, r4
> + ldr r7, numset_mask
> + /* extract max number of the index size*/
> + ands r7, r7, r1, lsr #13
> +loop2:
> + mov r9, r4
> + /* create working copy of max way size*/
> +loop3:
> + /* factor way and cache number into r11 */
> + orr r11, r10, r9, lsl r5
> + /* factor index number into r11 */
> + orr r11, r11, r7, lsl r2
> + /*clean & invalidate by set/way */
> + mcr p15, 0, r11, c7, c10, 2
> + /* decrement the way*/
> + subs r9, r9, #1
> + bge loop3
> + /*decrement the index */
> + subs r7, r7, #1
> + bge loop2
> +skip:
> + add r10, r10, #2
> + /* increment cache number */
> + cmp r3, r10
> + bgt loop1
> +finished:
> + /*swith back to cache level 0 */
> + mov r10, #0
> + /* select current cache level in cssr */
> + mcr p15, 2, r10, c0, c0, 0
> + isb
> +skip_l2_inval:
> + bl omap34xx_do_wfi
> + ldmfd sp!, {r0-r12, pc}
> +
> +/* This is where ROM code jumps when MPU comes out of off mode */
> restore_es3:
> /*b restore_es3*/ @ Enable to debug restore code
> ldr r5, pm_prepwstst_core_p
> @@ -437,175 +601,8 @@ usettbr0:
> ldr r2, cache_pred_disable_mask
> and r4, r2
> mcr p15, 0, r4, c1, c0, 0
> -
> ldmfd sp!, {r0-r12, pc} @ restore regs and return
> -save_context_wfi:
> - /*b save_context_wfi*/ @ enable to debug save code
> - mov r8, r0 /* Store SDRAM address in r8 */
> - mrc p15, 0, r5, c1, c0, 1 @ Read Auxiliary Control Register
> - mov r4, #0x1 @ Number of parameters for restore call
> - stmia r8!, {r4-r5} @ Push parameters for restore call
> - mrc p15, 1, r5, c9, c0, 2 @ Read L2 AUX ctrl register
> - stmia r8!, {r4-r5} @ Push parameters for restore call
> - /* Check what that target sleep state is:stored in r1*/
> - /* 1 - Only L1 and logic lost */
> - /* 2 - Only L2 lost */
> - /* 3 - Both L1 and L2 lost */
> - cmp r1, #0x2 /* Only L2 lost */
> - beq clean_l2
> - cmp r1, #0x1 /* L2 retained */
> - /* r9 stores whether to clean L2 or not*/
> - moveq r9, #0x0 /* Dont Clean L2 */
> - movne r9, #0x1 /* Clean L2 */
> -l1_logic_lost:
> - /* Store sp and spsr to SDRAM */
> - mov r4, sp
> - mrs r5, spsr
> - mov r6, lr
> - stmia r8!, {r4-r6}
> - /* Save all ARM registers */
> - /* Coprocessor access control register */
> - mrc p15, 0, r6, c1, c0, 2
> - stmia r8!, {r6}
> - /* TTBR0, TTBR1 and Translation table base control */
> - mrc p15, 0, r4, c2, c0, 0
> - mrc p15, 0, r5, c2, c0, 1
> - mrc p15, 0, r6, c2, c0, 2
> - stmia r8!, {r4-r6}
> - /* Domain access control register, data fault status register,
> - and instruction fault status register */
> - mrc p15, 0, r4, c3, c0, 0
> - mrc p15, 0, r5, c5, c0, 0
> - mrc p15, 0, r6, c5, c0, 1
> - stmia r8!, {r4-r6}
> - /* Data aux fault status register, instruction aux fault status,
> - datat fault address register and instruction fault address register*/
> - mrc p15, 0, r4, c5, c1, 0
> - mrc p15, 0, r5, c5, c1, 1
> - mrc p15, 0, r6, c6, c0, 0
> - mrc p15, 0, r7, c6, c0, 2
> - stmia r8!, {r4-r7}
> - /* user r/w thread and process ID, user r/o thread and process ID,
> - priv only thread and process ID, cache size selection */
> - mrc p15, 0, r4, c13, c0, 2
> - mrc p15, 0, r5, c13, c0, 3
> - mrc p15, 0, r6, c13, c0, 4
> - mrc p15, 2, r7, c0, c0, 0
> - stmia r8!, {r4-r7}
> - /* Data TLB lockdown, instruction TLB lockdown registers */
> - mrc p15, 0, r5, c10, c0, 0
> - mrc p15, 0, r6, c10, c0, 1
> - stmia r8!, {r5-r6}
> - /* Secure or non secure vector base address, FCSE PID, Context PID*/
> - mrc p15, 0, r4, c12, c0, 0
> - mrc p15, 0, r5, c13, c0, 0
> - mrc p15, 0, r6, c13, c0, 1
> - stmia r8!, {r4-r6}
> - /* Primary remap, normal remap registers */
> - mrc p15, 0, r4, c10, c2, 0
> - mrc p15, 0, r5, c10, c2, 1
> - stmia r8!,{r4-r5}
> -
> - /* Store current cpsr*/
> - mrs r2, cpsr
> - stmia r8!, {r2}
>
> - mrc p15, 0, r4, c1, c0, 0
> - /* save control register */
> - stmia r8!, {r4}
> -clean_caches:
> - /* Clean Data or unified cache to POU*/
> - /* How to invalidate only L1 cache???? - #FIX_ME# */
> - /* mcr p15, 0, r11, c7, c11, 1 */
> - cmp r9, #1 /* Check whether L2 inval is required or not*/
> - bne skip_l2_inval
> -clean_l2:
> - /* read clidr */
> - mrc p15, 1, r0, c0, c0, 1
> - /* extract loc from clidr */
> - ands r3, r0, #0x7000000
> - /* left align loc bit field */
> - mov r3, r3, lsr #23
> - /* if loc is 0, then no need to clean */
> - beq finished
> - /* start clean at cache level 0 */
> - mov r10, #0
> -loop1:
> - /* work out 3x current cache level */
> - add r2, r10, r10, lsr #1
> - /* extract cache type bits from clidr*/
> - mov r1, r0, lsr r2
> - /* mask of the bits for current cache only */
> - and r1, r1, #7
> - /* see what cache we have at this level */
> - cmp r1, #2
> - /* skip if no cache, or just i-cache */
> - blt skip
> - /* select current cache level in cssr */
> - mcr p15, 2, r10, c0, c0, 0
> - /* isb to sych the new cssr&csidr */
> - isb
> - /* read the new csidr */
> - mrc p15, 1, r1, c0, c0, 0
> - /* extract the length of the cache lines */
> - and r2, r1, #7
> - /* add 4 (line length offset) */
> - add r2, r2, #4
> - ldr r4, assoc_mask
> - /* find maximum number on the way size */
> - ands r4, r4, r1, lsr #3
> - /* find bit position of way size increment */
> - clz r5, r4
> - ldr r7, numset_mask
> - /* extract max number of the index size*/
> - ands r7, r7, r1, lsr #13
> -loop2:
> - mov r9, r4
> - /* create working copy of max way size*/
> -loop3:
> - /* factor way and cache number into r11 */
> - orr r11, r10, r9, lsl r5
> - /* factor index number into r11 */
> - orr r11, r11, r7, lsl r2
> - /*clean & invalidate by set/way */
> - mcr p15, 0, r11, c7, c10, 2
> - /* decrement the way*/
> - subs r9, r9, #1
> - bge loop3
> - /*decrement the index */
> - subs r7, r7, #1
> - bge loop2
> -skip:
> - add r10, r10, #2
> - /* increment cache number */
> - cmp r3, r10
> - bgt loop1
> -finished:
> - /*swith back to cache level 0 */
> - mov r10, #0
> - /* select current cache level in cssr */
> - mcr p15, 2, r10, c0, c0, 0
> - isb
> -skip_l2_inval:
> - /* Data memory barrier and Data sync barrier */
> - mov r1, #0
> - mcr p15, 0, r1, c7, c10, 4
> - mcr p15, 0, r1, c7, c10, 5
> -
> - wfi @ wait for interrupt
> - nop
> - nop
> - nop
> - nop
> - nop
> - nop
> - nop
> - nop
> - nop
> - nop
> - bl wait_sdrc_ok
> - /* restore regs and return */
> - ldmfd sp!, {r0-r12, pc}
>
> /* Make sure SDRC accesses are ok */
> wait_sdrc_ok:
> @@ -669,4 +666,4 @@ cache_pred_disable_mask:
> control_stat:
> .word CONTROL_STAT
> ENTRY(omap34xx_cpu_suspend_sz)
> - .word . - omap34xx_cpu_suspend
> + .word . - omap34xx_cpu_suspend
> diff --git a/arch/arm/plat-omap/include/plat/control.h b/arch/arm/plat-omap/include/plat/control.h
> index 46e166d..306259e 100644
> --- a/arch/arm/plat-omap/include/plat/control.h
> +++ b/arch/arm/plat-omap/include/plat/control.h
> @@ -314,6 +314,8 @@
> #define OMAP343X_SCRATCHPAD_ROM (OMAP343X_CTRL_BASE + 0x860)
> #define OMAP343X_SCRATCHPAD (OMAP343X_CTRL_BASE + 0x910)
> #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C
> +#define OMAP343X_SCRATCHPAD_REGADDR(reg) \
> + OMAP2_L4_IO_ADDRESS(OMAP343X_SCRATCHPAD + reg)
>
> /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */
> #define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
[not found] ` <20100924190930.GH4211-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
@ 2010-09-25 5:52 ` Shilimkar, Santosh
0 siblings, 0 replies; 37+ messages in thread
From: Shilimkar, Santosh @ 2010-09-25 5:52 UTC (permalink / raw)
To: Tony Lindgren, Sripathy, Vishwanath
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
> -----Original Message-----
> From: linux-omap-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-omap-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Tony Lindgren
> Sent: Saturday, September 25, 2010 12:40 AM
> To: Sripathy, Vishwanath
> Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org; Kevin Hillman
> Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
>
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [100924 11:53]:
> > * Vishwanath BS <vishwanath.bs-l0cyMroinI0@public.gmane.org> [100924 03:50]:
> > > There is no need to keep omap3 sleep code in SRAM. This code can be
> run very
> > > well on DDR. This would help us to instrument CPUIdle latencies.
> >
> > Uhh, are you sure about this? To me it sounds like you're then
> > relying on the code running from the cache for off-idle?
>
> Actually the caches are off too for off-idle..
>
The low power code can be executed from DDR and need not be from
cache. The only real implementation on OMAP3 is around DVFS code,
where you need to put DDR to self refresh and execute some
piece of code. That still needs to be executed from some other
memory like (SRAM).
Regards,
Santosh
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-09-24 19:57 ` Kevin Hilman
@ 2010-10-04 7:26 ` Sripathy, Vishwanath
0 siblings, 0 replies; 37+ messages in thread
From: Sripathy, Vishwanath @ 2010-10-04 7:26 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap@vger.kernel.org, linaro-dev@lists.linaro.org
Kevin,
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Saturday, September 25, 2010 1:28 AM
> To: Sripathy, Vishwanath
> Cc: linux-omap@vger.kernel.org; linaro-dev@lists.linaro.org
> Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
>
> Vishwanath BS <vishwanath.bs@ti.com> writes:
>
> > There is no need to keep omap3 sleep code in SRAM.
> > This code can be run very well on DDR.
>
> /me remains skeptical
>
> > This would help us to instrument CPUIdle latencies.
>
> Indeed, but...
>
> I'm afraid we will need a much more descriptive changelog here,
> describing in detail why this will still work, and what about the
> previous motiviations for running SRAM has changed such that this will
> work out of SRAM.
Running the code from SRAM for CPUIdle was more of legacy from OMAP2 and there was no technical reason why it cannot be run from DDR. Also note that, once MPU enters off mode, wake up code used to run from DDR earlier (w/o these changes) as well. I will put more details in the change log.
>
> > Tested on ZOOM3.
>
> Tested in what way? This path is used for both idle and suspend, and
> needs to be validated for retention and off mode.
I have tested for both retention and off mode in both CPU idle and suspend path. I will update the changelog in next version.
Vishwa
>
> Kevin
>
> > Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
> > Cc: Kevin Hillman <khilman@deeprootsystems.com>
> > Cc: <Linaro> linaro-dev@lists.linaro.org
> > ---
> > arch/arm/mach-omap2/pm34xx.c | 9 +--------
> > 1 files changed, 1 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> > index 85ef245..ed9d12c 100644
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -79,8 +79,6 @@ struct power_state {
> >
> > static LIST_HEAD(pwrst_list);
> >
> > -static void (*_omap_sram_idle)(u32 *addr, int save_state);
> > -
> > static int (*_omap_save_secure_sram)(u32 *addr);
> >
> > static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> > @@ -360,9 +358,6 @@ void omap_sram_idle(void)
> > int core_prev_state, per_prev_state;
> > u32 sdrc_pwr = 0;
> >
> > - if (!_omap_sram_idle)
> > - return;
> > -
> > pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
> > pwrdm_clear_all_prev_pwrst(neon_pwrdm);
> > pwrdm_clear_all_prev_pwrst(core_pwrdm);
> > @@ -438,7 +433,7 @@ void omap_sram_idle(void)
> > * get saved. The restore path then reads from this
> > * location and restores them back.
> > */
> > - _omap_sram_idle(omap3_arm_context, save_state);
> > + omap34xx_cpu_suspend(omap3_arm_context, save_state);
> > cpu_init();
> >
> > if (is_suspending())
> > @@ -995,8 +990,6 @@ static int __init clkdms_setup(struct clockdomain *clkdm,
> void *unused)
> >
> > void omap_push_sram_idle(void)
> > {
> > - _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
> > - omap34xx_cpu_suspend_sz);
> > if (omap_type() != OMAP2_DEVICE_TYPE_GP)
> > _omap_save_secure_sram =
> omap_sram_push(save_secure_ram_context,
> > save_secure_ram_context_sz);
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 2/2] OMAP3 PM: sleep code clean up
2010-09-24 20:05 ` Kevin Hilman
@ 2010-10-04 8:44 ` Sripathy, Vishwanath
2010-10-04 8:56 ` Amit Kucheria
0 siblings, 1 reply; 37+ messages in thread
From: Sripathy, Vishwanath @ 2010-10-04 8:44 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap@vger.kernel.org, linaro-dev@lists.linaro.org
Kevin,
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Saturday, September 25, 2010 1:35 AM
> To: Sripathy, Vishwanath
> Cc: linux-omap@vger.kernel.org; linaro-dev@lists.linaro.org
> Subject: Re: [PATCH 2/2] OMAP3 PM: sleep code clean up
>
> Vishwanath BS <vishwanath.bs@ti.com> writes:
>
> > This patch has done some clean up of omap3 sleep code.
> > Basically all possible hardcodings are removed and code is Reorganized
> > into more logical buckets for better readability and instrumentation.
> >
> > Tested on ZOOM3.
>
> Again, please describe more about how it was tested. idle? suspend?
> retention? off?
This has been tested for both RET and OFF mode in Idle and suspend path. Will update the change log for the same.
>
> Also please fix long-line checkpatch warnings.
OK.
>
> While breaking this up in to subroutines, why not just call them all
> from the C-code instead of assembly?
I thought about that. But unfortunately, while saving CPU registers (in save_context_wfi), LR also gets saved. So if I call wfi routine (omap34xx_do_wfi ) from C code itself, then LR would have pointed to omap34xx_do_wfi while saving
the registers which is not correct.
>
> But this also makes me wonder, if we're going to clean this up, the bulk
> of it could be re-written in C, with some inline asm helpers as needed.
Probably yes. But as this code is specific to OMAP3, do you think it's worth spending time on rewriting the entire code in C? It might be a significant effort and it will not be reusable for other ARM SOCs.
Vishwa
>
> Kevin
>
> > Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
> > Cc: Kevin Hillman <khilman@deeprootsystems.com>
> > Cc: <Linaro> linaro-dev@lists.linaro.org
> > ---
> > arch/arm/mach-omap2/sleep34xx.S | 377 ++++++++++++++-----------
> ----
> > arch/arm/plat-omap/include/plat/control.h | 2 +
> > 2 files changed, 189 insertions(+), 190 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
> omap2/sleep34xx.S
> > index ba53191..734f82a
> > --- a/arch/arm/mach-omap2/sleep34xx.S
> > +++ b/arch/arm/mach-omap2/sleep34xx.S
> > @@ -33,17 +33,20 @@
> > #include "prm.h"
> > #include "sdrc.h"
> >
> > -#define SDRC_SCRATCHPAD_SEM_V 0xfa00291c
> > +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc
> > +#define SDRC_SCRATCHPAD_SEM_V OMAP343X_SCRATCHPAD_REGADDR \
> > + (SDRC_SCRATCHPAD_SEM_OFFS)
> >
> > #define PM_PREPWSTST_CORE_V OMAP34XX_PRM_REGADDR(CORE_MOD, \
> > - OMAP3430_PM_PREPWSTST)
> > -#define PM_PREPWSTST_CORE_P 0x48306AE8
> > + OMAP3430_PM_PREPWSTST)
> > +#define PM_PREPWSTST_CORE_P OMAP3430_PRM_BASE + CORE_MOD + \
> > + OMAP3430_PM_PREPWSTST
> > #define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \
> > OMAP3430_PM_PREPWSTST)
> > #define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD +
> OMAP2_PM_PWSTCTRL
> > #define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD,
> CM_IDLEST1)
> > -#define SRAM_BASE_P 0x40200000
> > -#define CONTROL_STAT 0x480022F0
> > +#define SRAM_BASE_P 0x40200000
> > +#define CONTROL_STAT OMAP343X_CTRL_BASE +
> OMAP343X_CONTROL_STATUS
> > #define SCRATCHPAD_MEM_OFFS 0x310 /* Move this as correct place is
> > * available */
> > #define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE +
> OMAP343X_CONTROL_MEM_WKUP\
> > @@ -184,29 +187,16 @@ api_params:
> > ENTRY(save_secure_ram_context_sz)
> > .word . - save_secure_ram_context
> >
> > -/*
> > - * Forces OMAP into idle state
> > - *
> > - * omap34xx_suspend() - This bit of code just executes the WFI
> > - * for normal idles.
> > - *
> > - * Note: This code get's copied to internal SRAM at boot. When the OMAP
> > - * wakes up it continues execution at the point it went to sleep.
> > - */
> > -ENTRY(omap34xx_cpu_suspend)
> > +/* Function to execute WFI. When the MPU wakes up from retention
> > + * or inactive mode, it continues execution just after wfi */
>
> fix multi-line comment style
>
> > +ENTRY(omap34xx_do_wfi)
> > stmfd sp!, {r0-r12, lr} @ save registers on stack
> > -loop:
> > - /*b loop*/ @Enable to debug by stepping through code
> > - /* r0 contains restore pointer in sdram */
> > - /* r1 contains information about saving context */
> > +
> > ldr r4, sdrc_power @ read the SDRC_POWER register
> > ldr r5, [r4] @ read the contents of SDRC_POWER
> > orr r5, r5, #0x40 @ enable self refresh on idle req
> > str r5, [r4] @ write back to SDRC_POWER register
> >
> > - cmp r1, #0x0
> > - /* If context save is required, do that and execute wfi */
> > - bne save_context_wfi
> > /* Data memory barrier and Data sync barrier */
> > mov r1, #0
> > mcr p15, 0, r1, c7, c10, 4
> > @@ -225,8 +215,182 @@ loop:
> > nop
> > nop
> > bl wait_sdrc_ok
> > + ldmfd sp!, {r0-r12, pc} @ restore regs and return
> > +
> > +/*
> > + * Forces OMAP into idle state
> > + *
> > + * omap34xx_cpu_suspend() - This bit of code just executes the WFI
> > + * for normal idles and saves the context before WFI on off modes.
> > + *
> > + */
> > +
> > +ENTRY(omap34xx_cpu_suspend)
> > + stmfd sp!, {r0-r12, lr} @ save registers on stack
> > +loop:
> > + /*b loop*/ @Enable to debug by stepping through code
> > + /* r0 contains restore pointer in sdram */
> > + /* r1 contains information about saving context */
> > +
> > + cmp r1, #0x0
> > + /* If context save is required, do that and execute wfi */
> > + bne save_context_wfi
> > + bl omap34xx_do_wfi
> >
> > ldmfd sp!, {r0-r12, pc} @ restore regs and return
> > +
> > +save_context_wfi:
> > + /*b save_context_wfi*/ @ enable to debug save code
> > + mov r8, r0 /* Store SDRAM address in r8 */
> > + mrc p15, 0, r5, c1, c0, 1 @ Read Auxiliary Control Register
> > + mov r4, #0x1 @ Number of parameters for restore call
> > + stmia r8!, {r4-r5} @ Push parameters for restore call
> > + mrc p15, 1, r5, c9, c0, 2 @ Read L2 AUX ctrl register
> > + stmia r8!, {r4-r5} @ Push parameters for restore call
> > + /* Check what that target sleep state is:stored in r1*/
> > + /* 1 - Only L1 and logic lost */
> > + /* 2 - Only L2 lost */
> > + /* 3 - Both L1 and L2 lost */
> > + cmp r1, #0x2 /* Only L2 lost */
> > + beq clean_l2
> > + cmp r1, #0x1 /* L2 retained */
> > + /* r9 stores whether to clean L2 or not*/
> > + moveq r9, #0x0 /* Dont Clean L2 */
> > + movne r9, #0x1 /* Clean L2 */
> > +l1_logic_lost:
> > + /* Store sp and spsr to SDRAM */
> > + mov r4, sp
> > + mrs r5, spsr
> > + mov r6, lr
> > + stmia r8!, {r4-r6}
> > + /* Save all ARM registers */
> > + /* Coprocessor access control register */
> > + mrc p15, 0, r6, c1, c0, 2
> > + stmia r8!, {r6}
> > + /* TTBR0, TTBR1 and Translation table base control */
> > + mrc p15, 0, r4, c2, c0, 0
> > + mrc p15, 0, r5, c2, c0, 1
> > + mrc p15, 0, r6, c2, c0, 2
> > + stmia r8!, {r4-r6}
> > + /* Domain access control register, data fault status register,
> > + and instruction fault status register */
> > + mrc p15, 0, r4, c3, c0, 0
> > + mrc p15, 0, r5, c5, c0, 0
> > + mrc p15, 0, r6, c5, c0, 1
> > + stmia r8!, {r4-r6}
> > + /* Data aux fault status register, instruction aux fault status,
> > + datat fault address register and instruction fault address register*/
> > + mrc p15, 0, r4, c5, c1, 0
> > + mrc p15, 0, r5, c5, c1, 1
> > + mrc p15, 0, r6, c6, c0, 0
> > + mrc p15, 0, r7, c6, c0, 2
> > + stmia r8!, {r4-r7}
> > + /* user r/w thread and process ID, user r/o thread and process ID,
> > + priv only thread and process ID, cache size selection */
> > + mrc p15, 0, r4, c13, c0, 2
> > + mrc p15, 0, r5, c13, c0, 3
> > + mrc p15, 0, r6, c13, c0, 4
> > + mrc p15, 2, r7, c0, c0, 0
> > + stmia r8!, {r4-r7}
> > + /* Data TLB lockdown, instruction TLB lockdown registers */
> > + mrc p15, 0, r5, c10, c0, 0
> > + mrc p15, 0, r6, c10, c0, 1
> > + stmia r8!, {r5-r6}
> > + /* Secure or non secure vector base address, FCSE PID, Context PID*/
> > + mrc p15, 0, r4, c12, c0, 0
> > + mrc p15, 0, r5, c13, c0, 0
> > + mrc p15, 0, r6, c13, c0, 1
> > + stmia r8!, {r4-r6}
> > + /* Primary remap, normal remap registers */
> > + mrc p15, 0, r4, c10, c2, 0
> > + mrc p15, 0, r5, c10, c2, 1
> > + stmia r8!,{r4-r5}
> > +
> > + /* Store current cpsr*/
> > + mrs r2, cpsr
> > + stmia r8!, {r2}
> > +
> > + mrc p15, 0, r4, c1, c0, 0
> > + /* save control register */
> > + stmia r8!, {r4}
> > +clean_caches:
> > + /* Clean Data or unified cache to POU*/
> > + /* How to invalidate only L1 cache???? - #FIX_ME# */
> > + /* mcr p15, 0, r11, c7, c11, 1 */
> > + cmp r9, #1 /* Check whether L2 inval is required or not*/
> > + bne skip_l2_inval
> > +clean_l2:
> > + /* read clidr */
> > + mrc p15, 1, r0, c0, c0, 1
> > + /* extract loc from clidr */
> > + ands r3, r0, #0x7000000
> > + /* left align loc bit field */
> > + mov r3, r3, lsr #23
> > + /* if loc is 0, then no need to clean */
> > + beq finished
> > + /* start clean at cache level 0 */
> > + mov r10, #0
> > +loop1:
> > + /* work out 3x current cache level */
> > + add r2, r10, r10, lsr #1
> > + /* extract cache type bits from clidr*/
> > + mov r1, r0, lsr r2
> > + /* mask of the bits for current cache only */
> > + and r1, r1, #7
> > + /* see what cache we have at this level */
> > + cmp r1, #2
> > + /* skip if no cache, or just i-cache */
> > + blt skip
> > + /* select current cache level in cssr */
> > + mcr p15, 2, r10, c0, c0, 0
> > + /* isb to sych the new cssr&csidr */
> > + isb
> > + /* read the new csidr */
> > + mrc p15, 1, r1, c0, c0, 0
> > + /* extract the length of the cache lines */
> > + and r2, r1, #7
> > + /* add 4 (line length offset) */
> > + add r2, r2, #4
> > + ldr r4, assoc_mask
> > + /* find maximum number on the way size */
> > + ands r4, r4, r1, lsr #3
> > + /* find bit position of way size increment */
> > + clz r5, r4
> > + ldr r7, numset_mask
> > + /* extract max number of the index size*/
> > + ands r7, r7, r1, lsr #13
> > +loop2:
> > + mov r9, r4
> > + /* create working copy of max way size*/
> > +loop3:
> > + /* factor way and cache number into r11 */
> > + orr r11, r10, r9, lsl r5
> > + /* factor index number into r11 */
> > + orr r11, r11, r7, lsl r2
> > + /*clean & invalidate by set/way */
> > + mcr p15, 0, r11, c7, c10, 2
> > + /* decrement the way*/
> > + subs r9, r9, #1
> > + bge loop3
> > + /*decrement the index */
> > + subs r7, r7, #1
> > + bge loop2
> > +skip:
> > + add r10, r10, #2
> > + /* increment cache number */
> > + cmp r3, r10
> > + bgt loop1
> > +finished:
> > + /*swith back to cache level 0 */
> > + mov r10, #0
> > + /* select current cache level in cssr */
> > + mcr p15, 2, r10, c0, c0, 0
> > + isb
> > +skip_l2_inval:
> > + bl omap34xx_do_wfi
> > + ldmfd sp!, {r0-r12, pc}
> > +
> > +/* This is where ROM code jumps when MPU comes out of off mode */
> > restore_es3:
> > /*b restore_es3*/ @ Enable to debug restore code
> > ldr r5, pm_prepwstst_core_p
> > @@ -437,175 +601,8 @@ usettbr0:
> > ldr r2, cache_pred_disable_mask
> > and r4, r2
> > mcr p15, 0, r4, c1, c0, 0
> > -
> > ldmfd sp!, {r0-r12, pc} @ restore regs and return
> > -save_context_wfi:
> > - /*b save_context_wfi*/ @ enable to debug save code
> > - mov r8, r0 /* Store SDRAM address in r8 */
> > - mrc p15, 0, r5, c1, c0, 1 @ Read Auxiliary Control Register
> > - mov r4, #0x1 @ Number of parameters for restore call
> > - stmia r8!, {r4-r5} @ Push parameters for restore call
> > - mrc p15, 1, r5, c9, c0, 2 @ Read L2 AUX ctrl register
> > - stmia r8!, {r4-r5} @ Push parameters for restore call
> > - /* Check what that target sleep state is:stored in r1*/
> > - /* 1 - Only L1 and logic lost */
> > - /* 2 - Only L2 lost */
> > - /* 3 - Both L1 and L2 lost */
> > - cmp r1, #0x2 /* Only L2 lost */
> > - beq clean_l2
> > - cmp r1, #0x1 /* L2 retained */
> > - /* r9 stores whether to clean L2 or not*/
> > - moveq r9, #0x0 /* Dont Clean L2 */
> > - movne r9, #0x1 /* Clean L2 */
> > -l1_logic_lost:
> > - /* Store sp and spsr to SDRAM */
> > - mov r4, sp
> > - mrs r5, spsr
> > - mov r6, lr
> > - stmia r8!, {r4-r6}
> > - /* Save all ARM registers */
> > - /* Coprocessor access control register */
> > - mrc p15, 0, r6, c1, c0, 2
> > - stmia r8!, {r6}
> > - /* TTBR0, TTBR1 and Translation table base control */
> > - mrc p15, 0, r4, c2, c0, 0
> > - mrc p15, 0, r5, c2, c0, 1
> > - mrc p15, 0, r6, c2, c0, 2
> > - stmia r8!, {r4-r6}
> > - /* Domain access control register, data fault status register,
> > - and instruction fault status register */
> > - mrc p15, 0, r4, c3, c0, 0
> > - mrc p15, 0, r5, c5, c0, 0
> > - mrc p15, 0, r6, c5, c0, 1
> > - stmia r8!, {r4-r6}
> > - /* Data aux fault status register, instruction aux fault status,
> > - datat fault address register and instruction fault address register*/
> > - mrc p15, 0, r4, c5, c1, 0
> > - mrc p15, 0, r5, c5, c1, 1
> > - mrc p15, 0, r6, c6, c0, 0
> > - mrc p15, 0, r7, c6, c0, 2
> > - stmia r8!, {r4-r7}
> > - /* user r/w thread and process ID, user r/o thread and process ID,
> > - priv only thread and process ID, cache size selection */
> > - mrc p15, 0, r4, c13, c0, 2
> > - mrc p15, 0, r5, c13, c0, 3
> > - mrc p15, 0, r6, c13, c0, 4
> > - mrc p15, 2, r7, c0, c0, 0
> > - stmia r8!, {r4-r7}
> > - /* Data TLB lockdown, instruction TLB lockdown registers */
> > - mrc p15, 0, r5, c10, c0, 0
> > - mrc p15, 0, r6, c10, c0, 1
> > - stmia r8!, {r5-r6}
> > - /* Secure or non secure vector base address, FCSE PID, Context PID*/
> > - mrc p15, 0, r4, c12, c0, 0
> > - mrc p15, 0, r5, c13, c0, 0
> > - mrc p15, 0, r6, c13, c0, 1
> > - stmia r8!, {r4-r6}
> > - /* Primary remap, normal remap registers */
> > - mrc p15, 0, r4, c10, c2, 0
> > - mrc p15, 0, r5, c10, c2, 1
> > - stmia r8!,{r4-r5}
> > -
> > - /* Store current cpsr*/
> > - mrs r2, cpsr
> > - stmia r8!, {r2}
> >
> > - mrc p15, 0, r4, c1, c0, 0
> > - /* save control register */
> > - stmia r8!, {r4}
> > -clean_caches:
> > - /* Clean Data or unified cache to POU*/
> > - /* How to invalidate only L1 cache???? - #FIX_ME# */
> > - /* mcr p15, 0, r11, c7, c11, 1 */
> > - cmp r9, #1 /* Check whether L2 inval is required or not*/
> > - bne skip_l2_inval
> > -clean_l2:
> > - /* read clidr */
> > - mrc p15, 1, r0, c0, c0, 1
> > - /* extract loc from clidr */
> > - ands r3, r0, #0x7000000
> > - /* left align loc bit field */
> > - mov r3, r3, lsr #23
> > - /* if loc is 0, then no need to clean */
> > - beq finished
> > - /* start clean at cache level 0 */
> > - mov r10, #0
> > -loop1:
> > - /* work out 3x current cache level */
> > - add r2, r10, r10, lsr #1
> > - /* extract cache type bits from clidr*/
> > - mov r1, r0, lsr r2
> > - /* mask of the bits for current cache only */
> > - and r1, r1, #7
> > - /* see what cache we have at this level */
> > - cmp r1, #2
> > - /* skip if no cache, or just i-cache */
> > - blt skip
> > - /* select current cache level in cssr */
> > - mcr p15, 2, r10, c0, c0, 0
> > - /* isb to sych the new cssr&csidr */
> > - isb
> > - /* read the new csidr */
> > - mrc p15, 1, r1, c0, c0, 0
> > - /* extract the length of the cache lines */
> > - and r2, r1, #7
> > - /* add 4 (line length offset) */
> > - add r2, r2, #4
> > - ldr r4, assoc_mask
> > - /* find maximum number on the way size */
> > - ands r4, r4, r1, lsr #3
> > - /* find bit position of way size increment */
> > - clz r5, r4
> > - ldr r7, numset_mask
> > - /* extract max number of the index size*/
> > - ands r7, r7, r1, lsr #13
> > -loop2:
> > - mov r9, r4
> > - /* create working copy of max way size*/
> > -loop3:
> > - /* factor way and cache number into r11 */
> > - orr r11, r10, r9, lsl r5
> > - /* factor index number into r11 */
> > - orr r11, r11, r7, lsl r2
> > - /*clean & invalidate by set/way */
> > - mcr p15, 0, r11, c7, c10, 2
> > - /* decrement the way*/
> > - subs r9, r9, #1
> > - bge loop3
> > - /*decrement the index */
> > - subs r7, r7, #1
> > - bge loop2
> > -skip:
> > - add r10, r10, #2
> > - /* increment cache number */
> > - cmp r3, r10
> > - bgt loop1
> > -finished:
> > - /*swith back to cache level 0 */
> > - mov r10, #0
> > - /* select current cache level in cssr */
> > - mcr p15, 2, r10, c0, c0, 0
> > - isb
> > -skip_l2_inval:
> > - /* Data memory barrier and Data sync barrier */
> > - mov r1, #0
> > - mcr p15, 0, r1, c7, c10, 4
> > - mcr p15, 0, r1, c7, c10, 5
> > -
> > - wfi @ wait for interrupt
> > - nop
> > - nop
> > - nop
> > - nop
> > - nop
> > - nop
> > - nop
> > - nop
> > - nop
> > - nop
> > - bl wait_sdrc_ok
> > - /* restore regs and return */
> > - ldmfd sp!, {r0-r12, pc}
> >
> > /* Make sure SDRC accesses are ok */
> > wait_sdrc_ok:
> > @@ -669,4 +666,4 @@ cache_pred_disable_mask:
> > control_stat:
> > .word CONTROL_STAT
> > ENTRY(omap34xx_cpu_suspend_sz)
> > - .word . - omap34xx_cpu_suspend
> > + .word . - omap34xx_cpu_suspend
> > diff --git a/arch/arm/plat-omap/include/plat/control.h b/arch/arm/plat-
> omap/include/plat/control.h
> > index 46e166d..306259e 100644
> > --- a/arch/arm/plat-omap/include/plat/control.h
> > +++ b/arch/arm/plat-omap/include/plat/control.h
> > @@ -314,6 +314,8 @@
> > #define OMAP343X_SCRATCHPAD_ROM (OMAP343X_CTRL_BASE +
> 0x860)
> > #define OMAP343X_SCRATCHPAD (OMAP343X_CTRL_BASE + 0x910)
> > #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C
> > +#define OMAP343X_SCRATCHPAD_REGADDR(reg) \
> > + OMAP2_L4_IO_ADDRESS(OMAP343X_SCRATCHPAD + reg)
> >
> > /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */
> > #define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 2/2] OMAP3 PM: sleep code clean up
2010-10-04 8:44 ` Sripathy, Vishwanath
@ 2010-10-04 8:56 ` Amit Kucheria
2010-10-04 9:36 ` Shilimkar, Santosh
0 siblings, 1 reply; 37+ messages in thread
From: Amit Kucheria @ 2010-10-04 8:56 UTC (permalink / raw)
To: Sripathy, Vishwanath
Cc: Kevin Hilman, linux-omap@vger.kernel.org,
linaro-dev@lists.linaro.org
On 10 Oct 04, Sripathy, Vishwanath wrote:
> Kevin,
[snip]
> >
> > But this also makes me wonder, if we're going to clean this up, the bulk
> > of it could be re-written in C, with some inline asm helpers as needed.
> Probably yes. But as this code is specific to OMAP3, do you think it's
> worth spending time on rewriting the entire code in C? It might be a
> significant effort and it will not be reusable for other ARM SOCs.
The C code will be more maintainable and offer more opportunities to
refactor across OMAP flavours - perhaps OMAP4 as well.
I'm also interested in code reuse across other SoCs. We've got to be able to
shut down the ARM core using common code instead of each SoC copying buggy
code from each other. Could you list reasons why you don't think the code is
re-usable?
Regards,
Amit
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 2/2] OMAP3 PM: sleep code clean up
2010-10-04 8:56 ` Amit Kucheria
@ 2010-10-04 9:36 ` Shilimkar, Santosh
0 siblings, 0 replies; 37+ messages in thread
From: Shilimkar, Santosh @ 2010-10-04 9:36 UTC (permalink / raw)
To: Amit Kucheria, Sripathy, Vishwanath
Cc: Kevin Hilman, linux-omap@vger.kernel.org,
linaro-dev@lists.linaro.org
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Amit Kucheria
> Sent: Monday, October 04, 2010 2:27 PM
> To: Sripathy, Vishwanath
> Cc: Kevin Hilman; linux-omap@vger.kernel.org; linaro-dev@lists.linaro.org
> Subject: Re: [PATCH 2/2] OMAP3 PM: sleep code clean up
>
> On 10 Oct 04, Sripathy, Vishwanath wrote:
> > Kevin,
>
> [snip]
>
> > >
> > > But this also makes me wonder, if we're going to clean this up, the
> bulk
> > > of it could be re-written in C, with some inline asm helpers as needed.
> > Probably yes. But as this code is specific to OMAP3, do you think it's
> > worth spending time on rewriting the entire code in C? It might be a
> > significant effort and it will not be reusable for other ARM SOCs.
>
> The C code will be more maintainable and offer more opportunities to
> refactor across OMAP flavours - perhaps OMAP4 as well.
>
> I'm also interested in code reuse across other SoCs. We've got to be able
> to
> shut down the ARM core using common code instead of each SoC copying buggy
> code from each other. Could you list reasons why you don't think the code
> is
> re-usable?
Trust zone implementation and it's varients
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 14:51 OMAP3 sleep code clean-up Jean Pihet
@ 2010-11-18 14:51 ` Jean Pihet
2010-11-18 14:57 ` Nishanth Menon
0 siblings, 1 reply; 37+ messages in thread
From: Jean Pihet @ 2010-11-18 14:51 UTC (permalink / raw)
To: linux-omap; +Cc: Vishwanath BS, Kevin Hillman, Jean Pihet
From: Vishwanath BS <vishwanath.bs@ti.com>
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available for other uses.
Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
with full RET and OFF modes.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Cc: Kevin Hillman <khilman@deeprootsystems.com>
Changed the commit comments.
Cc: Jean Pihet <j-pihet@ti.com>
---
arch/arm/mach-omap2/pm34xx.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..035ca47 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -65,8 +65,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -346,9 +344,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -422,7 +417,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
/* Restore normal SDRC POWER settings */
@@ -972,8 +967,6 @@ static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
1.7.2.3
^ permalink raw reply related [flat|nested] 37+ messages in thread
* RE: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 14:51 ` [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr Jean Pihet
@ 2010-11-18 14:57 ` Nishanth Menon
2010-11-18 15:08 ` Sripathy, Vishwanath
2010-11-18 15:52 ` Kevin Hilman
0 siblings, 2 replies; 37+ messages in thread
From: Nishanth Menon @ 2010-11-18 14:57 UTC (permalink / raw)
To: Jean Pihet, linux-omap; +Cc: Vishwanath Sripathy, Kevin Hillman, Jean Pihet-XID
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Jean Pihet
> Sent: Thursday, November 18, 2010 8:52 AM
> To: linux-omap@vger.kernel.org
> Cc: Vishwanath BS; Kevin Hillman; Jean Pihet
> Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
>
> From: Vishwanath BS <vishwanath.bs@ti.com>
>
> For historical reasons the OMAP3 sleep code is run from SRAM.
> This code can run from DDR which provides better performance and
> leaves the SRAM available for other uses.
>
> Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
> with full RET and OFF modes.
Sorry, But I disagree with this patch.
There is a silicon errata which cannot be handled with this - RTA disable
- errata i608
You need to disable RTA while coming out of OFF - we cannot handle this on
GP devices if this is not done.
>
> Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
> Cc: Kevin Hillman <khilman@deeprootsystems.com>
>
> Changed the commit comments.
>
> Cc: Jean Pihet <j-pihet@ti.com>
> ---
> arch/arm/mach-omap2/pm34xx.c | 9 +--------
> 1 files changed, 1 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 75c0cd1..035ca47 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -65,8 +65,6 @@ struct power_state {
>
> static LIST_HEAD(pwrst_list);
>
> -static void (*_omap_sram_idle)(u32 *addr, int save_state);
> -
> static int (*_omap_save_secure_sram)(u32 *addr);
>
> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> @@ -346,9 +344,6 @@ void omap_sram_idle(void)
> int core_prev_state, per_prev_state;
> u32 sdrc_pwr = 0;
>
> - if (!_omap_sram_idle)
> - return;
> -
> pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
> pwrdm_clear_all_prev_pwrst(neon_pwrdm);
> pwrdm_clear_all_prev_pwrst(core_pwrdm);
> @@ -422,7 +417,7 @@ void omap_sram_idle(void)
> * get saved. The restore path then reads from this
> * location and restores them back.
> */
> - _omap_sram_idle(omap3_arm_context, save_state);
> + omap34xx_cpu_suspend(omap3_arm_context, save_state);
> cpu_init();
>
> /* Restore normal SDRC POWER settings */
> @@ -972,8 +967,6 @@ static int __init clkdms_setup(struct clockdomain
> *clkdm, void *unused)
>
> void omap_push_sram_idle(void)
> {
> - _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
> - omap34xx_cpu_suspend_sz);
> if (omap_type() != OMAP2_DEVICE_TYPE_GP)
> _omap_save_secure_sram =
> omap_sram_push(save_secure_ram_context,
> save_secure_ram_context_sz);
> --
> 1.7.2.3
>
> --
> 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 14:57 ` Nishanth Menon
@ 2010-11-18 15:08 ` Sripathy, Vishwanath
2010-11-18 15:11 ` Nishanth Menon
2010-11-18 15:52 ` Kevin Hilman
1 sibling, 1 reply; 37+ messages in thread
From: Sripathy, Vishwanath @ 2010-11-18 15:08 UTC (permalink / raw)
To: Nishanth Menon; +Cc: Jean Pihet, linux-omap, Kevin Hillman, Jean Pihet-XID
NIshant,
On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon <nm@ti.com> wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of Jean Pihet
>> Sent: Thursday, November 18, 2010 8:52 AM
>> To: linux-omap@vger.kernel.org
>> Cc: Vishwanath BS; Kevin Hillman; Jean Pihet
>> Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
>>
>> From: Vishwanath BS <vishwanath.bs@ti.com>
>>
>> For historical reasons the OMAP3 sleep code is run from SRAM.
>> This code can run from DDR which provides better performance and
>> leaves the SRAM available for other uses.
>>
>> Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
>> with full RET and OFF modes.
>
> Sorry, But I disagree with this patch.
>
> There is a silicon errata which cannot be handled with this - RTA disable
> - errata i608
>
> You need to disable RTA while coming out of OFF - we cannot handle this on
>
> GP devices if this is not done.
When you come out of Core off, SRAM contents are anyway lost. So you
have to run from DDR after ROM Code completes. This behavior has not
changed with this patch. I fail to understand your concern here.
Vishwa
>
>>
>> Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
>> Cc: Kevin Hillman <khilman@deeprootsystems.com>
>>
>> Changed the commit comments.
>>
>> Cc: Jean Pihet <j-pihet@ti.com>
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 9 +--------
>> 1 files changed, 1 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index 75c0cd1..035ca47 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -65,8 +65,6 @@ struct power_state {
>>
>> static LIST_HEAD(pwrst_list);
>>
>> -static void (*_omap_sram_idle)(u32 *addr, int save_state);
>> -
>> static int (*_omap_save_secure_sram)(u32 *addr);
>>
>> static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
>> @@ -346,9 +344,6 @@ void omap_sram_idle(void)
>> int core_prev_state, per_prev_state;
>> u32 sdrc_pwr = 0;
>>
>> - if (!_omap_sram_idle)
>> - return;
>> -
>> pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
>> pwrdm_clear_all_prev_pwrst(neon_pwrdm);
>> pwrdm_clear_all_prev_pwrst(core_pwrdm);
>> @@ -422,7 +417,7 @@ void omap_sram_idle(void)
>> * get saved. The restore path then reads from this
>> * location and restores them back.
>> */
>> - _omap_sram_idle(omap3_arm_context, save_state);
>> + omap34xx_cpu_suspend(omap3_arm_context, save_state);
>> cpu_init();
>>
>> /* Restore normal SDRC POWER settings */
>> @@ -972,8 +967,6 @@ static int __init clkdms_setup(struct clockdomain
>> *clkdm, void *unused)
>>
>> void omap_push_sram_idle(void)
>> {
>> - _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
>> - omap34xx_cpu_suspend_sz);
>> if (omap_type() != OMAP2_DEVICE_TYPE_GP)
>> _omap_save_secure_sram =
>> omap_sram_push(save_secure_ram_context,
>> save_secure_ram_context_sz);
>> --
>> 1.7.2.3
>>
>> --
>> 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
>
--
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 15:08 ` Sripathy, Vishwanath
@ 2010-11-18 15:11 ` Nishanth Menon
2010-11-18 15:15 ` Jean Pihet
0 siblings, 1 reply; 37+ messages in thread
From: Nishanth Menon @ 2010-11-18 15:11 UTC (permalink / raw)
To: Vishwanath Sripathy; +Cc: Jean Pihet, linux-omap, Kevin Hillman, Jean Pihet-XID
> -----Original Message-----
> From: Sripathy, Vishwanath [mailto:vishwanath.bs@ti.com]
> Sent: Thursday, November 18, 2010 9:09 AM
> To: Nishanth Menon
> Cc: Jean Pihet; linux-omap@vger.kernel.org; Kevin Hillman; Jean
Pihet-XID
> Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
>
> NIshant,
>
> On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon <nm@ti.com> wrote:
> >> -----Original Message-----
> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> owner@vger.kernel.org] On Behalf Of Jean Pihet
> >> Sent: Thursday, November 18, 2010 8:52 AM
> >> To: linux-omap@vger.kernel.org
> >> Cc: Vishwanath BS; Kevin Hillman; Jean Pihet
> >> Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
> >>
> >> From: Vishwanath BS <vishwanath.bs@ti.com>
> >>
> >> For historical reasons the OMAP3 sleep code is run from SRAM.
> >> This code can run from DDR which provides better performance and
> >> leaves the SRAM available for other uses.
> >>
> >> Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
> >> with full RET and OFF modes.
> >
> > Sorry, But I disagree with this patch.
> >
> > There is a silicon errata which cannot be handled with this - RTA
> disable
> > - errata i608
> >
> > You need to disable RTA while coming out of OFF - we cannot handle
this
> on
> >
> > GP devices if this is not done.
> When you come out of Core off, SRAM contents are anyway lost. So you
> have to run from DDR after ROM Code completes. This behavior has not
> changed with this patch. I fail to understand your concern here.
I could potentially be mistaken. Let me do one thing - I will post out the
patches that I have to the list and we can see how this all works
together.
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 15:11 ` Nishanth Menon
@ 2010-11-18 15:15 ` Jean Pihet
2010-11-18 15:33 ` Nishanth Menon
0 siblings, 1 reply; 37+ messages in thread
From: Jean Pihet @ 2010-11-18 15:15 UTC (permalink / raw)
To: Nishanth Menon
Cc: Vishwanath Sripathy, linux-omap, Kevin Hillman, Jean Pihet-XID
Hi Nishant,
On Thu, Nov 18, 2010 at 4:11 PM, Nishanth Menon <nm@ti.com> wrote:
>> -----Original Message-----
>> From: Sripathy, Vishwanath [mailto:vishwanath.bs@ti.com]
>> Sent: Thursday, November 18, 2010 9:09 AM
>> To: Nishanth Menon
>> Cc: Jean Pihet; linux-omap@vger.kernel.org; Kevin Hillman; Jean
> Pihet-XID
>> Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
>>
>> NIshant,
>>
>> On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon <nm@ti.com> wrote:
>> >> -----Original Message-----
>> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> >> owner@vger.kernel.org] On Behalf Of Jean Pihet
>> >> Sent: Thursday, November 18, 2010 8:52 AM
>> >> To: linux-omap@vger.kernel.org
>> >> Cc: Vishwanath BS; Kevin Hillman; Jean Pihet
>> >> Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
>> >>
>> >> From: Vishwanath BS <vishwanath.bs@ti.com>
>> >>
>> >> For historical reasons the OMAP3 sleep code is run from SRAM.
>> >> This code can run from DDR which provides better performance and
>> >> leaves the SRAM available for other uses.
>> >>
>> >> Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
>> >> with full RET and OFF modes.
>> >
>> > Sorry, But I disagree with this patch.
>> >
>> > There is a silicon errata which cannot be handled with this - RTA
>> disable
>> > - errata i608
>> >
>> > You need to disable RTA while coming out of OFF - we cannot handle
> this
>> on
>> >
>> > GP devices if this is not done.
>> When you come out of Core off, SRAM contents are anyway lost. So you
>> have to run from DDR after ROM Code completes. This behavior has not
>> changed with this patch. I fail to understand your concern here.
> I could potentially be mistaken. Let me do one thing - I will post out the
>
> patches that I have to the list and we can see how this all works
> together
Ok, fine.
I did not find any 36xx specific workaround for the errata i608 issue.
Is there one already available?
Thanks,
Jean
>
> Regards,
> Nishanth Menon
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 15:15 ` Jean Pihet
@ 2010-11-18 15:33 ` Nishanth Menon
0 siblings, 0 replies; 37+ messages in thread
From: Nishanth Menon @ 2010-11-18 15:33 UTC (permalink / raw)
To: Jean Pihet; +Cc: Vishwanath Sripathy, linux-omap, Kevin Hillman, Jean Pihet-XID
> -----Original Message-----
> From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
> Sent: Thursday, November 18, 2010 9:15 AM
[...]
> >> >>
> >> >> Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
> >> >> with full RET and OFF modes.
> >> >
> >> > Sorry, But I disagree with this patch.
> >> >
> >> > There is a silicon errata which cannot be handled with this - RTA
> >> disable
> >> > - errata i608
> >> >
> >> > You need to disable RTA while coming out of OFF - we cannot handle
> > this
> >> on
> >> >
> >> > GP devices if this is not done.
> >> When you come out of Core off, SRAM contents are anyway lost. So you
> >> have to run from DDR after ROM Code completes. This behavior has not
> >> changed with this patch. I fail to understand your concern here.
> > I could potentially be mistaken. Let me do one thing - I will post out
> the
> >
> > patches that I have to the list and we can see how this all works
> > together
> Ok, fine.
> I did not find any 36xx specific workaround for the errata i608 issue.
> Is there one already available?
Yes, I have a series of patches addressing that as well.. hoping to test
On EMU/HS devices prior to posting - GP devices (3430/3630) tested.
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 14:57 ` Nishanth Menon
2010-11-18 15:08 ` Sripathy, Vishwanath
@ 2010-11-18 15:52 ` Kevin Hilman
2010-11-18 16:55 ` Nishanth Menon
1 sibling, 1 reply; 37+ messages in thread
From: Kevin Hilman @ 2010-11-18 15:52 UTC (permalink / raw)
To: Nishanth Menon
Cc: Jean Pihet, linux-omap, Vishwanath Sripathy, Jean Pihet-XID
Nishanth Menon <nm@ti.com> writes:
>> From: Vishwanath BS <vishwanath.bs@ti.com>
>>
>> For historical reasons the OMAP3 sleep code is run from SRAM.
>> This code can run from DDR which provides better performance and
>> leaves the SRAM available for other uses.
>>
>> Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
>> with full RET and OFF modes.
>
> Sorry, But I disagree with this patch.
>
> There is a silicon errata which cannot be handled with this - RTA disable
> - errata i608
>
> You need to disable RTA while coming out of OFF - we cannot handle
> this on GP devices if this is not done.
You need to provide some more details here as to exactly why this patch
prevents the ability to do this workaround.
As Vishwa pointed out, when returning from OFF mode, current code
already starts in DDR since SRAM is lost. The current code also already
can jump back into SRAM for certain errata/fixup (c.f. es3_sdrc_fix in
current code.)
Kevin
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 15:52 ` Kevin Hilman
@ 2010-11-18 16:55 ` Nishanth Menon
2010-11-18 17:52 ` Tony Lindgren
0 siblings, 1 reply; 37+ messages in thread
From: Nishanth Menon @ 2010-11-18 16:55 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Jean Pihet, linux-omap, Vishwanath Sripathy, Jean Pihet-XID
Kevin Hilman had written, on 11/18/2010 09:52 AM, the following:
> Nishanth Menon <nm@ti.com> writes:
>
>>> From: Vishwanath BS <vishwanath.bs@ti.com>
>>>
>>> For historical reasons the OMAP3 sleep code is run from SRAM.
>>> This code can run from DDR which provides better performance and
>>> leaves the SRAM available for other uses.
>>>
>>> Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
>>> with full RET and OFF modes.
>> Sorry, But I disagree with this patch.
>>
>> There is a silicon errata which cannot be handled with this - RTA disable
>> - errata i608
>>
>> You need to disable RTA while coming out of OFF - we cannot handle
>> this on GP devices if this is not done.
>
> You need to provide some more details here as to exactly why this patch
> prevents the ability to do this workaround.
>
> As Vishwa pointed out, when returning from OFF mode, current code
> already starts in DDR since SRAM is lost. The current code also already
> can jump back into SRAM for certain errata/fixup (c.f. es3_sdrc_fix in
> current code.)
scratchpad_contents.public_restore_ptr -> this is the restore pointer
that is invoked when we get out of OFF mode.
-> on 3430 and 3630, I agree it in SDRAM, for es3_sdrc_fix, it
relocates the required code to sram as it cannot be run in ddr. - so I
believe no issues there.
But after wfi in wait_sdrc_ok as part of the code executing in SRAM
today omap34xx_cpu_suspend -> we are waiting for DPLL3 lock prior to
accessing DDR -> how do we execute that logic in SDRAM?
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 16:55 ` Nishanth Menon
@ 2010-11-18 17:52 ` Tony Lindgren
2010-11-18 18:13 ` Tony Lindgren
2010-11-18 18:15 ` Jean Pihet
0 siblings, 2 replies; 37+ messages in thread
From: Tony Lindgren @ 2010-11-18 17:52 UTC (permalink / raw)
To: Nishanth Menon
Cc: Kevin Hilman, Jean Pihet, linux-omap, Vishwanath Sripathy,
Jean Pihet-XID
* Nishanth Menon <nm@ti.com> [101118 08:46]:
>
> But after wfi in wait_sdrc_ok as part of the code executing in SRAM
> today omap34xx_cpu_suspend -> we are waiting for DPLL3 lock prior to
> accessing DDR -> how do we execute that logic in SDRAM?
I too am a bit concerned how this will all keep working. For light
testing it may be running OK if it happens to run from cache..
Also, moving the code out of SRAM will limit the options for what we
may need to do with DDR or L3.
Retention is something to consider, are there issues with that?
Regards,
Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 17:52 ` Tony Lindgren
@ 2010-11-18 18:13 ` Tony Lindgren
2010-11-18 18:15 ` Jean Pihet
1 sibling, 0 replies; 37+ messages in thread
From: Tony Lindgren @ 2010-11-18 18:13 UTC (permalink / raw)
To: Nishanth Menon
Cc: Kevin Hilman, Jean Pihet, linux-omap, Vishwanath Sripathy,
Jean Pihet-XID
* Tony Lindgren <tony@atomide.com> [101118 09:42]:
> * Nishanth Menon <nm@ti.com> [101118 08:46]:
> >
> > But after wfi in wait_sdrc_ok as part of the code executing in SRAM
> > today omap34xx_cpu_suspend -> we are waiting for DPLL3 lock prior to
> > accessing DDR -> how do we execute that logic in SDRAM?
>
> I too am a bit concerned how this will all keep working. For light
> testing it may be running OK if it happens to run from cache..
This in the retention case, in off-idle those should be powered down..
Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 17:52 ` Tony Lindgren
2010-11-18 18:13 ` Tony Lindgren
@ 2010-11-18 18:15 ` Jean Pihet
2010-11-18 18:27 ` Tony Lindgren
1 sibling, 1 reply; 37+ messages in thread
From: Jean Pihet @ 2010-11-18 18:15 UTC (permalink / raw)
To: Tony Lindgren
Cc: Nishanth Menon, Kevin Hilman, linux-omap, Vishwanath Sripathy,
Jean Pihet-XID
On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Nishanth Menon <nm@ti.com> [101118 08:46]:
>>
>> But after wfi in wait_sdrc_ok as part of the code executing in SRAM
>> today omap34xx_cpu_suspend -> we are waiting for DPLL3 lock prior to
>> accessing DDR -> how do we execute that logic in SDRAM?
> I too am a bit concerned how this will all keep working. For light
> testing it may be running OK if it happens to run from cache..
As Vishwa pointed out, when going out of OFF mode the SRAM and the
caches are lost.
That means the low power mode _has to_ rely on SDRAM at wake-up.
About the DPLL lock:
1) wait_sdrc_ok is only called when back from the non-OFF modes,
2) I checked that when running wait_sdrc_ok the CORE is already out of
idle and the DPLL is already locked. Note: l-o code has no support for
the voltages OFF and the external clocks OFF.
What to conclude from 1) and 2)? In my test setup ot looks like
wait_sdrc_ok is of no use, but I agree this a premature conclusion.
> Also, moving the code out of SRAM will limit the options for what we
> may need to do with DDR or L3.
What are the options? All the executable code runs from DDR anyway.
> Retention is something to consider, are there issues with that?
No issue so far. See the points 1) and 2) here above.
>
> Regards,
>
> Tony
>
Jean
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 18:15 ` Jean Pihet
@ 2010-11-18 18:27 ` Tony Lindgren
2010-11-18 18:34 ` Jean Pihet
0 siblings, 1 reply; 37+ messages in thread
From: Tony Lindgren @ 2010-11-18 18:27 UTC (permalink / raw)
To: Jean Pihet
Cc: Nishanth Menon, Kevin Hilman, linux-omap, Vishwanath Sripathy,
Jean Pihet-XID
* Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
>
> About the DPLL lock:
> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
> 2) I checked that when running wait_sdrc_ok the CORE is already out of
> idle and the DPLL is already locked. Note: l-o code has no support for
> the voltages OFF and the external clocks OFF.
>
> What to conclude from 1) and 2)? In my test setup ot looks like
> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
Yeah we should figure out in which cases wait_sdrc_ok is needed.
BTW, are you sure you're hitting core idle in your tests?
Regards,
Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 18:27 ` Tony Lindgren
@ 2010-11-18 18:34 ` Jean Pihet
2010-11-19 15:37 ` Jean Pihet
0 siblings, 1 reply; 37+ messages in thread
From: Jean Pihet @ 2010-11-18 18:34 UTC (permalink / raw)
To: Tony Lindgren
Cc: Nishanth Menon, Kevin Hilman, linux-omap, Vishwanath Sripathy,
Jean Pihet-XID
On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
>>
>> About the DPLL lock:
>> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
>> 2) I checked that when running wait_sdrc_ok the CORE is already out of
>> idle and the DPLL is already locked. Note: l-o code has no support for
>> the voltages OFF and the external clocks OFF.
>>
>> What to conclude from 1) and 2)? In my test setup ot looks like
>> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
>
> Yeah we should figure out in which cases wait_sdrc_ok is needed.
>
> BTW, are you sure you're hitting core idle in your tests?
Yes it is OK from the console messages and the counters values in
/debug/pm_debug/count.
Let me confirm asap with the PRCM registers dump.
>
> Regards,
>
> Tony
>
Thanks,
Jean
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-18 18:34 ` Jean Pihet
@ 2010-11-19 15:37 ` Jean Pihet
2010-11-19 16:09 ` Tony Lindgren
2010-11-19 16:14 ` Derrick, David
0 siblings, 2 replies; 37+ messages in thread
From: Jean Pihet @ 2010-11-19 15:37 UTC (permalink / raw)
To: Tony Lindgren
Cc: Nishanth Menon, Kevin Hilman, linux-omap, Vishwanath Sripathy,
Jean Pihet-XID
HI Tony,
On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
>> * Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>
>>> About the DPLL lock:
>>> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
>>> 2) I checked that when running wait_sdrc_ok the CORE is already out of
>>> idle and the DPLL is already locked. Note: l-o code has no support for
>>> the voltages OFF and the external clocks OFF.
>>>
>>> What to conclude from 1) and 2)? In my test setup ot looks like
>>> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
>>
>> Yeah we should figure out in which cases wait_sdrc_ok is needed.
>>
>> BTW, are you sure you're hitting core idle in your tests?
> Yes it is OK from the console messages and the counters values in
> /debug/pm_debug/count.
>
> Let me confirm asap with the PRCM registers dump.
Here is what I experimented:
1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases,
2) checked the real state entered in low power mode from the console
messages, the output of /debug/pm_debug/count and PRCM registers dump
2) is OK, which means that the RET and OFF modes are correctly hit.
Can I conclude from 1) that the wake-up code is not running from the
cache in RETention?
Thanks,
Jean
>
>>
>> Regards,
>>
>> Tony
>>
>
> Thanks,
> Jean
>
>>
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-19 15:37 ` Jean Pihet
@ 2010-11-19 16:09 ` Tony Lindgren
2010-11-19 16:14 ` Derrick, David
1 sibling, 0 replies; 37+ messages in thread
From: Tony Lindgren @ 2010-11-19 16:09 UTC (permalink / raw)
To: Jean Pihet
Cc: Nishanth Menon, Kevin Hilman, linux-omap, Vishwanath Sripathy,
Jean Pihet-XID
* Jean Pihet <jean.pihet@newoldbits.com> [101119 07:27]:
> HI Tony,
>
> On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> > On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> * Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
> >>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
> >>>
> >>> About the DPLL lock:
> >>> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
> >>> 2) I checked that when running wait_sdrc_ok the CORE is already out of
> >>> idle and the DPLL is already locked. Note: l-o code has no support for
> >>> the voltages OFF and the external clocks OFF.
> >>>
> >>> What to conclude from 1) and 2)? In my test setup ot looks like
> >>> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
> >>
> >> Yeah we should figure out in which cases wait_sdrc_ok is needed.
> >>
> >> BTW, are you sure you're hitting core idle in your tests?
> > Yes it is OK from the console messages and the counters values in
> > /debug/pm_debug/count.
> >
> > Let me confirm asap with the PRCM registers dump.
>
> Here is what I experimented:
> 1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all cases,
> 2) checked the real state entered in low power mode from the console
> messages, the output of /debug/pm_debug/count and PRCM registers dump
>
> 2) is OK, which means that the RET and OFF modes are correctly hit.
>
> Can I conclude from 1) that the wake-up code is not running from the
> cache in RETention?
Sounds pretty safe to me then, thanks for testing. Now we just have
to find out in which cases wait_sdrc_ok is needed..
Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-19 15:37 ` Jean Pihet
2010-11-19 16:09 ` Tony Lindgren
@ 2010-11-19 16:14 ` Derrick, David
2010-11-19 16:26 ` Jean Pihet
2010-11-22 10:07 ` Peter 'p2' De Schrijver
1 sibling, 2 replies; 37+ messages in thread
From: Derrick, David @ 2010-11-19 16:14 UTC (permalink / raw)
To: Jean Pihet, Tony Lindgren
Cc: Menon, Nishanth, Kevin Hilman, linux-omap@vger.kernel.org,
Sripathy, Vishwanath, Pihet-XID, Jean
>-----Original Message-----
>From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
>Sent: Friday, November 19, 2010 9:37 AM
>On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pihet@newoldbits.com> >wrote:
>> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> * Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
>>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>>
>>>> About the DPLL lock:
>>>> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
>>>> 2) I checked that when running wait_sdrc_ok the CORE is already out of
>>>> idle and the DPLL is already locked. Note: l-o code has no support for
>>>> the voltages OFF and the external clocks OFF.
>>>>
>>>> What to conclude from 1) and 2)? In my test setup ot looks like
>>>> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
>>>
>>> Yeah we should figure out in which cases wait_sdrc_ok is needed.
>>>
>>> BTW, are you sure you're hitting core idle in your tests?
>> Yes it is OK from the console messages and the counters values in
>> /debug/pm_debug/count.
>>
>> Let me confirm asap with the PRCM registers dump.
>Here is what I experimented:
>1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all >cases,
>2) checked the real state entered in low power mode from the console
>messages, the output of /debug/pm_debug/count and PRCM registers dump
>2) is OK, which means that the RET and OFF modes are correctly hit.
>Can I conclude from 1) that the wake-up code is not running from the
>cache in RETention?
[Derrick, David]
To add some context to the wait_sdrc_ok function and why it was added:
wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles
to lock. So you do not want to go back to DDR before DLL is locked. Also, we
found some times DLL never locked so we introduced the DLL kick procedure to
force it to lock.
Regards,
David
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-19 16:14 ` Derrick, David
@ 2010-11-19 16:26 ` Jean Pihet
2010-11-22 10:07 ` Peter 'p2' De Schrijver
1 sibling, 0 replies; 37+ messages in thread
From: Jean Pihet @ 2010-11-19 16:26 UTC (permalink / raw)
To: Derrick, David
Cc: Tony Lindgren, Menon, Nishanth, Kevin Hilman,
linux-omap@vger.kernel.org, Sripathy, Vishwanath, Pihet-XID, Jean
On Fri, Nov 19, 2010 at 5:14 PM, Derrick, David <dderrick@ti.com> wrote:
>>-----Original Message-----
>>From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
>>Sent: Friday, November 19, 2010 9:37 AM
>
>>On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pihet@newoldbits.com> >wrote:
>>> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>> * Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
>>>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>>>
>>>>> About the DPLL lock:
>>>>> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
>>>>> 2) I checked that when running wait_sdrc_ok the CORE is already out of
>>>>> idle and the DPLL is already locked. Note: l-o code has no support for
>>>>> the voltages OFF and the external clocks OFF.
>>>>>
>>>>> What to conclude from 1) and 2)? In my test setup ot looks like
>>>>> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
>>>>
>>>> Yeah we should figure out in which cases wait_sdrc_ok is needed.
>>>>
>>>> BTW, are you sure you're hitting core idle in your tests?
>>> Yes it is OK from the console messages and the counters values in
>>> /debug/pm_debug/count.
>>>
>>> Let me confirm asap with the PRCM registers dump.
>
>>Here is what I experimented:
>>1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all >cases,
>>2) checked the real state entered in low power mode from the console
>>messages, the output of /debug/pm_debug/count and PRCM registers dump
>
>>2) is OK, which means that the RET and OFF modes are correctly hit.
>
>>Can I conclude from 1) that the wake-up code is not running from the
>>cache in RETention?
>
> [Derrick, David]
>
> To add some context to the wait_sdrc_ok function and why it was added:
>
> wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles
> to lock. So you do not want to go back to DDR before DLL is locked. Also, we
> found some times DLL never locked so we introduced the DLL kick procedure to
> force it to lock.
Ok thanks for the details.
Does that mean that it is unsafe to run the sleep code (in
sleep34xx.S) from DDR?
>
> Regards,
> David
>
>
Regards,
Jean
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-19 16:14 ` Derrick, David
2010-11-19 16:26 ` Jean Pihet
@ 2010-11-22 10:07 ` Peter 'p2' De Schrijver
2010-11-22 16:03 ` Kevin Hilman
1 sibling, 1 reply; 37+ messages in thread
From: Peter 'p2' De Schrijver @ 2010-11-22 10:07 UTC (permalink / raw)
To: ext Derrick, David
Cc: Jean Pihet, Tony Lindgren, Menon, Nishanth, Kevin Hilman,
linux-omap@vger.kernel.org, Sripathy, Vishwanath, Pihet-XID, Jean
On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote:
> >-----Original Message-----
> >From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
> >Sent: Friday, November 19, 2010 9:37 AM
>
> >On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pihet@newoldbits.com> >wrote:
> >> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> >>> * Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
> >>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
> >>>>
> >>>> About the DPLL lock:
> >>>> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
> >>>> 2) I checked that when running wait_sdrc_ok the CORE is already out of
> >>>> idle and the DPLL is already locked. Note: l-o code has no support for
> >>>> the voltages OFF and the external clocks OFF.
> >>>>
> >>>> What to conclude from 1) and 2)? In my test setup ot looks like
> >>>> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
> >>>
> >>> Yeah we should figure out in which cases wait_sdrc_ok is needed.
> >>>
> >>> BTW, are you sure you're hitting core idle in your tests?
> >> Yes it is OK from the console messages and the counters values in
> >> /debug/pm_debug/count.
> >>
> >> Let me confirm asap with the PRCM registers dump.
>
> >Here is what I experimented:
> >1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all >cases,
> >2) checked the real state entered in low power mode from the console
> >messages, the output of /debug/pm_debug/count and PRCM registers dump
>
> >2) is OK, which means that the RET and OFF modes are correctly hit.
>
> >Can I conclude from 1) that the wake-up code is not running from the
> >cache in RETention?
>
> [Derrick, David]
>
> To add some context to the wait_sdrc_ok function and why it was added:
>
> wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles
> to lock. So you do not want to go back to DDR before DLL is locked. Also, we
> found some times DLL never locked so we introduced the DLL kick procedure to
> force it to lock.
>
The root cause for the DLL not locking has been found though and a
workaround implemented. So it should work now :) That still leaves the
500 L3 cycle delay though.
Cheers,
Peter.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-22 10:07 ` Peter 'p2' De Schrijver
@ 2010-11-22 16:03 ` Kevin Hilman
2010-11-22 16:08 ` Jean Pihet
2010-11-22 16:22 ` Peter 'p2' De Schrijver
0 siblings, 2 replies; 37+ messages in thread
From: Kevin Hilman @ 2010-11-22 16:03 UTC (permalink / raw)
To: Peter 'p2' De Schrijver
Cc: ext Derrick, David, Jean Pihet, Tony Lindgren, Menon, Nishanth,
linux-omap@vger.kernel.org, Sripathy, Vishwanath, Pihet-XID, Jean
"Peter 'p2' De Schrijver" <peter.de-schrijver@nokia.com> writes:
> On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote:
>> >-----Original Message-----
>> >From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
>> >Sent: Friday, November 19, 2010 9:37 AM
>>
>> >On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pihet@newoldbits.com> >wrote:
>> >> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >>> * Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
>> >>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >>>>
>> >>>> About the DPLL lock:
>> >>>> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
>> >>>> 2) I checked that when running wait_sdrc_ok the CORE is already out of
>> >>>> idle and the DPLL is already locked. Note: l-o code has no support for
>> >>>> the voltages OFF and the external clocks OFF.
>> >>>>
>> >>>> What to conclude from 1) and 2)? In my test setup ot looks like
>> >>>> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
>> >>>
>> >>> Yeah we should figure out in which cases wait_sdrc_ok is needed.
>> >>>
>> >>> BTW, are you sure you're hitting core idle in your tests?
>> >> Yes it is OK from the console messages and the counters values in
>> >> /debug/pm_debug/count.
>> >>
>> >> Let me confirm asap with the PRCM registers dump.
>>
>> >Here is what I experimented:
>> >1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all >cases,
>> >2) checked the real state entered in low power mode from the console
>> >messages, the output of /debug/pm_debug/count and PRCM registers dump
>>
>> >2) is OK, which means that the RET and OFF modes are correctly hit.
>>
>> >Can I conclude from 1) that the wake-up code is not running from the
>> >cache in RETention?
>>
>> [Derrick, David]
>>
>> To add some context to the wait_sdrc_ok function and why it was added:
>>
>> wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles
>> to lock. So you do not want to go back to DDR before DLL is locked. Also, we
>> found some times DLL never locked so we introduced the DLL kick procedure to
>> force it to lock.
>>
>
> The root cause for the DLL not locking has been found though and a
> workaround implemented. So it should work now :)
Is the workaround for this reflected in Nishanth's series?
Kevin
> That still leaves the
> 500 L3 cycle delay though.
>
> Cheers,
>
> Peter.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-22 16:03 ` Kevin Hilman
@ 2010-11-22 16:08 ` Jean Pihet
2010-11-22 16:22 ` Peter 'p2' De Schrijver
1 sibling, 0 replies; 37+ messages in thread
From: Jean Pihet @ 2010-11-22 16:08 UTC (permalink / raw)
To: Kevin Hilman
Cc: Peter 'p2' De Schrijver, ext Derrick, David,
Tony Lindgren, Menon, Nishanth, linux-omap@vger.kernel.org,
Sripathy, Vishwanath, Pihet-XID, Jean
On Mon, Nov 22, 2010 at 5:03 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> "Peter 'p2' De Schrijver" <peter.de-schrijver@nokia.com> writes:
>
>> On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote:
>>> >-----Original Message-----
>>> >From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
>>> >Sent: Friday, November 19, 2010 9:37 AM
>>>
>>> >On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pihet@newoldbits.com> >wrote:
>>> >> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> >>> * Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
>>> >>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> >>>>
>>> >>>> About the DPLL lock:
>>> >>>> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
>>> >>>> 2) I checked that when running wait_sdrc_ok the CORE is already out of
>>> >>>> idle and the DPLL is already locked. Note: l-o code has no support for
>>> >>>> the voltages OFF and the external clocks OFF.
>>> >>>>
>>> >>>> What to conclude from 1) and 2)? In my test setup ot looks like
>>> >>>> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
>>> >>>
>>> >>> Yeah we should figure out in which cases wait_sdrc_ok is needed.
>>> >>>
>>> >>> BTW, are you sure you're hitting core idle in your tests?
>>> >> Yes it is OK from the console messages and the counters values in
>>> >> /debug/pm_debug/count.
>>> >>
>>> >> Let me confirm asap with the PRCM registers dump.
>>>
>>> >Here is what I experimented:
>>> >1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all >cases,
>>> >2) checked the real state entered in low power mode from the console
>>> >messages, the output of /debug/pm_debug/count and PRCM registers dump
>>>
>>> >2) is OK, which means that the RET and OFF modes are correctly hit.
>>>
>>> >Can I conclude from 1) that the wake-up code is not running from the
>>> >cache in RETention?
>>>
>>> [Derrick, David]
>>>
>>> To add some context to the wait_sdrc_ok function and why it was added:
>>>
>>> wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles
>>> to lock. So you do not want to go back to DDR before DLL is locked. Also, we
>>> found some times DLL never locked so we introduced the DLL kick procedure to
>>> force it to lock.
>>>
>>
>> The root cause for the DLL not locking has been found though and a
>> workaround implemented. So it should work now :)
>
> Is the workaround for this reflected in Nishanth's series?
Yes the patch is '[PATCH 02/13] OMAP3: PM: Errata i581 suppport: dll
kick strategy'
>
> Kevin
>
>> That still leaves the
>> 500 L3 cycle delay though.
>>
>> Cheers,
>>
>> Peter.
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-22 16:03 ` Kevin Hilman
2010-11-22 16:08 ` Jean Pihet
@ 2010-11-22 16:22 ` Peter 'p2' De Schrijver
2010-11-22 16:25 ` Nishanth Menon
1 sibling, 1 reply; 37+ messages in thread
From: Peter 'p2' De Schrijver @ 2010-11-22 16:22 UTC (permalink / raw)
To: ext Kevin Hilman
Cc: ext Derrick, David, Jean Pihet, Tony Lindgren, Menon, Nishanth,
linux-omap@vger.kernel.org, Sripathy, Vishwanath, Pihet-XID, Jean
On Mon, Nov 22, 2010 at 05:03:59PM +0100, ext Kevin Hilman wrote:
> "Peter 'p2' De Schrijver" <peter.de-schrijver@nokia.com> writes:
>
> > On Fri, Nov 19, 2010 at 05:14:15PM +0100, ext Derrick, David wrote:
> >> >-----Original Message-----
> >> >From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
> >> >Sent: Friday, November 19, 2010 9:37 AM
> >>
> >> >On Thu, Nov 18, 2010 at 7:34 PM, Jean Pihet <jean.pihet@newoldbits.com> >wrote:
> >> >> On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> >>> * Jean Pihet <jean.pihet@newoldbits.com> [101118 10:06]:
> >> >>>> On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> >>>>
> >> >>>> About the DPLL lock:
> >> >>>> 1) wait_sdrc_ok is only called when back from the non-OFF modes,
> >> >>>> 2) I checked that when running wait_sdrc_ok the CORE is already out of
> >> >>>> idle and the DPLL is already locked. Note: l-o code has no support for
> >> >>>> the voltages OFF and the external clocks OFF.
> >> >>>>
> >> >>>> What to conclude from 1) and 2)? In my test setup ot looks like
> >> >>>> wait_sdrc_ok is of no use, but I agree this a premature conclusion.
> >> >>>
> >> >>> Yeah we should figure out in which cases wait_sdrc_ok is needed.
> >> >>>
> >> >>> BTW, are you sure you're hitting core idle in your tests?
> >> >> Yes it is OK from the console messages and the counters values in
> >> >> /debug/pm_debug/count.
> >> >>
> >> >> Let me confirm asap with the PRCM registers dump.
> >>
> >> >Here is what I experimented:
> >> >1) added a cache flush (v7_flush_kern_cache_all) just before WFI, in all >cases,
> >> >2) checked the real state entered in low power mode from the console
> >> >messages, the output of /debug/pm_debug/count and PRCM registers dump
> >>
> >> >2) is OK, which means that the RET and OFF modes are correctly hit.
> >>
> >> >Can I conclude from 1) that the wake-up code is not running from the
> >> >cache in RETention?
> >>
> >> [Derrick, David]
> >>
> >> To add some context to the wait_sdrc_ok function and why it was added:
> >>
> >> wait_sdrc_ok was added because the DLL takes 500 L3 clock cycles
> >> to lock. So you do not want to go back to DDR before DLL is locked. Also, we
> >> found some times DLL never locked so we introduced the DLL kick procedure to
> >> force it to lock.
> >>
> >
> > The root cause for the DLL not locking has been found though and a
> > workaround implemented. So it should work now :)
>
> Is the workaround for this reflected in Nishanth's series?
No. It seems not. The workaround needs VDD2 voltage scaling which seems
to be missing now from l-o ?
Cheers,
Peter.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-22 16:22 ` Peter 'p2' De Schrijver
@ 2010-11-22 16:25 ` Nishanth Menon
2010-11-22 18:23 ` Kevin Hilman
0 siblings, 1 reply; 37+ messages in thread
From: Nishanth Menon @ 2010-11-22 16:25 UTC (permalink / raw)
To: Peter 'p2' De Schrijver
Cc: ext Kevin Hilman, ext Derrick, David, Jean Pihet, Tony Lindgren,
linux-omap@vger.kernel.org, Sripathy, Vishwanath, Pihet-XID, Jean
Peter 'p2' De Schrijver had written, on 11/22/2010 10:22 AM, the following:
[...]
>>> The root cause for the DLL not locking has been found though and a
>>> workaround implemented. So it should work now :)
>> Is the workaround for this reflected in Nishanth's series?
>
> No. It seems not. The workaround needs VDD2 voltage scaling which seems
> to be missing now from l-o ?
yep, that is correct - we dont have dvfs/OPP/voltage scaling in
kernel.org as of today - until we have those, it might not be possible
to push the "real workaround". the mentioned patch is, as documented,
support for the voltage workaround.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-22 16:25 ` Nishanth Menon
@ 2010-11-22 18:23 ` Kevin Hilman
2010-11-22 18:31 ` Nishanth Menon
0 siblings, 1 reply; 37+ messages in thread
From: Kevin Hilman @ 2010-11-22 18:23 UTC (permalink / raw)
To: Nishanth Menon
Cc: Peter 'p2' De Schrijver, ext Derrick, David, Jean Pihet,
Tony Lindgren, linux-omap@vger.kernel.org, Sripathy, Vishwanath,
Pihet-XID, Jean
Nishanth Menon <nm@ti.com> writes:
> Peter 'p2' De Schrijver had written, on 11/22/2010 10:22 AM, the following:
> [...]
>>>> The root cause for the DLL not locking has been found though and a
>>>> workaround implemented. So it should work now :)
>>> Is the workaround for this reflected in Nishanth's series?
>>
>> No. It seems not. The workaround needs VDD2 voltage scaling which seems
>> to be missing now from l-o ?
>
> yep, that is correct - we dont have dvfs/OPP/voltage scaling in
> kernel.org as of today - until we have those, it might not be possible
> to push the "real workaround". the mentioned patch is, as documented,
> support for the voltage workaround.
It would be worth noting other known issues that are not worked around
in this series due to external dependencies.
Also, is the current SR/voltage series as proposed capable of handling
the workaround for this fix?
Kevin
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
2010-11-22 18:23 ` Kevin Hilman
@ 2010-11-22 18:31 ` Nishanth Menon
0 siblings, 0 replies; 37+ messages in thread
From: Nishanth Menon @ 2010-11-22 18:31 UTC (permalink / raw)
Cc: Peter 'p2' De Schrijver, ext Derrick, David, Jean Pihet,
Tony Lindgren, linux-omap@vger.kernel.org, Sripathy, Vishwanath,
Pihet-XID, Jean
Kevin Hilman had written, on 11/22/2010 12:23 PM, the following:
> Nishanth Menon <nm@ti.com> writes:
>
>> Peter 'p2' De Schrijver had written, on 11/22/2010 10:22 AM, the following:
>> [...]
>>>>> The root cause for the DLL not locking has been found though and a
>>>>> workaround implemented. So it should work now :)
>>>> Is the workaround for this reflected in Nishanth's series?
>>> No. It seems not. The workaround needs VDD2 voltage scaling which seems
>>> to be missing now from l-o ?
>> yep, that is correct - we dont have dvfs/OPP/voltage scaling in
>> kernel.org as of today - until we have those, it might not be possible
>> to push the "real workaround". the mentioned patch is, as documented,
>> support for the voltage workaround.
>
> It would be worth noting other known issues that are not worked around
> in this series due to external dependencies.
I believe I have done that
http://marc.info/?l=linux-omap&m=129013172525234&w=2
"IMPORTANT: this is not a complete workaround implementation as recommended
by the silicon errata. this is a support logic for detecting lockups and
attempting to recover where possible and is known to provide stability
in multiple platforms.
"
>
> Also, is the current SR/voltage series as proposed capable of handling
> the workaround for this fix?
I believe a new series is due sometime- we should see if the required
changes are part of that series.
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2010-11-22 18:31 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-24 10:56 [PATCH 0/2] OMAP3 PM: sleep code clean up Vishwanath BS
2010-09-24 10:56 ` [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr Vishwanath BS
2010-09-24 19:01 ` Tony Lindgren
2010-09-24 19:09 ` Tony Lindgren
[not found] ` <20100924190930.GH4211-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2010-09-25 5:52 ` Shilimkar, Santosh
2010-09-24 19:57 ` Kevin Hilman
2010-10-04 7:26 ` Sripathy, Vishwanath
2010-09-24 10:56 ` [PATCH 2/2] OMAP3 PM: sleep code clean up Vishwanath BS
[not found] ` <1285325785-6163-3-git-send-email-vishwanath.bs-l0cyMroinI0@public.gmane.org>
2010-09-24 20:05 ` Kevin Hilman
2010-10-04 8:44 ` Sripathy, Vishwanath
2010-10-04 8:56 ` Amit Kucheria
2010-10-04 9:36 ` Shilimkar, Santosh
-- strict thread matches above, loose matches on Subject: below --
2010-11-18 14:51 OMAP3 sleep code clean-up Jean Pihet
2010-11-18 14:51 ` [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr Jean Pihet
2010-11-18 14:57 ` Nishanth Menon
2010-11-18 15:08 ` Sripathy, Vishwanath
2010-11-18 15:11 ` Nishanth Menon
2010-11-18 15:15 ` Jean Pihet
2010-11-18 15:33 ` Nishanth Menon
2010-11-18 15:52 ` Kevin Hilman
2010-11-18 16:55 ` Nishanth Menon
2010-11-18 17:52 ` Tony Lindgren
2010-11-18 18:13 ` Tony Lindgren
2010-11-18 18:15 ` Jean Pihet
2010-11-18 18:27 ` Tony Lindgren
2010-11-18 18:34 ` Jean Pihet
2010-11-19 15:37 ` Jean Pihet
2010-11-19 16:09 ` Tony Lindgren
2010-11-19 16:14 ` Derrick, David
2010-11-19 16:26 ` Jean Pihet
2010-11-22 10:07 ` Peter 'p2' De Schrijver
2010-11-22 16:03 ` Kevin Hilman
2010-11-22 16:08 ` Jean Pihet
2010-11-22 16:22 ` Peter 'p2' De Schrijver
2010-11-22 16:25 ` Nishanth Menon
2010-11-22 18:23 ` Kevin Hilman
2010-11-22 18:31 ` Nishanth Menon
2010-09-24 10:47 [PATCH 0/2] OMAP3 PM: sleep code clean up Vishwanath BS
2010-09-24 10:47 ` [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr Vishwanath BS
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).