2024-05-07 09:02:02

by Jiaxun Yang

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

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 <[email protected]>
---
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 <[email protected]>

2024-05-07 09:02:37

by Jiaxun Yang

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

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 <[email protected]>
---
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

2024-05-07 09:02:37

by Jiaxun Yang

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

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 <[email protected]>
---
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

2024-05-07 09:03:07

by Jiaxun Yang

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

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 <[email protected]>
---
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

2024-05-07 09:03:11

by Jiaxun Yang

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

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

Signed-off-by: Jiaxun Yang <[email protected]>
---
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

2024-05-07 09:03:26

by Jiaxun Yang

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

Add devicetree binding documentation for MIPS Coherence Manager.

Signed-off-by: Jiaxun Yang <[email protected]>
---
.../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 <[email protected]>
+
+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

2024-05-07 16:59:56

by Conor Dooley

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

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 <[email protected]>
> ---
> .../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 <[email protected]>
> +
> +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
>

Attachments:

2024-05-07 18:17:26

by Jiaxun Yang

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

在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 <[email protected]>
>> ---
>> .../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 <[email protected]>
>> +
>> +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

2024-05-08 04:27:19

by kernel test robot

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

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/[email protected]/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 0ab4458df0688955620b72cc2c72a32dffad3615)
reproduce: (https://download.01.org/0day-ci/archive/20240508/[email protected]/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 <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

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

2024-05-08 12:37:46

by Serge Semin

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

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 <[email protected]>
> ---
> 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 <[email protected]>
>
>

2024-05-08 12:50:46

by Serge Semin

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

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 <[email protected]>
> ---
> 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
>
>

2024-05-08 16:24:19

by Jiaxun Yang

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

在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 <[email protected]>
>> ---
>> 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

2024-05-08 17:01:15

by Conor Dooley

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

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 <[email protected]>
> >> ---
> >> .../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 <[email protected]>
> >> +
> >> +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.

Attachments:

2024-05-08 20:29:52

by Jiaxun Yang

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

在 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.

2024-05-09 17:24:58

by Conor Dooley

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

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.

Attachments: