| Message ID | 20230811184432.732215-1-vigneshr@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: dts: ti: Introduce AM62P5 SoC and board | expand |
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 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git [2] https://lore.kernel.org/all/20230811192030.3480616-1-a-nandan@ti.com/
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. Best regards, Krzysztof
On 21:26-20230814, Krzysztof Kozlowski wrote: > On 12/08/2023 00:49, Nishanth Menon wrote: Looping in Vinod [...] > > A bit too fast. simple-mfd *is not allowed* on its own. > Actually dtbs_check comes up clean, but more I dug at it, looks like we should probably cleanup. (everything): https://gist.github.com/nmenon/5f5f689333c66697969f5d80ad94cfca (am62p alone): https://gist.github.com/nmenon/9aaa2067a619b12af338647d19b4cf9b $ git grep 'compatible = "simple-mfd";' arch/arm64/boot/dts/ti/ arch/arm64/boot/dts/ti/k3-am62-main.dtsi: compatible = "simple-mfd"; arch/arm64/boot/dts/ti/k3-am62p-main.dtsi: compatible = "simple-mfd"; arch/arm64/boot/dts/ti/k3-am64-main.dtsi: compatible = "simple-mfd"; arch/arm64/boot/dts/ti/k3-am65-main.dtsi: compatible = "simple-mfd"; arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi: compatible = "simple-mfd"; arch/arm64/boot/dts/ti/k3-j7200-main.dtsi: compatible = "simple-mfd"; arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi: compatible = "simple-mfd"; arch/arm64/boot/dts/ti/k3-j721e-main.dtsi: compatible = "simple-mfd"; arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi: compatible = "simple-mfd"; arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi: compatible = "simple-mfd"; arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi: compatible = "simple-mfd"; It is all over our k3 dts folder for dma. Digging further, it looks to have been explicitly permitted by the bindings: $ git grep 'compatible = "simple-mfd";' Documentation/devicetree/bindings/ Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml: compatible = "simple-mfd"; Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml: compatible = "simple-mfd"; Documentation/devicetree/bindings/dma/ti/k3-udma.yaml: compatible = "simple-mfd"; Looks like we will have to cleanup the yaml bindings and the dts nodes in a manner that doesn't break the platforms. I am not saying that simple-mfd usage is correct, but it was explicitly permitted by schema in these instances, are you OK that we clean that in the upcoming merge window as the very first thing we do and let this series through?
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?). 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. 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 >
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. 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 >>
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 >>> >
On 15/08/23 12:29, 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. > I will work towards adding such a file. Unfortunately that cannot be dropped, it indicates the navss instance to be used during PSIL pairing [0] (PSIL proxy to use). Looking again at simple-bus.yaml in dt-schema repo, I do see arbitrary properties are accepted [1]. But I am not sure if its means device specific properties are acceptable? [0] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_psil.html [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/simple-bus.yaml#L60 >