All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Dyer <amdyer@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [RFC][MIPS] Remove mips_cache_lock
Date: Sun, 23 Mar 2008 21:29:39 -0500	[thread overview]
Message-ID: <c166aa9f0803231929o7d809f32vf9305d48102af0cf@mail.gmail.com> (raw)
In-Reply-To: <47E3BC0C.4060406@ruby.dti.ne.jp>

On Fri, Mar 21, 2008 at 8:45 AM, Shinya Kuribayashi
<skuribay@ruby.dti.ne.jp> wrote:
>
>  [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>

>  ---
>
>   cpu/mips/cache.S |    2 ++
>   cpu/mips/start.S |    2 ++
>   2 files changed, 4 insertions(+), 0 deletions(-)
>
>
>  diff --git a/cpu/mips/cache.S b/cpu/mips/cache.S
>  index 443240e..67ee19f 100644
>  --- a/cpu/mips/cache.S
>  +++ b/cpu/mips/cache.S
>  @@ -238,6 +238,7 @@ dcache_disable:
>
>         .end    dcache_disable
>
>  +#ifdef CFG_INIT_RAM_LOCK_MIPS
>   /*******************************************************************************
>   *
>   * mips_cache_lock - lock RAM area pointed to by a0 in cache.
>  @@ -263,3 +264,4 @@ mips_cache_lock:
>         j       ra
>
>         .end    mips_cache_lock
>  +#endif /* CFG_INIT_RAM_LOCK_MIPS */
>  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)
>

      reply	other threads:[~2008-03-24  2:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-17 14:42 [U-Boot-Users] [RFC][MIPS] Remove mips_cache_lock Shinya Kuribayashi
2008-03-17 21:04 ` Wolfgang Denk
2008-03-17 23:55   ` Andrew Dyer
2008-03-18  0:28     ` Wolfgang Denk
2008-03-18 12:56       ` Shinya Kuribayashi
2008-03-18 13:47         ` Shinya Kuribayashi
2008-03-21 13:45           ` Shinya Kuribayashi
2008-03-24  2:29             ` Andrew Dyer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c166aa9f0803231929o7d809f32vf9305d48102af0cf@mail.gmail.com \
    --to=amdyer@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.