| Message ID | 20241028175935.51250-11-arikalo@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | MIPS: Support I6500 multi-cluster configuration | expand |
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
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
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
在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
在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
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
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.
在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 --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: