> -----Original Message----- > From: Kumar Gala [mailto:galak@xxxxxxxxxxxxxx] > Sent: Friday, August 15, 2014 10:44 AM > To: Yoder Stuart-B08248 > Cc: Basu Arnab-B45036; Mark Rutland; Sharma Bhupesh-B45370; arnd@xxxxxxxx; > Catalin Marinas; Will Deacon; grant.likely@xxxxxxxxxxxx; linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > > On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder@xxxxxxxxxxxxx> wrote: > > > > > > >> -----Original Message----- > >> From: Kumar Gala [mailto:galak@xxxxxxxxxxxxxx] > >> Sent: Friday, August 15, 2014 10:26 AM > >> To: Basu Arnab-B45036 > >> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd@xxxxxxxx; Catalin Marinas; > >> devicetree-discuss@xxxxxxxxxxxxxxxx; Will Deacon; Yoder Stuart-B08248; > >> grant.likely@xxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > >> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC > >> > >> > >> On Aug 15, 2014, at 10:21 AM, arnab.basu@xxxxxxxxxxxxx wrote: > >> > >>>>> > >>>>> + cpus { > >>>>> + #address-cells = <2>; > >>>>> + #size-cells = <0>; > >>>>> + > >>>>> + /* We have 4 clusters having 2 Cortex-A57 cores each */ > >>>>> + cpu@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. > > Are you guys planning on supporting UEFI on this platform? Yes. > > So we want to do the standard/conventional thing here that will > > allow are device trees to be used in more than u-boot. > > Well, I think the guys would say the standard thing is to move to PSCI. Agree. That is our plan. But it looks like at this point in time all the device tree have a common denominator spin table mechanim that gets updated/overriden if PSCI is supported. Stuart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
