[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230605235202.15670-1-blarson@amd.com>
Date: Mon, 5 Jun 2023 16:52:02 -0700
From: Brad Larson <blarson@....com>
To: <geert@...ux-m68k.org>
CC: <adrian.hunter@...el.com>, <alcooperx@...il.com>,
<andy.shevchenko@...il.com>, <arnd@...db.de>, <blarson@....com>,
<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>, <michal.simek@....com>,
<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 Geert,
On Wed, May 31, 2023 at 15:09 Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> On Wed, May 31, 2023 at 12:04 AM Brad Larson <blarson@....com> wrote:
>> On Wed, May 24, 2023 at 13:52 Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>> > 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:
...
>> >> >> + /* 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.
>>
>> Yes, the reg prop for this node is CPU/threads per dt spec. Checked the history and
>> the Elba dt was derived from socionext for these nodes and this is how those device
>> trees are configured along with over a dozen other devices. I changed to
>> address-cells = <1> and dropped the leading zero from all cpu* reg<> and booting
>> the system I'm observing no change. Looking in drivers/of I'm not seeing where
>> cpu*/reg is read and used, any recommendation?
>
> drivers/of/cpu.c
>
> Looks like there are lots of DTS files that use #address-cells = <2> for
> CPU nodes :-(
>
> git grep -w -A1 cpus -- "*dts*" | grep address-cells | grep "<2>"
>
> I would use <1> is the first cell is always zero...
I'll do that. Tha variation across DTS is likely coming from ~5.10 devicetree/bindings/arm/cpus.txt
- #address-cells
...
# On ARM v8 64-bit systems value should be set to 2,
that corresponds to the MPIDR_EL1 register size.
If MPIDR_EL1[63:32] value is equal to 0 on all CPUs
in the system, #address-cells can be set to 1, since
MPIDR_EL1[63:32] bits are not used for CPUs
identification.
where the size of MPIDR_EL1 register is 2 for Elba cores. However the shorthand is
allowed if MPIDR_EL1[63:32] bita are not used.
Latest version:
On ARM v8 64-bit systems this property is required
and matches the MPIDR_EL1 register affinity bits.
* If cpus node's #address-cells property is set to 2
The first reg cell bits [7:0] must be set to
bits [39:32] of MPIDR_EL1.
The second reg cell bits [23:0] must be set to
bits [23:0] of MPIDR_EL1.
* If cpus node's #address-cells property is set to 1
The reg cell bits [23:0] must be set to bits [23:0]
of MPIDR_EL1.
All other bits in the reg cells must be set to 0.
Regards,
Brad
Powered by blists - more mailing lists