[PATCH v3 00/20] USB support for Armada 38x and Armada 375

[PATCH v3 00/20] USB support for Armada 38x and Armada 375

[Gregory CLEMENT]

This patch set adds the USB support for the Armada 38x Armada
375. These SoCs use an xHCI but still need specific initialization,
mainly to setup the windows memory on the mbus. They also use the same
controller that the other mvebu SoC for EHCI.

Since the 2nd version I converted the usb cluster driver in a PHY
driver. While I was working on it I found a bug on ehci-orion which I
fixed in the 1st patch.

The other noticeable change was that in order to be able to use the
clocks I also added private platform data for xHCI.

In the meantime I also received the A0 version of the Armada 375 so I
removed all the workaround related to the very earlier version of the
SoC, indeed there were very few boards with this version of the SoC.


This series is also available in
the branch USB-375-38x-3.15-rc1-V3
https://github.com/MISL-EBU-System-SW/mainline-public.git

Thanks,

Gregory CLEMENT (20):
  usb: ehci-orion: Fix clock reference leaking
  usb: ehci-orion: Add the optional PHY support
  usb: host: xhci-plat: Sort the headers in alphabetic order
  usb: xhci: add a platform-private field
  usb: host: xhci-plat: Add clocks support
  usb: host: xhci-plat: Add support for the Armada 38x
  xhci-platform: Add a new controller using xhci: Armada 38x
  ARM: mvebu: Add Device Tree description of xHCI hosts on Armada 38x
  ARM: mvebu: Add Device Tree description of the EHCI host on Armada 38x
  ARM: mvebu: Add USB3 support for Armada 38x
  ARM: configs: Add usb_xhci_mvebu to mvebu_v7_defconfig
  ARM: configs: Add usb_xhci_mvebu to multi_v7_defconfig
  usb: host: xhci-plat: Add support for the Armada 375
  xhci-platform: Add a new controller using xHCI: Armada 375
  ARM: mvebu: Add Device Tree description of USB cluster controller on
    Armada 375
  dt: binding: Armada 375 USB cluster
  phy: Add support for USB cluster on the Armada 375 SoC
  ARM: mvebu: Add USB3 support for Armada 375
  ARM: mvebu: Add Device Tree description of the xHCI host on Armada 375
  ARM: mvebu: Add Device Tree description of the EHCI host on Armada 375

 .../bindings/phy/armada-375-usb-phy-cluster.txt    |  19 +++
 Documentation/devicetree/bindings/usb/usb-xhci.txt |   4 +-
 arch/arm/boot/dts/armada-375-db.dts                |   8 ++
 arch/arm/boot/dts/armada-375.dtsi                  |  34 +++++
 arch/arm/boot/dts/armada-385-db.dts                |  12 ++
 arch/arm/boot/dts/armada-385-rd.dts                |   4 +
 arch/arm/boot/dts/armada-38x.dtsi                  |  25 ++++
 arch/arm/configs/multi_v7_defconfig                |   1 +
 arch/arm/configs/mvebu_v7_defconfig                |   1 +
 arch/arm/mach-mvebu/Kconfig                        |   2 +
 drivers/phy/Kconfig                                |   5 +
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-armada375-usb2.c                   | 154 +++++++++++++++++++++
 drivers/usb/host/Kconfig                           |   7 +
 drivers/usb/host/Makefile                          |   1 +
 drivers/usb/host/ehci-orion.c                      |  68 ++++++---
 drivers/usb/host/xhci-mvebu.c                      |  71 ++++++++++
 drivers/usb/host/xhci-mvebu.h                      |  21 +++
 drivers/usb/host/xhci-plat.c                       |  74 +++++++++-
 drivers/usb/host/xhci.h                            |   3 +
 20 files changed, 491 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/armada-375-usb-phy-cluster.txt
 create mode 100644 drivers/phy/phy-armada375-usb2.c
 create mode 100644 drivers/usb/host/xhci-mvebu.c
 create mode 100644 drivers/usb/host/xhci-mvebu.h

-- 
1.8.1.2

[PATCH v3 01/20] usb: ehci-orion: Fix clock reference leaking

[Gregory CLEMENT]

In order to disable the clock while the module was removing, a call to
devm_clk_get() was made. This was wrong and lead to a leak module
ref-counts.

In order to have a reference of the clock get, a private structure was
added using the override mechanism provided by the ehci framework.

The bug was introduced in v3.6, however the ehci framework allowing to
use the override mechanism have only been introduced in v3.8, so this
patch won't apply before it.

Fixes: 8c869edaee07c623066266827371235fb9c12e01 ('ARM: Orion: EHCI: Add support for enabling clocks')
Cc: <stable@vger.kernel.org> # v3.8+
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 drivers/usb/host/ehci-orion.c | 49 +++++++++++++++++++++++++++----------------
 1 file changed, 31 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index 30d35e5e503a..d6c19c37c76b 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -42,6 +42,12 @@
 
 #define DRIVER_DESC "EHCI orion driver"
 
+#define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
+
+struct orion_ehci_hcd {
+	struct clk *clk;
+};
+
 static const char hcd_name[] = "ehci-orion";
 
 static struct hc_driver __read_mostly ehci_orion_hc_driver;
@@ -137,6 +143,10 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
 	}
 }
 
+static const struct ehci_driver_overrides orion_overrides __initdata = {
+	.extra_priv_size =	sizeof(struct orion_ehci_hcd),
+};
+
 static int ehci_orion_drv_probe(struct platform_device *pdev)
 {
 	struct orion_ehci_data *pd = dev_get_platdata(&pdev->dev);
@@ -144,10 +154,10 @@ static int ehci_orion_drv_probe(struct platform_device *pdev)
 	struct resource *res;
 	struct usb_hcd *hcd;
 	struct ehci_hcd *ehci;
-	struct clk *clk;
 	void __iomem *regs;
 	int irq, err;
 	enum orion_ehci_phy_ver phy_version;
+	struct orion_ehci_hcd *priv;
 
 	if (usb_disabled())
 		return -ENODEV;
@@ -190,17 +200,11 @@ static int ehci_orion_drv_probe(struct platform_device *pdev)
 		goto err1;
 	}
 
-	/* Not all platforms can gate the clock, so it is not
-	   an error if the clock does not exists. */
-	clk = devm_clk_get(&pdev->dev, NULL);
-	if (!IS_ERR(clk))
-		clk_prepare_enable(clk);
-
 	hcd = usb_create_hcd(&ehci_orion_hc_driver,
 			&pdev->dev, dev_name(&pdev->dev));
 	if (!hcd) {
 		err = -ENOMEM;
-		goto err2;
+		goto err1;
 	}
 
 	hcd->rsrc_start = res->start;
@@ -211,6 +215,15 @@ static int ehci_orion_drv_probe(struct platform_device *pdev)
 	ehci->caps = hcd->regs + 0x100;
 	hcd->has_tt = 1;
 
+	priv = hcd_to_orion_priv(hcd);
+	/*
+	 * Not all platforms can gate the clock, so it is not an error if
+	 * the clock does not exists.
+	 */
+	priv->clk = devm_clk_get(&pdev->dev, NULL);
+	if (!IS_ERR(priv->clk))
+		clk_prepare_enable(priv->clk);
+
 	/*
 	 * (Re-)program MBUS remapping windows if we are asked to.
 	 */
@@ -240,16 +253,16 @@ static int ehci_orion_drv_probe(struct platform_device *pdev)
 
 	err = usb_add_hcd(hcd, irq, IRQF_SHARED);
 	if (err)
-		goto err3;
+		goto err2;
 
 	device_wakeup_enable(hcd->self.controller);
 	return 0;
 
-err3:
-	usb_put_hcd(hcd);
 err2:
-	if (!IS_ERR(clk))
-		clk_disable_unprepare(clk);
+	usb_put_hcd(hcd);
+
+	if (!IS_ERR(priv->clk))
+		clk_disable_unprepare(priv->clk);
 err1:
 	dev_err(&pdev->dev, "init %s fail, %d\n",
 		dev_name(&pdev->dev), err);
@@ -260,14 +273,14 @@ err1:
 static int ehci_orion_drv_remove(struct platform_device *pdev)
 {
 	struct usb_hcd *hcd = platform_get_drvdata(pdev);
-	struct clk *clk;
+	struct orion_ehci_hcd *priv = hcd_to_orion_priv(hcd);
 
 	usb_remove_hcd(hcd);
 	usb_put_hcd(hcd);
 
-	clk = devm_clk_get(&pdev->dev, NULL);
-	if (!IS_ERR(clk))
-		clk_disable_unprepare(clk);
+	if (!IS_ERR(priv->clk))
+		clk_disable_unprepare(priv->clk);
+
 	return 0;
 }
 
@@ -295,7 +308,7 @@ static int __init ehci_orion_init(void)
 
 	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
 
-	ehci_init_driver(&ehci_orion_hc_driver, NULL);
+	ehci_init_driver(&ehci_orion_hc_driver, &orion_overrides);
 	return platform_driver_register(&ehci_orion_driver);
 }
 module_init(ehci_orion_init);
-- 
1.8.1.2

Re: [PATCH v3 01/20] usb: ehci-orion: Fix clock reference leaking

[Alan Stern]

On Tue, 6 May 2014, Gregory CLEMENT wrote:

> In order to disable the clock while the module was removing, a call to
> devm_clk_get() was made. This was wrong and lead to a leak module
> ref-counts.
> 
> In order to have a reference of the clock get, a private structure was
> added using the override mechanism provided by the ehci framework.
> 
> The bug was introduced in v3.6, however the ehci framework allowing to
> use the override mechanism have only been introduced in v3.8, so this
> patch won't apply before it.
> 
> Fixes: 8c869edaee07c623066266827371235fb9c12e01 ('ARM: Orion: EHCI: Add support for enabling clocks')
> Cc: <stable@vger.kernel.org> # v3.8+
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


>  	hcd = usb_create_hcd(&ehci_orion_hc_driver,
>  			&pdev->dev, dev_name(&pdev->dev));
>  	if (!hcd) {
>  		err = -ENOMEM;
> -		goto err2;
> +		goto err1;
>  	}
>  
>  	hcd->rsrc_start = res->start;
> @@ -211,6 +215,15 @@ static int ehci_orion_drv_probe(struct platform_device *pdev)
>  	ehci->caps = hcd->regs + 0x100;
>  	hcd->has_tt = 1;
>  
> +	priv = hcd_to_orion_priv(hcd);
> +	/*
> +	 * Not all platforms can gate the clock, so it is not an error if
> +	 * the clock does not exists.
> +	 */
> +	priv->clk = devm_clk_get(&pdev->dev, NULL);
> +	if (!IS_ERR(priv->clk))
> +		clk_prepare_enable(priv->clk);
> +
>  	/*
>  	 * (Re-)program MBUS remapping windows if we are asked to.
>  	 */
> @@ -240,16 +253,16 @@ static int ehci_orion_drv_probe(struct platform_device *pdev)
>  
>  	err = usb_add_hcd(hcd, irq, IRQF_SHARED);
>  	if (err)
> -		goto err3;
> +		goto err2;
>  
>  	device_wakeup_enable(hcd->self.controller);
>  	return 0;
>  
> -err3:
> -	usb_put_hcd(hcd);
>  err2:
> -	if (!IS_ERR(clk))
> -		clk_disable_unprepare(clk);
> +	usb_put_hcd(hcd);

At this point, priv has just become a dangling pointer, because it
points to something that was allocated along with hcd.

> +
> +	if (!IS_ERR(priv->clk))
> +		clk_disable_unprepare(priv->clk);

And now you are dereferencing memory that has been deallocated.  The
real problem is that you get and enable the clock _after_ creating hcd,
but you don't disable it _before_ deallocating hcd.

>  err1:
>  	dev_err(&pdev->dev, "init %s fail, %d\n",
>  		dev_name(&pdev->dev), err);
> @@ -260,14 +273,14 @@ err1:
>  static int ehci_orion_drv_remove(struct platform_device *pdev)
>  {
>  	struct usb_hcd *hcd = platform_get_drvdata(pdev);
> -	struct clk *clk;
> +	struct orion_ehci_hcd *priv = hcd_to_orion_priv(hcd);
>  
>  	usb_remove_hcd(hcd);
>  	usb_put_hcd(hcd);
>  
> -	clk = devm_clk_get(&pdev->dev, NULL);
> -	if (!IS_ERR(clk))
> -		clk_disable_unprepare(clk);
> +	if (!IS_ERR(priv->clk))
> +		clk_disable_unprepare(priv->clk);

This has the same problem as above.

Also, for both this patch and 02/20, it would be better to replace the
"errN" labels with something more descriptive, so that it's not
necessary to renumber them every time something changes.

Alan Stern

Re: [PATCH v3 01/20] usb: ehci-orion: Fix clock reference leaking

[Thomas Petazzoni]

Dear Alan Stern,

On Tue, 6 May 2014 10:30:57 -0400 (EDT), Alan Stern wrote:

> >  err2:
> > -	if (!IS_ERR(clk))
> > -		clk_disable_unprepare(clk);
> > +	usb_put_hcd(hcd);
> 
> At this point, priv has just become a dangling pointer, because it
> points to something that was allocated along with hcd.

Right.

> > +
> > +	if (!IS_ERR(priv->clk))
> > +		clk_disable_unprepare(priv->clk);
> 
> And now you are dereferencing memory that has been deallocated.  The
> real problem is that you get and enable the clock _after_ creating hcd,
> but you don't disable it _before_ deallocating hcd.

Correct.

> 
> >  err1:
> >  	dev_err(&pdev->dev, "init %s fail, %d\n",
> >  		dev_name(&pdev->dev), err);
> > @@ -260,14 +273,14 @@ err1:
> >  static int ehci_orion_drv_remove(struct platform_device *pdev)
> >  {
> >  	struct usb_hcd *hcd = platform_get_drvdata(pdev);
> > -	struct clk *clk;
> > +	struct orion_ehci_hcd *priv = hcd_to_orion_priv(hcd);
> >  
> >  	usb_remove_hcd(hcd);
> >  	usb_put_hcd(hcd);
> >  
> > -	clk = devm_clk_get(&pdev->dev, NULL);
> > -	if (!IS_ERR(clk))
> > -		clk_disable_unprepare(clk);
> > +	if (!IS_ERR(priv->clk))
> > +		clk_disable_unprepare(priv->clk);
> 
> This has the same problem as above.

Indeed. Will fix in v4.

> Also, for both this patch and 02/20, it would be better to replace the
> "errN" labels with something more descriptive, so that it's not
> necessary to renumber them every time something changes.

Sure. I've added an additional commit prior to this patch that renames
the goto labels to something more meaningful. This will be part of v4.

Thanks for the review!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH v3 02/20] usb: ehci-orion: Add the optional PHY support

[Gregory CLEMENT]

This commit allows to use the PHY provided through the device tree. It
will be useful for the Armada 375 SoCs. if no PHY is provided then the
behavior of the driver is unchanged.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 drivers/usb/host/ehci-orion.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index d6c19c37c76b..f6d9eb2e33cd 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -15,6 +15,7 @@
 #include <linux/clk.h>
 #include <linux/platform_data/usb-ehci-orion.h>
 #include <linux/of.h>
+#include <linux/phy/phy.h>
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
 #include <linux/usb.h>
@@ -46,6 +47,7 @@
 
 struct orion_ehci_hcd {
 	struct clk *clk;
+	struct phy *phy;
 };
 
 static const char hcd_name[] = "ehci-orion";
@@ -224,6 +226,18 @@ static int ehci_orion_drv_probe(struct platform_device *pdev)
 	if (!IS_ERR(priv->clk))
 		clk_prepare_enable(priv->clk);
 
+
+	priv->phy = devm_phy_get(&pdev->dev, "usb");
+	if (!IS_ERR(priv->phy)) {
+		err = phy_init(priv->phy);
+		if (err)
+			goto err2;
+
+		err = phy_power_on(priv->phy);
+		if (err)
+			goto err3;
+	}
+
 	/*
 	 * (Re-)program MBUS remapping windows if we are asked to.
 	 */
@@ -253,14 +267,18 @@ static int ehci_orion_drv_probe(struct platform_device *pdev)
 
 	err = usb_add_hcd(hcd, irq, IRQF_SHARED);
 	if (err)
-		goto err2;
+		goto err4;
 
 	device_wakeup_enable(hcd->self.controller);
 	return 0;
 
-err2:
+err4:
 	usb_put_hcd(hcd);
 
+err3:
+	phy_exit(priv->phy);
+
+err2:
 	if (!IS_ERR(priv->clk))
 		clk_disable_unprepare(priv->clk);
 err1:
@@ -278,6 +296,9 @@ static int ehci_orion_drv_remove(struct platform_device *pdev)
 	usb_remove_hcd(hcd);
 	usb_put_hcd(hcd);
 
+	if (!IS_ERR(priv->phy))
+		phy_exit(priv->phy);
+
 	if (!IS_ERR(priv->clk))
 		clk_disable_unprepare(priv->clk);
 
-- 
1.8.1.2

Re: [PATCH v3 02/20] usb: ehci-orion: Add the optional PHY support

[Andrew Lunn]

On Tue, May 06, 2014 at 02:13:57AM +0200, Gregory CLEMENT wrote:
> This commit allows to use the PHY provided through the device tree. It
> will be useful for the Armada 375 SoCs. if no PHY is provided then the
> behavior of the driver is unchanged.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>  drivers/usb/host/ehci-orion.c | 25 +++++++++++++++++++++++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
> index d6c19c37c76b..f6d9eb2e33cd 100644
> --- a/drivers/usb/host/ehci-orion.c
> +++ b/drivers/usb/host/ehci-orion.c
> @@ -15,6 +15,7 @@
>  #include <linux/clk.h>
>  #include <linux/platform_data/usb-ehci-orion.h>
>  #include <linux/of.h>
> +#include <linux/phy/phy.h>
>  #include <linux/of_device.h>
>  #include <linux/of_irq.h>
>  #include <linux/usb.h>
> @@ -46,6 +47,7 @@
>  
>  struct orion_ehci_hcd {
>  	struct clk *clk;
> +	struct phy *phy;
>  };
>  
>  static const char hcd_name[] = "ehci-orion";
> @@ -224,6 +226,18 @@ static int ehci_orion_drv_probe(struct platform_device *pdev)
>  	if (!IS_ERR(priv->clk))
>  		clk_prepare_enable(priv->clk);
>  
> +
> +	priv->phy = devm_phy_get(&pdev->dev, "usb");
> +	if (!IS_ERR(priv->phy)) {
> +		err = phy_init(priv->phy);
> +		if (err)
> +			goto err2;
> +
> +		err = phy_power_on(priv->phy);
> +		if (err)
> +			goto err3;
> +	}

Hi Gregory

What about EPROBE_DEFERRED?

     Andrew

Re: [PATCH v3 02/20] usb: ehci-orion: Add the optional PHY support

[Thomas Petazzoni]

Dear Andrew Lunn,

On Tue, 6 May 2014 15:33:41 +0200, Andrew Lunn wrote:

> > +	priv->phy = devm_phy_get(&pdev->dev, "usb");
> > +	if (!IS_ERR(priv->phy)) {
> > +		err = phy_init(priv->phy);
> > +		if (err)
> > +			goto err2;
> > +
> > +		err = phy_power_on(priv->phy);
> > +		if (err)
> > +			goto err3;
> > +	}
> 
> Hi Gregory
> 
> What about EPROBE_DEFERRED?

In v4 (to be submitted soon), I've changed this to:

	priv->phy = devm_phy_optional_get(&pdev->dev, "usb");
	if (IS_ERR(priv->phy)) {
		err = PTR_ERR(priv->phy);
		goto err_phy_get;
	} else {
		err = phy_init(priv->phy);
		if (err)
			goto err_phy_init;

		err = phy_power_on(priv->phy);
		if (err)
			goto err_phy_power_on;
	}

Thanks to devm_phy_optional_get(), the fact of not having a PHY in the
DT is not considered an error. So on any error from
devm_phy_optional_get() (including -EPROBE_DEFER), we simply bail out.
Does this looks good?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/20] usb: ehci-orion: Add the optional PHY support

[Andrew Lunn]

On Wed, May 07, 2014 at 11:40:06AM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Tue, 6 May 2014 15:33:41 +0200, Andrew Lunn wrote:
> 
> > > +	priv->phy = devm_phy_get(&pdev->dev, "usb");
> > > +	if (!IS_ERR(priv->phy)) {
> > > +		err = phy_init(priv->phy);
> > > +		if (err)
> > > +			goto err2;
> > > +
> > > +		err = phy_power_on(priv->phy);
> > > +		if (err)
> > > +			goto err3;
> > > +	}
> > 
> > Hi Gregory
> > 
> > What about EPROBE_DEFERRED?
> 
> In v4 (to be submitted soon), I've changed this to:
> 
> 	priv->phy = devm_phy_optional_get(&pdev->dev, "usb");
> 	if (IS_ERR(priv->phy)) {
> 		err = PTR_ERR(priv->phy);
> 		goto err_phy_get;
> 	} else {
> 		err = phy_init(priv->phy);
> 		if (err)
> 			goto err_phy_init;
> 
> 		err = phy_power_on(priv->phy);
> 		if (err)
> 			goto err_phy_power_on;
> 	}
> 
> Thanks to devm_phy_optional_get(), the fact of not having a PHY in the
> DT is not considered an error. So on any error from
> devm_phy_optional_get() (including -EPROBE_DEFER), we simply bail out.
> Does this looks good?

Hi Thomas

That looks good.

To avoid the SATA phy problems we had last time, i would like to test
this on a few systems. Please could you let me know what branch v4 is
in when it is ready.

   Thanks
	Andrew

Re: [PATCH v3 02/20] usb: ehci-orion: Add the optional PHY support

[Thomas Petazzoni]

Dear Andrew Lunn,

On Wed, 7 May 2014 15:21:50 +0200, Andrew Lunn wrote:

> > Thanks to devm_phy_optional_get(), the fact of not having a PHY in the
> > DT is not considered an error. So on any error from
> > devm_phy_optional_get() (including -EPROBE_DEFER), we simply bail out.
> > Does this looks good?
> 
> Hi Thomas
> 
> That looks good.
> 
> To avoid the SATA phy problems we had last time, i would like to test
> this on a few systems. Please could you let me know what branch v4 is
> in when it is ready.

Sure. It's now up at
https://github.com/MISL-EBU-System-SW/mainline-public/tree/USB-375-38x-3.15-rc1-V4.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH v3 05/20] usb: host: xhci-plat: Add clocks support

[Gregory CLEMENT]

Some platform (such as the Armada 38x ones) can gate the clock of
their USB controller. This patch add the support for the clock, by
enabling them during probe and disabling them on remove.

As not all platforms have clock support then enabling and disabling
the clocks have been placed in separate functions. Then if the clocks
are not supported we still can use the same calls, and there is no

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 drivers/usb/host/xhci-plat.c | 57 +++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 54 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index f5351af4b2c5..bb37b941c8ec 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -11,6 +11,7 @@
  * version 2 as published by the Free Software Foundation.
  */
 
+#include <linux/clk.h>
 #include <linux/dma-mapping.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -19,6 +20,10 @@
 
 #include "xhci.h"
 
+struct xhci_plat_priv {
+	struct clk *clk;
+};
+
 static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
 {
 	/*
@@ -38,7 +43,8 @@ static int xhci_plat_setup(struct usb_hcd *hcd)
 static const struct hc_driver xhci_plat_xhci_driver = {
 	.description =		"xhci-hcd",
 	.product_desc =		"xHCI Host Controller",
-	.hcd_priv_size =	sizeof(struct xhci_hcd *),
+	.hcd_priv_size =	sizeof(struct xhci_hcd *) +
+				sizeof(struct xhci_plat_priv),
 
 	/*
 	 * generic hardware linkage
@@ -85,6 +91,40 @@ static const struct hc_driver xhci_plat_xhci_driver = {
 	.bus_resume =		xhci_bus_resume,
 };
 
+static int xhci_plat_enable_clk(struct platform_device *pdev)
+{
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);
+	struct xhci_plat_priv *priv = (struct xhci_plat_priv *) xhci->priv;
+
+	priv->clk = devm_clk_get(&pdev->dev, NULL);
+
+	/*
+	 * Not all platforms have a clk so it is not an error if the
+	 * clock does not exists.
+	 */
+	if (IS_ERR(priv->clk))
+		return 0;
+
+	return clk_prepare_enable(priv->clk);
+}
+
+static void xhci_plat_disable_clk(struct platform_device *pdev)
+{
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);
+	struct xhci_plat_priv *priv = (struct xhci_plat_priv *) xhci->priv;
+
+	/*
+	 * Not all platforms have a clk so it is not an error if the
+	 * clock does not exists.
+	 */
+	if (IS_ERR(priv->clk))
+		return;
+
+	clk_disable_unprepare(priv->clk);
+}
+
 static int xhci_plat_probe(struct platform_device *pdev)
 {
 	const struct hc_driver	*driver;
@@ -118,7 +158,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
 
 	hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
 	if (!hcd)
-		return -ENOMEM;
+		ret = -ENOMEM;
 
 	hcd->rsrc_start = res->start;
 	hcd->rsrc_len = resource_size(res);
@@ -140,6 +180,13 @@ static int xhci_plat_probe(struct platform_device *pdev)
 	ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
 	if (ret)
 		goto unmap_registers;
+
+	ret = xhci_plat_enable_clk(pdev);
+	if (ret) {
+		dev_dbg(&pdev->dev, "error enabling clocks\n");
+		goto dealloc_usb2_hcd;
+	}
+
 	device_wakeup_enable(hcd->self.controller);
 
 	/* USB 2.0 roothub is stored in the platform_device now. */
@@ -149,7 +196,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
 			dev_name(&pdev->dev), hcd);
 	if (!xhci->shared_hcd) {
 		ret = -ENOMEM;
-		goto dealloc_usb2_hcd;
+		goto disable_clk;
 	}
 
 	/*
@@ -170,6 +217,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
 put_usb3_hcd:
 	usb_put_hcd(xhci->shared_hcd);
 
+disable_clk:
+	xhci_plat_disable_clk(pdev);
+
 dealloc_usb2_hcd:
 	usb_remove_hcd(hcd);
 
@@ -193,6 +243,7 @@ static int xhci_plat_remove(struct platform_device *dev)
 	usb_remove_hcd(xhci->shared_hcd);
 	usb_put_hcd(xhci->shared_hcd);
 
+	xhci_plat_disable_clk(dev);
 	usb_remove_hcd(hcd);
 	iounmap(hcd->regs);
 	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
-- 
1.8.1.2

Re: [PATCH v3 05/20] usb: host: xhci-plat: Add clocks support

[Felipe Balbi]

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

On Tue, May 06, 2014 at 02:14:00AM +0200, Gregory CLEMENT wrote:
> @@ -118,7 +158,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  
>  	hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
>  	if (!hcd)
> -		return -ENOMEM;
> +		ret = -ENOMEM;

regression

-- 
balbi

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

Re: [PATCH v3 05/20] usb: host: xhci-plat: Add clocks support

[Jason Cooper]

On Tue, May 06, 2014 at 02:14:00AM +0200, Gregory CLEMENT wrote:
> Some platform (such as the Armada 38x ones) can gate the clock of
> their USB controller. This patch add the support for the clock, by
> enabling them during probe and disabling them on remove.
> 
> As not all platforms have clock support then enabling and disabling
> the clocks have been placed in separate functions. Then if the clocks
> are not supported we still can use the same calls, and there is no

... ?

thx,

Jason.

> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>  drivers/usb/host/xhci-plat.c | 57 +++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 54 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index f5351af4b2c5..bb37b941c8ec 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -11,6 +11,7 @@
>   * version 2 as published by the Free Software Foundation.
>   */
>  
> +#include <linux/clk.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
> @@ -19,6 +20,10 @@
>  
>  #include "xhci.h"
>  
> +struct xhci_plat_priv {
> +	struct clk *clk;
> +};
> +
>  static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
>  {
>  	/*
> @@ -38,7 +43,8 @@ static int xhci_plat_setup(struct usb_hcd *hcd)
>  static const struct hc_driver xhci_plat_xhci_driver = {
>  	.description =		"xhci-hcd",
>  	.product_desc =		"xHCI Host Controller",
> -	.hcd_priv_size =	sizeof(struct xhci_hcd *),
> +	.hcd_priv_size =	sizeof(struct xhci_hcd *) +
> +				sizeof(struct xhci_plat_priv),
>  
>  	/*
>  	 * generic hardware linkage
> @@ -85,6 +91,40 @@ static const struct hc_driver xhci_plat_xhci_driver = {
>  	.bus_resume =		xhci_bus_resume,
>  };
>  
> +static int xhci_plat_enable_clk(struct platform_device *pdev)
> +{
> +	struct usb_hcd *hcd = platform_get_drvdata(pdev);
> +	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);
> +	struct xhci_plat_priv *priv = (struct xhci_plat_priv *) xhci->priv;
> +
> +	priv->clk = devm_clk_get(&pdev->dev, NULL);
> +
> +	/*
> +	 * Not all platforms have a clk so it is not an error if the
> +	 * clock does not exists.
> +	 */
> +	if (IS_ERR(priv->clk))
> +		return 0;
> +
> +	return clk_prepare_enable(priv->clk);
> +}
> +
> +static void xhci_plat_disable_clk(struct platform_device *pdev)
> +{
> +	struct usb_hcd *hcd = platform_get_drvdata(pdev);
> +	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);
> +	struct xhci_plat_priv *priv = (struct xhci_plat_priv *) xhci->priv;
> +
> +	/*
> +	 * Not all platforms have a clk so it is not an error if the
> +	 * clock does not exists.
> +	 */
> +	if (IS_ERR(priv->clk))
> +		return;
> +
> +	clk_disable_unprepare(priv->clk);
> +}
> +
>  static int xhci_plat_probe(struct platform_device *pdev)
>  {
>  	const struct hc_driver	*driver;
> @@ -118,7 +158,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  
>  	hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
>  	if (!hcd)
> -		return -ENOMEM;
> +		ret = -ENOMEM;
>  
>  	hcd->rsrc_start = res->start;
>  	hcd->rsrc_len = resource_size(res);
> @@ -140,6 +180,13 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  	ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
>  	if (ret)
>  		goto unmap_registers;
> +
> +	ret = xhci_plat_enable_clk(pdev);
> +	if (ret) {
> +		dev_dbg(&pdev->dev, "error enabling clocks\n");
> +		goto dealloc_usb2_hcd;
> +	}
> +
>  	device_wakeup_enable(hcd->self.controller);
>  
>  	/* USB 2.0 roothub is stored in the platform_device now. */
> @@ -149,7 +196,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  			dev_name(&pdev->dev), hcd);
>  	if (!xhci->shared_hcd) {
>  		ret = -ENOMEM;
> -		goto dealloc_usb2_hcd;
> +		goto disable_clk;
>  	}
>  
>  	/*
> @@ -170,6 +217,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  put_usb3_hcd:
>  	usb_put_hcd(xhci->shared_hcd);
>  
> +disable_clk:
> +	xhci_plat_disable_clk(pdev);
> +
>  dealloc_usb2_hcd:
>  	usb_remove_hcd(hcd);
>  
> @@ -193,6 +243,7 @@ static int xhci_plat_remove(struct platform_device *dev)
>  	usb_remove_hcd(xhci->shared_hcd);
>  	usb_put_hcd(xhci->shared_hcd);
>  
> +	xhci_plat_disable_clk(dev);
>  	usb_remove_hcd(hcd);
>  	iounmap(hcd->regs);
>  	release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
> -- 
> 1.8.1.2
> 

Re: [PATCH v3 05/20] usb: host: xhci-plat: Add clocks support

[Thomas Petazzoni]

Felipe, Gregory,

On Tue,  6 May 2014 02:14:00 +0200, Gregory CLEMENT wrote:

> +struct xhci_plat_priv {
> +	struct clk *clk;
> +};
> +
>  static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
>  {
>  	/*
> @@ -38,7 +43,8 @@ static int xhci_plat_setup(struct usb_hcd *hcd)
>  static const struct hc_driver xhci_plat_xhci_driver = {
>  	.description =		"xhci-hcd",
>  	.product_desc =		"xHCI Host Controller",
> -	.hcd_priv_size =	sizeof(struct xhci_hcd *),
> +	.hcd_priv_size =	sizeof(struct xhci_hcd *) +
> +				sizeof(struct xhci_plat_priv),
>  
>  	/*
>  	 * generic hardware linkage
> @@ -85,6 +91,40 @@ static const struct hc_driver xhci_plat_xhci_driver = {
>  	.bus_resume =		xhci_bus_resume,
>  };
>  
> +static int xhci_plat_enable_clk(struct platform_device *pdev)
> +{
> +	struct usb_hcd *hcd = platform_get_drvdata(pdev);
> +	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);
> +	struct xhci_plat_priv *priv = (struct xhci_plat_priv *) xhci->priv;

Unless I misread the USB code, I believe the way this patch proposes to
handle private data for the XHCI HCD is wrong and leads to memory
corruption.

By growing the size .hcd_priv_size, it increases the memory size
pointed by usb_hcd->hcd_priv. However, this pointer has nothing to do
with xhci->priv, which points to the end of the xhci_hcd structure.

I believe the confusion comes from the fact that OHCI and EHCI do
allocate the entire ohci_hcd and ehci_hcd structure as part of the
usb_hcd private data:

	.hcd_priv_size =	sizeof(struct ohci_hcd),

or

	.hcd_priv_size = 	sizeof(struct ehci_hcd),

In this case, enlarging hcd_priv_size, and having a ehci->priv or
ohci->priv pointing to the end of {ohci,ehci}_hcd structures works fine.

However, in the XHCI case, the usb_hcd private data is not used to hold
the entire xhci_hcd structure, but only a *pointer* to it:

	.hcd_priv_size =	sizeof(struct xhci_hcd *),

Therefore, adding more size to .hcd_priv_size isn't going to give extra
room at the end of the xhci_hcd structure. And therefore the whole
strategy of using xhci->priv pointing at the end of xhci_hcd is broken.

In v4, what I will do is simply to add a 'struct clk *' member to
xhci_hcd. A clock is, like a register area or an interrupt, a very
typical resource for any device, so it makes sense to have a pointer to
it from xhci_hcd. If someone complains that the clock would only be
used by xhci_plat, then I could point him to the fact that xhci_hcd
already contains members such as msix_count and msix_entries, that are
only used in xhci_pci :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 08/20] ARM: mvebu: Add Device Tree description of xHCI hosts on Armada 38x

[Gregory CLEMENT]

The Marvell Armada 38x SoCs contains two xHCI host. This commit adds
the Device Tree description of those interfaces at the SoC level, and
also enables the two USB3 ports on the Armada 385 DB platform and one
USB3 port on the Armada 385 RD platform.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/boot/dts/armada-385-db.dts |  8 ++++++++
 arch/arm/boot/dts/armada-385-rd.dts |  4 ++++
 arch/arm/boot/dts/armada-38x.dtsi   | 17 +++++++++++++++++
 3 files changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-385-db.dts b/arch/arm/boot/dts/armada-385-db.dts
index 6828d77696a6..d5db1466da82 100644
--- a/arch/arm/boot/dts/armada-385-db.dts
+++ b/arch/arm/boot/dts/armada-385-db.dts
@@ -101,6 +101,14 @@
 					reg = <0x1000000 0x3f000000>;
 				};
 			};
+
+			usb3@f0000 {
+				status = "okay";
+			};
+
+			usb3@f8000 {
+				status = "okay";
+			};
 		};
 
 		pcie-controller {
diff --git a/arch/arm/boot/dts/armada-385-rd.dts b/arch/arm/boot/dts/armada-385-rd.dts
index 45250c88814b..a505fe94ff37 100644
--- a/arch/arm/boot/dts/armada-385-rd.dts
+++ b/arch/arm/boot/dts/armada-385-rd.dts
@@ -77,6 +77,10 @@
 					reg = <1>;
 				};
 			};
+
+			usb3@f0000 {
+				status = "okay";
+			};
 		};
 
 		pcie-controller {
diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index a064f59da02d..5913ce1cc601 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -355,6 +355,23 @@
 				clocks = <&coredivclk 0>;
 				status = "disabled";
 			};
+
+			usb3@f0000 {
+				compatible = "marvell,armada-380-xhci";
+				reg = <0xf0000 0x3fff>,<0xf4000 0x3fff>;
+				interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&gateclk 9>;
+				status = "disabled";
+			};
+
+			usb3@f8000 {
+				compatible = "marvell,armada-380-xhci";
+				reg = <0xf8000 0x3fff>,<0xfc000 0x3fff>;
+				interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&gateclk 10>;
+				status = "disabled";
+			};
+
 		};
 	};
 
-- 
1.8.1.2

Re: [PATCH v3 08/20] ARM: mvebu: Add Device Tree description of xHCI hosts on Armada 38x

[Andrew Lunn]

On Tue, May 06, 2014 at 02:14:03AM +0200, Gregory CLEMENT wrote:
> The Marvell Armada 38x SoCs contains two xHCI host. This commit adds
> the Device Tree description of those interfaces at the SoC level, and
> also enables the two USB3 ports on the Armada 385 DB platform and one
> USB3 port on the Armada 385 RD platform.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>  arch/arm/boot/dts/armada-385-db.dts |  8 ++++++++
>  arch/arm/boot/dts/armada-385-rd.dts |  4 ++++
>  arch/arm/boot/dts/armada-38x.dtsi   | 17 +++++++++++++++++
>  3 files changed, 29 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/armada-385-db.dts b/arch/arm/boot/dts/armada-385-db.dts
> index 6828d77696a6..d5db1466da82 100644
> --- a/arch/arm/boot/dts/armada-385-db.dts
> +++ b/arch/arm/boot/dts/armada-385-db.dts
> @@ -101,6 +101,14 @@
>  					reg = <0x1000000 0x3f000000>;
>  				};
>  			};
> +
> +			usb3@f0000 {
> +				status = "okay";
> +			};
> +
> +			usb3@f8000 {
> +				status = "okay";
> +			};
>  		};
>  
>  		pcie-controller {
> diff --git a/arch/arm/boot/dts/armada-385-rd.dts b/arch/arm/boot/dts/armada-385-rd.dts
> index 45250c88814b..a505fe94ff37 100644
> --- a/arch/arm/boot/dts/armada-385-rd.dts
> +++ b/arch/arm/boot/dts/armada-385-rd.dts
> @@ -77,6 +77,10 @@
>  					reg = <1>;
>  				};
>  			};
> +
> +			usb3@f0000 {
> +				status = "okay";
> +			};
>  		};
>  
>  		pcie-controller {
> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
> index a064f59da02d..5913ce1cc601 100644
> --- a/arch/arm/boot/dts/armada-38x.dtsi
> +++ b/arch/arm/boot/dts/armada-38x.dtsi
> @@ -355,6 +355,23 @@
>  				clocks = <&coredivclk 0>;
>  				status = "disabled";
>  			};
> +
> +			usb3@f0000 {
> +				compatible = "marvell,armada-380-xhci";
> +				reg = <0xf0000 0x3fff>,<0xf4000 0x3fff>;

0x3fff?

I would expect that to be 0x4000.

	Andrew

[PATCH v3 13/20] usb: host: xhci-plat: Add support for the Armada 375

[Gregory CLEMENT]

For the Armada 375 SoC which comes with an xhci controller. Currently
the quirk is the same that the Armada 380/385 one, but by introducing
a new compatible string it will allow to make the driver evolve
seamless.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 drivers/usb/host/xhci-plat.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index d12ba56f52da..09639962c0bb 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -152,6 +152,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
 					"marvell,armada-380-xhci"))
 		xhci_mvebu_mbus_init_quirk(pdev);
 
+	if (of_device_is_compatible(pdev->dev.of_node,
+					"marvell,armada-375-xhci"))
+		xhci_mvebu_mbus_init_quirk(pdev);
+
 	/* Initialize dma_mask and coherent_dma_mask to 32-bits */
 	ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
 	if (ret)
@@ -288,6 +292,7 @@ static const struct of_device_id usb_xhci_of_match[] = {
 	{ .compatible = "generic-xhci" },
 	{ .compatible = "xhci-platform" },
 	{ .compatible = "marvell,armada-380-xhci"},
+	{ .compatible = "marvell,armada-375-xhci"},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
-- 
1.8.1.2

[PATCH v3 03/20] usb: host: xhci-plat: Sort the headers in alphabetic order

[Gregory CLEMENT]

Sorting the headers in alphabetic order will help to reduce the conflict
when adding new headers later.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
---
 drivers/usb/host/xhci-plat.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 151901ce1ba9..f5351af4b2c5 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -11,11 +11,11 @@
  * version 2 as published by the Free Software Foundation.
  */
 
-#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
 #include <linux/module.h>
-#include <linux/slab.h>
 #include <linux/of.h>
-#include <linux/dma-mapping.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
 
 #include "xhci.h"
 
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 04/20] usb: xhci: add a platform-private field

[Gregory CLEMENT]

This patch adds an xhci->priv field for private use by xHCI platform
drivers. This field was present for OHCI and EHCI and it was not
needed until now for xHCI. With the introduction of the clock support,
then a private field will be useful, so let's mimic what have been
done for the other HCI.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 drivers/usb/host/xhci.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index d280e9213d08..054017f66246 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1584,6 +1584,9 @@ struct xhci_hcd {
 	u32			port_status_u0;
 /* Compliance Mode Timer Triggered every 2 seconds */
 #define COMP_MODE_RCVRY_MSECS 2000
+
+	/* platform-specific data -- must come last */
+	unsigned long		priv[0] __aligned(sizeof(s64));
 };
 
 /* convert between an HCD pointer and the corresponding EHCI_HCD */
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 04/20] usb: xhci: add a platform-private field

[Felipe Balbi]

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

On Tue, May 06, 2014 at 02:13:59AM +0200, Gregory CLEMENT wrote:
> This patch adds an xhci->priv field for private use by xHCI platform
> drivers. This field was present for OHCI and EHCI and it was not
> needed until now for xHCI. With the introduction of the clock support,
> then a private field will be useful, so let's mimic what have been
> done for the other HCI.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Acked-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>

> ---
>  drivers/usb/host/xhci.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index d280e9213d08..054017f66246 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1584,6 +1584,9 @@ struct xhci_hcd {
>  	u32			port_status_u0;
>  /* Compliance Mode Timer Triggered every 2 seconds */
>  #define COMP_MODE_RCVRY_MSECS 2000
> +
> +	/* platform-specific data -- must come last */
> +	unsigned long		priv[0] __aligned(sizeof(s64));
>  };
>  
>  /* convert between an HCD pointer and the corresponding EHCI_HCD */
> -- 
> 1.8.1.2
> 

-- 
balbi

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

[PATCH v3 06/20] usb: host: xhci-plat: Add support for the Armada 38x

[Gregory CLEMENT]

For the Armada 38x SoCs which come with an xhci controller, specific
initialization must be done during probe related to the MBus windows
configuration. This patch adds the support of this quirk.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 drivers/usb/host/Kconfig      |  7 +++++
 drivers/usb/host/Makefile     |  1 +
 drivers/usb/host/xhci-mvebu.c | 71 +++++++++++++++++++++++++++++++++++++++++++
 drivers/usb/host/xhci-mvebu.h | 21 +++++++++++++
 drivers/usb/host/xhci-plat.c  |  6 ++++
 5 files changed, 106 insertions(+)
 create mode 100644 drivers/usb/host/xhci-mvebu.c
 create mode 100644 drivers/usb/host/xhci-mvebu.h

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3d9e54062d62..e70943fac4a1 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -29,6 +29,13 @@ if USB_XHCI_HCD
 config USB_XHCI_PLATFORM
 	tristate
 
+config USB_XHCI_MVEBU
+	tristate "xHCI support for Marvell Armada 38x"
+	select USB_XHCI_PLATFORM
+	---help---
+	  Say 'Y' to enable the support for the xHCI host controller
+	  found in Marvell Armada 38x ARM SOCs.
+
 endif # USB_XHCI_HCD
 
 config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 7530468c9a4f..7a8db7f7dc01 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -19,6 +19,7 @@ xhci-hcd-$(CONFIG_PCI)	+= xhci-pci.o
 
 ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
 	xhci-hcd-y		+= xhci-plat.o
+	xhci-hcd-$(CONFIG_USB_XHCI_MVEBU)	+= xhci-mvebu.o
 endif
 
 obj-$(CONFIG_USB_WHCI_HCD)	+= whci/
diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
new file mode 100644
index 000000000000..bcfa61a13f5d
--- /dev/null
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -0,0 +1,71 @@
+/*
+ * Copyright (C) 2014 Marvell
+ * Author: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/mbus.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define USB3_MAX_WINDOWS	4
+#define USB3_WIN_CTRL(w)	(0x0 + ((w) * 8))
+#define USB3_WIN_BASE(w)	(0x4 + ((w) * 8))
+
+static void __init xhci_mvebu_mbus_config(void __iomem *base,
+			const struct mbus_dram_target_info *dram)
+{
+	int win;
+
+	/* Clear all existing windows */
+	for (win = 0; win < USB3_MAX_WINDOWS; win++) {
+		writel(0, base + USB3_WIN_CTRL(win));
+		writel(0, base + USB3_WIN_BASE(win));
+	}
+
+	/* Program each DRAM CS in a seperate window */
+	for (win = 0; win < dram->num_cs; win++) {
+		const struct mbus_dram_window *cs = dram->cs + win;
+
+		writel(((cs->size - 1) & 0xffff0000) | (cs->mbus_attr << 8) |
+		       (dram->mbus_dram_target_id << 4) | 1,
+		       base + USB3_WIN_CTRL(win));
+
+		writel((cs->base & 0xffff0000), base + USB3_WIN_BASE(win));
+	}
+}
+
+int xhci_mvebu_mbus_init_quirk(struct platform_device *pdev)
+{
+	struct resource	*res;
+	void __iomem	*base;
+	const struct mbus_dram_target_info *dram;
+	int ret = 0;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!res)
+		return -ENODEV;
+
+	/*
+	 * We don't use devm_ioremap() because this mapping should
+	 * only exists for the duration of this probe function.
+	 */
+	base = ioremap(res->start, resource_size(res));
+	if (!base)
+		return -ENODEV;
+
+	dram = mv_mbus_dram_info();
+	xhci_mvebu_mbus_config(base, dram);
+
+	/*
+	 * This memory area was only needed to configure the MBus
+	 * windows, and is therefore no longer useful.
+	 */
+	iounmap(base);
+
+	return ret;
+}
diff --git a/drivers/usb/host/xhci-mvebu.h b/drivers/usb/host/xhci-mvebu.h
new file mode 100644
index 000000000000..61d09b6e8443
--- /dev/null
+++ b/drivers/usb/host/xhci-mvebu.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2014 Marvell
+ *
+ * Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __LINUX_XHCI_MVEBU_H
+#define __LINUX_XHCI_MVEBU_H
+#if IS_ENABLED(CONFIG_USB_XHCI_MVEBU)
+int xhci_mvebu_mbus_init_quirk(struct platform_device *pdev);
+#else
+static inline int xhci_mvebu_mbus_init_quirk(struct device dev)
+{
+	return 0;
+}
+#endif
+#endif /* __LINUX_XHCI_MVEBU_H */
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index bb37b941c8ec..d12ba56f52da 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
 #include <linux/slab.h>
 
 #include "xhci.h"
+#include "xhci-mvebu.h"
 
 struct xhci_plat_priv {
 	struct clk *clk;
@@ -147,6 +148,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
 	if (!res)
 		return -ENODEV;
 
+	if (of_device_is_compatible(pdev->dev.of_node,
+					"marvell,armada-380-xhci"))
+		xhci_mvebu_mbus_init_quirk(pdev);
+
 	/* Initialize dma_mask and coherent_dma_mask to 32-bits */
 	ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
 	if (ret)
@@ -282,6 +287,7 @@ static const struct dev_pm_ops xhci_plat_pm_ops = {
 static const struct of_device_id usb_xhci_of_match[] = {
 	{ .compatible = "generic-xhci" },
 	{ .compatible = "xhci-platform" },
+	{ .compatible = "marvell,armada-380-xhci"},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 06/20] usb: host: xhci-plat: Add support for the Armada 38x

[Bartlomiej Zolnierkiewicz]

Hi,

On Tuesday, May 06, 2014 02:14:01 AM Gregory CLEMENT wrote:
> For the Armada 38x SoCs which come with an xhci controller, specific
> initialization must be done during probe related to the MBus windows
> configuration. This patch adds the support of this quirk.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>  drivers/usb/host/Kconfig      |  7 +++++
>  drivers/usb/host/Makefile     |  1 +
>  drivers/usb/host/xhci-mvebu.c | 71 +++++++++++++++++++++++++++++++++++++++++++
>  drivers/usb/host/xhci-mvebu.h | 21 +++++++++++++
>  drivers/usb/host/xhci-plat.c  |  6 ++++
>  5 files changed, 106 insertions(+)
>  create mode 100644 drivers/usb/host/xhci-mvebu.c
>  create mode 100644 drivers/usb/host/xhci-mvebu.h
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 3d9e54062d62..e70943fac4a1 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -29,6 +29,13 @@ if USB_XHCI_HCD
>  config USB_XHCI_PLATFORM
>  	tristate
>  
> +config USB_XHCI_MVEBU
> +	tristate "xHCI support for Marvell Armada 38x"

Please limit this driver to mvebu arch and compile testing, i.e.

	depends on ARCH_MVEBU || COMPILE_TEST

> +	select USB_XHCI_PLATFORM
> +	---help---
> +	  Say 'Y' to enable the support for the xHCI host controller
> +	  found in Marvell Armada 38x ARM SOCs.
> +
>  endif # USB_XHCI_HCD
>  
>  config USB_EHCI_HCD

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 06/20] usb: host: xhci-plat: Add support for the Armada 38x

[Arnd Bergmann]

On Tuesday 06 May 2014 13:34:46 Bartlomiej Zolnierkiewicz wrote:
> On Tuesday, May 06, 2014 02:14:01 AM Gregory CLEMENT wrote:
> > For the Armada 38x SoCs which come with an xhci controller, specific
> > initialization must be done during probe related to the MBus windows
> > configuration. This patch adds the support of this quirk.
> > 
> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > ---
> >  drivers/usb/host/Kconfig      |  7 +++++
> >  drivers/usb/host/Makefile     |  1 +
> >  drivers/usb/host/xhci-mvebu.c | 71 +++++++++++++++++++++++++++++++++++++++++++
> >  drivers/usb/host/xhci-mvebu.h | 21 +++++++++++++
> >  drivers/usb/host/xhci-plat.c  |  6 ++++
> >  5 files changed, 106 insertions(+)
> >  create mode 100644 drivers/usb/host/xhci-mvebu.c
> >  create mode 100644 drivers/usb/host/xhci-mvebu.h
> > 
> > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > index 3d9e54062d62..e70943fac4a1 100644
> > --- a/drivers/usb/host/Kconfig
> > +++ b/drivers/usb/host/Kconfig
> > @@ -29,6 +29,13 @@ if USB_XHCI_HCD
> >  config USB_XHCI_PLATFORM
> >       tristate
> >  
> > +config USB_XHCI_MVEBU
> > +     tristate "xHCI support for Marvell Armada 38x"
> 
> Please limit this driver to mvebu arch and compile testing, i.e.
> 
>         depends on ARCH_MVEBU || COMPILE_TEST

I think it actually needs a dependency on MVEBU_MBUS.

You probably need something like

	depends on MVEBU_MBUS=y || (MVEBU_MBUS=m && USB_XHCI=m)

Also, having the option 'tristate' makes no sense, since you
can't have it as a loadable module.

	Arnd

Re: [PATCH v3 06/20] usb: host: xhci-plat: Add support for the Armada 38x

[Thomas Petazzoni]

Dear Arnd Bergmann,

On Tue, 06 May 2014 13:57:44 +0200, Arnd Bergmann wrote:

> > Please limit this driver to mvebu arch and compile testing, i.e.
> > 
> >         depends on ARCH_MVEBU || COMPILE_TEST
> 
> I think it actually needs a dependency on MVEBU_MBUS.

That's not what we do for any of the other drivers that use the
MVEBU_MBUS functions.

> You probably need something like
> 
> 	depends on MVEBU_MBUS=y || (MVEBU_MBUS=m && USB_XHCI=m)

MVEBU_MBUS is a bool, so there is no way is can be =m.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH v3 06/20] usb: host: xhci-plat: Add support for the Armada 38x

[Arnd Bergmann]

On Tuesday 06 May 2014 14:10:23 Thomas Petazzoni wrote:
> On Tue, 06 May 2014 13:57:44 +0200, Arnd Bergmann wrote:
> 
> > > Please limit this driver to mvebu arch and compile testing, i.e.
> > > 
> > >         depends on ARCH_MVEBU || COMPILE_TEST
> > 
> > I think it actually needs a dependency on MVEBU_MBUS.
> 
> That's not what we do for any of the other drivers that use the
> MVEBU_MBUS functions.

Fair enough. I guess using ARCH_MVEBU as the dependency works as well
because it implies MVEBU_MBUS. However, you can't use COMPILE_TEST
then because the driver itself needs the interfaces provided by MBUS.

It could be

	depends on ARCH_MVEBU || (MVEBU_MBUS && COMPILE_TEST)

to describe the dependency most accurately.

> > You probably need something like
> > 
> >       depends on MVEBU_MBUS=y || (MVEBU_MBUS=m && USB_XHCI=m)
> 
> MVEBU_MBUS is a bool, so there is no way is can be =m.

Yes, that helps.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 06/20] usb: host: xhci-plat: Add support for the Armada 38x

[Thomas Petazzoni]

Dear Arnd Bergmann,

On Tue, 06 May 2014 14:21:55 +0200, Arnd Bergmann wrote:

> > That's not what we do for any of the other drivers that use the
> > MVEBU_MBUS functions.
> 
> Fair enough. I guess using ARCH_MVEBU as the dependency works as well
> because it implies MVEBU_MBUS. However, you can't use COMPILE_TEST
> then because the driver itself needs the interfaces provided by MBUS.
> 
> It could be
> 
> 	depends on ARCH_MVEBU || (MVEBU_MBUS && COMPILE_TEST)
> 
> to describe the dependency most accurately.

Right, that would work indeed, but is in fact not necessary, at least
for this driver. The only mbus function used by this driver is
mv_mbus_dram_info(), and <linux/mbus.h> provides an empty stub for this
function (returning NULL) when MVEBU_MBUS is disabled. So from a
compile time point of view, there is no problem with compiling the
xhci-plat driver with MVEBU_MBUS disabled, so in fact:

	depends on ARCH_MVEBU || COMPILE_TEST

will work just fine.

The only case where this doesn't work is for drivers that use the other
mbus functions to create/remove windows, because no stubs are provided
for these ones. However, as things are today, the only driver in this
situation is the pci-mvebu driver, and its dependency is:

	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_KIRKWOOD

For this one, we could indeed add || (MVEBU_MBUS && COMPILE_TEST)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH v3 06/20] usb: host: xhci-plat: Add support for the Armada 38x

[Felipe Balbi]

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

Hi,

On Tue, May 06, 2014 at 02:14:01AM +0200, Gregory CLEMENT wrote:
> For the Armada 38x SoCs which come with an xhci controller, specific
> initialization must be done during probe related to the MBus windows
> configuration. This patch adds the support of this quirk.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>  drivers/usb/host/Kconfig      |  7 +++++
>  drivers/usb/host/Makefile     |  1 +
>  drivers/usb/host/xhci-mvebu.c | 71 +++++++++++++++++++++++++++++++++++++++++++
>  drivers/usb/host/xhci-mvebu.h | 21 +++++++++++++
>  drivers/usb/host/xhci-plat.c  |  6 ++++
>  5 files changed, 106 insertions(+)
>  create mode 100644 drivers/usb/host/xhci-mvebu.c
>  create mode 100644 drivers/usb/host/xhci-mvebu.h
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 3d9e54062d62..e70943fac4a1 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -29,6 +29,13 @@ if USB_XHCI_HCD
>  config USB_XHCI_PLATFORM
>  	tristate
>  
> +config USB_XHCI_MVEBU
> +	tristate "xHCI support for Marvell Armada 38x"
> +	select USB_XHCI_PLATFORM
> +	---help---
> +	  Say 'Y' to enable the support for the xHCI host controller
> +	  found in Marvell Armada 38x ARM SOCs.
> +
>  endif # USB_XHCI_HCD
>  
>  config USB_EHCI_HCD
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 7530468c9a4f..7a8db7f7dc01 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -19,6 +19,7 @@ xhci-hcd-$(CONFIG_PCI)	+= xhci-pci.o
>  
>  ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
>  	xhci-hcd-y		+= xhci-plat.o
> +	xhci-hcd-$(CONFIG_USB_XHCI_MVEBU)	+= xhci-mvebu.o

hmm, this has the potential of resulting in:

	xhci-hcd-m += xhci-mvebu.o

I guess it's best to turn this into:

ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
	xhci-hcd-y += xhci-mvebu.o
endif

no ? Other than this comment:

Acked-by: Felipe Balbi <balbi@ti.com>

-- 
balbi

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

Re: [PATCH v3 06/20] usb: host: xhci-plat: Add support for the Armada 38x

[Thomas Petazzoni]

Dear Felipe Balbi,

On Tue, 6 May 2014 10:39:53 -0500, Felipe Balbi wrote:

> >  config USB_EHCI_HCD
> > diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> > index 7530468c9a4f..7a8db7f7dc01 100644
> > --- a/drivers/usb/host/Makefile
> > +++ b/drivers/usb/host/Makefile
> > @@ -19,6 +19,7 @@ xhci-hcd-$(CONFIG_PCI)	+= xhci-pci.o
> >  
> >  ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
> >  	xhci-hcd-y		+= xhci-plat.o
> > +	xhci-hcd-$(CONFIG_USB_XHCI_MVEBU)	+= xhci-mvebu.o
> 
> hmm, this has the potential of resulting in:
> 
> 	xhci-hcd-m += xhci-mvebu.o
> 
> I guess it's best to turn this into:
> 
> ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
> 	xhci-hcd-y += xhci-mvebu.o
> endif

I guess you meant:

ifneq ($(CONFIG_USB_XHCI_MVEBU), )
	xhci-hcd-y += xhci-mvebu.o
endif

Right?

If so, then what about instead making CONFIG_USB_XHCI_MVEBU a bool
instead of a tristate? It's more an option for the xhci-platform
driver than an additional separate module, IMO. What do you think?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH v3 06/20] usb: host: xhci-plat: Add support for the Armada 38x

[Felipe Balbi]

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

On Wed, May 07, 2014 at 12:23:26PM +0200, Thomas Petazzoni wrote:
> Dear Felipe Balbi,
> 
> On Tue, 6 May 2014 10:39:53 -0500, Felipe Balbi wrote:
> 
> > >  config USB_EHCI_HCD
> > > diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> > > index 7530468c9a4f..7a8db7f7dc01 100644
> > > --- a/drivers/usb/host/Makefile
> > > +++ b/drivers/usb/host/Makefile
> > > @@ -19,6 +19,7 @@ xhci-hcd-$(CONFIG_PCI)	+= xhci-pci.o
> > >  
> > >  ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
> > >  	xhci-hcd-y		+= xhci-plat.o
> > > +	xhci-hcd-$(CONFIG_USB_XHCI_MVEBU)	+= xhci-mvebu.o
> > 
> > hmm, this has the potential of resulting in:
> > 
> > 	xhci-hcd-m += xhci-mvebu.o
> > 
> > I guess it's best to turn this into:
> > 
> > ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
> > 	xhci-hcd-y += xhci-mvebu.o
> > endif
> 
> I guess you meant:
> 
> ifneq ($(CONFIG_USB_XHCI_MVEBU), )
> 	xhci-hcd-y += xhci-mvebu.o
> endif
> 
> Right?

correct :-)

> If so, then what about instead making CONFIG_USB_XHCI_MVEBU a bool
> instead of a tristate? It's more an option for the xhci-platform
> driver than an additional separate module, IMO. What do you think?

fine by me too. It simply adds a quirk callback to xhci-plat.

-- 
balbi

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

Re: [PATCH v3 06/20] usb: host: xhci-plat: Add support for the Armada 38x

[Thomas Petazzoni]

Dear Felipe Balbi,

