* [PATCH 0/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards
@ 2024-03-21 21:47 ` Josua Mayer
0 siblings, 0 replies; 48+ messages in thread
From: Josua Mayer @ 2024-03-21 21:47 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel, Josua Mayer
SolidRun CN9130 SoM is a mostly pin-comptible replacement for Armada 388
SoM used in Clearfog and Clearfog Pro boards.
1. Add new binding for compatible strings closely matching the original.
2. Add device-tree includes for SoM and carrier shared design.
3. Add device-tree for both Clearfog Base and Pro.
NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE:
CN9130 SoM has a different footprint from Armada 388 SoM.
Components on the carrier board below the SoM may collide causing
damage, such as on Clearfog Base.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Josua Mayer (2):
dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards
arm64: dts: add description for solidrun cn9130 som and clearfog boards
.../bindings/arm/marvell/armada-7k-8k.yaml | 12 +
arch/arm64/boot/dts/marvell/Makefile | 2 +
arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++
arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++
arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++
arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 +++++++++++++
6 files changed, 759 insertions(+)
---
base-commit: e8f897f4afef0031fe618a8e94127a0934896aba
change-id: 20240318-cn9130-som-848e86acb0ac
Sincerely,
--
Josua Mayer <josua@solid-run.com>
^ permalink raw reply [flat|nested] 48+ messages in thread* [PATCH 0/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards @ 2024-03-21 21:47 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-21 21:47 UTC (permalink / raw) To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel, Josua Mayer SolidRun CN9130 SoM is a mostly pin-comptible replacement for Armada 388 SoM used in Clearfog and Clearfog Pro boards. 1. Add new binding for compatible strings closely matching the original. 2. Add device-tree includes for SoM and carrier shared design. 3. Add device-tree for both Clearfog Base and Pro. NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: CN9130 SoM has a different footprint from Armada 388 SoM. Components on the carrier board below the SoM may collide causing damage, such as on Clearfog Base. Signed-off-by: Josua Mayer <josua@solid-run.com> --- Josua Mayer (2): dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards arm64: dts: add description for solidrun cn9130 som and clearfog boards .../bindings/arm/marvell/armada-7k-8k.yaml | 12 + arch/arm64/boot/dts/marvell/Makefile | 2 + arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++ arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 +++++++++++++ 6 files changed, 759 insertions(+) --- base-commit: e8f897f4afef0031fe618a8e94127a0934896aba change-id: 20240318-cn9130-som-848e86acb0ac Sincerely, -- Josua Mayer <josua@solid-run.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-21 21:47 ` Josua Mayer @ 2024-03-21 21:47 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-21 21:47 UTC (permalink / raw) To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel, Josua Mayer Add bindings for SolidRun Clearfog boards, using a new SoM based on CN9130 SoC. The carrier boards are identical to the older Armada 388 based Clearfog boards. For consistency the carrier part of compatible strings are copied, including the established "-a1" suffix. Signed-off-by: Josua Mayer <josua@solid-run.com> --- .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml index 16d2e132d3d1..36bdfd1bedd9 100644 --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml @@ -82,4 +82,16 @@ properties: - const: marvell,armada-ap807-quad - const: marvell,armada-ap807 + - description: + SolidRun CN9130 clearfog family single-board computers + items: + - enum: + - solidrun,clearfog-base-a1 + - solidrun,clearfog-pro-a1 + - const: solidrun,clearfog-a1 + - const: solidrun,cn9130-sr-som + - const: marvell,cn9130 + - const: marvell,armada-ap807-quad + - const: marvell,armada-ap807 + additionalProperties: true -- 2.35.3 ^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-21 21:47 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-21 21:47 UTC (permalink / raw) To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel, Josua Mayer Add bindings for SolidRun Clearfog boards, using a new SoM based on CN9130 SoC. The carrier boards are identical to the older Armada 388 based Clearfog boards. For consistency the carrier part of compatible strings are copied, including the established "-a1" suffix. Signed-off-by: Josua Mayer <josua@solid-run.com> --- .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml index 16d2e132d3d1..36bdfd1bedd9 100644 --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml @@ -82,4 +82,16 @@ properties: - const: marvell,armada-ap807-quad - const: marvell,armada-ap807 + - description: + SolidRun CN9130 clearfog family single-board computers + items: + - enum: + - solidrun,clearfog-base-a1 + - solidrun,clearfog-pro-a1 + - const: solidrun,clearfog-a1 + - const: solidrun,cn9130-sr-som + - const: marvell,cn9130 + - const: marvell,armada-ap807-quad + - const: marvell,armada-ap807 + additionalProperties: true -- 2.35.3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-21 21:47 ` Josua Mayer @ 2024-03-22 2:16 ` Rob Herring -1 siblings, 0 replies; 48+ messages in thread From: Rob Herring @ 2024-03-22 2:16 UTC (permalink / raw) To: Josua Mayer Cc: Yazan Shhady, linux-kernel, Andrew Lunn, Conor Dooley, Sebastian Hesselbarth, Rob Herring, Gregory Clement, devicetree, linux-arm-kernel, Krzysztof Kozlowski On Thu, 21 Mar 2024 22:47:11 +0100, Josua Mayer wrote: > Add bindings for SolidRun Clearfog boards, using a new SoM based on > CN9130 SoC. > The carrier boards are identical to the older Armada 388 based Clearfog > boards. For consistency the carrier part of compatible strings are > copied, including the established "-a1" suffix. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- > .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > Acked-by: Rob Herring <robh@kernel.org> ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-22 2:16 ` Rob Herring 0 siblings, 0 replies; 48+ messages in thread From: Rob Herring @ 2024-03-22 2:16 UTC (permalink / raw) To: Josua Mayer Cc: Yazan Shhady, linux-kernel, Andrew Lunn, Conor Dooley, Sebastian Hesselbarth, Rob Herring, Gregory Clement, devicetree, linux-arm-kernel, Krzysztof Kozlowski On Thu, 21 Mar 2024 22:47:11 +0100, Josua Mayer wrote: > Add bindings for SolidRun Clearfog boards, using a new SoM based on > CN9130 SoC. > The carrier boards are identical to the older Armada 388 based Clearfog > boards. For consistency the carrier part of compatible strings are > copied, including the established "-a1" suffix. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- > .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > Acked-by: Rob Herring <robh@kernel.org> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-21 21:47 ` Josua Mayer @ 2024-03-22 10:08 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-22 10:08 UTC (permalink / raw) To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 21.03.24 um 22:47 schrieb Josua Mayer: > Add bindings for SolidRun Clearfog boards, using a new SoM based on > CN9130 SoC. > The carrier boards are identical to the older Armada 388 based Clearfog > boards. For consistency the carrier part of compatible strings are > copied, including the established "-a1" suffix. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- > .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > index 16d2e132d3d1..36bdfd1bedd9 100644 > --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > @@ -82,4 +82,16 @@ properties: > - const: marvell,armada-ap807-quad > - const: marvell,armada-ap807 > > + - description: > + SolidRun CN9130 clearfog family single-board computers > + items: > + - enum: > + - solidrun,clearfog-base-a1 > + - solidrun,clearfog-pro-a1 > + - const: solidrun,clearfog-a1 > + - const: solidrun,cn9130-sr-som > + - const: marvell,cn9130 > + - const: marvell,armada-ap807-quad > + - const: marvell,armada-ap807 > + > additionalProperties: true Before merging I would like some feedback about adding another product later, to ensure the compatibles above are adequate? In particular: - sequence of soc, cp, carrier compatibles - name of som compatible Draft for future bindings: - description: SolidRun CN9130 SoM based single-board computers with 1 external CP on the Carrier. items: - enum: - solidrun,cn9131-solidwan - const: marvell,cn9131 - const: solidrun,cn9130-sr-som - const: marvell,cn9130 - const: marvell,armada-ap807-quad - const: marvell,armada-ap807 - description: SolidRun CN9132 COM-Express Type 7 based single-board computers with 2 external CPs on the COM. items: - enum: - solidrun,cn9132-clearfog - const: solidrun,cn9132-cex7 - const: marvell,cn9132 - const: marvell,cn9131 - const: marvell,cn9130 - const: marvell,armada-ap807-quad - const: marvell,armada-ap807 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-22 10:08 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-22 10:08 UTC (permalink / raw) To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 21.03.24 um 22:47 schrieb Josua Mayer: > Add bindings for SolidRun Clearfog boards, using a new SoM based on > CN9130 SoC. > The carrier boards are identical to the older Armada 388 based Clearfog > boards. For consistency the carrier part of compatible strings are > copied, including the established "-a1" suffix. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- > .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > index 16d2e132d3d1..36bdfd1bedd9 100644 > --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > @@ -82,4 +82,16 @@ properties: > - const: marvell,armada-ap807-quad > - const: marvell,armada-ap807 > > + - description: > + SolidRun CN9130 clearfog family single-board computers > + items: > + - enum: > + - solidrun,clearfog-base-a1 > + - solidrun,clearfog-pro-a1 > + - const: solidrun,clearfog-a1 > + - const: solidrun,cn9130-sr-som > + - const: marvell,cn9130 > + - const: marvell,armada-ap807-quad > + - const: marvell,armada-ap807 > + > additionalProperties: true Before merging I would like some feedback about adding another product later, to ensure the compatibles above are adequate? In particular: - sequence of soc, cp, carrier compatibles - name of som compatible Draft for future bindings: - description: SolidRun CN9130 SoM based single-board computers with 1 external CP on the Carrier. items: - enum: - solidrun,cn9131-solidwan - const: marvell,cn9131 - const: solidrun,cn9130-sr-som - const: marvell,cn9130 - const: marvell,armada-ap807-quad - const: marvell,armada-ap807 - description: SolidRun CN9132 COM-Express Type 7 based single-board computers with 2 external CPs on the COM. items: - enum: - solidrun,cn9132-clearfog - const: solidrun,cn9132-cex7 - const: marvell,cn9132 - const: marvell,cn9131 - const: marvell,cn9130 - const: marvell,armada-ap807-quad - const: marvell,armada-ap807 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-22 10:08 ` Josua Mayer @ 2024-03-25 19:34 ` Krzysztof Kozlowski -1 siblings, 0 replies; 48+ messages in thread From: Krzysztof Kozlowski @ 2024-03-25 19:34 UTC (permalink / raw) To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On 22/03/2024 11:08, Josua Mayer wrote: > Am 21.03.24 um 22:47 schrieb Josua Mayer: >> Add bindings for SolidRun Clearfog boards, using a new SoM based on >> CN9130 SoC. >> The carrier boards are identical to the older Armada 388 based Clearfog >> boards. For consistency the carrier part of compatible strings are >> copied, including the established "-a1" suffix. >> >> Signed-off-by: Josua Mayer <josua@solid-run.com> >> --- >> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >> index 16d2e132d3d1..36bdfd1bedd9 100644 >> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >> @@ -82,4 +82,16 @@ properties: >> - const: marvell,armada-ap807-quad >> - const: marvell,armada-ap807 >> >> + - description: >> + SolidRun CN9130 clearfog family single-board computers >> + items: >> + - enum: >> + - solidrun,clearfog-base-a1 >> + - solidrun,clearfog-pro-a1 >> + - const: solidrun,clearfog-a1 >> + - const: solidrun,cn9130-sr-som >> + - const: marvell,cn9130 >> + - const: marvell,armada-ap807-quad >> + - const: marvell,armada-ap807 >> + >> additionalProperties: true > > Before merging I would like some feedback about adding > another product later, to ensure the compatibles above > are adequate? In particular: > - sequence of soc, cp, carrier compatibles > - name of som compatible > > Draft for future bindings: > - description: > SolidRun CN9130 SoM based single-board computers > with 1 external CP on the Carrier. > items: > - enum: > - solidrun,cn9131-solidwan > - const: marvell,cn9131 > - const: solidrun,cn9130-sr-som This does not look correct. cn9131 is not compatible with your som. > - const: marvell,cn9130 SoCs are compatible only in some cases, e.g. one is a subset of another like stripped out of modem. Are you sure this is your case? > - const: marvell,armada-ap807-quad > - const: marvell,armada-ap807 Anyway, 6 compatibles is beyond useful amount. What are you expressing here? Why is this even armada ap807? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-25 19:34 ` Krzysztof Kozlowski 0 siblings, 0 replies; 48+ messages in thread From: Krzysztof Kozlowski @ 2024-03-25 19:34 UTC (permalink / raw) To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On 22/03/2024 11:08, Josua Mayer wrote: > Am 21.03.24 um 22:47 schrieb Josua Mayer: >> Add bindings for SolidRun Clearfog boards, using a new SoM based on >> CN9130 SoC. >> The carrier boards are identical to the older Armada 388 based Clearfog >> boards. For consistency the carrier part of compatible strings are >> copied, including the established "-a1" suffix. >> >> Signed-off-by: Josua Mayer <josua@solid-run.com> >> --- >> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >> index 16d2e132d3d1..36bdfd1bedd9 100644 >> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >> @@ -82,4 +82,16 @@ properties: >> - const: marvell,armada-ap807-quad >> - const: marvell,armada-ap807 >> >> + - description: >> + SolidRun CN9130 clearfog family single-board computers >> + items: >> + - enum: >> + - solidrun,clearfog-base-a1 >> + - solidrun,clearfog-pro-a1 >> + - const: solidrun,clearfog-a1 >> + - const: solidrun,cn9130-sr-som >> + - const: marvell,cn9130 >> + - const: marvell,armada-ap807-quad >> + - const: marvell,armada-ap807 >> + >> additionalProperties: true > > Before merging I would like some feedback about adding > another product later, to ensure the compatibles above > are adequate? In particular: > - sequence of soc, cp, carrier compatibles > - name of som compatible > > Draft for future bindings: > - description: > SolidRun CN9130 SoM based single-board computers > with 1 external CP on the Carrier. > items: > - enum: > - solidrun,cn9131-solidwan > - const: marvell,cn9131 > - const: solidrun,cn9130-sr-som This does not look correct. cn9131 is not compatible with your som. > - const: marvell,cn9130 SoCs are compatible only in some cases, e.g. one is a subset of another like stripped out of modem. Are you sure this is your case? > - const: marvell,armada-ap807-quad > - const: marvell,armada-ap807 Anyway, 6 compatibles is beyond useful amount. What are you expressing here? Why is this even armada ap807? Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-25 19:34 ` Krzysztof Kozlowski @ 2024-03-25 20:12 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-25 20:12 UTC (permalink / raw) To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski: > On 22/03/2024 11:08, Josua Mayer wrote: >> Am 21.03.24 um 22:47 schrieb Josua Mayer: >>> Add bindings for SolidRun Clearfog boards, using a new SoM based on >>> CN9130 SoC. >>> The carrier boards are identical to the older Armada 388 based Clearfog >>> boards. For consistency the carrier part of compatible strings are >>> copied, including the established "-a1" suffix. >>> >>> Signed-off-by: Josua Mayer <josua@solid-run.com> >>> --- >>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>> index 16d2e132d3d1..36bdfd1bedd9 100644 >>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>> @@ -82,4 +82,16 @@ properties: >>> - const: marvell,armada-ap807-quad >>> - const: marvell,armada-ap807 >>> >>> + - description: >>> + SolidRun CN9130 clearfog family single-board computers >>> + items: >>> + - enum: >>> + - solidrun,clearfog-base-a1 >>> + - solidrun,clearfog-pro-a1 >>> + - const: solidrun,clearfog-a1 >>> + - const: solidrun,cn9130-sr-som >>> + - const: marvell,cn9130 >>> + - const: marvell,armada-ap807-quad >>> + - const: marvell,armada-ap807 >>> + >>> additionalProperties: true >> Before merging I would like some feedback about adding >> another product later, to ensure the compatibles above >> are adequate? In particular: >> - sequence of soc, cp, carrier compatibles >> - name of som compatible >> >> Draft for future bindings: >> - description: >> SolidRun CN9130 SoM based single-board computers >> with 1 external CP on the Carrier. >> items: >> - enum: >> - solidrun,cn9131-solidwan >> - const: marvell,cn9131 >> - const: solidrun,cn9130-sr-som > This does not look correct. cn9131 is not compatible with your som. This is partially my question. I considered changing the som to "cn913x-sr-som". The SoM itself is always 9130, it contains the base SoC with 1x AP and 1x CP in a single chip. 9131 and 9132 <happen> on the carrier boards. > >> - const: marvell,cn9130 > SoCs are compatible only in some cases, e.g. one is a subset of another > like stripped out of modem. Are you sure this is your case? This is more complex, CN9131 and CN9132 are not single SoCs. A "9132" is instantiated by connecting two southbridge chips via a Marvell defined bus, each providing additional IO such as network, i2c, gpio. Note that even the first, "9130", while a single chip, contains two dies: An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c), and a "CP" (Communication Processor I assume) with lots of IO. This CP as far as I know today is identical to the southbridges mentioned above. >> - const: marvell,armada-ap807-quad >> - const: marvell,armada-ap807 > Anyway, 6 compatibles is beyond useful amount. What are you expressing > here? I copied this part from the examples earlier in the file, such as: - description: Armada CN9132 SoC with two external CPs items: - const: marvell,cn9132 - const: marvell,cn9131 - const: marvell,cn9130 - const: marvell,armada-ap807-quad - const: marvell,armada-ap807 > Why is this even armada ap807? We noticed ap807 != ap806 (cn913x != 8040), because the thermal sensor coefficients converting raw values to celsius differed. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-25 20:12 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-25 20:12 UTC (permalink / raw) To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski: > On 22/03/2024 11:08, Josua Mayer wrote: >> Am 21.03.24 um 22:47 schrieb Josua Mayer: >>> Add bindings for SolidRun Clearfog boards, using a new SoM based on >>> CN9130 SoC. >>> The carrier boards are identical to the older Armada 388 based Clearfog >>> boards. For consistency the carrier part of compatible strings are >>> copied, including the established "-a1" suffix. >>> >>> Signed-off-by: Josua Mayer <josua@solid-run.com> >>> --- >>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>> index 16d2e132d3d1..36bdfd1bedd9 100644 >>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>> @@ -82,4 +82,16 @@ properties: >>> - const: marvell,armada-ap807-quad >>> - const: marvell,armada-ap807 >>> >>> + - description: >>> + SolidRun CN9130 clearfog family single-board computers >>> + items: >>> + - enum: >>> + - solidrun,clearfog-base-a1 >>> + - solidrun,clearfog-pro-a1 >>> + - const: solidrun,clearfog-a1 >>> + - const: solidrun,cn9130-sr-som >>> + - const: marvell,cn9130 >>> + - const: marvell,armada-ap807-quad >>> + - const: marvell,armada-ap807 >>> + >>> additionalProperties: true >> Before merging I would like some feedback about adding >> another product later, to ensure the compatibles above >> are adequate? In particular: >> - sequence of soc, cp, carrier compatibles >> - name of som compatible >> >> Draft for future bindings: >> - description: >> SolidRun CN9130 SoM based single-board computers >> with 1 external CP on the Carrier. >> items: >> - enum: >> - solidrun,cn9131-solidwan >> - const: marvell,cn9131 >> - const: solidrun,cn9130-sr-som > This does not look correct. cn9131 is not compatible with your som. This is partially my question. I considered changing the som to "cn913x-sr-som". The SoM itself is always 9130, it contains the base SoC with 1x AP and 1x CP in a single chip. 9131 and 9132 <happen> on the carrier boards. > >> - const: marvell,cn9130 > SoCs are compatible only in some cases, e.g. one is a subset of another > like stripped out of modem. Are you sure this is your case? This is more complex, CN9131 and CN9132 are not single SoCs. A "9132" is instantiated by connecting two southbridge chips via a Marvell defined bus, each providing additional IO such as network, i2c, gpio. Note that even the first, "9130", while a single chip, contains two dies: An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c), and a "CP" (Communication Processor I assume) with lots of IO. This CP as far as I know today is identical to the southbridges mentioned above. >> - const: marvell,armada-ap807-quad >> - const: marvell,armada-ap807 > Anyway, 6 compatibles is beyond useful amount. What are you expressing > here? I copied this part from the examples earlier in the file, such as: - description: Armada CN9132 SoC with two external CPs items: - const: marvell,cn9132 - const: marvell,cn9131 - const: marvell,cn9130 - const: marvell,armada-ap807-quad - const: marvell,armada-ap807 > Why is this even armada ap807? We noticed ap807 != ap806 (cn913x != 8040), because the thermal sensor coefficients converting raw values to celsius differed. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-25 20:12 ` Josua Mayer @ 2024-03-26 6:41 ` Krzysztof Kozlowski -1 siblings, 0 replies; 48+ messages in thread From: Krzysztof Kozlowski @ 2024-03-26 6:41 UTC (permalink / raw) To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On 25/03/2024 21:12, Josua Mayer wrote: > Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski: >> On 22/03/2024 11:08, Josua Mayer wrote: >>> Am 21.03.24 um 22:47 schrieb Josua Mayer: >>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on >>>> CN9130 SoC. >>>> The carrier boards are identical to the older Armada 388 based Clearfog >>>> boards. For consistency the carrier part of compatible strings are >>>> copied, including the established "-a1" suffix. >>>> >>>> Signed-off-by: Josua Mayer <josua@solid-run.com> >>>> --- >>>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >>>> 1 file changed, 12 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>> index 16d2e132d3d1..36bdfd1bedd9 100644 >>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>> @@ -82,4 +82,16 @@ properties: >>>> - const: marvell,armada-ap807-quad >>>> - const: marvell,armada-ap807 >>>> >>>> + - description: >>>> + SolidRun CN9130 clearfog family single-board computers >>>> + items: >>>> + - enum: >>>> + - solidrun,clearfog-base-a1 >>>> + - solidrun,clearfog-pro-a1 >>>> + - const: solidrun,clearfog-a1 >>>> + - const: solidrun,cn9130-sr-som >>>> + - const: marvell,cn9130 >>>> + - const: marvell,armada-ap807-quad >>>> + - const: marvell,armada-ap807 >>>> + >>>> additionalProperties: true >>> Before merging I would like some feedback about adding >>> another product later, to ensure the compatibles above >>> are adequate? In particular: >>> - sequence of soc, cp, carrier compatibles >>> - name of som compatible >>> >>> Draft for future bindings: >>> - description: >>> SolidRun CN9130 SoM based single-board computers >>> with 1 external CP on the Carrier. >>> items: >>> - enum: >>> - solidrun,cn9131-solidwan >>> - const: marvell,cn9131 >>> - const: solidrun,cn9130-sr-som >> This does not look correct. cn9131 is not compatible with your som. > This is partially my question. > I considered changing the som to "cn913x-sr-som". > > The SoM itself is always 9130, it contains the base SoC > with 1x AP and 1x CP in a single chip. > 9131 and 9132 <happen> on the carrier boards. No wildcards, but if the SoM name is 9130 then use 9130. The problem is that you use cn9130 SoC as fallback. > >> >>> - const: marvell,cn9130 >> SoCs are compatible only in some cases, e.g. one is a subset of another >> like stripped out of modem. Are you sure this is your case? > This is more complex, CN9131 and CN9132 are not single SoCs. > A "9132" is instantiated by connecting two southbridge chips > via a Marvell defined bus, each providing additional IO > such as network, i2c, gpio. > > Note that even the first, "9130", while a single chip, contains two dies: > An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c), > and a "CP" (Communication Processor I assume) with lots of IO. > This CP as far as I know today is identical to the southbridges > mentioned above. OK, but how does it affect compatibility between them? Which parts are the same? Or how much is shared? > >>> - const: marvell,armada-ap807-quad >>> - const: marvell,armada-ap807 >> Anyway, 6 compatibles is beyond useful amount. What are you expressing >> here? > I copied this part from the examples earlier in the file, such as: > - description: Armada CN9132 SoC with two external CPs > items: > - const: marvell,cn9132 > - const: marvell,cn9131 > - const: marvell,cn9130 > - const: marvell,armada-ap807-quad > - const: marvell,armada-ap807 >> Why is this even armada ap807? > We noticed ap807 != ap806 (cn913x != 8040), > because the thermal sensor coefficients converting > raw values to celsius differed. That's also not the best example. Might be correct but also looks over-complicated. The point of board-level compatibles is to identify machine and its common parts. It has little impact inside of kernel (at least should be almost no users inside!), but there can be some users, e.g. firmware or user-space. This claims that cn9132 is compatible with ap807, so you have exactly the same base. The same base is not CPU! It's about the S in SoC, so "System". Could firmware use marvell,armada-ap807 compatible to properly detect type of system and treat all these boards as ap807? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-26 6:41 ` Krzysztof Kozlowski 0 siblings, 0 replies; 48+ messages in thread From: Krzysztof Kozlowski @ 2024-03-26 6:41 UTC (permalink / raw) To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On 25/03/2024 21:12, Josua Mayer wrote: > Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski: >> On 22/03/2024 11:08, Josua Mayer wrote: >>> Am 21.03.24 um 22:47 schrieb Josua Mayer: >>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on >>>> CN9130 SoC. >>>> The carrier boards are identical to the older Armada 388 based Clearfog >>>> boards. For consistency the carrier part of compatible strings are >>>> copied, including the established "-a1" suffix. >>>> >>>> Signed-off-by: Josua Mayer <josua@solid-run.com> >>>> --- >>>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >>>> 1 file changed, 12 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>> index 16d2e132d3d1..36bdfd1bedd9 100644 >>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>> @@ -82,4 +82,16 @@ properties: >>>> - const: marvell,armada-ap807-quad >>>> - const: marvell,armada-ap807 >>>> >>>> + - description: >>>> + SolidRun CN9130 clearfog family single-board computers >>>> + items: >>>> + - enum: >>>> + - solidrun,clearfog-base-a1 >>>> + - solidrun,clearfog-pro-a1 >>>> + - const: solidrun,clearfog-a1 >>>> + - const: solidrun,cn9130-sr-som >>>> + - const: marvell,cn9130 >>>> + - const: marvell,armada-ap807-quad >>>> + - const: marvell,armada-ap807 >>>> + >>>> additionalProperties: true >>> Before merging I would like some feedback about adding >>> another product later, to ensure the compatibles above >>> are adequate? In particular: >>> - sequence of soc, cp, carrier compatibles >>> - name of som compatible >>> >>> Draft for future bindings: >>> - description: >>> SolidRun CN9130 SoM based single-board computers >>> with 1 external CP on the Carrier. >>> items: >>> - enum: >>> - solidrun,cn9131-solidwan >>> - const: marvell,cn9131 >>> - const: solidrun,cn9130-sr-som >> This does not look correct. cn9131 is not compatible with your som. > This is partially my question. > I considered changing the som to "cn913x-sr-som". > > The SoM itself is always 9130, it contains the base SoC > with 1x AP and 1x CP in a single chip. > 9131 and 9132 <happen> on the carrier boards. No wildcards, but if the SoM name is 9130 then use 9130. The problem is that you use cn9130 SoC as fallback. > >> >>> - const: marvell,cn9130 >> SoCs are compatible only in some cases, e.g. one is a subset of another >> like stripped out of modem. Are you sure this is your case? > This is more complex, CN9131 and CN9132 are not single SoCs. > A "9132" is instantiated by connecting two southbridge chips > via a Marvell defined bus, each providing additional IO > such as network, i2c, gpio. > > Note that even the first, "9130", while a single chip, contains two dies: > An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c), > and a "CP" (Communication Processor I assume) with lots of IO. > This CP as far as I know today is identical to the southbridges > mentioned above. OK, but how does it affect compatibility between them? Which parts are the same? Or how much is shared? > >>> - const: marvell,armada-ap807-quad >>> - const: marvell,armada-ap807 >> Anyway, 6 compatibles is beyond useful amount. What are you expressing >> here? > I copied this part from the examples earlier in the file, such as: > - description: Armada CN9132 SoC with two external CPs > items: > - const: marvell,cn9132 > - const: marvell,cn9131 > - const: marvell,cn9130 > - const: marvell,armada-ap807-quad > - const: marvell,armada-ap807 >> Why is this even armada ap807? > We noticed ap807 != ap806 (cn913x != 8040), > because the thermal sensor coefficients converting > raw values to celsius differed. That's also not the best example. Might be correct but also looks over-complicated. The point of board-level compatibles is to identify machine and its common parts. It has little impact inside of kernel (at least should be almost no users inside!), but there can be some users, e.g. firmware or user-space. This claims that cn9132 is compatible with ap807, so you have exactly the same base. The same base is not CPU! It's about the S in SoC, so "System". Could firmware use marvell,armada-ap807 compatible to properly detect type of system and treat all these boards as ap807? Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-26 6:41 ` Krzysztof Kozlowski @ 2024-03-26 19:26 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-26 19:26 UTC (permalink / raw) To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 26.03.24 um 07:41 schrieb Krzysztof Kozlowski: > On 25/03/2024 21:12, Josua Mayer wrote: >> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski: >>> On 22/03/2024 11:08, Josua Mayer wrote: >>>> Am 21.03.24 um 22:47 schrieb Josua Mayer: >>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on >>>>> CN9130 SoC. >>>>> The carrier boards are identical to the older Armada 388 based Clearfog >>>>> boards. For consistency the carrier part of compatible strings are >>>>> copied, including the established "-a1" suffix. >>>>> >>>>> Signed-off-by: Josua Mayer <josua@solid-run.com> >>>>> --- >>>>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >>>>> 1 file changed, 12 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>> index 16d2e132d3d1..36bdfd1bedd9 100644 >>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>> @@ -82,4 +82,16 @@ properties: >>>>> - const: marvell,armada-ap807-quad >>>>> - const: marvell,armada-ap807 >>>>> >>>>> + - description: >>>>> + SolidRun CN9130 clearfog family single-board computers >>>>> + items: >>>>> + - enum: >>>>> + - solidrun,clearfog-base-a1 >>>>> + - solidrun,clearfog-pro-a1 >>>>> + - const: solidrun,clearfog-a1 >>>>> + - const: solidrun,cn9130-sr-som >>>>> + - const: marvell,cn9130 >>>>> + - const: marvell,armada-ap807-quad >>>>> + - const: marvell,armada-ap807 >>>>> + >>>>> additionalProperties: true >>>> Before merging I would like some feedback about adding >>>> another product later, to ensure the compatibles above >>>> are adequate? In particular: >>>> - sequence of soc, cp, carrier compatibles >>>> - name of som compatible >>>> >>>> Draft for future bindings: >>>> - description: >>>> SolidRun CN9130 SoM based single-board computers >>>> with 1 external CP on the Carrier. >>>> items: >>>> - enum: >>>> - solidrun,cn9131-solidwan >>>> - const: marvell,cn9131 >>>> - const: solidrun,cn9130-sr-som >>> This does not look correct. cn9131 is not compatible with your som. >> This is partially my question. >> I considered changing the som to "cn913x-sr-som". >> >> The SoM itself is always 9130, it contains the base SoC >> with 1x AP and 1x CP in a single chip. >> 9131 and 9132 <happen> on the carrier boards. > No wildcards, but if the SoM name is 9130 then use 9130. > The problem is that you use cn9130 SoC as fallback. > >>>> - const: marvell,cn9130 >>> SoCs are compatible only in some cases, e.g. one is a subset of another >>> like stripped out of modem. Are you sure this is your case? >> This is more complex, CN9131 and CN9132 are not single SoCs. >> A "9132" is instantiated by connecting two southbridge chips >> via a Marvell defined bus, each providing additional IO >> such as network, i2c, gpio. >> >> Note that even the first, "9130", while a single chip, contains two dies: >> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c), >> and a "CP" (Communication Processor I assume) with lots of IO. >> This CP as far as I know today is identical to the southbridges >> mentioned above. > OK, but how does it affect compatibility between them? Which parts are > the same? Or how much is shared? 9130, 9131, 9132 belong together. 9130 is single chip including two dies: AP, CP. The CP is available as an individual chip, up to two can be connected to one 9130. What does this mean for compatibility? Which compatibility specifically? Is there a definition we can refer to? From software perspective we can always down-grade, i.e. run software only aware of the AP on 9130, 9131 or 9132. But we can't run software referencing the external CPs if they are not connected. >>>> - const: marvell,armada-ap807-quad >>>> - const: marvell,armada-ap807 >>> Anyway, 6 compatibles is beyond useful amount. What are you expressing >>> here? >> I copied this part from the examples earlier in the file, such as: >> - description: Armada CN9132 SoC with two external CPs >> items: >> - const: marvell,cn9132 >> - const: marvell,cn9131 >> - const: marvell,cn9130 >> - const: marvell,armada-ap807-quad >> - const: marvell,armada-ap807 >>> Why is this even armada ap807? >> We noticed ap807 != ap806 (cn913x != 8040), >> because the thermal sensor coefficients converting >> raw values to celsius differed. > That's also not the best example.Might be correct but also looks > over-complicated. The point of board-level compatibles is to identify > machine and its common parts. It has little impact inside of kernel (at > least should be almost no users inside!) Indeed, the temperature coefficients are handled by the thermal device compatible string, not board-level. > , but there can be some users, > e.g. firmware or user-space. > > This claims that cn9132 is compatible with ap807, so you have exactly > the same base. The same base is not CPU! It's about the S in SoC, so > "System". I would think since the base is always a single chip combining 1x AP+CP, the "system" is marvell,cn9130. For Armada 8040, the system would be marvell,armada8040 by same logic (also combining 1x AP+CP, different version, not extensible). > Could firmware use marvell,armada-ap807 compatible to properly > detect type of system and treat all these boards as ap807? I have not looked into presence detection for CP's during initialization. U-Boot support without spaghetti is a future Me task. I suspect it is possible with asterisk *, because so far I have only seen configuration with at least 1 CP, never with 0. Presence of a boot-rom on each die e.g. supports this idea. sincerely Josua Mayer ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-26 19:26 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-26 19:26 UTC (permalink / raw) To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 26.03.24 um 07:41 schrieb Krzysztof Kozlowski: > On 25/03/2024 21:12, Josua Mayer wrote: >> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski: >>> On 22/03/2024 11:08, Josua Mayer wrote: >>>> Am 21.03.24 um 22:47 schrieb Josua Mayer: >>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on >>>>> CN9130 SoC. >>>>> The carrier boards are identical to the older Armada 388 based Clearfog >>>>> boards. For consistency the carrier part of compatible strings are >>>>> copied, including the established "-a1" suffix. >>>>> >>>>> Signed-off-by: Josua Mayer <josua@solid-run.com> >>>>> --- >>>>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >>>>> 1 file changed, 12 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>> index 16d2e132d3d1..36bdfd1bedd9 100644 >>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>> @@ -82,4 +82,16 @@ properties: >>>>> - const: marvell,armada-ap807-quad >>>>> - const: marvell,armada-ap807 >>>>> >>>>> + - description: >>>>> + SolidRun CN9130 clearfog family single-board computers >>>>> + items: >>>>> + - enum: >>>>> + - solidrun,clearfog-base-a1 >>>>> + - solidrun,clearfog-pro-a1 >>>>> + - const: solidrun,clearfog-a1 >>>>> + - const: solidrun,cn9130-sr-som >>>>> + - const: marvell,cn9130 >>>>> + - const: marvell,armada-ap807-quad >>>>> + - const: marvell,armada-ap807 >>>>> + >>>>> additionalProperties: true >>>> Before merging I would like some feedback about adding >>>> another product later, to ensure the compatibles above >>>> are adequate? In particular: >>>> - sequence of soc, cp, carrier compatibles >>>> - name of som compatible >>>> >>>> Draft for future bindings: >>>> - description: >>>> SolidRun CN9130 SoM based single-board computers >>>> with 1 external CP on the Carrier. >>>> items: >>>> - enum: >>>> - solidrun,cn9131-solidwan >>>> - const: marvell,cn9131 >>>> - const: solidrun,cn9130-sr-som >>> This does not look correct. cn9131 is not compatible with your som. >> This is partially my question. >> I considered changing the som to "cn913x-sr-som". >> >> The SoM itself is always 9130, it contains the base SoC >> with 1x AP and 1x CP in a single chip. >> 9131 and 9132 <happen> on the carrier boards. > No wildcards, but if the SoM name is 9130 then use 9130. > The problem is that you use cn9130 SoC as fallback. > >>>> - const: marvell,cn9130 >>> SoCs are compatible only in some cases, e.g. one is a subset of another >>> like stripped out of modem. Are you sure this is your case? >> This is more complex, CN9131 and CN9132 are not single SoCs. >> A "9132" is instantiated by connecting two southbridge chips >> via a Marvell defined bus, each providing additional IO >> such as network, i2c, gpio. >> >> Note that even the first, "9130", while a single chip, contains two dies: >> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c), >> and a "CP" (Communication Processor I assume) with lots of IO. >> This CP as far as I know today is identical to the southbridges >> mentioned above. > OK, but how does it affect compatibility between them? Which parts are > the same? Or how much is shared? 9130, 9131, 9132 belong together. 9130 is single chip including two dies: AP, CP. The CP is available as an individual chip, up to two can be connected to one 9130. What does this mean for compatibility? Which compatibility specifically? Is there a definition we can refer to? From software perspective we can always down-grade, i.e. run software only aware of the AP on 9130, 9131 or 9132. But we can't run software referencing the external CPs if they are not connected. >>>> - const: marvell,armada-ap807-quad >>>> - const: marvell,armada-ap807 >>> Anyway, 6 compatibles is beyond useful amount. What are you expressing >>> here? >> I copied this part from the examples earlier in the file, such as: >> - description: Armada CN9132 SoC with two external CPs >> items: >> - const: marvell,cn9132 >> - const: marvell,cn9131 >> - const: marvell,cn9130 >> - const: marvell,armada-ap807-quad >> - const: marvell,armada-ap807 >>> Why is this even armada ap807? >> We noticed ap807 != ap806 (cn913x != 8040), >> because the thermal sensor coefficients converting >> raw values to celsius differed. > That's also not the best example.Might be correct but also looks > over-complicated. The point of board-level compatibles is to identify > machine and its common parts. It has little impact inside of kernel (at > least should be almost no users inside!) Indeed, the temperature coefficients are handled by the thermal device compatible string, not board-level. > , but there can be some users, > e.g. firmware or user-space. > > This claims that cn9132 is compatible with ap807, so you have exactly > the same base. The same base is not CPU! It's about the S in SoC, so > "System". I would think since the base is always a single chip combining 1x AP+CP, the "system" is marvell,cn9130. For Armada 8040, the system would be marvell,armada8040 by same logic (also combining 1x AP+CP, different version, not extensible). > Could firmware use marvell,armada-ap807 compatible to properly > detect type of system and treat all these boards as ap807? I have not looked into presence detection for CP's during initialization. U-Boot support without spaghetti is a future Me task. I suspect it is possible with asterisk *, because so far I have only seen configuration with at least 1 CP, never with 0. Presence of a boot-rom on each die e.g. supports this idea. sincerely Josua Mayer _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-26 19:26 ` Josua Mayer @ 2024-03-27 10:19 ` Krzysztof Kozlowski -1 siblings, 0 replies; 48+ messages in thread From: Krzysztof Kozlowski @ 2024-03-27 10:19 UTC (permalink / raw) To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On 26/03/2024 20:26, Josua Mayer wrote: > Am 26.03.24 um 07:41 schrieb Krzysztof Kozlowski: >> On 25/03/2024 21:12, Josua Mayer wrote: >>> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski: >>>> On 22/03/2024 11:08, Josua Mayer wrote: >>>>> Am 21.03.24 um 22:47 schrieb Josua Mayer: >>>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on >>>>>> CN9130 SoC. >>>>>> The carrier boards are identical to the older Armada 388 based Clearfog >>>>>> boards. For consistency the carrier part of compatible strings are >>>>>> copied, including the established "-a1" suffix. >>>>>> >>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com> >>>>>> --- >>>>>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >>>>>> 1 file changed, 12 insertions(+) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>> index 16d2e132d3d1..36bdfd1bedd9 100644 >>>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>> @@ -82,4 +82,16 @@ properties: >>>>>> - const: marvell,armada-ap807-quad >>>>>> - const: marvell,armada-ap807 >>>>>> >>>>>> + - description: >>>>>> + SolidRun CN9130 clearfog family single-board computers >>>>>> + items: >>>>>> + - enum: >>>>>> + - solidrun,clearfog-base-a1 >>>>>> + - solidrun,clearfog-pro-a1 >>>>>> + - const: solidrun,clearfog-a1 >>>>>> + - const: solidrun,cn9130-sr-som >>>>>> + - const: marvell,cn9130 >>>>>> + - const: marvell,armada-ap807-quad >>>>>> + - const: marvell,armada-ap807 >>>>>> + >>>>>> additionalProperties: true >>>>> Before merging I would like some feedback about adding >>>>> another product later, to ensure the compatibles above >>>>> are adequate? In particular: >>>>> - sequence of soc, cp, carrier compatibles >>>>> - name of som compatible >>>>> >>>>> Draft for future bindings: >>>>> - description: >>>>> SolidRun CN9130 SoM based single-board computers >>>>> with 1 external CP on the Carrier. >>>>> items: >>>>> - enum: >>>>> - solidrun,cn9131-solidwan >>>>> - const: marvell,cn9131 >>>>> - const: solidrun,cn9130-sr-som >>>> This does not look correct. cn9131 is not compatible with your som. >>> This is partially my question. >>> I considered changing the som to "cn913x-sr-som". >>> >>> The SoM itself is always 9130, it contains the base SoC >>> with 1x AP and 1x CP in a single chip. >>> 9131 and 9132 <happen> on the carrier boards. >> No wildcards, but if the SoM name is 9130 then use 9130. >> The problem is that you use cn9130 SoC as fallback. >> >>>>> - const: marvell,cn9130 >>>> SoCs are compatible only in some cases, e.g. one is a subset of another >>>> like stripped out of modem. Are you sure this is your case? >>> This is more complex, CN9131 and CN9132 are not single SoCs. >>> A "9132" is instantiated by connecting two southbridge chips >>> via a Marvell defined bus, each providing additional IO >>> such as network, i2c, gpio. >>> >>> Note that even the first, "9130", while a single chip, contains two dies: >>> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c), >>> and a "CP" (Communication Processor I assume) with lots of IO. >>> This CP as far as I know today is identical to the southbridges >>> mentioned above. >> OK, but how does it affect compatibility between them? Which parts are >> the same? Or how much is shared? > 9130, 9131, 9132 belong together. I don't understand what it means. > 9130 is single chip including two dies: AP, CP. > The CP is available as an individual chip, > up to two can be connected to one 9130. And? How does it help me to decide? What is 9131 and 9132? > > What does this mean for compatibility? > Which compatibility specifically? > Is there a definition we can refer to? Devicetree spec. Let me answer with a question, because you neither answer mine nor provide detailed information. Is Cortex-A15 compatible with Cortex-A7 in the Devicetree? No. Now what does it mean to your case? I don't even understand what is your case. > > From software perspective we can always down-grade, > i.e. run software only aware of the AP on 9130, 9131 or 9132. > But we can't run software referencing the external CPs > if they are not connected. Same with Cortex A15 and A7, right? > >>>>> - const: marvell,armada-ap807-quad >>>>> - const: marvell,armada-ap807 >>>> Anyway, 6 compatibles is beyond useful amount. What are you expressing >>>> here? >>> I copied this part from the examples earlier in the file, such as: >>> - description: Armada CN9132 SoC with two external CPs >>> items: >>> - const: marvell,cn9132 >>> - const: marvell,cn9131 >>> - const: marvell,cn9130 >>> - const: marvell,armada-ap807-quad >>> - const: marvell,armada-ap807 >>>> Why is this even armada ap807? >>> We noticed ap807 != ap806 (cn913x != 8040), >>> because the thermal sensor coefficients converting >>> raw values to celsius differed. >> That's also not the best example.Might be correct but also looks >> over-complicated. The point of board-level compatibles is to identify >> machine and its common parts. It has little impact inside of kernel (at >> least should be almost no users inside!) > Indeed, the temperature coefficients are handled by the thermal device > compatible string, not board-level. >> , but there can be some users, >> e.g. firmware or user-space. >> >> This claims that cn9132 is compatible with ap807, so you have exactly >> the same base. The same base is not CPU! It's about the S in SoC, so >> "System". > I would think since the base is always a single chip combining 1x AP+CP, > the "system" is marvell,cn9130. > For Armada 8040, the system would be marvell,armada8040 by same > logic (also combining 1x AP+CP, different version, not extensible). >> Could firmware use marvell,armada-ap807 compatible to properly >> detect type of system and treat all these boards as ap807? > I have not looked into presence detection for CP's during initialization. > U-Boot support without spaghetti is a future Me task. ??? > I suspect it is possible with asterisk *, because so far I have only seen > configuration with at least 1 CP, never with 0. > Presence of a boot-rom on each die e.g. supports this idea. I still don't understand. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-27 10:19 ` Krzysztof Kozlowski 0 siblings, 0 replies; 48+ messages in thread From: Krzysztof Kozlowski @ 2024-03-27 10:19 UTC (permalink / raw) To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On 26/03/2024 20:26, Josua Mayer wrote: > Am 26.03.24 um 07:41 schrieb Krzysztof Kozlowski: >> On 25/03/2024 21:12, Josua Mayer wrote: >>> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski: >>>> On 22/03/2024 11:08, Josua Mayer wrote: >>>>> Am 21.03.24 um 22:47 schrieb Josua Mayer: >>>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on >>>>>> CN9130 SoC. >>>>>> The carrier boards are identical to the older Armada 388 based Clearfog >>>>>> boards. For consistency the carrier part of compatible strings are >>>>>> copied, including the established "-a1" suffix. >>>>>> >>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com> >>>>>> --- >>>>>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >>>>>> 1 file changed, 12 insertions(+) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>> index 16d2e132d3d1..36bdfd1bedd9 100644 >>>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>> @@ -82,4 +82,16 @@ properties: >>>>>> - const: marvell,armada-ap807-quad >>>>>> - const: marvell,armada-ap807 >>>>>> >>>>>> + - description: >>>>>> + SolidRun CN9130 clearfog family single-board computers >>>>>> + items: >>>>>> + - enum: >>>>>> + - solidrun,clearfog-base-a1 >>>>>> + - solidrun,clearfog-pro-a1 >>>>>> + - const: solidrun,clearfog-a1 >>>>>> + - const: solidrun,cn9130-sr-som >>>>>> + - const: marvell,cn9130 >>>>>> + - const: marvell,armada-ap807-quad >>>>>> + - const: marvell,armada-ap807 >>>>>> + >>>>>> additionalProperties: true >>>>> Before merging I would like some feedback about adding >>>>> another product later, to ensure the compatibles above >>>>> are adequate? In particular: >>>>> - sequence of soc, cp, carrier compatibles >>>>> - name of som compatible >>>>> >>>>> Draft for future bindings: >>>>> - description: >>>>> SolidRun CN9130 SoM based single-board computers >>>>> with 1 external CP on the Carrier. >>>>> items: >>>>> - enum: >>>>> - solidrun,cn9131-solidwan >>>>> - const: marvell,cn9131 >>>>> - const: solidrun,cn9130-sr-som >>>> This does not look correct. cn9131 is not compatible with your som. >>> This is partially my question. >>> I considered changing the som to "cn913x-sr-som". >>> >>> The SoM itself is always 9130, it contains the base SoC >>> with 1x AP and 1x CP in a single chip. >>> 9131 and 9132 <happen> on the carrier boards. >> No wildcards, but if the SoM name is 9130 then use 9130. >> The problem is that you use cn9130 SoC as fallback. >> >>>>> - const: marvell,cn9130 >>>> SoCs are compatible only in some cases, e.g. one is a subset of another >>>> like stripped out of modem. Are you sure this is your case? >>> This is more complex, CN9131 and CN9132 are not single SoCs. >>> A "9132" is instantiated by connecting two southbridge chips >>> via a Marvell defined bus, each providing additional IO >>> such as network, i2c, gpio. >>> >>> Note that even the first, "9130", while a single chip, contains two dies: >>> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c), >>> and a "CP" (Communication Processor I assume) with lots of IO. >>> This CP as far as I know today is identical to the southbridges >>> mentioned above. >> OK, but how does it affect compatibility between them? Which parts are >> the same? Or how much is shared? > 9130, 9131, 9132 belong together. I don't understand what it means. > 9130 is single chip including two dies: AP, CP. > The CP is available as an individual chip, > up to two can be connected to one 9130. And? How does it help me to decide? What is 9131 and 9132? > > What does this mean for compatibility? > Which compatibility specifically? > Is there a definition we can refer to? Devicetree spec. Let me answer with a question, because you neither answer mine nor provide detailed information. Is Cortex-A15 compatible with Cortex-A7 in the Devicetree? No. Now what does it mean to your case? I don't even understand what is your case. > > From software perspective we can always down-grade, > i.e. run software only aware of the AP on 9130, 9131 or 9132. > But we can't run software referencing the external CPs > if they are not connected. Same with Cortex A15 and A7, right? > >>>>> - const: marvell,armada-ap807-quad >>>>> - const: marvell,armada-ap807 >>>> Anyway, 6 compatibles is beyond useful amount. What are you expressing >>>> here? >>> I copied this part from the examples earlier in the file, such as: >>> - description: Armada CN9132 SoC with two external CPs >>> items: >>> - const: marvell,cn9132 >>> - const: marvell,cn9131 >>> - const: marvell,cn9130 >>> - const: marvell,armada-ap807-quad >>> - const: marvell,armada-ap807 >>>> Why is this even armada ap807? >>> We noticed ap807 != ap806 (cn913x != 8040), >>> because the thermal sensor coefficients converting >>> raw values to celsius differed. >> That's also not the best example.Might be correct but also looks >> over-complicated. The point of board-level compatibles is to identify >> machine and its common parts. It has little impact inside of kernel (at >> least should be almost no users inside!) > Indeed, the temperature coefficients are handled by the thermal device > compatible string, not board-level. >> , but there can be some users, >> e.g. firmware or user-space. >> >> This claims that cn9132 is compatible with ap807, so you have exactly >> the same base. The same base is not CPU! It's about the S in SoC, so >> "System". > I would think since the base is always a single chip combining 1x AP+CP, > the "system" is marvell,cn9130. > For Armada 8040, the system would be marvell,armada8040 by same > logic (also combining 1x AP+CP, different version, not extensible). >> Could firmware use marvell,armada-ap807 compatible to properly >> detect type of system and treat all these boards as ap807? > I have not looked into presence detection for CP's during initialization. > U-Boot support without spaghetti is a future Me task. ??? > I suspect it is possible with asterisk *, because so far I have only seen > configuration with at least 1 CP, never with 0. > Presence of a boot-rom on each die e.g. supports this idea. I still don't understand. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-27 10:19 ` Krzysztof Kozlowski @ 2024-03-27 10:55 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-27 10:55 UTC (permalink / raw) To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 27.03.24 um 11:19 schrieb Krzysztof Kozlowski: > On 26/03/2024 20:26, Josua Mayer wrote: >> Am 26.03.24 um 07:41 schrieb Krzysztof Kozlowski: >>> On 25/03/2024 21:12, Josua Mayer wrote: >>>> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski: >>>>> On 22/03/2024 11:08, Josua Mayer wrote: >>>>>> Am 21.03.24 um 22:47 schrieb Josua Mayer: >>>>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on >>>>>>> CN9130 SoC. >>>>>>> The carrier boards are identical to the older Armada 388 based Clearfog >>>>>>> boards. For consistency the carrier part of compatible strings are >>>>>>> copied, including the established "-a1" suffix. >>>>>>> >>>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com> >>>>>>> --- >>>>>>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >>>>>>> 1 file changed, 12 insertions(+) >>>>>>> >>>>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>>> index 16d2e132d3d1..36bdfd1bedd9 100644 >>>>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>>> @@ -82,4 +82,16 @@ properties: >>>>>>> - const: marvell,armada-ap807-quad >>>>>>> - const: marvell,armada-ap807 >>>>>>> >>>>>>> + - description: >>>>>>> + SolidRun CN9130 clearfog family single-board computers >>>>>>> + items: >>>>>>> + - enum: >>>>>>> + - solidrun,clearfog-base-a1 >>>>>>> + - solidrun,clearfog-pro-a1 >>>>>>> + - const: solidrun,clearfog-a1 >>>>>>> + - const: solidrun,cn9130-sr-som >>>>>>> + - const: marvell,cn9130 >>>>>>> + - const: marvell,armada-ap807-quad >>>>>>> + - const: marvell,armada-ap807 >>>>>>> + >>>>>>> additionalProperties: true >>>>>> Before merging I would like some feedback about adding >>>>>> another product later, to ensure the compatibles above >>>>>> are adequate? In particular: >>>>>> - sequence of soc, cp, carrier compatibles >>>>>> - name of som compatible >>>>>> >>>>>> Draft for future bindings: >>>>>> - description: >>>>>> SolidRun CN9130 SoM based single-board computers >>>>>> with 1 external CP on the Carrier. >>>>>> items: >>>>>> - enum: >>>>>> - solidrun,cn9131-solidwan >>>>>> - const: marvell,cn9131 >>>>>> - const: solidrun,cn9130-sr-som >>>>> This does not look correct. cn9131 is not compatible with your som. >>>> This is partially my question. >>>> I considered changing the som to "cn913x-sr-som". >>>> >>>> The SoM itself is always 9130, it contains the base SoC >>>> with 1x AP and 1x CP in a single chip. >>>> 9131 and 9132 <happen> on the carrier boards. >>> No wildcards, but if the SoM name is 9130 then use 9130. >>> The problem is that you use cn9130 SoC as fallback. >>> >>>>>> - const: marvell,cn9130 >>>>> SoCs are compatible only in some cases, e.g. one is a subset of another >>>>> like stripped out of modem. Are you sure this is your case? >>>> This is more complex, CN9131 and CN9132 are not single SoCs. >>>> A "9132" is instantiated by connecting two southbridge chips >>>> via a Marvell defined bus, each providing additional IO >>>> such as network, i2c, gpio. >>>> >>>> Note that even the first, "9130", while a single chip, contains two dies: >>>> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c), >>>> and a "CP" (Communication Processor I assume) with lots of IO. >>>> This CP as far as I know today is identical to the southbridges >>>> mentioned above. >>> OK, but how does it affect compatibility between them? Which parts are >>> the same? Or how much is shared? >> 9130, 9131, 9132 belong together. > I don't understand what it means. > >> 9130 is single chip including two dies: AP, CP. >> The CP is available as an individual chip, >> up to two can be connected to one 9130. > And? How does it help me to decide? What is 9131 and 9132? > >> What does this mean for compatibility? >> Which compatibility specifically? >> Is there a definition we can refer to? > Devicetree spec. Let me fetch it for future reference: https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.4 > The compatible property value consists of one or more strings that define the specific programming model for > the device. This list of strings should be used by a client program for device driver selection. The property > value consists of a concatenated list of null terminated strings, from most specific to most general. They allow > a device to express its compatibility with a family of similar devices, potentially allowing a single device driver > to match against several devices. > > The recommended format is "manufacturer,model", where manufacturer is a string describing the name > of the manufacturer (such as a stock ticker symbol), and model specifies the model number. > > The compatible string should consist only of lowercase letters, digits and dashes, and should start with a letter. > A single comma is typically only used following a vendor prefix. Underscores should not be used. > > Example: > compatible = "fsl,mpc8641", "ns16550"; > In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a > driver was not found, it would then try to locate a driver that supported the more general ns16550 device type. I think I understand this for individual components, but with a SoM or complete product I get confused. Can I understand a SoM or product as a composite device, such as a usb to uart + i2c + gpio + spi adapter? > Let me answer with a question, because you neither answer mine nor > provide detailed information. > > Is Cortex-A15 compatible with Cortex-A7 in the Devicetree? No. Curious! Actually I don't fully understand why that would be. Based on the definition above, I would agree that neither cortex-a7 nor cortex-a17 are specializations of each other. They just happen to both support armv7-a instruction set. > Now what > does it mean to your case? > > I don't even understand what is your case. I see :( Yes there is a disconnect *somewhere*. I shall try again: Marvell is selling two chips: 1. CN9130, High-Performance Multi-Core CPU, System on Chip (can be used alone) 2. 88F8215, SouthBridge Communication Processor, System on Chip (only usable in combination with a CN9130) Now, in terms of compatible string, what happens when a board has multiples of these? > What is 9131 and 9132? I have no idea who came up with 9131 and 9132. But explanation is given by Grzegorz Jaszczyk <jaz@semihalf.com> when he submitted cn9131-db.dts (Marvell evaluation board): Extend the support of the CN9130 by adding an external CP115. The last number indicates how many external CP115 are used. > > >> From software perspective we can always down-grade, >> i.e. run software only aware of the AP on 9130, 9131 or 9132. >> But we can't run software referencing the external CPs >> if they are not connected. > Same with Cortex A15 and A7, right? Right. > > >>>>>> - const: marvell,armada-ap807-quad >>>>>> - const: marvell,armada-ap807 >>>>> Anyway, 6 compatibles is beyond useful amount. What are you expressing >>>>> here? >>>> I copied this part from the examples earlier in the file, such as: >>>> - description: Armada CN9132 SoC with two external CPs >>>> items: >>>> - const: marvell,cn9132 >>>> - const: marvell,cn9131 >>>> - const: marvell,cn9130 >>>> - const: marvell,armada-ap807-quad >>>> - const: marvell,armada-ap807 >>>>> Why is this even armada ap807? >>>> We noticed ap807 != ap806 (cn913x != 8040), >>>> because the thermal sensor coefficients converting >>>> raw values to celsius differed. >>> That's also not the best example.Might be correct but also looks >>> over-complicated. The point of board-level compatibles is to identify >>> machine and its common parts. It has little impact inside of kernel (at >>> least should be almost no users inside!) >> Indeed, the temperature coefficients are handled by the thermal device >> compatible string, not board-level. >>> , but there can be some users, >>> e.g. firmware or user-space. >>> >>> This claims that cn9132 is compatible with ap807, so you have exactly >>> the same base. The same base is not CPU! It's about the S in SoC, so >>> "System". >> I would think since the base is always a single chip combining 1x AP+CP, >> the "system" is marvell,cn9130. >> For Armada 8040, the system would be marvell,armada8040 by same >> logic (also combining 1x AP+CP, different version, not extensible). >>> Could firmware use marvell,armada-ap807 compatible to properly >>> detect type of system and treat all these boards as ap807? >> I have not looked into presence detection for CP's during initialization. >> U-Boot support without spaghetti is a future Me task. > ??? > >> I suspect it is possible with asterisk *, because so far I have only seen >> configuration with at least 1 CP, never with 0. >> Presence of a boot-rom on each die e.g. supports this idea. > I still don't understand. > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-27 10:55 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-27 10:55 UTC (permalink / raw) To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 27.03.24 um 11:19 schrieb Krzysztof Kozlowski: > On 26/03/2024 20:26, Josua Mayer wrote: >> Am 26.03.24 um 07:41 schrieb Krzysztof Kozlowski: >>> On 25/03/2024 21:12, Josua Mayer wrote: >>>> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski: >>>>> On 22/03/2024 11:08, Josua Mayer wrote: >>>>>> Am 21.03.24 um 22:47 schrieb Josua Mayer: >>>>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on >>>>>>> CN9130 SoC. >>>>>>> The carrier boards are identical to the older Armada 388 based Clearfog >>>>>>> boards. For consistency the carrier part of compatible strings are >>>>>>> copied, including the established "-a1" suffix. >>>>>>> >>>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com> >>>>>>> --- >>>>>>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ >>>>>>> 1 file changed, 12 insertions(+) >>>>>>> >>>>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>>> index 16d2e132d3d1..36bdfd1bedd9 100644 >>>>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >>>>>>> @@ -82,4 +82,16 @@ properties: >>>>>>> - const: marvell,armada-ap807-quad >>>>>>> - const: marvell,armada-ap807 >>>>>>> >>>>>>> + - description: >>>>>>> + SolidRun CN9130 clearfog family single-board computers >>>>>>> + items: >>>>>>> + - enum: >>>>>>> + - solidrun,clearfog-base-a1 >>>>>>> + - solidrun,clearfog-pro-a1 >>>>>>> + - const: solidrun,clearfog-a1 >>>>>>> + - const: solidrun,cn9130-sr-som >>>>>>> + - const: marvell,cn9130 >>>>>>> + - const: marvell,armada-ap807-quad >>>>>>> + - const: marvell,armada-ap807 >>>>>>> + >>>>>>> additionalProperties: true >>>>>> Before merging I would like some feedback about adding >>>>>> another product later, to ensure the compatibles above >>>>>> are adequate? In particular: >>>>>> - sequence of soc, cp, carrier compatibles >>>>>> - name of som compatible >>>>>> >>>>>> Draft for future bindings: >>>>>> - description: >>>>>> SolidRun CN9130 SoM based single-board computers >>>>>> with 1 external CP on the Carrier. >>>>>> items: >>>>>> - enum: >>>>>> - solidrun,cn9131-solidwan >>>>>> - const: marvell,cn9131 >>>>>> - const: solidrun,cn9130-sr-som >>>>> This does not look correct. cn9131 is not compatible with your som. >>>> This is partially my question. >>>> I considered changing the som to "cn913x-sr-som". >>>> >>>> The SoM itself is always 9130, it contains the base SoC >>>> with 1x AP and 1x CP in a single chip. >>>> 9131 and 9132 <happen> on the carrier boards. >>> No wildcards, but if the SoM name is 9130 then use 9130. >>> The problem is that you use cn9130 SoC as fallback. >>> >>>>>> - const: marvell,cn9130 >>>>> SoCs are compatible only in some cases, e.g. one is a subset of another >>>>> like stripped out of modem. Are you sure this is your case? >>>> This is more complex, CN9131 and CN9132 are not single SoCs. >>>> A "9132" is instantiated by connecting two southbridge chips >>>> via a Marvell defined bus, each providing additional IO >>>> such as network, i2c, gpio. >>>> >>>> Note that even the first, "9130", while a single chip, contains two dies: >>>> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c), >>>> and a "CP" (Communication Processor I assume) with lots of IO. >>>> This CP as far as I know today is identical to the southbridges >>>> mentioned above. >>> OK, but how does it affect compatibility between them? Which parts are >>> the same? Or how much is shared? >> 9130, 9131, 9132 belong together. > I don't understand what it means. > >> 9130 is single chip including two dies: AP, CP. >> The CP is available as an individual chip, >> up to two can be connected to one 9130. > And? How does it help me to decide? What is 9131 and 9132? > >> What does this mean for compatibility? >> Which compatibility specifically? >> Is there a definition we can refer to? > Devicetree spec. Let me fetch it for future reference: https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.4 > The compatible property value consists of one or more strings that define the specific programming model for > the device. This list of strings should be used by a client program for device driver selection. The property > value consists of a concatenated list of null terminated strings, from most specific to most general. They allow > a device to express its compatibility with a family of similar devices, potentially allowing a single device driver > to match against several devices. > > The recommended format is "manufacturer,model", where manufacturer is a string describing the name > of the manufacturer (such as a stock ticker symbol), and model specifies the model number. > > The compatible string should consist only of lowercase letters, digits and dashes, and should start with a letter. > A single comma is typically only used following a vendor prefix. Underscores should not be used. > > Example: > compatible = "fsl,mpc8641", "ns16550"; > In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a > driver was not found, it would then try to locate a driver that supported the more general ns16550 device type. I think I understand this for individual components, but with a SoM or complete product I get confused. Can I understand a SoM or product as a composite device, such as a usb to uart + i2c + gpio + spi adapter? > Let me answer with a question, because you neither answer mine nor > provide detailed information. > > Is Cortex-A15 compatible with Cortex-A7 in the Devicetree? No. Curious! Actually I don't fully understand why that would be. Based on the definition above, I would agree that neither cortex-a7 nor cortex-a17 are specializations of each other. They just happen to both support armv7-a instruction set. > Now what > does it mean to your case? > > I don't even understand what is your case. I see :( Yes there is a disconnect *somewhere*. I shall try again: Marvell is selling two chips: 1. CN9130, High-Performance Multi-Core CPU, System on Chip (can be used alone) 2. 88F8215, SouthBridge Communication Processor, System on Chip (only usable in combination with a CN9130) Now, in terms of compatible string, what happens when a board has multiples of these? > What is 9131 and 9132? I have no idea who came up with 9131 and 9132. But explanation is given by Grzegorz Jaszczyk <jaz@semihalf.com> when he submitted cn9131-db.dts (Marvell evaluation board): Extend the support of the CN9130 by adding an external CP115. The last number indicates how many external CP115 are used. > > >> From software perspective we can always down-grade, >> i.e. run software only aware of the AP on 9130, 9131 or 9132. >> But we can't run software referencing the external CPs >> if they are not connected. > Same with Cortex A15 and A7, right? Right. > > >>>>>> - const: marvell,armada-ap807-quad >>>>>> - const: marvell,armada-ap807 >>>>> Anyway, 6 compatibles is beyond useful amount. What are you expressing >>>>> here? >>>> I copied this part from the examples earlier in the file, such as: >>>> - description: Armada CN9132 SoC with two external CPs >>>> items: >>>> - const: marvell,cn9132 >>>> - const: marvell,cn9131 >>>> - const: marvell,cn9130 >>>> - const: marvell,armada-ap807-quad >>>> - const: marvell,armada-ap807 >>>>> Why is this even armada ap807? >>>> We noticed ap807 != ap806 (cn913x != 8040), >>>> because the thermal sensor coefficients converting >>>> raw values to celsius differed. >>> That's also not the best example.Might be correct but also looks >>> over-complicated. The point of board-level compatibles is to identify >>> machine and its common parts. It has little impact inside of kernel (at >>> least should be almost no users inside!) >> Indeed, the temperature coefficients are handled by the thermal device >> compatible string, not board-level. >>> , but there can be some users, >>> e.g. firmware or user-space. >>> >>> This claims that cn9132 is compatible with ap807, so you have exactly >>> the same base. The same base is not CPU! It's about the S in SoC, so >>> "System". >> I would think since the base is always a single chip combining 1x AP+CP, >> the "system" is marvell,cn9130. >> For Armada 8040, the system would be marvell,armada8040 by same >> logic (also combining 1x AP+CP, different version, not extensible). >>> Could firmware use marvell,armada-ap807 compatible to properly >>> detect type of system and treat all these boards as ap807? >> I have not looked into presence detection for CP's during initialization. >> U-Boot support without spaghetti is a future Me task. > ??? > >> I suspect it is possible with asterisk *, because so far I have only seen >> configuration with at least 1 CP, never with 0. >> Presence of a boot-rom on each die e.g. supports this idea. > I still don't understand. > > Best regards, > Krzysztof > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-27 10:55 ` Josua Mayer @ 2024-03-28 9:14 ` Krzysztof Kozlowski -1 siblings, 0 replies; 48+ messages in thread From: Krzysztof Kozlowski @ 2024-03-28 9:14 UTC (permalink / raw) To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On 27/03/2024 11:55, Josua Mayer wrote: >> >> I don't even understand what is your case. > I see :( > Yes there is a disconnect *somewhere*. > Your way of quoting, including removing blank lines, weird wrapping, does not make it easy to answer anything here. Use decent email client which solves all these problems. > I shall try again: > Marvell is selling two chips: > 1. CN9130, High-Performance Multi-Core CPU, System on Chip > (can be used alone) So this is the main SoC? > 2. 88F8215, SouthBridge Communication Processor, System on Chip > (only usable in combination with a CN9130) > > Now, in terms of compatible string, what happens when a board > has multiples of these? Multiple of CN9130? 2x CN9130? Nothing happens, does not really matter. Anyway the compatible is just to uniquely identify the device for users, not represent some programming model, because there is no programming model of a board. > >> What is 9131 and 9132? > I have no idea who came up with 9131 and 9132. > But explanation is given by Grzegorz Jaszczyk <jaz@semihalf.com> > when he submitted cn9131-db.dts (Marvell evaluation board): > > Extend the support of the CN9130 by adding an external CP115. > The last number indicates how many external CP115 are used. You use the compatibles in your patchset, so you should know, not me. I have zero knowledge, also actually almost zero interest, in learning your particular platform. I tried to fixup some bindings and maintainers for Marvell: failed with not really helpful comments. Therefore I don't care anymore about Marvell. You or your platform maintainers should know what is this about and come with explanation to the community. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-28 9:14 ` Krzysztof Kozlowski 0 siblings, 0 replies; 48+ messages in thread From: Krzysztof Kozlowski @ 2024-03-28 9:14 UTC (permalink / raw) To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On 27/03/2024 11:55, Josua Mayer wrote: >> >> I don't even understand what is your case. > I see :( > Yes there is a disconnect *somewhere*. > Your way of quoting, including removing blank lines, weird wrapping, does not make it easy to answer anything here. Use decent email client which solves all these problems. > I shall try again: > Marvell is selling two chips: > 1. CN9130, High-Performance Multi-Core CPU, System on Chip > (can be used alone) So this is the main SoC? > 2. 88F8215, SouthBridge Communication Processor, System on Chip > (only usable in combination with a CN9130) > > Now, in terms of compatible string, what happens when a board > has multiples of these? Multiple of CN9130? 2x CN9130? Nothing happens, does not really matter. Anyway the compatible is just to uniquely identify the device for users, not represent some programming model, because there is no programming model of a board. > >> What is 9131 and 9132? > I have no idea who came up with 9131 and 9132. > But explanation is given by Grzegorz Jaszczyk <jaz@semihalf.com> > when he submitted cn9131-db.dts (Marvell evaluation board): > > Extend the support of the CN9130 by adding an external CP115. > The last number indicates how many external CP115 are used. You use the compatibles in your patchset, so you should know, not me. I have zero knowledge, also actually almost zero interest, in learning your particular platform. I tried to fixup some bindings and maintainers for Marvell: failed with not really helpful comments. Therefore I don't care anymore about Marvell. You or your platform maintainers should know what is this about and come with explanation to the community. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-28 9:14 ` Krzysztof Kozlowski @ 2024-03-28 9:33 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-28 9:33 UTC (permalink / raw) To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Hi Krzysztof, Thank you for all the comments so far! Am 28.03.24 um 10:14 schrieb Krzysztof Kozlowski: > On 27/03/2024 11:55, Josua Mayer wrote: > >>> I don't even understand what is your case. >> I see :( >> Yes there is a disconnect *somewhere*. >> > Your way of quoting, including removing blank lines, weird wrapping, > does not make it easy to answer anything here. Use decent email client > which solves all these problems. > >> I shall try again: >> Marvell is selling two chips: >> 1. CN9130, High-Performance Multi-Core CPU, System on Chip >> (can be used alone) > So this is the main SoC? Correct. > >> 2. 88F8215, SouthBridge Communication Processor, System on Chip >> (only usable in combination with a CN9130) >> >> Now, in terms of compatible string, what happens when a board >> has multiples of these? > Multiple of CN9130? 2x CN9130? this specifically is an academic question, the main point is multiple southbridges to one CN9130. > Nothing happens, does not really matter. > Anyway the compatible is just to uniquely identify the device for users, > not represent some programming model, because there is no programming > model of a board. > >>> What is 9131 and 9132? >> I have no idea who came up with 9131 and 9132. >> But explanation is given by Grzegorz Jaszczyk <jaz@semihalf.com> >> when he submitted cn9131-db.dts (Marvell evaluation board): >> >> Extend the support of the CN9130 by adding an external CP115. >> The last number indicates how many external CP115 are used. > You use the compatibles in your patchset, so you should know, not me.I > have zero knowledge, also actually almost zero interest, in learning > your particular platform. Fair enough. > I tried to fixup some bindings and maintainers > for Marvell: failed with not really helpful comments. Therefore I don't > care anymore about Marvell. > > You <cut> should know what is this about and come > with explanation to the community. If I was to come up with something new, without looking at existing Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml I would describe the hardware like this: SolidRun "CN9131" SolidWAN board is comptible with: - solidrun,cn9131-solidwan: name of the carrier board, and name of the complete product includes one southbridge chip, but I don't need to mention it? - solidrun,cn9130-sr-som: just the som, including 1x CN9130 SoC - marvell,cn9130: this is the SoC, internally combining AP+CP AP *could* be mentioned, but I don't see a reason > You<cut>r platform maintainers should know what is this about and come > with explanation to the community. Is there a way forward? Would it be worth challenging the existing bindings by proposing (RFC) specific changes in line with what I described above? sincerely Josua Mayer ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-28 9:33 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-28 9:33 UTC (permalink / raw) To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Hi Krzysztof, Thank you for all the comments so far! Am 28.03.24 um 10:14 schrieb Krzysztof Kozlowski: > On 27/03/2024 11:55, Josua Mayer wrote: > >>> I don't even understand what is your case. >> I see :( >> Yes there is a disconnect *somewhere*. >> > Your way of quoting, including removing blank lines, weird wrapping, > does not make it easy to answer anything here. Use decent email client > which solves all these problems. > >> I shall try again: >> Marvell is selling two chips: >> 1. CN9130, High-Performance Multi-Core CPU, System on Chip >> (can be used alone) > So this is the main SoC? Correct. > >> 2. 88F8215, SouthBridge Communication Processor, System on Chip >> (only usable in combination with a CN9130) >> >> Now, in terms of compatible string, what happens when a board >> has multiples of these? > Multiple of CN9130? 2x CN9130? this specifically is an academic question, the main point is multiple southbridges to one CN9130. > Nothing happens, does not really matter. > Anyway the compatible is just to uniquely identify the device for users, > not represent some programming model, because there is no programming > model of a board. > >>> What is 9131 and 9132? >> I have no idea who came up with 9131 and 9132. >> But explanation is given by Grzegorz Jaszczyk <jaz@semihalf.com> >> when he submitted cn9131-db.dts (Marvell evaluation board): >> >> Extend the support of the CN9130 by adding an external CP115. >> The last number indicates how many external CP115 are used. > You use the compatibles in your patchset, so you should know, not me.I > have zero knowledge, also actually almost zero interest, in learning > your particular platform. Fair enough. > I tried to fixup some bindings and maintainers > for Marvell: failed with not really helpful comments. Therefore I don't > care anymore about Marvell. > > You <cut> should know what is this about and come > with explanation to the community. If I was to come up with something new, without looking at existing Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml I would describe the hardware like this: SolidRun "CN9131" SolidWAN board is comptible with: - solidrun,cn9131-solidwan: name of the carrier board, and name of the complete product includes one southbridge chip, but I don't need to mention it? - solidrun,cn9130-sr-som: just the som, including 1x CN9130 SoC - marvell,cn9130: this is the SoC, internally combining AP+CP AP *could* be mentioned, but I don't see a reason > You<cut>r platform maintainers should know what is this about and come > with explanation to the community. Is there a way forward? Would it be worth challenging the existing bindings by proposing (RFC) specific changes in line with what I described above? sincerely Josua Mayer _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-28 9:33 ` Josua Mayer @ 2024-03-28 9:41 ` Krzysztof Kozlowski -1 siblings, 0 replies; 48+ messages in thread From: Krzysztof Kozlowski @ 2024-03-28 9:41 UTC (permalink / raw) To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On 28/03/2024 10:33, Josua Mayer wrote: >> >>> 2. 88F8215, SouthBridge Communication Processor, System on Chip >>> (only usable in combination with a CN9130) >>> >>> Now, in terms of compatible string, what happens when a board >>> has multiples of these? >> Multiple of CN9130? 2x CN9130? > this specifically is an academic question, > the main point is multiple southbridges to one CN9130. I did not know to what you refer. >> >> You <cut> should know what is this about and come >> with explanation to the community. > If I was to come up with something new, without looking at existing > Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > I would describe the hardware like this: > > SolidRun "CN9131" SolidWAN board is comptible with: > - solidrun,cn9131-solidwan: > name of the carrier board, and name of the complete product > includes one southbridge chip, but I don't need to mention it? > - solidrun,cn9130-sr-som: > just the som, including 1x CN9130 SoC > - marvell,cn9130: > this is the SoC, internally combining AP+CP > AP *could* be mentioned, but I don't see a reason With an explanation in commit msg about not using other compatible fallbacks, this looks good to me. > >> You<cut>r platform maintainers should know what is this about and come >> with explanation to the community. > Is there a way forward? > Would it be worth challenging the existing bindings by proposing (RFC) > specific changes in line with what I described above? It all depends on "what" and "why" you want to do. I don't know. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-28 9:41 ` Krzysztof Kozlowski 0 siblings, 0 replies; 48+ messages in thread From: Krzysztof Kozlowski @ 2024-03-28 9:41 UTC (permalink / raw) To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On 28/03/2024 10:33, Josua Mayer wrote: >> >>> 2. 88F8215, SouthBridge Communication Processor, System on Chip >>> (only usable in combination with a CN9130) >>> >>> Now, in terms of compatible string, what happens when a board >>> has multiples of these? >> Multiple of CN9130? 2x CN9130? > this specifically is an academic question, > the main point is multiple southbridges to one CN9130. I did not know to what you refer. >> >> You <cut> should know what is this about and come >> with explanation to the community. > If I was to come up with something new, without looking at existing > Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > I would describe the hardware like this: > > SolidRun "CN9131" SolidWAN board is comptible with: > - solidrun,cn9131-solidwan: > name of the carrier board, and name of the complete product > includes one southbridge chip, but I don't need to mention it? > - solidrun,cn9130-sr-som: > just the som, including 1x CN9130 SoC > - marvell,cn9130: > this is the SoC, internally combining AP+CP > AP *could* be mentioned, but I don't see a reason With an explanation in commit msg about not using other compatible fallbacks, this looks good to me. > >> You<cut>r platform maintainers should know what is this about and come >> with explanation to the community. > Is there a way forward? > Would it be worth challenging the existing bindings by proposing (RFC) > specific changes in line with what I described above? It all depends on "what" and "why" you want to do. I don't know. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-28 9:41 ` Krzysztof Kozlowski @ 2024-03-28 9:46 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-28 9:46 UTC (permalink / raw) To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 28.03.24 um 10:41 schrieb Krzysztof Kozlowski: > On 28/03/2024 10:33, Josua Mayer wrote: >>>> 2. 88F8215, SouthBridge Communication Processor, System on Chip >>>> (only usable in combination with a CN9130) >>>> >>>> Now, in terms of compatible string, what happens when a board >>>> has multiples of these? >>> Multiple of CN9130? 2x CN9130? >> this specifically is an academic question, >> the main point is multiple southbridges to one CN9130. > I did not know to what you refer. > >>> You <cut> should know what is this about and come >>> with explanation to the community. >> If I was to come up with something new, without looking at existing >> Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >> I would describe the hardware like this: >> >> SolidRun "CN9131" SolidWAN board is comptible with: >> - solidrun,cn9131-solidwan: >> name of the carrier board, and name of the complete product >> includes one southbridge chip, but I don't need to mention it? >> - solidrun,cn9130-sr-som: >> just the som, including 1x CN9130 SoC >> - marvell,cn9130: >> this is the SoC, internally combining AP+CP >> AP *could* be mentioned, but I don't see a reason > With an explanation in commit msg about not using other compatible > fallbacks, this looks good to me. Great. So perhaps my next step will be a v2 with explanations. > >>> You<cut>r platform maintainers should know what is this about and come >>> with explanation to the community. >> Is there a way forward? >> Would it be worth challenging the existing bindings by proposing (RFC) >> specific changes in line with what I described above? > It all depends on "what" and "why" you want to do. I don't know. First priority is supporting the solidrun boards based on cn9130 soc, which requires getting the bindings right (at least for these boards). Changing the other bindings would only satisfy my desire for order, but could get attention from other contributors to these platforms. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-28 9:46 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-28 9:46 UTC (permalink / raw) To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 28.03.24 um 10:41 schrieb Krzysztof Kozlowski: > On 28/03/2024 10:33, Josua Mayer wrote: >>>> 2. 88F8215, SouthBridge Communication Processor, System on Chip >>>> (only usable in combination with a CN9130) >>>> >>>> Now, in terms of compatible string, what happens when a board >>>> has multiples of these? >>> Multiple of CN9130? 2x CN9130? >> this specifically is an academic question, >> the main point is multiple southbridges to one CN9130. > I did not know to what you refer. > >>> You <cut> should know what is this about and come >>> with explanation to the community. >> If I was to come up with something new, without looking at existing >> Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml >> I would describe the hardware like this: >> >> SolidRun "CN9131" SolidWAN board is comptible with: >> - solidrun,cn9131-solidwan: >> name of the carrier board, and name of the complete product >> includes one southbridge chip, but I don't need to mention it? >> - solidrun,cn9130-sr-som: >> just the som, including 1x CN9130 SoC >> - marvell,cn9130: >> this is the SoC, internally combining AP+CP >> AP *could* be mentioned, but I don't see a reason > With an explanation in commit msg about not using other compatible > fallbacks, this looks good to me. Great. So perhaps my next step will be a v2 with explanations. > >>> You<cut>r platform maintainers should know what is this about and come >>> with explanation to the community. >> Is there a way forward? >> Would it be worth challenging the existing bindings by proposing (RFC) >> specific changes in line with what I described above? > It all depends on "what" and "why" you want to do. I don't know. First priority is supporting the solidrun boards based on cn9130 soc, which requires getting the bindings right (at least for these boards). Changing the other bindings would only satisfy my desire for order, but could get attention from other contributors to these platforms. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards 2024-03-21 21:47 ` Josua Mayer @ 2024-03-28 16:22 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-28 16:22 UTC (permalink / raw) To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Hi all, Am 21.03.24 um 22:47 schrieb Josua Mayer: > Add bindings for SolidRun Clearfog boards, using a new SoM based on > CN9130 SoC. > The carrier boards are identical to the older Armada 388 based Clearfog > boards. For consistency the carrier part of compatible strings are > copied, including the established "-a1" suffix. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- > .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > index 16d2e132d3d1..36bdfd1bedd9 100644 > --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > @@ -82,4 +82,16 @@ properties: > - const: marvell,armada-ap807-quad > - const: marvell,armada-ap807 > > + - description: > + SolidRun CN9130 clearfog family single-board computers > + items: vvv > + - enum: > + - solidrun,clearfog-base-a1 > + - solidrun,clearfog-pro-a1 > + - const: solidrun,clearfog-a1 ^^^ After some thought, this no longer makes any sense to me. Even identical carrier board combined with different SoC will have different characteristics. Any reason to repeat armada 388 board compatibles? Otherwise I may choose only solidrun,cn9130-clearfog-base/pro. > + - const: solidrun,cn9130-sr-som > + - const: marvell,cn9130 > + - const: marvell,armada-ap807-quad > + - const: marvell,armada-ap807 > + > additionalProperties: true > ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards @ 2024-03-28 16:22 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-28 16:22 UTC (permalink / raw) To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Hi all, Am 21.03.24 um 22:47 schrieb Josua Mayer: > Add bindings for SolidRun Clearfog boards, using a new SoM based on > CN9130 SoC. > The carrier boards are identical to the older Armada 388 based Clearfog > boards. For consistency the carrier part of compatible strings are > copied, including the established "-a1" suffix. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- > .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > index 16d2e132d3d1..36bdfd1bedd9 100644 > --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml > @@ -82,4 +82,16 @@ properties: > - const: marvell,armada-ap807-quad > - const: marvell,armada-ap807 > > + - description: > + SolidRun CN9130 clearfog family single-board computers > + items: vvv > + - enum: > + - solidrun,clearfog-base-a1 > + - solidrun,clearfog-pro-a1 > + - const: solidrun,clearfog-a1 ^^^ After some thought, this no longer makes any sense to me. Even identical carrier board combined with different SoC will have different characteristics. Any reason to repeat armada 388 board compatibles? Otherwise I may choose only solidrun,cn9130-clearfog-base/pro. > + - const: solidrun,cn9130-sr-som > + - const: marvell,cn9130 > + - const: marvell,armada-ap807-quad > + - const: marvell,armada-ap807 > + > additionalProperties: true > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards 2024-03-21 21:47 ` Josua Mayer @ 2024-03-21 21:47 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-21 21:47 UTC (permalink / raw) To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel, Josua Mayer Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro reference boards. The SoM has been designed as a pin-compatible replacement for the older Armada 388 based SoM. Therefore it supports the same boards and a similar feature set. Most notable upgrades: - 4x Cortex-A72 - 10Gbps SFP - Both eMMC and SD supported at the same time The developer first supporting this product at SolidRun decided to use different filenames for the DTBs: Armada 388 uses the full "clearfog" string while cn9130 uses the abbreviation "cf". This name is already hard-coded in pre-installed vendor u-boot and can not be changed easily. NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: CN9130 SoM has a different footprint from Armada 388 SoM. Components on the carrier board below the SoM may collide causing damage, such as on Clearfog Base. Signed-off-by: Josua Mayer <josua@solid-run.com> --- arch/arm64/boot/dts/marvell/Makefile | 2 + arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 ++++++++++++++++ 5 files changed, 747 insertions(+) diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile index 99b8cb3c49e1..019f2251d696 100644 --- a/arch/arm64/boot/dts/marvell/Makefile +++ b/arch/arm64/boot/dts/marvell/Makefile @@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts new file mode 100644 index 000000000000..b0067940d5e4 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts @@ -0,0 +1,138 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + * DTS for SolidRun CN9130 Clearfog Base. + * + */ + +/dts-v1/; + +#include <dt-bindings/input/input.h> + +#include "cn9130.dtsi" +#include "cn9130-sr-som.dtsi" +#include "cn9130-cf.dtsi" + +/ { + model = "SolidRun CN9130 Clearfog Base"; + compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1", + "solidrun,cn9130-sr-som","marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + gpio-keys { + compatible = "gpio-keys"; + pinctrl-0 = <&rear_button_pins>; + pinctrl-names = "default"; + + button-0 { + /* The rear SW3 button */ + label = "Rear Button"; + gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>; + linux,can-disable; + linux,code = <BTN_0>; + }; + }; + + rfkill-m2-gnss { + compatible = "rfkill-gpio"; + label = "m.2 GNSS"; + radio-type = "gps"; + /* rfkill-gpio inverts internally */ + shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>; + }; + + /* M.2 is B-keyed, so w-disable is for WWAN */ + rfkill-m2-wwan { + compatible = "rfkill-gpio"; + label = "m.2 WWAN"; + radio-type = "wwan"; + /* rfkill-gpio inverts internally */ + shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>; + }; +}; + +/* SRDS #3 - SGMII 1GE */ +&cp0_eth1 { + phy = <&phy1>; + phys = <&cp0_comphy3 1>; + phy-mode = "sgmii"; + status = "okay"; +}; + +&cp0_eth2_phy { + /* + * Configure LEDs: + * - LED[0]: link/activity: On/blink (green) + * - LED[1]: link is 100/1000Mbps: On (yellow) + * - LED[2]: high impedance (floating) + */ + marvell,reg-init = <3 16 0xf000 0x0a61>; +}; + +&cp0_gpio1 { + sim-select-hog { + gpio-hog; + gpios = <27 GPIO_ACTIVE_HIGH>; + output-high; + line-name = "sim-select"; + }; +}; + +&cp0_mdio { + phy1: ethernet-phy@1 { + reg = <1>; + /* + * Configure LEDs: + * - LED[0]: link/activity: On/blink (green) + * - LED[1]: link is 100/1000Mbps: On (yellow) + * - LED[2]: high impedance (floating) + * + * Polarity: On = low, Off = high (not hi-z) + */ + marvell,reg-init = <3 16 0xf000 0x0a61>, + <3 17 0x003f 0x000a>; + }; +}; + +&cp0_pinctrl { + pinctrl-0 = <&sim_select_pins>; + pintrl-names = "default"; + + rear_button_pins: cp0-rear-button-pins { + marvell,pins = "mpp31"; + marvell,function = "gpio"; + }; + + sim_select_pins: cp0-sim-select-pins { + marvell,pins = "mpp27"; + marvell,function = "gpio"; + }; +}; + +/* + * SRDS #4 - USB 3.0 host on M.2 connector + * USB-2.0 Host on Type-A connector + */ +&cp0_usb3_1 { + phys = <&cp0_comphy4 1>, <&cp0_utmi1>; + phy-names = "comphy", "utmi"; + dr_mode = "host"; + status = "okay"; +}; + +&expander0 { + m2-full-card-power-off-hog { + gpio-hog; + gpios = <2 GPIO_ACTIVE_LOW>; + output-low; + line-name = "m2-full-card-power-off"; + }; + + m2-reset-hog { + gpio-hog; + gpios = <10 GPIO_ACTIVE_LOW>; + output-low; + line-name = "m2-reset"; + }; +}; diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts new file mode 100644 index 000000000000..f7733f6a89b8 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts @@ -0,0 +1,249 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + * DTS for SolidRun CN9130 Clearfog Pro. + * + */ + +/dts-v1/; + +#include <dt-bindings/input/input.h> + +#include "cn9130.dtsi" +#include "cn9130-sr-som.dtsi" +#include "cn9130-cf.dtsi" + +/ { + model = "SolidRun CN9130 Clearfog Pro"; + compatible = "solidrun,clearfog-pro-a1", "solidrun,clearfog-a1", + "solidrun,cn9130-sr-som","marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + gpio-keys { + compatible = "gpio-keys"; + pinctrl-0 = <&rear_button_pins>; + pinctrl-names = "default"; + + button-0 { + /* The rear SW3 button */ + label = "Rear Button"; + gpios = <&cp0_gpio2 0 GPIO_ACTIVE_LOW>; + linux,can-disable; + linux,code = <BTN_0>; + }; + }; + + /* mini-pcie w-disable could be either wlan or wwan */ + rfkill-mpcie1-xxan { + compatible = "rfkill-gpio"; + label = "mPCI-e WLAN (CON2)"; + radio-type = "wlan"; + /* rfkill-gpio inverts internally */ + shutdown-gpios = <&expander0 7 GPIO_ACTIVE_HIGH>; + }; +}; + +/* SRDS #3 - SGMII 1GE to L2 switch */ +&cp0_eth1 { + phys = <&cp0_comphy3 1>; + phy-mode = "sgmii"; + status = "okay"; + + fixed-link { + speed = <1000>; + full-duplex; + }; +}; + +&cp0_eth2_phy { + /* + * Configure LEDs similar to switch ports: + * - LED[0]: link/activity: On/blink (green) + * - LED[1]: link is 100/1000Mbps: On (red) + * - LED[2]: high impedance (floating) + * + * Switch port defaults: + * - LED0: link/activity: On/blink (green) + * - LED1: link is 1000Mbps: On (red) + * + * Identical configuration is impossible. + */ + marvell,reg-init = <3 16 0xf000 0x0a61>; +}; + +&cp0_mdio { + ethernet-switch@4 { + compatible = "marvell,mv88e6085"; + reg = <4>; + pinctrl-0 = <&dsa_clk_pins &dsa_pins>; + pinctrl-names = "default"; + reset-gpios = <&cp0_gpio1 27 GPIO_ACTIVE_LOW>; + interrupt-parent = <&cp0_gpio1>; + interrupts = <29 IRQ_TYPE_EDGE_FALLING>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-port@0 { + reg = <0>; + label = "lan5"; + phy = <&switch0phy0>; + }; + + ethernet-port@1 { + reg = <1>; + label = "lan4"; + phy = <&switch0phy1>; + }; + + ethernet-port@2 { + reg = <2>; + label = "lan3"; + phy = <&switch0phy2>; + }; + + ethernet-port@3 { + reg = <3>; + label = "lan2"; + phy = <&switch0phy3>; + }; + + ethernet-port@4 { + reg = <4>; + label = "lan1"; + phy = <&switch0phy4>; + }; + + ethernet-port@5 { + reg = <5>; + ethernet = <&cp0_eth1>; + phy-mode = "sgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + ethernet-port@6 { + reg = <6>; + label = "lan6"; + phy-mode = "rgmii"; + + /* + * Because of mdio address conflict the + * external phy is not readable. + * Force a fixed link instead. + */ + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + switch0phy0: ethernet-phy@0 { + reg = <0x0>; + }; + + switch0phy1: ethernet-phy@1 { + reg = <0x1>; + /* + * Indirectly configure LEDs for port + * lan6 using external phy. + * Internal PHYs are not using page 3, + * therefore writing to it is safe. + */ + marvell,reg-init = <3 16 0xf000 0x0a61>; + }; + + switch0phy2: ethernet-phy@2 { + reg = <0x2>; + }; + + switch0phy3: ethernet-phy@3 { + reg = <0x3>; + }; + + switch0phy4: ethernet-phy@4 { + reg = <0x4>; + }; + }; + + /* + * There is an external phy on the switch mdio bus. + * Because its mdio address collides with internal phys, + * it is not readable. + * + * mdio-external { + * compatible = "marvell,mv88e6xxx-mdio-external"; + * #address-cells = <1>; + * #size-cells = <0>; + * + * ethernet-phy@1 { + * reg = <0x1>; + * }; + * }; + */ + }; +}; + +/* SRDS #4 - miniPCIe (CON2) */ +&cp0_pcie1 { + num-lanes = <1>; + phys = <&cp0_comphy4 1>; + /* dw-pcie inverts internally */ + reset-gpios = <&expander0 2 GPIO_ACTIVE_HIGH>; + status = "okay"; +}; + +&cp0_pinctrl { + dsa_clk_pins: cp0-dsa-clk-pins { + marvell,pins = "mpp40"; + marvell,function = "synce1"; + }; + + dsa_pins: cp0-dsa-pins { + marvell,pins = "mpp27", "mpp29"; + marvell,function = "gpio"; + }; + + rear_button_pins: cp0-rear-button-pins { + marvell,pins = "mpp32"; + marvell,function = "gpio"; + }; +}; + +/* + * USB-2.0 Host on Type-A connector + */ +&cp0_usb3_1 { + phys = <&cp0_utmi1>; + phy-names = "utmi"; + dr_mode = "host"; + status = "okay"; +}; + +&expander0 { + /* CON2 */ + pcie1-0-clkreq-hog { + gpio-hog; + gpios = <4 GPIO_ACTIVE_LOW>; + input; + line-name = "pcie1.0-clkreq"; + }; + + /* CON2 */ + pcie1-0-w-disable-hog { + gpio-hog; + gpios = <7 GPIO_ACTIVE_LOW>; + output-low; + line-name = "pcie1.0-w-disable"; + }; +}; diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi b/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi new file mode 100644 index 000000000000..1aaa0d916e75 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi @@ -0,0 +1,198 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + * DTS for common base of SolidRun CN9130 Clearfog Base and Pro. + * + */ + +/ { + model = "SolidRun CN9130 Clearfog"; + compatible = "solidrun,clearfog-a1", + "solidrun,cn9130-sr-som","marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + aliases { + i2c1 = &cp0_i2c1; + mmc1 = &cp0_sdhci0; + }; + + reg_usb3_vbus0: regulator-usb3-vbus0 { + compatible = "regulator-fixed"; + regulator-name = "vbus0"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + gpio = <&expander0 6 GPIO_ACTIVE_LOW>; + }; + + sfp: sfp { + compatible = "sff,sfp"; + i2c-bus = <&cp0_i2c1>; + los-gpios = <&expander0 12 GPIO_ACTIVE_HIGH>; + mod-def0-gpios = <&expander0 15 GPIO_ACTIVE_LOW>; + tx-disable-gpios = <&expander0 14 GPIO_ACTIVE_HIGH>; + tx-fault-gpios = <&expander0 13 GPIO_ACTIVE_HIGH>; + maximum-power-milliwatt = <2000>; + }; +}; + +/* SRDS #2 - SFP+ 10GE */ +&cp0_eth0 { + managed = "in-band-status"; + phys = <&cp0_comphy2 0>; + phy-mode = "10gbase-r"; + sfp = <&sfp>; + status = "okay"; +}; + +&cp0_i2c0 { + expander0: gpio-expander@20 { + compatible = "nxp,pca9555"; + reg = <0x20>; + gpio-controller; + #gpio-cells = <2>; + pinctrl-0 = <&expander0_pins>; + pinctrl-names = "default"; + interrupt-parent = <&cp0_gpio1>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + + /* CON3 */ + pcie2-0-clkreq-hog { + gpio-hog; + gpios = <0 GPIO_ACTIVE_LOW>; + input; + line-name = "pcie2.0-clkreq"; + }; + + /* CON3 */ + pcie2-0-w-disable-hog { + gpio-hog; + gpios = <3 GPIO_ACTIVE_LOW>; + output-low; + line-name = "pcie2.0-w-disable"; + }; + + usb3-ilimit-hog { + gpio-hog; + gpios = <5 GPIO_ACTIVE_LOW>; + input; + line-name = "usb3-current-limit"; + }; + + m2-devslp-hog { + gpio-hog; + gpios = <11 GPIO_ACTIVE_HIGH>; + output-low; + line-name = "m.2 devslp"; + }; + }; + + /* The MCP3021 supports standard and fast modes */ + adc@4c { + compatible = "microchip,mcp3021"; + reg = <0x4c>; + }; + + carrier_eeprom: eeprom@52 { + compatible = "atmel,24c02"; + reg = <0x52>; + pagesize = <8>; + }; +}; + +&cp0_i2c1 { + /* + * Routed to SFP, M.2, mikrobus, and miniPCIe + * SFP limits this to 100kHz, and requires an AT24C01A/02/04 with + * address pins tied low, which takes addresses 0x50 and 0x51. + * Mikrobus doesn't specify beyond an I2C bus being present. + * PCIe uses ARP to assign addresses, or 0x63-0x64. + */ + clock-frequency = <100000>; + pinctrl-0 = <&cp0_i2c1_pins>; + pinctrl-names = "default"; + status = "okay"; +}; + +/* SRDS #5 - miniPCIe (CON3) */ +&cp0_pcie2 { + num-lanes = <1>; + phys = <&cp0_comphy5 2>; + /* dw-pcie inverts internally */ + reset-gpios = <&expander0 1 GPIO_ACTIVE_HIGH>; + status = "okay"; +}; + +&cp0_pinctrl { + cp0_i2c1_pins: cp0-i2c1-pins { + marvell,pins = "mpp35", "mpp36"; + marvell,function = "i2c1"; + }; + + cp0_mmc0_pins: cp0-mmc0-pins { + marvell,pins = "mpp43", "mpp56", "mpp57", "mpp58", + "mpp59", "mpp60", "mpp61"; + marvell,function = "sdio"; + }; + + mikro_spi_pins: cp0-spi1-cs1-pins { + marvell,pins = "mpp12"; + marvell,function = "spi1"; + }; + + mikro_uart_pins: cp0-uart-pins { + marvell,pins = "mpp2", "mpp3"; + marvell,function = "uart1"; + }; + + expander0_pins: cp0-expander0-pins { + marvell,pins = "mpp4"; + marvell,function = "gpio"; + }; +}; + +/* SRDS #0 - SATA on M.2 connector */ +&cp0_sata0 { + phys = <&cp0_comphy0 1>; + status = "okay"; + + /* only port 1 is available */ + /delete-node/ sata-port@0; +}; + +/* microSD */ +&cp0_sdhci0 { + pinctrl-0 = <&cp0_mmc0_pins>; + pinctrl-names = "default"; + bus-width = <4>; + no-1-8-v; + status = "okay"; +}; + +&cp0_spi1 { + /* CS1 for mikrobus */ + pinctrl-0 = <&cp0_spi1_pins &mikro_spi_pins>; +}; + +/* + * SRDS #1 - 3.0 Host on Type-A connector + * USB-2.0 Host on mPCI-e connector (CON3) + */ +&cp0_usb3_0 { + phys = <&cp0_comphy1 0>, <&cp0_utmi0>; + phy-names = "comphy", "utmi"; + vbus-supply = <®_usb3_vbus0>; + dr_mode = "host"; + status = "okay"; +}; + +&cp0_utmi { + status = "okay"; +}; + +/* mikrobus uart */ +&cp0_uart0 { + pinctrl-0 = <&mikro_uart_pins>; + pinctrl-names = "default"; + status = "okay"; +}; diff --git a/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi b/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi new file mode 100644 index 000000000000..f151a2a399c1 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi @@ -0,0 +1,160 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + */ + +#include <dt-bindings/gpio/gpio.h> + +/ { + model = "SolidRun CN9130 SoM"; + compatible = "solidrun,cn9130-sr-som", "marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + aliases { + /* label nics like armada-388 som */ + ethernet0 = &cp0_eth2; + ethernet1 = &cp0_eth1; + ethernet2 = &cp0_eth0; + i2c0 = &cp0_i2c0; + mmc0 = &ap_sdhci0; + rtc0 = &cp0_rtc; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; + + v_1_8: regulator-1-8 { + compatible = "regulator-fixed"; + regulator-name = "1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + /* requires assembly of R9307 */ + vhv: regulator-vhv-1-8 { + compatible = "regulator-fixed"; + regulator-name = "vhv-1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + pinctrl-0 = <&cp0_reg_vhv_pins>; + pinctrl-names = "default"; + gpio = <&cp0_gpio2 9 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; +}; + +&ap_pinctrl { + ap_mmc0_pins: ap-mmc0-pins { + marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3", "mpp4", "mpp5", + "mpp6", "mpp7", "mpp8", "mpp9", "mpp10", "mpp12"; + marvell,function = "sdio"; + /* + * mpp12 is emmc reset, function should be sdio (hw_rst), + * but pinctrl-mvebu does not support this. + * + * From pinctrl-mvebu.h: + * "The name will be used to switch to this setting in DT description, e.g. + * marvell,function = "uart2". subname is only for debugging purposes." + */ + }; +}; + +&ap_sdhci0 { + bus-width = <8>; + pinctrl-0 = <&ap_mmc0_pins>; + pinctrl-names = "default"; + vqmmc-supply = <&v_1_8>; + status = "okay"; +}; + +&cp0_ethernet { + status = "okay"; +}; + +/* for assembly with phy */ +&cp0_eth2 { + pinctrl-names = "default"; + pinctrl-0 = <&cp0_eth2_pins>; + phy-mode = "rgmii-id"; + phy = <&cp0_eth2_phy>; + status = "okay"; +}; + +&cp0_i2c0 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&cp0_i2c0_pins>; + clock-frequency = <100000>; + status = "okay"; + + som_eeprom: eeprom@53 { + compatible = "atmel,24c02"; + reg = <0x53>; + pagesize = <8>; + }; +}; + +&cp0_mdio { + status = "okay"; + pinctrl-0 = <&cp0_mdio_pins>; + + /* assembly option */ + cp0_eth2_phy: ethernet-phy@0 { + reg = <0>; + }; +}; + +&cp0_spi1 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&cp0_spi1_pins>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + spi-max-frequency = <10000000>; + }; +}; + +&cp0_syscon0 { + cp0_pinctrl: pinctrl { + compatible = "marvell,cp115-standalone-pinctrl"; + + cp0_eth2_pins: cp0-ge2-rgmii-pins { + marvell,pins = "mpp44", "mpp45", "mpp46", "mpp47", + "mpp48", "mpp49", "mpp50", "mpp51", + "mpp52", "mpp53", "mpp54", "mpp55"; + /* docs call it "ge2", but cp110-pinctrl "ge1" */ + marvell,function = "ge1"; + }; + + cp0_i2c0_pins: cp0-i2c0-pins { + marvell,pins = "mpp37", "mpp38"; + marvell,function = "i2c0"; + }; + + cp0_mdio_pins: cp0-mdio-pins { + marvell,pins = "mpp40", "mpp41"; + marvell,function = "ge"; + }; + + cp0_spi1_pins: cp0-spi1-pins { + marvell,pins = "mpp13", "mpp14", "mpp15", "mpp16"; + marvell,function = "spi1"; + }; + + cp0_reg_vhv_pins: cp0-reg-vhv-pins { + marvell,pins = "mpp41"; + marvell,function = "gpio"; + }; + }; +}; + +/* AP default console */ +&uart0 { + pinctrl-0 = <&uart0_pins>; + pinctrl-names = "default"; + status = "okay"; +}; -- 2.35.3 ^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards @ 2024-03-21 21:47 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-21 21:47 UTC (permalink / raw) To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel, Josua Mayer Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro reference boards. The SoM has been designed as a pin-compatible replacement for the older Armada 388 based SoM. Therefore it supports the same boards and a similar feature set. Most notable upgrades: - 4x Cortex-A72 - 10Gbps SFP - Both eMMC and SD supported at the same time The developer first supporting this product at SolidRun decided to use different filenames for the DTBs: Armada 388 uses the full "clearfog" string while cn9130 uses the abbreviation "cf". This name is already hard-coded in pre-installed vendor u-boot and can not be changed easily. NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: CN9130 SoM has a different footprint from Armada 388 SoM. Components on the carrier board below the SoM may collide causing damage, such as on Clearfog Base. Signed-off-by: Josua Mayer <josua@solid-run.com> --- arch/arm64/boot/dts/marvell/Makefile | 2 + arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++++++ arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 ++++++++++++++++ 5 files changed, 747 insertions(+) diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile index 99b8cb3c49e1..019f2251d696 100644 --- a/arch/arm64/boot/dts/marvell/Makefile +++ b/arch/arm64/boot/dts/marvell/Makefile @@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts new file mode 100644 index 000000000000..b0067940d5e4 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts @@ -0,0 +1,138 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + * DTS for SolidRun CN9130 Clearfog Base. + * + */ + +/dts-v1/; + +#include <dt-bindings/input/input.h> + +#include "cn9130.dtsi" +#include "cn9130-sr-som.dtsi" +#include "cn9130-cf.dtsi" + +/ { + model = "SolidRun CN9130 Clearfog Base"; + compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1", + "solidrun,cn9130-sr-som","marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + gpio-keys { + compatible = "gpio-keys"; + pinctrl-0 = <&rear_button_pins>; + pinctrl-names = "default"; + + button-0 { + /* The rear SW3 button */ + label = "Rear Button"; + gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>; + linux,can-disable; + linux,code = <BTN_0>; + }; + }; + + rfkill-m2-gnss { + compatible = "rfkill-gpio"; + label = "m.2 GNSS"; + radio-type = "gps"; + /* rfkill-gpio inverts internally */ + shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>; + }; + + /* M.2 is B-keyed, so w-disable is for WWAN */ + rfkill-m2-wwan { + compatible = "rfkill-gpio"; + label = "m.2 WWAN"; + radio-type = "wwan"; + /* rfkill-gpio inverts internally */ + shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>; + }; +}; + +/* SRDS #3 - SGMII 1GE */ +&cp0_eth1 { + phy = <&phy1>; + phys = <&cp0_comphy3 1>; + phy-mode = "sgmii"; + status = "okay"; +}; + +&cp0_eth2_phy { + /* + * Configure LEDs: + * - LED[0]: link/activity: On/blink (green) + * - LED[1]: link is 100/1000Mbps: On (yellow) + * - LED[2]: high impedance (floating) + */ + marvell,reg-init = <3 16 0xf000 0x0a61>; +}; + +&cp0_gpio1 { + sim-select-hog { + gpio-hog; + gpios = <27 GPIO_ACTIVE_HIGH>; + output-high; + line-name = "sim-select"; + }; +}; + +&cp0_mdio { + phy1: ethernet-phy@1 { + reg = <1>; + /* + * Configure LEDs: + * - LED[0]: link/activity: On/blink (green) + * - LED[1]: link is 100/1000Mbps: On (yellow) + * - LED[2]: high impedance (floating) + * + * Polarity: On = low, Off = high (not hi-z) + */ + marvell,reg-init = <3 16 0xf000 0x0a61>, + <3 17 0x003f 0x000a>; + }; +}; + +&cp0_pinctrl { + pinctrl-0 = <&sim_select_pins>; + pintrl-names = "default"; + + rear_button_pins: cp0-rear-button-pins { + marvell,pins = "mpp31"; + marvell,function = "gpio"; + }; + + sim_select_pins: cp0-sim-select-pins { + marvell,pins = "mpp27"; + marvell,function = "gpio"; + }; +}; + +/* + * SRDS #4 - USB 3.0 host on M.2 connector + * USB-2.0 Host on Type-A connector + */ +&cp0_usb3_1 { + phys = <&cp0_comphy4 1>, <&cp0_utmi1>; + phy-names = "comphy", "utmi"; + dr_mode = "host"; + status = "okay"; +}; + +&expander0 { + m2-full-card-power-off-hog { + gpio-hog; + gpios = <2 GPIO_ACTIVE_LOW>; + output-low; + line-name = "m2-full-card-power-off"; + }; + + m2-reset-hog { + gpio-hog; + gpios = <10 GPIO_ACTIVE_LOW>; + output-low; + line-name = "m2-reset"; + }; +}; diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts new file mode 100644 index 000000000000..f7733f6a89b8 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts @@ -0,0 +1,249 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + * DTS for SolidRun CN9130 Clearfog Pro. + * + */ + +/dts-v1/; + +#include <dt-bindings/input/input.h> + +#include "cn9130.dtsi" +#include "cn9130-sr-som.dtsi" +#include "cn9130-cf.dtsi" + +/ { + model = "SolidRun CN9130 Clearfog Pro"; + compatible = "solidrun,clearfog-pro-a1", "solidrun,clearfog-a1", + "solidrun,cn9130-sr-som","marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + gpio-keys { + compatible = "gpio-keys"; + pinctrl-0 = <&rear_button_pins>; + pinctrl-names = "default"; + + button-0 { + /* The rear SW3 button */ + label = "Rear Button"; + gpios = <&cp0_gpio2 0 GPIO_ACTIVE_LOW>; + linux,can-disable; + linux,code = <BTN_0>; + }; + }; + + /* mini-pcie w-disable could be either wlan or wwan */ + rfkill-mpcie1-xxan { + compatible = "rfkill-gpio"; + label = "mPCI-e WLAN (CON2)"; + radio-type = "wlan"; + /* rfkill-gpio inverts internally */ + shutdown-gpios = <&expander0 7 GPIO_ACTIVE_HIGH>; + }; +}; + +/* SRDS #3 - SGMII 1GE to L2 switch */ +&cp0_eth1 { + phys = <&cp0_comphy3 1>; + phy-mode = "sgmii"; + status = "okay"; + + fixed-link { + speed = <1000>; + full-duplex; + }; +}; + +&cp0_eth2_phy { + /* + * Configure LEDs similar to switch ports: + * - LED[0]: link/activity: On/blink (green) + * - LED[1]: link is 100/1000Mbps: On (red) + * - LED[2]: high impedance (floating) + * + * Switch port defaults: + * - LED0: link/activity: On/blink (green) + * - LED1: link is 1000Mbps: On (red) + * + * Identical configuration is impossible. + */ + marvell,reg-init = <3 16 0xf000 0x0a61>; +}; + +&cp0_mdio { + ethernet-switch@4 { + compatible = "marvell,mv88e6085"; + reg = <4>; + pinctrl-0 = <&dsa_clk_pins &dsa_pins>; + pinctrl-names = "default"; + reset-gpios = <&cp0_gpio1 27 GPIO_ACTIVE_LOW>; + interrupt-parent = <&cp0_gpio1>; + interrupts = <29 IRQ_TYPE_EDGE_FALLING>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-port@0 { + reg = <0>; + label = "lan5"; + phy = <&switch0phy0>; + }; + + ethernet-port@1 { + reg = <1>; + label = "lan4"; + phy = <&switch0phy1>; + }; + + ethernet-port@2 { + reg = <2>; + label = "lan3"; + phy = <&switch0phy2>; + }; + + ethernet-port@3 { + reg = <3>; + label = "lan2"; + phy = <&switch0phy3>; + }; + + ethernet-port@4 { + reg = <4>; + label = "lan1"; + phy = <&switch0phy4>; + }; + + ethernet-port@5 { + reg = <5>; + ethernet = <&cp0_eth1>; + phy-mode = "sgmii"; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + ethernet-port@6 { + reg = <6>; + label = "lan6"; + phy-mode = "rgmii"; + + /* + * Because of mdio address conflict the + * external phy is not readable. + * Force a fixed link instead. + */ + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + switch0phy0: ethernet-phy@0 { + reg = <0x0>; + }; + + switch0phy1: ethernet-phy@1 { + reg = <0x1>; + /* + * Indirectly configure LEDs for port + * lan6 using external phy. + * Internal PHYs are not using page 3, + * therefore writing to it is safe. + */ + marvell,reg-init = <3 16 0xf000 0x0a61>; + }; + + switch0phy2: ethernet-phy@2 { + reg = <0x2>; + }; + + switch0phy3: ethernet-phy@3 { + reg = <0x3>; + }; + + switch0phy4: ethernet-phy@4 { + reg = <0x4>; + }; + }; + + /* + * There is an external phy on the switch mdio bus. + * Because its mdio address collides with internal phys, + * it is not readable. + * + * mdio-external { + * compatible = "marvell,mv88e6xxx-mdio-external"; + * #address-cells = <1>; + * #size-cells = <0>; + * + * ethernet-phy@1 { + * reg = <0x1>; + * }; + * }; + */ + }; +}; + +/* SRDS #4 - miniPCIe (CON2) */ +&cp0_pcie1 { + num-lanes = <1>; + phys = <&cp0_comphy4 1>; + /* dw-pcie inverts internally */ + reset-gpios = <&expander0 2 GPIO_ACTIVE_HIGH>; + status = "okay"; +}; + +&cp0_pinctrl { + dsa_clk_pins: cp0-dsa-clk-pins { + marvell,pins = "mpp40"; + marvell,function = "synce1"; + }; + + dsa_pins: cp0-dsa-pins { + marvell,pins = "mpp27", "mpp29"; + marvell,function = "gpio"; + }; + + rear_button_pins: cp0-rear-button-pins { + marvell,pins = "mpp32"; + marvell,function = "gpio"; + }; +}; + +/* + * USB-2.0 Host on Type-A connector + */ +&cp0_usb3_1 { + phys = <&cp0_utmi1>; + phy-names = "utmi"; + dr_mode = "host"; + status = "okay"; +}; + +&expander0 { + /* CON2 */ + pcie1-0-clkreq-hog { + gpio-hog; + gpios = <4 GPIO_ACTIVE_LOW>; + input; + line-name = "pcie1.0-clkreq"; + }; + + /* CON2 */ + pcie1-0-w-disable-hog { + gpio-hog; + gpios = <7 GPIO_ACTIVE_LOW>; + output-low; + line-name = "pcie1.0-w-disable"; + }; +}; diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi b/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi new file mode 100644 index 000000000000..1aaa0d916e75 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi @@ -0,0 +1,198 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + * DTS for common base of SolidRun CN9130 Clearfog Base and Pro. + * + */ + +/ { + model = "SolidRun CN9130 Clearfog"; + compatible = "solidrun,clearfog-a1", + "solidrun,cn9130-sr-som","marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + aliases { + i2c1 = &cp0_i2c1; + mmc1 = &cp0_sdhci0; + }; + + reg_usb3_vbus0: regulator-usb3-vbus0 { + compatible = "regulator-fixed"; + regulator-name = "vbus0"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + gpio = <&expander0 6 GPIO_ACTIVE_LOW>; + }; + + sfp: sfp { + compatible = "sff,sfp"; + i2c-bus = <&cp0_i2c1>; + los-gpios = <&expander0 12 GPIO_ACTIVE_HIGH>; + mod-def0-gpios = <&expander0 15 GPIO_ACTIVE_LOW>; + tx-disable-gpios = <&expander0 14 GPIO_ACTIVE_HIGH>; + tx-fault-gpios = <&expander0 13 GPIO_ACTIVE_HIGH>; + maximum-power-milliwatt = <2000>; + }; +}; + +/* SRDS #2 - SFP+ 10GE */ +&cp0_eth0 { + managed = "in-band-status"; + phys = <&cp0_comphy2 0>; + phy-mode = "10gbase-r"; + sfp = <&sfp>; + status = "okay"; +}; + +&cp0_i2c0 { + expander0: gpio-expander@20 { + compatible = "nxp,pca9555"; + reg = <0x20>; + gpio-controller; + #gpio-cells = <2>; + pinctrl-0 = <&expander0_pins>; + pinctrl-names = "default"; + interrupt-parent = <&cp0_gpio1>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + + /* CON3 */ + pcie2-0-clkreq-hog { + gpio-hog; + gpios = <0 GPIO_ACTIVE_LOW>; + input; + line-name = "pcie2.0-clkreq"; + }; + + /* CON3 */ + pcie2-0-w-disable-hog { + gpio-hog; + gpios = <3 GPIO_ACTIVE_LOW>; + output-low; + line-name = "pcie2.0-w-disable"; + }; + + usb3-ilimit-hog { + gpio-hog; + gpios = <5 GPIO_ACTIVE_LOW>; + input; + line-name = "usb3-current-limit"; + }; + + m2-devslp-hog { + gpio-hog; + gpios = <11 GPIO_ACTIVE_HIGH>; + output-low; + line-name = "m.2 devslp"; + }; + }; + + /* The MCP3021 supports standard and fast modes */ + adc@4c { + compatible = "microchip,mcp3021"; + reg = <0x4c>; + }; + + carrier_eeprom: eeprom@52 { + compatible = "atmel,24c02"; + reg = <0x52>; + pagesize = <8>; + }; +}; + +&cp0_i2c1 { + /* + * Routed to SFP, M.2, mikrobus, and miniPCIe + * SFP limits this to 100kHz, and requires an AT24C01A/02/04 with + * address pins tied low, which takes addresses 0x50 and 0x51. + * Mikrobus doesn't specify beyond an I2C bus being present. + * PCIe uses ARP to assign addresses, or 0x63-0x64. + */ + clock-frequency = <100000>; + pinctrl-0 = <&cp0_i2c1_pins>; + pinctrl-names = "default"; + status = "okay"; +}; + +/* SRDS #5 - miniPCIe (CON3) */ +&cp0_pcie2 { + num-lanes = <1>; + phys = <&cp0_comphy5 2>; + /* dw-pcie inverts internally */ + reset-gpios = <&expander0 1 GPIO_ACTIVE_HIGH>; + status = "okay"; +}; + +&cp0_pinctrl { + cp0_i2c1_pins: cp0-i2c1-pins { + marvell,pins = "mpp35", "mpp36"; + marvell,function = "i2c1"; + }; + + cp0_mmc0_pins: cp0-mmc0-pins { + marvell,pins = "mpp43", "mpp56", "mpp57", "mpp58", + "mpp59", "mpp60", "mpp61"; + marvell,function = "sdio"; + }; + + mikro_spi_pins: cp0-spi1-cs1-pins { + marvell,pins = "mpp12"; + marvell,function = "spi1"; + }; + + mikro_uart_pins: cp0-uart-pins { + marvell,pins = "mpp2", "mpp3"; + marvell,function = "uart1"; + }; + + expander0_pins: cp0-expander0-pins { + marvell,pins = "mpp4"; + marvell,function = "gpio"; + }; +}; + +/* SRDS #0 - SATA on M.2 connector */ +&cp0_sata0 { + phys = <&cp0_comphy0 1>; + status = "okay"; + + /* only port 1 is available */ + /delete-node/ sata-port@0; +}; + +/* microSD */ +&cp0_sdhci0 { + pinctrl-0 = <&cp0_mmc0_pins>; + pinctrl-names = "default"; + bus-width = <4>; + no-1-8-v; + status = "okay"; +}; + +&cp0_spi1 { + /* CS1 for mikrobus */ + pinctrl-0 = <&cp0_spi1_pins &mikro_spi_pins>; +}; + +/* + * SRDS #1 - 3.0 Host on Type-A connector + * USB-2.0 Host on mPCI-e connector (CON3) + */ +&cp0_usb3_0 { + phys = <&cp0_comphy1 0>, <&cp0_utmi0>; + phy-names = "comphy", "utmi"; + vbus-supply = <®_usb3_vbus0>; + dr_mode = "host"; + status = "okay"; +}; + +&cp0_utmi { + status = "okay"; +}; + +/* mikrobus uart */ +&cp0_uart0 { + pinctrl-0 = <&mikro_uart_pins>; + pinctrl-names = "default"; + status = "okay"; +}; diff --git a/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi b/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi new file mode 100644 index 000000000000..f151a2a399c1 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi @@ -0,0 +1,160 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> + * + */ + +#include <dt-bindings/gpio/gpio.h> + +/ { + model = "SolidRun CN9130 SoM"; + compatible = "solidrun,cn9130-sr-som", "marvell,cn9130", + "marvell,armada-ap807-quad", "marvell,armada-ap807"; + + aliases { + /* label nics like armada-388 som */ + ethernet0 = &cp0_eth2; + ethernet1 = &cp0_eth1; + ethernet2 = &cp0_eth0; + i2c0 = &cp0_i2c0; + mmc0 = &ap_sdhci0; + rtc0 = &cp0_rtc; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; + + v_1_8: regulator-1-8 { + compatible = "regulator-fixed"; + regulator-name = "1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + /* requires assembly of R9307 */ + vhv: regulator-vhv-1-8 { + compatible = "regulator-fixed"; + regulator-name = "vhv-1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + pinctrl-0 = <&cp0_reg_vhv_pins>; + pinctrl-names = "default"; + gpio = <&cp0_gpio2 9 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; +}; + +&ap_pinctrl { + ap_mmc0_pins: ap-mmc0-pins { + marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3", "mpp4", "mpp5", + "mpp6", "mpp7", "mpp8", "mpp9", "mpp10", "mpp12"; + marvell,function = "sdio"; + /* + * mpp12 is emmc reset, function should be sdio (hw_rst), + * but pinctrl-mvebu does not support this. + * + * From pinctrl-mvebu.h: + * "The name will be used to switch to this setting in DT description, e.g. + * marvell,function = "uart2". subname is only for debugging purposes." + */ + }; +}; + +&ap_sdhci0 { + bus-width = <8>; + pinctrl-0 = <&ap_mmc0_pins>; + pinctrl-names = "default"; + vqmmc-supply = <&v_1_8>; + status = "okay"; +}; + +&cp0_ethernet { + status = "okay"; +}; + +/* for assembly with phy */ +&cp0_eth2 { + pinctrl-names = "default"; + pinctrl-0 = <&cp0_eth2_pins>; + phy-mode = "rgmii-id"; + phy = <&cp0_eth2_phy>; + status = "okay"; +}; + +&cp0_i2c0 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&cp0_i2c0_pins>; + clock-frequency = <100000>; + status = "okay"; + + som_eeprom: eeprom@53 { + compatible = "atmel,24c02"; + reg = <0x53>; + pagesize = <8>; + }; +}; + +&cp0_mdio { + status = "okay"; + pinctrl-0 = <&cp0_mdio_pins>; + + /* assembly option */ + cp0_eth2_phy: ethernet-phy@0 { + reg = <0>; + }; +}; + +&cp0_spi1 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&cp0_spi1_pins>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + spi-max-frequency = <10000000>; + }; +}; + +&cp0_syscon0 { + cp0_pinctrl: pinctrl { + compatible = "marvell,cp115-standalone-pinctrl"; + + cp0_eth2_pins: cp0-ge2-rgmii-pins { + marvell,pins = "mpp44", "mpp45", "mpp46", "mpp47", + "mpp48", "mpp49", "mpp50", "mpp51", + "mpp52", "mpp53", "mpp54", "mpp55"; + /* docs call it "ge2", but cp110-pinctrl "ge1" */ + marvell,function = "ge1"; + }; + + cp0_i2c0_pins: cp0-i2c0-pins { + marvell,pins = "mpp37", "mpp38"; + marvell,function = "i2c0"; + }; + + cp0_mdio_pins: cp0-mdio-pins { + marvell,pins = "mpp40", "mpp41"; + marvell,function = "ge"; + }; + + cp0_spi1_pins: cp0-spi1-pins { + marvell,pins = "mpp13", "mpp14", "mpp15", "mpp16"; + marvell,function = "spi1"; + }; + + cp0_reg_vhv_pins: cp0-reg-vhv-pins { + marvell,pins = "mpp41"; + marvell,function = "gpio"; + }; + }; +}; + +/* AP default console */ +&uart0 { + pinctrl-0 = <&uart0_pins>; + pinctrl-names = "default"; + status = "okay"; +}; -- 2.35.3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards 2024-03-21 21:47 ` Josua Mayer @ 2024-03-21 21:59 ` Andrew Lunn -1 siblings, 0 replies; 48+ messages in thread From: Andrew Lunn @ 2024-03-21 21:59 UTC (permalink / raw) To: Josua Mayer Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On Thu, Mar 21, 2024 at 10:47:12PM +0100, Josua Mayer wrote: > Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro > reference boards. > > The SoM has been designed as a pin-compatible replacement for the older > Armada 388 based SoM. Therefore it supports the same boards and a > similar feature set. > > Most notable upgrades: > - 4x Cortex-A72 > - 10Gbps SFP > - Both eMMC and SD supported at the same time > > The developer first supporting this product at SolidRun decided to use > different filenames for the DTBs: Armada 388 uses the full > "clearfog" string while cn9130 uses the abbreviation "cf". > This name is already hard-coded in pre-installed vendor u-boot and can > not be changed easily. > > NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: > CN9130 SoM has a different footprint from Armada 388 SoM. > Components on the carrier board below the SoM may collide causing > damage, such as on Clearfog Base. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- > arch/arm64/boot/dts/marvell/Makefile | 2 + > arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++++ > arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++++++ > arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++++++ > arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 ++++++++++++++++ > 5 files changed, 747 insertions(+) > > diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile > index 99b8cb3c49e1..019f2251d696 100644 > --- a/arch/arm64/boot/dts/marvell/Makefile > +++ b/arch/arm64/boot/dts/marvell/Makefile > @@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb > dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb > dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb > dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb > +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb > +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb > diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts > new file mode 100644 > index 000000000000..b0067940d5e4 > --- /dev/null > +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts > @@ -0,0 +1,138 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> > + * > + * DTS for SolidRun CN9130 Clearfog Base. > + * > + */ > + > +/dts-v1/; > + > +#include <dt-bindings/input/input.h> > + > +#include "cn9130.dtsi" > +#include "cn9130-sr-som.dtsi" > +#include "cn9130-cf.dtsi" > + > +/ { > + model = "SolidRun CN9130 Clearfog Base"; > + compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1", > + "solidrun,cn9130-sr-som","marvell,cn9130", > + "marvell,armada-ap807-quad", "marvell,armada-ap807"; > + > + gpio-keys { > + compatible = "gpio-keys"; > + pinctrl-0 = <&rear_button_pins>; > + pinctrl-names = "default"; > + > + button-0 { > + /* The rear SW3 button */ > + label = "Rear Button"; > + gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>; > + linux,can-disable; > + linux,code = <BTN_0>; > + }; > + }; > + > + rfkill-m2-gnss { > + compatible = "rfkill-gpio"; > + label = "m.2 GNSS"; > + radio-type = "gps"; > + /* rfkill-gpio inverts internally */ > + shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>; > + }; > + > + /* M.2 is B-keyed, so w-disable is for WWAN */ > + rfkill-m2-wwan { > + compatible = "rfkill-gpio"; > + label = "m.2 WWAN"; > + radio-type = "wwan"; > + /* rfkill-gpio inverts internally */ > + shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>; > + }; > +}; > + > +/* SRDS #3 - SGMII 1GE */ > +&cp0_eth1 { > + phy = <&phy1>; > + phys = <&cp0_comphy3 1>; > + phy-mode = "sgmii"; > + status = "okay"; > +}; > + > +&cp0_eth2_phy { > + /* > + * Configure LEDs: > + * - LED[0]: link/activity: On/blink (green) > + * - LED[1]: link is 100/1000Mbps: On (yellow) > + * - LED[2]: high impedance (floating) > + */ > + marvell,reg-init = <3 16 0xf000 0x0a61>; Sorry, but no. List the LEDs in the PHY node, and they can then be controlled via /sys/class/leds. arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. Andrew ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards @ 2024-03-21 21:59 ` Andrew Lunn 0 siblings, 0 replies; 48+ messages in thread From: Andrew Lunn @ 2024-03-21 21:59 UTC (permalink / raw) To: Josua Mayer Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On Thu, Mar 21, 2024 at 10:47:12PM +0100, Josua Mayer wrote: > Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro > reference boards. > > The SoM has been designed as a pin-compatible replacement for the older > Armada 388 based SoM. Therefore it supports the same boards and a > similar feature set. > > Most notable upgrades: > - 4x Cortex-A72 > - 10Gbps SFP > - Both eMMC and SD supported at the same time > > The developer first supporting this product at SolidRun decided to use > different filenames for the DTBs: Armada 388 uses the full > "clearfog" string while cn9130 uses the abbreviation "cf". > This name is already hard-coded in pre-installed vendor u-boot and can > not be changed easily. > > NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: > CN9130 SoM has a different footprint from Armada 388 SoM. > Components on the carrier board below the SoM may collide causing > damage, such as on Clearfog Base. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- > arch/arm64/boot/dts/marvell/Makefile | 2 + > arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++++ > arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++++++ > arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++++++ > arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 ++++++++++++++++ > 5 files changed, 747 insertions(+) > > diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile > index 99b8cb3c49e1..019f2251d696 100644 > --- a/arch/arm64/boot/dts/marvell/Makefile > +++ b/arch/arm64/boot/dts/marvell/Makefile > @@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb > dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb > dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb > dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb > +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb > +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb > diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts > new file mode 100644 > index 000000000000..b0067940d5e4 > --- /dev/null > +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts > @@ -0,0 +1,138 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> > + * > + * DTS for SolidRun CN9130 Clearfog Base. > + * > + */ > + > +/dts-v1/; > + > +#include <dt-bindings/input/input.h> > + > +#include "cn9130.dtsi" > +#include "cn9130-sr-som.dtsi" > +#include "cn9130-cf.dtsi" > + > +/ { > + model = "SolidRun CN9130 Clearfog Base"; > + compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1", > + "solidrun,cn9130-sr-som","marvell,cn9130", > + "marvell,armada-ap807-quad", "marvell,armada-ap807"; > + > + gpio-keys { > + compatible = "gpio-keys"; > + pinctrl-0 = <&rear_button_pins>; > + pinctrl-names = "default"; > + > + button-0 { > + /* The rear SW3 button */ > + label = "Rear Button"; > + gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>; > + linux,can-disable; > + linux,code = <BTN_0>; > + }; > + }; > + > + rfkill-m2-gnss { > + compatible = "rfkill-gpio"; > + label = "m.2 GNSS"; > + radio-type = "gps"; > + /* rfkill-gpio inverts internally */ > + shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>; > + }; > + > + /* M.2 is B-keyed, so w-disable is for WWAN */ > + rfkill-m2-wwan { > + compatible = "rfkill-gpio"; > + label = "m.2 WWAN"; > + radio-type = "wwan"; > + /* rfkill-gpio inverts internally */ > + shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>; > + }; > +}; > + > +/* SRDS #3 - SGMII 1GE */ > +&cp0_eth1 { > + phy = <&phy1>; > + phys = <&cp0_comphy3 1>; > + phy-mode = "sgmii"; > + status = "okay"; > +}; > + > +&cp0_eth2_phy { > + /* > + * Configure LEDs: > + * - LED[0]: link/activity: On/blink (green) > + * - LED[1]: link is 100/1000Mbps: On (yellow) > + * - LED[2]: high impedance (floating) > + */ > + marvell,reg-init = <3 16 0xf000 0x0a61>; Sorry, but no. List the LEDs in the PHY node, and they can then be controlled via /sys/class/leds. arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards 2024-03-21 21:59 ` Andrew Lunn @ 2024-03-22 9:54 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-22 9:54 UTC (permalink / raw) To: Andrew Lunn Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 21.03.24 um 22:59 schrieb Andrew Lunn: > On Thu, Mar 21, 2024 at 10:47:12PM +0100, Josua Mayer wrote: >> Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro >> reference boards. >> >> The SoM has been designed as a pin-compatible replacement for the older >> Armada 388 based SoM. Therefore it supports the same boards and a >> similar feature set. >> >> Most notable upgrades: >> - 4x Cortex-A72 >> - 10Gbps SFP >> - Both eMMC and SD supported at the same time >> >> The developer first supporting this product at SolidRun decided to use >> different filenames for the DTBs: Armada 388 uses the full >> "clearfog" string while cn9130 uses the abbreviation "cf". >> This name is already hard-coded in pre-installed vendor u-boot and can >> not be changed easily. >> >> NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: >> CN9130 SoM has a different footprint from Armada 388 SoM. >> Components on the carrier board below the SoM may collide causing >> damage, such as on Clearfog Base. >> >> Signed-off-by: Josua Mayer <josua@solid-run.com> >> --- >> arch/arm64/boot/dts/marvell/Makefile | 2 + >> arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++++ >> arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++++++ >> arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++++++ >> arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 ++++++++++++++++ >> 5 files changed, 747 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile >> index 99b8cb3c49e1..019f2251d696 100644 >> --- a/arch/arm64/boot/dts/marvell/Makefile >> +++ b/arch/arm64/boot/dts/marvell/Makefile >> @@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb >> +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb >> +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb >> diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts >> new file mode 100644 >> index 000000000000..b0067940d5e4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts >> @@ -0,0 +1,138 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> >> + * >> + * DTS for SolidRun CN9130 Clearfog Base. >> + * >> + */ >> + >> +/dts-v1/; >> + >> +#include <dt-bindings/input/input.h> >> + >> +#include "cn9130.dtsi" >> +#include "cn9130-sr-som.dtsi" >> +#include "cn9130-cf.dtsi" >> + >> +/ { >> + model = "SolidRun CN9130 Clearfog Base"; >> + compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1", >> + "solidrun,cn9130-sr-som","marvell,cn9130", >> + "marvell,armada-ap807-quad", "marvell,armada-ap807"; >> + >> + gpio-keys { >> + compatible = "gpio-keys"; >> + pinctrl-0 = <&rear_button_pins>; >> + pinctrl-names = "default"; >> + >> + button-0 { >> + /* The rear SW3 button */ >> + label = "Rear Button"; >> + gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>; >> + linux,can-disable; >> + linux,code = <BTN_0>; >> + }; >> + }; >> + >> + rfkill-m2-gnss { >> + compatible = "rfkill-gpio"; >> + label = "m.2 GNSS"; >> + radio-type = "gps"; >> + /* rfkill-gpio inverts internally */ >> + shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>; >> + }; >> + >> + /* M.2 is B-keyed, so w-disable is for WWAN */ >> + rfkill-m2-wwan { >> + compatible = "rfkill-gpio"; >> + label = "m.2 WWAN"; >> + radio-type = "wwan"; >> + /* rfkill-gpio inverts internally */ >> + shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>; >> + }; >> +}; >> + >> +/* SRDS #3 - SGMII 1GE */ >> +&cp0_eth1 { >> + phy = <&phy1>; >> + phys = <&cp0_comphy3 1>; >> + phy-mode = "sgmii"; >> + status = "okay"; >> +}; >> + >> +&cp0_eth2_phy { >> + /* >> + * Configure LEDs: >> + * - LED[0]: link/activity: On/blink (green) >> + * - LED[1]: link is 100/1000Mbps: On (yellow) >> + * - LED[2]: high impedance (floating) >> + */ >> + marvell,reg-init = <3 16 0xf000 0x0a61>; > Sorry, but no. List the LEDs in the PHY node, and they can then be > controlled via /sys/class/leds. May I ask more precisely the motivation? Does this replace the phy's builtin automatic led control? > arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. I will investigate it. My main motivation for tweaking the led controls was to make them all consistent across the two boards: - LEDs under control of PHYs on cpu mdio bus - LEDs under control of ethernet switch on mdio bus - LEDs under control of ethernet phy on external mdio bus behind ethernet switch It looks as if the marvell phy driver supports led subnodes, The switch driver does not. Finally one phy can only be written to but not read, the cpu can never know its link state. So I prefer (for the Clearfog Pro) board to explicitly use the phys autonomous management of LEDs. Is that still possible if I added led subnodes? ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards @ 2024-03-22 9:54 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-22 9:54 UTC (permalink / raw) To: Andrew Lunn Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 21.03.24 um 22:59 schrieb Andrew Lunn: > On Thu, Mar 21, 2024 at 10:47:12PM +0100, Josua Mayer wrote: >> Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro >> reference boards. >> >> The SoM has been designed as a pin-compatible replacement for the older >> Armada 388 based SoM. Therefore it supports the same boards and a >> similar feature set. >> >> Most notable upgrades: >> - 4x Cortex-A72 >> - 10Gbps SFP >> - Both eMMC and SD supported at the same time >> >> The developer first supporting this product at SolidRun decided to use >> different filenames for the DTBs: Armada 388 uses the full >> "clearfog" string while cn9130 uses the abbreviation "cf". >> This name is already hard-coded in pre-installed vendor u-boot and can >> not be changed easily. >> >> NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: >> CN9130 SoM has a different footprint from Armada 388 SoM. >> Components on the carrier board below the SoM may collide causing >> damage, such as on Clearfog Base. >> >> Signed-off-by: Josua Mayer <josua@solid-run.com> >> --- >> arch/arm64/boot/dts/marvell/Makefile | 2 + >> arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++++ >> arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++++++ >> arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++++++ >> arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 ++++++++++++++++ >> 5 files changed, 747 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile >> index 99b8cb3c49e1..019f2251d696 100644 >> --- a/arch/arm64/boot/dts/marvell/Makefile >> +++ b/arch/arm64/boot/dts/marvell/Makefile >> @@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb >> +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb >> +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb >> diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts >> new file mode 100644 >> index 000000000000..b0067940d5e4 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts >> @@ -0,0 +1,138 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com> >> + * >> + * DTS for SolidRun CN9130 Clearfog Base. >> + * >> + */ >> + >> +/dts-v1/; >> + >> +#include <dt-bindings/input/input.h> >> + >> +#include "cn9130.dtsi" >> +#include "cn9130-sr-som.dtsi" >> +#include "cn9130-cf.dtsi" >> + >> +/ { >> + model = "SolidRun CN9130 Clearfog Base"; >> + compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1", >> + "solidrun,cn9130-sr-som","marvell,cn9130", >> + "marvell,armada-ap807-quad", "marvell,armada-ap807"; >> + >> + gpio-keys { >> + compatible = "gpio-keys"; >> + pinctrl-0 = <&rear_button_pins>; >> + pinctrl-names = "default"; >> + >> + button-0 { >> + /* The rear SW3 button */ >> + label = "Rear Button"; >> + gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>; >> + linux,can-disable; >> + linux,code = <BTN_0>; >> + }; >> + }; >> + >> + rfkill-m2-gnss { >> + compatible = "rfkill-gpio"; >> + label = "m.2 GNSS"; >> + radio-type = "gps"; >> + /* rfkill-gpio inverts internally */ >> + shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>; >> + }; >> + >> + /* M.2 is B-keyed, so w-disable is for WWAN */ >> + rfkill-m2-wwan { >> + compatible = "rfkill-gpio"; >> + label = "m.2 WWAN"; >> + radio-type = "wwan"; >> + /* rfkill-gpio inverts internally */ >> + shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>; >> + }; >> +}; >> + >> +/* SRDS #3 - SGMII 1GE */ >> +&cp0_eth1 { >> + phy = <&phy1>; >> + phys = <&cp0_comphy3 1>; >> + phy-mode = "sgmii"; >> + status = "okay"; >> +}; >> + >> +&cp0_eth2_phy { >> + /* >> + * Configure LEDs: >> + * - LED[0]: link/activity: On/blink (green) >> + * - LED[1]: link is 100/1000Mbps: On (yellow) >> + * - LED[2]: high impedance (floating) >> + */ >> + marvell,reg-init = <3 16 0xf000 0x0a61>; > Sorry, but no. List the LEDs in the PHY node, and they can then be > controlled via /sys/class/leds. May I ask more precisely the motivation? Does this replace the phy's builtin automatic led control? > arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. I will investigate it. My main motivation for tweaking the led controls was to make them all consistent across the two boards: - LEDs under control of PHYs on cpu mdio bus - LEDs under control of ethernet switch on mdio bus - LEDs under control of ethernet phy on external mdio bus behind ethernet switch It looks as if the marvell phy driver supports led subnodes, The switch driver does not. Finally one phy can only be written to but not read, the cpu can never know its link state. So I prefer (for the Clearfog Pro) board to explicitly use the phys autonomous management of LEDs. Is that still possible if I added led subnodes? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards 2024-03-22 9:54 ` Josua Mayer @ 2024-03-22 13:11 ` Andrew Lunn -1 siblings, 0 replies; 48+ messages in thread From: Andrew Lunn @ 2024-03-22 13:11 UTC (permalink / raw) To: Josua Mayer Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel > > Sorry, but no. List the LEDs in the PHY node, and they can then be > > controlled via /sys/class/leds. > May I ask more precisely the motivation? > Does this replace the phy's builtin automatic led control? > > arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. > > I will investigate it. > > My main motivation for tweaking the led controls was to make them all consistent across the two boards: > - LEDs under control of PHYs on cpu mdio bus > - LEDs under control of ethernet switch on mdio bus > - LEDs under control of ethernet phy on external mdio bus behind ethernet switch > > It looks as if the marvell phy driver supports led subnodes, > The switch driver does not. https://lwn.net/Articles/965775/ There has been quite a bit of interest in mv88e6xxx driver support, so i expect support for other families outside of 6352 will be added after it has been merged, and it is not difficult code to write. > Finally one phy can only be written to but not read, > the cpu can never know its link state. O.K. That one cannot use the LED infrastructure in a meaningful way. > So I prefer (for the Clearfog Pro) board to explicitly use the phys > autonomous management of LEDs. > Is that still possible if I added led subnodes? You can combine both. The horrible marvell,reg-init will be applied first. The generic LED code will then take over controlling the LEDs. For the discrete PHYs, the generic LED code can make use of the hardware offload support to read back the hardware configuration and configure itself to match. The switch code is missing hardware offload at the moment. So it cannot read back the current configuration. However, it is simple code to add, and the discrete code is a good example to follow. marvell,reg-init is not going to go away, because of backwards compatibility with old DT blobs. But in general, i expect all vendor proprietary methods of configuring LEDs to be deprecated and replaced with the vendor neutral /sys/class/leds. Andrew ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards @ 2024-03-22 13:11 ` Andrew Lunn 0 siblings, 0 replies; 48+ messages in thread From: Andrew Lunn @ 2024-03-22 13:11 UTC (permalink / raw) To: Josua Mayer Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel > > Sorry, but no. List the LEDs in the PHY node, and they can then be > > controlled via /sys/class/leds. > May I ask more precisely the motivation? > Does this replace the phy's builtin automatic led control? > > arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. > > I will investigate it. > > My main motivation for tweaking the led controls was to make them all consistent across the two boards: > - LEDs under control of PHYs on cpu mdio bus > - LEDs under control of ethernet switch on mdio bus > - LEDs under control of ethernet phy on external mdio bus behind ethernet switch > > It looks as if the marvell phy driver supports led subnodes, > The switch driver does not. https://lwn.net/Articles/965775/ There has been quite a bit of interest in mv88e6xxx driver support, so i expect support for other families outside of 6352 will be added after it has been merged, and it is not difficult code to write. > Finally one phy can only be written to but not read, > the cpu can never know its link state. O.K. That one cannot use the LED infrastructure in a meaningful way. > So I prefer (for the Clearfog Pro) board to explicitly use the phys > autonomous management of LEDs. > Is that still possible if I added led subnodes? You can combine both. The horrible marvell,reg-init will be applied first. The generic LED code will then take over controlling the LEDs. For the discrete PHYs, the generic LED code can make use of the hardware offload support to read back the hardware configuration and configure itself to match. The switch code is missing hardware offload at the moment. So it cannot read back the current configuration. However, it is simple code to add, and the discrete code is a good example to follow. marvell,reg-init is not going to go away, because of backwards compatibility with old DT blobs. But in general, i expect all vendor proprietary methods of configuring LEDs to be deprecated and replaced with the vendor neutral /sys/class/leds. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards 2024-03-22 13:11 ` Andrew Lunn @ 2024-03-22 15:38 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-22 15:38 UTC (permalink / raw) To: Andrew Lunn Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 22.03.24 um 14:11 schrieb Andrew Lunn: >>> Sorry, but no. List the LEDs in the PHY node, and they can then be >>> controlled via /sys/class/leds. >> May I ask more precisely the motivation? >> Does this replace the phy's builtin automatic led control? >>> arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. >> I will investigate it. >> >> My main motivation for tweaking the led controls was to make them all consistent across the two boards: >> - LEDs under control of PHYs on cpu mdio bus >> - LEDs under control of ethernet switch on mdio bus >> - LEDs under control of ethernet phy on external mdio bus behind ethernet switch >> >> It looks as if the marvell phy driver supports led subnodes, >> The switch driver does not. > https://lwn.net/Articles/965775/ Great! > > There has been quite a bit of interest in mv88e6xxx driver support, so > i expect support for other families outside of 6352 will be added > after it has been merged, and it is not difficult code to write. > >> Finally one phy can only be written to but not read, >> the cpu can never know its link state. > O.K. That one cannot use the LED infrastructure in a meaningful way. > >> So I prefer (for the Clearfog Pro) board to explicitly use the phys >> autonomous management of LEDs. >> Is that still possible if I added led subnodes? > You can combine both. The horrible marvell,reg-init will be applied > first. The generic LED code will then take over controlling the LEDs. I (currently) can't put in the led node e.g. linux,default-trigger = "link100|link1000|tx|rx"; Right? > > For the discrete PHYs, the generic LED code can make use of the > hardware offload support to read back the hardware configuration and > configure itself to match. The switch code is missing hardware offload > at the moment. So it cannot read back the current > configuration. However, it is simple code to add, and the discrete > code is a good example to follow. > > marvell,reg-init is not going to go away, because of backwards > compatibility with old DT blobs. But in general, i expect all vendor > proprietary methods of configuring LEDs to be deprecated and replaced > with the vendor neutral /sys/class/leds. Sounds good. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards @ 2024-03-22 15:38 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-22 15:38 UTC (permalink / raw) To: Andrew Lunn Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 22.03.24 um 14:11 schrieb Andrew Lunn: >>> Sorry, but no. List the LEDs in the PHY node, and they can then be >>> controlled via /sys/class/leds. >> May I ask more precisely the motivation? >> Does this replace the phy's builtin automatic led control? >>> arch/arm/boot/dts/marvell/armada-370-rd.dts is an example. >> I will investigate it. >> >> My main motivation for tweaking the led controls was to make them all consistent across the two boards: >> - LEDs under control of PHYs on cpu mdio bus >> - LEDs under control of ethernet switch on mdio bus >> - LEDs under control of ethernet phy on external mdio bus behind ethernet switch >> >> It looks as if the marvell phy driver supports led subnodes, >> The switch driver does not. > https://lwn.net/Articles/965775/ Great! > > There has been quite a bit of interest in mv88e6xxx driver support, so > i expect support for other families outside of 6352 will be added > after it has been merged, and it is not difficult code to write. > >> Finally one phy can only be written to but not read, >> the cpu can never know its link state. > O.K. That one cannot use the LED infrastructure in a meaningful way. > >> So I prefer (for the Clearfog Pro) board to explicitly use the phys >> autonomous management of LEDs. >> Is that still possible if I added led subnodes? > You can combine both. The horrible marvell,reg-init will be applied > first. The generic LED code will then take over controlling the LEDs. I (currently) can't put in the led node e.g. linux,default-trigger = "link100|link1000|tx|rx"; Right? > > For the discrete PHYs, the generic LED code can make use of the > hardware offload support to read back the hardware configuration and > configure itself to match. The switch code is missing hardware offload > at the moment. So it cannot read back the current > configuration. However, it is simple code to add, and the discrete > code is a good example to follow. > > marvell,reg-init is not going to go away, because of backwards > compatibility with old DT blobs. But in general, i expect all vendor > proprietary methods of configuring LEDs to be deprecated and replaced > with the vendor neutral /sys/class/leds. Sounds good. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards 2024-03-22 15:38 ` Josua Mayer @ 2024-03-22 15:49 ` Andrew Lunn -1 siblings, 0 replies; 48+ messages in thread From: Andrew Lunn @ 2024-03-22 15:49 UTC (permalink / raw) To: Josua Mayer Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel > I (currently) can't put in the led node e.g. > linux,default-trigger = "link100|link1000|tx|rx"; > Right? No. The trigger will be 'netdev'. Or 'heartbeat', or 'kbd-numlock'. They are just LEDs, they can be used for anything. While testing some of this code i had the keyboard numlock indicating network packets, since it easier to see than the RJ45 socket... The same applies the other way. The RJ45 LEDs are just Linux LEDs, they can be used for anything... I do have some code adding additional properties for the blink reason. However, it is very debatable if it belongs in DT. DT describes hardware, not configuration of hardware. Do you actually have labels on the case indicating what the LEDs mean? It could be we describe the label, which is hardware, not the configuration of the LED, which is policy from user space. Andrew ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards @ 2024-03-22 15:49 ` Andrew Lunn 0 siblings, 0 replies; 48+ messages in thread From: Andrew Lunn @ 2024-03-22 15:49 UTC (permalink / raw) To: Josua Mayer Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel > I (currently) can't put in the led node e.g. > linux,default-trigger = "link100|link1000|tx|rx"; > Right? No. The trigger will be 'netdev'. Or 'heartbeat', or 'kbd-numlock'. They are just LEDs, they can be used for anything. While testing some of this code i had the keyboard numlock indicating network packets, since it easier to see than the RJ45 socket... The same applies the other way. The RJ45 LEDs are just Linux LEDs, they can be used for anything... I do have some code adding additional properties for the blink reason. However, it is very debatable if it belongs in DT. DT describes hardware, not configuration of hardware. Do you actually have labels on the case indicating what the LEDs mean? It could be we describe the label, which is hardware, not the configuration of the LED, which is policy from user space. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards 2024-03-22 15:49 ` Andrew Lunn @ 2024-03-22 15:58 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-22 15:58 UTC (permalink / raw) To: Andrew Lunn Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 22.03.24 um 16:49 schrieb Andrew Lunn: >> I (currently) can't put in the led node e.g. >> linux,default-trigger = "link100|link1000|tx|rx"; >> Right? > No. The trigger will be 'netdev'. Or 'heartbeat', or > 'kbd-numlock'. OK. > They are just LEDs, they can be used for > anything. While testing some of this code i had the keyboard numlock > indicating network packets, since it easier to see than the RJ45 > socket... The same applies the other way. The RJ45 LEDs are just Linux > LEDs, they can be used for anything... > > I do have some code adding additional properties for the blink > reason. However, it is very debatable if it belongs in DT. DT > describes hardware, not configuration of hardware. > > Do you actually have labels on the case indicating what the LEDs mean? > It could be we describe the label, which is hardware, not the > configuration of the LED, which is policy from user space. I have seen it on customer products, and I have seen it in manuals, and it can help in customer support. Personally I would want it for consistency reasons, so that even if hardware engineers confused 0 and 1 I can ensure consistent behaviour out of the box. It could be the vendor recommended or intended configuration ... ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards @ 2024-03-22 15:58 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-22 15:58 UTC (permalink / raw) To: Andrew Lunn Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 22.03.24 um 16:49 schrieb Andrew Lunn: >> I (currently) can't put in the led node e.g. >> linux,default-trigger = "link100|link1000|tx|rx"; >> Right? > No. The trigger will be 'netdev'. Or 'heartbeat', or > 'kbd-numlock'. OK. > They are just LEDs, they can be used for > anything. While testing some of this code i had the keyboard numlock > indicating network packets, since it easier to see than the RJ45 > socket... The same applies the other way. The RJ45 LEDs are just Linux > LEDs, they can be used for anything... > > I do have some code adding additional properties for the blink > reason. However, it is very debatable if it belongs in DT. DT > describes hardware, not configuration of hardware. > > Do you actually have labels on the case indicating what the LEDs mean? > It could be we describe the label, which is hardware, not the > configuration of the LED, which is policy from user space. I have seen it on customer products, and I have seen it in manuals, and it can help in customer support. Personally I would want it for consistency reasons, so that even if hardware engineers confused 0 and 1 I can ensure consistent behaviour out of the box. It could be the vendor recommended or intended configuration ... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards 2024-03-22 15:38 ` Josua Mayer @ 2024-03-22 18:14 ` Josua Mayer -1 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-22 18:14 UTC (permalink / raw) To: Andrew Lunn Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 22.03.24 um 16:38 schrieb Josua Mayer: > For the discrete PHYs, the generic LED code can make use of the > hardware offload support to read back the hardware configuration and > configure itself to match. The switch code is missing hardware offload > at the moment. So it cannot read back the current > configuration. However, it is simple code to add, and the discrete > code is a good example to follow. I have prototyped this on top of your patch-set, supporting offload for a single mode. It works as explained by you - first after boot-up the LEDs are executing their default function autonomously. When I set trigger netdev, I can see offloaded property is 1, and when I enable extra bits offload turns off. For Clearfog Base I have added the requested LED descriptions, it should be ready now. The Pro version I could 1) submit new version with only phy leds 2) wait (not preferred) 3) submit new version with an separate patch adding switch leds (can hold of ack on it till the fait of your patch-set becomes clear) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards @ 2024-03-22 18:14 ` Josua Mayer 0 siblings, 0 replies; 48+ messages in thread From: Josua Mayer @ 2024-03-22 18:14 UTC (permalink / raw) To: Andrew Lunn Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel Am 22.03.24 um 16:38 schrieb Josua Mayer: > For the discrete PHYs, the generic LED code can make use of the > hardware offload support to read back the hardware configuration and > configure itself to match. The switch code is missing hardware offload > at the moment. So it cannot read back the current > configuration. However, it is simple code to add, and the discrete > code is a good example to follow. I have prototyped this on top of your patch-set, supporting offload for a single mode. It works as explained by you - first after boot-up the LEDs are executing their default function autonomously. When I set trigger netdev, I can see offloaded property is 1, and when I enable extra bits offload turns off. For Clearfog Base I have added the requested LED descriptions, it should be ready now. The Pro version I could 1) submit new version with only phy leds 2) wait (not preferred) 3) submit new version with an separate patch adding switch leds (can hold of ack on it till the fait of your patch-set becomes clear) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards 2024-03-22 18:14 ` Josua Mayer @ 2024-03-22 18:27 ` Andrew Lunn -1 siblings, 0 replies; 48+ messages in thread From: Andrew Lunn @ 2024-03-22 18:27 UTC (permalink / raw) To: Josua Mayer Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On Fri, Mar 22, 2024 at 06:14:38PM +0000, Josua Mayer wrote: > Am 22.03.24 um 16:38 schrieb Josua Mayer: > > For the discrete PHYs, the generic LED code can make use of the > > hardware offload support to read back the hardware configuration and > > configure itself to match. The switch code is missing hardware offload > > at the moment. So it cannot read back the current > > configuration. However, it is simple code to add, and the discrete > > code is a good example to follow. > I have prototyped this on top of your patch-set, supporting offload > for a single mode. > It works as explained by you - first after boot-up the LEDs > are executing their default function autonomously. > > When I set trigger netdev, I can see offloaded property is 1, > and when I enable extra bits offload turns off. > > > For Clearfog Base I have added the requested LED descriptions, > it should be ready now. > > The Pro version I could > 1) submit new version with only phy leds > 2) wait (not preferred) > 3) submit new version with an separate patch adding switch leds > (can hold of ack on it till the fait of your patch-set becomes clear) You probably need to wait whatever. We are in the merge window. Many maintainers don't accept patches during these two weeks. They want you to submit against -rc1 once it is released. And there is no rush. The next merge window is not for another 7 weeks or so. Gregory will accept patches for mvebu for around 5 of those weeks. Andrew ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards @ 2024-03-22 18:27 ` Andrew Lunn 0 siblings, 0 replies; 48+ messages in thread From: Andrew Lunn @ 2024-03-22 18:27 UTC (permalink / raw) To: Josua Mayer Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel On Fri, Mar 22, 2024 at 06:14:38PM +0000, Josua Mayer wrote: > Am 22.03.24 um 16:38 schrieb Josua Mayer: > > For the discrete PHYs, the generic LED code can make use of the > > hardware offload support to read back the hardware configuration and > > configure itself to match. The switch code is missing hardware offload > > at the moment. So it cannot read back the current > > configuration. However, it is simple code to add, and the discrete > > code is a good example to follow. > I have prototyped this on top of your patch-set, supporting offload > for a single mode. > It works as explained by you - first after boot-up the LEDs > are executing their default function autonomously. > > When I set trigger netdev, I can see offloaded property is 1, > and when I enable extra bits offload turns off. > > > For Clearfog Base I have added the requested LED descriptions, > it should be ready now. > > The Pro version I could > 1) submit new version with only phy leds > 2) wait (not preferred) > 3) submit new version with an separate patch adding switch leds > (can hold of ack on it till the fait of your patch-set becomes clear) You probably need to wait whatever. We are in the merge window. Many maintainers don't accept patches during these two weeks. They want you to submit against -rc1 once it is released. And there is no rush. The next merge window is not for another 7 weeks or so. Gregory will accept patches for mvebu for around 5 of those weeks. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2024-03-28 16:22 UTC | newest] Thread overview: 48+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-03-21 21:47 [PATCH 0/2] arm64: dts: add description for solidrun cn9130 som and clearfog boards Josua Mayer 2024-03-21 21:47 ` Josua Mayer 2024-03-21 21:47 ` [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 " Josua Mayer 2024-03-21 21:47 ` Josua Mayer 2024-03-22 2:16 ` Rob Herring 2024-03-22 2:16 ` Rob Herring 2024-03-22 10:08 ` Josua Mayer 2024-03-22 10:08 ` Josua Mayer 2024-03-25 19:34 ` Krzysztof Kozlowski 2024-03-25 19:34 ` Krzysztof Kozlowski 2024-03-25 20:12 ` Josua Mayer 2024-03-25 20:12 ` Josua Mayer 2024-03-26 6:41 ` Krzysztof Kozlowski 2024-03-26 6:41 ` Krzysztof Kozlowski 2024-03-26 19:26 ` Josua Mayer 2024-03-26 19:26 ` Josua Mayer 2024-03-27 10:19 ` Krzysztof Kozlowski 2024-03-27 10:19 ` Krzysztof Kozlowski 2024-03-27 10:55 ` Josua Mayer 2024-03-27 10:55 ` Josua Mayer 2024-03-28 9:14 ` Krzysztof Kozlowski 2024-03-28 9:14 ` Krzysztof Kozlowski 2024-03-28 9:33 ` Josua Mayer 2024-03-28 9:33 ` Josua Mayer 2024-03-28 9:41 ` Krzysztof Kozlowski 2024-03-28 9:41 ` Krzysztof Kozlowski 2024-03-28 9:46 ` Josua Mayer 2024-03-28 9:46 ` Josua Mayer 2024-03-28 16:22 ` Josua Mayer 2024-03-28 16:22 ` Josua Mayer 2024-03-21 21:47 ` [PATCH 2/2] arm64: dts: add description for solidrun cn9130 som and " Josua Mayer 2024-03-21 21:47 ` Josua Mayer 2024-03-21 21:59 ` Andrew Lunn 2024-03-21 21:59 ` Andrew Lunn 2024-03-22 9:54 ` Josua Mayer 2024-03-22 9:54 ` Josua Mayer 2024-03-22 13:11 ` Andrew Lunn 2024-03-22 13:11 ` Andrew Lunn 2024-03-22 15:38 ` Josua Mayer 2024-03-22 15:38 ` Josua Mayer 2024-03-22 15:49 ` Andrew Lunn 2024-03-22 15:49 ` Andrew Lunn 2024-03-22 15:58 ` Josua Mayer 2024-03-22 15:58 ` Josua Mayer 2024-03-22 18:14 ` Josua Mayer 2024-03-22 18:14 ` Josua Mayer 2024-03-22 18:27 ` Andrew Lunn 2024-03-22 18:27 ` Andrew Lunn
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.