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

[Wolfgang Denk]

Dear Scott,

In message <1365622923.8381.10 at snotra> you wrote:
>
> > 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.

Agreed.  So we can either change the API to match your wishes, or we
can ask you to adapt to the existing API.  The first is less effort,
the second is conceptionally cleaner.

I prefer the second one.

> 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  

Come one. This is actually all pretty trivial code.  I don't buy this
argument.

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

Huh?  flush_cache() does not include any loop for BF.

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

Correct, and neither does any other of the existing architectures.
It's a plain stupid laborious task; it does not involve any kind of
critical operations or other forms of rocket science.


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
Any sufficiently advanced technology is indistinguishable from magic.
                                                   - Arthur C. Clarke