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