Skip to contentSkip to conversation

LoongArch: Add built-in dtb support

PATCH Applied Binbin Zhou 5 participants 19 messages Dec 22, 2023 – Jan 9, 2024

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

v6 cover LoongArch: Add built-in dtb support

Hi all:

This patchset introduces LoongArch's built-in dtb support.

During the upstream progress of those DT-based drivers, DT properties are changed a lot so very different from those in existing bootloaders. It is inevitably that some existing systems do not provide a standard, canonical device tree to the kernel at boot time. So let's provide a device tree table in the kernel, keyed by the dts filename, containing the relevant DTBs.

We can use the built-in dts files as references. Each SoC has only one built-in dts file which describes all possible device information of that SoC, so the dts files are good examples during development.

And as a reference, our built-in dts file only enables the most basic bootable combinations (so it is generic enough), acts as an alternative in case the dts in the bootloader is unexpected.

In the past while, we resolved the DTC_CHK warning for the v4 patchset, and the relevant patchset has either been applied or had the Reviewed-by tag added.

Now, we need to rely on the following patch sets:
1. liointc
https://lore.kernel.org/all/[email protected]/
Reviewed-by tag has been added.
2. pmc
https://lore.kernel.org/all/[email protected]/
has been applied by Daniel.
3. dmac
https://lore.kernel.org/all/[email protected]/
has been applied by Vinod.

Thanks.

-----
V6:
patch(3/7):
- Update cmdline handling;
patch(5/7):
- Drop bootargs;
- Drop cpu-map;
- Add dma-controller node;
patch(4/7)(6/7):
- Drop bootargs;
- Drop cpu-map;
patch(7/7):
- Initialize loongson_sysconf.cores_per_package.

Link to V5:
https://lore.kernel.org/all/[email protected]/

V5:
patch(1/7):
- Add reviewed-by tag.
patch(3/7):
- Rewrite commit message to describe the reason for needing the build-in DTB.
patch(4/7):
- Add Power-Manager node.
patch(5/7):
- Add Power-Manager node.
- Add spi node.
- Add pmc node.
patch(6/7):
- Add Power-Manager node.

Link to V4:
https://lore.kernel.org/all/[email protected]/

V4:
patch(1/7):
- Drop device_type property.
patch(2/7):
- Rename board.yaml to loongson.yaml.
patch(4/7):
- Keep the ranges attribute after compatible;
- Add bootargs = "ttyS0,115200", which is needed for reference board;
patch(5/7):
- Keep the ranges attribute after compatible;
- Add bootargs = "ttyS0,115200", which is needed for reference board;
- Change node name global-utilities to chipid.
patch(6/7):
- Keep the ranges attribute after compatible;
- Add bootargs = "ttyS0,115200", which is needed for reference board.

Link to V3:
https://lore.kernel.org/all/[email protected]/

V3:
patch(1/7):
- Add reference to the common cpu schema.
patch(2/7):
- Add reviewed-by tag.
patch(4/7):
- Drop bootargs;
- Move the cpus node to dtsi, which is part of the SoC.
patch(5/7):
- Drop bootargs;
- Move the cpus node to dtsi, which is part of the SoC;
- Fix gmac0/1-mdio node: compatible is always the first property;
- Drop i2c-gpio node.
patch(6/7):
- Drop bootargs;
- Move the cpus node to dtsi, which is part of the SoC.
- Changes liointc to liointc-1.0, for Loongson-2K2000 has 32 interrupt sources.

Link to V2:
https://lore.kernel.org/all/[email protected]/

V2:
patch(1/7):
- Drop model and clock-frequency properties;
- Add clocks property;
- Rewrite the description.
patch(2/7):
- Add the proper compatibles for boards.
patch(4/7)(5/7)(6/7):
- Format commit message head;
- Drop undocumented compatible, such as pci_bridge compatible;
- Distinguish the attributes, put SoC-related into DTSI and

    board-related into DTS;

- Check DTS with 'make dtbs_check W=1'.
patch(7/7)
- New patch;
- Parses Molde name and CPU MHz from the DTS attribute.

Link to V1:
https://lore.kernel.org/loongarch/[email protected]/

Binbin Zhou (7):
dt-bindings: loongarch: Add CPU bindings for LoongArch
dt-bindings: loongarch: Add Loongson SoC boards compatibles
LoongArch: Allow device trees to be built into the kernel
LoongArch: dts: DeviceTree for Loongson-2K0500
LoongArch: dts: DeviceTree for Loongson-2K1000
LoongArch: dts: DeviceTree for Loongson-2K2000
LoongArch: Parsing CPU-related information from DTS

 .../devicetree/bindings/loongarch/cpus.yaml   |  61 +++
 .../bindings/loongarch/loongson.yaml          |  34 ++
 arch/loongarch/Kbuild                         |   1 +
 arch/loongarch/Kconfig                        |  18 +
 arch/loongarch/Makefile                       |   3 +-
 arch/loongarch/boot/dts/Makefile              |   5 +-
 .../boot/dts/loongson-2k0500-ref.dts          |  88 ++++
 arch/loongarch/boot/dts/loongson-2k0500.dtsi  | 266 ++++++++++
 .../boot/dts/loongson-2k1000-ref.dts          | 183 +++++++
 arch/loongarch/boot/dts/loongson-2k1000.dtsi  | 492 ++++++++++++++++++
 .../boot/dts/loongson-2k2000-ref.dts          |  72 +++
 arch/loongarch/boot/dts/loongson-2k2000.dtsi  | 300 +++++++++++
 arch/loongarch/kernel/env.c                   |  34 +-
 arch/loongarch/kernel/setup.c                 |  12 +-
 arch/loongarch/kernel/smp.c                   |   3 +
 15 files changed, 1565 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/loongarch/cpus.yaml
 create mode 100644 Documentation/devicetree/bindings/loongarch/loongson.yaml
 create mode 100644 arch/loongarch/boot/dts/loongson-2k0500-ref.dts
 create mode 100644 arch/loongarch/boot/dts/loongson-2k0500.dtsi
 create mode 100644 arch/loongarch/boot/dts/loongson-2k1000-ref.dts
 create mode 100644 arch/loongarch/boot/dts/loongson-2k1000.dtsi
 create mode 100644 arch/loongarch/boot/dts/loongson-2k2000-ref.dts
 create mode 100644 arch/loongarch/boot/dts/loongson-2k2000.dtsi
Signature · 1 line
2.39.3
#1 lore raw

PATCH v6 1/7 dt-bindings: loongarch: Add CPU bindings for LoongArch

Add the available CPUs in LoongArch binding with DT schema format using json-schema.

---
 .../devicetree/bindings/loongarch/cpus.yaml   | 61 +++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/loongarch/cpus.yaml
Documentation/devicetree/bindings/loongarch/cpus.yaml new file +61 -0
new file mode 100644
index 000000000000..f175872995e1
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/loongarch/cpus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LoongArch CPUs
+
+maintainers:
+  - Binbin Zhou <[email protected]>
+
+description:
+  This document describes the list of LoongArch CPU cores that support FDT,
+  it describe the layout of CPUs in a system through the "cpus" node.
+
+allOf:
+  - $ref: /schemas/cpu.yaml#
+
+properties:
+  compatible:
+    enum:
+      - loongson,la264
+      - loongson,la364
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/loongson,ls2k-clk.h>
+
+    cpus {
+        #size-cells = <0>;
+        #address-cells = <1>;
+
+        cpu@0 {
+            compatible = "loongson,la264";
+            device_type = "cpu";
+            reg = <0>;
+            clocks = <&clk LOONGSON2_NODE_CLK>;
+        };
+
+        cpu@1 {
+            compatible = "loongson,la264";
+            device_type = "cpu";
+            reg = <1>;
+            clocks = <&clk LOONGSON2_NODE_CLK>;
+        };
+    };
+
+...
Signature · 1 line
2.39.3
#2 lore raw

PATCH v6 2/7 dt-bindings: loongarch: Add Loongson SoC boards compatibles

In reply to Binbin Zhou

Add Loongson SoC boards binding with DT schema format using json-schema.

---
 .../bindings/loongarch/loongson.yaml          | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/loongarch/loongson.yaml
Documentation/devicetree/bindings/loongarch/loongson.yaml new file +34 -0
new file mode 100644
index 000000000000..e1a4a97b7576
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/loongarch/loongson.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson SoC-based boards
+
+maintainers:
+  - Binbin Zhou <[email protected]>
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: Loongson-2K0500 processor based boards
+        items:
+          - const: loongson,ls2k0500-ref
+          - const: loongson,ls2k0500
+
+      - description: Loongson-2K1000 processor based boards
+        items:
+          - const: loongson,ls2k1000-ref
+          - const: loongson,ls2k1000
+
+      - description: Loongson-2K2000 processor based boards
+        items:
+          - const: loongson,ls2k2000-ref
+          - const: loongson,ls2k2000
+
+additionalProperties: true
+
+...
Signature · 1 line
2.39.3
#3 lore raw

PATCH v6 3/7 LoongArch: Allow device trees to be built into the kernel

In reply to Binbin Zhou

During the upstream progress of those DT-based drivers, DT properties are changed a lot so very different from those in existing bootloaders. It is inevitably that some existing systems do not provide a standard, canonical device tree to the kernel at boot time. So let's provide a device tree table in the kernel, keyed by the dts filename, containing the relevant DTBs.

We can use the built-in dts files as references. Each SoC has only one built-in dts file which describes all possible device information of that SoC, so the dts files are good examples during development.

And as a reference, our built-in dts file only enables the most basic bootable combinations (so it is generic enough), acts as an alternative in case the dts in the bootloader is unexpected.

---
 arch/loongarch/Kbuild            |  1 +
 arch/loongarch/Kconfig           | 18 ++++++++++++++++++
 arch/loongarch/Makefile          |  3 ++-
 arch/loongarch/boot/dts/Makefile |  3 +--
 arch/loongarch/kernel/setup.c    | 12 +++++++++---
 5 files changed, 31 insertions(+), 6 deletions(-)
arch/loongarch/Kbuild +1 -0
index beb8499dd8ed..bfa21465d83a 100644
@@ -4,6 +4,7 @@ obj-y += net/
 obj-y += vdso/
 
 obj-$(CONFIG_KVM) += kvm/
+obj-$(CONFIG_BUILTIN_DTB) += boot/dts/
 
 # for cleaning
 subdir- += boot
arch/loongarch/Kconfig +18 -0
index ee123820a476..dd23ed31c12f 100644
@@ -374,6 +374,24 @@ config CMDLINE_FORCE
 
 endchoice
 
+config BUILTIN_DTB
+	bool "Enable built-in dtb in kernel"
+	depends on OF
+	help
+	  Some existing systems do not provide a canonical device tree to
+	  the kernel at boot time. Let's provide a device tree table in the
+	  kernel, keyed by the dts filename, containing the relevant DTBs.
+
+	  Built-in DTBs are generic enough and can be used as references.
+
+config BUILTIN_DTB_NAME
+	string "Source file for built-in dtb"
+	depends on BUILTIN_DTB
+	help
+	  Base name (without suffix, relative to arch/loongarch/boot/dts/)
+	  for the DTS file that will be used to produce the DTB linked into
+	  the kernel.
+
 config DMI
 	bool "Enable DMI scanning"
 	select DMI_SCAN_MACHINE_NON_EFI_FALLBACK
arch/loongarch/Makefile +2 -1
index 4ba8d67ddb09..2ef3ff097f9a 100644
@@ -6,6 +6,7 @@
 boot	:= arch/loongarch/boot
 
 KBUILD_DEFCONFIG := loongson3_defconfig
+KBUILD_DTBS      := dtbs
 
 image-name-y			:= vmlinux
 image-name-$(CONFIG_EFI_ZBOOT)	:= vmlinuz
@@ -141,7 +142,7 @@ endif
 
 vdso-install-y += arch/loongarch/vdso/vdso.so.dbg
 
-all:	$(notdir $(KBUILD_IMAGE))
+all:	$(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS)
 
 vmlinuz.efi: vmlinux.efi
 
arch/loongarch/boot/dts/Makefile +1 -2
index 5f1f55e911ad..1e24cdb5180a 100644
@@ -1,4 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0-only
-dtstree	:= $(srctree)/$(src)
 
-dtb-y := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard $(dtstree)/*.dts))
+obj-$(CONFIG_BUILTIN_DTB)	+= $(addsuffix .dtb.o, $(CONFIG_BUILTIN_DTB_NAME))
arch/loongarch/kernel/setup.c +9 -3
index d183a745fb85..15d366b8407c 100644
@@ -295,8 +295,12 @@ static void __init fdt_setup(void)
 	if (acpi_os_get_root_pointer())
 		return;
 
-	/* Look for a device tree configuration table entry */
-	fdt_pointer = efi_fdt_pointer();
+	/* Prefer to use built-in dtb, checking its legality first. */
+	if (!fdt_check_header(__dtb_start))
+		fdt_pointer = __dtb_start;
+	else
+		fdt_pointer = efi_fdt_pointer(); /* Fallback to firmware dtb */
+
 	if (!fdt_pointer || fdt_check_header(fdt_pointer))
 		return;
 
@@ -330,7 +334,9 @@ static void __init bootcmdline_init(char **cmdline_p)
 		if (boot_command_line[0])
 			strlcat(boot_command_line, " ", COMMAND_LINE_SIZE);
 
-		strlcat(boot_command_line, init_command_line, COMMAND_LINE_SIZE);
+		if (!strstr(boot_command_line, init_command_line))
+			strlcat(boot_command_line, init_command_line, COMMAND_LINE_SIZE);
+
 		goto out;
 	}
 #endif
Signature · 1 line
2.39.3
#4 lore raw

PATCH v6 4/7 LoongArch: dts: DeviceTree for Loongson-2K0500

In reply to Binbin Zhou

Add DeviceTree file for Loongson-2K0500 processor, which integrates one 64-bit 2-issue superscalar LA264 processor core.

---
 arch/loongarch/boot/dts/Makefile              |   2 +
 .../boot/dts/loongson-2k0500-ref.dts          |  88 ++++++
 arch/loongarch/boot/dts/loongson-2k0500.dtsi  | 266 ++++++++++++++++++
 3 files changed, 356 insertions(+)
 create mode 100644 arch/loongarch/boot/dts/loongson-2k0500-ref.dts
 create mode 100644 arch/loongarch/boot/dts/loongson-2k0500.dtsi
arch/loongarch/boot/dts/Makefile +2 -0
index 1e24cdb5180a..89c9758bba7f 100644
@@ -1,3 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 
+dtb-y = loongson-2k0500-ref.dtb
+
 obj-$(CONFIG_BUILTIN_DTB)	+= $(addsuffix .dtb.o, $(CONFIG_BUILTIN_DTB_NAME))
arch/loongarch/boot/dts/loongson-2k0500-ref.dts new file +88 -0

88 lines not on this page · raw message

arch/loongarch/boot/dts/loongson-2k0500.dtsi new file +266 -0

266 lines not on this page · raw message

Signature · 1 line
2.39.3
#5 lore raw

PATCH v6 5/7 LoongArch: dts: DeviceTree for Loongson-2K1000

In reply to Binbin Zhou

Add DeviceTree file for Loongson-2K1000 processor, which integrates two 64-bit 2-issue superscalar LA264 processor cores.

---
 arch/loongarch/boot/dts/Makefile              |   2 +-
 .../boot/dts/loongson-2k1000-ref.dts          | 183 +++++++
 arch/loongarch/boot/dts/loongson-2k1000.dtsi  | 492 ++++++++++++++++++
 3 files changed, 676 insertions(+), 1 deletion(-)
 create mode 100644 arch/loongarch/boot/dts/loongson-2k1000-ref.dts
 create mode 100644 arch/loongarch/boot/dts/loongson-2k1000.dtsi
arch/loongarch/boot/dts/Makefile +1 -1
index 89c9758bba7f..cfb0a122d91c 100644
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 
-dtb-y = loongson-2k0500-ref.dtb
+dtb-y = loongson-2k0500-ref.dtb loongson-2k1000-ref.dtb
 
 obj-$(CONFIG_BUILTIN_DTB)	+= $(addsuffix .dtb.o, $(CONFIG_BUILTIN_DTB_NAME))
arch/loongarch/boot/dts/loongson-2k1000-ref.dts new file +183 -0

183 lines not on this page · raw message

arch/loongarch/boot/dts/loongson-2k1000.dtsi new file +492 -0

492 lines not on this page · raw message

Signature · 1 line
2.39.3
#6 lore raw

PATCH v6 6/7 LoongArch: dts: DeviceTree for Loongson-2K2000

In reply to Binbin Zhou

Add DeviceTree file for Loongson-2K2000 processor, which integrates two 64-bit 3-issue superscalar LA364 processor cores.

---
 arch/loongarch/boot/dts/Makefile              |   2 +-
 .../boot/dts/loongson-2k2000-ref.dts          |  72 +++++
 arch/loongarch/boot/dts/loongson-2k2000.dtsi  | 300 ++++++++++++++++++
 3 files changed, 373 insertions(+), 1 deletion(-)
 create mode 100644 arch/loongarch/boot/dts/loongson-2k2000-ref.dts
 create mode 100644 arch/loongarch/boot/dts/loongson-2k2000.dtsi
arch/loongarch/boot/dts/Makefile +1 -1
index cfb0a122d91c..747d0c3f6389 100644
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 
-dtb-y = loongson-2k0500-ref.dtb loongson-2k1000-ref.dtb
+dtb-y = loongson-2k0500-ref.dtb loongson-2k1000-ref.dtb loongson-2k2000-ref.dtb
 
 obj-$(CONFIG_BUILTIN_DTB)	+= $(addsuffix .dtb.o, $(CONFIG_BUILTIN_DTB_NAME))
arch/loongarch/boot/dts/loongson-2k2000-ref.dts new file +72 -0

72 lines not on this page · raw message

arch/loongarch/boot/dts/loongson-2k2000.dtsi new file +300 -0

300 lines not on this page · raw message

Signature · 1 line
2.39.3
#7 lore raw

PATCH v6 7/7 LoongArch: Parsing CPU-related information from DTS

In reply to Binbin Zhou

Generally, we can get cpu-related information, such as model name, from /proc/cpuinfo. For FDT-based systems, we need to parse the relevant information from DTS.

BTW, set loongson_sysconf.cores_per_package to num_processors if SMBIOS doesn't provide a valid number (usually FDT-based systems).

---
 arch/loongarch/kernel/env.c | 34 +++++++++++++++++++++++++++++++++-
 arch/loongarch/kernel/smp.c |  3 +++
 2 files changed, 36 insertions(+), 1 deletion(-)
arch/loongarch/kernel/env.c +33 -1
index 6b3bfb0092e6..2f1f5b08638f 100644
@@ -5,13 +5,16 @@
  * Copyright (C) 2020-2022 Loongson Technology Corporation Limited
  */
 #include <linux/acpi.h>
+#include <linux/clk.h>
 #include <linux/efi.h>
 #include <linux/export.h>
 #include <linux/memblock.h>
+#include <linux/of_clk.h>
 #include <asm/early_ioremap.h>
 #include <asm/bootinfo.h>
 #include <asm/loongson.h>
 #include <asm/setup.h>
+#include <asm/time.h>
 
 u64 efi_system_table;
 struct loongson_system_configuration loongson_sysconf;
@@ -36,7 +39,16 @@ void __init init_environ(void)
 
 static int __init init_cpu_fullname(void)
 {
-	int cpu;
+	struct device_node *root;
+	int cpu, ret;
+	char *model;
+
+	/* Parsing cpuname from DTS model property */
+	root = of_find_node_by_path("/");
+	ret = of_property_read_string(root, "model", (const char **)&model);
+	of_node_put(root);
+	if (ret == 0)
+		loongson_sysconf.cpuname = strsep(&model, " ");
 
 	if (loongson_sysconf.cpuname && !strncmp(loongson_sysconf.cpuname, "Loongson", 8)) {
 		for (cpu = 0; cpu < NR_CPUS; cpu++)
@@ -46,6 +58,26 @@ static int __init init_cpu_fullname(void)
 }
 arch_initcall(init_cpu_fullname);
 
+static int __init fdt_cpu_clk_init(void)
+{
+	struct clk *clk;
+	struct device_node *np;
+
+	np = of_get_cpu_node(0, NULL);
+	if (!np)
+		return -ENODEV;
+
+	clk = of_clk_get(np, 0);
+	if (IS_ERR(clk))
+		return -ENODEV;
+
+	cpu_clock_freq = clk_get_rate(clk);
+	clk_put(clk);
+
+	return 0;
+}
+late_initcall(fdt_cpu_clk_init);
+
 static ssize_t boardinfo_show(struct kobject *kobj,
 			      struct kobj_attribute *attr, char *buf)
 {
arch/loongarch/kernel/smp.c +3 -0
index 5bca12d16e06..9e33b5e36122 100644
@@ -216,6 +216,9 @@ void __init loongson_smp_setup(void)
 {
 	fdt_smp_setup();
 
+	if (loongson_sysconf.cores_per_package == 0)
+		loongson_sysconf.cores_per_package = num_processors;
+
 	cpu_data[0].core = cpu_logical_map(0) % loongson_sysconf.cores_per_package;
 	cpu_data[0].package = cpu_logical_map(0) / loongson_sysconf.cores_per_package;
 
Signature · 1 line
2.39.3
#8 lore raw
In reply to Binbin Zhou

Hey Binbin,

Quoted 15 lines · Binbin Zhou

Hi all:

This patchset introduces LoongArch's built-in dtb support.

During the upstream progress of those DT-based drivers, DT properties are changed a lot so very different from those in existing bootloaders. It is inevitably that some existing systems do not provide a standard, canonical device tree to the kernel at boot time. So let's provide a device tree table in the kernel, keyed by the dts filename, containing the relevant DTBs.

We can use the built-in dts files as references. Each SoC has only one built-in dts file which describes all possible device information of that SoC, so the dts files are good examples during development.

Quoted 7 lines

And as a reference, our built-in dts file only enables the most basic bootable combinations (so it is generic enough), acts as an alternative in case the dts in the bootloader is unexpected.

In the past while, we resolved the DTC_CHK warning for the v4 patchset, and the relevant patchset has either been applied or had the Reviewed-by tag added.

I notice you dropped the topology information from all patches in the series, not only the 2k0500 patch that only has one CPU. I didn't see a response to my comments the kernel being able to assemble the topology based on the second level caches using the generic topology code for the systems that have more than one cpu. With the cpu-map information dropped, do the multi-cpu systems have their topologies assembled correctly by the kernel?
You mentioned that there is an instruction that allows you to get information about i and d caches etc, so adding them to the DT is not required, but does it also cover the next level caches?
The program that I am familiar with for displaying this information is hwloc: https://github.com/open-mpi/hwloc

Cheers,
Conor.

#9 lore raw

Hi Conor:

Sorry for the late reply.

Quoted 27 lines · Conor Dooley

Hey Binbin,

Quoted 15 lines · Binbin Zhou

Hi all:

This patchset introduces LoongArch's built-in dtb support.

During the upstream progress of those DT-based drivers, DT properties are changed a lot so very different from those in existing bootloaders. It is inevitably that some existing systems do not provide a standard, canonical device tree to the kernel at boot time. So let's provide a device tree table in the kernel, keyed by the dts filename, containing the relevant DTBs.

We can use the built-in dts files as references. Each SoC has only one built-in dts file which describes all possible device information of that SoC, so the dts files are good examples during development.

Quoted 7 lines

And as a reference, our built-in dts file only enables the most basic bootable combinations (so it is generic enough), acts as an alternative in case the dts in the bootloader is unexpected.

In the past while, we resolved the DTC_CHK warning for the v4 patchset, and the relevant patchset has either been applied or had the Reviewed-by tag added.

Quoted 7 lines

I notice you dropped the topology information from all patches in the series, not only the 2k0500 patch that only has one CPU. I didn't see a response to my comments the kernel being able to assemble the topology based on the second level caches using the generic topology code for the systems that have more than one cpu. With the cpu-map information dropped, do the multi-cpu systems have their topologies assembled correctly by the kernel?

As we saw previously, our DT-based system only supports single cluster cpu{s}, and multi-cluster cpu is not going to be in our plans.

Quoted 3 lines

You mentioned that there is an instruction that allows you to get information about i and d caches etc, so adding them to the DT is not required, but does it also cover the next level caches?

Firstly, sorry for my previous mistake about the cache reads. cpucfg is actually a set of registers that describes the features of the cpu, including the CPU cache [1]. populate_cache_properties() reads all levels of cache information [2], including of course next cache if it exists.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/asm/loongarch.h#n765
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/mm/cache.c#n94

Quoted 3 lines

The program that I am familiar with for displaying this information is hwloc: https://github.com/open-mpi/hwloc

Ah, yes, I tried looking at the hwloc-ls output before committing, and it's below(LS2K1000):

[root@fedora ~]# hwloc-ls
Machine (7730MB total)
Package L#0

    NUMANode L#0 (P#0 7730MB)
    L2 L#0 (1024KB)
      L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
      L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)

It's the same as what we actually have.

Thanks.
Binbin

Quoted 3 lines

Cheers,
Conor.

#10 lore raw
Quoted 7 lines · Binbin Zhou

Ah, yes, I tried looking at the hwloc-ls output before committing, and it's below(LS2K1000):

[root@fedora ~]# hwloc-ls
Machine (7730MB total)
Package L#0

Quoted 6 lines
    NUMANode L#0 (P#0 7730MB)
    L2 L#0 (1024KB)
      L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
      L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)

It's the same as what we actually have.

Yeah, that looks to be about what I would expect, thanks.

maintainer
#11 lore raw

This series is good enough for me, I will apply it to the loongarch tree after [1] is merged.

[1] https://lore.kernel.org/loongarch/[email protected]/T/#t

Huacai

Quoted 18 lines · Conor Dooley
Quoted 7 lines · Binbin Zhou

Ah, yes, I tried looking at the hwloc-ls output before committing, and it's below(LS2K1000):

[root@fedora ~]# hwloc-ls
Machine (7730MB total)
Package L#0

Quoted 6 lines
    NUMANode L#0 (P#0 7730MB)
    L2 L#0 (1024KB)
      L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
      L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)

It's the same as what we actually have.

Yeah, that looks to be about what I would expect, thanks.

maintainer Applied
#12 lore raw

Applied to loongarch-next, thanks.

Huacai

Quoted 27 lines · Huacai Chen

This series is good enough for me, I will apply it to the loongarch tree after [1] is merged.

[1] https://lore.kernel.org/loongarch/[email protected]/T/#t

Huacai

Quoted 18 lines · Conor Dooley
Quoted 7 lines · Binbin Zhou

Ah, yes, I tried looking at the hwloc-ls output before committing, and it's below(LS2K1000):

[root@fedora ~]# hwloc-ls
Machine (7730MB total)
Package L#0

Quoted 6 lines
    NUMANode L#0 (P#0 7730MB)
    L2 L#0 (1024KB)
      L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
      L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)

It's the same as what we actually have.

Yeah, that looks to be about what I would expect, thanks.

#13 lore raw
Quoted 2 lines · Huacai Chen

Applied to loongarch-next, thanks.

It's merge window, why do you apply patches? For which cycle?

Best regards,
Krzysztof

maintainer
#14 lore raw

Hi, Krzysztof,

Quoted 6 lines · Krzysztof Kozlowski
Quoted 2 lines · Huacai Chen

Applied to loongarch-next, thanks.

It's merge window, why do you apply patches? For which cycle?

I'm sorry I forgot to reply to the email when I applied patches, the patches have already been pulled in linux-next some days before.

Huacai

Quoted 4 lines

Best regards,
Krzysztof

#15 lore raw
Quoted 5 lines · Huacai Chen

Hi, Krzysztof,

Quoted 1 line · Krzysztof Kozlowski
Quoted 7 lines
Quoted 5 lines · Huacai Chen
Quoted 2 lines

Applied to loongarch-next, thanks.

It's merge window, why do you apply patches? For which cycle?

I'm sorry I forgot to reply to the email when I applied patches, the patches have already been pulled in linux-next some days before.

Really? I cannot find them on next-20240108, so what happened?

Are you aware that patches should be in next for "few next cycles" minimum (which means few days or even a week)?

Best regards,
Krzysztof

maintainer
#16 lore raw

Hi, Krzysztof,

Quoted 8 lines · Krzysztof Kozlowski
Quoted 6 lines · Huacai Chen

Hi, Krzysztof,

Quoted 2 lines · Krzysztof Kozlowski

On 09/01/2024 10:57, Huacai Chen wrote:

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

Applied to loongarch-next, thanks.

It's merge window, why do you apply patches? For which cycle?

I'm sorry I forgot to reply to the email when I applied patches, the patches have already been pulled in linux-next some days before.

Really? I cannot find them on next-20240108, so what happened?

Hmm, I applied patches two days ago, and they were only pulled in next-20240109.

Quoted 3 lines

Are you aware that patches should be in next for "few next cycles" minimum (which means few days or even a week)?

Thank you for your reminder, when I sent my first PR, my mentor had already told me this. So I will wait until next week to send PR for this series.

Huacai

Quoted 5 lines

Best regards,
Krzysztof

#17 lore raw
Quoted 9 lines · Huacai Chen
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

Applied to loongarch-next, thanks.

It's merge window, why do you apply patches? For which cycle?

I'm sorry I forgot to reply to the email when I applied patches, the patches have already been pulled in linux-next some days before.

Really? I cannot find them on next-20240108, so what happened?

Hmm, I applied patches two days ago, and they were only pulled in next-20240109.

Two days ago is weekend, so basically one day ago and definitely not "some days before".

Anyway two days ago merge window started, so it means you applied them during the merge window or immediately before. That's not good. Patches should be in linux-next BEFORE.

Quoted 7 lines
Quoted 4 lines

Are you aware that patches should be in next for "few next cycles" minimum (which means few days or even a week)?

Thank you for your reminder, when I sent my first PR, my mentor had already told me this. So I will wait until next week to send PR for this series.

In the future, please be sure that all your patches for next PR are for several days in your for-next branch, thus at least for few linux-next cycles.

Best regards,
Krzysztof

maintainer
#18 lore raw

Hi, Krzysztof,

Quoted 23 lines · Krzysztof Kozlowski
Quoted 9 lines · Huacai Chen
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

Applied to loongarch-next, thanks.

It's merge window, why do you apply patches? For which cycle?

I'm sorry I forgot to reply to the email when I applied patches, the patches have already been pulled in linux-next some days before.

Really? I cannot find them on next-20240108, so what happened?

Hmm, I applied patches two days ago, and they were only pulled in next-20240109.

Two days ago is weekend, so basically one day ago and definitely not "some days before".

Anyway two days ago merge window started, so it means you applied them during the merge window or immediately before. That's not good. Patches should be in linux-next BEFORE.

Quoted 4 lines
Quoted 4 lines

Are you aware that patches should be in next for "few next cycles" minimum (which means few days or even a week)?

Quoted 7 lines
Quoted 3 lines

Thank you for your reminder, when I sent my first PR, my mentor had already told me this. So I will wait until next week to send PR for this series.

In the future, please be sure that all your patches for next PR are for several days in your for-next branch, thus at least for few linux-next cycles.

OK, I will obey this rule strictly. Thanks.

Huacai

Quoted 5 lines

Best regards,
Krzysztof