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;
Date:   Sun, 7 May 2023 22:35:12 +0100
From:   Conor Dooley <conor@kernel.org>
To:     Jisheng Zhang <jszhang@kernel.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Marc Zyngier <maz@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
        linux-riscv@lists.infradead.org, Guo Ren <guoren@kernel.org>,
        heiko@sntech.de
Subject: Re: [PATCH 3/5] riscv: dts: add initial T-HEAD light SoC device tree
Message-ID: <20230507-calamari-gentleman-bbe62af06f92@spud>
References: <20230507182304.2934-1-jszhang@kernel.org>
 <20230507182304.2934-4-jszhang@kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="OKce/XdTtjQB3lJP"
Content-Disposition: inline
In-Reply-To: <20230507182304.2934-4-jszhang@kernel.org>
Precedence: bulk


--OKce/XdTtjQB3lJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey Jisheng,

On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote:

> +		c910_0: cpu@0 {
> +			compatible = "thead,c910", "riscv";
> +			device_type = "cpu";
> +			riscv,isa = "rv64imafdc";

Does this support more than "rv64imafdc"?
I assume there's some _xtheadfoo extensions that it does support,
although I am not sure how we are proceeding with those - Heiko might
have a more nuanced take.

> +		reset: reset-sample {
> +			compatible = "thead,reset-sample";

What is a "reset-sample"?

> +			entry-reg = <0xff 0xff019050>;
> +			entry-cnt = <4>;
> +			control-reg = <0xff 0xff015004>;
> +			control-val = <0x1c>;
> +			csr-copy = <0x7f3 0x7c0 0x7c1 0x7c2 0x7c3 0x7c5 0x7cc>;
> +		};
> +
> +		plic: interrupt-controller@ffd8000000 {
> +			compatible = "thead,c910-plic";
> +			reg = <0xff 0xd8000000 0x0 0x01000000>;
> +			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
> +					      <&cpu1_intc 11>, <&cpu1_intc 9>,
> +					      <&cpu2_intc 11>, <&cpu2_intc 9>,
> +					      <&cpu3_intc 11>, <&cpu3_intc 9>;
> +			interrupt-controller;
> +			#interrupt-cells = <1>;
> +			riscv,ndev = <240>;
> +		};
> +
> +		clint: timer@ffdc000000 {
> +			compatible = "thead,c900-clint";

"c900"? That a typo or intentional. Hard to tell since this compatible
is undocumented ;)

> +			reg = <0xff 0xdc000000 0x0 0x00010000>;
> +			interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
> +					      <&cpu1_intc 3>, <&cpu1_intc 7>,
> +					      <&cpu2_intc 3>, <&cpu2_intc 7>,
> +					      <&cpu3_intc 3>, <&cpu3_intc 7>;
> +		};
> +
> +		uart0: serial@ffe7014000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0xff 0xe7014000 0x0 0x4000>;
> +			interrupts = <36>;
> +			clocks = <&uart_sclk>;
> +			clock-names = "baudclk";

dtbs_check complains about this clock name.
> +
> +		dmac0: dmac@ffefc00000 {

dma-controller@

As I mentioned in the other patch, please clean up the dtbs_check
complaints for v2.

Cheers,
Conor.


--OKce/XdTtjQB3lJP
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZFgZkAAKCRB4tDGHoIJi
0gJkAP9TyzjHcuAsWbOpJ8RnqioUEWne+Q8oDh+GeealrSC1hAEAjWjGDNcOBF7i
EgCMKjbIUEwwPx/9ox6mnCrgpzj20gA=
=Xg5D
-----END PGP SIGNATURE-----

--OKce/XdTtjQB3lJP--