[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9b24ffdf-1247-4164-9841-6063106d76ea@linaro.org>
Date: Thu, 25 Apr 2024 11:21:25 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Niko Pasaloukos <nikolaos.pasaloukos@...ize.com>,
"robh@...nel.org" <robh@...nel.org>,
"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"will@...nel.org" <will@...nel.org>, "arnd@...db.de" <arnd@...db.de>,
"olof@...om.net" <olof@...om.net>, Neil Jones <neil.jones@...ize.com>,
Matt Redfearn <matthew.redfearn@...ize.com>,
James Cowgill <james.cowgill@...ize.com>,
"heiko.stuebner@...rry.de" <heiko.stuebner@...rry.de>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"macromorgan@...mail.com" <macromorgan@...mail.com>,
"sre@...nel.org" <sre@...nel.org>,
"hvilleneuve@...onoff.com" <hvilleneuve@...onoff.com>,
"andre.przywara@....com" <andre.przywara@....com>,
"rafal@...ecki.pl" <rafal@...ecki.pl>,
"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
"andersson@...nel.org" <andersson@...nel.org>,
"konrad.dybcio@...aro.org" <konrad.dybcio@...aro.org>,
"geert+renesas@...der.be" <geert+renesas@...der.be>,
"neil.armstrong@...aro.org" <neil.armstrong@...aro.org>,
"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
"nfraprado@...labora.com" <nfraprado@...labora.com>,
"u-kumar1@...com" <u-kumar1@...com>
Cc: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 4/5] arm64: Add initial support for Blaize BLZP1600 CB2
On 25/04/2024 11:15, Niko Pasaloukos wrote:
> Adds support for the Blaize CB2 development board based on
> BLZP1600 SoC. This consists of a Carrier-Board-2 and a SoM.
Subject: missing dts prefix.
..
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + enable-method = "psci";
> + reg = <0x0 0x0>;
> + next-level-cache = <&l2>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + enable-method = "psci";
> + reg = <0x0 0x1>;
> + next-level-cache = <&l2>;
> + };
> +
> + l2: l2-cache0 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-unified;
> + };
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = /* Physical Secure PPI */
> + <GIC_PPI 13 (GIC_CPU_MASK_RAW(0x3) |
> + IRQ_TYPE_LEVEL_LOW)>,
> + /* Physical Non-Secure PPI */
> + <GIC_PPI 14 (GIC_CPU_MASK_RAW(0x3) |
> + IRQ_TYPE_LEVEL_LOW)>,
> + /* Hypervisor PPI */
> + <GIC_PPI 10 (GIC_CPU_MASK_RAW(0x3) |
> + IRQ_TYPE_LEVEL_LOW)>,
> + /* Virtual PPI */
> + <GIC_PPI 11 (GIC_CPU_MASK_RAW(0x3) |
> + IRQ_TYPE_LEVEL_LOW)>;
> + };
> +
> + psci {
> + compatible = "arm,psci-1.0", "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + pmu {
Nodes in top-level look randomly ordered. Any reason why not using DTS
coding style in this regard?
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&cpu0>, <&cpu1>;
> + };
> +
> + sram@0 {
> + /*
> + * On BLZP1600 there is no general purpose (non-secure) SRAM.
> + * A small DDR memory space has been reserved for general use.
> + */
> + compatible = "mmio-sram";
> + reg = <0x0 0x00000000 0x00001000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x00000000 0x1000>;
ranges follow reg
> +
> + /* SCMI reserved buffer space on DDR space */
> + scmi0_shm: scmi-sram@800 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x800 0x80>;
> + };
> + };
> +
> + firmware {
> + scmi {
> + compatible = "arm,scmi-smc";
> + arm,smc-id = <0x82002000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + shmem = <&scmi0_shm>;
> +
> + scmi_clk: protocol@14 {
> + reg = <0x14>;
> + #clock-cells = <1>;
> + };
> +
> + scmi_rst: protocol@16 {
> + reg = <0x16>;
> + #reset-cells = <1>;
> + };
> + };
> + };
> +
> + soc {
This does not cause dtbs_check W=1 warnings? Surprising a bit... This
should cause big fat warning, so I have doubts patchset was tested.
Best regards,
Krzysztof
Powered by blists - more mailing lists