On Wed, 7 May 2014 10:10:08 -0500, Felipe Balbi wrote:

> > ifneq ($(CONFIG_USB_XHCI_MVEBU), )
> > 	xhci-hcd-y += xhci-mvebu.o
> > endif
> > 
> > Right?
> 
> correct :-)
> 
> > If so, then what about instead making CONFIG_USB_XHCI_MVEBU a bool
> > instead of a tristate? It's more an option for the xhci-platform
> > driver than an additional separate module, IMO. What do you think?
> 
> fine by me too. It simply adds a quirk callback to xhci-plat.

In the end, I settled on keeping the tristate, and used your
suggestion. Because since xhci-plat itself is a blind option, and
xhci-mvebu selects it, if xhci-mvebu is a bool, there would no longer
be a way to have xhci-plat as a module. At least that's my
understanding of the kconfig stuff :)

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH v3 07/20] xhci-platform: Add a new controller using xhci: Armada 38x

[Gregory CLEMENT]

Extend the compatible string list with armada-380-xhci. It is used to
describe xhci controller which is in the Armada 38x SoCs.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 90f8f607d125..a0915941fc25 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -1,7 +1,8 @@
 USB xHCI controllers
 
 Required properties:
-  - compatible: should be "generic-xhci" (deprecated: "xhci-platform").
+  - compatible: should be one of "generic-xhci",
+    "marvell,armada-380-xhci" (deprecated: "xhci-platform").
   - reg: should contain address and length of the standard XHCI
     register set for the device.
   - interrupts: one XHCI interrupt should be described here.
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 09/20] ARM: mvebu: Add Device Tree description of the EHCI host on Armada 38x

[Gregory CLEMENT]

The Marvell Armada 38x SoCs contains one EHCI host. This commit adds
the Device Tree description of this interface at the SoC level, and
also enables the USB2 port on the Armada 385 DB platform.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 arch/arm/boot/dts/armada-385-db.dts | 4 ++++
 arch/arm/boot/dts/armada-38x.dtsi   | 8 ++++++++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/armada-385-db.dts b/arch/arm/boot/dts/armada-385-db.dts
index d5db1466da82..91e3e449067f 100644
--- a/arch/arm/boot/dts/armada-385-db.dts
+++ b/arch/arm/boot/dts/armada-385-db.dts
@@ -65,6 +65,10 @@
 				phy-mode = "rgmii-id";
 			};
 
+			usb@50000 {
+				status = "ok";
+			};
+
 			ethernet@70000 {
 				status = "okay";
 				phy = <&phy0>;
diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index 5913ce1cc601..11f1f9e28cbc 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -283,6 +283,14 @@
 				status = "disabled";
 			};
 
+			usb@50000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x58000 0x500>;
+				interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&gateclk 18>;
+				status = "disabled";
+			};
+
 			xor@60800 {
 				compatible = "marvell,orion-xor";
 				reg = <0x60800 0x100
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 10/20] ARM: mvebu: Add USB3 support for Armada 38x

[Gregory CLEMENT]

This patch add the selection of the config symbol to build the USB3
support for Armada 38x.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 arch/arm/mach-mvebu/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 3f73eecbcfb0..7960f218702b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -54,6 +54,7 @@ config MACH_ARMADA_38X
 	select CPU_V7
 	select MACH_MVEBU_V7
 	select PINCTRL_ARMADA_38X
+	select USB_ARCH_HAS_XHCI
 	help
 	  Say 'Y' here if you want your kernel to support boards based
 	  on the Marvell Armada 380/385 SoC with device tree.
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 11/20] ARM: configs: Add usb_xhci_mvebu to mvebu_v7_defconfig

[Gregory CLEMENT]

The Marvell Armada 38x platform needs the xhci_mvebu driver enabled
for the xHCI USB hosts, so this commit enables the corresponding
Kconfig option in mvebu_v7_defconfig.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index a34713d8db9f..e8811066b8e4 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -78,6 +78,7 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_ROOT_HUB_TT=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_MVEBU=y
 CONFIG_MMC=y
 CONFIG_MMC_MVSDIO=y
 CONFIG_NEW_LEDS=y
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 12/20] ARM: configs: Add usb_xhci_mvebu to multi_v7_defconfig

[Gregory CLEMENT]

The Marvell Armada 38x platform needs the xhci_mvebu driver enabled
for the xHCI USB hosts, so this commit enables the corresponding
Kconfig option in multi_v7_defconfig.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index d4e8a47a2f7c..820cc35d40cf 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -254,6 +254,7 @@ CONFIG_SND_SOC_TEGRA_ALC5632=y
 CONFIG_SND_SOC_TEGRA_MAX98090=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_MVEBU=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_TEGRA=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 12/20] ARM: configs: Add usb_xhci_mvebu to multi_v7_defconfig

[Jason Cooper]

If you need to do another respin of this series, please add Olof, Arnd
and Kevin (and arm@kernel.org) to the To:.  Otherwise, I'll take care of
it.

thx,

Jason.

On Tue, May 06, 2014 at 02:14:07AM +0200, Gregory CLEMENT wrote:
> The Marvell Armada 38x platform needs the xhci_mvebu driver enabled
> for the xHCI USB hosts, so this commit enables the corresponding
> Kconfig option in multi_v7_defconfig.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>  arch/arm/configs/multi_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index d4e8a47a2f7c..820cc35d40cf 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -254,6 +254,7 @@ CONFIG_SND_SOC_TEGRA_ALC5632=y
>  CONFIG_SND_SOC_TEGRA_MAX98090=y
>  CONFIG_USB=y
>  CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_MVEBU=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_EHCI_TEGRA=y
>  CONFIG_USB_EHCI_HCD_PLATFORM=y
> -- 
> 1.8.1.2
> 

[PATCH v3 14/20] xhci-platform: Add a new controller using xHCI: Armada 375

[Gregory CLEMENT]

Extend the compatible string list with armada-375-xhci. It is used to
describe xHCI controller which is in the Armada 375 SoC.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index a0915941fc25..5eafa9a4e136 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -2,7 +2,8 @@ USB xHCI controllers
 
 Required properties:
   - compatible: should be one of "generic-xhci",
-    "marvell,armada-380-xhci" (deprecated: "xhci-platform").
+    "marvell,armada-375-xhci", "marvell,armada-380-xhci" (deprecated:
+    "xhci-platform").
   - reg: should contain address and length of the standard XHCI
     register set for the device.
   - interrupts: one XHCI interrupt should be described here.
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 15/20] ARM: mvebu: Add Device Tree description of USB cluster controller on Armada 375

[Gregory CLEMENT]

On Armada 375, the USB cluster allows to control the cluster composed
of the USB2 and USB3 host controllers.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 arch/arm/boot/dts/armada-375.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 3877693fb2d8..6724c10a8862 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -320,6 +320,12 @@
 				clocks = <&coreclk 0>;
 			};
 
+			usbcluster: usb-cluster@18400 {
+				compatible = "marvell,armada-375-usb-cluster";
+				reg = <0x18400 0x4>;
+				#phy-cells = <1>;
+			};
+
 			xor@60800 {
 				compatible = "marvell,orion-xor";
 				reg = <0x60800 0x100
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 16/20] dt: binding: Armada 375 USB cluster

[Gregory CLEMENT]

Armada 375 comes with an USB2 host and device controller and an USB3
controller. The USB cluster control register allows to manage common
features of both USB controllers.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 .../bindings/phy/armada-375-usb-phy-cluster.txt       | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/armada-375-usb-phy-cluster.txt

diff --git a/Documentation/devicetree/bindings/phy/armada-375-usb-phy-cluster.txt b/Documentation/devicetree/bindings/phy/armada-375-usb-phy-cluster.txt
new file mode 100644
index 000000000000..258407c5ab90
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/armada-375-usb-phy-cluster.txt
@@ -0,0 +1,19 @@
+Armada 375 USB cluster
+----------------------
+
+Armada 375 comes with an USB2 host and device controller and an USB3
+controller. The USB cluster control register allows to manage common
+features of both USB controllers.
+
+Required properties:
+
+- compatible: "marvell,armada-375-usb-cluster"
+- reg: Should contain usb cluster register location and length.
+- #phy-cells : from the generic phy bindings, must be 1
+
+Example:
+	usbcluster: usb-cluster@18400 {
+		compatible = "marvell,armada-375-usb-cluster";
+		reg = <0x18400 0x4>;
+		#phy-cells = <1>
+	};
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 17/20] phy: Add support for USB cluster on the Armada 375 SoC

[Gregory CLEMENT]

The Armada 375 SoC comes with an USB2 host and device controller and
an USB3 controller. The USB cluster control register allows to manage
common features of both USB controllers. It uses the generic PHY
framework

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 drivers/phy/Kconfig              |   5 ++
 drivers/phy/Makefile             |   1 +
 drivers/phy/phy-armada375-usb2.c | 154 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 160 insertions(+)
 create mode 100644 drivers/phy/phy-armada375-usb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f17b9b4..cdf3e2c24e3a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,6 +15,11 @@ config GENERIC_PHY
 	  phy users can obtain reference to the PHY. All the users of this
 	  framework should select this config.
 
+config ARMADA375_USBCLUSTER_PHY
+	def_bool y
+	depends on OF
+	select GENERIC_PHY
+
 config PHY_EXYNOS_MIPI_VIDEO
 	tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
 	depends on HAS_IOMEM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78edc864..47d5a86807b6 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
+obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)	+= phy-armada375-usb2.o
 obj-$(CONFIG_BCM_KONA_USB2_PHY)		+= phy-bcm-kona-usb2.o
 obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)	+= phy-exynos-dp-video.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)	+= phy-exynos-mipi-video.o
diff --git a/drivers/phy/phy-armada375-usb2.c b/drivers/phy/phy-armada375-usb2.c
new file mode 100644
index 000000000000..8bbac45e72c8
--- /dev/null
+++ b/drivers/phy/phy-armada375-usb2.c
@@ -0,0 +1,154 @@
+/*
+ * USB cluster support for Armada 375 platform.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2 or later. This program is licensed "as is"
+ * without any warranty of any kind, whether express or implied.
+ *
+ * Armada 375 comes with an USB2 host and device controller and an
+ * USB3 controller. The USB cluster control register allows to manage
+ * common features of both USB controller.
+ */
+
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define USB2_PHY_CONFIG_ENABLE BIT(0) /* active low */
+
+/* the USB cluster allow to choose between two PHYs*/
+#define NB_PHY 2
+
+enum {
+	PHY_USB2 = 0,
+	PHY_USB3 = 1,
+};
+
+struct armada375_cluster_phy {
+	struct phy *phy;
+	void __iomem *reg;
+	bool enable;
+	bool use_usb3;
+};
+
+struct armada375_cluster_phy usb_cluster_phy[NB_PHY];
+
+static int armada375_usb_phy_init(struct phy *phy)
+{
+	struct armada375_cluster_phy *cluster_phy = phy_get_drvdata(phy);
+	u32 reg;
+
+	if (cluster_phy->enable) {
+		reg = readl(cluster_phy->reg);
+		if (cluster_phy->use_usb3)
+			reg |= USB2_PHY_CONFIG_ENABLE;
+		else
+			reg &= ~USB2_PHY_CONFIG_ENABLE;
+		writel(reg, cluster_phy->reg);
+
+		return 0;
+	} else {
+		return -ENODEV;
+	}
+}
+
+static struct phy_ops armada375_usb_phy_ops = {
+	.init = armada375_usb_phy_init,
+	.owner		= THIS_MODULE,
+};
+
+static struct phy *armada375_usb_phy_xlate(struct device *dev,
+					struct of_phandle_args *args)
+{
+	if (WARN_ON(args->args[0] >= NB_PHY))
+		return ERR_PTR(-ENODEV);
+
+	return usb_cluster_phy[args->args[0]].phy;
+}
+
+static int armada375_usb_phy_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct phy *phy;
+	struct device_node *np = dev->of_node;
+	struct phy_provider *phy_provider;
+	void __iomem *usb_cluster_base;
+	struct device_node *xhci_node;
+	int i;
+
+	usb_cluster_base = of_iomap(np, 0);
+	BUG_ON(!usb_cluster_base);
+
+	for (i = 0; i < NB_PHY; i++) {
+		phy = devm_phy_create(dev, &armada375_usb_phy_ops, NULL);
+		if (IS_ERR(phy))
+			dev_err(dev, "failed to create PHY n%d\n", i);
+
+		usb_cluster_phy[i].phy = phy;
+		usb_cluster_phy[i].reg = usb_cluster_base;
+		usb_cluster_phy[i].enable = false;
+		phy_set_drvdata(phy, &usb_cluster_phy[i]);
+	}
+
+	usb_cluster_phy[PHY_USB2].use_usb3 = false;
+	usb_cluster_phy[PHY_USB3].use_usb3 = true;
+
+	/*
+	 * We can't use the first usb2 unit and usb3 at the same time
+	 * to manage a USB2 device, so let's disable usb2 if usb3 is
+	 * slelected. In this case USB2 device will be managed by the
+	 * xhci controller.
+	 */
+
+	xhci_node = of_find_compatible_node(NULL, NULL,
+					"marvell,armada-375-xhci");
+
+	if (xhci_node && of_device_is_available(xhci_node)) {
+		usb_cluster_phy[PHY_USB3].enable = true;
+	} else {
+		struct device_node *ehci_node;
+		ehci_node = of_find_compatible_node(NULL, NULL,
+					"marvell,orion-ehci");
+		if (ehci_node && of_device_is_available(ehci_node))
+			usb_cluster_phy[PHY_USB2].enable = true;
+		of_node_put(ehci_node);
+	}
+
+	of_node_put(xhci_node);
+
+	phy_provider = devm_of_phy_provider_register(&pdev->dev,
+						     armada375_usb_phy_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	return 0;
+}
+
+static const struct of_device_id of_usb_cluster_table[] = {
+	{ .compatible = "marvell,armada-375-usb-cluster", },
+	{ /* end of list */ },
+};
+MODULE_DEVICE_TABLE(of, of_usb_cluster_table);
+
+static struct platform_driver armada375_usb_phy_driver = {
+	.probe	= armada375_usb_phy_probe,
+	.driver = {
+		.of_match_table	= of_usb_cluster_table,
+		.name  = "armada-375-usb-cluster",
+		.owner = THIS_MODULE,
+	}
+};
+module_platform_driver(armada375_usb_phy_driver);
+
+MODULE_DESCRIPTION("Armada 375 USB cluster driver");
+MODULE_AUTHOR("Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>");
+MODULE_LICENSE("GPL");
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 17/20] phy: Add support for USB cluster on the Armada 375 SoC

[Bartlomiej Zolnierkiewicz]

Hi,

On Tuesday, May 06, 2014 02:14:12 AM Gregory CLEMENT wrote:
> The Armada 375 SoC comes with an USB2 host and device controller and
> an USB3 controller. The USB cluster control register allows to manage
> common features of both USB controllers. It uses the generic PHY
> framework
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>  drivers/phy/Kconfig              |   5 ++
>  drivers/phy/Makefile             |   1 +
>  drivers/phy/phy-armada375-usb2.c | 154 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 160 insertions(+)
>  create mode 100644 drivers/phy/phy-armada375-usb2.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 3bb05f17b9b4..cdf3e2c24e3a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -15,6 +15,11 @@ config GENERIC_PHY
>  	  phy users can obtain reference to the PHY. All the users of this
>  	  framework should select this config.
>  
> +config ARMADA375_USBCLUSTER_PHY
> +	def_bool y
> +	depends on OF

Please limit this driver to Armada 375 or compile testing, i.e. add additional

	depends on (ARCH_MVEBU && MACH_ARMADA_375) || COMPILE_TEST

> +	select GENERIC_PHY
> +
>  config PHY_EXYNOS_MIPI_VIDEO
>  	tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
>  	depends on HAS_IOMEM

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH v3 17/20] phy: Add support for USB cluster on the Armada 375 SoC

[Thomas Petazzoni]

Dear Bartlomiej Zolnierkiewicz,

On Tue, 06 May 2014 13:37:04 +0200, Bartlomiej Zolnierkiewicz wrote:

> > +config ARMADA375_USBCLUSTER_PHY
> > +	def_bool y
> > +	depends on OF
> 
> Please limit this driver to Armada 375 or compile testing, i.e. add additional
> 
> 	depends on (ARCH_MVEBU && MACH_ARMADA_375) || COMPILE_TEST

Right, will do.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 17/20] phy: Add support for USB cluster on the Armada 375 SoC

[Andrew Lunn]

On Tue, May 06, 2014 at 02:14:12AM +0200, Gregory CLEMENT wrote:
> The Armada 375 SoC comes with an USB2 host and device controller and
> an USB3 controller. The USB cluster control register allows to manage
> common features of both USB controllers. It uses the generic PHY
> framework
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>  drivers/phy/Kconfig              |   5 ++
>  drivers/phy/Makefile             |   1 +
>  drivers/phy/phy-armada375-usb2.c | 154 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 160 insertions(+)
>  create mode 100644 drivers/phy/phy-armada375-usb2.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 3bb05f17b9b4..cdf3e2c24e3a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -15,6 +15,11 @@ config GENERIC_PHY
>  	  phy users can obtain reference to the PHY. All the users of this
>  	  framework should select this config.
>  
> +config ARMADA375_USBCLUSTER_PHY
> +	def_bool y
> +	depends on OF
> +	select GENERIC_PHY
> +
>  config PHY_EXYNOS_MIPI_VIDEO
>  	tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
>  	depends on HAS_IOMEM
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 2faf78edc864..47d5a86807b6 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -3,6 +3,7 @@
>  #
>  
>  obj-$(CONFIG_GENERIC_PHY)		+= phy-core.o
> +obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)	+= phy-armada375-usb2.o
>  obj-$(CONFIG_BCM_KONA_USB2_PHY)		+= phy-bcm-kona-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)	+= phy-exynos-dp-video.o
>  obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)	+= phy-exynos-mipi-video.o
> diff --git a/drivers/phy/phy-armada375-usb2.c b/drivers/phy/phy-armada375-usb2.c
> new file mode 100644
> index 000000000000..8bbac45e72c8
> --- /dev/null
> +++ b/drivers/phy/phy-armada375-usb2.c
> @@ -0,0 +1,154 @@
> +/*
> + * USB cluster support for Armada 375 platform.
> + *
> + * Copyright (C) 2014 Marvell
> + *
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2 or later. This program is licensed "as is"
> + * without any warranty of any kind, whether express or implied.
> + *
> + * Armada 375 comes with an USB2 host and device controller and an
> + * USB3 controller. The USB cluster control register allows to manage
> + * common features of both USB controller.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +#define USB2_PHY_CONFIG_ENABLE BIT(0) /* active low */
> +
> +/* the USB cluster allow to choose between two PHYs*/
> +#define NB_PHY 2
> +
> +enum {
> +	PHY_USB2 = 0,
> +	PHY_USB3 = 1,
> +};
> +
> +struct armada375_cluster_phy {
> +	struct phy *phy;
> +	void __iomem *reg;
> +	bool enable;
> +	bool use_usb3;

Hi Gregory

nit: How about using the enum you just defined?

> +};
> +
> +struct armada375_cluster_phy usb_cluster_phy[NB_PHY];
> +
> +static int armada375_usb_phy_init(struct phy *phy)
> +{
> +	struct armada375_cluster_phy *cluster_phy = phy_get_drvdata(phy);
> +	u32 reg;
> +
> +	if (cluster_phy->enable) {
> +		reg = readl(cluster_phy->reg);
> +		if (cluster_phy->use_usb3)
> +			reg |= USB2_PHY_CONFIG_ENABLE;
> +		else
> +			reg &= ~USB2_PHY_CONFIG_ENABLE;
> +		writel(reg, cluster_phy->reg);
> +
> +		return 0;
> +	} else {
> +		return -ENODEV;
> +	}
> +}
> +
> +static struct phy_ops armada375_usb_phy_ops = {
> +	.init = armada375_usb_phy_init,
> +	.owner		= THIS_MODULE,
> +};
> +
> +static struct phy *armada375_usb_phy_xlate(struct device *dev,
> +					struct of_phandle_args *args)
> +{
> +	if (WARN_ON(args->args[0] >= NB_PHY))
> +		return ERR_PTR(-ENODEV);
> +
> +	return usb_cluster_phy[args->args[0]].phy;
> +}
> +
> +static int armada375_usb_phy_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct phy *phy;
> +	struct device_node *np = dev->of_node;
> +	struct phy_provider *phy_provider;
> +	void __iomem *usb_cluster_base;
> +	struct device_node *xhci_node;
> +	int i;
> +
> +	usb_cluster_base = of_iomap(np, 0);

devm_ API?

Check the return value for an error?

> +	BUG_ON(!usb_cluster_base);
> +
> +	for (i = 0; i < NB_PHY; i++) {
> +		phy = devm_phy_create(dev, &armada375_usb_phy_ops, NULL);
> +		if (IS_ERR(phy))
> +			dev_err(dev, "failed to create PHY n%d\n", i);
> +
> +		usb_cluster_phy[i].phy = phy;
> +		usb_cluster_phy[i].reg = usb_cluster_base;
> +		usb_cluster_phy[i].enable = false;
> +		phy_set_drvdata(phy, &usb_cluster_phy[i]);
> +	}
> +
> +	usb_cluster_phy[PHY_USB2].use_usb3 = false;
> +	usb_cluster_phy[PHY_USB3].use_usb3 = true;
> +
> +	/*
> +	 * We can't use the first usb2 unit and usb3 at the same time
> +	 * to manage a USB2 device, so let's disable usb2 if usb3 is
> +	 * slelected. In this case USB2 device will be managed by the

selected


> +	 * xhci controller.
> +	 */
> +
> +	xhci_node = of_find_compatible_node(NULL, NULL,
> +					"marvell,armada-375-xhci");
> +
> +	if (xhci_node && of_device_is_available(xhci_node)) {
> +		usb_cluster_phy[PHY_USB3].enable = true;
> +	} else {
> +		struct device_node *ehci_node;
> +		ehci_node = of_find_compatible_node(NULL, NULL,
> +					"marvell,orion-ehci");
> +		if (ehci_node && of_device_is_available(ehci_node))
> +			usb_cluster_phy[PHY_USB2].enable = true;
> +		of_node_put(ehci_node);
> +	}
> +
> +	of_node_put(xhci_node);
> +
> +	phy_provider = devm_of_phy_provider_register(&pdev->dev,
> +						     armada375_usb_phy_xlate);
> +	if (IS_ERR(phy_provider))
> +		return PTR_ERR(phy_provider);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id of_usb_cluster_table[] = {
> +	{ .compatible = "marvell,armada-375-usb-cluster", },
> +	{ /* end of list */ },
> +};
> +MODULE_DEVICE_TABLE(of, of_usb_cluster_table);
> +
> +static struct platform_driver armada375_usb_phy_driver = {
> +	.probe	= armada375_usb_phy_probe,
> +	.driver = {
> +		.of_match_table	= of_usb_cluster_table,
> +		.name  = "armada-375-usb-cluster",
> +		.owner = THIS_MODULE,
> +	}
> +};
> +module_platform_driver(armada375_usb_phy_driver);
> +
> +MODULE_DESCRIPTION("Armada 375 USB cluster driver");
> +MODULE_AUTHOR("Gregory CLEMENT <gregory.clement@free-electrons.com>");
> +MODULE_LICENSE("GPL");
> -- 
> 1.8.1.2
> 

Re: [PATCH v3 17/20] phy: Add support for USB cluster on the Armada 375 SoC

[Thomas Petazzoni]

Dear Andrew Lunn,

On Tue, 6 May 2014 15:54:27 +0200, Andrew Lunn wrote:

> > +enum {
> > +	PHY_USB2 = 0,
> > +	PHY_USB3 = 1,
> > +};
> > +
> > +struct armada375_cluster_phy {
> > +	struct phy *phy;
> > +	void __iomem *reg;
> > +	bool enable;
> > +	bool use_usb3;
> 
> Hi Gregory
> 
> nit: How about using the enum you just defined?

Nope, I don't think it's a good idea, because they mean different
things. The enum is used to index the arrays of two PHYs: PHY_USB2 is
the first one, PHY_USB3 is the second one.

On the other hand, the 'use_usb3' field indicates in which mode is a
particular PHY. So it could apply on either of the PHYs, and is
therefore not related to the index of the PHYs in the array.


> > +	usb_cluster_base = of_iomap(np, 0);
> 
> devm_ API?
> 
> Check the return value for an error?

Indeed, I'll use devm_ioremap_resource() here.

> > +	BUG_ON(!usb_cluster_base);
> > +
> > +	for (i = 0; i < NB_PHY; i++) {
> > +		phy = devm_phy_create(dev, &armada375_usb_phy_ops, NULL);
> > +		if (IS_ERR(phy))
> > +			dev_err(dev, "failed to create PHY n%d\n", i);
> > +
> > +		usb_cluster_phy[i].phy = phy;
> > +		usb_cluster_phy[i].reg = usb_cluster_base;
> > +		usb_cluster_phy[i].enable = false;
> > +		phy_set_drvdata(phy, &usb_cluster_phy[i]);
> > +	}
> > +
> > +	usb_cluster_phy[PHY_USB2].use_usb3 = false;
> > +	usb_cluster_phy[PHY_USB3].use_usb3 = true;
> > +
> > +	/*
> > +	 * We can't use the first usb2 unit and usb3 at the same time
> > +	 * to manage a USB2 device, so let's disable usb2 if usb3 is
> > +	 * slelected. In this case USB2 device will be managed by the
> 
> selected

Fixed.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 17/20] phy: Add support for USB cluster on the Armada 375 SoC

[Ezequiel Garcia]

Hi Greg,

On 06 May 02:14 AM, Gregory CLEMENT wrote:
> +
> +#define USB2_PHY_CONFIG_ENABLE BIT(0) /* active low */
> +

I still think it's more readable to use USB2_PHY_CONFIG_DISABLE.
It's just a nitpick, though.

> +static int armada375_usb_phy_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct phy *phy;
> +	struct device_node *np = dev->of_node;
> +	struct phy_provider *phy_provider;
> +	void __iomem *usb_cluster_base;
> +	struct device_node *xhci_node;
> +	int i;
> +
> +	usb_cluster_base = of_iomap(np, 0);
> +	BUG_ON(!usb_cluster_base);
> +

Isn't a bit extreme to call BUG_ON (and thus bring down the whole system)
in a phy driver?

> +	for (i = 0; i < NB_PHY; i++) {
> +		phy = devm_phy_create(dev, &armada375_usb_phy_ops, NULL);
> +		if (IS_ERR(phy))
> +			dev_err(dev, "failed to create PHY n%d\n", i);
> +

I think you're missing a continue/break here.

> +		usb_cluster_phy[i].phy = phy;
> +		usb_cluster_phy[i].reg = usb_cluster_base;
> +		usb_cluster_phy[i].enable = false;
> +		phy_set_drvdata(phy, &usb_cluster_phy[i]);
> +	}
> +
> +	usb_cluster_phy[PHY_USB2].use_usb3 = false;
> +	usb_cluster_phy[PHY_USB3].use_usb3 = true;
> +
[..]
> +
> +MODULE_DESCRIPTION("Armada 375 USB cluster driver");
> +MODULE_AUTHOR("Gregory CLEMENT <gregory.clement@free-electrons.com>");
> +MODULE_LICENSE("GPL");

GPL v2 ?

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH v3 17/20] phy: Add support for USB cluster on the Armada 375 SoC

[Thomas Petazzoni]

Dear Ezequiel Garcia,

On Tue, 6 May 2014 17:53:30 -0300, Ezequiel Garcia wrote:

> > +#define USB2_PHY_CONFIG_ENABLE BIT(0) /* active low */
> > +
> 
> I still think it's more readable to use USB2_PHY_CONFIG_DISABLE.
> It's just a nitpick, though.

Yes, fixed.

> > +static int armada375_usb_phy_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct phy *phy;
> > +	struct device_node *np = dev->of_node;
> > +	struct phy_provider *phy_provider;
> > +	void __iomem *usb_cluster_base;
> > +	struct device_node *xhci_node;
> > +	int i;
> > +
> > +	usb_cluster_base = of_iomap(np, 0);
> > +	BUG_ON(!usb_cluster_base);
> > +
> 
> Isn't a bit extreme to call BUG_ON (and thus bring down the whole system)
> in a phy driver?

Indeed, fixed by a more normal error return.

> > +	for (i = 0; i < NB_PHY; i++) {
> > +		phy = devm_phy_create(dev, &armada375_usb_phy_ops, NULL);
> > +		if (IS_ERR(phy))
> > +			dev_err(dev, "failed to create PHY n%d\n", i);
> > +
> 
> I think you're missing a continue/break here.

Indeed, fixed, I just do a return from the ->probe() function if
creating the PHY fails.

> > +MODULE_DESCRIPTION("Armada 375 USB cluster driver");
> > +MODULE_AUTHOR("Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>");
> > +MODULE_LICENSE("GPL");
> 
> GPL v2 ?

Well, using just "GPL" seems to be the more common usage through the
kernel:

linux/drivers $ git grep MODULE_LICENSE | grep "\"GPL\"" | wc -l
4276
linux/drivers $ git grep MODULE_LICENSE | grep "\"GPLv2\"" | wc -l
5
linux/drivers $ git grep MODULE_LICENSE | grep "\"GPL v2\"" | wc -l
841

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 18/20] ARM: mvebu: Add USB3 support for Armada 375

[Gregory CLEMENT]

This patch add the selection of the config symbol to build the USB3
support for Armada 375.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 arch/arm/mach-mvebu/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 7960f218702b..95afc7677ee1 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -41,6 +41,7 @@ config MACH_ARMADA_375
 	select CPU_V7
 	select MACH_MVEBU_V7
 	select PINCTRL_ARMADA_375
+	select USB_ARCH_HAS_XHCI
 	help
 	  Say 'Y' here if you want your kernel to support boards based
 	  on the Marvell Armada 375 SoC with device tree.
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 20/20] ARM: mvebu: Add Device Tree description of the EHCI host on Armada 375

[Gregory CLEMENT]

The Marvell Armada 375 SoCs contains one EHCI host. This commit adds
the Device Tree description of this interfaces at the SoC level, and
also enables the USB2 port on the Armada 375 DB platform.

Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
 arch/arm/boot/dts/armada-375-db.dts |  4 ++++
 arch/arm/boot/dts/armada-375.dtsi   | 18 ++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index 0453d69e6433..01bc5e87898b 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -102,6 +102,10 @@
 				};
 			};
 
+			usb@54000 {
+				status = "okay";
+			};
+
 			usb3@58000 {
 				status = "okay";
 			};
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 1b81d1e33510..d2b19bfe7496 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -320,6 +320,24 @@
 				clocks = <&coreclk 0>;
 			};
 
+			usb@50000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x50000 0x500>;
+				interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&gateclk 18>;
+				phys = <&usbcluster 0>;
+				phy-names="usb";
+				status = "disabled";
+			};
+
+			usb@54000 {
+				compatible = "marvell,orion-ehci";
+				reg = <0x54000 0x500>;
+				interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&gateclk 26>;
+				status = "disabled";
+			};
+
 			usb3@58000 {
 				compatible = "marvell,armada-375-xhci";
 				reg = <0x58000 0x20000>,<0x5b880 0x80>;
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 19/20] ARM: mvebu: Add Device Tree description of the xHCI host on Armada 375

[Gregory CLEMENT]

The Marvell Armada 375 SoCs contain a xHCI host. This commit adds the
Device Tree description of this interfaces at the SoC level, and also
enables the USB3 port on the Armada 375 DB platform.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm/boot/dts/armada-375-db.dts |  4 ++++
 arch/arm/boot/dts/armada-375.dtsi   | 10 ++++++++++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index 9378d3136b41..0453d69e6433 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -102,6 +102,10 @@
 				};
 			};
 
+			usb3@58000 {
+				status = "okay";
+			};
+
 			mvsdio@d4000 {
 				pinctrl-0 = <&sdio_pins &sdio_st_pins>;
 				pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 6724c10a8862..1b81d1e33510 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -320,6 +320,16 @@
 				clocks = <&coreclk 0>;
 			};
 
+			usb3@58000 {
+				compatible = "marvell,armada-375-xhci";
+				reg = <0x58000 0x20000>,<0x5b880 0x80>;
+				interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&gateclk 16>;
+				phys = <&usbcluster 1>;
+				phy-names="usb";
+				status = "disabled";
+			};
+
 			usbcluster: usb-cluster@18400 {
 				compatible = "marvell,armada-375-usb-cluster";
 				reg = <0x18400 0x4>;
-- 
1.8.1.2

Re: [PATCH v3 00/20] USB support for Armada 38x and Armada 375

[Sebastian Hesselbarth]

[Adding back the original Cc-List]

On 05/07/2014 10:33 AM, Hans de Goede wrote:
> Hi Gregory,
>
> Gregory CLEMENT <gregory.clement <at> free-electrons.com> writes:
>
>> This patch set adds the USB support for the Armada 38x Armada
>> 375. These SoCs use an xHCI but still need specific initialization,
>> mainly to setup the windows memory on the mbus. They also use the same
>> controller that the other mvebu SoC for EHCI.
>
> <snip>
>
>> Gregory CLEMENT (20):
>>    usb: ehci-orion: Fix clock reference leaking
>>    usb: ehci-orion: Add the optional PHY support
>
> If you're using a proper phy driver, do you really need a soc specific ehci
> driver? I've spend a lot of time during the last release cycle to make
> ehci-platform a lot more generic, including adding (optional) phy support to
> it. It would be great if the new Armada SoCs could use ehci-platform instead
> of extending ehci-orion to cover more models (ideally most ehci-foo drivers
> would go away completely). I've no idea how feasible it is to use
> ehci-platform in your case, but IMHO it should at least be considered.

Hans,

unfortunately we currently have no USB-PHY driver for the other mvebu
SoCs. I have started some code grabbing for barebox bootloader and plan
to add proper USB-PHYs for Linux later.

There is one thing very specific to mvebu SoCs, which is the mbus:
you need to setup upstream memory windows for the usb bus master.
 From my current understanding, that will require at least a minimal
stub to remain for ehci-orion.

I do think that most of the stuff in ehci-orion can (and should) be
replaced with ehci-platform then. So, we definitely consider reusing
the generic foo-platform drivers on all opportunities but IMHO we are
not yet ready for it.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/20] USB support for Armada 38x and Armada 375

[Hans de Goede]

Hi,

On 05/07/2014 11:21 AM, Sebastian Hesselbarth wrote:
> [Adding back the original Cc-List]
> 
> On 05/07/2014 10:33 AM, Hans de Goede wrote:
>> Hi Gregory,
>>
>> Gregory CLEMENT <gregory.clement <at> free-electrons.com> writes:
>>
>>> This patch set adds the USB support for the Armada 38x Armada
>>> 375. These SoCs use an xHCI but still need specific initialization,
>>> mainly to setup the windows memory on the mbus. They also use the same
>>> controller that the other mvebu SoC for EHCI.
>>
>> <snip>
>>
>>> Gregory CLEMENT (20):
>>>    usb: ehci-orion: Fix clock reference leaking
>>>    usb: ehci-orion: Add the optional PHY support
>>
>> If you're using a proper phy driver, do you really need a soc specific ehci
>> driver? I've spend a lot of time during the last release cycle to make
>> ehci-platform a lot more generic, including adding (optional) phy support to
>> it. It would be great if the new Armada SoCs could use ehci-platform instead
>> of extending ehci-orion to cover more models (ideally most ehci-foo drivers
>> would go away completely). I've no idea how feasible it is to use
>> ehci-platform in your case, but IMHO it should at least be considered.
> 
> Hans,
> 
> unfortunately we currently have no USB-PHY driver for the other mvebu
> SoCs. I have started some code grabbing for barebox bootloader and plan
> to add proper USB-PHYs for Linux later.
> 
> There is one thing very specific to mvebu SoCs, which is the mbus:
> you need to setup upstream memory windows for the usb bus master.
> From my current understanding, that will require at least a minimal
> stub to remain for ehci-orion.
> 
> I do think that most of the stuff in ehci-orion can (and should) be
> replaced with ehci-platform then. So, we definitely consider reusing
> the generic foo-platform drivers on all opportunities but IMHO we are
> not yet ready for it.

Ok, thanks for explaining.

Regards,

Hans