All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Pei <huangpei@loongson.cn>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: ambrosehua@gmail.com, Bibo Mao <maobibo@loongson.cn>,
	linux-mips@vger.kernel.org, Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Paul Burton <paulburton@kernel.org>,
	Li Xuefeng <lixuefeng@loongson.cn>,
	Yang Tiezhu <yangtiezhu@loongson.cn>,
	Gao Juxin <gaojuxin@loongson.cn>,
	Huacai Chen <chenhuacai@loongson.cn>
Subject: Re: [PATCH 4/4] MIPS: loongson64: fix FTLB configuration
Date: Tue, 30 Nov 2021 19:42:05 +0800	[thread overview]
Message-ID: <20211130114204.l2vvn7de337mznp3@loongson-pc> (raw)
In-Reply-To: <20211130103448.GA9643@alpha.franken.de>

On Tue, Nov 30, 2021 at 11:34:48AM +0100, Thomas Bogendoerfer wrote:
> On Fri, Nov 26, 2021 at 11:13:19AM +0800, Huang Pei wrote:
> > On Thu, Nov 25, 2021 at 04:55:28PM +0100, Thomas Bogendoerfer wrote:
> > > On Thu, Nov 25, 2021 at 06:59:49PM +0800, Huang Pei wrote:
> > > > It turns out that 'decode_configs' -> 'set_ftlb_enable' is called under
> > > > c->cputype unset, which leaves FTLB disabled on BOTH 3A2000 and 3A3000
> > > > 
> > > > Fix it by calling "decode_configs" after c->cputype is initialized
> > > > 
> > > > Fixes: da1bd29742b1 ("MIPS: Loongson64: Probe CPU features via CPUCFG")
> > > > Signed-off-by: Huang Pei <huangpei@loongson.cn>
> > > > ---
> > > >  arch/mips/kernel/cpu-probe.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
> > > > index ac0e2cfc6d57..24a529c6c4be 100644
> > > > --- a/arch/mips/kernel/cpu-probe.c
> > > > +++ b/arch/mips/kernel/cpu-probe.c
> > > > @@ -1734,8 +1734,6 @@ static inline void decode_cpucfg(struct cpuinfo_mips *c)
> > > >  
> > > >  static inline void cpu_probe_loongson(struct cpuinfo_mips *c, unsigned int cpu)
> > > >  {
> > > > -	decode_configs(c);
> > > > -
> > > >  	/* All Loongson processors covered here define ExcCode 16 as GSExc. */
> > > >  	c->options |= MIPS_CPU_GSEXCEX;
> > > >  
> > > > @@ -1796,6 +1794,8 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips *c, unsigned int cpu)
> > > >  		panic("Unknown Loongson Processor ID!");
> > > >  		break;
> > > >  	}
> > > > +
> > > > +	decode_configs(c);
> > > >  }
> > > >  #else
> > > >  static inline void cpu_probe_loongson(struct cpuinfo_mips *c, unsigned int cpu) { }
> > > > -- 
> > > > 2.20.1
> > > 
> > > applied to mips-fixes.
> > > 
> > > Thomas.
> > > 
> > > -- 
> > > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> > > good idea.                                                [ RFC1925, 2.3 ]
> > Hi, Thomas,
> > 
> > What about PATCH 1/4, without it, kernel/trace/ring_buffer.i using
> > local_add_return, like this 
> > --------------------------------------------------------------------------------
> >     __asm__ __volatile__(
> > 	"     .set    push                                    \n"
> > 	"     .set    ""arch=r4000""                  \n"
> > 	".if (( 0x00 ) != -1) && ( (1 << 31) ); .set push; .set mips64r2;.rept 1; sync 
> > 	0x00; .endr; .set pop; .else; ; .endif" "\n"
> > 	"1:" "lld     " "%1, %2               # local_add_return\n"
> > 	"     addu    %0, %1, %3				\n"
> > 	"scd " "%0, %2						\n"
> > 	"     beqz    %0, 1b					\n"
> > 	"     addu    %0, %1, %3				\n"
> > 	"     .set    pop
> > 	\n"
> > 	: "=&r" (result), "=&r" (temp), "=m" (l->a.counter)
> > 	: "Ir" (i), "m" (l->a.counter)
> > 	: "memory");
> > } else if (1) {
> >   unsigned long temp;
> > 
> >     __asm__ __volatile__(
> > 	    "     .set    push                                    \n"
> > 	    "     .set    ""arch=r4000""                  \n"
> > 	    ".if (( 0x00 ) != -1) && ( (1 << 31) ); .set push; .set
> > 	    mips64r2; .rept 1; sync 0x00; .endr; .set pop; .else; ;
> > 	    .endif" "                    \n"
> > 	    "1:" "lld     " "%1, %2               # local_add_return
> > 	    \n"
> > 	    "     addu    %0, %1, %3                              \n"
> > 	    "scd " "%0, %2
> > 	    \n"
> > 	    "     beqz    %0, 1b
> > 	    \n"
> > 	    "     addu    %0, %1, %3
> > 	    \n"
> > 	    "     .set    pop
> > 	    \n"
> > 	    : "=&r" (result), "=&r" (temp), "=m"
> > 	    (l->a.counter)
> > 	    : "Ir" (i), "m" (l->a.counter)
> > 	    : "memory");
> > 
> > --------------------------------------------------------------------------------
> > it is wrong here, "lld" + "addu"
> 
> it fixes something, but I didn't see the impact from the commit message.
> Because there is no Fixes tag, I haven't applied it tomips-fixes.
> 
Sorry, this bug is introduced by 7232311ef14c274d88871212a07557f18f4140d1
> And
> 
> +#elif MIPS_ISA_REV >= 6
> +# define SC_BEQZ	beqzc
> 
> why are you doing this ?
This copies from arch/mips/include/asm/llsc.h, I had another patch which
remove llsc.h. I do not want add that patch into bugfix;

> > and PATCH 2, any comment?
> 
> parameter page already contains the virtual address of the page to
> flush, so there is nothing to fix. I'm not 100% about the cache
> nature of all TX39 core, so leaving the check for cpu_has_dc_aliases
> in place is the safer bet. And this platform is nearly dead, so I'm
> sure sure whether this sort of cosemtics is needed.
> 
Based on the comment, I can see TX39 want to bypass TLB by Indexed Cache
Operation,  because with KSEG0 address, Indexed Cache Operation does not 
pass through TLB; But there are two limitation:

+. KSEG0 only cover first 512MB physical address, so do not support 
High Memory, if not using KSEG0 address ,then it passes through TLB, which
is not intended;

+. Indexed Cache Operation can overkill cache line with same cache index
from different way, but it can not kill Cache Alias, since Cache Alias
actually has different cache index;

From datasheet of TX39xx, I know the R3900 core of TX39 series has only
4KB direct-mapped Icache and 2KB two-way Dcache, so it has no Cache 
Alias under 4KB page size, and I can assume it does not support memory
beyond 512MB based on Kconfig of TX39, AKA no High Memory;

Above all, I think it is OK to both use KSEG0 address and remove cpu_has_dc_alias 

> Thomas.
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]


  reply	other threads:[~2021-11-30 11:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-25 10:59 [PATCH V4]: bugfix Huang Pei
2021-11-25 10:59 ` [PATCH 1/4] MIPS: rework local_t operation on MIPS64 Huang Pei
2021-11-25 10:59 ` [PATCH 2/4] MIPS: tx39: fix tx39_flush_cache_page Huang Pei
2021-11-25 10:59 ` [PATCH 3/4] MIPS: use 3-level pgtable for 64KB page size on MIPS_VA_BITS_48 Huang Pei
2021-11-25 15:55   ` Thomas Bogendoerfer
2021-11-25 10:59 ` [PATCH 4/4] MIPS: loongson64: fix FTLB configuration Huang Pei
2021-11-25 15:55   ` Thomas Bogendoerfer
2021-11-26  3:13     ` Huang Pei
2021-11-30 10:34       ` Thomas Bogendoerfer
2021-11-30 11:42         ` Huang Pei [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-11-24 10:12 [PATCH V3 resend]: bugfix Huang Pei
2021-11-24 10:12 ` [PATCH 4/4] MIPS: loongson64: fix FTLB configuration Huang Pei
2021-11-24 12:35   ` Sergey Shtylyov
2021-11-24  3:50 [PATCH V3]: bugfix Huang Pei
2021-11-24  3:50 ` [PATCH 4/4] MIPS: loongson64: fix FTLB configuration Huang Pei

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=20211130114204.l2vvn7de337mznp3@loongson-pc \
    --to=huangpei@loongson.cn \
    --cc=ambrosehua@gmail.com \
    --cc=chenhuacai@loongson.cn \
    --cc=gaojuxin@loongson.cn \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-mips@vger.kernel.org \
    --cc=lixuefeng@loongson.cn \
    --cc=maobibo@loongson.cn \
    --cc=paulburton@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=yangtiezhu@loongson.cn \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.