Dear Scott,
In message 1365622923.8381.10@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