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

[Scott Wood <scottwood@freescale.com>]

On 04/10/2013 06:54:25 AM, Wolfgang Denk wrote:
> Dear Scott,
> 
> In message <1365555490.31043.20@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.

The existing ones have semantics that are mismatched to what we want to  
expose.
	
> > 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):

It was my answer to your question.  If you don't like my answer, fine.

> | ...  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.

Needing to touch them at all is a big issue.  We don't know the details  
of all these architectures, and cannot test them.  If there were a good  
*reason* for it we could engage the maintainers of those architectures,  
but I've yet to hear a reason that justifies the hassle.  We'd probably  
be better off just keeping the patch in our internal tree, which is the  
tree that the user who ran into this problem is using.

> Actually quite a number of them are actually just combiing calls like  
> that:

Many have the instruction/data sequence inside the loop so we'd need to  
pick it apart (higher risk of introducing a bug, so more need for  
testing that we cannot do).  Blackfin is weird -- if we did a simple  
split at the C-code level it looks like we'd have two dummy loops  
executing.

> > 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.

The openrisc example does not show any great difficulty implementing  
flush_cache().

> > 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?

"Major achievement"?  No, I just said it was a useful (but poorly  
named) abstraction, which it is.  What do we gain by replacing every  
caller of flush_cache() with two function calls instead?  When would we  
ever call one but not the other, and if there is such a case, what harm  
would come out of doing both anyway?

-Scott