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
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
