[U-Boot] [v3] command/cache: Add flush command

[Wolfgang Denk]

Dear Scott,

In message <1365555490.31043.20 at snotra> you wrote:
>
> If that means you have some other reason for objecting that you *do*  
> want to go into, could you elaborate?

I explained that before: we already have commands to operate with the
caches, and we should rather use the existingones and extend these as
needed instead of adding arbitrary new ones.

> This is just one implementation of flush_cache().  Here are all of them:

Thanks for the list.  But that was not my question.  I asked (ok, in
the other message):

| ...  Can you please point me to
| the code (ideally in mainline U-Boot) which would cause problems with
| the suggested separation of invalidating the IC and flushing the DC
| into subcommands of the "icache" resp. "dcache" commands?

Yes, I did have a look at all these implementations, and I think none
of them will cause any issues.  Actually quite a number of them are
actually just combiing calls like that:

"arch/openrisc/cpu/cache.c":

	 54 void flush_cache(unsigned long addr, unsigned long size)
	 55 {
	 56         flush_dcache_range(addr, addr + size);
	 57         invalidate_icache_range(addr, addr + size);
	 58 }

I do not claim to have perfect understanding of all arhcitectures and
implementations; I may easily miss something.  So could you please
tell me _exactly_ where you see issues?


> This is what we're trying to expose as a command.  If you want it split  
> into icache and dcache, it needs to be rewritten for every architecture  

Actually it appears to be already split quite naturally for all
currently supported architectures (at least to the extend these
implement this functinality at all).  flush_cache() is just a
convenience, and if you think twice not even a very lucky one.
The openrisc example above shows this pretty clearly.

So far, I cannot see a real technical problem in doing what I
proposed, i. e. running  flush_dcache_range()  as  "dcache flush"
sub-command, and  invalidate_icache_range()  as  "icache invalidate"
sub-command.  I see no need to define a new command, and I see no
technical problems with the implementation of the new subcommands.

If I'm missing something, and you are aware of any real problems, then
please point these out.

> (or else we'd need to limit the command to only running on certain  
> architectures), and not all of them are as easily splittable.  What is  

Where exactly do you see problems?  Do you have any unpublished code
for a new architecture sitting somewhere, or what?  The current code
in mainline U-Boot should be straightforward to handle.

> the actual need for splitting it?  The semantics we're trying to expose  
> as a command are the same as this function is meant to implement,  

You defend this stupid function  flush_cache()  as if it was of major
achievement of the development of software in the last decades?  I'm
sorry, but it ain't so.  It's just a pretty stupid thing without any
real value.  I can imagine to see it gone without sheding a tear.

> regardless of the choice of name.  Those semantics are "make the data  
> we just wrote to this range visible to instruction fetches".

...and the implementation usually requires the two steps
flush_dcache_range() and invalidate_icache_range(), which translated
straightforward into "dcache flush" resp. "icache invalidate"
commands.

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
It is wrong always, everywhere and for everyone to  believe  anything
upon  insufficient  evidence.  - W. K. Clifford, British philosopher,
circa 1876