diff mbox series

[v8,10/13] dt-bindings: mips: cpu: Add property for broken HCI information

Message ID 20241028175935.51250-11-arikalo@gmail.com
State Changes Requested
Headers show
Series MIPS: Support I6500 multi-cluster configuration | expand

Checks

Context Check Description
robh/checkpatch success
robh/patch-applied success
robh/dtbs-check warning build log
robh/dt-meta-schema success

Commit Message

Aleksandar Rikalo Oct. 28, 2024, 5:59 p.m. UTC
From: Gregory CLEMENT <gregory.clement@bootlin.com>

Some CM3.5 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
optional property allows warning about this broken feature that cannot
be detected at runtime.

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Aleksandar Rikalo <arikalo@gmail.com>
Tested-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
 Documentation/devicetree/bindings/mips/cpus.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Krzysztof Kozlowski Oct. 29, 2024, 7:03 a.m. UTC | #1
On Mon, Oct 28, 2024 at 06:59:32PM +0100, Aleksandar Rikalo wrote:
> From: Gregory CLEMENT <gregory.clement@bootlin.com>
> 
> Some CM3.5 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
> optional property allows warning about this broken feature that cannot
> be detected at runtime.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> Signed-off-by: Aleksandar Rikalo <arikalo@gmail.com>
> Tested-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
>  Documentation/devicetree/bindings/mips/cpus.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

I cannot find this patch in v6, nothing in changelog explaining what
happened here.

> diff --git a/Documentation/devicetree/bindings/mips/cpus.yaml b/Documentation/devicetree/bindings/mips/cpus.yaml
> index a85137add668..57e93c07ab1b 100644
> --- a/Documentation/devicetree/bindings/mips/cpus.yaml
> +++ b/Documentation/devicetree/bindings/mips/cpus.yaml
> @@ -47,6 +47,12 @@ properties:
>    clocks:
>      maxItems: 1
>  
> +  cm3-l2-config-hci-broken:

Are these names - cm3, l2, hci - obvious and known in MIPS? HCI usually
means something else - see drivers/bluetooth/ and drivers/nfc/

Is this property applicable for all MIPS vendors? There is no vendor
prefix here, so this is generic for this architecture, right?

Best regards,
Krzysztof
Aleksandar Rikalo Oct. 29, 2024, 12:21 p.m. UTC | #2
On Tue, Oct 29, 2024 at 8:03 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:

> > diff --git a/Documentation/devicetree/bindings/mips/cpus.yaml b/Documentation/devicetree/bindings/mips/cpus.yaml
> > index a85137add668..57e93c07ab1b 100644
> > --- a/Documentation/devicetree/bindings/mips/cpus.yaml
> > +++ b/Documentation/devicetree/bindings/mips/cpus.yaml
> > @@ -47,6 +47,12 @@ properties:
> >    clocks:
> >      maxItems: 1
> >
> > +  cm3-l2-config-hci-broken:
>
> Are these names - cm3, l2, hci - obvious and known in MIPS? HCI usually
> means something else - see drivers/bluetooth/ and drivers/nfc/

I would say yes. At least the name "CM3" (Coherence Manager 3) is
common knowledge.
L2 HCI (L2 Hardware Cache Initialization) is a feature of CM3 that is
non-functional on some systems.

> Is this property applicable for all MIPS vendors? There is no vendor
> prefix here, so this is generic for this architecture, right?

I'm honestly not sure if this is something that only one vendor will use.
Theoretically, there could be more. Perhaps Gregory CLEMENT can give a
more precise answer.

Best Regards,
Aleksandar
Gregory CLEMENT Oct. 29, 2024, 4:08 p.m. UTC | #3
Hi,

> On Tue, Oct 29, 2024 at 8:03 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
>> > diff --git a/Documentation/devicetree/bindings/mips/cpus.yaml b/Documentation/devicetree/bindings/mips/cpus.yaml
>> > index a85137add668..57e93c07ab1b 100644
>> > --- a/Documentation/devicetree/bindings/mips/cpus.yaml
>> > +++ b/Documentation/devicetree/bindings/mips/cpus.yaml
>> > @@ -47,6 +47,12 @@ properties:
>> >    clocks:
>> >      maxItems: 1
>> >
>> > +  cm3-l2-config-hci-broken:
>>
>> Are these names - cm3, l2, hci - obvious and known in MIPS? HCI usually
>> means something else - see drivers/bluetooth/ and drivers/nfc/
>
> I would say yes. At least the name "CM3" (Coherence Manager 3) is
> common knowledge.
> L2 HCI (L2 Hardware Cache Initialization) is a feature of CM3 that is
> non-functional on some systems.
>
>> Is this property applicable for all MIPS vendors? There is no vendor
>> prefix here, so this is generic for this architecture, right?
>
> I'm honestly not sure if this is something that only one vendor will use.
> Theoretically, there could be more. Perhaps Gregory CLEMENT can give a
> more precise answer.

All I know is that this property is needed because of an issue in this
CPU designed by Imagination. So, to my knowledge, it is present at least
on some Imagination CPUs, but since it is an issue, I think any other
MIPS designer could encounter the same problem.

Gregory

>
> Best Regards,
> Aleksandar
Jiaxun Yang Oct. 29, 2024, 4:11 p.m. UTC | #4
在2024年10月29日十月 下午12:21,Aleksandar Rikalo写道:
[...]
>
>> Is this property applicable for all MIPS vendors? There is no vendor
>> prefix here, so this is generic for this architecture, right?

I'd say the best vendor prefix is mti in this case.

CM3 IP block is supplied by MIPS Technology, it is not a part of MIPS
architecture spec.

Thanks
Jiaxun Yang Oct. 30, 2024, 11:35 a.m. UTC | #5
在2024年10月29日十月 下午4:11,Jiaxun Yang写道:
> 在2024年10月29日十月 下午12:21,Aleksandar Rikalo写道:
> [...]
>>
>>> Is this property applicable for all MIPS vendors? There is no vendor
>>> prefix here, so this is generic for this architecture, right?
>
> I'd say the best vendor prefix is mti in this case.
>
> CM3 IP block is supplied by MIPS Technology, it is not a part of MIPS
> architecture spec.

I just tried to revise this problem and I think a better approach would
be picking my CM binding [1] patch and add this as a property to CM binding.

You don't need to pick rest of that series, this binding alone is sufficient,
and it's already being reviewed.

Thanks
[1]: https://lore.kernel.org/all/20240612-cm_probe-v2-5-a5b55440563c@flygoat.com/
>
> Thanks
> -- 
> - Jiaxun
Gregory CLEMENT Oct. 31, 2024, 8:13 a.m. UTC | #6
Hi Jiaxun,

> 在2024年10月29日十月 下午4:11,Jiaxun Yang写道:
>> 在2024年10月29日十月 下午12:21,Aleksandar Rikalo写道:
>> [...]
>>>
>>>> Is this property applicable for all MIPS vendors? There is no vendor
>>>> prefix here, so this is generic for this architecture, right?
>>
>> I'd say the best vendor prefix is mti in this case.
>>
>> CM3 IP block is supplied by MIPS Technology, it is not a part of MIPS
>> architecture spec.
>
> I just tried to revise this problem and I think a better approach would
> be picking my CM binding [1] patch and add this as a property to CM binding.
>
> You don't need to pick rest of that series, this binding alone is sufficient,
> and it's already being reviewed.
>
> Thanks
> [1]:
> https://lore.kernel.org/all/20240612-cm_probe-v2-5-a5b55440563c@flygoat.com/

I had a look at your series and it seems that all the issues raised were
solved, so why wasn't it merged?

Regarding the binding in particular: If we add the property
"cm3-l2-config-hci-broken", then it should be optional. However, the reg
property also should be optional. Indeed, if we can detect the CM
address, we shouldn't use a reg property.

If we go in this direction, not only will the binding be modified but
also code in arch/mips/kernel/mips-cm.c to handle this new property and
manage the case where the reg is not needed. Additionally, we'll need to
modify code in arch/mips/kernel/smp-cps.c to retrieve information about
the HCI.

I can write a series to illustrate it, if needed.

Gregory

>>
>> Thanks
>> -- 
>> - Jiaxun
>
> -- 
> - Jiaxun
Thomas Bogendoerfer Oct. 31, 2024, 2:42 p.m. UTC | #7
On Thu, Oct 31, 2024 at 09:13:57AM +0100, Gregory CLEMENT wrote:
> Hi Jiaxun,
> 
> > 在2024年10月29日十月 下午4:11,Jiaxun Yang写道:
> >> 在2024年10月29日十月 下午12:21,Aleksandar Rikalo写道:
> >> [...]
> >>>
> >>>> Is this property applicable for all MIPS vendors? There is no vendor
> >>>> prefix here, so this is generic for this architecture, right?
> >>
> >> I'd say the best vendor prefix is mti in this case.
> >>
> >> CM3 IP block is supplied by MIPS Technology, it is not a part of MIPS
> >> architecture spec.
> >
> > I just tried to revise this problem and I think a better approach would
> > be picking my CM binding [1] patch and add this as a property to CM binding.
> >
> > You don't need to pick rest of that series, this binding alone is sufficient,
> > and it's already being reviewed.
> >
> > Thanks
> > [1]:
> > https://lore.kernel.org/all/20240612-cm_probe-v2-5-a5b55440563c@flygoat.com/
> 
> I had a look at your series and it seems that all the issues raised were
> solved, so why wasn't it merged?

https://lore.kernel.org/all/2xkut5pyzk4b4ugl4ku72y4rfqrfsoxj4aww2jwlgkc3lmd464@zwf773fr7fpq/

so it's still unclear to me, whether there is something to fix or not.

Thomas.
Jiaxun Yang Oct. 31, 2024, 3:27 p.m. UTC | #8
在2024年10月31日十月 下午2:42,Thomas Bogendoerfer写道:
> On Thu, Oct 31, 2024 at 09:13:57AM +0100, Gregory CLEMENT wrote:
>> Hi Jiaxun,
>> 
>> > 在2024年10月29日十月 下午4:11,Jiaxun Yang写道:
>> >> 在2024年10月29日十月 下午12:21,Aleksandar Rikalo写道:
>> >> [...]
>> >>>
>> >>>> Is this property applicable for all MIPS vendors? There is no vendor
>> >>>> prefix here, so this is generic for this architecture, right?
>> >>
>> >> I'd say the best vendor prefix is mti in this case.
>> >>
>> >> CM3 IP block is supplied by MIPS Technology, it is not a part of MIPS
>> >> architecture spec.
>> >
>> > I just tried to revise this problem and I think a better approach would
>> > be picking my CM binding [1] patch and add this as a property to CM binding.
>> >
>> > You don't need to pick rest of that series, this binding alone is sufficient,
>> > and it's already being reviewed.
>> >
>> > Thanks
>> > [1]:
>> > https://lore.kernel.org/all/20240612-cm_probe-v2-5-a5b55440563c@flygoat.com/
>> 
>> I had a look at your series and it seems that all the issues raised were
>> solved, so why wasn't it merged?
>
> https://lore.kernel.org/all/2xkut5pyzk4b4ugl4ku72y4rfqrfsoxj4aww2jwlgkc3lmd464@zwf773fr7fpq/

Yes this is still pending.

My FPGA boards are constantly breaking down so I’m on radio silence recently.

Sorry for the confusion.

Thanks

>
> so it's still unclear to me, whether there is something to fix or not.
>
> Thomas.
>
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/mips/cpus.yaml b/Documentation/devicetree/bindings/mips/cpus.yaml
index a85137add668..57e93c07ab1b 100644
--- a/Documentation/devicetree/bindings/mips/cpus.yaml
+++ b/Documentation/devicetree/bindings/mips/cpus.yaml
@@ -47,6 +47,12 @@  properties:
   clocks:
     maxItems: 1
 
+  cm3-l2-config-hci-broken:
+    type: boolean
+    description:
+      If present, indicates that the HCI (Hardware Cache Initialization)
+      information for the L2 cache in multi-cluster configuration is broken.
+
   device_type: true
 
 allOf: