[PATCH 0/5] MIPS: cm: Probe GCR address from devicetree

[PATCH 0/5] MIPS: cm: Probe GCR address from devicetree

[Jiaxun Yang]

Hi all,

This series enabled mips-cm code to probe GCR address from devicetree.

This feature has been implemented in MIPS's out-of-tree kernel for
a while, and MIPS's u-boot fork on boston will generate required
"mti,mips-cm" node as well.

Please review.
Thanks

Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
Jiaxun Yang (5):
      MIPS: generic: Do __dt_setup_arch in prom_init
      MIPS: cm: Prefix probe functions with __init
      MIPS: Move mips_cm_probe after prom_init
      dt-bindings: mips: Document mti,mips-cm
      MIPS: cm: Probe GCR address from DeviceTree

 .../devicetree/bindings/mips/mips-cm.yaml          | 37 ++++++++++++
 arch/mips/generic/init.c                           |  9 ++-
 arch/mips/include/asm/mips-cm.h                    |  4 +-
 arch/mips/kernel/mips-cm.c                         | 66 ++++++++++++++++++----
 arch/mips/kernel/setup.c                           |  2 +-
 5 files changed, 100 insertions(+), 18 deletions(-)
---
base-commit: 2b84edefcad14934796fad37b16512b6a2ca467e
change-id: 20240506-cm_probe-0c667c8b63bf

Best regards,
-- 
Jiaxun Yang <jiaxun.yang@flygoat.com>

[PATCH 1/5] MIPS: generic: Do __dt_setup_arch in prom_init

[Jiaxun Yang]

We want fdt parse functions to be available as early as possible,
thus do __dt_setup_arch immediately after we get fdt address in
prom_init.

Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
 arch/mips/generic/init.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/mips/generic/init.c b/arch/mips/generic/init.c
index 1d712eac1617..9fd09061de78 100644
--- a/arch/mips/generic/init.c
+++ b/arch/mips/generic/init.c
@@ -26,8 +26,12 @@ static __initconst const void *mach_match_data;
 
 void __init prom_init(void)
 {
+	fw_init_cmdline();
 	plat_get_fdt();
 	BUG_ON(!fdt);
+	if (mach && mach->fixup_fdt)
+		fdt = mach->fixup_fdt(fdt, mach_match_data);
+	__dt_setup_arch((void *)fdt);
 }
 
 void __init *plat_get_fdt(void)
@@ -101,11 +105,6 @@ void __init plat_fdt_relocated(void *new_location)
 
 void __init plat_mem_setup(void)
 {
-	if (mach && mach->fixup_fdt)
-		fdt = mach->fixup_fdt(fdt, mach_match_data);
-
-	fw_init_cmdline();
-	__dt_setup_arch((void *)fdt);
 }
 
 void __init device_tree_init(void)

-- 
2.34.1

[PATCH 2/5] MIPS: cm: Prefix probe functions with __init

[Jiaxun Yang]

Those functions are only used at boot time.
Prefix them with __init so they can be discarded after boot.

Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
 arch/mips/include/asm/mips-cm.h | 4 ++--
 arch/mips/kernel/mips-cm.c      | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/mips/include/asm/mips-cm.h b/arch/mips/include/asm/mips-cm.h
index c2930a75b7e4..5292b516d60b 100644
--- a/arch/mips/include/asm/mips-cm.h
+++ b/arch/mips/include/asm/mips-cm.h
@@ -30,7 +30,7 @@ extern void __iomem *mips_cm_l2sync_base;
  * and may be overridden by platforms which determine this address in a
  * different way by defining a function with the same prototype.
  */
-extern phys_addr_t mips_cm_phys_base(void);
+extern phys_addr_t __init mips_cm_phys_base(void);
 
 /**
  * mips_cm_l2sync_phys_base - retrieve the physical base address of the CM
@@ -43,7 +43,7 @@ extern phys_addr_t mips_cm_phys_base(void);
  * determine this address in a different way by defining a function with the
  * same prototype.
  */
-extern phys_addr_t mips_cm_l2sync_phys_base(void);
+extern phys_addr_t  __init mips_cm_l2sync_phys_base(void);
 
 /*
  * mips_cm_is64 - determine CM register width
diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c
index 3a115fab5573..dddc9428fe58 100644
--- a/arch/mips/kernel/mips-cm.c
+++ b/arch/mips/kernel/mips-cm.c
@@ -179,7 +179,7 @@ static char *cm3_causes[32] = {
 static DEFINE_PER_CPU_ALIGNED(spinlock_t, cm_core_lock);
 static DEFINE_PER_CPU_ALIGNED(unsigned long, cm_core_lock_flags);
 
-phys_addr_t __weak mips_cm_phys_base(void)
+phys_addr_t __init __weak mips_cm_phys_base(void)
 {
 	unsigned long cmgcr;
 
@@ -198,7 +198,7 @@ phys_addr_t __weak mips_cm_phys_base(void)
 	return (cmgcr & MIPS_CMGCRF_BASE) << (36 - 32);
 }
 
-phys_addr_t __weak mips_cm_l2sync_phys_base(void)
+phys_addr_t __init __weak mips_cm_l2sync_phys_base(void)
 {
 	u32 base_reg;
 
@@ -214,7 +214,7 @@ phys_addr_t __weak mips_cm_l2sync_phys_base(void)
 	return mips_cm_phys_base() + MIPS_CM_GCR_SIZE;
 }
 
-static void mips_cm_probe_l2sync(void)
+static void __init mips_cm_probe_l2sync(void)
 {
 	unsigned major_rev;
 	phys_addr_t addr;
@@ -237,7 +237,7 @@ static void mips_cm_probe_l2sync(void)
 	mips_cm_l2sync_base = ioremap(addr, MIPS_CM_L2SYNC_SIZE);
 }
 
-int mips_cm_probe(void)
+int __init mips_cm_probe(void)
 {
 	phys_addr_t addr;
 	u32 base_reg;

-- 
2.34.1

[PATCH 3/5] MIPS: Move mips_cm_probe after prom_init

[Jiaxun Yang]

Move mips_cm_probe after prom_init so we can use fdt functions
in mips_cm_probe to obtain essential information.

Impat for all systems that may have CM in system:
- geneirc: Adjusted code to accommodate this change
- Lantiq: No impact, CM configuration won't be changed at all
- ralink: Called mips_cm_probe on it's own, in prom_init->prom_soc_init
- malta: No impact, CM address comes from CP0_CMGCR

Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
 arch/mips/kernel/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 12a1a4ffb602..732579c8f4f8 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -773,8 +773,8 @@ static void __init setup_rng_seed(void)
 void __init setup_arch(char **cmdline_p)
 {
 	cpu_probe();
-	mips_cm_probe();
 	prom_init();
+	mips_cm_probe();
 
 	setup_early_fdc_console();
 #ifdef CONFIG_EARLY_PRINTK

-- 
2.34.1

[PATCH 4/5] dt-bindings: mips: Document mti,mips-cm

[Jiaxun Yang]

Add devicetree binding documentation for MIPS Coherence Manager.

Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
 .../devicetree/bindings/mips/mips-cm.yaml          | 37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/Documentation/devicetree/bindings/mips/mips-cm.yaml b/Documentation/devicetree/bindings/mips/mips-cm.yaml
new file mode 100644
index 000000000000..b92b008d7758
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/mips-cm.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/mips-cm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPS Coherence Manager
+
+description: |
+  Defines a location of the MIPS Coherence Manager registers.
+
+maintainers:
+  - Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+properties:
+  compatible:
+    const: mti,mips-cm
+
+  reg:
+    description: |
+      Base address and size of an unoccupied memory region, which will be
+      used to map the MIPS CM registers block.
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    cm@1fbf8000 {
+      compatible = "mti,mips-cm";
+      reg = <0x1bde8000 0x8000>;
+    };
+...

-- 
2.34.1

[PATCH 5/5] MIPS: cm: Probe GCR address from DeviceTree

[Jiaxun Yang]

Traditionally, CM GCR address can be probed from CP0_CMGCRBase.

However there are chips in wild that do have CM GCR but CP0_CMGCRBase
is not available from CPU point of view. Thus we need to be able to
probe GCR address from DeviceTree.

It is implemented as:
- If only CP0_CMGCRBase present, trust CP0_CMGCRBase
- If only mti,mips-cm node present, trust mti,mips-cm reg prop
- If both present, remap address space to address specified in dt

Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
 arch/mips/kernel/mips-cm.c | 58 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 52 insertions(+), 6 deletions(-)

diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c
index dddc9428fe58..9563fc1ad438 100644
--- a/arch/mips/kernel/mips-cm.c
+++ b/arch/mips/kernel/mips-cm.c
@@ -5,6 +5,8 @@
  */
 
 #include <linux/errno.h>
+#include <linux/of_address.h>
+#include <linux/of_fdt.h>
 #include <linux/percpu.h>
 #include <linux/spinlock.h>
 
@@ -179,23 +181,67 @@ static char *cm3_causes[32] = {
 static DEFINE_PER_CPU_ALIGNED(spinlock_t, cm_core_lock);
 static DEFINE_PER_CPU_ALIGNED(unsigned long, cm_core_lock_flags);
 
+static int __init mips_cm_fdt_scan(unsigned long node, const char *uname,
+		int depth, void *data)
+{
+	unsigned long *cmgcr = data;
+
+	if (!of_flat_dt_is_compatible(node, "mti,mips-cm"))
+		return 0;
+
+	*cmgcr = of_flat_dt_translate_address(node);
+	if (*cmgcr == OF_BAD_ADDR)
+		*cmgcr = 0;
+
+	return 0;
+}
+
 phys_addr_t __init __weak mips_cm_phys_base(void)
 {
-	unsigned long cmgcr;
+	unsigned long gcr_reg = 0, gcr_dt = 0;
+
+	if (of_have_populated_dt()) {
+		int err;
+		struct resource res;
+		struct device_node *cm_node;
+
+		cm_node = of_find_compatible_node(of_root, NULL, "mti,mips-cm");
+		if (cm_node) {
+			err = of_address_to_resource(cm_node, 0, &res);
+			of_node_put(cm_node);
+			if (!err)
+				gcr_dt = res.start;
+		}
+	} else {
+		of_scan_flat_dt(mips_cm_fdt_scan, &gcr_dt);
+	}
 
 	/* Check the CMGCRBase register is implemented */
 	if (!(read_c0_config() & MIPS_CONF_M))
-		return 0;
+		return gcr_dt;
 
 	if (!(read_c0_config2() & MIPS_CONF_M))
-		return 0;
+		return gcr_dt;
 
 	if (!(read_c0_config3() & MIPS_CONF3_CMGCR))
-		return 0;
+		return gcr_dt;
 
 	/* Read the address from CMGCRBase */
-	cmgcr = read_c0_cmgcrbase();
-	return (cmgcr & MIPS_CMGCRF_BASE) << (36 - 32);
+	gcr_reg = read_c0_cmgcrbase();
+	gcr_reg = (gcr_reg & MIPS_CMGCRF_BASE) << (36 - 32);
+
+	/* If no of node, return straight away */
+	if (!gcr_dt)
+		return gcr_reg;
+
+	/* If the CMGCRBase mismatches with dt, remap it */
+	if (gcr_reg != gcr_dt) {
+		pr_info("Remapping CMGCRBase from 0x%08lx to 0x%08lx\n",
+			gcr_reg, gcr_dt);
+		change_gcr_base(CM_GCR_BASE_GCRBASE, gcr_dt);
+	}
+
+	return gcr_dt;
 }
 
 phys_addr_t __init __weak mips_cm_l2sync_phys_base(void)

-- 
2.34.1

Re: [PATCH 4/5] dt-bindings: mips: Document mti,mips-cm

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]

On Tue, May 07, 2024 at 10:01:52AM +0100, Jiaxun Yang wrote:
> Add devicetree binding documentation for MIPS Coherence Manager.
> 
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> ---
>  .../devicetree/bindings/mips/mips-cm.yaml          | 37 ++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mips/mips-cm.yaml b/Documentation/devicetree/bindings/mips/mips-cm.yaml
> new file mode 100644
> index 000000000000..b92b008d7758
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/mips-cm.yaml

Filename matching the compatible please.

> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mips/mips-cm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MIPS Coherence Manager
> +
> +description: |
> +  Defines a location of the MIPS Coherence Manager registers.
> +
> +maintainers:
> +  - Jiaxun Yang <jiaxun.yang@flygoat.com>
> +
> +properties:
> +  compatible:
> +    const: mti,mips-cm

Is it actually only available on mips? Google seems to report there
being Coherence Managers on their RISC-V offerings too.

> +  reg:
> +    description: |

The | isn't needed, there's no formatting to preserve.

> +      Base address and size of an unoccupied memory region, which will be
> +      used to map the MIPS CM registers block.

This sounds like it should actually be a memory-region that references
some reserved memory, not a reg, given the description. I think the
commit message here is lacking any information about what the intentions
are for this binding.

> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    cm@1fbf8000 {

And a generic node name here please. I actually don't quite know what to
suggest though, but "coherency-manager" would likely be better than
"cm".

Thanks,
Conor.

> +      compatible = "mti,mips-cm";
> +      reg = <0x1bde8000 0x8000>;
> +    };
> +...
> 
> -- 
> 2.34.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 4/5] dt-bindings: mips: Document mti,mips-cm

[Jiaxun Yang]

在2024年5月7日五月 下午5:50，Conor Dooley写道：
> On Tue, May 07, 2024 at 10:01:52AM +0100, Jiaxun Yang wrote:
>> Add devicetree binding documentation for MIPS Coherence Manager.
>> 
>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>> ---
>>  .../devicetree/bindings/mips/mips-cm.yaml          | 37 ++++++++++++++++++++++
>>  1 file changed, 37 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/mips/mips-cm.yaml b/Documentation/devicetree/bindings/mips/mips-cm.yaml
>> new file mode 100644
>> index 000000000000..b92b008d7758
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mips/mips-cm.yaml
Hi Cornor,

Thanks for your comments.

>
> Filename matching the compatible please.
Ok.

>
>> @@ -0,0 +1,37 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/mips/mips-cm.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: MIPS Coherence Manager
>> +
>> +description: |
>> +  Defines a location of the MIPS Coherence Manager registers.
>> +
>> +maintainers:
>> +  - Jiaxun Yang <jiaxun.yang@flygoat.com>
>> +
>> +properties:
>> +  compatible:
>> +    const: mti,mips-cm
>
> Is it actually only available on mips? Google seems to report there
> being Coherence Managers on their RISC-V offerings too.

I think for MIPS's RISC-V system, it is only used by SBI and transparent
to kernel, so it won't present in DT. 

Register fields for RISC-V system is totally different with MIPS one, and
there is no driver to be reused. In MIPS system CM code is highly coupled
with arch code, so for RISC-V if we want to expose it to kernel we'll need
a new set of driver and a new binding.

>
>> +  reg:
>> +    description: |
>
> The | isn't needed, there's no formatting to preserve.
Ok.

>
>> +      Base address and size of an unoccupied memory region, which will be
>> +      used to map the MIPS CM registers block.
>
> This sounds like it should actually be a memory-region that references
> some reserved memory, not a reg, given the description. I think the
> commit message here is lacking any information about what the intentions
> are for this binding.
So it's actually a register block that can be remapped to anywhere in
MMIO address space. DeviceTree usually passes firmware's mapping location
to kernel.

There are some other similar bindings like mti,mips-cdmm and mti,mips-cpc,
I just copied phraseology from them, should I try to explain it more here?

>
>> +    maxItems: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    cm@1fbf8000 {
>
> And a generic node name here please. I actually don't quite know what to
> suggest though, but "coherency-manager" would likely be better than
> "cm".
Ok

Thanks!
- Jiaxun
>
> Thanks,
> Conor.
>
>> +      compatible = "mti,mips-cm";
>> +      reg = <0x1bde8000 0x8000>;
>> +    };
>> +...
>> 
>> -- 
>> 2.34.1
>> 
>
> 附件:
> * signature.asc

-- 
- Jiaxun

Re: [PATCH 5/5] MIPS: cm: Probe GCR address from DeviceTree

[kernel test robot]

Hi Jiaxun,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 2b84edefcad14934796fad37b16512b6a2ca467e]

url:    https://github.com/intel-lab-lkp/linux/commits/Jiaxun-Yang/MIPS-generic-Do-__dt_setup_arch-in-prom_init/20240507-170413
base:   2b84edefcad14934796fad37b16512b6a2ca467e
patch link:    https://lore.kernel.org/r/20240507-cm_probe-v1-5-11dbfd598f3c%40flygoat.com
patch subject: [PATCH 5/5] MIPS: cm: Probe GCR address from DeviceTree
config: mips-randconfig-r113-20240508 (https://download.01.org/0day-ci/archive/20240508/202405081255.MGvZEuuc-lkp@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 0ab4458df0688955620b72cc2c72a32dffad3615)
reproduce: (https://download.01.org/0day-ci/archive/20240508/202405081255.MGvZEuuc-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405081255.MGvZEuuc-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> arch/mips/kernel/mips-cm.c:193:13: warning: result of comparison of constant 18446744073709551615 with expression of type 'unsigned long' is always false [-Wtautological-constant-out-of-range-compare]
     193 |         if (*cmgcr == OF_BAD_ADDR)
         |             ~~~~~~ ^  ~~~~~~~~~~~
   1 warning generated.


vim +193 arch/mips/kernel/mips-cm.c

   183	
   184	static int __init mips_cm_fdt_scan(unsigned long node, const char *uname,
   185			int depth, void *data)
   186	{
   187		unsigned long *cmgcr = data;
   188	
   189		if (!of_flat_dt_is_compatible(node, "mti,mips-cm"))
   190			return 0;
   191	
   192		*cmgcr = of_flat_dt_translate_address(node);
 > 193		if (*cmgcr == OF_BAD_ADDR)
   194			*cmgcr = 0;
   195	
   196		return 0;
   197	}
   198	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 0/5] MIPS: cm: Probe GCR address from devicetree

[Serge Semin]

Hi Jiaxun

On Tue, May 07, 2024 at 10:01:48AM +0100, Jiaxun Yang wrote:
> Hi all,
> 
> This series enabled mips-cm code to probe GCR address from devicetree.
> 
> This feature has been implemented in MIPS's out-of-tree kernel for
> a while, and MIPS's u-boot fork on boston will generate required
> "mti,mips-cm" node as well.

Thank you very much for the series. This work has been scheduled in my
TODO list for years. I could have done it earlier but a simple at the
first glance change turned to be tricky. The main concern was the
stage at what CM was probed. I was afraid to break things by changing
the order of the CM-base address getting. Let's discuss this matter in
the respective patch. It might get to be I was wrong to worry.

-Serge(y)

> 
> Please review.
> Thanks
> 
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> ---
> Jiaxun Yang (5):
>       MIPS: generic: Do __dt_setup_arch in prom_init
>       MIPS: cm: Prefix probe functions with __init
>       MIPS: Move mips_cm_probe after prom_init
>       dt-bindings: mips: Document mti,mips-cm
>       MIPS: cm: Probe GCR address from DeviceTree
> 
>  .../devicetree/bindings/mips/mips-cm.yaml          | 37 ++++++++++++
>  arch/mips/generic/init.c                           |  9 ++-
>  arch/mips/include/asm/mips-cm.h                    |  4 +-
>  arch/mips/kernel/mips-cm.c                         | 66 ++++++++++++++++++----
>  arch/mips/kernel/setup.c                           |  2 +-
>  5 files changed, 100 insertions(+), 18 deletions(-)
> ---
> base-commit: 2b84edefcad14934796fad37b16512b6a2ca467e
> change-id: 20240506-cm_probe-0c667c8b63bf
> 
> Best regards,
> -- 
> Jiaxun Yang <jiaxun.yang@flygoat.com>
> 
> 

Re: [PATCH 3/5] MIPS: Move mips_cm_probe after prom_init

[Serge Semin]

On Tue, May 07, 2024 at 10:01:51AM +0100, Jiaxun Yang wrote:
> Move mips_cm_probe after prom_init so we can use fdt functions
> in mips_cm_probe to obtain essential information.
> 
> Impat for all systems that may have CM in system:

> - geneirc: Adjusted code to accommodate this change

s/geneirc/generic

> - Lantiq: No impact, CM configuration won't be changed at all
> - ralink: Called mips_cm_probe on it's own, in prom_init->prom_soc_init

> - malta: No impact, CM address comes from CP0_CMGCR

Are you sure about this? This was one of the problematic part I met
back when was trying to implement the feature.
arch/mips/mti-malta/malta-init.c:
prom_init()
+-> mips_cpc_probe()
    +-> mips_cpc_phys_base()
        +-> mips_cm_present(): mips_gcr_base != NULL
        +-> read_gcr_cpc_status()
        +-> read_gcr_cpc_base()
        +-> write_gcr_cpc_base()

So by moving mips_cm_probe() to being executed after prom_init() the
calls-chain above will be broken since the mips_gcr_base will be left
uninitialized. Do I miss something?

Please, note originally the mips_cm_probe() invocation was right
above the Malta's mips_cpc_probe():
3af5a67c86a3 ("MIPS: Fix early CM probing")

-Serge(y)

> 
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> ---
>  arch/mips/kernel/setup.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 12a1a4ffb602..732579c8f4f8 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -773,8 +773,8 @@ static void __init setup_rng_seed(void)
>  void __init setup_arch(char **cmdline_p)
>  {
>  	cpu_probe();
> -	mips_cm_probe();
>  	prom_init();
> +	mips_cm_probe();
>  
>  	setup_early_fdc_console();
>  #ifdef CONFIG_EARLY_PRINTK
> 
> -- 
> 2.34.1
> 
> 

Re: [PATCH 3/5] MIPS: Move mips_cm_probe after prom_init

[Jiaxun Yang]

在2024年5月8日五月 下午1:50，Serge Semin写道：
> On Tue, May 07, 2024 at 10:01:51AM +0100, Jiaxun Yang wrote:
>> Move mips_cm_probe after prom_init so we can use fdt functions
>> in mips_cm_probe to obtain essential information.
>> 
>> Impat for all systems that may have CM in system:
>
>> - geneirc: Adjusted code to accommodate this change
>
> s/geneirc/generic
>
>> - Lantiq: No impact, CM configuration won't be changed at all
>> - ralink: Called mips_cm_probe on it's own, in prom_init->prom_soc_init
>
>> - malta: No impact, CM address comes from CP0_CMGCR
>
> Are you sure about this? This was one of the problematic part I met
> back when was trying to implement the feature.
> arch/mips/mti-malta/malta-init.c:
> prom_init()
> +-> mips_cpc_probe()
>     +-> mips_cpc_phys_base()
>         +-> mips_cm_present(): mips_gcr_base != NULL
>         +-> read_gcr_cpc_status()
>         +-> read_gcr_cpc_base()
>         +-> write_gcr_cpc_base()
>
> So by moving mips_cm_probe() to being executed after prom_init() the
> calls-chain above will be broken since the mips_gcr_base will be left
> uninitialized. Do I miss something?

Hi Serge,

Good catch! This is indeed a problem.
I tried to dig a little bit and found that a possible solution is to
move SMP initialization to device_tree_init(), as what generic platform
did.

I was able to test malta boot with this solution on my heavily patched
QEMU, I can confirm that both CM-SMP and scache are working as expected.

Will share my QEMU patches and configurations in next rev. 

Thanks
- Jiaxun

>
> Please, note originally the mips_cm_probe() invocation was right
> above the Malta's mips_cpc_probe():
> 3af5a67c86a3 ("MIPS: Fix early CM probing")
>
> -Serge(y)
>
>> 
>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>> ---
>>  arch/mips/kernel/setup.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>> index 12a1a4ffb602..732579c8f4f8 100644
>> --- a/arch/mips/kernel/setup.c
>> +++ b/arch/mips/kernel/setup.c
>> @@ -773,8 +773,8 @@ static void __init setup_rng_seed(void)
>>  void __init setup_arch(char **cmdline_p)
>>  {
>>  	cpu_probe();
>> -	mips_cm_probe();
>>  	prom_init();
>> +	mips_cm_probe();
>>  
>>  	setup_early_fdc_console();
>>  #ifdef CONFIG_EARLY_PRINTK
>> 
>> -- 
>> 2.34.1
>> 
>>

-- 
- Jiaxun

Re: [PATCH 4/5] dt-bindings: mips: Document mti,mips-cm

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 3284 bytes --]

On Tue, May 07, 2024 at 07:16:25PM +0100, Jiaxun Yang wrote:
> 
> 
> 在2024年5月7日五月 下午5:50，Conor Dooley写道：
> > On Tue, May 07, 2024 at 10:01:52AM +0100, Jiaxun Yang wrote:
> >> Add devicetree binding documentation for MIPS Coherence Manager.
> >> 
> >> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> >> ---
> >>  .../devicetree/bindings/mips/mips-cm.yaml          | 37 ++++++++++++++++++++++
> >>  1 file changed, 37 insertions(+)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/mips/mips-cm.yaml b/Documentation/devicetree/bindings/mips/mips-cm.yaml
> >> new file mode 100644
> >> index 000000000000..b92b008d7758
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mips/mips-cm.yaml
> Hi Cornor,
> 
> Thanks for your comments.
> 
> >
> > Filename matching the compatible please.
> Ok.
> 
> >
> >> @@ -0,0 +1,37 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/mips/mips-cm.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: MIPS Coherence Manager
> >> +
> >> +description: |
> >> +  Defines a location of the MIPS Coherence Manager registers.
> >> +
> >> +maintainers:
> >> +  - Jiaxun Yang <jiaxun.yang@flygoat.com>
> >> +
> >> +properties:
> >> +  compatible:
> >> +    const: mti,mips-cm
> >
> > Is it actually only available on mips? Google seems to report there
> > being Coherence Managers on their RISC-V offerings too.
> 
> I think for MIPS's RISC-V system, it is only used by SBI and transparent
> to kernel, so it won't present in DT. 

Devicetree isn't just for Linux, things that only the SBI implementation
cares about should also be documented in bindings - or at least I try to
get them to be, where I have enough sway to have it happen..

> Register fields for RISC-V system is totally different with MIPS one, and
> there is no driver to be reused. In MIPS system CM code is highly coupled
> with arch code, so for RISC-V if we want to expose it to kernel we'll need
> a new set of driver and a new binding.

Right, that's a reasonable reason (lol) for having it be declared as
mips-specific.

> >> +  reg:
> >> +    description: |
> >
> > The | isn't needed, there's no formatting to preserve.
> Ok.
> 
> >
> >> +      Base address and size of an unoccupied memory region, which will be
> >> +      used to map the MIPS CM registers block.
> >
> > This sounds like it should actually be a memory-region that references
> > some reserved memory, not a reg, given the description. I think the
> > commit message here is lacking any information about what the intentions
> > are for this binding.
> So it's actually a register block that can be remapped to anywhere in
> MMIO address space. DeviceTree usually passes firmware's mapping location
> to kernel.
> 
> There are some other similar bindings like mti,mips-cdmm and mti,mips-cpc,
> I just copied phraseology from them, should I try to explain it more here?

The description that you've given here is of something that sounded
awfully like mapping into a location in DDR etc, is it actually being
mapped into a non-memory address?

Thanks,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 4/5] dt-bindings: mips: Document mti,mips-cm

[Jiaxun Yang]

在 2024/5/8 18:01, Conor Dooley 写道:
[...]
>> So it's actually a register block that can be remapped to anywhere in
>> MMIO address space. DeviceTree usually passes firmware's mapping location
>> to kernel.
>>
>> There are some other similar bindings like mti,mips-cdmm and mti,mips-cpc,
>> I just copied phraseology from them, should I try to explain it more here?
> The description that you've given here is of something that sounded
> awfully like mapping into a location in DDR etc, is it actually being
> mapped into a non-memory address?
It is an overlay being realized at CPU core level so it can be mapped at any
where, but the firmware convention is to map it to a "non-memory address".

Thanks
- Jiaxun
>
> Thanks,
> Conor.

Re: [PATCH 4/5] dt-bindings: mips: Document mti,mips-cm

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

On Wed, May 08, 2024 at 09:28:27PM +0100, Jiaxun Yang wrote:
> 
> 
> 在 2024/5/8 18:01, Conor Dooley 写道:
> [...]
> > > So it's actually a register block that can be remapped to anywhere in
> > > MMIO address space. DeviceTree usually passes firmware's mapping location
> > > to kernel.
> > > 
> > > There are some other similar bindings like mti,mips-cdmm and mti,mips-cpc,
> > > I just copied phraseology from them, should I try to explain it more here?
> > The description that you've given here is of something that sounded
> > awfully like mapping into a location in DDR etc, is it actually being
> > mapped into a non-memory address?
> It is an overlay being realized at CPU core level so it can be mapped at any
> where, but the firmware convention is to map it to a "non-memory address".

In that case, a description that even eejits like my can understand
sounds like all you need to understand :)

Thanks,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]