Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Huang Pei <huangpei@loongson.cn>
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 11:34:48 +0100	[thread overview]
Message-ID: <20211130103448.GA9643@alpha.franken.de> (raw)
In-Reply-To: <20211126031319.kfhemh73dyq4rkra@loongson-pc>

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.

And

+#elif MIPS_ISA_REV >= 6
+# define SC_BEQZ	beqzc

why are you doing this ?

> 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.

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 10:35 UTC|newest]

Thread overview: 12+ 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 [this message]
2021-11-30 11:42         ` Huang Pei
  -- 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

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=20211130103448.GA9643@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=ambrosehua@gmail.com \
    --cc=chenhuacai@loongson.cn \
    --cc=gaojuxin@loongson.cn \
    --cc=huangpei@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox