linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhou Yanjie <zhouyanjie@zoho.com>
To: Paul Burton <paul.burton@mips.com>
Cc: "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ralf@linux-mips.org" <ralf@linux-mips.org>,
	"paul@crapouillou.net" <paul@crapouillou.net>,
	"jhogan@kernel.org" <jhogan@kernel.org>,
	"malat@debian.org" <malat@debian.org>,
	"chenhc@lemote.com" <chenhc@lemote.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"allison@lohutok.net" <allison@lohutok.net>,
	"syq@debian.org" <syq@debian.org>,
	"jiaxun.yang@flygoat.com" <jiaxun.yang@flygoat.com>
Subject: Re: [PATCH v2] MIPS: Ingenic: Fix bugs when detecting X1000's parameters.
Date: Thu, 1 Aug 2019 18:55:26 +0800	[thread overview]
Message-ID: <5D42C51E.1090906@zoho.com> (raw)
In-Reply-To: <20190731203430.2wst6pivwxnmtt74@pburton-laptop>

Hi Paul,

On 2019年08月01日 04:34, Paul Burton wrote:
> Hi Zhou,
>
> On Wed, Jul 31, 2019 at 12:39:03PM +0800, Zhou Yanjie wrote:
>> 1.fix bugs when detecting L2 cache sets value.
>> 2.fix bugs when detecting L2 cache ways value.
>> 3.fix bugs when calculate bogoMips and loops_per_jiffy.
> This should be split into 2 patches - one that fixes the L2 cache
> detection problems, and possibly one that fixes the bogomips/lpj issue.
Thanks for your advice. I have split it in v3.
>
>> Signed-off-by: Zhou Yanjie <zhouyanjie@zoho.com>
>> ---
>>   arch/mips/include/asm/mipsregs.h |  1 +
>>   arch/mips/kernel/cpu-probe.c     |  7 +++++++
>>   arch/mips/mm/sc-mips.c           | 18 +++++++++++++++---
>>   3 files changed, 23 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
>> index 1e6966e..01e0fcb 100644
>> --- a/arch/mips/include/asm/mipsregs.h
>> +++ b/arch/mips/include/asm/mipsregs.h
>> @@ -2813,6 +2813,7 @@ __BUILD_SET_C0(status)
>>   __BUILD_SET_C0(cause)
>>   __BUILD_SET_C0(config)
>>   __BUILD_SET_C0(config5)
>> +__BUILD_SET_C0(config7)
>>   __BUILD_SET_C0(intcontrol)
>>   __BUILD_SET_C0(intctl)
>>   __BUILD_SET_C0(srsmap)
>> diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
>> index eb527a1..547c9a0 100644
>> --- a/arch/mips/kernel/cpu-probe.c
>> +++ b/arch/mips/kernel/cpu-probe.c
>> @@ -1964,6 +1964,13 @@ static inline void cpu_probe_ingenic(struct cpuinfo_mips *c, unsigned int cpu)
>>   		c->cputype = CPU_XBURST;
>>   		c->writecombine = _CACHE_UNCACHED_ACCELERATED;
>>   		__cpu_name[cpu] = "Ingenic XBurst";
>> +		/*
>> +		 * config7 bit 4 is used to control a low-power mode in
>> +		 * XBurst architecture. This mode may cause errors in the
>> +		 * calculation of bogomips and loops_per_jiffy, set config7
>> +		 * bit 4 to disable this feature to prevent that.
>> +		 */
>> +		set_c0_config7(BIT(4));
> I happen to know what this bit does - see this old patch for an
> explanation:
>
>    https://github.com/paulburton/linux/commit/0d72377bd615d00e99733adc0d37e6a2373fcde7
>
> In short it disables a loop optimization in the CPU that is supposed to
> special case loops & prevent them from relying upon the BTB.
> Unfortunately that loop optimization negatively affects short loops,
> such as in __delay(), and Ingenic's vendor kernels have generally set
> this bit to disable it.
>
> Note though that bogomips is bogus, so changing the bogomips value is
> really not good justification for the patch at all (which is why I've so
> far not bothered upstreaming the patch linked above). The best
> justification I can think of is that Ingenic set the bit in their
> downstream kernels, which presumably means it's beneficial overall (or
> just that someone cares too much about bogomips).
>
> In any case, one thing I don't know for sure is which CPU versions are
> affected. I don't believe this affected older devices like the JZ4740,
> and my copy of the XBurst1 CPU Core Programming Manual documents the bit
> as reserved. Given that you're seeing the X1000 is affected, and I know
> the JZ4780 is affected, that covers at least 2 different PRIDs so we
> can't just check for that.
>
> Hopefully writing to the bit is just a no-op on older systems if it is
> actually reserved, but it'd be great if we could test that.
>
> At the very least we should define the bit in asm/mipsregs.h & properly
> document what it does - using BIT(4) here may be a little nicer than
> (1<<4), but it's still just a magic number. I don't mind if you want to
> fix your patch to do that, or one of us can resurrect mine which has
> that information already.
I have verified the Ingenic's CPU department. According to their reply,
all XBurst1 cores support this feature. Therefore, it is safe to turn off it
in XBurst1.

