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@xxxxxxx> 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: > > > > 1) 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. > > 2) 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html