diff options
author | Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> | 2008-03-25 11:39:29 +0900 |
---|---|---|
committer | Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> | 2008-03-25 11:39:29 +0900 |
commit | e1390801a3c1a2b6d12fa90be368efc19f5b9bfd (patch) | |
tree | bd17c0d102a57979894da20cdab6d2c006f2d979 /include/asm-mips/ptrace.h | |
parent | 0d48926c87ec96f974a6ac4034f4a2f2eab3255f (diff) |
[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>
Diffstat (limited to 'include/asm-mips/ptrace.h')
0 files changed, 0 insertions, 0 deletions