tree bd17c0d102a57979894da20cdab6d2c006f2d979
parent 48116dc97bdbdf7ebf2c4061c356a72842ca2364
author Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> 1206412769 +0900
committer Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> 1206412769 +0900

[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>