Jean Pihet wrote, on 11/19/2010 03:57 AM:
[...]
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 5a4468f..7259541 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
...
/* Function call to get the restore pointer for for ES3 to resume from OFF */
@@ -246,6 +256,19 @@ copy_to_sram:
This code is from 'restore_es3' which ends with a pass-through to 'restore:'...
bne copy_to_sram
ldr r1, sram_base
blx r1
+
.. and so adding restore_3630 here has the result that is also run by
34xx>= ES3.x.
Is that a concern? Was it tested on 34xx>= ES3.x?
arrgh.. thanks for catching it
I did run it on a SDP3430 ES3.1 platform.. hmmm... I did not intend that
behavior though - there should be a b restore here!
+restore_3630:
+ /*b restore_es3630*/ @ Enable to debug restore code
+ ldr r1, pm_prepwstst_core_p
+ ldr r2, [r1]
+ and r2, r2, #0x3
+ cmp r2, #0x0 @ Check if previous power state of CORE is OFF
+ bne restore
+ /* Disable rta before giving control */
+ ldr r1, control_mem_rta
+ mov r2, #OMAP36XX_RTA_DISABLE
+ str r2, [r1]
+ /* Fall thru for the remaining logic */
restore:
/* b restore*/ @ Enable to debug restore code
/* Check what was the reason for mpu reset and store the reason in r9*/
@@ -650,6 +673,8 @@ cache_pred_disable_mask:
.word 0xFFFFE7FB
control_stat:
.word CONTROL_STAT
+control_mem_rta:
+ .word CONTROL_MEM_RTA_CTRL
kernel_flush:
.word v7_flush_dcache_all
/* these 2 words need to be at the end !!! */
--
1.6.3.3
A more general remark: since pm34xx.c and sleep34xx.S now contain 34xx
and 36xx specific code, should those (and possibly other files) be
renamed to e.g. pm3xxx.c and sleep3xxx.S?
During the initial days of 3630 code introduction we found that almost
all of the code with 34xx could be reused for 3630 as well.. what ended
up happening is 34xx now means 3630&3430, while 343x holds to the 3430
family :(.. cpu_is_omap34xx() as an example - ideally should have been
cpu_is_omap3xxx() ;) ..I guess it is becoming more of a convention to do
3xxx for new code and leaving the old code as is :(
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
