LoongArch: Add built-in dtb support
Subsystems (2)
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
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
@@ -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
PATCH v6 2/7 dt-bindings: loongarch: Add Loongson SoC boards compatibles
In reply to Binbin ZhouAdd 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
@@ -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
PATCH v6 3/7 LoongArch: Allow device trees to be built into the kernel
In reply to Binbin ZhouDuring 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH v6 4/7 LoongArch: dts: DeviceTree for Loongson-2K0500
In reply to Binbin ZhouAdd 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
@@ -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
PATCH v6 5/7 LoongArch: dts: DeviceTree for Loongson-2K1000
In reply to Binbin ZhouAdd 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
@@ -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
PATCH v6 6/7 LoongArch: dts: DeviceTree for Loongson-2K2000
In reply to Binbin ZhouAdd 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
@@ -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
PATCH v6 7/7 LoongArch: Parsing CPU-related information from DTS
In reply to Binbin ZhouGenerally, 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
@@ -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
@@ -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
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_CHKwarning 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.
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_CHKwarning 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.
Quoted 7 lines · Binbin Zhou
Ah, yes, I tried looking at the
hwloc-lsoutput 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.
Huacai Chen
maintainerThis 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-lsoutput before committing, and it's below(LS2K1000):[root@fedora ~]# hwloc-ls
Machine (7730MB total)
Package L#0Quoted 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.
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-lsoutput before committing, and it's below(LS2K1000):[root@fedora ~]# hwloc-ls
Machine (7730MB total)
Package L#0Quoted 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.
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
Huacai Chen
maintainerHi, 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
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
Huacai Chen
maintainerHi, 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
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
Huacai Chen
maintainerHi, 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