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 C177BC4332F for ; Wed, 14 Dec 2022 11:24:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237943AbiLNLYj (ORCPT ); Wed, 14 Dec 2022 06:24:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237896AbiLNLYU (ORCPT ); Wed, 14 Dec 2022 06:24:20 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4B6221E27; Wed, 14 Dec 2022 03:24:19 -0800 (PST) Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id 0C1B56602C56; Wed, 14 Dec 2022 11:24:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1671017058; bh=NEFZcGNbx1H7VeJP6Mv0ncKb7TmxoWPVOEsWCQJSFbU=; h=Date:Subject:To:References:From:In-Reply-To:From; b=ei0nVUgclMv+T7W4Kx5OHkj2Pc8X1ty/gJXnvcytSHqfFcv3jz+ybKMJkx/A3M+lj f7w+4jEN9J4KNP3poMCL72mWpuD80wVFTzB4ArGOixNO4cE/JY8rJ7QM9Pf3oqMUC7 MiqoVAU6D6aO/ompBalgH2dpgLvskaSh/v9wrLoAbnoXekXqyEDvcsAddXlDsF/Dky JXIJn7RU3ye/Lq4iMShJzlH4IHd9nEOhWRIFcfjbZVJjfCikWhEkhrVVe9pKBujyCF Kf+4af0BbUU3Hn2LvjUEHvPWCEnMR3G0efRRl6qvcxmgLxHW1vI/mvTMW5DkI7/xh5 CRKoKgL9MxDXA== Message-ID: <9917f349-51dd-905f-e272-65315bb5b2cc@collabora.com> Date: Wed, 14 Dec 2022 12:24:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH v5 7/7] arm64: dts: mediatek: Initial mt8365-evk support To: =?UTF-8?Q?Bernhard_Rosenkr=c3=a4nzer?= , linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com, khilman@baylibre.com References: <20221213234346.2868828-1-bero@baylibre.com> <20221213234346.2868828-8-bero@baylibre.com> Content-Language: en-US From: AngeloGioacchino Del Regno In-Reply-To: <20221213234346.2868828-8-bero@baylibre.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Il 14/12/22 00:43, Bernhard Rosenkränzer ha scritto: > From: Fabien Parent > > This adds minimal support for the Mediatek 8365 SOC and the EVK reference > board, allowing the board to boot to initramfs with serial port I/O. > > Signed-off-by: Fabien Parent > [bero@baylibre.com: Removed parts depending on drivers that aren't upstream yet, cleanups, add L2 cache] > Signed-off-by: Bernhard Rosenkränzer > Tested-by: Kevin Hilman > --- > arch/arm64/boot/dts/mediatek/Makefile | 1 + > arch/arm64/boot/dts/mediatek/mt8365-evk.dts | 163 ++++++++++ > arch/arm64/boot/dts/mediatek/mt8365.dtsi | 343 ++++++++++++++++++++ > 3 files changed, 507 insertions(+) > create mode 100644 arch/arm64/boot/dts/mediatek/mt8365-evk.dts > create mode 100644 arch/arm64/boot/dts/mediatek/mt8365.dtsi > ..snip.. > diff --git a/arch/arm64/boot/dts/mediatek/mt8365.dtsi b/arch/arm64/boot/dts/mediatek/mt8365.dtsi > new file mode 100644 > index 0000000000000..2c4ef9b92b68b > --- /dev/null > +++ b/arch/arm64/boot/dts/mediatek/mt8365.dtsi > @@ -0,0 +1,343 @@ > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) > +/* > + * (C) 2018 MediaTek Inc. > + * Copyright (C) 2022 BayLibre SAS > + * Fabien Parent > + * Bernhard Rosenkränzer > + */ > +#include > +#include > +#include > +#include > +#include > + > +/ { > + compatible = "mediatek,mt8365"; > + interrupt-parent = <&sysirq>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + cpus: cpus { You're not referencing `cpus` anywhere, hence this label is useless: please remove. > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu-map { > + cluster0: cluster0 { Same for this one. > + core0 { > + cpu = <&cpu0>; > + }; > + core1 { > + cpu = <&cpu1>; > + }; > + core2 { > + cpu = <&cpu2>; > + }; > + core3 { > + cpu = <&cpu3>; > + }; > + }; > + }; > + > + cpu0: cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53"; > + reg = <0x0>; > + #cooling-cells = <2>; > + enable-method = "psci"; > + next-level-cache = <&l2>; It would be nice if you described the I/D caches for all CPUs. > + }; > + > + cpu1: cpu@1 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53"; > + reg = <0x1>; > + #cooling-cells = <2>; > + enable-method = "psci"; > + next-level-cache = <&l2>; > + }; > + > + cpu2: cpu@2 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53"; > + reg = <0x2>; > + #cooling-cells = <2>; > + enable-method = "psci"; > + next-level-cache = <&l2>; > + }; > + > + cpu3: cpu@3 { > + device_type = "cpu"; > + compatible = "arm,cortex-a53"; > + reg = <0x3>; > + #cooling-cells = <2>; > + enable-method = "psci"; > + next-level-cache = <&l2>; > + }; > + > + l2: l2-cache { > + compatible = "cache"; ....and what's the size of this L2 cache? Is it unified, or does each CPU core have its own private L2? > + }; > + }; > + > + clk26m: oscillator { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <26000000>; > + clock-output-names = "clk26m"; > + }; > + > + psci { > + compatible = "arm,psci-1.0"; > + method = "smc"; > + }; > + > + reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + /* 128 KiB reserved for ARM Trusted Firmware (BL31) */ > + bl31_secmon_reserved: secmon@43000000 { This depends on the bootloader that's flashed on your board - it's not a global SoC property. Please move it to your board, or explain why BL31 *must* always be 128KiB starting at 0x43000000. > + no-map; > + reg = <0 0x43000000 0 0x20000>; > + }; > + }; > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + compatible = "simple-bus"; > + ranges; > + Is there really no systimer in this SoC? Would be pretty odd.... Regards, Angelo