In the device tree, what does multiple cpu nodes mean inside 'cpus' node without the wrapping 'cpu-map' node?
Chan Kim
ckim at etri.re.kr
Thu Nov 4 02:44:10 EDT 2021
Hello all,
There is something I can't understand clearly about the device tree's cpu
topology so I ask it here.
In Documentation/devicetree/bindings/cpu/cpu-topology.txt, it says abput
cpu-map node,
- cpu-map node
Usage: Optional - On SMP systems provide CPUs topology to the OS.
Uniprocessor systems do not require a topology
description and therefore should not define a
cpu-map node.
Description: The cpu-map node is just a container node where its
subnodes describe the CPU topology.
Node name must be "cpu-map".
The cpu-map node's parent node must be the cpus node.
The cpu-map node's child nodes can be:
- one or more cluster nodes or
- one or more socket nodes in a multi-socket system
Any other configuration is considered invalid.
And the arch/arm64/boot/dts/arm/juno.dts files shows the usage of this
cpu-map node.
cpus {
#address-cells = <2>;
#size-cells = <0>;
cpu-map {
cluster0 {
core0 {
cpu = <&A57_0>;
};
core1 {
cpu = <&A57_1>;
};
};
cluster1 {
core0 {
cpu = <&A53_0>;
};
core1 {
cpu = <&A53_1>;
};
core2 {
cpu = <&A53_2>;
};
core3 {
cpu = <&A53_3>;
};
};
};
But in arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts,
cpus {
#address-cells = <2>;
#size-cells = <0>;
cpu at 0 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0 0>;
next-level-cache = <&L2_0>;
};
cpu at 1 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0 1>;
next-level-cache = <&L2_0>;
};
L2_0: l2-cache0 {
compatible = "cache";
};
};
So, uni-processor system should not define a cpu-map node and the above
vexpress-v2f-1xv7-ca53x2 fpga tile has this multiple cpus directly inside
the cpus node(without wrapping with cpu-map node). So even though it is not
uni-processor system, it doesn't have cpu-map node, Just cpu nodes.
What does it mean? Does it mean this system doesn't support SMP? Or, I can
use style without violation?
Any comment/explanation will be very much appreciated.
Thank you!
Chan Kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20211104/6310d7b9/attachment.html>
More information about the Kernelnewbies
mailing list