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