Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1704858rwd; Sun, 21 May 2023 04:46:10 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ65Har6sYvbFnaJnmB7Qd6QGO6XNcFmrnbo6gok1mM9me7phHCvUIEaVC3dNwN5Z11hje0P X-Received: by 2002:a05:6a00:188e:b0:64d:3227:b800 with SMTP id x14-20020a056a00188e00b0064d3227b800mr10936295pfh.16.1684669569801; Sun, 21 May 2023 04:46:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684669569; cv=none; d=google.com; s=arc-20160816; b=Brp7sMjF2EDTaW5ZZFk9EjiQCz+urPHwJ3pnDboTNaGpf4NxiBn9urQNhqnFgB3JPB tXY+/0iqqRfA71QBJpumpmQs1hhtXwdEBYIGYSFVxC6nr8S922aifcJqg9jl4C9xgmx4 HcZs1ifI1NVfGP+bp8C7M118X4c0si0YbuVTnTVYWKBgk/DLXv+UNSEgraKD9FhBfOUe G96XzSsWt3b/tTg0HH75lYdujzLVEX9+BD8m+GOGR7LuxLbfk5LkJYUT0QBj+5QsPhOH jcQ6vpZCwBVEnydsqKS4gR34vQCpaA3UQY5SRr0mF8EcVsnNf9y6K3WZAfDtInTKkV9w fQcg== 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=aAA6hXVb2FfMcB0+/kQyUbmnhC5dqGE1lSd56CMNx9I=; b=Cs8kGOMat+5s0xt/Pa/lCQBuWM4rdnT+BOvhLY4R5vX/4mgaBT9CtomRrnrXGkTWgM 4uEYjVPdO1zdqyTDavmQg8sdodtH5XNTHHPrhUVc/Yfp5ftuUxemkfech4ppDCwZ4mH0 hUZ+6IaTxBcqjN5w0eTW6EQL+g1fxuc+bBaVeHdyYcieYra05fPE3Ng7yRHXSNcE2spP lIiPZ7mBbvuARiR2l79D7FIMAqn3TpRlDOmHVppfdA1QwEQzwomE29OX8mE1WDDTZuW6 YCebryrhnn7x7vllEEGP2JyWgbroR6CxacOKvceAXRi6qqfYS7KILPl7nmP+PE9UruTt sL5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="bK1LHT/Y"; 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 q4-20020aa79604000000b006367f3bb8a9si3052734pfg.249.2023.05.21.04.45.55; Sun, 21 May 2023 04:46:09 -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="bK1LHT/Y"; 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 S229980AbjEUJxU (ORCPT + 99 others); Sun, 21 May 2023 05:53:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229511AbjEUJwI (ORCPT ); Sun, 21 May 2023 05:52:08 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C99DF1; Sun, 21 May 2023 02:52:07 -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 C5E9F60BC4; Sun, 21 May 2023 09:52:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3937C433D2; Sun, 21 May 2023 09:52:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684662726; bh=sF3fGO7U/xMB1sIbnknNsRZycdV/4okIPZSR/hPio8U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bK1LHT/YeUymJe+bmviXtp5mkVbBYHgww5sdBnnL4Aq3MazisAdOr9Eoh9KjEMT46 82WZxC27NLxnfDCkF9uoXRKThZaEhEGRvOijdZfL3Dg9LC1nfZK4cFX/gkotJdEUqF BMzsUHQEJzUnp2QhLRs4Ze0sRtWnRRogDb91smVpGALFwHdfzyNnP2k8Fn8So76cOl q+EWVBh/+JWPenfQAEbGuV8TdVl/u62JI0TJ+OdcfqdjeEVk36Elutf1GOsSV6uA4c Sq+ugXJhR8kJJ/yqcmmmsut0OYwKWo1L0eBpsipjXsXR7qLebKKv0sCH4uncaIZc0G IGU00kotUCwRw== Date: Sun, 21 May 2023 17:40:53 +0800 From: Jisheng Zhang To: Samuel Holland Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-serial@vger.kernel.org, Palmer Dabbelt , Thomas Gleixner , Marc Zyngier , Palmer Dabbelt , Paul Walmsley , Albert Ou , Greg Kroah-Hartman , Jiri Slaby Subject: Re: [PATCH v4 08/10] riscv: dts: bouffalolab: add Sipeed M1s SoM and Dock devicetree Message-ID: References: <20230518152244.2178-1-jszhang@kernel.org> <20230518152244.2178-9-jszhang@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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 Thu, May 18, 2023 at 10:55:21PM -0500, Samuel Holland wrote: > Hi Jisheng, > > On 5/18/23 10:22, Jisheng Zhang wrote: > > Sipeed manufactures a M1s system-on-module and dock board, add basic > > support for them. > > > > Signed-off-by: Jisheng Zhang > > Acked-by: Palmer Dabbelt > > --- > > arch/riscv/boot/dts/Makefile | 1 + > > arch/riscv/boot/dts/bouffalolab/Makefile | 2 ++ > > .../dts/bouffalolab/bl808-sipeed-m1s-dock.dts | 25 +++++++++++++++++++ > > .../dts/bouffalolab/bl808-sipeed-m1s.dtsi | 21 ++++++++++++++++ > > 4 files changed, 49 insertions(+) > > create mode 100644 arch/riscv/boot/dts/bouffalolab/Makefile > > create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts > > create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi > > > > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile > > index f0d9f89054f8..133e6c38c9b0 100644 > > --- a/arch/riscv/boot/dts/Makefile > > +++ b/arch/riscv/boot/dts/Makefile > > @@ -1,5 +1,6 @@ > > # SPDX-License-Identifier: GPL-2.0 > > subdir-y += allwinner > > +subdir-y += bouffalolab > > subdir-y += sifive > > subdir-y += starfive > > subdir-y += canaan > > diff --git a/arch/riscv/boot/dts/bouffalolab/Makefile b/arch/riscv/boot/dts/bouffalolab/Makefile > > new file mode 100644 > > index 000000000000..5419964e892d > > --- /dev/null > > +++ b/arch/riscv/boot/dts/bouffalolab/Makefile > > @@ -0,0 +1,2 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +dtb-$(CONFIG_SOC_BOUFFALOLAB) += bl808-sipeed-m1s-dock.dtb > > diff --git a/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts > > new file mode 100644 > > index 000000000000..aa6cf909cd4d > > --- /dev/null > > +++ b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts > > @@ -0,0 +1,25 @@ > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT) > > +/* > > + * Copyright (C) 2022 Jisheng Zhang > > + */ > > + > > +/dts-v1/; > > + > > +#include "bl808-sipeed-m1s.dtsi" > > + > > +/ { > > + model = "Sipeed M1s Dock"; > > + compatible = "sipeed,m1s-dock", "sipeed,m1s", "bouffalolab,bl808"; > > + > > + aliases { > > + serial3 = &uart3; > > + }; > > + > > + chosen { > > + stdout-path = "serial3:2000000n8"; > > + }; > > +}; > > + > > +&uart3 { > > + status = "okay"; > > +}; > > diff --git a/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi > > new file mode 100644 > > index 000000000000..5026de768534 > > --- /dev/null > > +++ b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi > > @@ -0,0 +1,21 @@ > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT) > > +/* > > + * Copyright (C) 2022 Jisheng Zhang > > + */ > > + > > +/dts-v1/; > > + > > +#include "bl808.dtsi" > > + > > +/ { > > + compatible = "sipeed,m1s", "bouffalolab,bl808"; > > + > > + memory@50000000 { > > + device_type = "memory"; > > + reg = <0x50000000 0x04000000>; > > + }; > > Especially since the SoC contains three heterogeneous CPUs, the firmware > may want to divide the PSRAM among them, so I do not think it is a good > idea to define this statically. (Or would all of the DTs contain this do you want the bootloader/firmware e.g uboot to add the memory node dynamically? But to be honest, nowdays most SoCs contain some heterogeneous CPUs, and in real products some of those CPUs need to use DDR memory. FWICT, their dtbs(in arch/arm64/boot/dts/...) still define the memory statically. I believe this is acchieved by dynamically update the memory node of DT. This solution doesn't make obvious difference with the uboot adding memory node solution. > same node, and then use reserved-memory nodes to cover the other CPUs' > allocations?) > > Regards, > Samuel > > > +}; > > + > > +&xtal { > > + clock-frequency = <40000000>; > > +}; >