2013-08-12 18:47:16

by Sebastian Hesselbarth

Subject: [PATCH 0/9] ARM: dove: DT PCIe support

This patch set adds support for the PCIe controllers found on Marvell
Dove SoCs. It depends on mvebu-pci patches sent by Thomas Petazzoni.
Also, it adds support for the Globalscale D3Plug - a Dove based board
comprising a USB3.0 dual port controller and a mini-PCIe port. The
mini-PCIe port has not been tested, but USB controller and attached
USB stick has been detected.

The patch set can be separated into two main parts and should be
taken by the respective maintainers. First five patches belong to
PCI driver for MVEBU SoCs, while last four patches are Marvell Dove
related. It is based on (unstable) mvebu/for-next branch with MSI
patches applied and will be rebased on request.

Devicetree and Doc MLs are not Cc'ed for the driver-only patches,
PCI ML and maintainer are not Cc'ed for the Dove-only patches.

Patches 1 and 2 fix some minor issues with pci-mvebu by moving
clk_prepare_enable before accessing any controller registers and
counting sucessfully registered ports only.

Patch 3 converts pci-mvebu from subsys_initcall registration to
normal platform driver registration to allow it to fail with
EPROBE_DEFER later.

Patch 4 adds DT parsing for reset (PERST#) GPIO pins and delay to
wait for PCIe devices after reset de-assertion.

Patch 5 finally adds a compatible to pci-mvebu for Dove SoCs.

Patch 6 updates dove_defconfig with some useful options for the
Si5351 i2c clock generator found on SolidRun CuBox, PCIe driver,
and USB3.0 xHCI driver.

Patches 7 and 8 add PCIe controller nodes to Dove SoC DT and
add support for the Globalscale D3Plug where this patches have
been tested on.

Patch 8 finally removes legacy PCIe driver init and clock
gate workarounds from DT based Dove init.

Sebastian Hesselbarth (9):
PCI: mvebu: move clock enable before register access
PCI: mvebu: increment nports only for registered ports
PCI: mvebu: remove subsys_initcall
PCI: mvebu: add support for reset on GPIO
PCI: mvebu: add support for Marvell Dove SoCs
ARM: dove: update dove_defconfig with SI5351, PCI, and xHCI
ARM: dove: add PCIe controllers to SoC DT
ARM: dove: add initial DT file for Globalscale D3Plug
ARM: dove: remove legacy pcie and clock init

.../devicetree/bindings/pci/mvebu-pci.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/dove-d3plug.dts | 103 ++++++++++++++++++
arch/arm/boot/dts/dove.dtsi | 54 ++++++++++
arch/arm/configs/dove_defconfig | 4 +
arch/arm/mach-dove/board-dt.c | 29 -----
drivers/pci/host/Kconfig | 2 +-
drivers/pci/host/pci-mvebu.c | 113 +++++++++++++-------
8 files changed, 241 insertions(+), 68 deletions(-)
create mode 100644 arch/arm/boot/dts/dove-d3plug.dts
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
--
1.7.10.4

2013-08-12 18:47:13

by Sebastian Hesselbarth

Subject: [PATCH 3/9] PCI: mvebu: remove subsys_initcall

This removes the subsys_initcall from the driver and converts it to
a normal platform_driver. Also, drvdata is set and a remove functions
is added to disable the clock and free resources.

Signed-off-by: Sebastian Hesselbarth <[email protected]>
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
drivers/pci/host/pci-mvebu.c | 46 +++++++++++++++++++++++++-----------------
1 file changed, 27 insertions(+), 19 deletions(-)

diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 0a359d7..2370b59 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -165,7 +165,7 @@ static void mvebu_pcie_set_local_dev_nr(struct mvebu_pcie_port *port, int nr)
* BAR[0,2] -> disabled, BAR[1] -> covers all DRAM banks
* WIN[0-3] -> DRAM bank[0-3]
*/
-static void __init mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
+static void mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
{
const struct mbus_dram_target_info *dram;
u32 size;
@@ -217,7 +217,7 @@ static void __init mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
port->base + PCIE_BAR_CTRL_OFF(1));
}

-static void __init mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
+static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
{
u16 cmd;
u32 mask;
@@ -628,7 +628,7 @@ static struct pci_ops mvebu_pcie_ops = {
.write = mvebu_pcie_wr_conf,
};

-static int __init mvebu_pcie_setup(int nr, struct pci_sys_data *sys)
+static int mvebu_pcie_setup(int nr, struct pci_sys_data *sys)
{
struct mvebu_pcie *pcie = sys_to_pcie(sys);
int i;
@@ -647,7 +647,7 @@ static int __init mvebu_pcie_setup(int nr, struct pci_sys_data *sys)
return 1;
}

-static int __init mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
struct of_irq oirq;
int ret;
@@ -704,7 +704,7 @@ resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
return start;
}

-static void __init mvebu_pcie_enable(struct mvebu_pcie *pcie)
+static void mvebu_pcie_enable(struct mvebu_pcie *pcie)
{
struct hw_pci hw;

@@ -727,10 +727,8 @@ static void __init mvebu_pcie_enable(struct mvebu_pcie *pcie)
* <...> property for one that matches the given port/lane. Once
* found, maps it.
*/
-static void __iomem * __init
-mvebu_pcie_map_registers(struct platform_device *pdev,
- struct device_node *np,
- struct mvebu_pcie_port *port)
+static void __iomem *mvebu_pcie_map_registers(struct platform_device *pdev,
+ struct device_node *np, struct mvebu_pcie_port *port)
{
struct resource regs;
int ret = 0;
@@ -786,7 +784,7 @@ static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
return -ENOENT;
}

-static void __init mvebu_pcie_msi_enable(struct mvebu_pcie *pcie)
+static void mvebu_pcie_msi_enable(struct mvebu_pcie *pcie)
{
struct device_node *msi_node;

@@ -801,7 +799,7 @@ static void __init mvebu_pcie_msi_enable(struct mvebu_pcie *pcie)
pcie->msi->dev = &pcie->pdev->dev;
}

-static int __init mvebu_pcie_probe(struct platform_device *pdev)
+static int mvebu_pcie_probe(struct platform_device *pdev)
{
struct mvebu_pcie *pcie;
struct device_node *np = pdev->dev.of_node;
@@ -814,6 +812,7 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
return -ENOMEM;

pcie->pdev = pdev;
+ platform_set_drvdata(pdev, pcie);

/* Get the PCIe memory and I/O aperture */
mvebu_mbus_get_pcie_mem_aperture(&pcie->mem);
@@ -939,6 +938,20 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
return 0;
}

+static int mvebu_pcie_remove(struct platform_device *pdev)
+{
+ struct mvebu_pcie *pcie = platform_get_drvdata(pdev);
+ struct mvebu_pcie_port *port = &pcie->ports[0];
+ int i;
+
+ for (i = 0; i < pcie->nports; i++, port++) {
+ clk_disable_unprepare(port->clk);
+ kfree(port->name);
+ }
+
+ return 0;
+}
+
static const struct of_device_id mvebu_pcie_of_match_table[] = {
{ .compatible = "marvell,armada-xp-pcie", },
{ .compatible = "marvell,armada-370-pcie", },
@@ -954,15 +967,10 @@ static struct platform_driver mvebu_pcie_driver = {
.of_match_table =
of_match_ptr(mvebu_pcie_of_match_table),
},
+ .probe = mvebu_pcie_probe,
+ .remove = mvebu_pcie_remove,
};
-
-static int __init mvebu_pcie_init(void)
-{
- return platform_driver_probe(&mvebu_pcie_driver,
- mvebu_pcie_probe);
-}
-
-subsys_initcall(mvebu_pcie_init);
+module_platform_driver(mvebu_pcie_driver);

MODULE_AUTHOR("Thomas Petazzoni <[email protected]>");
MODULE_DESCRIPTION("Marvell EBU PCIe driver");
--
1.7.10.4

2013-08-12 18:47:08

by Sebastian Hesselbarth

Subject: [PATCH 1/9] PCI: mvebu: move clock enable before register access

The clock passed to PCI controller found on MVEBU SoCs may come from a
clock gate. This requires the clock to be enabled before any registers
are accessed. Therefore, move the clock enable before register iomap to
ensure it is enabled.

Signed-off-by: Sebastian Hesselbarth <[email protected]>
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
drivers/pci/host/pci-mvebu.c | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 6aa0daf..d5fe674 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -897,6 +897,16 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
continue;
}

