Messages in this thread |  | | Date | Wed, 14 Dec 2022 12:24:15 +0100 | Subject | Re: [PATCH v5 7/7] arm64: dts: mediatek: Initial mt8365-evk support | From | AngeloGioacchino Del Regno <> |
| |
Il 14/12/22 00:43, Bernhard Rosenkränzer ha scritto: > From: Fabien Parent <fparent@baylibre.com> > > 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 <fparent@baylibre.com> > [bero@baylibre.com: Removed parts depending on drivers that aren't upstream yet, cleanups, add L2 cache] > Signed-off-by: Bernhard Rosenkränzer <bero@baylibre.com> > Tested-by: Kevin Hilman <khilman@baylibre.com> > --- > 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 <fparent@baylibre.com> > + * Bernhard Rosenkränzer <bero@baylibre.com> > + */ > +#include <dt-bindings/clock/mediatek,mt8365-clk.h> > +#include <dt-bindings/interrupt-controller/arm-gic.h> > +#include <dt-bindings/interrupt-controller/irq.h> > +#include <dt-bindings/phy/phy.h> > +#include <dt-bindings/thermal/thermal.h> > + > +/ { > + 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
|  |