Hi, sorry for my silence for several resending posts. I talked with Ralf on this briefly, when the patch was posted for the first time last year. He seems busy these days, so I'm trying to move things forward. On 01/06/2011 04:31 PM, Kevin Cernekee wrote: > On processors with deep write buffers, it is likely that many cycles > will pass between a CACHE instruction and the time the data actually > gets written out to DRAM. Add a SYNC instruction to ensure that the > buffers get emptied before the flush functions return. Having a talk with appropriate people (probably including MIPS guys), such CACHE behavior would be eventually considered to be _legitimate_, Ralf said. Thus we agree with this change required not only for BMIPS cores, but also for the rest of processors, as one of cache features. The problem is how to implement it. Most of SYNC-equipped processors work fine without this treatment, so unless it's required, we don't want to have __sync() after every cacheflush operations. Having SYNC there is somewhat waste of time. > diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c > index b4923a7..dc5d9c4 100644 > --- a/arch/mips/mm/c-r4k.c > +++ b/arch/mips/mm/c-r4k.c > @@ -604,6 +604,7 @@ static void r4k_dma_cache_wback_inv(unsigned long addr, unsigned long size) > r4k_blast_scache(); > else > blast_scache_range(addr, addr + size); > + __sync(); > return; > } > Just random thought, how it's going to be when implementing this as, - sort of barrier - sort of hazard - one of cache features (e.g., cpu_has_xxx or similar way) - and so on... Another concern is that, except for four __sync() insertions, are we missing other places? Ralf also thinks that run-time probe & detection would be better than build-time configuration. Optimization is easy and won't be problem here, so we'd like to keep things synthesized as much as possible. I couldn't imagine the final shape how this patch should be as of now, sorry! Shinya
