On Tue, Jul 24, 2018 at 9:21 AM, Paul Burton <paul.burton@xxxxxxxx> wrote: > Hi Huacai, > > Please stop top-posting - you make it difficult to reply. I know you've > mentioned difficulties sending mail from your @lemote.com address but no > matter which email address you're using you should be able to format > your email properly if you're using a suitable email client. > > On Tue, Jun 19, 2018 at 02:50:36PM +0800, 陈华才 wrote: >> > I think it'd be neater if we did this from C in cpu_probe_loongson() >> > though. If we add __BUILD_SET_C0(config6) to asm/mipsregs.h and define a >> > macro naming the SFB enable bit then both boot CPU & secondary cases >> > could be handled by a single line in cpu_probe_loongson(). Something >> > like this: >> > >> > set_c0_config6(LOONGSON_CONFIG6_SFB_ENABLE); >> > >> > Unless there's a technical reason this doesn't work I'd prefer it to the >> > assembly version (and maybe we could move the LPA & ELPA configuration >> > into cpu-probe.c too then remove asm/mach-loongson64/kernel-entry-init.h >> > entirely). >> >> We should enable SFB/ELPA as early as possible, because it is >> dangerous if one core is SFB-enabled why another core isn't. ELPA is >> similar. > > Why is it dangerous, and in what circumstances? > > Based on commit messages & our other discussions about the SFB my > understanding is that it sits within a core, between the CPU pipeline & > the core's L1 data cache. Why would another core care about it being > enabled or disabled? How could the other core even tell? In practice, SFB cannot be enabled/disabled dynamically. But I don't know why because I'm not the CPU designer. Huacai > > Thanks, > Paul
