From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 20 Mar 2013 19:31:42 -0500 Subject: [U-Boot] [RFC] command/cache: Add flush_cache command In-Reply-To: <867D8C0F-FE72-49A5-915D-470E731437C4@prograde.net> (from mboards@prograde.net on Wed Mar 20 19:27:29 2013) References: <20130320191519.GO25919@bill-the-cat> <1363808165.25034.14@snotra> <20130320231157.4f312493@lilith> <1363818951.25034.28@snotra> <4BABA974-A22D-4FD7-9678-035DD5AE5107@prograde.net> <1363823318.25034.33@snotra> <867D8C0F-FE72-49A5-915D-470E731437C4@prograde.net> Message-ID: <1363825902.25034.37@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 03/20/2013 07:27:29 PM, Michael Cashwell wrote: > On Mar 20, 2013, at 7:48 PM, Scott Wood > wrote: > > > On 03/20/2013 06:33:41 PM, Michael Cashwell wrote: > > > >> 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? > > "Flushing all of RAM" is what trips me up. Fundamentally, that puts > the cart in front of the horse. The goal isn't to flush all of RAM > but rather to flush all of cache. Right, I was just responding to your question of, "What is the purpose of limiting the memory range to be flushed?" > Iterating over the small thing rather than the large would seem > reasonably efficient. > > But as you say, if there are architectures where that can't be done > and you must pass GBs of physical address space (rather than KB of > cache space) through some process then range limiting it does make > sense. Right. The range specified is a minimum to be flushed -- if a particular architecture finds it easier/quicker to flush everything instead, that's fine. -Scott