* [PATCH v6 0/3] arm64: mvebu: Support for Marvell 98DX2530 (and variants) @ 2022-05-10 23:09 Chris Packham 2022-05-10 23:10 ` [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles Chris Packham ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Chris Packham @ 2022-05-10 23:09 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko Cc: devicetree, linux-kernel, linux-arm-kernel, Chris Packham This series adds support for the Marvell 98DX2530 SoC which is the Control and Management CPU integrated into the AlleyCat5/AlleyCat5X series of Marvell switches. The CPU core is an ARM Cortex-A55 with neon, simd and crypto extensions. This is fairly similar to the Armada-3700 SoC so most of the required peripherals are already supported. This series adds a devicetree and pinctrl driver for the SoC and the RD-AC5X-32G16HVG6HLG reference board. The pinctrl changes from v4 have been picked up and are in linux-next so I haven't included them in this round. That leaves just the dts files and a minor Kconfig update for arm64. Chris Packham (3): dt-bindings: marvell: Document the AC5/AC5X compatibles arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board arm64: marvell: enable the 98DX2530 pinctrl driver .../bindings/arm/marvell/armada-98dx2530.yaml | 27 ++ arch/arm64/Kconfig.platforms | 2 + arch/arm64/boot/dts/marvell/Makefile | 1 + .../boot/dts/marvell/armada-98dx2530.dtsi | 313 ++++++++++++++++++ arch/arm64/boot/dts/marvell/rd-ac5x.dts | 90 +++++ 5 files changed, 433 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml create mode 100644 arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi create mode 100644 arch/arm64/boot/dts/marvell/rd-ac5x.dts -- 2.36.0 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-10 23:09 [PATCH v6 0/3] arm64: mvebu: Support for Marvell 98DX2530 (and variants) Chris Packham @ 2022-05-10 23:10 ` Chris Packham 2022-05-11 16:34 ` Krzysztof Kozlowski 2022-05-11 17:02 ` Andrew Lunn 2022-05-10 23:10 ` [PATCH v6 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board Chris Packham 2022-05-10 23:10 ` [PATCH v6 3/3] arm64: marvell: enable the 98DX2530 pinctrl driver Chris Packham 2 siblings, 2 replies; 18+ messages in thread From: Chris Packham @ 2022-05-10 23:10 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko Cc: devicetree, linux-kernel, linux-arm-kernel, Chris Packham Describe the compatible properties for the Marvell Alleycat5/5X switches with integrated CPUs. Alleycat5: * 98DX2538: 24x1G + 2x10G + 2x10G Stack * 98DX2535: 24x1G + 4x1G Stack * 98DX2532: 8x1G + 2x10G + 2x1G Stack * 98DX2531: 8x1G + 4x1G Stack * 98DX2528: 24x1G + 2x10G + 2x10G Stack * 98DX2525: 24x1G + 4x1G Stack * 98DX2522: 8x1G + 2x10G + 2x1G Stack * 98DX2521: 8x1G + 4x1G Stack * 98DX2518: 24x1G + 2x10G + 2x10G Stack * 98DX2515: 24x1G + 4x1G Stack * 98DX2512: 8x1G + 2x10G + 2x1G Stack * 98DX2511: 8x1G + 4x1G Stack Alleycat5X: * 98DX3500: 24x1G + 6x25G * 98DX3501: 16x1G + 6x10G * 98DX3510: 48x1G + 6x25G * 98DX3520: 24x2.5G + 6x25G * 98DX3530: 48x2.5G + 6x25G * 98DX3540: 12x5G/6x10G + 6x25G * 98DX3550: 24x5G/12x10G + 6x25G Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> --- Notes: Changes in v6: - New .../bindings/arm/marvell/armada-98dx2530.yaml | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml new file mode 100644 index 000000000000..6d9185baf0c5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/marvell/armada-98dx2530.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Alleycat5/5X Platforms + +maintainers: + - Chris Packham <chris.packham@alliedtelesis.co.nz> + +properties: + $nodename: + const: '/' + compatible: + oneOf: + + - description: Alleycat5 (98DX25xx) + items: + - const: marvell,ac5 + + - description: Alleycat5X (98DX35xx) + items: + - const: marvell,ac5x + - const: marvell,ac5 + +additionalProperties: true -- 2.36.0 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-10 23:10 ` [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles Chris Packham @ 2022-05-11 16:34 ` Krzysztof Kozlowski 2022-05-12 1:20 ` Chris Packham 2022-05-11 17:02 ` Andrew Lunn 1 sibling, 1 reply; 18+ messages in thread From: Krzysztof Kozlowski @ 2022-05-11 16:34 UTC (permalink / raw) To: Chris Packham, robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko Cc: devicetree, linux-kernel, linux-arm-kernel On 11/05/2022 01:10, Chris Packham wrote: > Describe the compatible properties for the Marvell Alleycat5/5X switches > with integrated CPUs. > > Alleycat5: > * 98DX2538: 24x1G + 2x10G + 2x10G Stack > * 98DX2535: 24x1G + 4x1G Stack > * 98DX2532: 8x1G + 2x10G + 2x1G Stack > * 98DX2531: 8x1G + 4x1G Stack > * 98DX2528: 24x1G + 2x10G + 2x10G Stack > * 98DX2525: 24x1G + 4x1G Stack > * 98DX2522: 8x1G + 2x10G + 2x1G Stack > * 98DX2521: 8x1G + 4x1G Stack > * 98DX2518: 24x1G + 2x10G + 2x10G Stack > * 98DX2515: 24x1G + 4x1G Stack > * 98DX2512: 8x1G + 2x10G + 2x1G Stack > * 98DX2511: 8x1G + 4x1G Stack > > Alleycat5X: > * 98DX3500: 24x1G + 6x25G > * 98DX3501: 16x1G + 6x10G > * 98DX3510: 48x1G + 6x25G > * 98DX3520: 24x2.5G + 6x25G > * 98DX3530: 48x2.5G + 6x25G > * 98DX3540: 12x5G/6x10G + 6x25G > * 98DX3550: 24x5G/12x10G + 6x25G > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > --- > > Notes: > Changes in v6: > - New > > .../bindings/arm/marvell/armada-98dx2530.yaml | 27 +++++++++++++++++++ > 1 file changed, 27 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml > > diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml > new file mode 100644 > index 000000000000..6d9185baf0c5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml > @@ -0,0 +1,27 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/marvell/armada-98dx2530.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Marvell Alleycat5/5X Platforms > + > +maintainers: > + - Chris Packham <chris.packham@alliedtelesis.co.nz> > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + > + - description: Alleycat5 (98DX25xx) > + items: > + - const: marvell,ac5 This is confusing and does not look correct. The DTS calls AC5 a SoC and you cannot have SoC alone. It's unusable without a SoM or board. > + > + - description: Alleycat5X (98DX35xx) > + items: > + - const: marvell,ac5x > + - const: marvell,ac5 This entry looks correct except ac5x once is called a SoC and once a RD-AC5X board. It cannot be both. Probably you need third compatible, assuming AC5x is a flavor of AC5. items: - enum: - marvell,rd-ac5x - const: marvell,ac5x - const: marvell,ac5 > + > +additionalProperties: true Best regards, Krzysztof ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-11 16:34 ` Krzysztof Kozlowski @ 2022-05-12 1:20 ` Chris Packham 2022-05-12 1:51 ` Chris Packham 2022-05-12 10:10 ` Krzysztof Kozlowski 0 siblings, 2 replies; 18+ messages in thread From: Chris Packham @ 2022-05-12 1:20 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko Cc: devicetree, linux-kernel, linux-arm-kernel On 12/05/22 04:34, Krzysztof Kozlowski wrote: > On 11/05/2022 01:10, Chris Packham wrote: >> Describe the compatible properties for the Marvell Alleycat5/5X switches >> with integrated CPUs. >> >> Alleycat5: >> * 98DX2538: 24x1G + 2x10G + 2x10G Stack >> * 98DX2535: 24x1G + 4x1G Stack >> * 98DX2532: 8x1G + 2x10G + 2x1G Stack >> * 98DX2531: 8x1G + 4x1G Stack >> * 98DX2528: 24x1G + 2x10G + 2x10G Stack >> * 98DX2525: 24x1G + 4x1G Stack >> * 98DX2522: 8x1G + 2x10G + 2x1G Stack >> * 98DX2521: 8x1G + 4x1G Stack >> * 98DX2518: 24x1G + 2x10G + 2x10G Stack >> * 98DX2515: 24x1G + 4x1G Stack >> * 98DX2512: 8x1G + 2x10G + 2x1G Stack >> * 98DX2511: 8x1G + 4x1G Stack >> >> Alleycat5X: >> * 98DX3500: 24x1G + 6x25G >> * 98DX3501: 16x1G + 6x10G >> * 98DX3510: 48x1G + 6x25G >> * 98DX3520: 24x2.5G + 6x25G >> * 98DX3530: 48x2.5G + 6x25G >> * 98DX3540: 12x5G/6x10G + 6x25G >> * 98DX3550: 24x5G/12x10G + 6x25G >> >> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >> --- >> >> Notes: >> Changes in v6: >> - New >> >> .../bindings/arm/marvell/armada-98dx2530.yaml | 27 +++++++++++++++++++ >> 1 file changed, 27 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml >> >> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml >> new file mode 100644 >> index 000000000000..6d9185baf0c5 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml >> @@ -0,0 +1,27 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://scanmail.trustwave.com/?c=20988&d=heX74s-dh8HSCAJmafRigZHOoyY0XQDl80QSCXWitw&u=http%3a%2f%2fdevicetree%2eorg%2fschemas%2farm%2fmarvell%2farmada-98dx2530%2eyaml%23 >> +$schema: http://scanmail.trustwave.com/?c=20988&d=heX74s-dh8HSCAJmafRigZHOoyY0XQDl80oVWnOltA&u=http%3a%2f%2fdevicetree%2eorg%2fmeta-schemas%2fcore%2eyaml%23 >> + >> +title: Marvell Alleycat5/5X Platforms >> + >> +maintainers: >> + - Chris Packham <chris.packham@alliedtelesis.co.nz> >> + >> +properties: >> + $nodename: >> + const: '/' >> + compatible: >> + oneOf: >> + >> + - description: Alleycat5 (98DX25xx) >> + items: >> + - const: marvell,ac5 > This is confusing and does not look correct. The DTS calls AC5 a SoC and > you cannot have SoC alone. It's unusable without a SoM or board. > >> + >> + - description: Alleycat5X (98DX35xx) >> + items: >> + - const: marvell,ac5x >> + - const: marvell,ac5 > This entry looks correct except ac5x once is called a SoC and once a > RD-AC5X board. > > It cannot be both. Probably you need third compatible, assuming AC5x is > a flavor of AC5. Yeah it's a bit confusing RD-AC5X-(bunch of extra numbers and letters) is the board I have. AC5X is a L3 switch chip with integrated CPU. AC5 is a L3 switch chip with integrated CPU. Switch wise the AC5X and AC5 are quite different but the CPU block is the same between the two. > > items: > - enum: > - marvell,rd-ac5x > - const: marvell,ac5x > - const: marvell,ac5 I can go with that but I'm a little vague on what the requirements are. I was trying to follow the armada-7k-8k.yaml as an example. If I look at the cn9130-crb-A board it ends up with: compatible = "marvell,cn9130", "marvell,armada-ap807-quad", "marvell,armada-ap807"; I know the ap807 has something to do with the vagaries of the cn9130 SoC but isn't the "marvell,cn9130" still referring to the SoC. From what you've said shouldn't there be a "marvell,cn9130-crb" somewhere in the mix? Perhaps I've picked a bad example but the other dtbs I've poked at don't have any board binding. >> + >> +additionalProperties: true > > Best regards, > Krzysztof ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-12 1:20 ` Chris Packham @ 2022-05-12 1:51 ` Chris Packham 2022-05-12 14:45 ` Krzysztof Kozlowski 2022-05-12 10:10 ` Krzysztof Kozlowski 1 sibling, 1 reply; 18+ messages in thread From: Chris Packham @ 2022-05-12 1:51 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko Cc: devicetree, linux-kernel, linux-arm-kernel On 12/05/22 13:20, Chris Packham wrote: > > On 12/05/22 04:34, Krzysztof Kozlowski wrote: >> On 11/05/2022 01:10, Chris Packham wrote: >>> Describe the compatible properties for the Marvell Alleycat5/5X >>> switches >>> with integrated CPUs. >>> >>> Alleycat5: >>> * 98DX2538: 24x1G + 2x10G + 2x10G Stack >>> * 98DX2535: 24x1G + 4x1G Stack >>> * 98DX2532: 8x1G + 2x10G + 2x1G Stack >>> * 98DX2531: 8x1G + 4x1G Stack >>> * 98DX2528: 24x1G + 2x10G + 2x10G Stack >>> * 98DX2525: 24x1G + 4x1G Stack >>> * 98DX2522: 8x1G + 2x10G + 2x1G Stack >>> * 98DX2521: 8x1G + 4x1G Stack >>> * 98DX2518: 24x1G + 2x10G + 2x10G Stack >>> * 98DX2515: 24x1G + 4x1G Stack >>> * 98DX2512: 8x1G + 2x10G + 2x1G Stack >>> * 98DX2511: 8x1G + 4x1G Stack >>> >>> Alleycat5X: >>> * 98DX3500: 24x1G + 6x25G >>> * 98DX3501: 16x1G + 6x10G >>> * 98DX3510: 48x1G + 6x25G >>> * 98DX3520: 24x2.5G + 6x25G >>> * 98DX3530: 48x2.5G + 6x25G >>> * 98DX3540: 12x5G/6x10G + 6x25G >>> * 98DX3550: 24x5G/12x10G + 6x25G >>> >>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >>> --- >>> >>> Notes: >>> Changes in v6: >>> - New >>> >>> .../bindings/arm/marvell/armada-98dx2530.yaml | 27 >>> +++++++++++++++++++ >>> 1 file changed, 27 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml >>> >>> diff --git >>> a/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml >>> b/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml >>> new file mode 100644 >>> index 000000000000..6d9185baf0c5 >>> --- /dev/null >>> +++ >>> b/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml >>> @@ -0,0 +1,27 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: >>> http://scanmail.trustwave.com/?c=20988&d=heX74s-dh8HSCAJmafRigZHOoyY0XQDl80QSCXWitw&u=http%3a%2f%2fdevicetree%2eorg%2fschemas%2farm%2fmarvell%2farmada-98dx2530%2eyaml%23 >>> +$schema: >>> http://scanmail.trustwave.com/?c=20988&d=heX74s-dh8HSCAJmafRigZHOoyY0XQDl80oVWnOltA&u=http%3a%2f%2fdevicetree%2eorg%2fmeta-schemas%2fcore%2eyaml%23 >>> + >>> +title: Marvell Alleycat5/5X Platforms >>> + >>> +maintainers: >>> + - Chris Packham <chris.packham@alliedtelesis.co.nz> >>> + >>> +properties: >>> + $nodename: >>> + const: '/' >>> + compatible: >>> + oneOf: >>> + >>> + - description: Alleycat5 (98DX25xx) >>> + items: >>> + - const: marvell,ac5 >> This is confusing and does not look correct. The DTS calls AC5 a SoC and >> you cannot have SoC alone. It's unusable without a SoM or board. >> >>> + >>> + - description: Alleycat5X (98DX35xx) >>> + items: >>> + - const: marvell,ac5x >>> + - const: marvell,ac5 >> This entry looks correct except ac5x once is called a SoC and once a >> RD-AC5X board. >> >> It cannot be both. Probably you need third compatible, assuming AC5x is >> a flavor of AC5. > > Yeah it's a bit confusing > > RD-AC5X-(bunch of extra numbers and letters) is the board I have. > AC5X is a L3 switch chip with integrated CPU. > AC5 is a L3 switch chip with integrated CPU. > > Switch wise the AC5X and AC5 are quite different but the CPU block is > the same between the two. > >> >> items: >> - enum: >> - marvell,rd-ac5x >> - const: marvell,ac5x >> - const: marvell,ac5 > > I can go with that but I'm a little vague on what the requirements > are. I was trying to follow the armada-7k-8k.yaml as an example. > > If I look at the cn9130-crb-A board it ends up with: > > compatible = "marvell,cn9130", "marvell,armada-ap807-quad", > "marvell,armada-ap807"; > > I know the ap807 has something to do with the vagaries of the cn9130 > SoC but isn't the "marvell,cn9130" still referring to the SoC. From > what you've said shouldn't there be a "marvell,cn9130-crb" somewhere > in the mix? > > Perhaps I've picked a bad example but the other dtbs I've poked at > don't have any board binding. > The fsl,imx boards seem like a better example to follow Documentation/devicetree/bindings/arm/fsl.yaml >>> + >>> +additionalProperties: true >> >> Best regards, >> Krzysztof ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-12 1:51 ` Chris Packham @ 2022-05-12 14:45 ` Krzysztof Kozlowski 0 siblings, 0 replies; 18+ messages in thread From: Krzysztof Kozlowski @ 2022-05-12 14:45 UTC (permalink / raw) To: Chris Packham, robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko Cc: devicetree, linux-kernel, linux-arm-kernel On 12/05/2022 03:51, Chris Packham wrote: >> >> I know the ap807 has something to do with the vagaries of the cn9130 >> SoC but isn't the "marvell,cn9130" still referring to the SoC. From >> what you've said shouldn't there be a "marvell,cn9130-crb" somewhere >> in the mix? >> >> Perhaps I've picked a bad example but the other dtbs I've poked at >> don't have any board binding. >> > The fsl,imx boards seem like a better example to follow > Documentation/devicetree/bindings/arm/fsl.yaml Yes. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-12 1:20 ` Chris Packham 2022-05-12 1:51 ` Chris Packham @ 2022-05-12 10:10 ` Krzysztof Kozlowski 1 sibling, 0 replies; 18+ messages in thread From: Krzysztof Kozlowski @ 2022-05-12 10:10 UTC (permalink / raw) To: Chris Packham, robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko, Grzegorz Jaszczyk Cc: devicetree, linux-kernel, linux-arm-kernel On 12/05/2022 03:20, Chris Packham wrote: > > On 12/05/22 04:34, Krzysztof Kozlowski wrote: >> On 11/05/2022 01:10, Chris Packham wrote: >>> Describe the compatible properties for the Marvell Alleycat5/5X switches >>> with integrated CPUs. >>> >>> Alleycat5: >>> * 98DX2538: 24x1G + 2x10G + 2x10G Stack >>> * 98DX2535: 24x1G + 4x1G Stack >>> * 98DX2532: 8x1G + 2x10G + 2x1G Stack >>> * 98DX2531: 8x1G + 4x1G Stack >>> * 98DX2528: 24x1G + 2x10G + 2x10G Stack >>> * 98DX2525: 24x1G + 4x1G Stack >>> * 98DX2522: 8x1G + 2x10G + 2x1G Stack >>> * 98DX2521: 8x1G + 4x1G Stack >>> * 98DX2518: 24x1G + 2x10G + 2x10G Stack >>> * 98DX2515: 24x1G + 4x1G Stack >>> * 98DX2512: 8x1G + 2x10G + 2x1G Stack >>> * 98DX2511: 8x1G + 4x1G Stack >>> >>> Alleycat5X: >>> * 98DX3500: 24x1G + 6x25G >>> * 98DX3501: 16x1G + 6x10G >>> * 98DX3510: 48x1G + 6x25G >>> * 98DX3520: 24x2.5G + 6x25G >>> * 98DX3530: 48x2.5G + 6x25G >>> * 98DX3540: 12x5G/6x10G + 6x25G >>> * 98DX3550: 24x5G/12x10G + 6x25G >>> >>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >>> --- >>> >>> Notes: >>> Changes in v6: >>> - New >>> >>> .../bindings/arm/marvell/armada-98dx2530.yaml | 27 +++++++++++++++++++ >>> 1 file changed, 27 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml >>> new file mode 100644 >>> index 000000000000..6d9185baf0c5 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-98dx2530.yaml >>> @@ -0,0 +1,27 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://scanmail.trustwave.com/?c=20988&d=heX74s-dh8HSCAJmafRigZHOoyY0XQDl80QSCXWitw&u=http%3a%2f%2fdevicetree%2eorg%2fschemas%2farm%2fmarvell%2farmada-98dx2530%2eyaml%23 >>> +$schema: http://scanmail.trustwave.com/?c=20988&d=heX74s-dh8HSCAJmafRigZHOoyY0XQDl80oVWnOltA&u=http%3a%2f%2fdevicetree%2eorg%2fmeta-schemas%2fcore%2eyaml%23 >>> + >>> +title: Marvell Alleycat5/5X Platforms >>> + >>> +maintainers: >>> + - Chris Packham <chris.packham@alliedtelesis.co.nz> >>> + >>> +properties: >>> + $nodename: >>> + const: '/' >>> + compatible: >>> + oneOf: >>> + >>> + - description: Alleycat5 (98DX25xx) >>> + items: >>> + - const: marvell,ac5 >> This is confusing and does not look correct. The DTS calls AC5 a SoC and >> you cannot have SoC alone. It's unusable without a SoM or board. >> >>> + >>> + - description: Alleycat5X (98DX35xx) >>> + items: >>> + - const: marvell,ac5x >>> + - const: marvell,ac5 >> This entry looks correct except ac5x once is called a SoC and once a >> RD-AC5X board. >> >> It cannot be both. Probably you need third compatible, assuming AC5x is >> a flavor of AC5. > > Yeah it's a bit confusing > > RD-AC5X-(bunch of extra numbers and letters) is the board I have. > AC5X is a L3 switch chip with integrated CPU. > AC5 is a L3 switch chip with integrated CPU. > > Switch wise the AC5X and AC5 are quite different but the CPU block is > the same between the two. > >> >> items: >> - enum: >> - marvell,rd-ac5x >> - const: marvell,ac5x >> - const: marvell,ac5 > > I can go with that but I'm a little vague on what the requirements are. > I was trying to follow the armada-7k-8k.yaml as an example. > > If I look at the cn9130-crb-A board it ends up with: > > compatible = "marvell,cn9130", "marvell,armada-ap807-quad", > "marvell,armada-ap807"; > > I know the ap807 has something to do with the vagaries of the cn9130 SoC > but isn't the "marvell,cn9130" still referring to the SoC. From what > you've said shouldn't there be a "marvell,cn9130-crb" somewhere in the mix? > > Perhaps I've picked a bad example but the other dtbs I've poked at don't > have any board binding. The CN9130 looks wrong the same way. They have cn9130.dtsi with "Marvell Armada CN9130 SoC", so it is clearly a SoC. It has its own compatibles. Then this DTSI is included in board DTSes. Till now everything is correct. However the board DTS does not define its own compatible and re-uses SoC compatible, so this is wrong. It seems it was done like this inf commit 6a380172f171 ("dt-bindings: marvell: Declare the CN913x SoC compatibles") . That commit even explains "There are three development boards based on these SoCs:" but then fails to define these boards and instead later everything uses SoC compatibles as board ones! Anyone knowing Marvell HW/architecture could fix it? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-10 23:10 ` [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles Chris Packham 2022-05-11 16:34 ` Krzysztof Kozlowski @ 2022-05-11 17:02 ` Andrew Lunn 2022-05-11 23:14 ` Chris Packham 1 sibling, 1 reply; 18+ messages in thread From: Andrew Lunn @ 2022-05-11 17:02 UTC (permalink / raw) To: Chris Packham Cc: robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, gregory.clement, sebastian.hesselbarth, kostap, robert.marko, devicetree, linux-kernel, linux-arm-kernel On Wed, May 11, 2022 at 11:10:00AM +1200, Chris Packham wrote: > Describe the compatible properties for the Marvell Alleycat5/5X switches > with integrated CPUs. > > Alleycat5: > * 98DX2538: 24x1G + 2x10G + 2x10G Stack > * 98DX2535: 24x1G + 4x1G Stack > * 98DX2532: 8x1G + 2x10G + 2x1G Stack > * 98DX2531: 8x1G + 4x1G Stack > * 98DX2528: 24x1G + 2x10G + 2x10G Stack > * 98DX2525: 24x1G + 4x1G Stack > * 98DX2522: 8x1G + 2x10G + 2x1G Stack > * 98DX2521: 8x1G + 4x1G Stack > * 98DX2518: 24x1G + 2x10G + 2x10G Stack > * 98DX2515: 24x1G + 4x1G Stack > * 98DX2512: 8x1G + 2x10G + 2x1G Stack > * 98DX2511: 8x1G + 4x1G Stack > > Alleycat5X: > * 98DX3500: 24x1G + 6x25G > * 98DX3501: 16x1G + 6x10G > * 98DX3510: 48x1G + 6x25G > * 98DX3520: 24x2.5G + 6x25G > * 98DX3530: 48x2.5G + 6x25G > * 98DX3540: 12x5G/6x10G + 6x25G > * 98DX3550: 24x5G/12x10G + 6x25G Hi Chris When looking at this list, is it just the switch which changes, and everything else in the package stays the same? I'm thinking back to plain Kirkwood. There were 3 Kirkwood SoCs. We had kirkwood.dtsi which described everything common to all three SoCs. And then kirkwood-6192.dtsi, kirkwood-6281.dtsi, kirkwood-6282.dtsi which extended that base with whatever additional things each SoC had. I'm wondering if something similar is needed here? armada-98DX25xx.dtsi which describes everything common to Alleycat5. armada-98DX35xx.dtsi which describes everything common to Alleycat5X, maybe making use of armada-98DX25xx.dtsi?. armada-98DX2538.dtsi which extends armada-98DX25xx.dtsi And then a board file which includes armada-98DX2538.dtsi and add the board specific bits? I've no idea how these different devices differ, so i don't know what the correct hierarchy should be. Andrew ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-11 17:02 ` Andrew Lunn @ 2022-05-11 23:14 ` Chris Packham 2022-05-12 0:27 ` Andrew Lunn 0 siblings, 1 reply; 18+ messages in thread From: Chris Packham @ 2022-05-11 23:14 UTC (permalink / raw) To: Andrew Lunn Cc: robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, gregory.clement, sebastian.hesselbarth, kostap, robert.marko, devicetree, linux-kernel, linux-arm-kernel On 12/05/22 05:02, Andrew Lunn wrote: > On Wed, May 11, 2022 at 11:10:00AM +1200, Chris Packham wrote: >> Describe the compatible properties for the Marvell Alleycat5/5X switches >> with integrated CPUs. >> >> Alleycat5: >> * 98DX2538: 24x1G + 2x10G + 2x10G Stack >> * 98DX2535: 24x1G + 4x1G Stack >> * 98DX2532: 8x1G + 2x10G + 2x1G Stack >> * 98DX2531: 8x1G + 4x1G Stack >> * 98DX2528: 24x1G + 2x10G + 2x10G Stack >> * 98DX2525: 24x1G + 4x1G Stack >> * 98DX2522: 8x1G + 2x10G + 2x1G Stack >> * 98DX2521: 8x1G + 4x1G Stack >> * 98DX2518: 24x1G + 2x10G + 2x10G Stack >> * 98DX2515: 24x1G + 4x1G Stack >> * 98DX2512: 8x1G + 2x10G + 2x1G Stack >> * 98DX2511: 8x1G + 4x1G Stack >> >> Alleycat5X: >> * 98DX3500: 24x1G + 6x25G >> * 98DX3501: 16x1G + 6x10G >> * 98DX3510: 48x1G + 6x25G >> * 98DX3520: 24x2.5G + 6x25G >> * 98DX3530: 48x2.5G + 6x25G >> * 98DX3540: 12x5G/6x10G + 6x25G >> * 98DX3550: 24x5G/12x10G + 6x25G > Hi Chris > > When looking at this list, is it just the switch which changes, and > everything else in the package stays the same? CPU wise I've been told everything is identical. The differences are all in the switch side. > I'm thinking back to plain Kirkwood. There were 3 Kirkwood SoCs. We > had kirkwood.dtsi which described everything common to all three > SoCs. And then kirkwood-6192.dtsi, kirkwood-6281.dtsi, > kirkwood-6282.dtsi which extended that base with whatever additional > things each SoC had. > > I'm wondering if something similar is needed here? > > armada-98DX25xx.dtsi which describes everything common to Alleycat5. > > armada-98DX35xx.dtsi which describes everything common to Alleycat5X, > maybe making use of armada-98DX25xx.dtsi?. Right now there would be no difference between 25xx and 35xx but perhaps having armada-98DX35xx.dtsi just #include armada-98DX25xx.dtsi would make the boards able to pull in something that more naturally fits the actual chip that is used. > armada-98DX2538.dtsi which extends armada-98DX25xx.dtsi There wouldn't be anything to add in 98DX2538 (at least not until we have a proper switchdev driver). > And then a board file which includes armada-98DX2538.dtsi and add the > board specific bits? > > I've no idea how these different devices differ, so i don't know what > the correct hierarchy should be. If you put aside the switch stuff they don't differ at all. Which is a bit different to the 98dx3236/98dx3336/98dx4251 support I added a few years ago where there were differences w.r.t number of CPU cores and the odd peripheral. My main goal has been to get the CPU side stuff landed first. In what I've submitted so far I haven't tried to incorporate the switch register space, that's where you might see some difference like 'compatible = "marvell,prestera-98dx2538", "marvell,prestera";'. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-11 23:14 ` Chris Packham @ 2022-05-12 0:27 ` Andrew Lunn 2022-05-12 0:38 ` Chris Packham 0 siblings, 1 reply; 18+ messages in thread From: Andrew Lunn @ 2022-05-12 0:27 UTC (permalink / raw) To: Chris Packham Cc: robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, gregory.clement, sebastian.hesselbarth, kostap, robert.marko, devicetree, linux-kernel, linux-arm-kernel On Wed, May 11, 2022 at 11:14:25PM +0000, Chris Packham wrote: > > On 12/05/22 05:02, Andrew Lunn wrote: > > On Wed, May 11, 2022 at 11:10:00AM +1200, Chris Packham wrote: > >> Describe the compatible properties for the Marvell Alleycat5/5X switches > >> with integrated CPUs. > >> > >> Alleycat5: > >> * 98DX2538: 24x1G + 2x10G + 2x10G Stack > >> * 98DX2535: 24x1G + 4x1G Stack > >> * 98DX2532: 8x1G + 2x10G + 2x1G Stack > >> * 98DX2531: 8x1G + 4x1G Stack > >> * 98DX2528: 24x1G + 2x10G + 2x10G Stack > >> * 98DX2525: 24x1G + 4x1G Stack > >> * 98DX2522: 8x1G + 2x10G + 2x1G Stack > >> * 98DX2521: 8x1G + 4x1G Stack > >> * 98DX2518: 24x1G + 2x10G + 2x10G Stack > >> * 98DX2515: 24x1G + 4x1G Stack > >> * 98DX2512: 8x1G + 2x10G + 2x1G Stack > >> * 98DX2511: 8x1G + 4x1G Stack > >> > >> Alleycat5X: > >> * 98DX3500: 24x1G + 6x25G > >> * 98DX3501: 16x1G + 6x10G > >> * 98DX3510: 48x1G + 6x25G > >> * 98DX3520: 24x2.5G + 6x25G > >> * 98DX3530: 48x2.5G + 6x25G > >> * 98DX3540: 12x5G/6x10G + 6x25G > >> * 98DX3550: 24x5G/12x10G + 6x25G > > Hi Chris > > > > When looking at this list, is it just the switch which changes, and > > everything else in the package stays the same? > > CPU wise I've been told everything is identical. The differences are all > in the switch side. O.K. That helps a lot with this description. > > armada-98DX2538.dtsi which extends armada-98DX25xx.dtsi > > There wouldn't be anything to add in 98DX2538 (at least not until we > have a proper switchdev driver). Does the switch/SoC have ID registers? For mv88e6xxx, the switch is identified by its ID registers, so we don't have switch specific compatible value in DT. Hopefully it is the same here. All we need to say is that there is a switch in the main .dtsi file, and the .dts file would then indicate which ports are actually used. Andrew ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-12 0:27 ` Andrew Lunn @ 2022-05-12 0:38 ` Chris Packham 2022-05-12 0:45 ` Andrew Lunn 0 siblings, 1 reply; 18+ messages in thread From: Chris Packham @ 2022-05-12 0:38 UTC (permalink / raw) To: Andrew Lunn Cc: robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, gregory.clement, sebastian.hesselbarth, kostap, robert.marko, devicetree, linux-kernel, linux-arm-kernel On 12/05/22 12:27, Andrew Lunn wrote: > On Wed, May 11, 2022 at 11:14:25PM +0000, Chris Packham wrote: >> On 12/05/22 05:02, Andrew Lunn wrote: >>> On Wed, May 11, 2022 at 11:10:00AM +1200, Chris Packham wrote: >>>> Describe the compatible properties for the Marvell Alleycat5/5X switches >>>> with integrated CPUs. >>>> >>>> Alleycat5: >>>> * 98DX2538: 24x1G + 2x10G + 2x10G Stack >>>> * 98DX2535: 24x1G + 4x1G Stack >>>> * 98DX2532: 8x1G + 2x10G + 2x1G Stack >>>> * 98DX2531: 8x1G + 4x1G Stack >>>> * 98DX2528: 24x1G + 2x10G + 2x10G Stack >>>> * 98DX2525: 24x1G + 4x1G Stack >>>> * 98DX2522: 8x1G + 2x10G + 2x1G Stack >>>> * 98DX2521: 8x1G + 4x1G Stack >>>> * 98DX2518: 24x1G + 2x10G + 2x10G Stack >>>> * 98DX2515: 24x1G + 4x1G Stack >>>> * 98DX2512: 8x1G + 2x10G + 2x1G Stack >>>> * 98DX2511: 8x1G + 4x1G Stack >>>> >>>> Alleycat5X: >>>> * 98DX3500: 24x1G + 6x25G >>>> * 98DX3501: 16x1G + 6x10G >>>> * 98DX3510: 48x1G + 6x25G >>>> * 98DX3520: 24x2.5G + 6x25G >>>> * 98DX3530: 48x2.5G + 6x25G >>>> * 98DX3540: 12x5G/6x10G + 6x25G >>>> * 98DX3550: 24x5G/12x10G + 6x25G >>> Hi Chris >>> >>> When looking at this list, is it just the switch which changes, and >>> everything else in the package stays the same? >> CPU wise I've been told everything is identical. The differences are all >> in the switch side. > O.K. That helps a lot with this description. > >>> armada-98DX2538.dtsi which extends armada-98DX25xx.dtsi >> There wouldn't be anything to add in 98DX2538 (at least not until we >> have a proper switchdev driver). > Does the switch/SoC have ID registers? For mv88e6xxx, the switch is > identified by its ID registers, so we don't have switch specific > compatible value in DT. Hopefully it is the same here. All we need to > say is that there is a switch in the main .dtsi file, and the .dts > file would then indicate which ports are actually used. Yes there are registers that you can read to identify the specific chip. It still might be useful to have a expected vs actual check as those ID values are determined by pin strapping resistors. It could also be used to validate the dts (e.g. port 20 would be invalid on a 98DX3501). But those are considerations for further down the track. > Andrew ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-12 0:38 ` Chris Packham @ 2022-05-12 0:45 ` Andrew Lunn 2022-05-12 0:54 ` Chris Packham 0 siblings, 1 reply; 18+ messages in thread From: Andrew Lunn @ 2022-05-12 0:45 UTC (permalink / raw) To: Chris Packham Cc: robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, gregory.clement, sebastian.hesselbarth, kostap, robert.marko, devicetree, linux-kernel, linux-arm-kernel > Yes there are registers that you can read to identify the specific chip. > > It still might be useful to have a expected vs actual check as those ID > values are determined by pin strapping resistors. That i don't get? Can i turn a * 98DX2538: 24x1G + 2x10G + 2x10G Stack into a * 98DX2535: 24x1G + 4x1G Stack by strapping its pin differently? > It could also be used > to validate the dts (e.g. port 20 would be invalid on a 98DX3501). But > those are considerations for further down the track. Yes, that would be up to the switchdev driver to validate the DT based on the ID register. Andrew ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles 2022-05-12 0:45 ` Andrew Lunn @ 2022-05-12 0:54 ` Chris Packham 0 siblings, 0 replies; 18+ messages in thread From: Chris Packham @ 2022-05-12 0:54 UTC (permalink / raw) To: Andrew Lunn Cc: robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, gregory.clement, sebastian.hesselbarth, kostap, robert.marko, devicetree, linux-kernel, linux-arm-kernel On 12/05/22 12:45, Andrew Lunn wrote: >> Yes there are registers that you can read to identify the specific chip. >> >> It still might be useful to have a expected vs actual check as those ID >> values are determined by pin strapping resistors. > That i don't get? Can i turn a > > * 98DX2538: 24x1G + 2x10G + 2x10G Stack > > into a > > * 98DX2535: 24x1G + 4x1G Stack > > by strapping its pin differently? I'm not sure it'd actually work properly but yes there are external PU/PD resistors that if you fitted differently would at least make the ID say that a 98DX2538 is a 98DX2535. The HW docs have these as "reserved" pins that must be pulled up/down depending on the specific part. In reality I suspect that the different serdes arrangements are based on what level of screening the silicon passed (similar to how some SoC speed grades are distinguished). So you might be able to go down (i.e. 2538 -> 2535) but probably not up (i.e 2535 -> 2538). > >> It could also be used >> to validate the dts (e.g. port 20 would be invalid on a 98DX3501). But >> those are considerations for further down the track. > Yes, that would be up to the switchdev driver to validate the DT based > on the ID register. > > Andrew ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v6 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board 2022-05-10 23:09 [PATCH v6 0/3] arm64: mvebu: Support for Marvell 98DX2530 (and variants) Chris Packham 2022-05-10 23:10 ` [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles Chris Packham @ 2022-05-10 23:10 ` Chris Packham 2022-05-11 16:38 ` Krzysztof Kozlowski 2022-05-10 23:10 ` [PATCH v6 3/3] arm64: marvell: enable the 98DX2530 pinctrl driver Chris Packham 2 siblings, 1 reply; 18+ messages in thread From: Chris Packham @ 2022-05-10 23:10 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko Cc: devicetree, linux-kernel, linux-arm-kernel, Chris Packham The 98DX2530 SoC is the Control and Management CPU integrated into the Marvell 98DX25xx and 98DX35xx series of switch chip (internally referred to as AlleyCat5 and AlleyCat5X). These files have been taken from the Marvell SDK and lightly cleaned up with the License and copyright retained. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> --- Notes: The Marvell SDK has a number of new compatible strings. I've brought through some of the drivers or where possible used an in-tree alternative (e.g. there is SDK code for a ac5-gpio but two instances of the existing marvell,orion-gpio seems to cover what is needed if you use an appropriate binding). I expect that there will a new series of patches when I get some different hardware (or additions to this series depending on if/when it lands). Changes in v6: - Move CPU nodes above the SoC (Krzysztof) - Minor formatting clean ups (Krzysztof) - Run through `make dtbs_check` - Move gic nodes inside SoC - Group clocks under a clock node Changes in v5: - add #{address,size}-cells property to i2c nodes - make i2c nodes disabled in the SoC and enable them in the board - add interrupt controller attributes to gpio nodes - Move fixed-clock nodes up a level and remove unnecessary @0 Changes in v4: - use 'phy-handle' instead of 'phy' - move status="okay" on usb nodes to board dts - Add review from Andrew Changes in v3: - Move memory node to board - Use single digit reg value for phy address - Remove MMC node (driver needs work) - Remove syscon & simple-mfd for pinctrl Changes in v2: - Make pinctrl a child node of a syscon node - Use marvell,armada-8k-gpio instead of orion-gpio - Remove nand peripheral. The Marvell SDK does have some changes for the ac5-nand-controller but I currently lack hardware with NAND fitted so I can't test it right now. I've therefore chosen to omit the node and not attempted to bring in the driver or binding. - Remove pcie peripheral. Again there are changes in the SDK and I have no way of testing them. - Remove prestera node. - Remove "marvell,ac5-ehci" compatible from USB node as "marvell,orion-ehci" is sufficient - Remove watchdog node. There is a buggy driver for the ac5 watchdog in the SDK but it needs some work so I've dropped the node for now. arch/arm64/boot/dts/marvell/Makefile | 1 + .../boot/dts/marvell/armada-98dx2530.dtsi | 313 ++++++++++++++++++ arch/arm64/boot/dts/marvell/rd-ac5x.dts | 90 +++++ 3 files changed, 404 insertions(+) create mode 100644 arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi create mode 100644 arch/arm64/boot/dts/marvell/rd-ac5x.dts diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile index 1c794cdcb8e6..3905dee558b4 100644 --- a/arch/arm64/boot/dts/marvell/Makefile +++ b/arch/arm64/boot/dts/marvell/Makefile @@ -24,3 +24,4 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9132-db.dtb dtb-$(CONFIG_ARCH_MVEBU) += cn9132-db-B.dtb dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb +dtb-$(CONFIG_ARCH_MVEBU) += rd-ac5x.dtb diff --git a/arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi b/arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi new file mode 100644 index 000000000000..724e722b4265 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi @@ -0,0 +1,313 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Device Tree For AC5. + * + * Copyright (C) 2021 Marvell + * + */ + +/dts-v1/; + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/interrupt-controller/arm-gic.h> + +/ { + model = "Marvell AC5 SoC"; + compatible = "marvell,ac5"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + aliases { + serial0 = &uart0; + spiflash0 = &spiflash0; + gpio0 = &gpio0; + gpio1 = &gpio1; + ethernet0 = ð0; + ethernet1 = ð1; + }; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + cpu-map { + cluster0 { + core0 { + cpu = <&cpu0>; + }; + core1 { + cpu = <&cpu1>; + }; + }; + }; + + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x0>; + enable-method = "psci"; + next-level-cache = <&l2>; + }; + + cpu1: cpu@1 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0 0x100>; + enable-method = "psci"; + next-level-cache = <&l2>; + }; + + l2: l2-cache { + compatible = "cache"; + }; + }; + + + psci { + compatible = "arm,psci-0.2"; + method = "smc"; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>, + <GIC_PPI 8 IRQ_TYPE_LEVEL_HIGH>, + <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>, + <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <25000000>; + }; + + pmu { + compatible = "arm,armv8-pmuv3"; + interrupts = <GIC_PPI 12 IRQ_TYPE_LEVEL_HIGH>; + }; + + soc { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + dma-ranges; + + internal-regs@7f000000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + /* 16M internal register @ 0x7f00_0000 */ + ranges = <0x0 0x0 0x7f000000 0x1000000>; + dma-coherent; + + uart0: serial@12000 { + compatible = "snps,dw-apb-uart"; + reg = <0x12000 0x100>; + reg-shift = <2>; + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + reg-io-width = <1>; + clock-frequency = <328000000>; + status = "okay"; + }; + + mdio: mdio@22004 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "marvell,orion-mdio"; + reg = <0x22004 0x4>; + clocks = <&core_clock>; + }; + + i2c0: i2c@11000{ + compatible = "marvell,mv78230-i2c"; + reg = <0x11000 0x20>; + #address-cells = <1>; + #size-cells = <0>; + + clocks = <&core_clock>; + clock-names = "core"; + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency=<100000>; + + pinctrl-names = "default", "gpio"; + pinctrl-0 = <&i2c0_pins>; + pinctrl-1 = <&i2c0_gpio>; + scl_gpio = <&gpio0 26 GPIO_ACTIVE_HIGH>; + sda_gpio = <&gpio0 27 GPIO_ACTIVE_HIGH>; + status = "disabled"; + }; + + i2c1: i2c@11100{ + compatible = "marvell,mv78230-i2c"; + reg = <0x11100 0x20>; + #address-cells = <1>; + #size-cells = <0>; + + clocks = <&core_clock>; + clock-names = "core"; + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency=<100000>; + + pinctrl-names = "default", "gpio"; + pinctrl-0 = <&i2c1_pins>; + pinctrl-1 = <&i2c1_gpio>; + scl_gpio = <&gpio0 20 GPIO_ACTIVE_HIGH>; + sda_gpio = <&gpio0 21 GPIO_ACTIVE_HIGH>; + status = "disabled"; + }; + + gpio0: gpio@18100 { + compatible = "marvell,orion-gpio"; + reg = <0x18100 0x40>; + ngpios = <32>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl0 0 0 32>; + marvell,pwm-offset = <0x1f0>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio1: gpio@18140 { + reg = <0x18140 0x40>; + compatible = "marvell,orion-gpio"; + ngpios = <14>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl0 0 32 14>; + marvell,pwm-offset = <0x1f0>; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + + /* + * Dedicated section for devices behind 32bit controllers so we + * can configure specific DMA mapping for them + */ + behind-32bit-controller@7f000000 { + compatible = "simple-bus"; + #address-cells = <0x2>; + #size-cells = <0x2>; + ranges = <0x0 0x0 0x0 0x7f000000 0x0 0x1000000>; + /* Host phy ram starts at 0x200M */ + dma-ranges = <0x0 0x0 0x2 0x0 0x1 0x0>; + dma-coherent; + + eth0: ethernet@20000 { + compatible = "marvell,armada-ac5-neta"; + reg = <0x0 0x20000 0x0 0x4000>; + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&core_clock>; + phy-mode = "sgmii"; + status = "disabled"; + }; + + eth1: ethernet@24000 { + compatible = "marvell,armada-ac5-neta"; + reg = <0x0 0x24000 0x0 0x4000>; + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&core_clock>; + phy-mode = "sgmii"; + status = "disabled"; + }; + + /* A dummy entry used for chipidea phy init */ + usb1phy: usb-phy { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; + }; + + /* USB0 is a host USB */ + usb0: usb@80000 { + compatible = "marvell,orion-ehci"; + reg = <0x0 0x80000 0x0 0x500>; + interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + }; + + /* USB1 is a peripheral USB */ + usb1: usb@a0000 { + reg = <0x0 0xa0000 0x0 0x500>; + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + }; + }; + + pinctrl0: pinctrl@80020100 { + compatible = "marvell,ac5-pinctrl"; + reg = <0 0x80020100 0 0x20>; + + i2c0_pins: i2c0-pins { + marvell,pins = "mpp26", "mpp27"; + marvell,function = "i2c0"; + }; + + i2c0_gpio: i2c0-gpio-pins { + marvell,pins = "mpp26", "mpp27"; + marvell,function = "gpio"; + }; + + i2c1_pins: i2c1-pins { + marvell,pins = "mpp20", "mpp21"; + marvell,function = "i2c1"; + }; + + i2c1_gpio: i2c1-gpio-pins { + marvell,pins = "mpp20", "mpp21"; + marvell,function = "i2c1"; + }; + }; + + spi0: spi@805a0000 { + compatible = "marvell,armada-3700-spi"; + reg = <0x0 0x805a0000 0x0 0x50>; + #address-cells = <0x1>; + #size-cells = <0x0>; + clocks = <&spi_clock>; + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; + num-cs = <1>; + status = "disabled"; + }; + + spi1: spi@805a8000 { + compatible = "marvell,armada-3700-spi"; + reg = <0x0 0x805a8000 0x0 0x50>; + #address-cells = <0x1>; + #size-cells = <0x0>; + clocks = <&spi_clock>; + interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>; + num-cs = <1>; + status = "disabled"; + }; + + gic: interrupt-controller@80600000 { + compatible = "arm,gic-v3"; + #interrupt-cells = <3>; + interrupt-controller; + /*#redistributor-regions = <1>;*/ + redistributor-stride = <0x0 0x20000>; // 128kB stride + reg = <0x0 0x80600000 0x0 0x10000>, /* GICD */ + <0x0 0x80660000 0x0 0x40000>; /* GICR */ + interrupts = <GIC_PPI 6 IRQ_TYPE_LEVEL_HIGH>; + }; + }; + + clocks { + core_clock: core-clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <400000000>; + }; + + axi_clock: axi-clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <325000000>; + }; + + spi_clock: spi-clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <200000000>; + }; + }; +}; diff --git a/arch/arm64/boot/dts/marvell/rd-ac5x.dts b/arch/arm64/boot/dts/marvell/rd-ac5x.dts new file mode 100644 index 000000000000..7ac87413e023 --- /dev/null +++ b/arch/arm64/boot/dts/marvell/rd-ac5x.dts @@ -0,0 +1,90 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Device Tree For AC5X. + * + * Copyright (C) 2021 Marvell + * + */ +/* + * Device Tree file for Marvell Alleycat 5X development board + * This board file supports the B configuration of the board + */ + +/dts-v1/; + +#include "armada-98dx2530.dtsi" + +/ { + model = "Marvell RD-AC5X Board"; + compatible = "marvell,ac5x", "marvell,ac5"; + + memory@0 { + device_type = "memory"; + reg = <0x2 0x00000000 0x0 0x40000000>; + }; +}; + +&mdio { + phy0: ethernet-phy@0 { + reg = <0>; + }; +}; + +&i2c0 { + status = "okay"; +}; + +&i2c1 { + status = "okay"; +}; + +ð0 { + status = "okay"; + phy-handle = <&phy0>; +}; + +&usb0 { + status = "okay"; +}; + +&usb1 { + status = "okay"; +}; + +&spi0 { + status = "okay"; + + spiflash0: flash@0 { + compatible = "jedec,spi-nor"; + spi-max-frequency = <50000000>; + spi-tx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */ + spi-rx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */ + reg = <0>; + + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "spi_flash_part0"; + reg = <0x0 0x800000>; + }; + + parition@1 { + label = "spi_flash_part1"; + reg = <0x800000 0x700000>; + }; + + parition@2 { + label = "spi_flash_part2"; + reg = <0xF00000 0x100000>; + }; + }; +}; + +&usb1 { + compatible = "chipidea,usb2"; + phys = <&usb1phy>; + phy-names = "usb-phy"; + dr_mode = "peripheral"; +}; + -- 2.36.0 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH v6 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board 2022-05-10 23:10 ` [PATCH v6 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board Chris Packham @ 2022-05-11 16:38 ` Krzysztof Kozlowski 2022-05-11 23:49 ` Chris Packham 0 siblings, 1 reply; 18+ messages in thread From: Krzysztof Kozlowski @ 2022-05-11 16:38 UTC (permalink / raw) To: Chris Packham, robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko Cc: devicetree, linux-kernel, linux-arm-kernel On 11/05/2022 01:10, Chris Packham wrote: > The 98DX2530 SoC is the Control and Management CPU integrated into > the Marvell 98DX25xx and 98DX35xx series of switch chip (internally > referred to as AlleyCat5 and AlleyCat5X). > > These files have been taken from the Marvell SDK and lightly cleaned > up with the License and copyright retained. > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > Reviewed-by: Andrew Lunn <andrew@lunn.ch> > --- > > Notes: > The Marvell SDK has a number of new compatible strings. I've brought > through some of the drivers or where possible used an in-tree > alternative (e.g. there is SDK code for a ac5-gpio but two instances of > the existing marvell,orion-gpio seems to cover what is needed if you use > an appropriate binding). I expect that there will a new series of > patches when I get some different hardware (or additions to this series > depending on if/when it lands). > > Changes in v6: > - Move CPU nodes above the SoC (Krzysztof) > - Minor formatting clean ups (Krzysztof) > - Run through `make dtbs_check` > - Move gic nodes inside SoC > - Group clocks under a clock node > Changes in v5: > - add #{address,size}-cells property to i2c nodes > - make i2c nodes disabled in the SoC and enable them in the board > - add interrupt controller attributes to gpio nodes > - Move fixed-clock nodes up a level and remove unnecessary @0 > Changes in v4: > - use 'phy-handle' instead of 'phy' > - move status="okay" on usb nodes to board dts > - Add review from Andrew > Changes in v3: > - Move memory node to board > - Use single digit reg value for phy address > - Remove MMC node (driver needs work) > - Remove syscon & simple-mfd for pinctrl > Changes in v2: > - Make pinctrl a child node of a syscon node > - Use marvell,armada-8k-gpio instead of orion-gpio > - Remove nand peripheral. The Marvell SDK does have some changes for the > ac5-nand-controller but I currently lack hardware with NAND fitted so > I can't test it right now. I've therefore chosen to omit the node and > not attempted to bring in the driver or binding. > - Remove pcie peripheral. Again there are changes in the SDK and I have > no way of testing them. > - Remove prestera node. > - Remove "marvell,ac5-ehci" compatible from USB node as > "marvell,orion-ehci" is sufficient > - Remove watchdog node. There is a buggy driver for the ac5 watchdog in > the SDK but it needs some work so I've dropped the node for now. > > arch/arm64/boot/dts/marvell/Makefile | 1 + > .../boot/dts/marvell/armada-98dx2530.dtsi | 313 ++++++++++++++++++ > arch/arm64/boot/dts/marvell/rd-ac5x.dts | 90 +++++ > 3 files changed, 404 insertions(+) > create mode 100644 arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi > create mode 100644 arch/arm64/boot/dts/marvell/rd-ac5x.dts > > diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile > index 1c794cdcb8e6..3905dee558b4 100644 > --- a/arch/arm64/boot/dts/marvell/Makefile > +++ b/arch/arm64/boot/dts/marvell/Makefile > @@ -24,3 +24,4 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9132-db.dtb > dtb-$(CONFIG_ARCH_MVEBU) += cn9132-db-B.dtb > dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb > dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb > +dtb-$(CONFIG_ARCH_MVEBU) += rd-ac5x.dtb > diff --git a/arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi b/arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi > new file mode 100644 > index 000000000000..724e722b4265 > --- /dev/null > +++ b/arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi > @@ -0,0 +1,313 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > +/* > + * Device Tree For AC5. > + * > + * Copyright (C) 2021 Marvell > + * > + */ > + > +/dts-v1/; > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/interrupt-controller/arm-gic.h> > + > +/ { > + model = "Marvell AC5 SoC"; > + compatible = "marvell,ac5"; > + interrupt-parent = <&gic>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + aliases { > + serial0 = &uart0; > + spiflash0 = &spiflash0; These should be in board DTS, not SoC. https://lore.kernel.org/linux-rockchip/CAK8P3a25iYksubCnQb1-e5yj=crEsK37RB9Hn4ZGZMwcVVrG7g@mail.gmail.com/ > + gpio0 = &gpio0; > + gpio1 = &gpio1; > + ethernet0 = ð0; > + ethernet1 = ð1; (...) > + > + clocks { > + core_clock: core-clock { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <400000000>; > + }; > + > + axi_clock: axi-clock { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <325000000>; > + }; > + > + spi_clock: spi-clock { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <200000000>; > + }; My questions about these clocks are still unanswered. Why do you define fixed-clocks. Aren't these part of clock controller? > + }; > +}; > diff --git a/arch/arm64/boot/dts/marvell/rd-ac5x.dts b/arch/arm64/boot/dts/marvell/rd-ac5x.dts > new file mode 100644 > index 000000000000..7ac87413e023 > --- /dev/null > +++ b/arch/arm64/boot/dts/marvell/rd-ac5x.dts > @@ -0,0 +1,90 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > +/* > + * Device Tree For AC5X. > + * > + * Copyright (C) 2021 Marvell > + * > + */ > +/* > + * Device Tree file for Marvell Alleycat 5X development board > + * This board file supports the B configuration of the board > + */ > + > +/dts-v1/; > + > +#include "armada-98dx2530.dtsi" > + > +/ { > + model = "Marvell RD-AC5X Board"; > + compatible = "marvell,ac5x", "marvell,ac5"; From the bindings I understood ac5x is a SoC, not board. If ac5x is a board, not a SoC, then compatible should be rather "marvell,rd-ac5x". > + > + memory@0 { > + device_type = "memory"; > + reg = <0x2 0x00000000 0x0 0x40000000>; > + }; > +}; > + > +&mdio { > + phy0: ethernet-phy@0 { > + reg = <0>; > + }; > +}; > + > +&i2c0 { > + status = "okay"; > +}; > + > +&i2c1 { > + status = "okay"; > +}; > + > +ð0 { > + status = "okay"; > + phy-handle = <&phy0>; > +}; > + > +&usb0 { > + status = "okay"; > +}; > + > +&usb1 { > + status = "okay"; > +}; > + > +&spi0 { > + status = "okay"; > + > + spiflash0: flash@0 { > + compatible = "jedec,spi-nor"; > + spi-max-frequency = <50000000>; > + spi-tx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */ > + spi-rx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */ > + reg = <0>; > + > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + label = "spi_flash_part0"; > + reg = <0x0 0x800000>; > + }; > + > + parition@1 { > + label = "spi_flash_part1"; > + reg = <0x800000 0x700000>; > + }; > + > + parition@2 { > + label = "spi_flash_part2"; > + reg = <0xF00000 0x100000>; > + }; > + }; > +}; > + > +&usb1 { > + compatible = "chipidea,usb2"; Why compatible is defined per board? > + phys = <&usb1phy>; > + phy-names = "usb-phy"; > + dr_mode = "peripheral"; > +}; > + Best regards, Krzysztof ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board 2022-05-11 16:38 ` Krzysztof Kozlowski @ 2022-05-11 23:49 ` Chris Packham 2022-05-12 14:45 ` Krzysztof Kozlowski 0 siblings, 1 reply; 18+ messages in thread From: Chris Packham @ 2022-05-11 23:49 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko, Vadym Kochan Cc: devicetree, linux-kernel, linux-arm-kernel On 12/05/22 04:38, Krzysztof Kozlowski wrote: > On 11/05/2022 01:10, Chris Packham wrote: >> The 98DX2530 SoC is the Control and Management CPU integrated into >> the Marvell 98DX25xx and 98DX35xx series of switch chip (internally >> referred to as AlleyCat5 and AlleyCat5X). >> >> These files have been taken from the Marvell SDK and lightly cleaned >> up with the License and copyright retained. >> >> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >> Reviewed-by: Andrew Lunn <andrew@lunn.ch> >> --- >> >> Notes: >> The Marvell SDK has a number of new compatible strings. I've brought >> through some of the drivers or where possible used an in-tree >> alternative (e.g. there is SDK code for a ac5-gpio but two instances of >> the existing marvell,orion-gpio seems to cover what is needed if you use >> an appropriate binding). I expect that there will a new series of >> patches when I get some different hardware (or additions to this series >> depending on if/when it lands). >> >> Changes in v6: >> - Move CPU nodes above the SoC (Krzysztof) >> - Minor formatting clean ups (Krzysztof) >> - Run through `make dtbs_check` >> - Move gic nodes inside SoC >> - Group clocks under a clock node >> Changes in v5: >> - add #{address,size}-cells property to i2c nodes >> - make i2c nodes disabled in the SoC and enable them in the board >> - add interrupt controller attributes to gpio nodes >> - Move fixed-clock nodes up a level and remove unnecessary @0 >> Changes in v4: >> - use 'phy-handle' instead of 'phy' >> - move status="okay" on usb nodes to board dts >> - Add review from Andrew >> Changes in v3: >> - Move memory node to board >> - Use single digit reg value for phy address >> - Remove MMC node (driver needs work) >> - Remove syscon & simple-mfd for pinctrl >> Changes in v2: >> - Make pinctrl a child node of a syscon node >> - Use marvell,armada-8k-gpio instead of orion-gpio >> - Remove nand peripheral. The Marvell SDK does have some changes for the >> ac5-nand-controller but I currently lack hardware with NAND fitted so >> I can't test it right now. I've therefore chosen to omit the node and >> not attempted to bring in the driver or binding. >> - Remove pcie peripheral. Again there are changes in the SDK and I have >> no way of testing them. >> - Remove prestera node. >> - Remove "marvell,ac5-ehci" compatible from USB node as >> "marvell,orion-ehci" is sufficient >> - Remove watchdog node. There is a buggy driver for the ac5 watchdog in >> the SDK but it needs some work so I've dropped the node for now. >> >> arch/arm64/boot/dts/marvell/Makefile | 1 + >> .../boot/dts/marvell/armada-98dx2530.dtsi | 313 ++++++++++++++++++ >> arch/arm64/boot/dts/marvell/rd-ac5x.dts | 90 +++++ >> 3 files changed, 404 insertions(+) >> create mode 100644 arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi >> create mode 100644 arch/arm64/boot/dts/marvell/rd-ac5x.dts >> >> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile >> index 1c794cdcb8e6..3905dee558b4 100644 >> --- a/arch/arm64/boot/dts/marvell/Makefile >> +++ b/arch/arm64/boot/dts/marvell/Makefile >> @@ -24,3 +24,4 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9132-db.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += cn9132-db-B.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb >> dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb >> +dtb-$(CONFIG_ARCH_MVEBU) += rd-ac5x.dtb >> diff --git a/arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi b/arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi >> new file mode 100644 >> index 000000000000..724e722b4265 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/marvell/armada-98dx2530.dtsi >> @@ -0,0 +1,313 @@ >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) >> +/* >> + * Device Tree For AC5. >> + * >> + * Copyright (C) 2021 Marvell >> + * >> + */ >> + >> +/dts-v1/; >> + >> +#include <dt-bindings/gpio/gpio.h> >> +#include <dt-bindings/interrupt-controller/arm-gic.h> >> + >> +/ { >> + model = "Marvell AC5 SoC"; >> + compatible = "marvell,ac5"; >> + interrupt-parent = <&gic>; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + >> + aliases { >> + serial0 = &uart0; >> + spiflash0 = &spiflash0; > These should be in board DTS, not SoC. > > https://lore.kernel.org/linux-rockchip/CAK8P3a25iYksubCnQb1-e5yj=crEsK37RB9Hn4ZGZMwcVVrG7g@mail.gmail.com/ Thanks for the reference. Will move. > >> + gpio0 = &gpio0; >> + gpio1 = &gpio1; >> + ethernet0 = ð0; >> + ethernet1 = ð1; > (...) > >> + >> + clocks { >> + core_clock: core-clock { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <400000000>; >> + }; >> + >> + axi_clock: axi-clock { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <325000000>; >> + }; >> + >> + spi_clock: spi-clock { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <200000000>; >> + }; > My questions about these clocks are still unanswered. Why do you define > fixed-clocks. Aren't these part of clock controller? Not one that I have any information on. Marvell don't put it in their customer facing documentation so I can only speculate. The 25MHz oscillator goes into the chip, from there I guess that it is fed in some fashion to both the CPU block (CnM in Marvell speak) and to the switch block. Where exactly it gets divided into these individual peripheral clocks I don't really know. >> + }; >> +}; >> diff --git a/arch/arm64/boot/dts/marvell/rd-ac5x.dts b/arch/arm64/boot/dts/marvell/rd-ac5x.dts >> new file mode 100644 >> index 000000000000..7ac87413e023 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/marvell/rd-ac5x.dts >> @@ -0,0 +1,90 @@ >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) >> +/* >> + * Device Tree For AC5X. >> + * >> + * Copyright (C) 2021 Marvell >> + * >> + */ >> +/* >> + * Device Tree file for Marvell Alleycat 5X development board >> + * This board file supports the B configuration of the board >> + */ >> + >> +/dts-v1/; >> + >> +#include "armada-98dx2530.dtsi" >> + >> +/ { >> + model = "Marvell RD-AC5X Board"; >> + compatible = "marvell,ac5x", "marvell,ac5"; > From the bindings I understood ac5x is a SoC, not board. If ac5x is a > board, not a SoC, then compatible should be rather "marvell,rd-ac5x". So If I understand the convention the full compatible would be: compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5"; > >> + >> + memory@0 { >> + device_type = "memory"; >> + reg = <0x2 0x00000000 0x0 0x40000000>; >> + }; >> +}; >> + >> +&mdio { >> + phy0: ethernet-phy@0 { >> + reg = <0>; >> + }; >> +}; >> + >> +&i2c0 { >> + status = "okay"; >> +}; >> + >> +&i2c1 { >> + status = "okay"; >> +}; >> + >> +ð0 { >> + status = "okay"; >> + phy-handle = <&phy0>; >> +}; >> + >> +&usb0 { >> + status = "okay"; >> +}; >> + >> +&usb1 { >> + status = "okay"; >> +}; >> + >> +&spi0 { >> + status = "okay"; >> + >> + spiflash0: flash@0 { >> + compatible = "jedec,spi-nor"; >> + spi-max-frequency = <50000000>; >> + spi-tx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */ >> + spi-rx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */ >> + reg = <0>; >> + >> + #address-cells = <1>; >> + #size-cells = <1>; >> + >> + partition@0 { >> + label = "spi_flash_part0"; >> + reg = <0x0 0x800000>; >> + }; >> + >> + parition@1 { >> + label = "spi_flash_part1"; >> + reg = <0x800000 0x700000>; >> + }; >> + >> + parition@2 { >> + label = "spi_flash_part2"; >> + reg = <0xF00000 0x100000>; >> + }; >> + }; >> +}; >> + >> +&usb1 { >> + compatible = "chipidea,usb2"; > Why compatible is defined per board? That came from the Marvell SDK. On some boards this is used as a device/OTG interface. But regardless it should have one in the SoC dtsi. As for why they used the "chipidea,usb2" compatible I have no idea. I'll remove this and add the correct compatible to the SoC. >> + phys = <&usb1phy>; >> + phy-names = "usb-phy"; >> + dr_mode = "peripheral"; >> +}; >> + > > Best regards, > Krzysztof ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v6 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board 2022-05-11 23:49 ` Chris Packham @ 2022-05-12 14:45 ` Krzysztof Kozlowski 0 siblings, 0 replies; 18+ messages in thread From: Krzysztof Kozlowski @ 2022-05-12 14:45 UTC (permalink / raw) To: Chris Packham, robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko, Vadym Kochan Cc: devicetree, linux-kernel, linux-arm-kernel On 12/05/2022 01:49, Chris Packham wrote: > >>> + spi_clock: spi-clock { >>> + compatible = "fixed-clock"; >>> + #clock-cells = <0>; >>> + clock-frequency = <200000000>; >>> + }; >> My questions about these clocks are still unanswered. Why do you define >> fixed-clocks. Aren't these part of clock controller? > > Not one that I have any information on. Marvell don't put it in their > customer facing documentation so I can only speculate. The 25MHz > oscillator goes into the chip, from there I guess that it is fed in some > fashion to both the CPU block (CnM in Marvell speak) and to the switch > block. Where exactly it gets divided into these individual peripheral > clocks I don't really know. Hm, so it seems you do not have a proper clock-controller (or cannot create one). OK then, but these are silly stubs, you know. :) > >>> + }; >>> +}; >>> diff --git a/arch/arm64/boot/dts/marvell/rd-ac5x.dts b/arch/arm64/boot/dts/marvell/rd-ac5x.dts >>> new file mode 100644 >>> index 000000000000..7ac87413e023 >>> --- /dev/null >>> +++ b/arch/arm64/boot/dts/marvell/rd-ac5x.dts >>> @@ -0,0 +1,90 @@ >>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) >>> +/* >>> + * Device Tree For AC5X. >>> + * >>> + * Copyright (C) 2021 Marvell >>> + * >>> + */ >>> +/* >>> + * Device Tree file for Marvell Alleycat 5X development board >>> + * This board file supports the B configuration of the board >>> + */ >>> + >>> +/dts-v1/; >>> + >>> +#include "armada-98dx2530.dtsi" >>> + >>> +/ { >>> + model = "Marvell RD-AC5X Board"; >>> + compatible = "marvell,ac5x", "marvell,ac5"; >> From the bindings I understood ac5x is a SoC, not board. If ac5x is a >> board, not a SoC, then compatible should be rather "marvell,rd-ac5x". > > So If I understand the convention the full compatible would be: > > compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5"; Yes, this looks correct. > >> >>> + >>> + memory@0 { >>> + device_type = "memory"; >>> + reg = <0x2 0x00000000 0x0 0x40000000>; >>> + }; >>> +}; >>> + >>> +&mdio { >>> + phy0: ethernet-phy@0 { >>> + reg = <0>; >>> + }; >>> +}; >>> + >>> +&i2c0 { >>> + status = "okay"; >>> +}; >>> + >>> +&i2c1 { >>> + status = "okay"; >>> +}; >>> + >>> +ð0 { >>> + status = "okay"; >>> + phy-handle = <&phy0>; >>> +}; >>> + >>> +&usb0 { >>> + status = "okay"; >>> +}; >>> + >>> +&usb1 { >>> + status = "okay"; >>> +}; >>> + >>> +&spi0 { >>> + status = "okay"; >>> + >>> + spiflash0: flash@0 { >>> + compatible = "jedec,spi-nor"; >>> + spi-max-frequency = <50000000>; >>> + spi-tx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */ >>> + spi-rx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */ >>> + reg = <0>; >>> + >>> + #address-cells = <1>; >>> + #size-cells = <1>; >>> + >>> + partition@0 { >>> + label = "spi_flash_part0"; >>> + reg = <0x0 0x800000>; >>> + }; >>> + >>> + parition@1 { >>> + label = "spi_flash_part1"; >>> + reg = <0x800000 0x700000>; >>> + }; >>> + >>> + parition@2 { >>> + label = "spi_flash_part2"; >>> + reg = <0xF00000 0x100000>; >>> + }; >>> + }; >>> +}; >>> + >>> +&usb1 { >>> + compatible = "chipidea,usb2"; >> Why compatible is defined per board? > > That came from the Marvell SDK. On some boards this is used as a > device/OTG interface. But regardless it should have one in the SoC dtsi. Yes, please. > As for why they used the "chipidea,usb2" compatible I have no idea. I'll > remove this and add the correct compatible to the SoC. They could reuse some other block. Pretty often for such cases there is a dedicated compatible and fallback, e.g.: Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml Best regards, Krzysztof ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v6 3/3] arm64: marvell: enable the 98DX2530 pinctrl driver 2022-05-10 23:09 [PATCH v6 0/3] arm64: mvebu: Support for Marvell 98DX2530 (and variants) Chris Packham 2022-05-10 23:10 ` [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles Chris Packham 2022-05-10 23:10 ` [PATCH v6 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board Chris Packham @ 2022-05-10 23:10 ` Chris Packham 2 siblings, 0 replies; 18+ messages in thread From: Chris Packham @ 2022-05-10 23:10 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, catalin.marinas, will, andrew, gregory.clement, sebastian.hesselbarth, kostap, robert.marko Cc: devicetree, linux-kernel, linux-arm-kernel, Chris Packham This commit makes sure the drivers for the 98DX2530 pin controller is enabled. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> --- Notes: Changes in v6: - New Changes in v5: - None Changes in v4: - None Changes in v3: - Add review from Andrew Changes in v2: - None arch/arm64/Kconfig.platforms | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 30b123cde02c..229571d57496 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -183,11 +183,13 @@ config ARCH_MVEBU select PINCTRL_ARMADA_37XX select PINCTRL_ARMADA_AP806 select PINCTRL_ARMADA_CP110 + select PINCTRL_AC5 help This enables support for Marvell EBU familly, including: - Armada 3700 SoC Family - Armada 7K SoC Family - Armada 8K SoC Family + - 98DX2530 SoC Family config ARCH_MXC bool "ARMv8 based NXP i.MX SoC family" -- 2.36.0 ^ permalink raw reply related [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-05-12 14:46 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-10 23:09 [PATCH v6 0/3] arm64: mvebu: Support for Marvell 98DX2530 (and variants) Chris Packham 2022-05-10 23:10 ` [PATCH v6 1/3] dt-bindings: marvell: Document the AC5/AC5X compatibles Chris Packham 2022-05-11 16:34 ` Krzysztof Kozlowski 2022-05-12 1:20 ` Chris Packham 2022-05-12 1:51 ` Chris Packham 2022-05-12 14:45 ` Krzysztof Kozlowski 2022-05-12 10:10 ` Krzysztof Kozlowski 2022-05-11 17:02 ` Andrew Lunn 2022-05-11 23:14 ` Chris Packham 2022-05-12 0:27 ` Andrew Lunn 2022-05-12 0:38 ` Chris Packham 2022-05-12 0:45 ` Andrew Lunn 2022-05-12 0:54 ` Chris Packham 2022-05-10 23:10 ` [PATCH v6 2/3] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board Chris Packham 2022-05-11 16:38 ` Krzysztof Kozlowski 2022-05-11 23:49 ` Chris Packham 2022-05-12 14:45 ` Krzysztof Kozlowski 2022-05-10 23:10 ` [PATCH v6 3/3] arm64: marvell: enable the 98DX2530 pinctrl driver Chris Packham
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).