On Fri, Jun 07, 2013 at 12:48:58PM +0100, James King wrote:
Hi Lorenzo,
On 7 June 2013 11:23, Lorenzo Pieralisi lorenzo.pieralisi@arm.com wrote:
Hi James,
On Thu, Jun 06, 2013 at 06:11:25PM +0100, James King wrote:
If CPUs are marked as disabled in the devicetree, make sure they do not exist in the system CPU information and CPU topology information. In this case these CPUs will not be able to be added to the system later using hot-plug. This allows a single chip with many CPUs to be easily used in a variety of hardware devices where they may have different actual processing requirements (eg for thermal/cost reasons).
- Change devicetree.c to ignore any cpu nodes marked as disabled, this effectively limits the number of active cpu cores so no need for the max_cpus=x in the chosen node.
- Change topology.c to ignore any cpu nodes marked as disabled, this is where the scheduler would learn about big/LITTLE cores so this effectively keeps the scheduler in sync.
I have two questions:
- Since with this approach the DT should change anyway if on different hardware devices based on the same chip you want to allow booting a different number of CPUs, why do not we remove the cpu nodes instead of disabling them ? Put it another way: cpu nodes define a cpu as possible (currently), we can simply remove the node if we do not want that cpu to be seen by the kernel.
The reason we want disabled status rather than just remove the nodes is to use a common soc.dtsi file which is included in many board.dts files - eg:
file soc.dtsi contains:
cpus { cpu0: cpu@0 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0>; cluster = <&cluster0>; core = <&core0>;
Minor nit, "cluster" and "core" phandles are not part of cpu the bindings that will be merged this cycle, I know it is just an example.
}; cpu1: cpu@1 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <1>; cluster = <&cluster0>; core = <&core1>; }; cpu2: cpu@2 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <2>; cluster = <&cluster0>; core = <&core2>; }; };file board1.dts where we want the A15 disabled contains:
/include/ "soc.dtsi"
cpus { cpu2: cpu@2 { status = "disabled"; }; };
Understood, see the other reply as far as the status property is concerned.
- If we go for the "status" property, why do not we use it to set present mask ? That way the cpu is possible but not present, you cannot hotplug it in. It is a bit of a stretch, granted, the cpu _is_ present, we just want to disable it, do not know how this is handled in x86 and other archs though.
I have been struggling to find any equivalent example for another arch, so just tried to solve our problem. I guess in the x86 world it is less likely to want to disable processors in a SoC for heat/battery issues so this has just never arisen. In this case the cpu is physically present but not possible, but I am not sure it should be in a present mask (giving the impression it can be used). Perhaps you could elaborate with an example what you are thinking about here?
I was thinking about using status == "disabled" to mark a cpu as possible but not present; that is a bad idea for the reason you mentioned and also for the point Rob raised related to the ePAPR.
I am not sure how we can solve this issue, as I mentioned the easiest solution consists in not defining cpu nodes in the DT or probably add an additional property != status with proper bindings attached to it.
Lorenzo