public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [v3] command/cache: Add flush command
Date: Mon, 08 Apr 2013 21:18:20 +0200	[thread overview]
Message-ID: <20130408191820.D34632016C2@gemini.denx.de> (raw)
In-Reply-To: <1365447916.28843.7@snotra>

Dear Scott,

In message <1365447916.28843.7@snotra> you wrote:
>
> Maybe "cache" should be the toplevel command, with "icache" and  
> "dcache" refactored to be subcommands?  Of course, then you're making  
> an incompatible interface change.  How much is consistency worth?

I think backward compatibility is mandatory here.  We cannot break
existing user scripts.

I'm also not convinced that merging this into one command would be a
better design.  I think the current split is a pretty good represen-
tation of what the hardware looks like and how i works.  Let's keep
it.

> The whole point of the patch is to expose the existing flush_cache()  
> functionality, which is not split into icache/dcache.  From the user's  

I understand this.  But while the combination of IC and DC related
operations into one function may be convenient for internal use, it is
not a good idea when exposed externally.

> perspective, it's a command to flush the specified region out of *all*  
> caches.  It's an implementation detail that some hardware or  

I understand what you mean, but actually we do not flush the IC, we
invalidate it, which is something different.  I don't want to start a
discussion here if flush_cache() is actually a bad function name (when
discussing the functionality, it is), not do I want to suggest to
change that name.

But when we publish such interfaces to the end user, it is important
to be precise in our terminology.

> architectures accomplish this using separate dcache and icache  
> instructions.  If you make the interface be "icache/dcache", how would  
> you handle hardware where the flushing mechanism (or even the cache  
> itself) is not split?

If IC and DC are the same thing, the same function can be used to
implement the operations.  "icache" and "dcache" would then run the
same code, i. e. be aliases.

> > [In the example of L2 cache above, it would be for example sufficient
> > to add a "-L2" option to the "icache" / "dcache" commands.]
> 
> Would it?  On our chips L2 cache is (more or less) unified.  There's no  
> separate icache/dcache flush.

See above.  In such a case "icache" and "dcache" can just call the
same underlying code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When you lose, don't lose the lesson.                    - Dalai Lama

  reply	other threads:[~2013-04-08 19:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05 20:50 [U-Boot] [v3] command/cache: Add flush command York Sun
2013-04-05 21:00 ` Tom Rini
2013-04-05 21:09   ` York Sun
2013-04-05 22:09 ` Wolfgang Denk
2013-04-05 23:02   ` York Sun
2013-04-06  7:01     ` Wolfgang Denk
2013-04-07  3:31       ` sun york-R58495
2013-04-07  8:29         ` Wolfgang Denk
2013-04-08 17:45           ` sun york-R58495
2013-04-08 18:35             ` Wolfgang Denk
2013-04-08 19:05               ` Scott Wood
2013-04-08 19:18                 ` Wolfgang Denk [this message]
2013-04-08 19:31                   ` Scott Wood
2013-04-09 17:45                     ` Wolfgang Denk
2013-04-10  0:58                       ` Scott Wood
2013-04-10  2:07                         ` [U-Boot] DWMMC / DWMCI question TigerLiu at viatech.com.cn
2013-04-10 11:58                           ` Wolfgang Denk
2013-04-11  1:43                             ` TigerLiu at viatech.com.cn
2013-04-10 11:54                         ` [U-Boot] [v3] command/cache: Add flush command Wolfgang Denk
2013-04-10 19:42                           ` Scott Wood
2013-04-10 21:04                             ` Wolfgang Denk
2013-04-10 21:10                               ` Scott Wood
2013-04-10 22:50                                 ` Wolfgang Denk
2013-04-10 23:00                                   ` Scott Wood
2013-04-11 11:56                                     ` Wolfgang Denk
2013-04-08 19:50           ` Scott Wood
2013-04-09 17:48             ` Wolfgang Denk

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=20130408191820.D34632016C2@gemini.denx.de \
    --to=wd@denx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox