[PATCH v3 0/5] MIPS: Allow using multi-cluster with a broken HCI.

[PATCH v3 0/5] MIPS: Allow using multi-cluster with a broken HCI.

[Gregory CLEMENT]

Hello,

Some CM3.5 reports indicate that Hardware Cache Initialization is
complete, but in reality it's not the case. They also incorrectly show
that Hardware Cache Initialization is supported. Unfortunately, it is
not possible to detect this issue at runtime and the information has
to be passed by the device tree.

In this third version, I rebased on v6.13. I also addressed remarks
made by Rob and Krzysztof, and endeavored to add more explanation
about CM, explaining why we now need to represent it in the device
tree.

My initial proposal was integrated into the series set by Aleksandar
here [1]. And the series adding the CM binding was here: [2]. The
patches 1,2,3, and 5 have no dependencies while patch 4 should depend
on this series [1]. Actually, those five patches should replace
patches 10, 11, and 12.

Gregory

[1]: https://lore.kernel.org/all/20241028175935.51250-1-arikalo@gmail.com/
[2]: https://lore.kernel.org/all/20240612-cm_probe-v2-5-a5b55440563c@flygoat.com/

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
Changes in v3:
- Provide a more detailed explanation about the CM in the device tree binding.
- Make the reg property optional for all compatible strings.
- Use "mobileye" instead of "mti" for the eyeq6-cm compatible string.
- Address and correct the formatting issues in example and description.
- Link to v2: https://lore.kernel.org/r/20250116-cluster-hci-broken-v2-0-fc52cfb7a19e@bootlin.com

Changes in v2:
- Use compatible string instead of property
- Link to v1: https://lore.kernel.org/r/20241115-cluster-hci-broken-v1-0-00636800611d@bootlin.com

---
Gregory CLEMENT (5):
      dt-bindings: mips: Document mti,mips-cm
      dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6
      MIPS: cm: Detect CM quirks from device tree
      MIPS: CPS: Support broken HCI for multicluster
      MIPS: mobileye: dts: eyeq6h: Enable cluster support

 .../devicetree/bindings/mips/mti,mips-cm.yaml      | 57 ++++++++++++++++++++++
 arch/mips/boot/dts/mobileye/eyeq6h.dtsi            |  4 ++
 arch/mips/include/asm/mips-cm.h                    | 22 +++++++++
 arch/mips/kernel/mips-cm.c                         | 14 ++++++
 arch/mips/kernel/smp-cps.c                         |  5 +-
 5 files changed, 101 insertions(+), 1 deletion(-)
---
base-commit: 24da360081efcc12be3f346b6822a91fcb142027
change-id: 20241115-cluster-hci-broken-840a78f72aae

Best regards,
-- 
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Gregory CLEMENT]

Add device tree binding documentation for MIPS Coherence Manager. This
component enables support for SMP by providing each processor in the
system with a uniform view of memory. The Coherence Manager is
responsible for establishing the global ordering of requests from all
elements of the system and sending the correct data back to the
requester.

Based on the work of Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
 .../devicetree/bindings/mips/mti,mips-cm.yaml      | 47 ++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..4324b2306535f1bf66c44b1f96be9094ee282041
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/mti,mips-cm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPS Coherence Manager
+
+description:
+  The Coherence Manager (CM) is responsible for establishing the
+  global ordering of requests from all elements of the system and
+  sending the correct data back to the requester. It supports Cache
+  to Cache transfers.
+  https://training.mips.com/cps_mips/PDF/CPS_Introduction.pdf
+  https://training.mips.com/cps_mips/PDF/Coherency_Manager.pdf
+
+maintainers:
+  - Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+properties:
+  compatible:
+    const: mti,mips-cm
+
+  reg:
+    description:
+      Base address and size of the Global Configuration Registers
+      referred to as CMGCR.They are the system programmer's interface
+      to the Coherency Manager. Their location in the memory map is
+      determined at core build time. In a functional system, the base
+      address is provided by the Coprocessor 0, but some
+      System-on-Chip (SoC) designs may not provide an accurate address
+      that needs to be described statically.
+
+    maxItems: 1
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    coherency-manager@1fbf8000 {
+      compatible = "mti,mips-cm";
+      reg = <0x1bde8000 0x8000>;
+    };
+...

-- 
2.45.2

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

[Rob Herring (Arm)]

On Thu, 23 Jan 2025 12:01:54 +0100, Gregory CLEMENT wrote:
> Add device tree binding documentation for MIPS Coherence Manager. This
> component enables support for SMP by providing each processor in the
> system with a uniform view of memory. The Coherence Manager is
> responsible for establishing the global ordering of requests from all
> elements of the system and sending the correct data back to the
> requester.
> 
> Based on the work of Jiaxun Yang <jiaxun.yang@flygoat.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
>  .../devicetree/bindings/mips/mti,mips-cm.yaml      | 47 ++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH v3 2/5] dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6

[Gregory CLEMENT]

The CM3.5 used on EyeQ6 reports that Hardware Cache Initialization is
complete, but in reality it's not the case. It also incorrectly
indicates that Hardware Cache Initialization is supported. This new
compatible string allows warning about this broken feature that cannot
be detected at runtime.

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
 Documentation/devicetree/bindings/mips/mti,mips-cm.yaml | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
index 4324b2306535f1bf66c44b1f96be9094ee282041..d129d6382847768dc026336d8d2c7328b6b81f9b 100644
--- a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
+++ b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
@@ -19,7 +19,12 @@ maintainers:
 
 properties:
   compatible:
-    const: mti,mips-cm
+    oneOf:
+      - const: mti,mips-cm
+      - const: mobileye,eyeq6-cm
+        description:
+          On EyeQ6 the HCI (Hardware Cache Initialization) information for
+          the L2 cache in multi-cluster configuration is broken.
 
   reg:
     description:
@@ -44,4 +49,9 @@ examples:
       compatible = "mti,mips-cm";
       reg = <0x1bde8000 0x8000>;
     };
+
+  - |
+    coherency-manager {
+      compatible = "mobileye,eyeq6-cm";
+    };
 ...

-- 
2.45.2

Re: [PATCH v3 2/5] dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6

[Rob Herring (Arm)]

On Thu, 23 Jan 2025 12:01:55 +0100, Gregory CLEMENT wrote:
> The CM3.5 used on EyeQ6 reports that Hardware Cache Initialization is
> complete, but in reality it's not the case. It also incorrectly
> indicates that Hardware Cache Initialization is supported. This new
> compatible string allows warning about this broken feature that cannot
> be detected at runtime.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
>  Documentation/devicetree/bindings/mips/mti,mips-cm.yaml | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH v3 2/5] dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6

[Jiaxun Yang]

在2025年1月23日一月 上午11:01，Gregory CLEMENT写道：
> The CM3.5 used on EyeQ6 reports that Hardware Cache Initialization is
> complete, but in reality it's not the case. It also incorrectly
> indicates that Hardware Cache Initialization is supported. This new
> compatible string allows warning about this broken feature that cannot
> be detected at runtime.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
>  Documentation/devicetree/bindings/mips/mti,mips-cm.yaml | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml 
> b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> index 
> 4324b2306535f1bf66c44b1f96be9094ee282041..d129d6382847768dc026336d8d2c7328b6b81f9b 
> 100644
> --- a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> +++ b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> @@ -19,7 +19,12 @@ maintainers:
> 
>  properties:
>    compatible:
> -    const: mti,mips-cm
> +    oneOf:
> +      - const: mti,mips-cm
> +      - const: mobileye,eyeq6-cm
> +        description:
> +          On EyeQ6 the HCI (Hardware Cache Initialization) information for
> +          the L2 cache in multi-cluster configuration is broken.
> 
>    reg:
>      description:
> @@ -44,4 +49,9 @@ examples:
>        compatible = "mti,mips-cm";
>        reg = <0x1bde8000 0x8000>;
>      };
> +
> +  - |
> +    coherency-manager {
> +      compatible = "mobileye,eyeq6-cm";

I think “mobileye,eyeq6-cm”, “mti,mips-cm” would describe the hardware better as eyeq6’s CM is just a special variant of mips-cm.

But I’m fine with leaving it as is.


Thanks

> +    };
>  ...
>
> -- 
> 2.45.2

-- 
- Jiaxun

Re: [PATCH v3 2/5] dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6

[Rob Herring]

On Mon, Jan 27, 2025 at 3:43 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
>
>
> 在2025年1月23日一月 上午11:01，Gregory CLEMENT写道：
> > The CM3.5 used on EyeQ6 reports that Hardware Cache Initialization is
> > complete, but in reality it's not the case. It also incorrectly
> > indicates that Hardware Cache Initialization is supported. This new
> > compatible string allows warning about this broken feature that cannot
> > be detected at runtime.
> >
> > Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> > ---
> >  Documentation/devicetree/bindings/mips/mti,mips-cm.yaml | 12 +++++++++++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> > b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> > index
> > 4324b2306535f1bf66c44b1f96be9094ee282041..d129d6382847768dc026336d8d2c7328b6b81f9b
> > 100644
> > --- a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> > +++ b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> > @@ -19,7 +19,12 @@ maintainers:
> >
> >  properties:
> >    compatible:
> > -    const: mti,mips-cm
> > +    oneOf:
> > +      - const: mti,mips-cm
> > +      - const: mobileye,eyeq6-cm
> > +        description:
> > +          On EyeQ6 the HCI (Hardware Cache Initialization) information for
> > +          the L2 cache in multi-cluster configuration is broken.
> >
> >    reg:
> >      description:
> > @@ -44,4 +49,9 @@ examples:
> >        compatible = "mti,mips-cm";
> >        reg = <0x1bde8000 0x8000>;
> >      };
> > +
> > +  - |
> > +    coherency-manager {
> > +      compatible = "mobileye,eyeq6-cm";
>
> I think “mobileye,eyeq6-cm”, “mti,mips-cm” would describe the hardware better as eyeq6’s CM is just a special variant of mips-cm.

Is s/w that only understands “mti,mips-cm” useful on eyeq6 chip? If
so, I agree. If not, then a fallback compatible is not useful.

Rob

Re: [PATCH v3 2/5] dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6

[Jiaxun Yang]

在2025年1月27日一月 下午10:07，Rob Herring写道：
> On Mon, Jan 27, 2025 at 3:43 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>>
>>
>>
>> 在2025年1月23日一月 上午11:01，Gregory CLEMENT写道：
>> > The CM3.5 used on EyeQ6 reports that Hardware Cache Initialization is
>> > complete, but in reality it's not the case. It also incorrectly
>> > indicates that Hardware Cache Initialization is supported. This new
>> > compatible string allows warning about this broken feature that cannot
>> > be detected at runtime.
>> >
>> > Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
>> > ---
>> >  Documentation/devicetree/bindings/mips/mti,mips-cm.yaml | 12 +++++++++++-
>> >  1 file changed, 11 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>> > b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>> > index
>> > 4324b2306535f1bf66c44b1f96be9094ee282041..d129d6382847768dc026336d8d2c7328b6b81f9b
>> > 100644
>> > --- a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>> > +++ b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>> > @@ -19,7 +19,12 @@ maintainers:
>> >
>> >  properties:
>> >    compatible:
>> > -    const: mti,mips-cm
>> > +    oneOf:
>> > +      - const: mti,mips-cm
>> > +      - const: mobileye,eyeq6-cm
>> > +        description:
>> > +          On EyeQ6 the HCI (Hardware Cache Initialization) information for
>> > +          the L2 cache in multi-cluster configuration is broken.
>> >
>> >    reg:
>> >      description:
>> > @@ -44,4 +49,9 @@ examples:
>> >        compatible = "mti,mips-cm";
>> >        reg = <0x1bde8000 0x8000>;
>> >      };
>> > +
>> > +  - |
>> > +    coherency-manager {
>> > +      compatible = "mobileye,eyeq6-cm";
>>
>> I think “mobileye,eyeq6-cm”, “mti,mips-cm” would describe the hardware better as eyeq6’s CM is just a special variant of mips-cm.
>
> Is s/w that only understands “mti,mips-cm” useful on eyeq6 chip? If
> so, I agree. If not, then a fallback compatible is not useful.

Yes, mobileye,eyeq6-cm only enable an additional bug workaround in software.

The programming interfaces and so on remains unchanged.

Also other firmware components like U-Boot doesn’t need to be aware of eyeq6 variant.

Thanks

>
> Rob

-- 
- Jiaxun

Re: [PATCH v3 2/5] dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6

[Gregory CLEMENT]

> 在2025年1月27日一月 下午10:07，Rob Herring写道：
>> On Mon, Jan 27, 2025 at 3:43 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>>>
>>>
>>>
>>> 在2025年1月23日一月 上午11:01，Gregory CLEMENT写道：
>>> > The CM3.5 used on EyeQ6 reports that Hardware Cache Initialization is
>>> > complete, but in reality it's not the case. It also incorrectly
>>> > indicates that Hardware Cache Initialization is supported. This new
>>> > compatible string allows warning about this broken feature that cannot
>>> > be detected at runtime.
>>> >
>>> > Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
>>> > ---
>>> >  Documentation/devicetree/bindings/mips/mti,mips-cm.yaml | 12 +++++++++++-
>>> >  1 file changed, 11 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>>> > b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>>> > index
>>> > 4324b2306535f1bf66c44b1f96be9094ee282041..d129d6382847768dc026336d8d2c7328b6b81f9b
>>> > 100644
>>> > --- a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>>> > +++ b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>>> > @@ -19,7 +19,12 @@ maintainers:
>>> >
>>> >  properties:
>>> >    compatible:
>>> > -    const: mti,mips-cm
>>> > +    oneOf:
>>> > +      - const: mti,mips-cm
>>> > +      - const: mobileye,eyeq6-cm
>>> > +        description:
>>> > +          On EyeQ6 the HCI (Hardware Cache Initialization) information for
>>> > +          the L2 cache in multi-cluster configuration is broken.
>>> >
>>> >    reg:
>>> >      description:
>>> > @@ -44,4 +49,9 @@ examples:
>>> >        compatible = "mti,mips-cm";
>>> >        reg = <0x1bde8000 0x8000>;
>>> >      };
>>> > +
>>> > +  - |
>>> > +    coherency-manager {
>>> > +      compatible = "mobileye,eyeq6-cm";
>>>
>>> I think “mobileye,eyeq6-cm”, “mti,mips-cm” would describe the hardware better as eyeq6’s CM is just a special variant of mips-cm.
>>
>> Is s/w that only understands “mti,mips-cm” useful on eyeq6 chip? If
>> so, I agree. If not, then a fallback compatible is not useful.
>
> Yes, mobileye,eyeq6-cm only enable an additional bug workaround in software.
>

Having "mti,mips-cm" is not useful for the EyeQ6 chip. On the EyeQ6, we
obtain all relevant information related to CM dynamically without
needing this compatible string.

> The programming interfaces and so on remains unchanged.

Even without a compatible string, we are able to utilize the CM. At
present, there is no node in the device tree, and apart from the
hardware being faulty, we do not need it.

>
> Also other firmware components like U-Boot doesn’t need to be aware of
> eyeq6 variant.

It's the same for the firmware; they don't need to have "mti, mips-cm"
information, as they can retrieve all they need dynamically.

Gregory

-- 
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v3 2/5] dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6

