[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877c5jskb2.fsf@BLaptop.bootlin.com>
Date: Fri, 21 Feb 2025 10:45:21 +0100
From: Gregory CLEMENT <gregory.clement@...tlin.com>
To: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc: Jiaxun Yang <jiaxun.yang@...goat.com>, Rob Herring <robh@...nel.org>,
Aleksandar Rikalo <arikalo@...il.com>, Krzysztof Kozlowski
<krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Vladimir
Kondratiev <vladimir.kondratiev@...ileye.com>, Théo Lebrun
<theo.lebrun@...tlin.com>, Tawfik Bayouk <tawfik.bayouk@...ileye.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/5] dt-bindings: mips: mips-cm: Add a new compatible
string for EyeQ6
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@...goat.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@...tlin.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
Powered by blists - more mailing lists