public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Leo Liang <ycliang@andestech.com>
To: Xiang W <wxjstz@126.com>
Cc: <u-boot@lists.denx.de>, <anup.patel@wdc.com>,
	<atish.patra@wdc.com>, <bmeng.cn@gmail.com>, <rick@andestech.com>,
	<lukas.auer@aisec.fraunhofer.de>
Subject: Re: [PATCH v2] riscv: cancel the limitation that NR_CPUS is less than or equal to 32
Date: Wed, 29 Dec 2021 17:23:10 +0800	[thread overview]
Message-ID: <20211229092310.GA1314619@atcsi01> (raw)
In-Reply-To: <20211221233253.123268-1-wxjstz@126.com>

Hi Xiang,
On Wed, Dec 22, 2021 at 07:32:53AM +0800, Xiang W wrote:
> Various specifications of riscv allow the number of hart to be
> greater than 32. The limit of 32 is determined by
> gd->arch.available_harts. We can eliminate this limitation through
> bitmaps. Currently, the number of hart is limited to 4095, and 4095
> is the limit of the RISC-V Advanced Core Local Interruptor
> Specification.
> 
> Test on sifive unmatched.
> 
> Signed-off-by: Xiang W <wxjstz@126.com>
> ---
> Changes since v1:
> 
> * When NR_CPUS is very large, the value of GD_AVAILABLE_HARTS will
>   overflow the immediate range of ld/lw. This patch fixes this
>   problem
> 
>  arch/riscv/Kconfig                   |  4 ++--
>  arch/riscv/cpu/start.S               | 21 ++++++++++++++++-----
>  arch/riscv/include/asm/global_data.h |  4 +++-
>  arch/riscv/lib/smp.c                 |  2 +-
>  4 files changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index 76850ec9be..92f3b78f29 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -166,11 +166,22 @@ wait_for_gd_init:
>  	mv	gp, s0
>  
>  	/* register available harts in the available_harts mask */
> -	li	t1, 1
> -	sll	t1, t1, tp
> -	LREG	t2, GD_AVAILABLE_HARTS(gp)
> -	or	t2, t2, t1
> -	SREG	t2, GD_AVAILABLE_HARTS(gp)
> +	li	t1, GD_AVAILABLE_HARTS
> +	add	t1, t1, gp
> +	LREG	t1, 0(t1)
> +#if defined(CONFIG_ARCH_RV64I)
> +	srli	t2, tp, 6
> +	slli	t2, t2, 3
> +#elif defined(CONFIG_ARCH_RV32I)
> +	srli	t2, tp, 5
> +	slli	t2, t2, 2
> +#endif
> +	add	t1, t1, t2
> +	LREG	t2, 0(t1)
> +	li	t3, 1
> +	sll	t3, t3, tp
This seems incorrect.
Shouldn't we have "$tp % sizeof(ulong)" instead of "$tp / sizeof(ulong)" ?
> +	or	t2, t2, t3
> +	SREG	t2, 0(t1)
>  
>  	amoswap.w.rl zero, zero, 0(t0)
Best regards,
Leo

  reply	other threads:[~2021-12-29  9:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21 23:32 [PATCH v2] riscv: cancel the limitation that NR_CPUS is less than or equal to 32 Xiang W
2021-12-29  9:23 ` Leo Liang [this message]
2021-12-29 17:55   ` Xiang W
2022-01-03 11:11     ` Leo Liang
2023-02-03 14:24       ` David Abdurachmanov
2023-02-06  8:07         ` Leo Liang
2023-02-10  7:25         ` Leo Liang
2023-02-11 14:11           ` Xiang W
2023-02-13  8:46             ` Leo Liang

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=20211229092310.GA1314619@atcsi01 \
    --to=ycliang@andestech.com \
    --cc=anup.patel@wdc.com \
    --cc=atish.patra@wdc.com \
    --cc=bmeng.cn@gmail.com \
    --cc=lukas.auer@aisec.fraunhofer.de \
    --cc=rick@andestech.com \
    --cc=u-boot@lists.denx.de \
    --cc=wxjstz@126.com \
    /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