[Thomas Bogendoerfer]

On Tue, Jan 28, 2025 at 05:23:26PM +0100, Gregory CLEMENT wrote:
> > 在2025年1月27日一月 下午10:07，Rob Herring写道：
> >> On Mon, Jan 27, 2025 at 3:43 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
> >>>
> >>>
> >>>
> >>> 在2025年1月23日一月 上午11:01，Gregory CLEMENT写道：
> >>> > The CM3.5 used on EyeQ6 reports that Hardware Cache Initialization is
> >>> > complete, but in reality it's not the case. It also incorrectly
> >>> > indicates that Hardware Cache Initialization is supported. This new
> >>> > compatible string allows warning about this broken feature that cannot
> >>> > be detected at runtime.
> >>> >
> >>> > Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> >>> > ---
> >>> >  Documentation/devicetree/bindings/mips/mti,mips-cm.yaml | 12 +++++++++++-
> >>> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >>> >
> >>> > diff --git a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> >>> > b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> >>> > index
> >>> > 4324b2306535f1bf66c44b1f96be9094ee282041..d129d6382847768dc026336d8d2c7328b6b81f9b
> >>> > 100644
> >>> > --- a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> >>> > +++ b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
> >>> > @@ -19,7 +19,12 @@ maintainers:
> >>> >
> >>> >  properties:
> >>> >    compatible:
> >>> > -    const: mti,mips-cm
> >>> > +    oneOf:
> >>> > +      - const: mti,mips-cm
> >>> > +      - const: mobileye,eyeq6-cm
> >>> > +        description:
> >>> > +          On EyeQ6 the HCI (Hardware Cache Initialization) information for
> >>> > +          the L2 cache in multi-cluster configuration is broken.
> >>> >
> >>> >    reg:
> >>> >      description:
> >>> > @@ -44,4 +49,9 @@ examples:
> >>> >        compatible = "mti,mips-cm";
> >>> >        reg = <0x1bde8000 0x8000>;
> >>> >      };
> >>> > +
> >>> > +  - |
> >>> > +    coherency-manager {
> >>> > +      compatible = "mobileye,eyeq6-cm";
> >>>
> >>> I think “mobileye,eyeq6-cm”, “mti,mips-cm” would describe the hardware better as eyeq6’s CM is just a special variant of mips-cm.
> >>
> >> Is s/w that only understands “mti,mips-cm” useful on eyeq6 chip? If
> >> so, I agree. If not, then a fallback compatible is not useful.
> >
> > Yes, mobileye,eyeq6-cm only enable an additional bug workaround in software.
> >
> 
> Having "mti,mips-cm" is not useful for the EyeQ6 chip. On the EyeQ6, we
> obtain all relevant information related to CM dynamically without
> needing this compatible string.
> 
> > The programming interfaces and so on remains unchanged.
> 
> Even without a compatible string, we are able to utilize the CM. At
> present, there is no node in the device tree, and apart from the
> hardware being faulty, we do not need it.
> 
> >
> > Also other firmware components like U-Boot doesn’t need to be aware of
> > eyeq6 variant.
> 
> It's the same for the firmware; they don't need to have "mti, mips-cm"
> information, as they can retrieve all they need dynamically.

so it the current patch version correct ? If yes and nothing else is
outstanding, I'm going to apply the series.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH v3 2/5] dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6

[Gregory CLEMENT]

Hello Thomas,

> On Tue, Jan 28, 2025 at 05:23:26PM +0100, Gregory CLEMENT wrote:
>> > 在2025年1月27日一月 下午10:07，Rob Herring写道：
>> >> On Mon, Jan 27, 2025 at 3:43 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> 在2025年1月23日一月 上午11:01，Gregory CLEMENT写道：
>> >>> > The CM3.5 used on EyeQ6 reports that Hardware Cache Initialization is
>> >>> > complete, but in reality it's not the case. It also incorrectly
>> >>> > indicates that Hardware Cache Initialization is supported. This new
>> >>> > compatible string allows warning about this broken feature that cannot
>> >>> > be detected at runtime.
>> >>> >
>> >>> > Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
>> >>> > ---
>> >>> >  Documentation/devicetree/bindings/mips/mti,mips-cm.yaml | 12 +++++++++++-
>> >>> >  1 file changed, 11 insertions(+), 1 deletion(-)
>> >>> >
>> >>> > diff --git a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>> >>> > b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>> >>> > index
>> >>> > 4324b2306535f1bf66c44b1f96be9094ee282041..d129d6382847768dc026336d8d2c7328b6b81f9b
>> >>> > 100644
>> >>> > --- a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>> >>> > +++ b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml
>> >>> > @@ -19,7 +19,12 @@ maintainers:
>> >>> >
>> >>> >  properties:
>> >>> >    compatible:
>> >>> > -    const: mti,mips-cm
>> >>> > +    oneOf:
>> >>> > +      - const: mti,mips-cm
>> >>> > +      - const: mobileye,eyeq6-cm
>> >>> > +        description:
>> >>> > +          On EyeQ6 the HCI (Hardware Cache Initialization) information for
>> >>> > +          the L2 cache in multi-cluster configuration is broken.
>> >>> >
>> >>> >    reg:
>> >>> >      description:
>> >>> > @@ -44,4 +49,9 @@ examples:
>> >>> >        compatible = "mti,mips-cm";
>> >>> >        reg = <0x1bde8000 0x8000>;
>> >>> >      };
>> >>> > +
>> >>> > +  - |
>> >>> > +    coherency-manager {
>> >>> > +      compatible = "mobileye,eyeq6-cm";
>> >>>
>> >>> I think “mobileye,eyeq6-cm”, “mti,mips-cm” would describe the hardware better as eyeq6’s CM is just a special variant of mips-cm.
>> >>
>> >> Is s/w that only understands “mti,mips-cm” useful on eyeq6 chip? If
>> >> so, I agree. If not, then a fallback compatible is not useful.
>> >
>> > Yes, mobileye,eyeq6-cm only enable an additional bug workaround in software.
>> >
>> 
>> Having "mti,mips-cm" is not useful for the EyeQ6 chip. On the EyeQ6, we
>> obtain all relevant information related to CM dynamically without
>> needing this compatible string.
>> 
>> > The programming interfaces and so on remains unchanged.
>> 
>> Even without a compatible string, we are able to utilize the CM. At
>> present, there is no node in the device tree, and apart from the
>> hardware being faulty, we do not need it.
>> 
>> >
>> > Also other firmware components like U-Boot doesn’t need to be aware of
>> > eyeq6 variant.
>> 
>> It's the same for the firmware; they don't need to have "mti, mips-cm"
>> information, as they can retrieve all they need dynamically.
>
> so it the current patch version correct ? If yes and nothing else is
> outstanding, I'm going to apply the series.

Thank you for taking care of it. From my perspective, this patch is the
correct version, and you can apply this series.

Gregory

>
> Thomas.
>
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]

