From: Richard Woodruff <r-woodru...@ti.com>
I'm thinking DLL state is an exceptional condition which happens based
on some wrong early programming when initially setting DLL up. Some
kind of race between idle features and lock happens early on. This
patch recognizes the issue and moves state machine into locked state.
Its my guess the kick case won't be executed that often. As long as
DLL is not on you can mess with idle state. When its on to mess with
DDR control you need to be in self-refresh and not making
accesses... like in dvfs code.
Tested-by: Mike Chan <mikec...@google.com>
---
arch/arm/mach-omap2/sleep34xx.S | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index aedcf94..c469bbe 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -595,20 +595,38 @@ wait_sdrc_ok:
ldr r5, [r4]
bic r5, r5, #0x40
str r5, [r4]
-wait_dll_lock:
- /* Is dll in lock mode? */
+is_dll_in_lock_mode:
ldr r4, sdrc_dlla_ctrl
ldr r5, [r4]
tst r5, #0x4
bxne lr
/* wait till dll locks */
+wait_dll_lock_timed:
ldr r4, sdrc_dlla_status
+ mov r6, #0x2000
+wait_dll_lock:
+ subs r6, r6, #0x1
+ beq kick_dll
ldr r5, [r4]
and r5, r5, #0x4
cmp r5, #0x4
bne wait_dll_lock
bx lr
+ /* Kick DLL state machine if lock not started */
+kick_dll:
+ ldr r4, sdrc_dlla_ctrl /* get dlla addr */
+ ldr r5, [r4] /* grab value */
+ mov r6, r5 /* save value */
+ orr r6, r6, #0x10 /* dllidle on */
+ str r6, [r4]
+ dsb
+ bic r6, #0x10 /* dllidle off */
+ str r6, [r4]
+ dsb
+ str r6, [r4] /* restore old value */
+ b wait_dll_lock_timed
+
cm_idlest1_core:
.word CM_IDLEST1_CORE_V
sdrc_dlla_status:
--
1.6.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
