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

[Scott Wood <scottwood@freescale.com>]

On 04/08/2013 02:18:20 PM, Wolfgang Denk wrote:
> Dear Scott,
> 
> In message <1365447916.28843.7@snotra> you wrote:
> >
> > Maybe "cache" should be the toplevel command, with "icache" and
> > "dcache" refactored to be subcommands?  Of course, then you're  
> making
> > an incompatible interface change.  How much is consistency worth?
> 
> I think backward compatibility is mandatory here.  We cannot break
> existing user scripts.

Sure.  But if the main reason for the icache/dcache split is  
compatibility, I don't think that should constrict the form of new  
commands.

> I'm also not convinced that merging this into one command would be a
> better design.  I think the current split is a pretty good represen-
> tation of what the hardware looks like and how i works.  Let's keep
> it.
> 
> > The whole point of the patch is to expose the existing flush_cache()
> > functionality, which is not split into icache/dcache.  From the  
> user's
> 
> I understand this.  But while the combination of IC and DC related
> operations into one function may be convenient for internal use, it is
> not a good idea when exposed externally.
> 
> > perspective, it's a command to flush the specified region out of  
> *all*
> > caches.  It's an implementation detail that some hardware or
> 
> I understand what you mean, but actually we do not flush the IC, we
> invalidate it, which is something different.  I don't want to start a
> discussion here if flush_cache() is actually a bad function name (when
> discussing the functionality, it is), not do I want to suggest to
> change that name.
> 
> But when we publish such interfaces to the end user, it is important
> to be precise in our terminology.

I think the terminology is just fine.  It's not just invalidating the  
icache (flushing and invalidating are the same thing for cache lines  
which are not modified -- or are incapable of being modified).  It's  
flushing the region out of *all* caches.

What actual use case is there for only wanting to flush one or the  
other?

> > architectures accomplish this using separate dcache and icache
> > instructions.  If you make the interface be "icache/dcache", how  
> would
> > you handle hardware where the flushing mechanism (or even the cache
> > itself) is not split?
> 
> If IC and DC are the same thing, the same function can be used to
> implement the operations.  "icache" and "dcache" would then run the
> same code, i. e. be aliases.
> 
> > > [In the example of L2 cache above, it would be for example  
> sufficient
> > > to add a "-L2" option to the "icache" / "dcache" commands.]
> >
> > Would it?  On our chips L2 cache is (more or less) unified.   
> There's no
> > separate icache/dcache flush.
> 
> See above.  In such a case "icache" and "dcache" can just call the
> same underlying code.

And then we end up having to do the flush twice, if the user follows  
the "first flush dcache, then flush icache" instructions.  That's not  
an ideal interface.

-Scott