-- 
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[PATCH v3 3/5] MIPS: cm: Detect CM quirks from device tree

[Gregory CLEMENT]

Some information that should be retrieved at runtime for the Coherence
Manager can be either absent or wrong. This patch allows checking if
some of this information is available from the device tree and updates
the internal variable accordingly.

For now, only the compatible string associated with the broken HCI is
being retrieved.

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
 arch/mips/include/asm/mips-cm.h | 22 ++++++++++++++++++++++
 arch/mips/kernel/mips-cm.c      | 14 ++++++++++++++
 2 files changed, 36 insertions(+)

diff --git a/arch/mips/include/asm/mips-cm.h b/arch/mips/include/asm/mips-cm.h
index 1afa85db1fb37d1017fbe7d6b7a2b7d2470e8257..3bfe0633b57639bfb05b7692e4bb83ba7c0b2523 100644
--- a/arch/mips/include/asm/mips-cm.h
+++ b/arch/mips/include/asm/mips-cm.h
@@ -59,6 +59,16 @@ extern phys_addr_t mips_cm_l2sync_phys_base(void);
  */
 extern int mips_cm_is64;
 
+/*
+ * mips_cm_is_l2_hci_broken  - determine if HCI is broken
+ *
+ * Some CM reports show that Hardware Cache Initialization is
+ * complete, but in reality it's not the case. They also incorrectly
+ * indicate that Hardware Cache Initialization is supported. This
+ * flags allows warning about this broken feature.
+ */
+extern bool mips_cm_is_l2_hci_broken;
+
 /**
  * mips_cm_error_report - Report CM cache errors
  */
@@ -97,6 +107,18 @@ static inline bool mips_cm_present(void)
 #endif
 }
 
+/**
+ * mips_cm_update_property - update property from the device tree
+ *
+ * Retrieve the properties from the device tree if a CM node exist and
+ * update the internal variable based on this.
+ */
+#ifdef CONFIG_MIPS_CM
+extern void mips_cm_update_property(void);
+#else
+static void mips_cm_update_property(void) {}
+#endif
+
 /**
  * mips_cm_has_l2sync - determine whether an L2-only sync region is present
  *
diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c
index 9854bc2b6895d4db67d216586f65e4810661d29b..43cb1e20baed3648ff83bb5d3bbe6a726072e063 100644
--- a/arch/mips/kernel/mips-cm.c
+++ b/arch/mips/kernel/mips-cm.c
@@ -5,6 +5,7 @@
  */
 
 #include <linux/errno.h>
+#include <linux/of.h>
 #include <linux/percpu.h>
 #include <linux/spinlock.h>
 
@@ -14,6 +15,7 @@
 void __iomem *mips_gcr_base;
 void __iomem *mips_cm_l2sync_base;
 int mips_cm_is64;
+bool mips_cm_is_l2_hci_broken;
 
 static char *cm2_tr[8] = {
 	"mem",	"gcr",	"gic",	"mmio",
@@ -237,6 +239,18 @@ static void mips_cm_probe_l2sync(void)
 	mips_cm_l2sync_base = ioremap(addr, MIPS_CM_L2SYNC_SIZE);
 }
 
+void mips_cm_update_property(void)
+{
+	struct device_node *cm_node;
+
+	cm_node = of_find_compatible_node(of_root, NULL, "mobileye,eyeq6-cm");
+	if (!cm_node)
+		return;
+	pr_info("HCI (Hardware Cache Init for the L2 cache) in GCR_L2_RAM_CONFIG from the CM3 is broken");
+	mips_cm_is_l2_hci_broken = true;
+	of_node_put(cm_node);
+}
+
 int mips_cm_probe(void)
 {
 	phys_addr_t addr;

-- 
2.45.2

[PATCH v3 4/5] MIPS: CPS: Support broken HCI for multicluster

[Gregory CLEMENT]

Some CM3.5 devices incorrectly report that hardware cache
initialization has completed, and also claim to support hardware cache
initialization when they don't actually do so. This commit fixes this
issue by retrieving the correct information from the device tree and
allowing the system to bypass the hardware cache initialization
step. Instead, it relies on manual operation. As a result, multi-user
support is now possible for these CPUs.

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
 arch/mips/kernel/smp-cps.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/kernel/smp-cps.c b/arch/mips/kernel/smp-cps.c
index b20ea4048429e1aab2bffbada793ee594bee1e05..e85bd087467e8caf0640ad247ee5f8eb65107591 100644
--- a/arch/mips/kernel/smp-cps.c
+++ b/arch/mips/kernel/smp-cps.c
@@ -333,6 +333,9 @@ static void __init cps_prepare_cpus(unsigned int max_cpus)
 					   sizeof(*mips_cps_cluster_bootcfg),
 					   GFP_KERNEL);
 
+	if (nclusters > 1)
+		mips_cm_update_property();
+
 	for (cl = 0; cl < nclusters; cl++) {
 		/* Allocate core boot configuration structs */
 		ncores = mips_cps_numcores(cl);
@@ -394,7 +397,7 @@ static void init_cluster_l2(void)
 {
 	u32 l2_cfg, l2sm_cop, result;
 
-	while (1) {
+	while (!mips_cm_is_l2_hci_broken) {
 		l2_cfg = read_gcr_redir_l2_ram_config();
 
 		/* If HCI is not supported, use the state machine below */

-- 
2.45.2

[PATCH v3 5/5] MIPS: mobileye: dts: eyeq6h: Enable cluster support

[Gregory CLEMENT]

The CM3.5 device used in EyeQ6H SoCs incorrectly reports the status
for Hardware Cache Initialization (HCI). This commit adds the
compatible string for the CM to acknowledge this issue, which enables
the use of the second CPU cluster.

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
 arch/mips/boot/dts/mobileye/eyeq6h.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/boot/dts/mobileye/eyeq6h.dtsi b/arch/mips/boot/dts/mobileye/eyeq6h.dtsi
index 4a1a43f351d39625b520a16d035cacd2e29d157c..dabd5ed778b739b62f5c6e7348f1837a207dbb6c 100644
--- a/arch/mips/boot/dts/mobileye/eyeq6h.dtsi
+++ b/arch/mips/boot/dts/mobileye/eyeq6h.dtsi
@@ -32,6 +32,10 @@ cpu_intc: interrupt-controller {
 		#interrupt-cells = <1>;
 	};
 
+	coherency-manager {
+		compatible = "mobileye,eyeq6-cm";
+	};
+
 	xtal: clock-30000000 {
 		compatible = "fixed-clock";
 		#clock-cells = <0>;

-- 
2.45.2

Re: [PATCH v3 0/5] MIPS: Allow using multi-cluster with a broken HCI.

[Thomas Bogendoerfer]

On Thu, Jan 23, 2025 at 12:01:53PM +0100, Gregory CLEMENT wrote:
> Hello,
> 
> Some CM3.5 reports indicate that Hardware Cache Initialization is
> complete, but in reality it's not the case. They also incorrectly show
> that Hardware Cache Initialization is supported. Unfortunately, it is
> not possible to detect this issue at runtime and the information has
> to be passed by the device tree.
> 
> In this third version, I rebased on v6.13. I also addressed remarks
> made by Rob and Krzysztof, and endeavored to add more explanation
> about CM, explaining why we now need to represent it in the device
> tree.
> 
> My initial proposal was integrated into the series set by Aleksandar
> here [1]. And the series adding the CM binding was here: [2]. The
> patches 1,2,3, and 5 have no dependencies while patch 4 should depend
> on this series [1]. Actually, those five patches should replace
> patches 10, 11, and 12.
> 
> Gregory
> 
> [1]: https://lore.kernel.org/all/20241028175935.51250-1-arikalo@gmail.com/
> [2]: https://lore.kernel.org/all/20240612-cm_probe-v2-5-a5b55440563c@flygoat.com/
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
> Changes in v3:
> - Provide a more detailed explanation about the CM in the device tree binding.
> - Make the reg property optional for all compatible strings.
> - Use "mobileye" instead of "mti" for the eyeq6-cm compatible string.
> - Address and correct the formatting issues in example and description.
> - Link to v2: https://lore.kernel.org/r/20250116-cluster-hci-broken-v2-0-fc52cfb7a19e@bootlin.com
> 
> Changes in v2:
> - Use compatible string instead of property
> - Link to v1: https://lore.kernel.org/r/20241115-cluster-hci-broken-v1-0-00636800611d@bootlin.com
> 
> ---
> Gregory CLEMENT (5):
>       dt-bindings: mips: Document mti,mips-cm
>       dt-bindings: mips: mips-cm: Add a new compatible string for EyeQ6
>       MIPS: cm: Detect CM quirks from device tree
>       MIPS: CPS: Support broken HCI for multicluster
>       MIPS: mobileye: dts: eyeq6h: Enable cluster support
> 
>  .../devicetree/bindings/mips/mti,mips-cm.yaml      | 57 ++++++++++++++++++++++
>  arch/mips/boot/dts/mobileye/eyeq6h.dtsi            |  4 ++
>  arch/mips/include/asm/mips-cm.h                    | 22 +++++++++
>  arch/mips/kernel/mips-cm.c                         | 14 ++++++
>  arch/mips/kernel/smp-cps.c                         |  5 +-
>  5 files changed, 101 insertions(+), 1 deletion(-)

series applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]