Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3854490pxj; Mon, 24 May 2021 16:58:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyCMlAW4OUYHlbp/m852cfpeoLFCs9+c0OrMfe8OJPdbIPV65Cmot5jCHQVzqjcadkcgN24 X-Received: by 2002:a92:cd85:: with SMTP id r5mr17803246ilb.294.1621900706675; Mon, 24 May 2021 16:58:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621900706; cv=none; d=google.com; s=arc-20160816; b=lvs9EnGpfLQeaJvBL2+bNSJFIk172B03FbRZhNR4Veyg/f7QnER4tGUCDLN/hnfuqx L7gQ3UkZAIDgmqpYrvSqcmlZRZ5i5SOqTxmw5DyPABySrsL0mGu6Cqdk16YOkzQf/9+Q HNugaY1WrWSt3GHjq+v9FluNgMcF1gi76IogVIgQh5GunQl0nKhXvQR6ku1vIvY/xcLW xIzBj8F30BEcECuD8Z6qqTEkrqqNvchI84WgpMNnQtIyI2hUlch3bWhaI/UI8IqG1S1Y yuLl5R7UP6p6VsrNkgD/st8ZIcA9vF9i1NzGUwC3q9NXMyDFddZ0EZtKhMX/sbHN+W1p yTHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=9rliqqYlqgOs1eFWkmpiCo4I4pSOQqwik04N+mwSDW4=; b=W7GzyHvaSKqxrxHzuHtkjIuIgcgLNUNtXaSR1/Syrq50ZMgXBYRWl5Y4kaR/kc0NBa QYnYxEUK/Rfy+3gJigFKVwKrviwB0MZxbB97U4zvrTscJ1fLRkGquCQSvnwlF4YI+4Og POGNOK0YxfiHu1Bvcs9d5HDUVS3Bx8m5Vy3WBTGlkaiKgCDfAiP1tuAugt+Ee4y/+aww BA6BYAkBClNekeRxpAqap7+5l75hBXfZ5CO82nfPrisgGOWLuPHTjqfqHK3N/kgYros9 J4dzasYyWW8Fe1aSnbzHV6pUkrCatKeLUVGqsYa8gD5u4Qrnop8Kbtq7IHX8KBZO9zUX Pgyw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h6si14053670jaj.29.2021.05.24.16.58.14; Mon, 24 May 2021 16:58:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233491AbhEXVOi convert rfc822-to-8bit (ORCPT + 99 others); Mon, 24 May 2021 17:14:38 -0400 Received: from gloria.sntech.de ([185.11.138.130]:43672 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233278AbhEXVOh (ORCPT ); Mon, 24 May 2021 17:14:37 -0400 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 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Montag, 24. Mai 2021, 17:21:41 CEST schrieb Marc Zyngier: > On Mon, 24 May 2021 14:32:41 +0100, > Andreas F?rber wrote: > > > > On 17.05.21 11:21, Marc Zyngier wrote: > > > On Mon, 17 May 2021 00:05:45 +0100, > > > Andreas F?rber wrote: > > >> > > >> Add an initial Device Tree for Rockchip RK1808 SoC. > > >> Based on shipping TB-RK1808M0 DTB. > > >> > > >> Signed-off-by: Andreas F?rber > > >> --- > > >> 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/boot/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 = "arm,gic-v3"; > > >> + reg = <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 = 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 = <3>; > > >> + interrupts = ; > > >> + #address-cells = <1>; > > >> + #size-cells = <1>; > > >> + ranges; > > >> + > > >> + gic_its: msi-controller@ff120000 { > > >> + compatible = "arm,gic-v3-its"; > > >> + reg = <0xff120000 0x20000>; > > >> + msi-controller; > > >> + #msi-cells = <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