[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdX_Sdb3RFrLthcwThK__GKhJvJuXWu5+2RsQpGgFRkrXQ@mail.gmail.com>
Date: Wed, 24 May 2023 13:52:40 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Brad Larson <blarson@....com>
Cc: michal.simek@....com, adrian.hunter@...el.com, alcooperx@...il.com,
andy.shevchenko@...il.com, arnd@...db.de,
brendan.higgins@...ux.dev, briannorris@...omium.org,
broonie@...nel.org, catalin.marinas@....com, conor+dt@...nel.org,
davidgow@...gle.com, devicetree@...r.kernel.org,
fancer.lancer@...il.com, gerg@...ux-m68k.org, gsomlo@...il.com,
hal.feng@...rfivetech.com, hasegawa-hitomi@...itsu.com,
j.neuschaefer@....net, joel@....id.au, kernel@...il.dk,
krzk@...nel.org, krzysztof.kozlowski+dt@...aro.org,
lee.jones@...aro.org, lee@...nel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-mmc@...r.kernel.org, linux-spi@...r.kernel.org,
p.zabel@...gutronix.de, rdunlap@...radead.org, robh+dt@...nel.org,
samuel@...lland.org, skhan@...uxfoundation.org,
suravee.suthikulpanit@....com, thomas.lendacky@....com,
tonyhuang.sunplus@...il.com, ulf.hansson@...aro.org,
vaishnav.a@...com, walker.chen@...rfivetech.com, will@...nel.org,
zhuyinbo@...ngson.cn
Subject: Re: [PATCH v14 6/8] arm64: dts: Add AMD Pensando Elba SoC support
Hi Brad,
On Tue, May 23, 2023 at 9:30 PM Brad Larson <blarson@....com> wrote:
> On 5/16/23 09:54, Michal Simek wrote:
> > On 5/15/23 20:16, Brad Larson wrote:
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/amd/elba-16core.dtsi
> >> @@ -0,0 +1,197 @@
> >> +// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> >> +/*
> >> + * Copyright 2020-2022 Advanced Micro Devices, Inc.
> >
> > 2023 and the same below.
>
> I'll update the copyright in the next submit
Did you make any substantial changes in 2023?
> >> + */
> >> +
> >> +/ {
> >> + cpus {
> >> + #address-cells = <2>;
> >> + #size-cells = <0>;
> >> +
> >> + cpu-map {
> >> + cluster0 {
> >> + core0 { cpu = <&cpu0>; };
> >> + core1 { cpu = <&cpu1>; };
> >> + core2 { cpu = <&cpu2>; };
> >> + core3 { cpu = <&cpu3>; };
> >> + };
> >> +
> >> + cluster1 {
> >> + core0 { cpu = <&cpu4>; };
> >> + core1 { cpu = <&cpu5>; };
> >> + core2 { cpu = <&cpu6>; };
> >> + core3 { cpu = <&cpu7>; };
> >> + };
> >> +
> >> + cluster2 {
> >> + core0 { cpu = <&cpu8>; };
> >> + core1 { cpu = <&cpu9>; };
> >> + core2 { cpu = <&cpu10>; };
> >> + core3 { cpu = <&cpu11>; };
> >> + };
> >> +
> >> + cluster3 {
> >> + core0 { cpu = <&cpu12>; };
> >> + core1 { cpu = <&cpu13>; };
> >> + core2 { cpu = <&cpu14>; };
> >> + core3 { cpu = <&cpu15>; };
> >> + };
> >> + };
> >> +
> >> + /* CLUSTER 0 */
> >> + cpu0: cpu@0 {
> >> + device_type = "cpu";
> >> + compatible = "arm,cortex-a72";
> >> + reg = <0 0x0>;
> >
> > Do you really need 2/0 split here. The first cell is 0 anyway.
>
> Yes following 64-bit system definition
You mean for the 64-bit main address space?
The CPU address space under /cpus is unrelated.
> >> +++ b/arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
> >> @@ -0,0 +1,106 @@
> >> +// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> >> +/*
> >> + * Copyright 2020-2022 Advanced Micro Devices, Inc.
> >> + */
> >> +
> >> +&flash0 {
> 0xf0000>> + partitions {
> >> + compatible = "fixed-partitions";
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> + partition@0 {
> >> + label = "flash";
> >> + reg = <0x10000 0xfff0000>;
> >
> > This doesn't fit with partition@0 above.
> > Also size is weird.
>
> This is intended to not expose sector 0.
The unit address should still match the first reg entry
=> partition@...00.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists