Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1056017rwd; Wed, 31 May 2023 08:56:02 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5WD0tnTaqdtkmzS3wR5pMgtNQW2wyE+cukhd2Xdq8bZqHk9ek/4qp65+lGh80tXktjp94b X-Received: by 2002:a17:902:d505:b0:1b0:663e:4b10 with SMTP id b5-20020a170902d50500b001b0663e4b10mr5227954plg.64.1685548562345; Wed, 31 May 2023 08:56:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685548562; cv=none; d=google.com; s=arc-20160816; b=Im5t8Sd7AqwYYpqmYIshsL/EmD5gxkDCuqstj3blk7cTbSxnZZxB/TGskKF4iyOSKb afhjwU2DYCMbS7bZphEeEBt+DN8wbRMgi6FoMW10bEopi6QydHI8v6y7kH/XOgRaULbo oIH+EDlthNWF/1JqzBSTbL7lKoR0+kPm5m3uWnX6Zjdsr8hEgVUv4dN5xIgCmSnaCH9J WZuUqzTJOnfyp5MvTmIIdXpqx8VqPwa8AVtQJGSJmrQE8OBwNIwzKBL0WKB0silSvh7U lSZEOKfEp3zCet/7YE2Ff9FDWFzJMnS1a8g9LQxxJeM5sDM6GQT0U+mIfdDgs+p0EHwX 6ngA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=DmrwLvsXTXujDrPKTeAYr0Chv7EIzk7YAIGwZr0nMoE=; b=UycXYBuTRQc3uRzg1WhYquaO0WY70gjr7iPpNQKGbFy9zJJCBTrFA5E9lgzrii1R6J bSuI+DKX+Vp0X2MbgcH2BvayerGWEE2EQfywamIQmReerPt3y1fBwiSMkv8iLCeNZdH+ K0vFIl9ELji2rgN5GMIQG55TjWmqvQYTqFO3ropAGU6Vxu3+4Y5wFdCtQ4bidFUK7CX/ YugmRP7zAkQq1UoZKqqxOeuLfaDBJ9OCFVWFnu8Sb/JrnN0rcfSXJPl0IakGzadLdPWp xW2Js6cgTxkbnM3yDIxG1uwV/p2vRmZueswy6wnA42zXRoI8J1dtjQMFOgLu8Ul85kQJ rQHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=VKxcX9Js; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id iw18-20020a170903045200b001b05c05cd65si1097726plb.3.2023.05.31.08.55.18; Wed, 31 May 2023 08:56:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=VKxcX9Js; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232979AbjEaPjm (ORCPT + 99 others); Wed, 31 May 2023 11:39:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230470AbjEaPjl (ORCPT ); Wed, 31 May 2023 11:39:41 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45E2A11D for ; Wed, 31 May 2023 08:39:40 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BA58660E9A for ; Wed, 31 May 2023 15:39:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5CBB4C433EF; Wed, 31 May 2023 15:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685547579; bh=gRRVW/9HX5SDK2Upr3j05g4cZEa7IhlENCUXLxaW21Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VKxcX9Js9T9W3YXFIWsl4ACmy/b+2ev7XJV8btoO3+hVNb6UfBoprYxI6hmiB70BV WH4aUdIsScHCOu0v6Hf4coSuENIpVMcOV6leiumqp5uQqCFenSrYCvh/iZf+uPElfd jsv1JNNfH1KAah2w0axzxam6tIgiDaOe1yiTCK4sX0PLvehplM/T82FIkbs0gNRzlY LK0ZM2I0NVjF1Wh9vmxCOwmldtdPj1wqSMq5KmQpmwSIWdWR3Cv/+uQID84/mLOszB JK0G9k94q/aNZ2MD5KmGdYzOHSVA7wPO5gW9pUDIv8bZHrw/eRsmf1d8LF8dM73Evj MYr5zj7bfZF0w== Date: Wed, 31 May 2023 23:28:22 +0800 From: Jisheng Zhang To: Conor Dooley Cc: Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Catalin Marinas Subject: Re: [PATCH 4/6] riscv: mm: pass noncoherent or not to riscv_noncoherent_supported() Message-ID: References: <20230526165958.908-1-jszhang@kernel.org> <20230526165958.908-5-jszhang@kernel.org> <20230529-gainfully-ribbon-48520d25ef6e@wendy> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 31, 2023 at 11:24:19PM +0800, Jisheng Zhang wrote: > On Mon, May 29, 2023 at 12:13:10PM +0100, Conor Dooley wrote: > > Hey Jisheng, > > Hi Conor, > > > > > On Sat, May 27, 2023 at 12:59:56AM +0800, Jisheng Zhang wrote: > > > We will soon take different actions by checking the HW is noncoherent > > > or not, I.E ZICBOM/ERRATA_THEAD_CMO or not. > > > > > > Signed-off-by: Jisheng Zhang > > > --- > > > arch/riscv/errata/thead/errata.c | 19 +++++++++++-------- > > > arch/riscv/include/asm/cacheflush.h | 4 ++-- > > > arch/riscv/kernel/setup.c | 6 +++++- > > > arch/riscv/mm/dma-noncoherent.c | 10 ++++++---- > > > 4 files changed, 24 insertions(+), 15 deletions(-) > > > > > > diff --git a/arch/riscv/errata/thead/errata.c b/arch/riscv/errata/thead/errata.c > > > index be84b14f0118..c192b80a5166 100644 > > > --- a/arch/riscv/errata/thead/errata.c > > > +++ b/arch/riscv/errata/thead/errata.c > > > @@ -36,21 +36,24 @@ static bool errata_probe_pbmt(unsigned int stage, > > > static bool errata_probe_cmo(unsigned int stage, > > > unsigned long arch_id, unsigned long impid) > > > { > > > - if (!IS_ENABLED(CONFIG_ERRATA_THEAD_CMO)) > > > - return false; > > > - > > > - if (arch_id != 0 || impid != 0) > > > - return false; > > > + bool cmo; > > > > > > if (stage == RISCV_ALTERNATIVES_EARLY_BOOT) > > > return false; > > > > > > + if (IS_ENABLED(CONFIG_ERRATA_THEAD_CMO) && > > > + (arch_id == 0 && impid == 0)) > > > + cmo = true; > > > + else > > > + cmo = false; > > > + > > > if (stage == RISCV_ALTERNATIVES_BOOT) { > > > - riscv_cbom_block_size = L1_CACHE_BYTES; > > > - riscv_noncoherent_supported(); > > > + if (cmo) > > > + riscv_cbom_block_size = L1_CACHE_BYTES; > > > + riscv_noncoherent_supported(cmo); > > > } > > > > > > - return true; > > > + return cmo; > > > > I don't really understand the changes that you are making to this > > function, so that is tries really hard to call > > riscv_noncoherent_supported(). Why do we need to always call the function > > in the erratum's probe function, if the erratum is not detected, given > > In one unified kernel Image, to support both coherent and noncoherent > platforms(currently, either T-HEAD CMO or ZICBOM), we need to let the > kmalloc meet both cases, specifically, ARCH_DMA_MINALIGN aligned. seems adding three words can make it better: kmalloc meet both cases at the beginning, specifically ... > Once we know the underlying HW is coherent, I.E neither T-HEAD CMO nor > ZICBOM, we need to notice kmalloc we are safe to reduce the alignment > to 1. The notice action is done in patch 5: > > + } else { > + dma_cache_alignment = 1; > > > > that riscv_noncoherent_supported() is called immediately after > > apply_boot_alternatives() in setup_arch()? > > > > > } > > > > > > static bool errata_probe_pmu(unsigned int stage, > > > diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h > > > index 8091b8bf4883..9d056c9b625a 100644 > > > --- a/arch/riscv/include/asm/cacheflush.h > > > +++ b/arch/riscv/include/asm/cacheflush.h > > > @@ -54,9 +54,9 @@ extern unsigned int riscv_cboz_block_size; > > > void riscv_init_cbo_blocksizes(void); > > > > > > #ifdef CONFIG_RISCV_DMA_NONCOHERENT > > > -void riscv_noncoherent_supported(void); > > > +void riscv_noncoherent_supported(bool cmo); > > > > I think it would "read better" if you renamed this variable to > > "have_cmo". > > > > > #else > > > -static inline void riscv_noncoherent_supported(void) {} > > > +static inline void riscv_noncoherent_supported(bool cmo) {} > > > #endif > > > > > > /* > > > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c > > > index 36b026057503..565f3e20169b 100644 > > > --- a/arch/riscv/kernel/setup.c > > > +++ b/arch/riscv/kernel/setup.c > > > @@ -264,6 +264,7 @@ static void __init parse_dtb(void) > > > > > > void __init setup_arch(char **cmdline_p) > > > { > > > + bool cmo; > > > parse_dtb(); > > > setup_initial_init_mm(_stext, _etext, _edata, _end); > > > > > > @@ -298,7 +299,10 @@ void __init setup_arch(char **cmdline_p) > > > apply_boot_alternatives(); > > > if (IS_ENABLED(CONFIG_RISCV_ISA_ZICBOM) && > > > riscv_isa_extension_available(NULL, ZICBOM)) > > > - riscv_noncoherent_supported(); > > > + cmo = true; > > > + else > > > + cmo = false; > > > + riscv_noncoherent_supported(cmo); > > > > As a nit, could you put a newline before the call to > > riscv_noncoherent_supported()? > > > > > } > > > > > > static int __init topology_init(void) > > > diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c > > > index d51a75864e53..0e172e2b4751 100644 > > > --- a/arch/riscv/mm/dma-noncoherent.c > > > +++ b/arch/riscv/mm/dma-noncoherent.c > > > @@ -72,9 +72,11 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, > > > dev->dma_coherent = coherent; > > > } > > > > > > -void riscv_noncoherent_supported(void) > > > +void riscv_noncoherent_supported(bool cmo) > > > { > > > - WARN(!riscv_cbom_block_size, > > > - "Non-coherent DMA support enabled without a block size\n"); > > > - noncoherent_supported = true; > > > + if (cmo) { > > > + WARN(!riscv_cbom_block_size, > > > + "Non-coherent DMA support enabled without a block size\n"); > > > + noncoherent_supported = true; > > > + } > > > > The other places that we do a WARN() because of screwed up devicetrees > > for CMO things, we do a WARN_TAINT(CPU_OUT_OF_SPEC). Should we do the > > same here too? > > > > Cheers, > > Conor. > >