On Mar 12, 2015, at 1:25 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote: >>>> + cpus { >>>> + #address-cells = <1>; >>>> + #size-cells = <0>; >>>> + >>>> + CPU0: cpu@0 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x0>; >>>> + }; >>>> + >>>> + CPU1: cpu@1 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x1>; >>>> + }; >>>> + >>>> + CPU2: cpu@2 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x2>; >>>> + }; >>>> + >>>> + CPU3: cpu@3 { >>>> + device_type = "cpu"; >>>> + compatible = "arm,cortex-a53", "arm,armv8"; >>>> + reg = <0x3>; >>>> + }; >>>> + }; >>> >>> The secondary CPUs need an enable-method. Are you using PSCI or >>> spin-table? >> >> This is on purpose. We aren’t using either PSCI or spin-table. Right >> now the dts is for booting on a single core. I can drop CPU1..CPU3 if >> that helps. > > We won't poke the CPUs without an enable-method, so personally I'm not > too worried either way about having the CPUs listed. That was my thinking, so left them in. > Which of spin-table/psci are you planning on using for SMP support, and > when would that be likely to appear? We have a qcom specific SMP enablement method for this device. This was one of our first devices so it utilized as much from arm 32-bit as possible. > Which exception level do CPUs enter the kernel? Even without a > virt-capable GIC booting at EL2 is less work for the FW and gives the > kernel a better chance of fixing things up (e.g. CNTVOFF). I think the enter in EL1. - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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