Re: [PATCH v2 0/3] arm64: dts: ti: Introduce AM62P5 SoC and board

From: Andrew Davis
Date: Tue Aug 15 2023 - 09:57:50 EST


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