+ port->clk = of_clk_get_by_name(child, NULL);
+ if (IS_ERR(port->clk)) {
+ dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n",
+ port->port, port->lane);
+ iounmap(port->base);
+ port->haslink = 0;
+ continue;
+ }
+ clk_prepare_enable(port->clk);
+
port->base = mvebu_pcie_map_registers(pdev, child, port);
if (!port->base) {
dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
@@ -916,22 +926,9 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
port->port, port->lane);
}

- port->clk = of_clk_get_by_name(child, NULL);
- if (IS_ERR(port->clk)) {
- dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n",
- port->port, port->lane);
- iounmap(port->base);
- port->haslink = 0;
- continue;
- }
-
port->dn = child;
-
- clk_prepare_enable(port->clk);
spin_lock_init(&port->conf_lock);
-
mvebu_sw_pci_bridge_init(port);
-
i++;
}

--
1.7.10.4

2013-08-12 18:47:10

by Sebastian Hesselbarth

Subject: [PATCH 2/9] PCI: mvebu: increment nports only for registered ports

The number of ports is probed by counting the number of available child nodes.
Later on, the registration of a port can fail and cause a mismatch between
the ->nports counter and registered ports. This patch modifies the counting
strategy, to make ->nports represent the number of registered ports instead
of the number of available childs.

Signed-off-by: Sebastian Hesselbarth <[email protected]>
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
drivers/pci/host/pci-mvebu.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index d5fe674..0a359d7 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -842,21 +842,21 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
return ret;
}

+ i = 0;
for_each_child_of_node(pdev->dev.of_node, child) {
if (!of_device_is_available(child))
continue;
- pcie->nports++;
+ i++;
}

- pcie->ports = devm_kzalloc(&pdev->dev, pcie->nports *
+ pcie->ports = devm_kzalloc(&pdev->dev, i *
sizeof(struct mvebu_pcie_port),
GFP_KERNEL);
if (!pcie->ports)
return -ENOMEM;

- i = 0;
for_each_child_of_node(pdev->dev.of_node, child) {
- struct mvebu_pcie_port *port = &pcie->ports[i];
+ struct mvebu_pcie_port *port = &pcie->ports[pcie->nports];

if (!of_device_is_available(child))
continue;
@@ -929,7 +929,7 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
port->dn = child;
spin_lock_init(&port->conf_lock);
mvebu_sw_pci_bridge_init(port);
- i++;
+ pcie->nports++;
}

mvebu_pcie_msi_enable(pcie);
--
1.7.10.4

2013-08-12 18:47:58

by Sebastian Hesselbarth

Subject: [PATCH 7/9] ARM: dove: add PCIe controllers to SoC DT

This adds a node for the pcie controllers found on Dove SoCs to the
SoC DT include.

Signed-off-by: Sebastian Hesselbarth <[email protected]>
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
arch/arm/boot/dts/dove.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index d42b323..499abad 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -44,6 +44,60 @@
MBUS_ID(0x03, 0x01) 0 0xc8000000 0x0100000 /* CESA SRAM 1M */
MBUS_ID(0x0d, 0x00) 0 0xf0000000 0x0100000>; /* PMU SRAM 1M */

+ pcie: pcie-controller {
+ compatible = "marvell,dove-pcie";
+ status = "disabled";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ msi-parent = <&intc>;
+ bus-range = <0x00 0xff>;
+
+ ranges = <0x82000000 0x0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x2000
+ 0x82000000 0x0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x2000
+ 0x82000000 0x1 0x0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 Mem */
+ 0x81000000 0x1 0x0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 I/O */
+ 0x82000000 0x2 0x0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 Mem */
+ 0x81000000 0x2 0x0 MBUS_ID(0x08, 0xe0) 0 1 0>; /* Port 1.0 I/O */
+
+ pcie-port@0 {
+ device_type = "pci";
+ status = "disabled";
+ assigned-addresses = <0x82000800 0 0x40000 0 0x2000>;
+ reg = <0x0800 0 0 0 0>;
+ clocks = <&gate_clk 4>;
+ marvell,pcie-port = <0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
+ 0x81000000 0 0 0x81000000 0x1 0 1 0>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &intc 16>;
+ };
+
+ pcie-port@1 {
+ device_type = "pci";
+ status = "disabled";
+ assigned-addresses = <0x82002800 0 0x80000 0 0x2000>;
+ reg = <0x1000 0 0 0 0>;
+ clocks = <&gate_clk 5>;
+ marvell,pcie-port = <1>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+ 0x81000000 0 0 0x81000000 0x2 0 1 0>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &intc 18>;
+ };
+ };
+
internal-regs {
compatible = "simple-bus";
#address-cells = <1>;
--
1.7.10.4

2013-08-12 18:48:02

by Sebastian Hesselbarth

Subject: [PATCH 8/9] ARM: dove: add initial DT file for Globalscale D3Plug

This adds an initial DT file for the Globalscale D3Plug with Dove SoC.

Signed-off-by: Sebastian Hesselbarth <[email protected]>
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/dove-d3plug.dts | 103 +++++++++++++++++++++++++++++++++++++
2 files changed, 104 insertions(+)
create mode 100644 arch/arm/boot/dts/dove-d3plug.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 984a997..ffb361c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
dove-cubox.dtb \
dove-d2plug.dtb \
+ dove-d3plug.dtb \
dove-dove-db.dtb
dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
diff --git a/arch/arm/boot/dts/dove-d3plug.dts b/arch/arm/boot/dts/dove-d3plug.dts
new file mode 100644
index 0000000..ead90eb
--- /dev/null
+++ b/arch/arm/boot/dts/dove-d3plug.dts
@@ -0,0 +1,103 @@
+/dts-v1/;
+
+#include "dove.dtsi"
+
+/ {
+ model = "Globalscale D3Plug";
+ compatible = "globalscale,d3plug", "marvell,dove";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 earlyprintk root=/dev/mmcblk0p2 rw rootwait";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&pmx_gpio_0 &pmx_gpio_1 &pmx_gpio_2>;
+ pinctrl-names = "default";
+
+ wlan-act {
+ label = "wlan-act";
+ gpios = <&gpio0 0 1>;
+ };
+
+ wlan-ap {
+ label = "wlan-ap";
+ gpios = <&gpio0 1 1>;
+ };
+
+ status {
+ label = "status";
+ gpios = <&gpio0 2 1>;
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb_power: regulator@1 {
+ compatible = "regulator-fixed";
+ reg = <1>;
+ regulator-name = "USB Power";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = <&gpio0 8 0>;
+ pinctrl-0 = <&pmx_gpio_8>;
+ pinctrl-names = "default";
+ };
+ };
+};
+
+&uart0 { status = "okay"; };
+&sata0 { status = "okay"; };
+&i2c0 { status = "okay"; };
+
+/* Samsung M8G2F eMMC */
+&sdio0 {
+ status = "okay";
+ non-removable;
+ bus-width = <4>;
+};
+
+/* Marvell SD8787 WLAN/BT */
+&sdio1 {
+ status = "okay";
+ non-removable;
+};
+
+&spi0 {
+ status = "okay";
+
+ /* spi0.0: 2M Flash Macronix MX25L1605D */
+ spi-flash@0 {
+ compatible = "st,m25l1605d";
+ spi-max-frequency = <86000000>;
+ reg = <0>;
+ };
+};
+
+&pcie {
+ status = "okay";
+ /* Fresco Logic USB3.0 xHCI controller */
+ pcie-port@0 {
+ status = "okay";
+ reset-gpios = <&gpio0 26 1>;
+ reset-delay-ms = <20>;
+ pinctrl-0 = <&pmx_camera_gpio>;
+ pinctrl-names = "default";
+ };
+ /* Mini-PCIe slot */
+ pcie-port@1 {
+ status = "okay";
+ reset-gpios = <&gpio0 25 1>;
+ };
+};
--
1.7.10.4

2013-08-12 18:48:10

by Sebastian Hesselbarth

Subject: [PATCH 5/9] PCI: mvebu: add support for Marvell Dove SoCs

This patch adds a compatible for the PCIe controller found on Marvell
Dove SoCs. Binding documentation and Kconfig entry are also updated.

Signed-off-by: Sebastian Hesselbarth <[email protected]>
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
drivers/pci/host/Kconfig | 2 +-
drivers/pci/host/pci-mvebu.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index f2fa261..cf470a9 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -5,6 +5,7 @@ Mandatory properties:
- compatible: one of the following values:
marvell,armada-370-pcie
marvell,armada-xp-pcie
+ marvell,dove-pcie
marvell,kirkwood-pcie
- #address-cells, set to <3>
- #size-cells, set to <2>
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 1184ff6..492eec9 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -3,7 +3,7 @@ menu "PCI host controller drivers"

config PCI_MVEBU
bool "Marvell EBU PCIe controller"
- depends on ARCH_MVEBU || ARCH_KIRKWOOD
+ depends on ARCH_MVEBU || ARCH_DOVE || ARCH_KIRKWOOD

config PCIE_DW
bool
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index bdad4d4..b204c1d 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -986,6 +986,7 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
static const struct of_device_id mvebu_pcie_of_match_table[] = {
{ .compatible = "marvell,armada-xp-pcie", },
{ .compatible = "marvell,armada-370-pcie", },
+ { .compatible = "marvell,dove-pcie", },
{ .compatible = "marvell,kirkwood-pcie", },
{},
};
--
1.7.10.4

2013-08-12 18:48:07

by Sebastian Hesselbarth

Subject: [PATCH 6/9] ARM: dove: update dove_defconfig with SI5351, PCI, and xHCI

This adds SI5351 clock driver found on the SolidRun CuBox, PCI driver
and USB 3.0 xHCI driver found on the Globalscale D3Plug to dove_defconfig.

Signed-off-by: Sebastian Hesselbarth <[email protected]>
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
arch/arm/configs/dove_defconfig | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/dove_defconfig b/arch/arm/configs/dove_defconfig
index 4364eff..1101054 100644
--- a/arch/arm/configs/dove_defconfig
+++ b/arch/arm/configs/dove_defconfig
@@ -13,6 +13,9 @@ CONFIG_ARCH_DOVE=y
CONFIG_MACH_DOVE_DB=y
CONFIG_MACH_CM_A510=y
CONFIG_MACH_DOVE_DT=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_MVEBU=y
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
CONFIG_ZBOOT_ROM_TEXT=0x0
@@ -78,6 +81,7 @@ CONFIG_SPI_ORION=y
CONFIG_THERMAL=y
CONFIG_DOVE_THERMAL=y
CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_STORAGE=y
--
1.7.10.4

2013-08-12 18:49:04

by Sebastian Hesselbarth

Subject: [PATCH 9/9] ARM: dove: remove legacy pcie and clock init

With DT support for PCIe controllers on Dove, we can now remove the
legacy pcie init and the last remaining clock workaround for its clocks.

Signed-off-by: Sebastian Hesselbarth <[email protected]>
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
arch/arm/mach-dove/board-dt.c | 29 -----------------------------
1 file changed, 29 deletions(-)

diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
index 1efbe1d..9a116d7 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-dove/board-dt.c
@@ -23,28 +23,6 @@
#include <plat/irq.h>
#include "common.h"

-/*
- * There are still devices that doesn't even know about DT,
- * get clock gates here and add a clock lookup.
- */
-static void __init dove_legacy_clk_init(void)
-{
- struct device_node *np = of_find_compatible_node(NULL, NULL,
- "marvell,dove-gating-clock");
- struct of_phandle_args clkspec;
-
- clkspec.np = np;
- clkspec.args_count = 1;
-
- clkspec.args[0] = CLOCK_GATING_BIT_PCIE0;
- orion_clkdev_add("0", "pcie",
- of_clk_get_from_provider(&clkspec));
-
- clkspec.args[0] = CLOCK_GATING_BIT_PCIE1;
- orion_clkdev_add("1", "pcie",
- of_clk_get_from_provider(&clkspec));
-}
-
static void __init dove_dt_time_init(void)
{
of_clk_init(NULL);
@@ -59,13 +37,6 @@ static void __init dove_dt_init(void)
tauros2_init(0);
#endif
BUG_ON(mvebu_mbus_dt_init());
-
- /* Setup clocks for legacy devices */
- dove_legacy_clk_init();
-
- /* Internal devices not ported to DT yet */
- dove_pcie_init(1, 1);
-
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}

--
1.7.10.4

2013-08-12 18:49:45

by Sebastian Hesselbarth

Subject: [PATCH 4/9] PCI: mvebu: add support for reset on GPIO

This patch adds a check for DT passed reset-gpios property and deasserts/
asserts reset pin on probe/remove with configurable delay. Corresponding
binding documentation is also updated.

Signed-off-by: Sebastian Hesselbarth <[email protected]>
---
Cc: Russell King <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
.../devicetree/bindings/pci/mvebu-pci.txt | 2 ++
drivers/pci/host/pci-mvebu.c | 33 +++++++++++++++++++-
2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 638673a..f2fa261 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -76,6 +76,8 @@ and the following optional properties:
- marvell,pcie-lane: the physical PCIe lane number, for ports having
multiple lanes. If this property is not found, we assume that the
value is 0.
+- reset-gpios: optional gpio to PERST#
+- reset-delay-ms: delay in ms to wait after reset de-assertion

Example:

diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 2370b59..bdad4d4 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -9,14 +9,17 @@
#include <linux/kernel.h>
#include <linux/pci.h>
#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
#include <linux/module.h>
#include <linux/mbus.h>
#include <linux/msi.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
#include <linux/of_address.h>
-#include <linux/of_pci.h>
#include <linux/of_irq.h>
+#include <linux/of_gpio.h>
+#include <linux/of_pci.h>
#include <linux/of_platform.h>

/*
@@ -126,6 +129,9 @@ struct mvebu_pcie_port {
unsigned int io_target;
unsigned int io_attr;
struct clk *clk;
+ int reset_gpio;
+ int reset_active_low;
+ char *reset_name;
struct mvebu_sw_pci_bridge bridge;
struct device_node *dn;
struct mvebu_pcie *pcie;
@@ -856,6 +862,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)

for_each_child_of_node(pdev->dev.of_node, child) {
struct mvebu_pcie_port *port = &pcie->ports[pcie->nports];
+ enum of_gpio_flags flags;

if (!of_device_is_available(child))
continue;
@@ -896,6 +903,25 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
continue;
}

+ port->reset_gpio = of_get_named_gpio_flags(child,
+ "reset-gpios", 0, &flags);
+ if (gpio_is_valid(port->reset_gpio)) {
+ u32 reset_mdelay = 20;
+ port->reset_active_low = flags & OF_GPIO_ACTIVE_LOW;
+ port->reset_name = kasprintf(GFP_KERNEL,
+ "pcie%d.%d-reset", port->port, port->lane);
+ ret = devm_gpio_request_one(&pdev->dev,
+ port->reset_gpio, GPIOF_DIR_OUT, port->reset_name);
+ if (ret)
+ return ret;
+ gpio_set_value(port->reset_gpio,
+ (port->reset_active_low) ? 1 : 0);
+
+ of_property_read_u32(child, "reset-delay-ms",
+ &reset_mdelay);
+ mdelay(reset_mdelay);
+ }
+
port->clk = of_clk_get_by_name(child, NULL);
if (IS_ERR(port->clk)) {
dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n",
@@ -945,6 +971,11 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
int i;

for (i = 0; i < pcie->nports; i++, port++) {
+ if (gpio_is_valid(port->reset_gpio)) {
+ gpio_set_value(port->reset_gpio,
+ (port->reset_active_low) ? 0 : 1);
+ kfree(port->reset_name);
+ }
clk_disable_unprepare(port->clk);
kfree(port->name);
}
--
1.7.10.4

2013-08-12 20:00:43

by Jason Cooper

Subject: Re: [PATCH 6/9] ARM: dove: update dove_defconfig with SI5351, PCI, and xHCI

On Mon, Aug 12, 2013 at 08:46:52PM +0200, Sebastian Hesselbarth wrote:
> This adds SI5351 clock driver found on the SolidRun CuBox, PCI driver
> and USB 3.0 xHCI driver found on the Globalscale D3Plug to dove_defconfig.
>
> Signed-off-by: Sebastian Hesselbarth <[email protected]>
> ---
> Cc: Russell King <[email protected]>
> Cc: Jason Cooper <[email protected]>
> Cc: Andrew Lunn <[email protected]>
> Cc: Olof Johansson <[email protected]>
> Cc: Thomas Petazzoni <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> ---
> arch/arm/configs/dove_defconfig | 4 ++++
> 1 file changed, 4 insertions(+)

Applied to mvebu/defconfig

thx,

Jason.

2013-08-12 20:05:07

by Jason Cooper

Subject: Re: [PATCH 7/9] ARM: dove: add PCIe controllers to SoC DT

On Mon, Aug 12, 2013 at 08:46:53PM +0200, Sebastian Hesselbarth wrote:
> This adds a node for the pcie controllers found on Dove SoCs to the
> SoC DT include.
>
> Signed-off-by: Sebastian Hesselbarth <[email protected]>
> ---
> Cc: Russell King <[email protected]>
> Cc: Jason Cooper <[email protected]>
> Cc: Andrew Lunn <[email protected]>
> Cc: Thomas Petazzoni <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> ---
> arch/arm/boot/dts/dove.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)

patches 7-9 applied to mvebu/dove_mbus since the dependencies are
cleaner that way.

thx,

Jason.

2013-08-12 20:55:19

by Bjorn Helgaas

Subject: Re: [PATCH 0/9] ARM: dove: DT PCIe support

On Mon, Aug 12, 2013 at 12:46 PM, Sebastian Hesselbarth
<[email protected]> wrote:
> This patch set adds support for the PCIe controllers found on Marvell
> Dove SoCs. It depends on mvebu-pci patches sent by Thomas Petazzoni.
> Also, it adds support for the Globalscale D3Plug - a Dove based board
> comprising a USB3.0 dual port controller and a mini-PCIe port. The
> mini-PCIe port has not been tested, but USB controller and attached
> USB stick has been detected.
>
> The patch set can be separated into two main parts and should be
> taken by the respective maintainers. First five patches belong to
> PCI driver for MVEBU SoCs, while last four patches are Marvell Dove
> related. It is based on (unstable) mvebu/for-next branch with MSI
> patches applied and will be rebased on request.
>
> Devicetree and Doc MLs are not Cc'ed for the driver-only patches,
> PCI ML and maintainer are not Cc'ed for the Dove-only patches.
>
> Patches 1 and 2 fix some minor issues with pci-mvebu by moving
> clk_prepare_enable before accessing any controller registers and
> counting sucessfully registered ports only.
>
> Patch 3 converts pci-mvebu from subsys_initcall registration to
> normal platform driver registration to allow it to fail with
> EPROBE_DEFER later.
>
> Patch 4 adds DT parsing for reset (PERST#) GPIO pins and delay to
> wait for PCIe devices after reset de-assertion.
>
> Patch 5 finally adds a compatible to pci-mvebu for Dove SoCs.

I'm happy to merge patches 1-5 for v3.12 if you like, given acks from Thomas.

> Patch 6 updates dove_defconfig with some useful options for the
> Si5351 i2c clock generator found on SolidRun CuBox, PCIe driver,
> and USB3.0 xHCI driver.
>
> Patches 7 and 8 add PCIe controller nodes to Dove SoC DT and
> add support for the Globalscale D3Plug where this patches have
> been tested on.
>
> Patch 8 finally removes legacy PCIe driver init and clock
> gate workarounds from DT based Dove init.
>
> Sebastian Hesselbarth (9):
> PCI: mvebu: move clock enable before register access
> PCI: mvebu: increment nports only for registered ports
> PCI: mvebu: remove subsys_initcall
> PCI: mvebu: add support for reset on GPIO
> PCI: mvebu: add support for Marvell Dove SoCs
> ARM: dove: update dove_defconfig with SI5351, PCI, and xHCI
> ARM: dove: add PCIe controllers to SoC DT
> ARM: dove: add initial DT file for Globalscale D3Plug
> ARM: dove: remove legacy pcie and clock init
>
> .../devicetree/bindings/pci/mvebu-pci.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/dove-d3plug.dts | 103 ++++++++++++++++++
> arch/arm/boot/dts/dove.dtsi | 54 ++++++++++
> arch/arm/configs/dove_defconfig | 4 +
> arch/arm/mach-dove/board-dt.c | 29 -----
> drivers/pci/host/Kconfig | 2 +-
> drivers/pci/host/pci-mvebu.c | 113 +++++++++++++-------
> 8 files changed, 241 insertions(+), 68 deletions(-)
> create mode 100644 arch/arm/boot/dts/dove-d3plug.dts
> ---
> Cc: Russell King <[email protected]>
> Cc: Jason Cooper <[email protected]>
> Cc: Andrew Lunn <[email protected]>
> Cc: Bjorn Helgaas <[email protected]>
> Cc: Olof Johansson <[email protected]>
> Cc: Thomas Petazzoni <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> --
> 1.7.10.4
>

2013-08-13 00:56:52

by Kumar Gala

Subject: Re: [PATCH 4/9] PCI: mvebu: add support for reset on GPIO

On Aug 12, 2013, at 1:46 PM, Sebastian Hesselbarth wrote:

> This patch adds a check for DT passed reset-gpios property and deasserts/
> asserts reset pin on probe/remove with configurable delay. Corresponding
> binding documentation is also updated.
>
> Signed-off-by: Sebastian Hesselbarth <[email protected]>
> ---
> Cc: Russell King <[email protected]>
> Cc: Jason Cooper <[email protected]>
> Cc: Andrew Lunn <[email protected]>
> Cc: Bjorn Helgaas <[email protected]>
> Cc: Thomas Petazzoni <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> ---
> .../devicetree/bindings/pci/mvebu-pci.txt | 2 ++
> drivers/pci/host/pci-mvebu.c | 33 +++++++++++++++++++-
> 2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index 638673a..f2fa261 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -76,6 +76,8 @@ and the following optional properties:
> - marvell,pcie-lane: the physical PCIe lane number, for ports having
> multiple lanes. If this property is not found, we assume that the
> value is 0.
> +- reset-gpios: optional gpio to PERST#
> +- reset-delay-ms: delay in ms to wait after reset de-assertion

Both of these should probably be marvell,reset...

Does reset-delay-ms vary per board? I can't remember where the discussion got to about configuration info.

>
> Example:

It's usually good to update example to show all optional properties.

- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

2013-08-13 07:11:20

by Thomas Petazzoni

Subject: Re: [PATCH 1/9] PCI: mvebu: move clock enable before register access

Dear Sebastian Hesselbarth,

On Mon, 12 Aug 2013 20:46:47 +0200, Sebastian Hesselbarth wrote:

> + port->clk = of_clk_get_by_name(child, NULL);
> + if (IS_ERR(port->clk)) {
> + dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n",
> + port->port, port->lane);
> + iounmap(port->base);

You shouldn't iounmap() here in case of error, since the register
mapping hasn't been done yet.

> + port->haslink = 0;
> + continue;
> + }
> + clk_prepare_enable(port->clk);

Nitpick, an empty new line between the closing } and the
clk_prepare_enable() line would be nice.

> +
> port->base = mvebu_pcie_map_registers(pdev, child, port);
> if (!port->base) {
> dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
> @@ -916,22 +926,9 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
> port->port, port->lane);

and maybe here you could unprepare+release the clock if we haven't
managed to remap registers?

> }
>
> - port->clk = of_clk_get_by_name(child, NULL);
> - if (IS_ERR(port->clk)) {
> - dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n",
> - port->port, port->lane);
> - iounmap(port->base);
> - port->haslink = 0;
> - continue;
> - }
> -
> port->dn = child;
> -
> - clk_prepare_enable(port->clk);
> spin_lock_init(&port->conf_lock);
> -
> mvebu_sw_pci_bridge_init(port);
> -
> i++;
> }
>

Thanks!

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

2013-08-13 07:15:51

by Thomas Petazzoni

Subject: Re: [PATCH 2/9] PCI: mvebu: increment nports only for registered ports

Dear Sebastian Hesselbarth,

On Mon, 12 Aug 2013 20:46:48 +0200, Sebastian Hesselbarth wrote:

> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index d5fe674..0a359d7 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -842,21 +842,21 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
> return ret;
> }
>
> + i = 0;
> for_each_child_of_node(pdev->dev.of_node, child) {
> if (!of_device_is_available(child))
> continue;
> - pcie->nports++;
> + i++;
> }
>
> - pcie->ports = devm_kzalloc(&pdev->dev, pcie->nports *
> + pcie->ports = devm_kzalloc(&pdev->dev, i *
> sizeof(struct mvebu_pcie_port),
> GFP_KERNEL);
> if (!pcie->ports)
> return -ENOMEM;
>
> - i = 0;
> for_each_child_of_node(pdev->dev.of_node, child) {
> - struct mvebu_pcie_port *port = &pcie->ports[i];
> + struct mvebu_pcie_port *port = &pcie->ports[pcie->nports];
>
> if (!of_device_is_available(child))
> continue;
> @@ -929,7 +929,7 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
> port->dn = child;
> spin_lock_init(&port->conf_lock);
> mvebu_sw_pci_bridge_init(port);
> - i++;
> + pcie->nports++;
> }

I think I'd prefer using 'i' in this loop, and then after the loop have
a:

pcie->nports = i;

assignment. That's nitpicking, but I don't like the fact that within
the loop 'pcie->nports' doesn't mean "Number of enabled PCIe ports",
but means "Last enabled PCIe port".

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

2013-08-13 07:20:14

by Thomas Petazzoni

Subject: Re: [PATCH 3/9] PCI: mvebu: remove subsys_initcall

Dear Sebastian Hesselbarth,

On Mon, 12 Aug 2013 20:46:49 +0200, Sebastian Hesselbarth wrote:
> This removes the subsys_initcall from the driver and converts it to
> a normal platform_driver. Also, drvdata is set and a remove functions
> is added to disable the clock and free resources.
>
> Signed-off-by: Sebastian Hesselbarth <[email protected]>

I'm OK with this, just a comment below.

> +static int mvebu_pcie_remove(struct platform_device *pdev)
> +{
> + struct mvebu_pcie *pcie = platform_get_drvdata(pdev);
> + struct mvebu_pcie_port *port = &pcie->ports[0];
> + int i;
> +
> + for (i = 0; i < pcie->nports; i++, port++) {
> + clk_disable_unprepare(port->clk);
> + kfree(port->name);
> + }
> +
> + return 0;
> +}

I believe the ->remove() part is quite useless. The driver is a 'bool'
in Kconfig, so it cannot be compiled as a module, and I'm not sure
there a way to remove the platform device that corresponds to the PCIe
controller.

And even if there was, then it would still not work because as far as I
know, the ARM PCI core doesn't provide functions to 'unregister' PCI
controllers, so it would keep pointers to functions located in the
driver, which would cause nasty things when unloading the module.

So the reason why I didn't include a ->remove() hook is simply because
there was, as of today, no use for it.

Best regards,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

2013-08-13 07:58:36

by Thierry Reding

Subject: Re: [PATCH 1/9] PCI: mvebu: move clock enable before register access

On Mon, Aug 12, 2013 at 08:46:47PM +0200, Sebastian Hesselbarth wrote:
[...]
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
[...]
> @@ -897,6 +897,16 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
> continue;
> }
>
> + port->clk = of_clk_get_by_name(child, NULL);
> + if (IS_ERR(port->clk)) {
> + dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n",
> + port->port, port->lane);
> + iounmap(port->base);
> + port->haslink = 0;
> + continue;
> + }
> + clk_prepare_enable(port->clk);

I see that this was already wrong previously, but since you're changing
the line anyway you should probably also check for failure of the
clk_prepare_enable() call and error out if it can't be prepare/enabled.

Thierry

Attachments:

2013-08-13 08:06:49

by Thierry Reding

Subject: Re: [PATCH 3/9] PCI: mvebu: remove subsys_initcall

On Tue, Aug 13, 2013 at 09:19:59AM +0200, Thomas Petazzoni wrote:
> Dear Sebastian Hesselbarth,
>
> On Mon, 12 Aug 2013 20:46:49 +0200, Sebastian Hesselbarth wrote:
> > This removes the subsys_initcall from the driver and converts it to
> > a normal platform_driver. Also, drvdata is set and a remove functions
> > is added to disable the clock and free resources.
> >
> > Signed-off-by: Sebastian Hesselbarth <[email protected]>
>
> I'm OK with this, just a comment below.
>
> > +static int mvebu_pcie_remove(struct platform_device *pdev)
> > +{
> > + struct mvebu_pcie *pcie = platform_get_drvdata(pdev);
> > + struct mvebu_pcie_port *port = &pcie->ports[0];
> > + int i;
> > +
> > + for (i = 0; i < pcie->nports; i++, port++) {
> > + clk_disable_unprepare(port->clk);
> > + kfree(port->name);
> > + }
> > +
> > + return 0;
> > +}
>
> I believe the ->remove() part is quite useless. The driver is a 'bool'
> in Kconfig, so it cannot be compiled as a module, and I'm not sure
> there a way to remove the platform device that corresponds to the PCIe
> controller.

There is. You can write the device's name to the driver's unbind file in
sysfs. What I ended up doing for Tegra was not to provide a .remove() at
all and set the struct device_driver's .suppress_bind_attrs to true.

Those two things combined should make it impossible to unbind the device
from the driver.

> And even if there was, then it would still not work because as far as I
> know, the ARM PCI core doesn't provide functions to 'unregister' PCI
> controllers, so it would keep pointers to functions located in the
> driver, which would cause nasty things when unloading the module.

I did some initial work to support driver unbinding (in order to support
module unloading) on Tegra and things look pretty promising. The ARM PCI
code would need something like pci_common_exit() to make sure there are
no leaks.

Unfortunately I can't seem to find that branch anymore, so I will have
to reconstruct it from memory...

That said, I agree with Thomas that it's not useful (and potentially
even dangerous) to add the .remove() at this point in time.

Thierry

Attachments:

2013-08-13 08:10:08

by Thierry Reding

Subject: Re: [PATCH 4/9] PCI: mvebu: add support for reset on GPIO

On Mon, Aug 12, 2013 at 08:46:50PM +0200, Sebastian Hesselbarth wrote:
> This patch adds a check for DT passed reset-gpios property and deasserts/
> asserts reset pin on probe/remove with configurable delay. Corresponding
> binding documentation is also updated.
>
> Signed-off-by: Sebastian Hesselbarth <[email protected]>
> ---
> Cc: Russell King <[email protected]>
> Cc: Jason Cooper <[email protected]>
> Cc: Andrew Lunn <[email protected]>
> Cc: Bjorn Helgaas <[email protected]>
> Cc: Thomas Petazzoni <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> ---
> .../devicetree/bindings/pci/mvebu-pci.txt | 2 ++
> drivers/pci/host/pci-mvebu.c | 33 +++++++++++++++++++-
> 2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index 638673a..f2fa261 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -76,6 +76,8 @@ and the following optional properties:
> - marvell,pcie-lane: the physical PCIe lane number, for ports having
> multiple lanes. If this property is not found, we assume that the
> value is 0.
> +- reset-gpios: optional gpio to PERST#
> +- reset-delay-ms: delay in ms to wait after reset de-assertion

I remember some recent discussion about this, and we now have this reset
framework, so perhaps it makes more sense to use the reset binding for
this? Cc'ing Stephen (as part of the device tree bindings maintainers
team) who was involved in that recent reset bindings discussion.

Thierry

Attachments:

2013-08-13 08:30:43

by Thomas Petazzoni

Subject: Re: [PATCH 4/9] PCI: mvebu: add support for reset on GPIO

Dear Thierry Reding,

On Tue, 13 Aug 2013 10:09:56 +0200, Thierry Reding wrote:

> > +- reset-gpios: optional gpio to PERST#
> > +- reset-delay-ms: delay in ms to wait after reset de-assertion
>
> I remember some recent discussion about this, and we now have this reset
> framework, so perhaps it makes more sense to use the reset binding for
> this? Cc'ing Stephen (as part of the device tree bindings maintainers
> team) who was involved in that recent reset bindings discussion.

I also thought about this, but the reset framework seems to be designed
for "reset controller" IPs, i.e special IPs that are controlling reset
signals. Looking at Documentation/devicetree/bindings/reset/reset.txt,
I'm not sure to see how this would apply to GPIO-controlled reset
signals.

Best regards,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

2013-08-13 09:19:11

by Sebastian Hesselbarth

Subject: Re: [PATCH 4/9] PCI: mvebu: add support for reset on GPIO

[Added DT maintainers directly for a question below]

On 08/13/13 02:56, Kumar Gala wrote:
> On Aug 12, 2013, at 1:46 PM, Sebastian Hesselbarth wrote:
>
>> This patch adds a check for DT passed reset-gpios property and deasserts/
>> asserts reset pin on probe/remove with configurable delay. Corresponding
>> binding documentation is also updated.
>>
>> Signed-off-by: Sebastian Hesselbarth <[email protected]>
[...]
>> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
>> index 638673a..f2fa261 100644
>> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
>> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
>> @@ -76,6 +76,8 @@ and the following optional properties:
>> - marvell,pcie-lane: the physical PCIe lane number, for ports having
>> multiple lanes. If this property is not found, we assume that the
>> value is 0.
>> +- reset-gpios: optional gpio to PERST#
>> +- reset-delay-ms: delay in ms to wait after reset de-assertion
>
> Both of these should probably be marvell,reset...

Kumar,

as Thomas already mentioned, non-prefixed "foo-gpios" are quite common.
As reset gpios are likely to be common among SoC pci controller setups,
I though I'd stick with the non-prefixed property. But I have no strong
opinion about it - but let's see how DT jurisdiction will vote :)

> Does reset-delay-ms vary per board? I can't remember where the
discussion got to about configuration info.

Hmm, for Dove SoC, I only have one board to test - but the driver
currently is for 4 different SoCs. I just did some quick evaluation
of the reset delay required to bring up the device on the D3Plug.
Using 10ms was too short, 20ms worked.

I guess there will be other SoC/boards requiring different delays
but I am fine with hardcoded 20ms and re-introduce reset-delay property
only if it is really required. The driver's default is 20ms anyway.

>>
>> Example:
>
> It's usually good to update example to show all optional properties.

Ok, will add the properties to one of the example ports.

Thanks,

Sebastian

2013-08-13 09:23:04

by Sebastian Hesselbarth

Subject: Re: [PATCH 1/9] PCI: mvebu: move clock enable before register access

On 08/13/13 09:11, Thomas Petazzoni wrote:
> On Mon, 12 Aug 2013 20:46:47 +0200, Sebastian Hesselbarth wrote:
>> + port->clk = of_clk_get_by_name(child, NULL);
>> + if (IS_ERR(port->clk)) {
>> + dev_err(&pdev->dev, "PCIe%d.%d: cannot get clock\n",
>> + port->port, port->lane);
>> + iounmap(port->base);
>
> You shouldn't iounmap() here in case of error, since the register
> mapping hasn't been done yet.

Dooh, it was in my testing branch, but I failed to transfer that when
separating the changes to single patches. Will update.

>> + port->haslink = 0;
>> + continue;
>> + }
>> + clk_prepare_enable(port->clk);
>
> Nitpick, an empty new line between the closing } and the
> clk_prepare_enable() line would be nice.

Ok, as Theirry mentioned to check for clk_prepare_enable's return value
that would give a new "if (..)" anyway. Although, it might be the first
driver ever checking for this return value ;)

>> +
>> port->base = mvebu_pcie_map_registers(pdev, child, port);
>> if (!port->base) {
>> dev_err(&pdev->dev, "PCIe%d.%d: cannot map registers\n",
>> @@ -916,22 +926,9 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
>> port->port, port->lane);
>
> and maybe here you could unprepare+release the clock if we haven't
> managed to remap registers?

Ack.

Sebastian

2013-08-13 09:24:06

by Sebastian Hesselbarth

Subject: Re: [PATCH 2/9] PCI: mvebu: increment nports only for registered ports

On 08/13/13 09:15, Thomas Petazzoni wrote:
> Dear Sebastian Hesselbarth,
>
> On Mon, 12 Aug 2013 20:46:48 +0200, Sebastian Hesselbarth wrote:
>
>> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
>> index d5fe674..0a359d7 100644
>> --- a/drivers/pci/host/pci-mvebu.c
>> +++ b/drivers/pci/host/pci-mvebu.c
>> @@ -842,21 +842,21 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
>> return ret;
>> }
>>
>> + i = 0;
>> for_each_child_of_node(pdev->dev.of_node, child) {
>> if (!of_device_is_available(child))
>> continue;
>> - pcie->nports++;
>> + i++;
>> }
>>
>> - pcie->ports = devm_kzalloc(&pdev->dev, pcie->nports *
>> + pcie->ports = devm_kzalloc(&pdev->dev, i *
>> sizeof(struct mvebu_pcie_port),
>> GFP_KERNEL);
>> if (!pcie->ports)
>> return -ENOMEM;
>>
>> - i = 0;
>> for_each_child_of_node(pdev->dev.of_node, child) {
>> - struct mvebu_pcie_port *port = &pcie->ports[i];
>> + struct mvebu_pcie_port *port = &pcie->ports[pcie->nports];
>>
>> if (!of_device_is_available(child))
>> continue;
>> @@ -929,7 +929,7 @@ static int __init mvebu_pcie_probe(struct platform_device *pdev)
>> port->dn = child;
>> spin_lock_init(&port->conf_lock);
>> mvebu_sw_pci_bridge_init(port);
>> - i++;
>> + pcie->nports++;
>> }
>
> I think I'd prefer using 'i' in this loop, and then after the loop have
> a:
>
> pcie->nports = i;
>
> assignment. That's nitpicking, but I don't like the fact that within
> the loop 'pcie->nports' doesn't mean "Number of enabled PCIe ports",
> but means "Last enabled PCIe port".

Ok, I'll use 'i' in both loops and assign it like you suggested.

Sebastian

2013-08-13 09:25:41

by Sebastian Hesselbarth

Subject: Re: [PATCH 3/9] PCI: mvebu: remove subsys_initcall

On 08/13/13 10:06, Thierry Reding wrote:
> On Tue, Aug 13, 2013 at 09:19:59AM +0200, Thomas Petazzoni wrote:
>> On Mon, 12 Aug 2013 20:46:49 +0200, Sebastian Hesselbarth wrote:
>>> This removes the subsys_initcall from the driver and converts it to
>>> a normal platform_driver. Also, drvdata is set and a remove functions
>>> is added to disable the clock and free resources.
>>>
>>> Signed-off-by: Sebastian Hesselbarth <[email protected]>
>>
>> I'm OK with this, just a comment below.
>>
>>> +static int mvebu_pcie_remove(struct platform_device *pdev)
>>> +{
>>> + struct mvebu_pcie *pcie = platform_get_drvdata(pdev);
>>> + struct mvebu_pcie_port *port = &pcie->ports[0];
>>> + int i;
>>> +
>>> + for (i = 0; i < pcie->nports; i++, port++) {
>>> + clk_disable_unprepare(port->clk);
>>> + kfree(port->name);
>>> + }
>>> +
>>> + return 0;
>>> +}
>>
>> I believe the ->remove() part is quite useless. The driver is a 'bool'
>> in Kconfig, so it cannot be compiled as a module, and I'm not sure
>> there a way to remove the platform device that corresponds to the PCIe
>> controller.
>
> There is. You can write the device's name to the driver's unbind file in
> sysfs. What I ended up doing for Tegra was not to provide a .remove() at
> all and set the struct device_driver's .suppress_bind_attrs to true.
[...]
> That said, I agree with Thomas that it's not useful (and potentially
> even dangerous) to add the .remove() at this point in time.

Thierry, Thomas,

I will not introduce the .remove and set .suppress_bind_attrs = true as
Thierry suggested.

Sebastian

2013-08-13 09:59:59

by Sascha Hauer

Subject: Re: [PATCH 4/9] PCI: mvebu: add support for reset on GPIO

On Tue, Aug 13, 2013 at 10:30:30AM +0200, Thomas Petazzoni wrote:
> Dear Thierry Reding,
>
> On Tue, 13 Aug 2013 10:09:56 +0200, Thierry Reding wrote:
>
> > > +- reset-gpios: optional gpio to PERST#
> > > +- reset-delay-ms: delay in ms to wait after reset de-assertion
> >
> > I remember some recent discussion about this, and we now have this reset
> > framework, so perhaps it makes more sense to use the reset binding for
> > this? Cc'ing Stephen (as part of the device tree bindings maintainers
> > team) who was involved in that recent reset bindings discussion.
>
> I also thought about this, but the reset framework seems to be designed
> for "reset controller" IPs, i.e special IPs that are controlling reset
> signals. Looking at Documentation/devicetree/bindings/reset/reset.txt,
> I'm not sure to see how this would apply to GPIO-controlled reset
> signals.

Search for:

[PATCH v10] reset: Add driver for gpio-controlled reset pins

Which aims to be a solution for what you need here.

Sascha

--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

2013-08-13 10:03:55

by Thierry Reding

Subject: Re: [PATCH 4/9] PCI: mvebu: add support for reset on GPIO

On Tue, Aug 13, 2013 at 10:30:30AM +0200, Thomas Petazzoni wrote:
> Dear Thierry Reding,
>
> On Tue, 13 Aug 2013 10:09:56 +0200, Thierry Reding wrote:
>
> > > +- reset-gpios: optional gpio to PERST#
> > > +- reset-delay-ms: delay in ms to wait after reset de-assertion
> >
> > I remember some recent discussion about this, and we now have this reset
> > framework, so perhaps it makes more sense to use the reset binding for
> > this? Cc'ing Stephen (as part of the device tree bindings maintainers
> > team) who was involved in that recent reset bindings discussion.
>
> I also thought about this, but the reset framework seems to be designed
> for "reset controller" IPs, i.e special IPs that are controlling reset
> signals. Looking at Documentation/devicetree/bindings/reset/reset.txt,
> I'm not sure to see how this would apply to GPIO-controlled reset
> signals.

See:

http://www.mail-archive.com/[email protected]/msg36900.html

which seems to have carried over to this at some point:

http://www.spinics.net/lists/devicetree/msg00521.html

Some of the messages in between I can't find in any archive, sorry.

Thierry

Attachments:

2013-08-13 10:40:37

by Sebastian Hesselbarth

Subject: Re: [PATCH 4/9] PCI: mvebu: add support for reset on GPIO

On 08/13/13 12:03, Thierry Reding wrote:
> On Tue, Aug 13, 2013 at 10:30:30AM +0200, Thomas Petazzoni wrote:
>> Dear Thierry Reding,
>>
>> On Tue, 13 Aug 2013 10:09:56 +0200, Thierry Reding wrote:
>>
>>>> +- reset-gpios: optional gpio to PERST#
>>>> +- reset-delay-ms: delay in ms to wait after reset de-assertion
>>>
>>> I remember some recent discussion about this, and we now have this reset
>>> framework, so perhaps it makes more sense to use the reset binding for
>>> this? Cc'ing Stephen (as part of the device tree bindings maintainers
>>> team) who was involved in that recent reset bindings discussion.
>>
>> I also thought about this, but the reset framework seems to be designed
>> for "reset controller" IPs, i.e special IPs that are controlling reset
>> signals. Looking at Documentation/devicetree/bindings/reset/reset.txt,
>> I'm not sure to see how this would apply to GPIO-controlled reset
>> signals.
>
> See:
>
> http://www.mail-archive.com/[email protected]/msg36900.html
>
> which seems to have carried over to this at some point:
>
> http://www.spinics.net/lists/devicetree/msg00521.html
>
> Some of the messages in between I can't find in any archive, sorry.

Thierry, Sascha,

thanks for the input. Flipping through the above discussion, I guess
using "reset-gpios" and "reset-delay-us" should be fine?

I can also remove the delay property for now, as I cannot find a final
conclusion about the configurable delay.

In the driver, I will stick to bare gpiolib and wait for gpio-reset
driver to become available. Currently, we don't have sophisticated
reset handling in pci-mvebu anyway.

Sebastian

2013-08-13 11:00:38

by Philipp Zabel

Subject: Re: [PATCH 4/9] PCI: mvebu: add support for reset on GPIO

Hi Sebastian,

Am Dienstag, den 13.08.2013, 12:40 +0200 schrieb Sebastian Hesselbarth:
> On 08/13/13 12:03, Thierry Reding wrote:
> > On Tue, Aug 13, 2013 at 10:30:30AM +0200, Thomas Petazzoni wrote:
> >> Dear Thierry Reding,
> >>
> >> On Tue, 13 Aug 2013 10:09:56 +0200, Thierry Reding wrote:
> >>
> >>>> +- reset-gpios: optional gpio to PERST#
> >>>> +- reset-delay-ms: delay in ms to wait after reset de-assertion
> >>>
> >>> I remember some recent discussion about this, and we now have this reset
> >>> framework, so perhaps it makes more sense to use the reset binding for
> >>> this? Cc'ing Stephen (as part of the device tree bindings maintainers
> >>> team) who was involved in that recent reset bindings discussion.
> >>
> >> I also thought about this, but the reset framework seems to be designed
> >> for "reset controller" IPs, i.e special IPs that are controlling reset
> >> signals. Looking at Documentation/devicetree/bindings/reset/reset.txt,
> >> I'm not sure to see how this would apply to GPIO-controlled reset
> >> signals.
> >
> > See:
> >
> > http://www.mail-archive.com/[email protected]/msg36900.html
> >
> > which seems to have carried over to this at some point:
> >
> > http://www.spinics.net/lists/devicetree/msg00521.html
> >
> > Some of the messages in between I can't find in any archive, sorry.
>
> Thierry, Sascha,
>
> thanks for the input. Flipping through the above discussion, I guess
> using "reset-gpios" and "reset-delay-us" should be fine?
>
> I can also remove the delay property for now, as I cannot find a final
> conclusion about the configurable delay.

Yes, I'm in favor of using 'reset-gpios'. If we can agree on this
binding, I'll add support to the reset framework core.

> In the driver, I will stick to bare gpiolib and wait for gpio-reset
> driver to become available. Currently, we don't have sophisticated
> reset handling in pci-mvebu anyway.

Sounds good to me.

regards
Philipp

2013-08-13 11:28:55

by Sebastian Hesselbarth

Subject: Re: [PATCH 7/9] ARM: dove: add PCIe controllers to SoC DT

On 08/12/13 22:04, Jason Cooper wrote:
> On Mon, Aug 12, 2013 at 08:46:53PM +0200, Sebastian Hesselbarth wrote:
>> This adds a node for the pcie controllers found on Dove SoCs to the
>> SoC DT include.
>>
>> Signed-off-by: Sebastian Hesselbarth <[email protected]>
>> ---
>> Cc: Russell King <[email protected]>
>> Cc: Jason Cooper <[email protected]>
>> Cc: Andrew Lunn <[email protected]>
>> Cc: Thomas Petazzoni <[email protected]>
>> Cc: [email protected]
>> Cc: [email protected]
>> ---
>> arch/arm/boot/dts/dove.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 54 insertions(+)
>
> patches 7-9 applied to mvebu/dove_mbus since the dependencies are
> cleaner that way.

Jason,

I will have to slightly modify the reset-gpio property names and that
requires a fixup patch for patch 8. Can you still squash it or do you
need a proper patch?

Sebastian

---

Attachments:

2013-08-13 13:21:46

by Jason Cooper

Subject: Re: [PATCH 7/9] ARM: dove: add PCIe controllers to SoC DT

On Tue, Aug 13, 2013 at 01:28:49PM +0200, Sebastian Hesselbarth wrote:
> On 08/12/13 22:04, Jason Cooper wrote:
> >On Mon, Aug 12, 2013 at 08:46:53PM +0200, Sebastian Hesselbarth wrote:
> >>This adds a node for the pcie controllers found on Dove SoCs to the
> >>SoC DT include.
> >>
> >>Signed-off-by: Sebastian Hesselbarth <[email protected]>
> >>---
> >>Cc: Russell King <[email protected]>
> >>Cc: Jason Cooper <[email protected]>
> >>Cc: Andrew Lunn <[email protected]>
> >>Cc: Thomas Petazzoni <[email protected]>
> >>Cc: [email protected]
> >>Cc: [email protected]
> >>---
> >> arch/arm/boot/dts/dove.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 54 insertions(+)
> >
> >patches 7-9 applied to mvebu/dove_mbus since the dependencies are
> >cleaner that way.
>
> Jason,
>
> I will have to slightly modify the reset-gpio property names and that
> requires a fixup patch for patch 8. Can you still squash it or do you
> need a proper patch?

I can squash it, no problem.

thx,

Jason.

> diff --git a/arch/arm/boot/dts/dove-d3plug.dts b/arch/arm/boot/dts/dove-d3plug.dts
> index ead90eb..f5f59bb 100644
> --- a/arch/arm/boot/dts/dove-d3plug.dts
> +++ b/arch/arm/boot/dts/dove-d3plug.dts
> @@ -91,7 +91,7 @@
> pcie-port@0 {
> status = "okay";
> reset-gpios = <&gpio0 26 1>;
> - reset-delay-ms = <20>;
> + reset-delay-us = <20000>;
> pinctrl-0 = <&pmx_camera_gpio>;
> pinctrl-names = "default";
> };

2013-08-13 13:49:05

by Jason Cooper

Subject: Re: [PATCH 7/9] ARM: dove: add PCIe controllers to SoC DT

On Tue, Aug 13, 2013 at 01:28:49PM +0200, Sebastian Hesselbarth wrote:
> On 08/12/13 22:04, Jason Cooper wrote:
> >On Mon, Aug 12, 2013 at 08:46:53PM +0200, Sebastian Hesselbarth wrote:
> >>This adds a node for the pcie controllers found on Dove SoCs to the
> >>SoC DT include.
> >>
> >>Signed-off-by: Sebastian Hesselbarth <[email protected]>
> >>---
> >>Cc: Russell King <[email protected]>
> >>Cc: Jason Cooper <[email protected]>
> >>Cc: Andrew Lunn <[email protected]>
> >>Cc: Thomas Petazzoni <[email protected]>
> >>Cc: [email protected]
> >>Cc: [email protected]
> >>---
> >> arch/arm/boot/dts/dove.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 54 insertions(+)
> >
> >patches 7-9 applied to mvebu/dove_mbus since the dependencies are
> >cleaner that way.
>
> Jason,
>
> I will have to slightly modify the reset-gpio property names and that
> requires a fixup patch for patch 8. Can you still squash it or do you
> need a proper patch?
...
> diff --git a/arch/arm/boot/dts/dove-d3plug.dts b/arch/arm/boot/dts/dove-d3plug.dts
> index ead90eb..f5f59bb 100644
> --- a/arch/arm/boot/dts/dove-d3plug.dts
> +++ b/arch/arm/boot/dts/dove-d3plug.dts
> @@ -91,7 +91,7 @@
> pcie-port@0 {
> status = "okay";
> reset-gpios = <&gpio0 26 1>;
> - reset-delay-ms = <20>;
> + reset-delay-us = <20000>;
> pinctrl-0 = <&pmx_camera_gpio>;
> pinctrl-names = "default";
> };

Squashed into 'ARM: dove: add initial DT file for Globalscale D3Plug' in
mvebu/dove_mbus-dt

thx,

Jason.