ARM: pm: omap34xx: remove get_*_restore_pointer functions, directly use entry points
Upon return from off-mode, the ROM code jumps to a restore function
saved in the scratchpad. Based on SoC revision or errata, this
restore entry point is different. Current code uses some helper
functions in sleep34xx.S (get_*_restore_pointer) to get the restore
function entry point.
When returning from off-mode, this code is executed from SDRAM, so
there's no reason to use these helper functions when using the SDRAM
entry points directly would work just fine.
This patch uses ENTRY/ENDPROC to create "real" entry points for these
functions, and uses those values directly when writing the scratchpad.
Tested all three entry points
- restore_es3: 3430/n900
- restore_3630: 3630/Zoom3
- restore: 3530/Overo
Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Jean Pihet <j-pihet@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index da53ba3..aab884f 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -286,14 +286,15 @@
scratchpad_contents.boot_config_ptr = 0x0;
if (cpu_is_omap3630())
scratchpad_contents.public_restore_ptr =
- virt_to_phys(get_omap3630_restore_pointer());
+ virt_to_phys(omap3_restore_3630);
else if (omap_rev() != OMAP3430_REV_ES3_0 &&
omap_rev() != OMAP3430_REV_ES3_1)
scratchpad_contents.public_restore_ptr =
- virt_to_phys(get_restore_pointer());
+ virt_to_phys(omap3_restore);
else
scratchpad_contents.public_restore_ptr =
- virt_to_phys(get_es3_restore_pointer());
+ virt_to_phys(omap3_restore_es3);
+
if (omap_type() == OMAP2_DEVICE_TYPE_GP)
scratchpad_contents.secure_ram_restore_ptr = 0x0;
else