Kevin Hilman had written, on 11/18/2010 09:52 AM, the following:
Nishanth Menon <nm@xxxxxx> writes:
From: Vishwanath BS <vishwanath.bs@xxxxxx>
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
--
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