However, the hardware that I can use normally is JZ4760 and later, so
the JZ4730/JZ4740/JZ4750 has not been tested. So for safe we can also
turn off this feature only in JZ4760 and later if necessary. Wait for your
comments and if necessary I will change it in v4.
>>   		break;
>>   	default:
>>   		panic("Unknown Ingenic Processor ID!");
>> diff --git a/arch/mips/mm/sc-mips.c b/arch/mips/mm/sc-mips.c
>> index 9385ddb..ed953d4 100644
>> --- a/arch/mips/mm/sc-mips.c
>> +++ b/arch/mips/mm/sc-mips.c
>> @@ -215,6 +215,14 @@ static inline int __init mips_sc_probe(void)
>>   	else
>>   		return 0;
>>   
>> +	/*
>> +	 * According to config2 it would be 512-sets, but that is contradicted
>> +	 * by all documentation.
>> +	 */
>> +	if (current_cpu_type() == CPU_XBURST &&
>> +				mips_machtype == MACH_INGENIC_X1000)
>> +		c->scache.sets = 256;
>> +
>>   	tmp = (config2 >> 0) & 0x0f;
>>   	if (tmp <= 7)
>>   		c->scache.ways = tmp + 1;
>> @@ -225,9 +233,13 @@ static inline int __init mips_sc_probe(void)
>>   	 * According to config2 it would be 5-ways, but that is contradicted
>>   	 * by all documentation.
>>   	 */
>> -	if (current_cpu_type() == CPU_XBURST &&
>> -				mips_machtype == MACH_INGENIC_JZ4770)
>> -		c->scache.ways = 4;
>> +	if (current_cpu_type() == CPU_XBURST) {
>> +		switch (mips_machtype) {
>> +		case MACH_INGENIC_JZ4770:
>> +		case MACH_INGENIC_X1000:
>> +			c->scache.ways = 4;
>> +		}
>> +	}
>>   
>>   	c->scache.waysize = c->scache.sets * c->scache.linesz;
>>   	c->scache.waybit = __ffs(c->scache.waysize);
> Given that we need to fix up both sets & ways, I think this would be
> cleaner if both were done in the switch statement here after we've read
> the values from Config2. ie. something like:
>
> 	if (current_cpu_type() == CPU_XBURST) {
> 		switch (mips_machtype) {
> 		case MACH_INGENIC_JZ4770:
> 			c->scache.ways = 4;
> 			break;
>
> 		case MACH_INGENIC_X1000:
> 			c->scache.sets = 256;
> 			c->scache.ways = 4;
> 			break;
> 		}
> 	}
>
> With appropriate comments added for each machine/SoC.

Thanks for you advice. I have change it in v3.
>
> Thanks,
>      Paul




  reply	other threads:[~2019-08-01 10:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30 14:55 MIPS: Ingenic: Fix bugs when detecting X1000's parameters Zhou Yanjie
2019-07-30 14:55 ` [PATCH] " Zhou Yanjie
2019-07-30 18:02   ` Paul Cercueil
2019-07-31  4:32     ` Zhou Yanjie
2019-07-31  4:39 ` MIPS: Ingenic: Fix bugs when detecting X1000's parameters v2 Zhou Yanjie
2019-07-31  4:39   ` [PATCH v2] MIPS: Ingenic: Fix bugs when detecting X1000's parameters Zhou Yanjie
2019-07-31 20:34     ` Paul Burton
2019-08-01 10:55       ` Zhou Yanjie [this message]
2019-08-01 12:16 ` MIPS: Ingenic: Fix bugs when detecting X1000's parameters v3 Zhou Yanjie
2019-08-01 12:16   ` [PATCH 1/2 v3] MIPS: Ingenic: Fix bugs when detecting X1000's L2 cache Zhou Yanjie
2019-08-01 12:16   ` [PATCH 2/2 v3] MIPS: Ingenic: Fix bugs when calculate bogomips/lpj Zhou Yanjie
2019-08-02  1:26     ` Paul Cercueil
2019-08-02  8:13       ` Zhou Yanjie
2019-08-02 17:32       ` Paul Burton
2019-08-02  8:27 ` MIPS: Ingenic: Fix bugs when detecting X1000's parameters v4 Zhou Yanjie
2019-08-02  8:27   ` [PATCH 1/2 v4] MIPS: Ingenic: Fix bugs when detecting X1000's L2 cache Zhou Yanjie
2019-08-06 23:02     ` Paul Burton
2019-08-02  8:27   ` [PATCH 2/2 v4] MIPS: Ingenic: Disable broken BTB lookup optimization Zhou Yanjie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5D42C51E.1090906@zoho.com \
    --to=zhouyanjie@zoho.com \
    --cc=allison@lohutok.net \
    --cc=chenhc@lemote.com \
    --cc=jhogan@kernel.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=malat@debian.org \
    --cc=paul.burton@mips.com \
    --cc=paul@crapouillou.net \
    --cc=ralf@linux-mips.org \
    --cc=syq@debian.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).