Sometimes, we get stuck while trying to enter sleep. This seems
to occur if we do not have udelay() in the instruction cache. Avoid
this by requesting a short delay prior to modifying the SDRAM timings.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
*
* Causes sa11x0 to enter sleep state
*
*
* Causes sa11x0 to enter sleep state
*
+ * Must be aligned to a cacheline.
ENTRY(sa1100_finish_suspend)
@ disable clock switching
mcr p15, 0, r1, c15, c2, 2
ENTRY(sa1100_finish_suspend)
@ disable clock switching
mcr p15, 0, r1, c15, c2, 2
- @ Adjust memory timing before lowering CPU clock
- @ Clock speed adjustment without changing memory timing makes
- @ CPU hang in some cases
- ldr r0, =MDREFR
- ldr r1, [r0]
- orr r1, r1, #MDREFR_K1DB2
- str r1, [r0]
+ ldr r6, =MDREFR
+ ldr r4, [r6]
+ orr r4, r4, #MDREFR_K1DB2
+ ldr r5, =PPCR
+
+ @ Pre-load __udelay into the I-cache
+ mov r0, #1
+ bl __udelay
+ mov r0, r0
+
+ @ The following must all exist in a single cache line to
+ @ avoid accessing memory until this sequence is complete,
+ @ otherwise we occasionally hang.
+
+ @ Adjust memory timing before lowering CPU clock
+ str r4, [r6]
@ delay 90us and set CPU PLL to lowest speed
@ fixes resume problem on high speed SA1110
mov r0, #90
bl __udelay
@ delay 90us and set CPU PLL to lowest speed
@ fixes resume problem on high speed SA1110
mov r0, #90
bl __udelay
bic r5, r5, #FMsk(MSC_RT)
bic r5, r5, #FMsk(MSC_RT)<<16
bic r5, r5, #FMsk(MSC_RT)
bic r5, r5, #FMsk(MSC_RT)<<16
-bic r7, r7, #0x0000FF00
-bic r7, r7, #0x000000F0
-orr r8, r7, #MDREFR_SLFRSH
+ bic r7, r7, #0x0000FF00
+ bic r7, r7, #0x000000F0
+ orr r8, r7, #MDREFR_SLFRSH
ldr r9, =MDCNFG
ldr r10, [r9]
ldr r9, =MDCNFG
ldr r10, [r9]