[MIPS] Request for the 'mips_cache_lock()' removal

The initial intension of having mips_cache_lock() was to use the cache
as memory for temporary stack use so that a C environment can be set up
as early as possible.

But now mips_cache_lock() follow lowlevel_init(). We've already have the
real memory initilaized at this point, therefore we could/should use it.
No reason to lock at all.

Other problems:

Cache locking is not consistent across MIPS implementaions. Some imple-
mentations don't support locking at all. The style of locking varies -
some support per line locking, others per way, etc. Some parts use bits
in status registers instead of cache ops. Current mips_cache_lock() is
not necessarily general-purpose.

And this is worthy of special mention; once U-Boot/MIPS locks the lines,
they are never get unlocked, so the code relies on whatever gets loaded
after U-Boot to re-initialize the cache and clear the locks. We're sup-
posed to have CFG_INIT_RAM_LOCK and unlock_ram_in_cache() implemented,
but leave the situation as it is for a long time.

For these reasons, I proposed the removal of mips_cache_lock() from the
global start-up code.

This patch adds CFG_INIT_RAM_LOCK_MIPS to make existing users aware that
*things have changed*. If he wants the same behavior as before, he needs
to have CFG_INIT_RAM_LOCK_MIPS in his config file.

If we don't have any regression report through several releases, then
we'll remove codes entirely.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Acked-by: Andrew Dyer <amdyer@gmail.com>

1 files changed, 2 insertions, 0 deletions

diff --git a/cpu/mips/start.S b/cpu/mips/start.S
index c92b162..930f9b3 100644
--- a/cpu/mips/start.S
+++ b/cpu/mips/start.S
@@ -267,10 +267,12 @@ reset:
 
 	/* Set up temporary stack.
 	 */
+#ifdef CFG_INIT_RAM_LOCK_MIPS
 	li	a0, CFG_INIT_SP_OFFSET
 	la	t9, mips_cache_lock
 	jalr	t9
 	nop
+#endif
 
 	li	t0, CFG_SDRAM_BASE + CFG_INIT_SP_OFFSET
 	la	sp, 0(t0)