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 X-Spam-Level: X-Spam-Status: No, score=-14.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 530D6C2B9F7 for ; Tue, 25 May 2021 02:13:51 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CA07B6141D for ; Tue, 25 May 2021 02:13:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CA07B6141D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sntech.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Fk+YP9i9S0yjdoHhcgqWVawObYfWtk+7WFVfNFQALwg=; b=cIIype1AjKcZY5 S7vRYUp6NsaaCb46lkQkcuOIqjtiVcnfpAIet/cl0QcGC6DcQ4baBXghFE8TFBD4XOUnuc0fi/2f5 PgJD8cb0Tkl9fL/TJ7/idITfNDXcG3ZVbsqwPfSWQ1aqKi3H8ayfDUNuye+iK0QeXL+OV5ubNj31e fxmak1ubAcDmSyAiqHQff9SGcIh+tWviacwO2RGtafZDoGBr6YfMGt9ySGxrNyGPLe78FhzALncoZ PaFzvbw14K2rbuLYTe4mDwyjD2fT86otWYYxKVlqBWxtFbTFgmNF0r4s012sQhe+ZddH8Dp2mHPqu ttowgyKrCNQ1PZD+L48A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1llMXp-002rqh-2V; Tue, 25 May 2021 02:11:45 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1llHsn-001uK1-2R; Mon, 24 May 2021 21:13:09 +0000 Received: from ip5f5aa64a.dynamic.kabel-deutschland.de ([95.90.166.74] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1llHsk-0008Me-To; Mon, 24 May 2021 23:13:02 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Andreas =?ISO-8859-1?Q?F=E4rber?= , Marc Zyngier Cc: linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Rob Herring , devicetree@vger.kernel.org Subject: Re: [PATCH 3/9] arm64: dts: rockchip: Prepare Rockchip RK1808 Date: Mon, 24 May 2021 23:13:03 +0200 Message-ID: <3998020.X9hSmTKtgW@diego> In-Reply-To: <87fsycw41m.wl-maz@kernel.org> References: <20210516230551.12469-1-afaerber@suse.de> <7ef183f1-00f8-13c4-1fd3-eae9e0bbf74c@suse.de> <87fsycw41m.wl-maz@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210524_141305_159728_C38A45A1 X-CRM114-Status: GOOD ( 28.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am Montag, 24. Mai 2021, 17:21:41 CEST schrieb Marc Zyngier: > On Mon, 24 May 2021 14:32:41 +0100, > Andreas F=E4rber wrote: > > = > > On 17.05.21 11:21, Marc Zyngier wrote: > > > On Mon, 17 May 2021 00:05:45 +0100, > > > Andreas F=E4rber wrote: > > >> > > >> Add an initial Device Tree for Rockchip RK1808 SoC. > > >> Based on shipping TB-RK1808M0 DTB. > > >> > > >> Signed-off-by: Andreas F=E4rber > > >> --- > > >> arch/arm64/boot/dts/rockchip/rk1808.dtsi | 203 ++++++++++++++++++++= +++ > > >> 1 file changed, 203 insertions(+) > > >> create mode 100644 arch/arm64/boot/dts/rockchip/rk1808.dtsi > > >> > > >> diff --git a/arch/arm64/boot/dts/rockchip/rk1808.dtsi b/arch/arm64/b= oot/dts/rockchip/rk1808.dtsi > > >> new file mode 100644 > > >> index 000000000000..af2b51afda7d > > >> --- /dev/null > > >> +++ b/arch/arm64/boot/dts/rockchip/rk1808.dtsi > > [...] > > >> + gic: interrupt-controller@ff100000 { > > >> + compatible =3D "arm,gic-v3"; > > >> + reg =3D <0xff100000 0x10000>, /* GICD */ > > >> + <0xff140000 0xc0000>, /* GICR */ > > > = > > > This is obviously wrong. You have two CPUs, and yet describe a range > > > that spans 6. I guess this is a copy paste from rk3399 again? > > = > > Not on my part at least. As indicated, these numbers are what ships in > > the DTB on the RK1808 card, as per dtc -I dtb -O dts. Could be a mistake > > by Rockchip, of course. > > = > > Are you suggesting 0xc0000/6*2 =3D 0x40000 for two CPUs here? Works > > as bad as before - investigation still ongoing with latest next. > > = > > As for "obviously": The GICv3 YAML binding has no description for me to > > validate those numbers: "GIC Redistributors (GICR), one range per > > redistributor region" - says nothing about correlation to number of CPUs > > or size per CPU, and the examples are not explaining either: 0x200000 > > has no number of CPUs associated, and by my calculation 0x800000 for 32 > > CPUs results in 0x40000 per CPU; but then again the examples also have > > GICC etc. at diverging 0x2000 size. > = > The GICv3/v4 architecture spec does apply, and you should really have > a look at what these sizes mean. What is the value of copy-pasting > things without understanding it the first place? > = > > = > > >> + <0xff300000 0x10000>, /* GICC */ > > >> + <0xff310000 0x10000>, /* GICH */ > > >> + <0xff320000 0x10000>; /* GICV */ > > >> + interrupt-controller; > > >> + #interrupt-cells =3D <3>; > > >> + interrupts =3D ; > > >> + #address-cells =3D <1>; > > >> + #size-cells =3D <1>; > > >> + ranges; > > >> + > > >> + gic_its: msi-controller@ff120000 { > > >> + compatible =3D "arm,gic-v3-its"; > > >> + reg =3D <0xff120000 0x20000>; > > >> + msi-controller; > > >> + #msi-cells =3D <1>; > > >> + }; > > > = > > > What uses the ITS? > > = > > DT-wise seemingly only the __symbols__ table (named just "its" there, I > > notice), so we could drop (or rename) the label if you prefer. > = > No, I am asking *what* uses the ITS. Is it just dangling without any > user? No PCI bus making use of it? just 2ct, as far as I remember the rk1808 does have a PCIe controller. And the datasheet [0] does agree with my memory it seems Heiko [0] http://opensource.rock-chips.com/images/4/43/Rockchip_RK1808_Datasheet_= V1.2_20190527.pdf _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel