[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a96ce59e-f354-4814-ac33-7df268eea202@ti.com>
Date: Tue, 15 Aug 2023 08:56:51 -0500
From: Andrew Davis <afd@...com>
To: Vignesh Raghavendra <vigneshr@...com>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Nishanth Menon <nm@...com>, Tero Kristo <kristo@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>
CC: <linux-arm-kernel@...ts.infradead.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] arm64: dts: ti: Introduce AM62P5 SoC and board
On 8/15/23 1:59 AM, Vignesh Raghavendra wrote:
>
>
> On 15/08/23 02:24, Andrew Davis wrote:
>> On 8/14/23 2:26 PM, Krzysztof Kozlowski wrote:
>>> On 12/08/2023 00:49, Nishanth Menon wrote:
>>>> Hi Vignesh Raghavendra,
>>>>
>>>> On Sat, 12 Aug 2023 00:14:29 +0530, Vignesh Raghavendra wrote:
>>>>> This series adds basic support for AM62P family of SoCs and
>>>>> specifically
>>>>> AM62P5 variant. Also adds AM62P5-SK support with basic peripheral
>>>>> like UART.
>>>>>
>>>>> TRM at [0] and Schematics is at [1]
>>>>>
>>>>> [0]: https://www.ti.com/lit/pdf/spruj83
>>>>> [1]: https://www.ti.com/lit/zip/sprr487
>>>>>
>>>>> [...]
>>>>
>>>> Note: since the changes were trivial, I incorporated the cosmetic
>>>> fixup suggested by Andrew locally when I applied. I have also dropped
>>>> bootph property from board's reserved nodes inline with what we did
>>>> for j721s2[2]. Thanks for the bootlog.
>>>>
>>>> I have applied the following to branch ti-k3-dts-next on [1].
>>>> Thank you!
>>>>
>>>> [1/3] dt-bindings: arm: ti: Add bindings for AM62P5 SoCs
>>>> commit: b57fc5cbdbdfd04d44697800a9d59aeb3be2f273
>>>> [2/3] arm64: dts: ti: Introduce AM62P5 family of SoCs
>>>> commit: 29075cc09f43a024d962da66d2e4f9eb577713d0
>>>> [3/3] arm64: dts: ti: Add support for the AM62P5 Starter Kit
>>>> commit: 935c4047d42e53a06ec768ddc495a44f6869209c
>>>>
>>>
>>> A bit too fast. simple-mfd *is not allowed* on its own.
>>>
>> We have the rule against ['syscon', 'simple-mfd'], which requires a 3rd
>> specific compatible, but it seems 'simple-mfd' is allowed in the same way
>> as "simple-bus" (not sure how or why, I would expect a `failed to match any
>> schema with compatible`, but I'm not getting that either?).
>>
>
> Indeed, I didn't see any warnings from dtbs_check so far
>
>> We can add something like simple-mfd.yaml for this to explicitly check that
>> the compatible has minItems: 2.
>>
>> But in this case these seem to be just a typo and we meant "simple-bus"
>> here,
>> then it got copy/pasted over our k3 tree.
>>
>
> I dont think "simple-bus" is enough due to presence to TI specific
> property (ti,sci-dev-id). So this will warrant a separate yaml bindings.
What does that property actually do for us? I know the DMASS has a device ID,
but many of the child devices have their own. Do we need the top level ID and
would it be easier to just drop that property here instead?
Andrew
> I will work towards adding such a file.
>
>> So as Nishanth suggested, we can clean this up first thing next cycle, then
>> add a rule to prevent it from happening for anyone else again while we
>> are at it.
>>
>> Andrew
>>
>>> Best regards,
>>> Krzysztof
>>>
>
Powered by blists - more mailing lists