From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] command/cache: Add flush_cache command
Date: Wed, 20 Mar 2013 18:48:38 -0500 [thread overview]
Message-ID: <1363823318.25034.33@snotra> (raw)
In-Reply-To: <4BABA974-A22D-4FD7-9678-035DD5AE5107@prograde.net> (from mboards@prograde.net on Wed Mar 20 18:33:41 2013)
On 03/20/2013 06:33:41 PM, Michael Cashwell wrote:
> On Mar 20, 2013, at 6:35 PM, Scott Wood <scottwood@freescale.com>
> wrote:
>
> > Really, instead of adding one command, you want to modify *two*
> commands to do the same thing separately, which involves changing the
> syntax of both commands to accept memory range information?
>
> What is the purpose of limiting the memory range to be flushed? Is
> there a reason one might want to NOT flush certain data sitting in a
> dirty cache line out to memory before doing a go or boot command?
Because it would take a while to flush all of RAM?
> If you drive the operation as a "walk the cache" process rather than
> a "iterate over all SDRAM physical address space to cherry pick
> within a range" it wouldn't seem that slow. I mean, there's only so
> much cache memory.
There's no way to "walk the cache" on many chips, including ours.
There are generally ways to flush the entire thing, but they are (more)
hardware-specific than using the architected method of flushing a
memory range, and sometimes these methods have errata associated with
them.
-Scott
next prev parent reply other threads:[~2013-03-20 23:48 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-19 20:29 [U-Boot] [RFC] command/cache: Add flush_cache command York Sun
2013-03-19 22:01 ` Albert ARIBAUD
2013-03-19 22:07 ` York Sun
2013-03-19 23:32 ` Scott Wood
2013-03-20 13:59 ` Albert ARIBAUD
2013-03-20 14:58 ` Wolfgang Denk
2013-03-20 16:43 ` Scott Wood
2013-03-20 17:38 ` Albert ARIBAUD
2013-03-20 18:16 ` Scott Wood
2013-03-20 19:15 ` Tom Rini
2013-03-20 19:36 ` Scott Wood
2013-03-20 19:59 ` Tom Rini
2013-03-20 21:31 ` Scott Wood
2013-03-21 5:42 ` Wolfgang Denk
2013-03-21 5:39 ` Wolfgang Denk
2013-03-21 12:29 ` Tom Rini
2013-03-21 13:37 ` Wolfgang Denk
2013-03-21 18:22 ` Scott Wood
2013-03-21 19:25 ` Wolfgang Denk
2013-03-21 20:34 ` Scott Wood
2013-03-22 6:30 ` Albert ARIBAUD
2013-03-22 12:17 ` Tom Rini
2013-03-22 14:03 ` Wolfgang Denk
2013-03-22 14:29 ` Tom Rini
2013-03-22 15:57 ` Albert ARIBAUD
2013-03-22 16:48 ` Scott Wood
2013-03-22 17:19 ` Tom Rini
2013-03-22 20:39 ` Wolfgang Denk
2013-03-20 22:11 ` Albert ARIBAUD
2013-03-20 22:35 ` Scott Wood
2013-03-20 23:33 ` Michael Cashwell
2013-03-20 23:48 ` Scott Wood [this message]
2013-03-21 0:27 ` Michael Cashwell
2013-03-21 0:31 ` Scott Wood
2013-03-21 5:02 ` Sricharan R
2013-03-21 18:51 ` Scott Wood
2013-03-21 17:58 ` Albert ARIBAUD
2013-03-21 18:07 ` Scott Wood
2013-03-21 19:21 ` Wolfgang Denk
2013-03-20 19:40 ` York Sun
2013-03-20 14:51 ` Wolfgang Denk
2013-03-20 16:44 ` Scott Wood
2013-04-03 14:02 ` Jim Chargin
2013-04-18 17:09 ` Scott Wood
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=1363823318.25034.33@snotra \
--to=scottwood@freescale.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.