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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected] Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
