Hi, Maciej Joshua Kinard suggest me to split the patch, which you can see here: https://patchwork.linux-mips.org/patch/12324/ If it is better to not split, please see my V2 patchset. Huacai On Thu, Feb 25, 2016 at 8:59 AM, Maciej W. Rozycki <macro@xxxxxxxxxx> wrote: > On Wed, 24 Feb 2016, Huacai Chen wrote: > >> If a platform maintains cache coherency by hardware fully: >> 1) It's icache is coherent with dcache. >> 2) It's dcaches don't alias (maybe depend on PAGE_SIZE). >> 3) It maintains cache coherency across cores (and for DMA). >> >> So we introduce a MIPS_CPU_CACHE_COHERENT bit, and a cpu feature named >> cpu_has_coherent_cache to modify MIPS's cache flushing functions. > [...] >> diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c >> index caac3d7..04a38d8 100644 >> --- a/arch/mips/mm/c-r4k.c >> +++ b/arch/mips/mm/c-r4k.c >> @@ -428,6 +428,9 @@ static void r4k_blast_scache_setup(void) >> >> static inline void local_r4k___flush_cache_all(void * args) >> { >> + if (cpu_has_coherent_cache) >> + return; >> + > [etc.] > > Have you considered setting the relevant handlers to `cache_noop' in > `r4k_cache_init' instead? It seems more natural to me and avoids the > performance hit where `cpu_has_coherent_cache' is variable, which at this > time means everywhere. > > Also you don't set the MIPS_CPU_CACHE_COHERENT bit anywhere within you > patch set -- is there a follow-up change you're going to submit? > > Maciej >
