On Mon, Dec 18, 2023 at 09:52:59AM +0800, Binbin Zhou wrote:
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> + core1 {
> + cpu = <&cpu1>;
> + };
> + };
> + };
> +
> + cpu0: cpu@0 {
> + compatible = "loongson,la264";
> + device_type = "cpu";
> + reg= <0x0>;
> + clocks = <&clk LOONGSON2_NODE_CLK>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "loongson,la264";
> + device_type = "cpu";
> + reg = <0x1>;
> + clocks = <&clk LOONGSON2_NODE_CLK>;
> + };
> + };
Even with 2 CPUs, the cpu-map should not really be needed.
The generic topology code that is used by riscv and arm64 should be able
to determine that these two cpus are in the same cluster (See
CONFIG_GENERIC_ARCH_TOPOLOGY) provided you populate the next level cache
in the cpu devicetree nodes. As with the ls2k0500, you have no i, d or
next level cache information in these nodes, which I suspect your
hardware actually has?
I wired this generic "fallback" code up for riscv in this series here:
https://lore.kernel.org/all/20220715175155.3567243-3-mail@xxxxxxxxxxx/
Cheers,
Conor.
Attachment:
signature.asc
Description: PGP signature
