arm64: dts: marvell: Externalize PCIe macros from CP11x file

PCIe macros are specific to CP110 and will not fit CP115
constraints. To keep the same way the files are organized, just move
some macros

arm64: dts: marvell: Externalize PCIe macros from CP11x file

PCIe macros are specific to CP110 and will not fit CP115
constraints. To keep the same way the files are organized, just move
some macros out of the CP11x generic file and define them directly in
SoC DTSI, instead of defining single addresses in the SoC DTSI and
reusing them in macros.

In the end:
* CP11X_PCIE_MEM_BASE SoC define is dropped
* CP11X_PCIEx_MEM_BASE is moved out of the generic DT to be put in the
SoC files as it replaces the above definition.
* As the CP11X_PCIEx_MEM_SIZE macro is also subject to change with
newer SoCs, we put it in the SoC files as well.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>

show more ...

arm64: dts: marvell: Drop PCIe I/O ranges from CP11x file

As an example, Armada 70x0 and 80x0 SoC 0xf9000000 region points to
RUNIT/SPICS0 while it is referenced in the DT as PCIe I/O memory
range.

arm64: dts: marvell: Drop PCIe I/O ranges from CP11x file

As an example, Armada 70x0 and 80x0 SoC 0xf9000000 region points to
RUNIT/SPICS0 while it is referenced in the DT as PCIe I/O memory
range. This shows that I/O memory has never been used/working on the
old SoCs despite the region being advertised. As PCIe I/O ranges will
not be supported in newer SoCs using CP11x co-processors, let's
simply drop them. It is not harmful in any case as PCIe device drivers
can do it all with the regular mapped memory anyway.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>

show more ...

arm64: dts: marvell: Prepare the introduction of CP115

CP110 and CP115 are almost the same in terms of features and have a
very limited set of differences. Let's create an armada-cp11x.dtsi
file whi

arm64: dts: marvell: Prepare the introduction of CP115

CP110 and CP115 are almost the same in terms of features and have a
very limited set of differences. Let's create an armada-cp11x.dtsi
file which will be used to instantiate both CP110 and CP115
nodes.

The only changes between the two armada-cp11{0,x}.dtsi files are the
following naming in macros: s/CP110/CP11X/.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>

show more ...

arm64: dts: marvell: use SPDX-License-Identifier for Armada SoCs

Follow the recent trend for the license description, and also fix the
wrongly stated X11 to MIT.

As already pointed on the DT ML, th

arm64: dts: marvell: use SPDX-License-Identifier for Armada SoCs

Follow the recent trend for the license description, and also fix the
wrongly stated X11 to MIT.

As already pointed on the DT ML, the X11 license text [1] is explicitly
for the X Consortium and has a couple of extra clauses. The MIT
license text [2] is actually what the current DT files claim.

[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>

show more ...

arm64: dts: marvell: armada-80x0: Fix pinctrl compatible string

When replacing the cpm by cp0 and cps by cp1 [1] not only the label and
the alias were replaced but also the compatible string which w

arm64: dts: marvell: armada-80x0: Fix pinctrl compatible string

When replacing the cpm by cp0 and cps by cp1 [1] not only the label and
the alias were replaced but also the compatible string which was wrong.

Due to this the pinctrl driver was no more probed.

This patch fix it by reverting this change for the pinctrl compatible
string on Armada 8K.

[1]: "arm64: dts: marvell: replace cpm by cp0, cps by cp1"

Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: replace cpm by cp0, cps by cp1

In preparation for the introduction of more than 2 CPs in upcoming
SoCs, it makes sense to move away from the "CP master" (cpm) and "CP
slave" (cp

arm64: dts: marvell: replace cpm by cp0, cps by cp1

In preparation for the introduction of more than 2 CPs in upcoming
SoCs, it makes sense to move away from the "CP master" (cpm) and "CP
slave" (cps) naming, and use instead cp0/cp1.

This commit is the result of:

sed 's%cpm%cp0g%' arch/arm64/boot/dts/marvell/*
sed 's%cps%cp1g%' arch/arm64/boot/dts/marvell/*

So it is a purely mechaninal change.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Suggested-by: Hanna Hawa <hannah@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: de-duplicate CP110 description

One concept of Marvell Armada 7K/8K SoCs is that they are made of HW
blocks composed of a variety of IPs (network, PCIe, SATA, XOR, SPI,
I2C, etc.

arm64: dts: marvell: de-duplicate CP110 description

One concept of Marvell Armada 7K/8K SoCs is that they are made of HW
blocks composed of a variety of IPs (network, PCIe, SATA, XOR, SPI,
I2C, etc.), and those HW blocks can be duplicated several times within
a given SoC. The Armada 7K SoC has a single CP110 (so no duplication),
while the Armada 8K SoC has two CP110. In the future, SoCs with more
than 2 CP110s will be introduced.

In current kernel versions, the master CP110 is described in
armada-cp110-master.dtsi and the slave CP110 is described in
armada-cp110-slave.dtsi. Those files are basically exactly the same,
since they describe the same hardware. They only have a few
differences:

- Base address of the registers is different for the "config-space"

- Base address of the PCIe registers, MEM, CONF and IO areas were
different

- Labels (and phandles pointing to them) of the nodes were different
("cpm" prefix in the master CP, "cps" prefix in the slave CP)

This duplication issue has been discussed at the DT workshop [1] in
Prague last October, and we presented on this topic [2]. The solution
of using the C pre-processor to avoid this duplication has been
validated by the people present in this DT workshop, and this patch
simply implements what has been presented.

We handle differences between the master CP and slave CP description
using the C pre-processor, by defining a set of macros with different
values armada-cp110.dtsi is included to instantiate one of the master
or slave CP110.

There are a few aspects that deserve additional explanations:

- PCIe needs to be handled separately because it is not part of the
config-space {...} node, since it has registers outside of the
range covered by config-space {...}.

- We need to defined CP110_BASE, CP110_PCIEx_BASE without 0x, because
they are used for the unit address part of some DT nodes. But since
they are also used for the "reg" property of the same nodes, we
have an ADDRESSIFY() macro that prepends 0x to those values.

We compared the resulting .dtb for armada-8040-db.dtb before and after
this patch is applied, and the result is exactly the same, except for
a few differences:

- the SDHCI controller that was only described in the master CP110 is
now also described in the slave CP110. Even though the SDHCI
controller from the slave CP110 is indeed not usable (as it isn't
wired to the outside world) it is technically part of the silicon,
and therefore it is reasonable to also describe it to be part of
the slave CP110. In addition, if we wanted to get this correct for
the SDHCI controller, we should also do it for the NAND controller,
for which the situation is even more complicated: in a single CP110
configuration (Armada 7K), the usable NAND controller is in the
master CP110, while in a dual CP110 configuration (Armada 8K), the
usable NAND controller is in the slave CP110. Since that would add
a lot of additional complexity for no good reason, and since the IP
blocks are in fact really present in both CPs, we simply describe
them in both CPs at the DT level.

- the cp110-master and cp110-slave nodes are now named cpm and
cps. We could have kept cp110-master and cp110-slave, but that
would have required adding another CP110_xyz define, which didn't
seem very useful.

Note that this commit also gets rid of the armada-cp110-master.dtsi
and armada-cp110-slave.dtsi files, as future SoCs will have more than
2 CPs. Instead, we instantiate the CPs directly from the SoC-specific
.dtsi files, i.e armada-70x0.dtsi and armada-80x0.dtsi.

[1] https://elinux.org/Device_tree_kernel_summit_2017_etherpad
[2] https://elinux.org/images/1/14/DTWorkshop2017-duplicate-data.pdf

[gregory.clement@free-electrons.com: add back the "ARM64: dts: marvell:
Fix clock resources for various node" commit]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: use aliases for SPI busses on Armada 7K/8K

We are currently using the cell-index DT property to assign SPI bus
numbers. This property is specific to the spi-orion driver, and
re

arm64: dts: marvell: use aliases for SPI busses on Armada 7K/8K

We are currently using the cell-index DT property to assign SPI bus
numbers. This property is specific to the spi-orion driver, and
requires each SPI controller to have a unique ID defined in the Device
Tree.

As we are about to merge armada-cp110-master.dtsi and
armada-cp110-slave.dtsi into a single file, those cell-index
properties that differ between the master CP110 and the slave CP110
are a difference that would have to be handled.

In order to avoid this, we switch to using the "aliases" DT node to
assign a unique number to each SPI controller. This is more generic,
and directly handled by the SPI core.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: add NAND support on the 8040-DB board

Add NAND support on the Armada-8040-DB by adding the same tree as for
the Armada-7040-DB by using the same compatible string
"marvell,armad

arm64: dts: marvell: add NAND support on the 8040-DB board

Add NAND support on the Armada-8040-DB by adding the same tree as for
the Armada-7040-DB by using the same compatible string
"marvell,armada-8k-nand".

Do not enable the NAND node as enabling it (and changing manually the
proper DPR-76 switch) would disable MDIO from CP1 (and thus disable CPS
Ethernet PHY).

Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: add gpio support for Armada 7K/8K

Enable gpio support for CP and AP on the Marvell Armada 7K/8K SoCs.

The Armada 8K has two CP110 blocks, each having two GPIO controllers.
Howe

arm64: dts: marvell: add gpio support for Armada 7K/8K

Enable gpio support for CP and AP on the Marvell Armada 7K/8K SoCs.

The Armada 8K has two CP110 blocks, each having two GPIO controllers.
However, in each CP110 block, one of the GPIO controller cannot be
used: in the master CP110, only the second GPIO controller can be used,
while on the slave CP110, only the first GPIO controller can be used.

On the other side, the Armada 7K has only one CP110, but both its GPIO
controllers can be used.

For this reason, the GPIO controllers are marked as "disabled" in the
armada-cp110-master.dtsi and armada-cp110-slave.dtsi files, and only
enabled in the per-SoC dtsi files.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: add pinctrl support for Armada 7K/8K

Enable pinctrl support for CP and AP on the Armada 7K/8K SoCs.

The CP master being different between Armada 7k and Armada 8k. This
commit i

arm64: dts: marvell: add pinctrl support for Armada 7K/8K

Enable pinctrl support for CP and AP on the Armada 7K/8K SoCs.

The CP master being different between Armada 7k and Armada 8k. This
commit introduces the intermediates files armada-70x0.dtsi and
armada-80x0.dtsi.

These new files will provide different compatible strings depending of
the SoC family. They will also be the location for the pinmux
configuration at the SoC level.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: Externalize PCIe macros from CP11x file

PCIe macros are specific to CP110 and will not fit CP115
constraints. To keep the same way the files are organized, just move

arm64: dts: marvell: Externalize PCIe macros from CP11x file

PCIe macros are specific to CP110 and will not fit CP115
constraints. To keep the same way the files are organized, just move
some macros out of the CP11x generic file and define them directly in
SoC DTSI, instead of defining single addresses in the SoC DTSI and
reusing them in macros.

In the end:
* CP11X_PCIE_MEM_BASE SoC define is dropped
* CP11X_PCIEx_MEM_BASE is moved out of the generic DT to be put in the
SoC files as it replaces the above definition.
* As the CP11X_PCIEx_MEM_SIZE macro is also subject to change with
newer SoCs, we put it in the SoC files as well.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>

show more ...

arm64: dts: marvell: Drop PCIe I/O ranges from CP11x file

As an example, Armada 70x0 and 80x0 SoC 0xf9000000 region points to
RUNIT/SPICS0 while it is referenced in the DT as PCIe I/O me

arm64: dts: marvell: Drop PCIe I/O ranges from CP11x file

As an example, Armada 70x0 and 80x0 SoC 0xf9000000 region points to
RUNIT/SPICS0 while it is referenced in the DT as PCIe I/O memory
range. This shows that I/O memory has never been used/working on the
old SoCs despite the region being advertised. As PCIe I/O ranges will
not be supported in newer SoCs using CP11x co-processors, let's
simply drop them. It is not harmful in any case as PCIe device drivers
can do it all with the regular mapped memory anyway.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>

show more ...

arm64: dts: marvell: Prepare the introduction of CP115

CP110 and CP115 are almost the same in terms of features and have a
very limited set of differences. Let's create an armada-cp11x.d

arm64: dts: marvell: Prepare the introduction of CP115

CP110 and CP115 are almost the same in terms of features and have a
very limited set of differences. Let's create an armada-cp11x.dtsi
file which will be used to instantiate both CP110 and CP115
nodes.

The only changes between the two armada-cp11{0,x}.dtsi files are the
following naming in macros: s/CP110/CP11X/.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>

show more ...

arm64: dts: marvell: use SPDX-License-Identifier for Armada SoCs

Follow the recent trend for the license description, and also fix the
wrongly stated X11 to MIT.

As already poin

arm64: dts: marvell: use SPDX-License-Identifier for Armada SoCs

Follow the recent trend for the license description, and also fix the
wrongly stated X11 to MIT.

As already pointed on the DT ML, the X11 license text [1] is explicitly
for the X Consortium and has a couple of extra clauses. The MIT
license text [2] is actually what the current DT files claim.

[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>

show more ...

arm64: dts: marvell: armada-80x0: Fix pinctrl compatible string

When replacing the cpm by cp0 and cps by cp1 [1] not only the label and
the alias were replaced but also the compatible st

arm64: dts: marvell: armada-80x0: Fix pinctrl compatible string

When replacing the cpm by cp0 and cps by cp1 [1] not only the label and
the alias were replaced but also the compatible string which was wrong.

Due to this the pinctrl driver was no more probed.

This patch fix it by reverting this change for the pinctrl compatible
string on Armada 8K.

[1]: "arm64: dts: marvell: replace cpm by cp0, cps by cp1"

Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: replace cpm by cp0, cps by cp1

In preparation for the introduction of more than 2 CPs in upcoming
SoCs, it makes sense to move away from the "CP master" (cpm) and "C

arm64: dts: marvell: replace cpm by cp0, cps by cp1

In preparation for the introduction of more than 2 CPs in upcoming
SoCs, it makes sense to move away from the "CP master" (cpm) and "CP
slave" (cps) naming, and use instead cp0/cp1.

This commit is the result of:

sed 's%cpm%cp0g%' arch/arm64/boot/dts/marvell/*
sed 's%cps%cp1g%' arch/arm64/boot/dts/marvell/*

So it is a purely mechaninal change.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Suggested-by: Hanna Hawa <hannah@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: de-duplicate CP110 description

One concept of Marvell Armada 7K/8K SoCs is that they are made of HW
blocks composed of a variety of IPs (network, PCIe, SATA, XOR, SP

arm64: dts: marvell: de-duplicate CP110 description

One concept of Marvell Armada 7K/8K SoCs is that they are made of HW
blocks composed of a variety of IPs (network, PCIe, SATA, XOR, SPI,
I2C, etc.), and those HW blocks can be duplicated several times within
a given SoC. The Armada 7K SoC has a single CP110 (so no duplication),
while the Armada 8K SoC has two CP110. In the future, SoCs with more
than 2 CP110s will be introduced.

In current kernel versions, the master CP110 is described in
armada-cp110-master.dtsi and the slave CP110 is described in
armada-cp110-slave.dtsi. Those files are basically exactly the same,
since they describe the same hardware. They only have a few
differences:

- Base address of the registers is different for the "config-space"

- Base address of the PCIe registers, MEM, CONF and IO areas were
different

- Labels (and phandles pointing to them) of the nodes were different
("cpm" prefix in the master CP, "cps" prefix in the slave CP)

This duplication issue has been discussed at the DT workshop [1] in
Prague last October, and we presented on this topic [2]. The solution
of using the C pre-processor to avoid this duplication has been
validated by the people present in this DT workshop, and this patch
simply implements what has been presented.

We handle differences between the master CP and slave CP description
using the C pre-processor, by defining a set of macros with different
values armada-cp110.dtsi is included to instantiate one of the master
or slave CP110.

There are a few aspects that deserve additional explanations:

- PCIe needs to be handled separately because it is not part of the
config-space {...} node, since it has registers outside of the
range covered by config-space {...}.

- We need to defined CP110_BASE, CP110_PCIEx_BASE without 0x, because
they are used for the unit address part of some DT nodes. But since
they are also used for the "reg" property of the same nodes, we
have an ADDRESSIFY() macro that prepends 0x to those values.

We compared the resulting .dtb for armada-8040-db.dtb before and after
this patch is applied, and the result is exactly the same, except for
a few differences:

- the SDHCI controller that was only described in the master CP110 is
now also described in the slave CP110. Even though the SDHCI
controller from the slave CP110 is indeed not usable (as it isn't
wired to the outside world) it is technically part of the silicon,
and therefore it is reasonable to also describe it to be part of
the slave CP110. In addition, if we wanted to get this correct for
the SDHCI controller, we should also do it for the NAND controller,
for which the situation is even more complicated: in a single CP110
configuration (Armada 7K), the usable NAND controller is in the
master CP110, while in a dual CP110 configuration (Armada 8K), the
usable NAND controller is in the slave CP110. Since that would add
a lot of additional complexity for no good reason, and since the IP
blocks are in fact really present in both CPs, we simply describe
them in both CPs at the DT level.

- the cp110-master and cp110-slave nodes are now named cpm and
cps. We could have kept cp110-master and cp110-slave, but that
would have required adding another CP110_xyz define, which didn't
seem very useful.

Note that this commit also gets rid of the armada-cp110-master.dtsi
and armada-cp110-slave.dtsi files, as future SoCs will have more than
2 CPs. Instead, we instantiate the CPs directly from the SoC-specific
.dtsi files, i.e armada-70x0.dtsi and armada-80x0.dtsi.

[1] https://elinux.org/Device_tree_kernel_summit_2017_etherpad
[2] https://elinux.org/images/1/14/DTWorkshop2017-duplicate-data.pdf

[gregory.clement@free-electrons.com: add back the "ARM64: dts: marvell:
Fix clock resources for various node" commit]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: use aliases for SPI busses on Armada 7K/8K

We are currently using the cell-index DT property to assign SPI bus
numbers. This property is specific to the spi-orion dr

arm64: dts: marvell: use aliases for SPI busses on Armada 7K/8K

We are currently using the cell-index DT property to assign SPI bus
numbers. This property is specific to the spi-orion driver, and
requires each SPI controller to have a unique ID defined in the Device
Tree.

As we are about to merge armada-cp110-master.dtsi and
armada-cp110-slave.dtsi into a single file, those cell-index
properties that differ between the master CP110 and the slave CP110
are a difference that would have to be handled.

In order to avoid this, we switch to using the "aliases" DT node to
assign a unique number to each SPI controller. This is more generic,
and directly handled by the SPI core.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: add NAND support on the 8040-DB board

Add NAND support on the Armada-8040-DB by adding the same tree as for
the Armada-7040-DB by using the same compatible string

arm64: dts: marvell: add NAND support on the 8040-DB board

Add NAND support on the Armada-8040-DB by adding the same tree as for
the Armada-7040-DB by using the same compatible string
"marvell,armada-8k-nand".

Do not enable the NAND node as enabling it (and changing manually the
proper DPR-76 switch) would disable MDIO from CP1 (and thus disable CPS
Ethernet PHY).

Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: add gpio support for Armada 7K/8K

Enable gpio support for CP and AP on the Marvell Armada 7K/8K SoCs.

The Armada 8K has two CP110 blocks, each having two GPIO c

arm64: dts: marvell: add gpio support for Armada 7K/8K

Enable gpio support for CP and AP on the Marvell Armada 7K/8K SoCs.

The Armada 8K has two CP110 blocks, each having two GPIO controllers.
However, in each CP110 block, one of the GPIO controller cannot be
used: in the master CP110, only the second GPIO controller can be used,
while on the slave CP110, only the first GPIO controller can be used.

On the other side, the Armada 7K has only one CP110, but both its GPIO
controllers can be used.

For this reason, the GPIO controllers are marked as "disabled" in the
armada-cp110-master.dtsi and armada-cp110-slave.dtsi files, and only
enabled in the per-SoC dtsi files.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

arm64: dts: marvell: add pinctrl support for Armada 7K/8K

Enable pinctrl support for CP and AP on the Armada 7K/8K SoCs.

The CP master being different between Armada 7k and Armada 8

arm64: dts: marvell: add pinctrl support for Armada 7K/8K

Enable pinctrl support for CP and AP on the Armada 7K/8K SoCs.

The CP master being different between Armada 7k and Armada 8k. This
commit introduces the intermediates files armada-70x0.dtsi and
armada-80x0.dtsi.

These new files will provide different compatible strings depending of
the SoC family. They will also be the location for the pinmux
configuration at the SoC level.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...