[PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
Stuart Yoder
stuart.yoder at freescale.com
Fri Aug 15 08:41:28 PDT 2014
> -----Original Message-----
> From: Kumar Gala [mailto:galak at codeaurora.org]
> Sent: Friday, August 15, 2014 10:26 AM
> To: Basu Arnab-B45036
> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd at arndb.de; Catalin Marinas;
> devicetree-discuss at lists.ozlabs.org; Will Deacon; Yoder Stuart-B08248;
> grant.likely at secretlab.ca; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
>
>
> On Aug 15, 2014, at 10:21 AM, arnab.basu at freescale.com wrote:
>
> >>>
> >>> + cpus {
> >>> + #address-cells = <2>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + /* We have 4 clusters having 2 Cortex-A57 cores each */
> >>> + cpu at 0 {
> >>> + device_type = "cpu";
> >>> + compatible = "arm,cortex-a57";
> >>> + reg = <0x0 0x0>;
> >>> + enable-method = "spin-table";
> >>> + cpu-release-addr = <0x0 0x8000fff8>;
> >>> + };
> >>
> >> I would strongly recommend having a unique cpu-release-addr for each CPU.
> >>
> >
> > This is more of a place holder, we intend to patch this address from U-Boot
> > and use individual release addresses for each CPU.
>
> If you are going to patch it in u-boot, than why not just have u-boot add the
> property and drop it from here.
>
> If you intend to keep it here, than make <0x0 0x0> and add a comment that says
> u-boot will fill it out
As I said to Mark re: the comment on having different release addresses
per CPU, we are just following existing practice from the existing
arch/arm64 device trees:
apm-storm.dtsi
foundation-v8.dts
rtsm_ve-aemv8a.dts
I think one of the reasons the cpu-release-addr is not 0x0 is that
UEFI had(?)/has(?) limited ability to do device tree fix ups. It's
not a problem at all in u-boot, but there is some reason all
existing device trees have the same hardcoded address for all
CPUs.
So we want to do the standard/conventional thing here that will
allow are device trees to be used in more than u-boot.
Thanks,
Stuart
More information about the linux-arm-kernel
mailing list