From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E11F5C433F5 for ; Wed, 29 Dec 2021 09:24:52 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A94D983033; Wed, 29 Dec 2021 10:24:49 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=andestech.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id AB61182FB4; Wed, 29 Dec 2021 10:24:47 +0100 (CET) Received: from ATCSQR.andestech.com (exmail.andestech.com [60.248.187.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id D895E82FB4 for ; Wed, 29 Dec 2021 10:24:43 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=andestech.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ycliang@andestech.com Received: from mail.andestech.com (ATCPCS16.andestech.com [10.0.1.222]) by ATCSQR.andestech.com with ESMTP id 1BT9NHbe021374; Wed, 29 Dec 2021 17:23:17 +0800 (GMT-8) (envelope-from ycliang@andestech.com) Received: from atcsi01 (10.0.15.167) by ATCPCS16.andestech.com (10.0.1.222) with Microsoft SMTP Server id 14.3.498.0; Wed, 29 Dec 2021 17:23:15 +0800 Date: Wed, 29 Dec 2021 17:23:10 +0800 From: Leo Liang To: Xiang W CC: , , , , , Subject: Re: [PATCH v2] riscv: cancel the limitation that NR_CPUS is less than or equal to 32 Message-ID: <20211229092310.GA1314619@atcsi01> References: <20211221233253.123268-1-wxjstz@126.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20211221233253.123268-1-wxjstz@126.com> User-Agent: Mutt/1.13.2 (2019-12-18) X-Originating-IP: [10.0.15.167] X-DNSRBL: X-MAIL: ATCSQR.andestech.com 1BT9NHbe021374 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean 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 > --- > 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