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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02BBAC3DA7A for ; Wed, 28 Dec 2022 22:48:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229959AbiL1Wsy (ORCPT ); Wed, 28 Dec 2022 17:48:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229630AbiL1Wsx (ORCPT ); Wed, 28 Dec 2022 17:48:53 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE2D9140E9; Wed, 28 Dec 2022 14:48:52 -0800 (PST) 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 ams.source.kernel.org (Postfix) with ESMTPS id 786CBB81914; Wed, 28 Dec 2022 22:48:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2A96C433D2; Wed, 28 Dec 2022 22:48:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672267730; bh=NpdedqY/UTF4uGtmQnKeb03AizfJv69Dyw7+UYmfMTI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OrtpYwSOR4m8WnCl/Mf8LMEdEVVsPneyDJF41yJ6LWb6/7YXTotxA0t2lQ60MNvrG pBPfRBZHNDLFWGzbZb1dXpGynJeo2YHWG1AdK8pZjEeHk+WfnFI/I6dsnnLtQ8pLIv TZGNX5k+YTsivGZdaEDyaj4CnwOGmmuCLjnnSHnI95SIaCmyP9jwnEpUtDGI0O9T51 xE51e4n9UbZF9IHZBula35YMhCYhTo0koHBu00NZ4O2YH3A7j33So0AvFvvua900V7 wSs9xfZ28XGmgpZvy/xfHrBhHn2FmduADwgy9PhgxCISlEXQwzSleIrZm+dAUd0o/T PpXaUKLi65t5A== Date: Wed, 28 Dec 2022 22:48:43 +0000 From: Conor Dooley To: Hal Feng Cc: linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, Palmer Dabbelt , Rob Herring , Krzysztof Kozlowski , Paul Walmsley , Albert Ou , Ben Dooks , Daniel Lezcano , Thomas Gleixner , Marc Zyngier , Stephen Boyd , Michael Turquette , Philipp Zabel , Linus Walleij , Emil Renner Berthing , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 6/7] riscv: dts: starfive: Add initial StarFive JH7110 device tree Message-ID: References: <20221220011247.35560-1-hal.feng@starfivetech.com> <20221220011247.35560-7-hal.feng@starfivetech.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ANn4P8tMvc1B4Y18" Content-Disposition: inline In-Reply-To: <20221220011247.35560-7-hal.feng@starfivetech.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org --ANn4P8tMvc1B4Y18 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, On Tue, Dec 20, 2022 at 09:12:46AM +0800, Hal Feng wrote: > From: Emil Renner Berthing >=20 > Add initial device tree for the JH7110 RISC-V SoC by StarFive > Technology Ltd. >=20 > Signed-off-by: Emil Renner Berthing > Co-developed-by: Jianlong Huang > Signed-off-by: Jianlong Huang > Co-developed-by: Hal Feng > Signed-off-by: Hal Feng > --- > arch/riscv/boot/dts/starfive/jh7110.dtsi | 411 +++++++++++++++++++++++ > 1 file changed, 411 insertions(+) > create mode 100644 arch/riscv/boot/dts/starfive/jh7110.dtsi >=20 > diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/d= ts/starfive/jh7110.dtsi > new file mode 100644 > index 000000000000..64d260ea1f29 > --- /dev/null > +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi > @@ -0,0 +1,411 @@ > +// SPDX-License-Identifier: GPL-2.0 OR MIT > +/* > + * Copyright (C) 2022 StarFive Technology Co., Ltd. > + * Copyright (C) 2022 Emil Renner Berthing > + */ > + > +/dts-v1/; > +#include > +#include > + > +/ { > + compatible =3D "starfive,jh7110"; > + #address-cells =3D <2>; > + #size-cells =3D <2>; > + > + cpus { > + #address-cells =3D <1>; > + #size-cells =3D <0>; > + > + S76_0: cpu@0 { > + compatible =3D "sifive,u74-mc", "riscv"; The label here says S76 but the compatible says u74-mc. Which is correct? Your docs say S7 and S76, so I would imagine that it is actually an S76? > + reg =3D <0>; > + d-cache-block-size =3D <64>; > + d-cache-sets =3D <64>; > + d-cache-size =3D <8192>; > + d-tlb-sets =3D <1>; > + d-tlb-size =3D <40>; > + device_type =3D "cpu"; > + i-cache-block-size =3D <64>; > + i-cache-sets =3D <64>; > + i-cache-size =3D <16384>; > + i-tlb-sets =3D <1>; > + i-tlb-size =3D <40>; > + mmu-type =3D "riscv,sv39"; > + next-level-cache =3D <&ccache>; > + riscv,isa =3D "rv64imac"; While I was poking around trying to see if there was some logic behind that compatible, I noticed that SiFive's docs for the S76 say it is RV64GBC *but* the docs for the u74-mc say "4xRV64GBC and 1xRV64IMAC". I assume that rv64imac is the correct one here? > + tlb-split; > + status =3D "disabled"; > + > + cpu0_intc: interrupt-controller { > + compatible =3D "riscv,cpu-intc"; > + interrupt-controller; > + #interrupt-cells =3D <1>; > + }; > + }; > + > + U74_1: cpu@1 { > + compatible =3D "sifive,u74-mc", "riscv"; > + reg =3D <1>; > + d-cache-block-size =3D <64>; > + d-cache-sets =3D <64>; > + d-cache-size =3D <32768>; > + d-tlb-sets =3D <1>; > + d-tlb-size =3D <40>; > + device_type =3D "cpu"; > + i-cache-block-size =3D <64>; > + i-cache-sets =3D <64>; > + i-cache-size =3D <32768>; > + i-tlb-sets =3D <1>; > + i-tlb-size =3D <40>; > + mmu-type =3D "riscv,sv39"; > + next-level-cache =3D <&ccache>; > + riscv,isa =3D "rv64imafdc"; That also begs the question: Do your u74s support RV64GBC, as the (current) SiFive documentation suggests? Thanks, Conor. --ANn4P8tMvc1B4Y18 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCY6zHywAKCRB4tDGHoIJi 0qgIAP9goDzTR6Vrk3MaunduxIAwBUWHl3xCKWlRZnoQe55+eAD9HZ6QEMK242tX +jlk7hQ1SjjbYoeCLbpCrF0OoheU2Q4= =lZyu -----END PGP SIGNATURE----- --ANn4P8tMvc1B4Y18--