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

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

[Sebastian Hesselbarth]

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 <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-pci@vger.kernel.org
-- 
1.7.10.4

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

[Sebastian Hesselbarth]

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 <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pci at vger.kernel.org
-- 
1.7.10.4

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-pci@vger.kernel.org
---
 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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pci at vger.kernel.org
---
 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

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

[Thomas Petazzoni]

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

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

[Thomas Petazzoni]

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

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

[Sebastian Hesselbarth]

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

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

[Sebastian Hesselbarth]

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

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Thierry Reding]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130813/91abbf9d/attachment.sig>

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-pci@vger.kernel.org
---
 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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pci at vger.kernel.org
---
 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

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

[Thomas Petazzoni]

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

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

[Thomas Petazzoni]

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

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

[Sebastian Hesselbarth]

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

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

[Sebastian Hesselbarth]

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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-pci@vger.kernel.org
---
 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 <thomas.petazzoni@free-electrons.com>");
 MODULE_DESCRIPTION("Marvell EBU PCIe driver");
-- 
1.7.10.4

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pci at vger.kernel.org
---
 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 <thomas.petazzoni@free-electrons.com>");
 MODULE_DESCRIPTION("Marvell EBU PCIe driver");
-- 
1.7.10.4

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

[Thomas Petazzoni]

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 <sebastian.hesselbarth@gmail.com>

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

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

[Thomas Petazzoni]

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 <sebastian.hesselbarth@gmail.com>

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

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

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 <sebastian.hesselbarth@gmail.com>
> 
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Thierry Reding]

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 <sebastian.hesselbarth@gmail.com>
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130813/9c9556dc/attachment-0001.sig>

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
>>
>> 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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
>>
>> 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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-pci@vger.kernel.org
---
 .../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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pci at vger.kernel.org
---
 .../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

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

[Kumar Gala]

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 <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-pci@vger.kernel.org
> ---
> .../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

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

[Kumar Gala]

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 <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: devicetree at vger.kernel.org
> Cc: linux-doc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-pci at vger.kernel.org
> ---
> .../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

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

[Sebastian Hesselbarth]

[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 <sebastian.hesselbarth@gmail.com>
[...]
>> 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

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

[Sebastian Hesselbarth]

[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 <sebastian.hesselbarth@gmail.com>
[...]
>> 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

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

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 <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-pci@vger.kernel.org
> ---
>  .../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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Thierry Reding]

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 <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: devicetree at vger.kernel.org
> Cc: linux-doc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-pci at vger.kernel.org
> ---
>  .../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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130813/1383a882/attachment.sig>

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

[Thomas Petazzoni]

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

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

[Thomas Petazzoni]

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

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

[Sascha Hauer]

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 |

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

[Sascha Hauer]

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 |

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

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

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/devicetree-discuss@lists.ozlabs.org/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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Thierry Reding]

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/devicetree-discuss at lists.ozlabs.org/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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130813/05e454c5/attachment.sig>

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

[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/devicetree-discuss@lists.ozlabs.org/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

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

[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/devicetree-discuss at lists.ozlabs.org/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

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

[Philipp Zabel]

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/devicetree-discuss@lists.ozlabs.org/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

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

[Philipp Zabel]

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/devicetree-discuss at lists.ozlabs.org/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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-pci@vger.kernel.org
---
 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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-pci at vger.kernel.org
---
 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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <olof@lixom.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Olof Johansson <olof@lixom.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 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

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

[Jason Cooper]

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 <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
>  arch/arm/configs/dove_defconfig |    4 ++++
>  1 file changed, 4 insertions(+)

Applied to mvebu/defconfig

thx,

Jason.

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

[Jason Cooper]

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 <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  arch/arm/configs/dove_defconfig |    4 ++++
>  1 file changed, 4 insertions(+)

Applied to mvebu/defconfig

thx,

Jason.

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

[Sebastian Hesselbarth]

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

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 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

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

[Sebastian Hesselbarth]

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

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 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 at 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 at 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

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

[Jason Cooper]

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 <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
>  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.

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

[Jason Cooper]

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 <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  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.

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

[Sebastian Hesselbarth]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

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 <sebastian.hesselbarth@gmail.com>
>> ---
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Jason Cooper <jason@lakedaemon.net>
>> Cc: Andrew Lunn <andrew@lunn.ch>
>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> ---
>>   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

---



[-- Attachment #2: d3plug-dts.diff --]
[-- Type: text/x-patch, Size: 404 bytes --]

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";
 	};

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
>> ---
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Jason Cooper <jason@lakedaemon.net>
>> Cc: Andrew Lunn <andrew@lunn.ch>
>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Cc: linux-kernel at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> ---
>>   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

---


-------------- next part --------------
A non-text attachment was scrubbed...
Name: d3plug-dts.diff
Type: text/x-patch
Size: 404 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130813/424c82b2/attachment.bin>

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

[Jason Cooper]

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 <sebastian.hesselbarth@gmail.com>
> >>---
> >>Cc: Russell King <linux@arm.linux.org.uk>
> >>Cc: Jason Cooper <jason@lakedaemon.net>
> >>Cc: Andrew Lunn <andrew@lunn.ch>
> >>Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >>Cc: linux-kernel@vger.kernel.org
> >>Cc: linux-arm-kernel@lists.infradead.org
> >>---
> >>  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";
>  	};

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

[Jason Cooper]

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 <sebastian.hesselbarth@gmail.com>
> >>---
> >>Cc: Russell King <linux@arm.linux.org.uk>
> >>Cc: Jason Cooper <jason@lakedaemon.net>
> >>Cc: Andrew Lunn <andrew@lunn.ch>
> >>Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >>Cc: linux-kernel at vger.kernel.org
> >>Cc: linux-arm-kernel at lists.infradead.org
> >>---
> >>  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 at 0 {
>  		status = "okay";
>  		reset-gpios = <&gpio0 26 1>;
> -		reset-delay-ms = <20>;
> +		reset-delay-us = <20000>;
>  		pinctrl-0 = <&pmx_camera_gpio>;
>  		pinctrl-names = "default";
>  	};

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

[Jason Cooper]

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 <sebastian.hesselbarth@gmail.com>
> >>---
> >>Cc: Russell King <linux@arm.linux.org.uk>
> >>Cc: Jason Cooper <jason@lakedaemon.net>
> >>Cc: Andrew Lunn <andrew@lunn.ch>
> >>Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >>Cc: linux-kernel@vger.kernel.org
> >>Cc: linux-arm-kernel@lists.infradead.org
> >>---
> >>  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.

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

[Jason Cooper]

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 <sebastian.hesselbarth@gmail.com>
> >>---
> >>Cc: Russell King <linux@arm.linux.org.uk>
> >>Cc: Jason Cooper <jason@lakedaemon.net>
> >>Cc: Andrew Lunn <andrew@lunn.ch>
> >>Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >>Cc: linux-kernel at vger.kernel.org
> >>Cc: linux-arm-kernel at lists.infradead.org
> >>---
> >>  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 at 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.

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

[Sebastian Hesselbarth]

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

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 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

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

[Sebastian Hesselbarth]

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

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 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 at 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 at 0 {
+		compatible = "st,m25l1605d";
+		spi-max-frequency = <86000000>;
+		reg = <0>;
+	};
+};
+
+&pcie {
+	status = "okay";
+	/* Fresco Logic USB3.0 xHCI controller */
+	pcie-port at 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 at 1 {
+		status = "okay";
+		reset-gpios = <&gpio0 25 1>;
+	};
+};
-- 
1.7.10.4

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 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

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

[Sebastian Hesselbarth]

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 <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 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

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

[Bjorn Helgaas]

On Mon, Aug 12, 2013 at 12:46 PM, Sebastian Hesselbarth
<sebastian.hesselbarth@gmail.com> 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 <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-pci@vger.kernel.org
> --
> 1.7.10.4
>

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

[Bjorn Helgaas]

On Mon, Aug 12, 2013 at 12:46 PM, Sebastian Hesselbarth
<sebastian.hesselbarth@gmail.com> 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 <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: devicetree at vger.kernel.org
> Cc: linux-doc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-pci at vger.kernel.org
> --
> 1.7.10.4
>