[PATCH 00/16] OMAP USB Host cleanup

[PATCH 00/16] OMAP USB Host cleanup

[Roger Quadros]

Hi,

This patchset addresses the following

- Avoid addressing clocks one by one by name and use a for loop + bunch
  of cleanups.
- Get number of channels/ports dynamically either from revision register
  or from platform data. Avoids getting clocks that are not present.
- Add OMAP5 and HSIC mode (Not tested)
- Save power on Panda when EHCI driver is not loaded.

cheers,
-roger

---
Andy Green (1):
  ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

Roger Quadros (15):
  mfd: omap-usb-tll: Avoid creating copy of platform data
  mfd: omap-usb-tll: Clean up clock handling
  mfd: omap-usb-tll: introduce and use mode_needs_tll()
  mfd: omap-usb-tll: Move port clock handling out of runtime ops
  mfd: omap-usb-tll: Add OMAP5 revision and HSIC support
  mfd: omap-usb-host: cleanup clock management code
  mfd: omap_usb_host: Avoid creating copy of platform_data
  mfd: omap-usb-host: know about number of ports from revision register
  mfd: omap-usb-host: override number of ports from platform data
  mfd: omap-usb-host: Intialize all available ports
  mfd: omap-usb-host: Manage HSIC clocks for HSIC mode
  ARM: OMAP2+: clock data: Merge utmi_px_gfclk into
    usb_host_hs_utmi_px_clk
  mfd: omap-usb-host: Get rid of unnecessary spinlock
  mfd: omap-usb-host: Support an auxiliary clock per port
  ARM: OMAP4: omap4panda: Don't enable USB PHY clock from board

 arch/arm/mach-omap2/board-omap4panda.c |   94 +++++---
 arch/arm/mach-omap2/clock3xxx_data.c   |    2 -
 arch/arm/mach-omap2/clock44xx_data.c   |   30 +--
 arch/arm/mach-omap2/usb-host.c         |    3 +
 arch/arm/plat-omap/include/plat/usb.h  |    8 +
 drivers/mfd/omap-usb-host.c            |  397 +++++++++++++++++++-------------
 drivers/mfd/omap-usb-tll.c             |  255 +++++++++++----------
 7 files changed, 454 insertions(+), 335 deletions(-)

-- 
1.7.4.1

[PATCH 01/16] mfd: omap-usb-tll: Avoid creating copy of platform data

[Roger Quadros]

Just a pointer to the platform data should suffice.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/mfd/omap-usb-tll.c |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 4b7757b..d1750a4 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -98,7 +98,7 @@
 struct usbtll_omap {
 	struct clk				*usbtll_p1_fck;
 	struct clk				*usbtll_p2_fck;
-	struct usbtll_omap_platform_data	platdata;
+	struct usbtll_omap_platform_data	*pdata;
 	/* secure the register updates */
 	spinlock_t				lock;
 };
@@ -223,8 +223,7 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 
 	spin_lock_init(&tll->lock);
 
-	for (i = 0; i < OMAP3_HS_USB_PORTS; i++)
-		tll->platdata.port_mode[i] = pdata->port_mode[i];
+	tll->pdata = pdata;
 
 	tll->usbtll_p1_fck = clk_get(dev, "usb_tll_hs_usb_ch0_clk");
 	if (IS_ERR(tll->usbtll_p1_fck)) {
@@ -362,7 +361,7 @@ static int __devexit usbtll_omap_remove(struct platform_device *pdev)
 static int usbtll_runtime_resume(struct device *dev)
 {
 	struct usbtll_omap			*tll = dev_get_drvdata(dev);
-	struct usbtll_omap_platform_data	*pdata = &tll->platdata;
+	struct usbtll_omap_platform_data	*pdata = tll->pdata;
 	unsigned long				flags;
 
 	dev_dbg(dev, "usbtll_runtime_resume\n");
@@ -388,7 +387,7 @@ static int usbtll_runtime_resume(struct device *dev)
 static int usbtll_runtime_suspend(struct device *dev)
 {
 	struct usbtll_omap			*tll = dev_get_drvdata(dev);
-	struct usbtll_omap_platform_data	*pdata = &tll->platdata;
+	struct usbtll_omap_platform_data	*pdata = tll->pdata;
 	unsigned long				flags;
 
 	dev_dbg(dev, "usbtll_runtime_suspend\n");
-- 
1.7.4.1

Re: [PATCH 01/16] mfd: omap-usb-tll: Avoid creating copy of platform data

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:33:59PM +0200, Roger Quadros wrote:
> Just a pointer to the platform data should suffice.
> 
> Signed-off-by: Roger Quadros <rogerq@ti.com>

this looks fine to me:

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

> ---
>  drivers/mfd/omap-usb-tll.c |    9 ++++-----
>  1 files changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> index 4b7757b..d1750a4 100644
> --- a/drivers/mfd/omap-usb-tll.c
> +++ b/drivers/mfd/omap-usb-tll.c
> @@ -98,7 +98,7 @@
>  struct usbtll_omap {
>  	struct clk				*usbtll_p1_fck;
>  	struct clk				*usbtll_p2_fck;
> -	struct usbtll_omap_platform_data	platdata;
> +	struct usbtll_omap_platform_data	*pdata;
>  	/* secure the register updates */
>  	spinlock_t				lock;
>  };
> @@ -223,8 +223,7 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  
>  	spin_lock_init(&tll->lock);
>  
> -	for (i = 0; i < OMAP3_HS_USB_PORTS; i++)
> -		tll->platdata.port_mode[i] = pdata->port_mode[i];
> +	tll->pdata = pdata;
>  
>  	tll->usbtll_p1_fck = clk_get(dev, "usb_tll_hs_usb_ch0_clk");
>  	if (IS_ERR(tll->usbtll_p1_fck)) {
> @@ -362,7 +361,7 @@ static int __devexit usbtll_omap_remove(struct platform_device *pdev)
>  static int usbtll_runtime_resume(struct device *dev)
>  {
>  	struct usbtll_omap			*tll = dev_get_drvdata(dev);
> -	struct usbtll_omap_platform_data	*pdata = &tll->platdata;
> +	struct usbtll_omap_platform_data	*pdata = tll->pdata;
>  	unsigned long				flags;
>  
>  	dev_dbg(dev, "usbtll_runtime_resume\n");
> @@ -388,7 +387,7 @@ static int usbtll_runtime_resume(struct device *dev)
>  static int usbtll_runtime_suspend(struct device *dev)
>  {
>  	struct usbtll_omap			*tll = dev_get_drvdata(dev);
> -	struct usbtll_omap_platform_data	*pdata = &tll->platdata;
> +	struct usbtll_omap_platform_data	*pdata = tll->pdata;
>  	unsigned long				flags;
>  
>  	dev_dbg(dev, "usbtll_runtime_suspend\n");
> -- 
> 1.7.4.1
> 

-- 
balbi

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

[PATCH 02/16] mfd: omap-usb-tll: Clean up clock handling

[Roger Quadros]

Every channel has a functional clock that is similarly named.
It makes sense to use a for loop to manage these clocks as OMAPs
can come with upto 3 channels.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/mfd/omap-usb-tll.c |  130 +++++++++++++++++++++++++-------------------
 1 files changed, 74 insertions(+), 56 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index d1750a4..943ac14 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -82,8 +82,12 @@
 #define	OMAP_TLL_ULPI_DEBUG(num)			(0x815 + 0x100 * num)
 #define	OMAP_TLL_ULPI_SCRATCH_REGISTER(num)		(0x816 + 0x100 * num)
 
-#define OMAP_REV2_TLL_CHANNEL_COUNT			2
-#define OMAP_TLL_CHANNEL_COUNT				3
+#define REV2_TLL_CHANNEL_COUNT				2
+#define DEFAULT_TLL_CHANNEL_COUNT			3
+
+/* Update if any chip has more */
+#define MAX_TLL_CHANNEL_COUNT				3
+
 #define OMAP_TLL_CHANNEL_1_EN_MASK			(1 << 0)
 #define OMAP_TLL_CHANNEL_2_EN_MASK			(1 << 1)
 #define OMAP_TLL_CHANNEL_3_EN_MASK			(1 << 2)
@@ -96,8 +100,9 @@
 #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
 
 struct usbtll_omap {
-	struct clk				*usbtll_p1_fck;
-	struct clk				*usbtll_p2_fck;
+	void __iomem				*base;
+	int					nch;	/* number of channels */
+	struct clk				*ch_clk[MAX_TLL_CHANNEL_COUNT];
 	struct usbtll_omap_platform_data	*pdata;
 	/* secure the register updates */
 	spinlock_t				lock;
@@ -210,49 +215,35 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 	unsigned				reg;
 	unsigned long				flags;
 	int					ret = 0;
-	int					i, ver, count;
+	int					i, ver;
 
 	dev_dbg(dev, "starting TI HSUSB TLL Controller\n");
 
 	tll = kzalloc(sizeof(struct usbtll_omap), GFP_KERNEL);
 	if (!tll) {
 		dev_err(dev, "Memory allocation failed\n");
-		ret = -ENOMEM;
-		goto end;
+		return -ENOMEM;
 	}
 
 	spin_lock_init(&tll->lock);
 
 	tll->pdata = pdata;
 
-	tll->usbtll_p1_fck = clk_get(dev, "usb_tll_hs_usb_ch0_clk");
-	if (IS_ERR(tll->usbtll_p1_fck)) {
-		ret = PTR_ERR(tll->usbtll_p1_fck);
-		dev_err(dev, "usbtll_p1_fck failed error:%d\n", ret);
-		goto err_tll;
-	}
-
-	tll->usbtll_p2_fck = clk_get(dev, "usb_tll_hs_usb_ch1_clk");
-	if (IS_ERR(tll->usbtll_p2_fck)) {
-		ret = PTR_ERR(tll->usbtll_p2_fck);
-		dev_err(dev, "usbtll_p2_fck failed error:%d\n", ret);
-		goto err_usbtll_p1_fck;
-	}
-
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!res) {
 		dev_err(dev, "usb tll get resource failed\n");
 		ret = -ENODEV;
-		goto err_usbtll_p2_fck;
+		goto err_mem;
 	}
 
 	base = ioremap(res->start, resource_size(res));
 	if (!base) {
 		dev_err(dev, "TLL ioremap failed\n");
 		ret = -ENOMEM;
-		goto err_usbtll_p2_fck;
+		goto err_mem;
 	}
 
+	tll->base = base;
 	platform_set_drvdata(pdev, tll);
 	pm_runtime_enable(dev);
 	pm_runtime_get_sync(dev);
@@ -262,16 +253,33 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 	ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
 	switch (ver) {
 	case OMAP_USBTLL_REV1:
-	case OMAP_USBTLL_REV2:
-		count = OMAP_TLL_CHANNEL_COUNT;
+		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
 		break;
+	case OMAP_USBTLL_REV2:
 	case OMAP_USBTLL_REV3:
-		count = OMAP_REV2_TLL_CHANNEL_COUNT;
+		tll->nch = REV2_TLL_CHANNEL_COUNT;
 		break;
 	default:
-		dev_err(dev, "TLL version failed\n");
-		ret = -ENODEV;
-		goto err_ioremap;
+		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
+		dev_info(dev,
+		 "USB TLL Rev : 0x%x not recognized, assuming %d channels\n",
+			ver, tll->nch);
+		break;
+	}
+
+	for (i = 0; i < tll->nch; i++) {
+		char clk_name[] = "usb_tll_hs_usb_chx_clk";
+		struct clk *fck;
+
+		sprintf(clk_name, "usb_tll_hs_usb_ch%d_clk", i);
+		fck = clk_get(dev, clk_name);
+
+		if (IS_ERR(fck)) {
+			dev_err(dev, "can't get clock : %s\n", clk_name);
+			ret = PTR_ERR(fck);
+			goto err_clk;
+		}
+		tll->ch_clk[i] = fck;
 	}
 
 	if (is_ehci_tll_mode(pdata->port_mode[0]) ||
@@ -291,7 +299,7 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 		usbtll_write(base, OMAP_TLL_SHARED_CONF, reg);
 
 		/* Enable channels now */
-		for (i = 0; i < count; i++) {
+		for (i = 0; i < tll->nch; i++) {
 			reg = usbtll_read(base,	OMAP_TLL_CHANNEL_CONF(i));
 
 			if (is_ohci_port(pdata->port_mode[i])) {
@@ -319,25 +327,25 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 		}
 	}
 
-err_ioremap:
-	spin_unlock_irqrestore(&tll->lock, flags);
-	iounmap(base);
-	pm_runtime_put_sync(dev);
 	tll_pdev = pdev;
-	if (!ret)
-		goto end;
-	pm_runtime_disable(dev);
 
-err_usbtll_p2_fck:
-	clk_put(tll->usbtll_p2_fck);
+err_clk:
+	for (--i; i >= 0 ; i--)
+		clk_put(tll->ch_clk[i]);
 
-err_usbtll_p1_fck:
-	clk_put(tll->usbtll_p1_fck);
+	spin_unlock_irqrestore(&tll->lock, flags);
+	pm_runtime_put_sync(dev);
+	if (ret == 0) {
+		pr_info("OMAP USB TLL : revision 0x%x, channels %d\n",
+				ver, tll->nch);
+		return 0;
+	}
 
-err_tll:
-	kfree(tll);
+	iounmap(base);
+	pm_runtime_disable(dev);
 
-end:
+err_mem:
+	kfree(tll);
 	return ret;
 }
 
@@ -350,9 +358,12 @@ end:
 static int __devexit usbtll_omap_remove(struct platform_device *pdev)
 {
 	struct usbtll_omap *tll = platform_get_drvdata(pdev);
+	int i;
+
+	iounmap(tll->base);
+	for (i = 0; i < tll->nch; i++)
+		clk_put(tll->ch_clk[i]);
 
-	clk_put(tll->usbtll_p2_fck);
-	clk_put(tll->usbtll_p1_fck);
 	pm_runtime_disable(&pdev->dev);
 	kfree(tll);
 	return 0;
@@ -363,6 +374,7 @@ static int usbtll_runtime_resume(struct device *dev)
 	struct usbtll_omap			*tll = dev_get_drvdata(dev);
 	struct usbtll_omap_platform_data	*pdata = tll->pdata;
 	unsigned long				flags;
+	int i;
 
 	dev_dbg(dev, "usbtll_runtime_resume\n");
 
@@ -373,11 +385,17 @@ static int usbtll_runtime_resume(struct device *dev)
 
 	spin_lock_irqsave(&tll->lock, flags);
 
-	if (is_ehci_tll_mode(pdata->port_mode[0]))
-		clk_enable(tll->usbtll_p1_fck);
-
-	if (is_ehci_tll_mode(pdata->port_mode[1]))
-		clk_enable(tll->usbtll_p2_fck);
+	for (i = 0; i < tll->nch; i++) {
+		if (is_ehci_tll_mode(pdata->port_mode[i])) {
+			int r;
+			r = clk_enable(tll->ch_clk[i]);
+			if (r) {
+				dev_err(dev,
+				 "%s : Error enabling ch %d clock: %d\n",
+				 __func__, i, r);
+			}
+		}
+	}
 
 	spin_unlock_irqrestore(&tll->lock, flags);
 
@@ -389,6 +407,7 @@ static int usbtll_runtime_suspend(struct device *dev)
 	struct usbtll_omap			*tll = dev_get_drvdata(dev);
 	struct usbtll_omap_platform_data	*pdata = tll->pdata;
 	unsigned long				flags;
+	int i;
 
 	dev_dbg(dev, "usbtll_runtime_suspend\n");
 
@@ -399,11 +418,10 @@ static int usbtll_runtime_suspend(struct device *dev)
 
 	spin_lock_irqsave(&tll->lock, flags);
 
-	if (is_ehci_tll_mode(pdata->port_mode[0]))
-		clk_disable(tll->usbtll_p1_fck);
-
-	if (is_ehci_tll_mode(pdata->port_mode[1]))
-		clk_disable(tll->usbtll_p2_fck);
+	for (i = 0; i < tll->nch; i++) {
+		if (is_ehci_tll_mode(pdata->port_mode[i]))
+			clk_disable(tll->ch_clk[i]);
+	}
 
 	spin_unlock_irqrestore(&tll->lock, flags);
 
-- 
1.7.4.1

Re: [PATCH 02/16] mfd: omap-usb-tll: Clean up clock handling

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:00PM +0200, Roger Quadros wrote:
> Every channel has a functional clock that is similarly named.
> It makes sense to use a for loop to manage these clocks as OMAPs
> can come with upto 3 channels.

s/upto/up to

BTW, this patch is doing a lot more than "cleaning up clock handling".
This needs to be split into smaller patches.

> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
>  drivers/mfd/omap-usb-tll.c |  130 +++++++++++++++++++++++++-------------------
>  1 files changed, 74 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> index d1750a4..943ac14 100644
> --- a/drivers/mfd/omap-usb-tll.c
> +++ b/drivers/mfd/omap-usb-tll.c
> @@ -82,8 +82,12 @@
>  #define	OMAP_TLL_ULPI_DEBUG(num)			(0x815 + 0x100 * num)
>  #define	OMAP_TLL_ULPI_SCRATCH_REGISTER(num)		(0x816 + 0x100 * num)
>  
> -#define OMAP_REV2_TLL_CHANNEL_COUNT			2
> -#define OMAP_TLL_CHANNEL_COUNT				3
> +#define REV2_TLL_CHANNEL_COUNT				2

why are you dropping the OMAP_ prefix ? You shouldn't do that.

> +#define DEFAULT_TLL_CHANNEL_COUNT			3

Add OMAP_ prefix here.

> +
> +/* Update if any chip has more */
> +#define MAX_TLL_CHANNEL_COUNT				3

can't you figure this one out in runtime ? If this isn't in any
registers (and looks like it's not), you can pass this information to
the driver via DT or just use driver_data field on struct
platform_driver.

>  #define OMAP_TLL_CHANNEL_1_EN_MASK			(1 << 0)
>  #define OMAP_TLL_CHANNEL_2_EN_MASK			(1 << 1)
>  #define OMAP_TLL_CHANNEL_3_EN_MASK			(1 << 2)
> @@ -96,8 +100,9 @@
>  #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
>  
>  struct usbtll_omap {
> -	struct clk				*usbtll_p1_fck;
> -	struct clk				*usbtll_p2_fck;
> +	void __iomem				*base;
> +	int					nch;	/* number of channels */
> +	struct clk				*ch_clk[MAX_TLL_CHANNEL_COUNT];

should be allocated dynamically.

>  	struct usbtll_omap_platform_data	*pdata;
>  	/* secure the register updates */
>  	spinlock_t				lock;
> @@ -210,49 +215,35 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  	unsigned				reg;
>  	unsigned long				flags;
>  	int					ret = 0;
> -	int					i, ver, count;
> +	int					i, ver;
>  
>  	dev_dbg(dev, "starting TI HSUSB TLL Controller\n");
>  
>  	tll = kzalloc(sizeof(struct usbtll_omap), GFP_KERNEL);
>  	if (!tll) {
>  		dev_err(dev, "Memory allocation failed\n");
> -		ret = -ENOMEM;
> -		goto end;
> +		return -ENOMEM;
>  	}
>  
>  	spin_lock_init(&tll->lock);
>  
>  	tll->pdata = pdata;
>  
> -	tll->usbtll_p1_fck = clk_get(dev, "usb_tll_hs_usb_ch0_clk");
> -	if (IS_ERR(tll->usbtll_p1_fck)) {
> -		ret = PTR_ERR(tll->usbtll_p1_fck);
> -		dev_err(dev, "usbtll_p1_fck failed error:%d\n", ret);
> -		goto err_tll;
> -	}
> -
> -	tll->usbtll_p2_fck = clk_get(dev, "usb_tll_hs_usb_ch1_clk");
> -	if (IS_ERR(tll->usbtll_p2_fck)) {
> -		ret = PTR_ERR(tll->usbtll_p2_fck);
> -		dev_err(dev, "usbtll_p2_fck failed error:%d\n", ret);
> -		goto err_usbtll_p1_fck;
> -	}
> -
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	if (!res) {
>  		dev_err(dev, "usb tll get resource failed\n");
>  		ret = -ENODEV;
> -		goto err_usbtll_p2_fck;
> +		goto err_mem;
>  	}
>  
>  	base = ioremap(res->start, resource_size(res));
>  	if (!base) {
>  		dev_err(dev, "TLL ioremap failed\n");
>  		ret = -ENOMEM;
> -		goto err_usbtll_p2_fck;
> +		goto err_mem;
>  	}
>  
> +	tll->base = base;
>  	platform_set_drvdata(pdev, tll);
>  	pm_runtime_enable(dev);
>  	pm_runtime_get_sync(dev);
> @@ -262,16 +253,33 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  	ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
>  	switch (ver) {
>  	case OMAP_USBTLL_REV1:
> -	case OMAP_USBTLL_REV2:
> -		count = OMAP_TLL_CHANNEL_COUNT;
> +		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
>  		break;
> +	case OMAP_USBTLL_REV2:
>  	case OMAP_USBTLL_REV3:
> -		count = OMAP_REV2_TLL_CHANNEL_COUNT;
> +		tll->nch = REV2_TLL_CHANNEL_COUNT;

nice, you *can* figure that out based on the revision... In that case,
you shouldn't even define MAX_TLL_CHANNEL_COUNT, just allocate the array
dynamically for the exact size you need.

>  		break;
>  	default:
> -		dev_err(dev, "TLL version failed\n");
> -		ret = -ENODEV;
> -		goto err_ioremap;
> +		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
> +		dev_info(dev,
> +		 "USB TLL Rev : 0x%x not recognized, assuming %d channels\n",
> +			ver, tll->nch);

this hsould be dev_dbg().

> +		break;
> +	}
> +
> +	for (i = 0; i < tll->nch; i++) {
> +		char clk_name[] = "usb_tll_hs_usb_chx_clk";

just lazyness of counting the amount of letters ? :-p

> +		struct clk *fck;
> +
> +		sprintf(clk_name, "usb_tll_hs_usb_ch%d_clk", i);

this will overflow if 'i' (for whatever reason) goes over 9.

> +		fck = clk_get(dev, clk_name);

please use devm_clk_get().

> +		if (IS_ERR(fck)) {
> +			dev_err(dev, "can't get clock : %s\n", clk_name);
> +			ret = PTR_ERR(fck);
> +			goto err_clk;
> +		}
> +		tll->ch_clk[i] = fck;
>  	}
>  
>  	if (is_ehci_tll_mode(pdata->port_mode[0]) ||
> @@ -291,7 +299,7 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  		usbtll_write(base, OMAP_TLL_SHARED_CONF, reg);
>  
>  		/* Enable channels now */
> -		for (i = 0; i < count; i++) {
> +		for (i = 0; i < tll->nch; i++) {
>  			reg = usbtll_read(base,	OMAP_TLL_CHANNEL_CONF(i));
>  
>  			if (is_ohci_port(pdata->port_mode[i])) {
> @@ -319,25 +327,25 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> -err_ioremap:
> -	spin_unlock_irqrestore(&tll->lock, flags);
> -	iounmap(base);
> -	pm_runtime_put_sync(dev);
>  	tll_pdev = pdev;
> -	if (!ret)
> -		goto end;
> -	pm_runtime_disable(dev);
>  
> -err_usbtll_p2_fck:
> -	clk_put(tll->usbtll_p2_fck);
> +err_clk:
> +	for (--i; i >= 0 ; i--)
> +		clk_put(tll->ch_clk[i]);

is clk_put(NULL) safe ??

> -err_usbtll_p1_fck:
> -	clk_put(tll->usbtll_p1_fck);
> +	spin_unlock_irqrestore(&tll->lock, flags);
> +	pm_runtime_put_sync(dev);
> +	if (ret == 0) {
> +		pr_info("OMAP USB TLL : revision 0x%x, channels %d\n",
> +				ver, tll->nch);
> +		return 0;
> +	}

the whole thing is quite confusing. Please while cleaning up the driver,
also try to clean up the error path.

> -err_tll:
> -	kfree(tll);
> +	iounmap(base);

could be using devm_request_and_ioremap()

> +	pm_runtime_disable(dev);
>  
> -end:
> +err_mem:
> +	kfree(tll);

could be using devm_kzalloc()

>  	return ret;
>  }
>  
> @@ -350,9 +358,12 @@ end:
>  static int __devexit usbtll_omap_remove(struct platform_device *pdev)
>  {
>  	struct usbtll_omap *tll = platform_get_drvdata(pdev);
> +	int i;
> +
> +	iounmap(tll->base);
> +	for (i = 0; i < tll->nch; i++)
> +		clk_put(tll->ch_clk[i]);
>  
> -	clk_put(tll->usbtll_p2_fck);
> -	clk_put(tll->usbtll_p1_fck);
>  	pm_runtime_disable(&pdev->dev);
>  	kfree(tll);
>  	return 0;
> @@ -363,6 +374,7 @@ static int usbtll_runtime_resume(struct device *dev)
>  	struct usbtll_omap			*tll = dev_get_drvdata(dev);
>  	struct usbtll_omap_platform_data	*pdata = tll->pdata;
>  	unsigned long				flags;
> +	int i;
>  
>  	dev_dbg(dev, "usbtll_runtime_resume\n");
>  
> @@ -373,11 +385,17 @@ static int usbtll_runtime_resume(struct device *dev)
>  
>  	spin_lock_irqsave(&tll->lock, flags);
>  
> -	if (is_ehci_tll_mode(pdata->port_mode[0]))
> -		clk_enable(tll->usbtll_p1_fck);
> -
> -	if (is_ehci_tll_mode(pdata->port_mode[1]))
> -		clk_enable(tll->usbtll_p2_fck);
> +	for (i = 0; i < tll->nch; i++) {
> +		if (is_ehci_tll_mode(pdata->port_mode[i])) {
> +			int r;
> +			r = clk_enable(tll->ch_clk[i]);
> +			if (r) {
> +				dev_err(dev,
> +				 "%s : Error enabling ch %d clock: %d\n",
> +				 __func__, i, r);

you don't need __func__.


-- 
balbi

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

Re: [PATCH 02/16] mfd: omap-usb-tll: Clean up clock handling

[Roger Quadros]

Felipe,

Thanks for reviewing.

On 11/21/2012 01:55 PM, Felipe Balbi wrote:
> On Thu, Nov 15, 2012 at 04:34:00PM +0200, Roger Quadros wrote:
>> Every channel has a functional clock that is similarly named.
>> It makes sense to use a for loop to manage these clocks as OMAPs
>> can come with upto 3 channels.
> 
> s/upto/up to
> 
> BTW, this patch is doing a lot more than "cleaning up clock handling".
> This needs to be split into smaller patches.
> 
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>>  drivers/mfd/omap-usb-tll.c |  130 +++++++++++++++++++++++++-------------------
>>  1 files changed, 74 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
>> index d1750a4..943ac14 100644
>> --- a/drivers/mfd/omap-usb-tll.c
>> +++ b/drivers/mfd/omap-usb-tll.c
>> @@ -82,8 +82,12 @@
>>  #define	OMAP_TLL_ULPI_DEBUG(num)			(0x815 + 0x100 * num)
>>  #define	OMAP_TLL_ULPI_SCRATCH_REGISTER(num)		(0x816 + 0x100 * num)
>>  
>> -#define OMAP_REV2_TLL_CHANNEL_COUNT			2
>> -#define OMAP_TLL_CHANNEL_COUNT				3
>> +#define REV2_TLL_CHANNEL_COUNT				2
> 
> why are you dropping the OMAP_ prefix ? You shouldn't do that.
> 
>> +#define DEFAULT_TLL_CHANNEL_COUNT			3
> 
> Add OMAP_ prefix here.
> 
>> +
>> +/* Update if any chip has more */
>> +#define MAX_TLL_CHANNEL_COUNT				3
> 
> can't you figure this one out in runtime ? If this isn't in any
> registers (and looks like it's not), you can pass this information to
> the driver via DT or just use driver_data field on struct
> platform_driver.
> 
>>  #define OMAP_TLL_CHANNEL_1_EN_MASK			(1 << 0)
>>  #define OMAP_TLL_CHANNEL_2_EN_MASK			(1 << 1)
>>  #define OMAP_TLL_CHANNEL_3_EN_MASK			(1 << 2)
>> @@ -96,8 +100,9 @@
>>  #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
>>  
>>  struct usbtll_omap {
>> -	struct clk				*usbtll_p1_fck;
>> -	struct clk				*usbtll_p2_fck;
>> +	void __iomem				*base;
>> +	int					nch;	/* number of channels */
>> +	struct clk				*ch_clk[MAX_TLL_CHANNEL_COUNT];
> 
> should be allocated dynamically.
> 
>>  	struct usbtll_omap_platform_data	*pdata;
>>  	/* secure the register updates */
>>  	spinlock_t				lock;
>> @@ -210,49 +215,35 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>>  	unsigned				reg;
>>  	unsigned long				flags;
>>  	int					ret = 0;
>> -	int					i, ver, count;
>> +	int					i, ver;
>>  
>>  	dev_dbg(dev, "starting TI HSUSB TLL Controller\n");
>>  
>>  	tll = kzalloc(sizeof(struct usbtll_omap), GFP_KERNEL);
>>  	if (!tll) {
>>  		dev_err(dev, "Memory allocation failed\n");
>> -		ret = -ENOMEM;
>> -		goto end;
>> +		return -ENOMEM;
>>  	}
>>  
>>  	spin_lock_init(&tll->lock);
>>  
>>  	tll->pdata = pdata;
>>  
>> -	tll->usbtll_p1_fck = clk_get(dev, "usb_tll_hs_usb_ch0_clk");
>> -	if (IS_ERR(tll->usbtll_p1_fck)) {
>> -		ret = PTR_ERR(tll->usbtll_p1_fck);
>> -		dev_err(dev, "usbtll_p1_fck failed error:%d\n", ret);
>> -		goto err_tll;
>> -	}
>> -
>> -	tll->usbtll_p2_fck = clk_get(dev, "usb_tll_hs_usb_ch1_clk");
>> -	if (IS_ERR(tll->usbtll_p2_fck)) {
>> -		ret = PTR_ERR(tll->usbtll_p2_fck);
>> -		dev_err(dev, "usbtll_p2_fck failed error:%d\n", ret);
>> -		goto err_usbtll_p1_fck;
>> -	}
>> -
>>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>  	if (!res) {
>>  		dev_err(dev, "usb tll get resource failed\n");
>>  		ret = -ENODEV;
>> -		goto err_usbtll_p2_fck;
>> +		goto err_mem;
>>  	}
>>  
>>  	base = ioremap(res->start, resource_size(res));
>>  	if (!base) {
>>  		dev_err(dev, "TLL ioremap failed\n");
>>  		ret = -ENOMEM;
>> -		goto err_usbtll_p2_fck;
>> +		goto err_mem;
>>  	}
>>  
>> +	tll->base = base;
>>  	platform_set_drvdata(pdev, tll);
>>  	pm_runtime_enable(dev);
>>  	pm_runtime_get_sync(dev);
>> @@ -262,16 +253,33 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>>  	ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
>>  	switch (ver) {
>>  	case OMAP_USBTLL_REV1:
>> -	case OMAP_USBTLL_REV2:
>> -		count = OMAP_TLL_CHANNEL_COUNT;
>> +		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
>>  		break;
>> +	case OMAP_USBTLL_REV2:
>>  	case OMAP_USBTLL_REV3:
>> -		count = OMAP_REV2_TLL_CHANNEL_COUNT;
>> +		tll->nch = REV2_TLL_CHANNEL_COUNT;
> 
> nice, you *can* figure that out based on the revision... In that case,
> you shouldn't even define MAX_TLL_CHANNEL_COUNT, just allocate the array
> dynamically for the exact size you need.
> 

OK.

>>  		break;
>>  	default:
>> -		dev_err(dev, "TLL version failed\n");
>> -		ret = -ENODEV;
>> -		goto err_ioremap;
>> +		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
>> +		dev_info(dev,
>> +		 "USB TLL Rev : 0x%x not recognized, assuming %d channels\n",
>> +			ver, tll->nch);
> 
> this hsould be dev_dbg().
> 

I think it should be more of a warning because it signals a problem.
There is another pr_info in the success path which could probably be a
dev_dbg.

>> +		break;
>> +	}
>> +
>> +	for (i = 0; i < tll->nch; i++) {
>> +		char clk_name[] = "usb_tll_hs_usb_chx_clk";
> 
> just lazyness of counting the amount of letters ? :-p

;)

> 
>> +		struct clk *fck;
>> +
>> +		sprintf(clk_name, "usb_tll_hs_usb_ch%d_clk", i);
> 
> this will overflow if 'i' (for whatever reason) goes over 9.

OK i'll add an extra character. Highly unlikely to go above 99 :)

> 
>> +		fck = clk_get(dev, clk_name);
> 
> please use devm_clk_get().
> 
>> +		if (IS_ERR(fck)) {
>> +			dev_err(dev, "can't get clock : %s\n", clk_name);
>> +			ret = PTR_ERR(fck);
>> +			goto err_clk;
>> +		}
>> +		tll->ch_clk[i] = fck;
>>  	}
>>  
>>  	if (is_ehci_tll_mode(pdata->port_mode[0]) ||
>> @@ -291,7 +299,7 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>>  		usbtll_write(base, OMAP_TLL_SHARED_CONF, reg);
>>  
>>  		/* Enable channels now */
>> -		for (i = 0; i < count; i++) {
>> +		for (i = 0; i < tll->nch; i++) {
>>  			reg = usbtll_read(base,	OMAP_TLL_CHANNEL_CONF(i));
>>  
>>  			if (is_ohci_port(pdata->port_mode[i])) {
>> @@ -319,25 +327,25 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>>  		}
>>  	}
>>  
>> -err_ioremap:
>> -	spin_unlock_irqrestore(&tll->lock, flags);
>> -	iounmap(base);
>> -	pm_runtime_put_sync(dev);
>>  	tll_pdev = pdev;
>> -	if (!ret)
>> -		goto end;
>> -	pm_runtime_disable(dev);
>>  
>> -err_usbtll_p2_fck:
>> -	clk_put(tll->usbtll_p2_fck);
>> +err_clk:
>> +	for (--i; i >= 0 ; i--)
>> +		clk_put(tll->ch_clk[i]);
> 
> is clk_put(NULL) safe ??
> 
>> -err_usbtll_p1_fck:
>> -	clk_put(tll->usbtll_p1_fck);
>> +	spin_unlock_irqrestore(&tll->lock, flags);
>> +	pm_runtime_put_sync(dev);
>> +	if (ret == 0) {
>> +		pr_info("OMAP USB TLL : revision 0x%x, channels %d\n",
>> +				ver, tll->nch);
>> +		return 0;
>> +	}
> 
> the whole thing is quite confusing. Please while cleaning up the driver,
> also try to clean up the error path.
> 
>> -err_tll:
>> -	kfree(tll);
>> +	iounmap(base);
> 
> could be using devm_request_and_ioremap()
> 
>> +	pm_runtime_disable(dev);
>>  
>> -end:
>> +err_mem:
>> +	kfree(tll);
> 
> could be using devm_kzalloc()
> 
>>  	return ret;
>>  }
>>  
>> @@ -350,9 +358,12 @@ end:
>>  static int __devexit usbtll_omap_remove(struct platform_device *pdev)
>>  {
>>  	struct usbtll_omap *tll = platform_get_drvdata(pdev);
>> +	int i;
>> +
>> +	iounmap(tll->base);
>> +	for (i = 0; i < tll->nch; i++)
>> +		clk_put(tll->ch_clk[i]);
>>  
>> -	clk_put(tll->usbtll_p2_fck);
>> -	clk_put(tll->usbtll_p1_fck);
>>  	pm_runtime_disable(&pdev->dev);
>>  	kfree(tll);
>>  	return 0;
>> @@ -363,6 +374,7 @@ static int usbtll_runtime_resume(struct device *dev)
>>  	struct usbtll_omap			*tll = dev_get_drvdata(dev);
>>  	struct usbtll_omap_platform_data	*pdata = tll->pdata;
>>  	unsigned long				flags;
>> +	int i;
>>  
>>  	dev_dbg(dev, "usbtll_runtime_resume\n");
>>  
>> @@ -373,11 +385,17 @@ static int usbtll_runtime_resume(struct device *dev)
>>  
>>  	spin_lock_irqsave(&tll->lock, flags);
>>  
>> -	if (is_ehci_tll_mode(pdata->port_mode[0]))
>> -		clk_enable(tll->usbtll_p1_fck);
>> -
>> -	if (is_ehci_tll_mode(pdata->port_mode[1]))
>> -		clk_enable(tll->usbtll_p2_fck);
>> +	for (i = 0; i < tll->nch; i++) {
>> +		if (is_ehci_tll_mode(pdata->port_mode[i])) {
>> +			int r;
>> +			r = clk_enable(tll->ch_clk[i]);
>> +			if (r) {
>> +				dev_err(dev,
>> +				 "%s : Error enabling ch %d clock: %d\n",
>> +				 __func__, i, r);
> 
> you don't need __func__.
> 

Thought it would be useful to point out where the message is coming
from. But it should be easy to grep too so I'll remove it.

cheers,
-roger

Re: [PATCH 02/16] mfd: omap-usb-tll: Clean up clock handling

[Felipe Balbi]

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

Hi,

On Wed, Nov 21, 2012 at 02:36:48PM +0200, Roger Quadros wrote:
> >>  		break;
> >>  	default:
> >> -		dev_err(dev, "TLL version failed\n");
> >> -		ret = -ENODEV;
> >> -		goto err_ioremap;
> >> +		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
> >> +		dev_info(dev,
> >> +		 "USB TLL Rev : 0x%x not recognized, assuming %d channels\n",
> >> +			ver, tll->nch);
> > 
> > this hsould be dev_dbg().
> > 
> 
> I think it should be more of a warning because it signals a problem.
> There is another pr_info in the success path which could probably be a
> dev_dbg.

it's not a problem at all. It just means that a newer OMAP has come to
market and perhaps we don't need extra code to support it. A revision
detection should *never* be grounds to failure. When we can't understand
the revision, we default to the highest possible value we know.

that's not an error.

> >> +		struct clk *fck;
> >> +
> >> +		sprintf(clk_name, "usb_tll_hs_usb_ch%d_clk", i);
> > 
> > this will overflow if 'i' (for whatever reason) goes over 9.
> 
> OK i'll add an extra character. Highly unlikely to go above 99 :)

I'd stick to snprintf() though, or something safer.

> >> +		fck = clk_get(dev, clk_name);
> > 
> > please use devm_clk_get().

sidenote, it would be amazing to a patch at the top of this series
converting to devm_* api ;-)

> >> @@ -373,11 +385,17 @@ static int usbtll_runtime_resume(struct device *dev)
> >>  
> >>  	spin_lock_irqsave(&tll->lock, flags);
> >>  
> >> -	if (is_ehci_tll_mode(pdata->port_mode[0]))
> >> -		clk_enable(tll->usbtll_p1_fck);
> >> -
> >> -	if (is_ehci_tll_mode(pdata->port_mode[1]))
> >> -		clk_enable(tll->usbtll_p2_fck);
> >> +	for (i = 0; i < tll->nch; i++) {
> >> +		if (is_ehci_tll_mode(pdata->port_mode[i])) {
> >> +			int r;
> >> +			r = clk_enable(tll->ch_clk[i]);
> >> +			if (r) {
> >> +				dev_err(dev,
> >> +				 "%s : Error enabling ch %d clock: %d\n",
> >> +				 __func__, i, r);
> > 
> > you don't need __func__.
> > 
> 
> Thought it would be useful to point out where the message is coming
> from. But it should be easy to grep too so I'll remove it.

correct, if messages are unique, you don't need __func__ anyway ;-)

-- 
balbi

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

Re: [PATCH 02/16] mfd: omap-usb-tll: Clean up clock handling

[Roger Quadros]

On 11/21/2012 04:03 PM, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Nov 21, 2012 at 02:36:48PM +0200, Roger Quadros wrote:
>>>>  		break;
>>>>  	default:
>>>> -		dev_err(dev, "TLL version failed\n");
>>>> -		ret = -ENODEV;
>>>> -		goto err_ioremap;
>>>> +		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
>>>> +		dev_info(dev,
>>>> +		 "USB TLL Rev : 0x%x not recognized, assuming %d channels\n",
>>>> +			ver, tll->nch);
>>>
>>> this hsould be dev_dbg().
>>>
>>
>> I think it should be more of a warning because it signals a problem.
>> There is another pr_info in the success path which could probably be a
>> dev_dbg.
> 
> it's not a problem at all. It just means that a newer OMAP has come to
> market and perhaps we don't need extra code to support it. A revision
> detection should *never* be grounds to failure. When we can't understand
> the revision, we default to the highest possible value we know.
> 
> that's not an error.

Agreed. I'm not treating it as an error. We still continue probe and the
driver should work for newer revisions. Just prints a line on the
console about the new revision. Thought it would be useful to us, but if
you think it is a problem I don't mind removing it :).

> 
>>>> +		struct clk *fck;
>>>> +
>>>> +		sprintf(clk_name, "usb_tll_hs_usb_ch%d_clk", i);
>>>
>>> this will overflow if 'i' (for whatever reason) goes over 9.
>>
>> OK i'll add an extra character. Highly unlikely to go above 99 :)
> 
> I'd stick to snprintf() though, or something safer.

OK.

> 
>>>> +		fck = clk_get(dev, clk_name);
>>>
>>> please use devm_clk_get().
> 
> sidenote, it would be amazing to a patch at the top of this series
> converting to devm_* api ;-)
> 
>>>> @@ -373,11 +385,17 @@ static int usbtll_runtime_resume(struct device *dev)
>>>>  
>>>>  	spin_lock_irqsave(&tll->lock, flags);
>>>>  
>>>> -	if (is_ehci_tll_mode(pdata->port_mode[0]))
>>>> -		clk_enable(tll->usbtll_p1_fck);
>>>> -
>>>> -	if (is_ehci_tll_mode(pdata->port_mode[1]))
>>>> -		clk_enable(tll->usbtll_p2_fck);
>>>> +	for (i = 0; i < tll->nch; i++) {
>>>> +		if (is_ehci_tll_mode(pdata->port_mode[i])) {
>>>> +			int r;
>>>> +			r = clk_enable(tll->ch_clk[i]);
>>>> +			if (r) {
>>>> +				dev_err(dev,
>>>> +				 "%s : Error enabling ch %d clock: %d\n",
>>>> +				 __func__, i, r);
>>>
>>> you don't need __func__.
>>>
>>
>> Thought it would be useful to point out where the message is coming
>> from. But it should be easy to grep too so I'll remove it.
> 
> correct, if messages are unique, you don't need __func__ anyway ;-)
> 

--
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 02/16] mfd: omap-usb-tll: Clean up clock handling

[Felipe Balbi]

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

Hi,

On Wed, Nov 21, 2012 at 05:39:57PM +0200, Roger Quadros wrote:
> On 11/21/2012 04:03 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Nov 21, 2012 at 02:36:48PM +0200, Roger Quadros wrote:
> >>>>  		break;
> >>>>  	default:
> >>>> -		dev_err(dev, "TLL version failed\n");
> >>>> -		ret = -ENODEV;
> >>>> -		goto err_ioremap;
> >>>> +		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
> >>>> +		dev_info(dev,
> >>>> +		 "USB TLL Rev : 0x%x not recognized, assuming %d channels\n",
> >>>> +			ver, tll->nch);
> >>>
> >>> this hsould be dev_dbg().
> >>>
> >>
> >> I think it should be more of a warning because it signals a problem.
> >> There is another pr_info in the success path which could probably be a
> >> dev_dbg.
> > 
> > it's not a problem at all. It just means that a newer OMAP has come to
> > market and perhaps we don't need extra code to support it. A revision
> > detection should *never* be grounds to failure. When we can't understand
> > the revision, we default to the highest possible value we know.
> > 
> > that's not an error.
> 
> Agreed. I'm not treating it as an error. We still continue probe and the
> driver should work for newer revisions. Just prints a line on the
> console about the new revision. Thought it would be useful to us, but if
> you think it is a problem I don't mind removing it :).

that's the thing. It _is_ useful to *us*, kernel/device-driver
engineers. But for the end user it just ends up as yet another
meaningless print in dmesg ;-)

-- 
balbi

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

Re: [PATCH 02/16] mfd: omap-usb-tll: Clean up clock handling

[Roger Quadros]

On 11/21/2012 09:39 PM, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Nov 21, 2012 at 05:39:57PM +0200, Roger Quadros wrote:
>> On 11/21/2012 04:03 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Wed, Nov 21, 2012 at 02:36:48PM +0200, Roger Quadros wrote:
>>>>>>  		break;
>>>>>>  	default:
>>>>>> -		dev_err(dev, "TLL version failed\n");
>>>>>> -		ret = -ENODEV;
>>>>>> -		goto err_ioremap;
>>>>>> +		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
>>>>>> +		dev_info(dev,
>>>>>> +		 "USB TLL Rev : 0x%x not recognized, assuming %d channels\n",
>>>>>> +			ver, tll->nch);
>>>>>
>>>>> this hsould be dev_dbg().
>>>>>
>>>>
>>>> I think it should be more of a warning because it signals a problem.
>>>> There is another pr_info in the success path which could probably be a
>>>> dev_dbg.
>>>
>>> it's not a problem at all. It just means that a newer OMAP has come to
>>> market and perhaps we don't need extra code to support it. A revision
>>> detection should *never* be grounds to failure. When we can't understand
>>> the revision, we default to the highest possible value we know.
>>>
>>> that's not an error.
>>
>> Agreed. I'm not treating it as an error. We still continue probe and the
>> driver should work for newer revisions. Just prints a line on the
>> console about the new revision. Thought it would be useful to us, but if
>> you think it is a problem I don't mind removing it :).
> 
> that's the thing. It _is_ useful to *us*, kernel/device-driver
> engineers. But for the end user it just ends up as yet another
> meaningless print in dmesg ;-)
> 

Okay, makes sense. I'll convert it to dev_dbg().

--
cheers,
-roger

[PATCH 03/16] mfd: omap-usb-tll: introduce and use mode_needs_tll()

[Roger Quadros]

This is a handy macro to check if the port requires the
USB TLL module or not. Use it to Enable the TLL module and manage
the clocks.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/mfd/omap-usb-tll.c |   20 ++++++++++++--------
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 943ac14..7054395e 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -99,6 +99,10 @@
 
 #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
 
+/* only PHY and UNUSED modes don't need TLL */
+#define mode_needs_tll(x)	((x != OMAP_USBHS_PORT_MODE_UNUSED) && \
+				 (x != OMAP_EHCI_PORT_MODE_PHY))
+
 struct usbtll_omap {
 	void __iomem				*base;
 	int					nch;	/* number of channels */
@@ -216,6 +220,7 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 	unsigned long				flags;
 	int					ret = 0;
 	int					i, ver;
+	bool needs_tll;
 
 	dev_dbg(dev, "starting TI HSUSB TLL Controller\n");
 
@@ -282,12 +287,11 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 		tll->ch_clk[i] = fck;
 	}
 
-	if (is_ehci_tll_mode(pdata->port_mode[0]) ||
-	    is_ehci_tll_mode(pdata->port_mode[1]) ||
-	    is_ehci_tll_mode(pdata->port_mode[2]) ||
-	    is_ohci_port(pdata->port_mode[0]) ||
-	    is_ohci_port(pdata->port_mode[1]) ||
-	    is_ohci_port(pdata->port_mode[2])) {
+	needs_tll = false;
+	for (i = 0; i < tll->nch; i++)
+		needs_tll |= mode_needs_tll(pdata->port_mode[i]);
+
+	if (needs_tll) {
 
 		/* Program Common TLL register */
 		reg = usbtll_read(base, OMAP_TLL_SHARED_CONF);
@@ -386,7 +390,7 @@ static int usbtll_runtime_resume(struct device *dev)
 	spin_lock_irqsave(&tll->lock, flags);
 
 	for (i = 0; i < tll->nch; i++) {
-		if (is_ehci_tll_mode(pdata->port_mode[i])) {
+		if (mode_needs_tll(pdata->port_mode[i])) {
 			int r;
 			r = clk_enable(tll->ch_clk[i]);
 			if (r) {
@@ -419,7 +423,7 @@ static int usbtll_runtime_suspend(struct device *dev)
 	spin_lock_irqsave(&tll->lock, flags);
 
 	for (i = 0; i < tll->nch; i++) {
-		if (is_ehci_tll_mode(pdata->port_mode[i]))
+		if (mode_needs_tll(pdata->port_mode[i]))
 			clk_disable(tll->ch_clk[i]);
 	}
 
-- 
1.7.4.1

Re: [PATCH 03/16] mfd: omap-usb-tll: introduce and use mode_needs_tll()

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:01PM +0200, Roger Quadros wrote:
> This is a handy macro to check if the port requires the
> USB TLL module or not. Use it to Enable the TLL module and manage
> the clocks.
> 
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
>  drivers/mfd/omap-usb-tll.c |   20 ++++++++++++--------
>  1 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> index 943ac14..7054395e 100644
> --- a/drivers/mfd/omap-usb-tll.c
> +++ b/drivers/mfd/omap-usb-tll.c
> @@ -99,6 +99,10 @@
>  
>  #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
>  
> +/* only PHY and UNUSED modes don't need TLL */
> +#define mode_needs_tll(x)	((x != OMAP_USBHS_PORT_MODE_UNUSED) && \

prepend with omap_usb_

> +				 (x != OMAP_EHCI_PORT_MODE_PHY))
> +
>  struct usbtll_omap {
>  	void __iomem				*base;
>  	int					nch;	/* number of channels */
> @@ -216,6 +220,7 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  	unsigned long				flags;
>  	int					ret = 0;
>  	int					i, ver;
> +	bool needs_tll;
>  
>  	dev_dbg(dev, "starting TI HSUSB TLL Controller\n");
>  
> @@ -282,12 +287,11 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  		tll->ch_clk[i] = fck;
>  	}
>  
> -	if (is_ehci_tll_mode(pdata->port_mode[0]) ||
> -	    is_ehci_tll_mode(pdata->port_mode[1]) ||
> -	    is_ehci_tll_mode(pdata->port_mode[2]) ||
> -	    is_ohci_port(pdata->port_mode[0]) ||
> -	    is_ohci_port(pdata->port_mode[1]) ||
> -	    is_ohci_port(pdata->port_mode[2])) {
> +	needs_tll = false;
> +	for (i = 0; i < tll->nch; i++)
> +		needs_tll |= mode_needs_tll(pdata->port_mode[i]);
> +
> +	if (needs_tll) {
>  
>  		/* Program Common TLL register */
>  		reg = usbtll_read(base, OMAP_TLL_SHARED_CONF);
> @@ -386,7 +390,7 @@ static int usbtll_runtime_resume(struct device *dev)
>  	spin_lock_irqsave(&tll->lock, flags);
>  
>  	for (i = 0; i < tll->nch; i++) {
> -		if (is_ehci_tll_mode(pdata->port_mode[i])) {
> +		if (mode_needs_tll(pdata->port_mode[i])) {
>  			int r;
>  			r = clk_enable(tll->ch_clk[i]);
>  			if (r) {
> @@ -419,7 +423,7 @@ static int usbtll_runtime_suspend(struct device *dev)
>  	spin_lock_irqsave(&tll->lock, flags);
>  
>  	for (i = 0; i < tll->nch; i++) {
> -		if (is_ehci_tll_mode(pdata->port_mode[i]))
> +		if (mode_needs_tll(pdata->port_mode[i]))
>  			clk_disable(tll->ch_clk[i]);
>  	}
>  
> -- 
> 1.7.4.1
> 

-- 
balbi

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

Re: [PATCH 03/16] mfd: omap-usb-tll: introduce and use mode_needs_tll()

[Roger Quadros]

On 11/21/2012 01:57 PM, Felipe Balbi wrote:
> On Thu, Nov 15, 2012 at 04:34:01PM +0200, Roger Quadros wrote:
>> This is a handy macro to check if the port requires the
>> USB TLL module or not. Use it to Enable the TLL module and manage
>> the clocks.
>>
>> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>> ---
>>  drivers/mfd/omap-usb-tll.c |   20 ++++++++++++--------
>>  1 files changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
>> index 943ac14..7054395e 100644
>> --- a/drivers/mfd/omap-usb-tll.c
>> +++ b/drivers/mfd/omap-usb-tll.c
>> @@ -99,6 +99,10 @@
>>  
>>  #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
>>  
>> +/* only PHY and UNUSED modes don't need TLL */
>> +#define mode_needs_tll(x)	((x != OMAP_USBHS_PORT_MODE_UNUSED) && \
> 
> prepend with omap_usb_

OK.

cheers,
-roger
--
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 07/16] mfd: omap_usb_host: Avoid creating copy of platform_data

[Roger Quadros]

We can just hold the pointer to the platform data instead
of creating a copy of it.

Also get rid of the unnecessary missing platform data checks
in runtime_suspend/resume. We are already checking for missing
platform data in probe.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/mfd/omap-usb-host.c |   34 ++++++++++------------------------
 1 files changed, 10 insertions(+), 24 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7303c41..44772ae 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -103,7 +103,7 @@ struct usbhs_hcd_omap {
 
 	void __iomem			*uhh_base;
 
-	struct usbhs_omap_platform_data	platdata;
+	struct usbhs_omap_platform_data	*pdata;
 
 	u32				usbhs_rev;
 	spinlock_t			lock;
@@ -195,8 +195,8 @@ static int omap_usbhs_alloc_children(struct platform_device *pdev)
 	int					ret;
 
 	omap = platform_get_drvdata(pdev);
-	ehci_data = omap->platdata.ehci_data;
-	ohci_data = omap->platdata.ohci_data;
+	ehci_data = omap->pdata->ehci_data;
+	ohci_data = omap->pdata->ohci_data;
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ehci");
 	if (!res) {
@@ -279,17 +279,12 @@ static bool is_ohci_port(enum usbhs_omap_port_mode pmode)
 static int usbhs_runtime_resume(struct device *dev)
 {
 	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
-	struct usbhs_omap_platform_data	*pdata = &omap->platdata;
 	unsigned long			flags;
+	struct usbhs_omap_platform_data *pdata = omap->pdata;
 	int i, r;
 
 	dev_dbg(dev, "usbhs_runtime_resume\n");
 
-	if (!pdata) {
-		dev_dbg(dev, "missing platform_data\n");
-		return  -ENODEV;
-	}
-
 	omap_tll_enable();
 	spin_lock_irqsave(&omap->lock, flags);
 
@@ -317,17 +312,12 @@ static int usbhs_runtime_resume(struct device *dev)
 static int usbhs_runtime_suspend(struct device *dev)
 {
 	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
-	struct usbhs_omap_platform_data	*pdata = &omap->platdata;
 	unsigned long			flags;
+	struct usbhs_omap_platform_data *pdata = omap->pdata;
 	int i;
 
 	dev_dbg(dev, "usbhs_runtime_suspend\n");
 
-	if (!pdata) {
-		dev_dbg(dev, "missing platform_data\n");
-		return  -ENODEV;
-	}
-
 	spin_lock_irqsave(&omap->lock, flags);
 
 	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
@@ -349,7 +339,7 @@ static int usbhs_runtime_suspend(struct device *dev)
 static void omap_usbhs_init(struct device *dev)
 {
 	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
-	struct usbhs_omap_platform_data	*pdata = &omap->platdata;
+	struct usbhs_omap_platform_data	*pdata = omap->pdata;
 	unsigned long			flags;
 	unsigned			reg;
 
@@ -456,7 +446,7 @@ static void omap_usbhs_init(struct device *dev)
 static void omap_usbhs_deinit(struct device *dev)
 {
 	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
-	struct usbhs_omap_platform_data	*pdata = &omap->platdata;
+	struct usbhs_omap_platform_data	*pdata = omap->pdata;
 
 	if (pdata->ehci_data->phy_reset) {
 		if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[0]))
@@ -509,19 +499,16 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 
 	spin_lock_init(&omap->lock);
 
+	omap->pdata = pdata;
+	platform_set_drvdata(pdev, omap);
+
 	need_logic_fck = false;
 	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
-		omap->platdata.port_mode[i] = pdata->port_mode[i];
-
 		if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
 			is_ehci_hsic_mode(i))
 				need_logic_fck |= true;
 	}
 
-	omap->platdata.ehci_data = pdata->ehci_data;
-	omap->platdata.ohci_data = pdata->ohci_data;
-
-
 	if (need_logic_fck) {
 		omap->ehci_logic_fck = clk_get(dev, "ehci_logic_fck");
 		if (IS_ERR(omap->ehci_logic_fck)) {
@@ -600,7 +587,6 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 				"failed error:%d\n", ret);
 	}
 
-	platform_set_drvdata(pdev, omap);
 
 	pm_runtime_enable(dev);
 
-- 
1.7.4.1

Re: [PATCH 07/16] mfd: omap_usb_host: Avoid creating copy of platform_data

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:05PM +0200, Roger Quadros wrote:
> We can just hold the pointer to the platform data instead
> of creating a copy of it.
> 
> Also get rid of the unnecessary missing platform data checks
> in runtime_suspend/resume. We are already checking for missing
> platform data in probe.
> 
> Signed-off-by: Roger Quadros <rogerq@ti.com>

This looks ok:

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

> ---
>  drivers/mfd/omap-usb-host.c |   34 ++++++++++------------------------
>  1 files changed, 10 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 7303c41..44772ae 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -103,7 +103,7 @@ struct usbhs_hcd_omap {
>  
>  	void __iomem			*uhh_base;
>  
> -	struct usbhs_omap_platform_data	platdata;
> +	struct usbhs_omap_platform_data	*pdata;
>  
>  	u32				usbhs_rev;
>  	spinlock_t			lock;
> @@ -195,8 +195,8 @@ static int omap_usbhs_alloc_children(struct platform_device *pdev)
>  	int					ret;
>  
>  	omap = platform_get_drvdata(pdev);
> -	ehci_data = omap->platdata.ehci_data;
> -	ohci_data = omap->platdata.ohci_data;
> +	ehci_data = omap->pdata->ehci_data;
> +	ohci_data = omap->pdata->ohci_data;
>  
>  	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ehci");
>  	if (!res) {
> @@ -279,17 +279,12 @@ static bool is_ohci_port(enum usbhs_omap_port_mode pmode)
>  static int usbhs_runtime_resume(struct device *dev)
>  {
>  	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
> -	struct usbhs_omap_platform_data	*pdata = &omap->platdata;
>  	unsigned long			flags;
> +	struct usbhs_omap_platform_data *pdata = omap->pdata;
>  	int i, r;
>  
>  	dev_dbg(dev, "usbhs_runtime_resume\n");
>  
> -	if (!pdata) {
> -		dev_dbg(dev, "missing platform_data\n");
> -		return  -ENODEV;
> -	}
> -
>  	omap_tll_enable();
>  	spin_lock_irqsave(&omap->lock, flags);
>  
> @@ -317,17 +312,12 @@ static int usbhs_runtime_resume(struct device *dev)
>  static int usbhs_runtime_suspend(struct device *dev)
>  {
>  	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
> -	struct usbhs_omap_platform_data	*pdata = &omap->platdata;
>  	unsigned long			flags;
> +	struct usbhs_omap_platform_data *pdata = omap->pdata;
>  	int i;
>  
>  	dev_dbg(dev, "usbhs_runtime_suspend\n");
>  
> -	if (!pdata) {
> -		dev_dbg(dev, "missing platform_data\n");
> -		return  -ENODEV;
> -	}
> -
>  	spin_lock_irqsave(&omap->lock, flags);
>  
>  	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
> @@ -349,7 +339,7 @@ static int usbhs_runtime_suspend(struct device *dev)
>  static void omap_usbhs_init(struct device *dev)
>  {
>  	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
> -	struct usbhs_omap_platform_data	*pdata = &omap->platdata;
> +	struct usbhs_omap_platform_data	*pdata = omap->pdata;
>  	unsigned long			flags;
>  	unsigned			reg;
>  
> @@ -456,7 +446,7 @@ static void omap_usbhs_init(struct device *dev)
>  static void omap_usbhs_deinit(struct device *dev)
>  {
>  	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
> -	struct usbhs_omap_platform_data	*pdata = &omap->platdata;
> +	struct usbhs_omap_platform_data	*pdata = omap->pdata;
>  
>  	if (pdata->ehci_data->phy_reset) {
>  		if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[0]))
> @@ -509,19 +499,16 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  
>  	spin_lock_init(&omap->lock);
>  
> +	omap->pdata = pdata;
> +	platform_set_drvdata(pdev, omap);
> +
>  	need_logic_fck = false;
>  	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
> -		omap->platdata.port_mode[i] = pdata->port_mode[i];
> -
>  		if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
>  			is_ehci_hsic_mode(i))
>  				need_logic_fck |= true;
>  	}
>  
> -	omap->platdata.ehci_data = pdata->ehci_data;
> -	omap->platdata.ohci_data = pdata->ohci_data;
> -
> -
>  	if (need_logic_fck) {
>  		omap->ehci_logic_fck = clk_get(dev, "ehci_logic_fck");
>  		if (IS_ERR(omap->ehci_logic_fck)) {
> @@ -600,7 +587,6 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  				"failed error:%d\n", ret);
>  	}
>  
> -	platform_set_drvdata(pdev, omap);
>  
>  	pm_runtime_enable(dev);
>  
> -- 
> 1.7.4.1
> 

-- 
balbi

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

[PATCH 08/16] mfd: omap-usb-host: know about number of ports from revision register

[Roger Quadros]

prevents getting clocks that don't exist on the platform.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/mfd/omap-usb-host.c |   47 ++++++++++++++++++++++++++++++++-----------
 1 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 44772ae..ad89939 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -94,6 +94,7 @@ struct usbhs_port {
 };
 
 struct usbhs_hcd_omap {
+	int				nports;
 	struct usbhs_port		port[MAX_HS_USB_PORTS];
 
 	struct clk			*xclk60mhsp1_ck;
@@ -291,7 +292,7 @@ static int usbhs_runtime_resume(struct device *dev)
 	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
 		clk_enable(omap->ehci_logic_fck);
 
-	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
+	for (i = 0; i < omap->nports; i++) {
 		if (is_ehci_tll_mode(pdata->port_mode[i])) {
 			if (omap->port[i].utmi_clk) {
 				r = clk_enable(omap->port[i].utmi_clk);
@@ -320,7 +321,7 @@ static int usbhs_runtime_suspend(struct device *dev)
 
 	spin_lock_irqsave(&omap->lock, flags);
 
-	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
+	for (i = 0; i < omap->nports; i++) {
 		if (is_ehci_tll_mode(pdata->port_mode[i])) {
 			if (omap->port[i].utmi_clk)
 				clk_disable(omap->port[i].utmi_clk);
@@ -360,8 +361,6 @@ static void omap_usbhs_init(struct device *dev)
 
 	pm_runtime_get_sync(dev);
 	spin_lock_irqsave(&omap->lock, flags);
-	omap->usbhs_rev = usbhs_read(omap->uhh_base, OMAP_UHH_REVISION);
-	dev_dbg(dev, "OMAP UHH_REVISION 0x%x\n", omap->usbhs_rev);
 
 	reg = usbhs_read(omap->uhh_base, OMAP_UHH_HOSTCONFIG);
 	/* setup ULPI bypass and burst configurations */
@@ -502,8 +501,32 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 	omap->pdata = pdata;
 	platform_set_drvdata(pdev, omap);
 
+	pm_runtime_enable(dev);
+	pm_runtime_get_sync(dev);
+	omap->usbhs_rev = usbhs_read(omap->uhh_base, OMAP_UHH_REVISION);
+
+	/* we need to call runtime suspend before we update omap->nports
+	 * to prevent unbalanced clk_disable()
+	 */
+	pm_runtime_put_sync(dev);
+
+	switch (omap->usbhs_rev) {
+	case OMAP_USBHS_REV1:
+		omap->nports = 3;
+		break;
+	case OMAP_USBHS_REV2:
+		omap->nports = 2;
+		break;
+	default:
+		omap->nports = MAX_HS_USB_PORTS;
+		dev_info(dev,
+		  "USB HOST Rev : 0x%d not recognized, assuming %d ports\n",
+		   omap->usbhs_rev, omap->nports);
+		break;
+	}
+
 	need_logic_fck = false;
-	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
+	for (i = 0; i < omap->nports; i++) {
 		if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
 			is_ehci_hsic_mode(i))
 				need_logic_fck |= true;
@@ -538,7 +561,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 		goto err_init60m;
 	}
 
-	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
+	for (i = 0; i < omap->nports; i++) {
 		struct clk *pclk;
 		char utmi_clk[] = "usb_host_hs_utmi_px_clk";
 
@@ -588,8 +611,6 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 	}
 
 
-	pm_runtime_enable(dev);
-
 	omap_usbhs_init(dev);
 	ret = omap_usbhs_alloc_children(pdev);
 	if (ret) {
@@ -597,15 +618,15 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 		goto err_alloc;
 	}
 
+	pr_info("OMAP USB HOST : revision 0x%x, ports %d\n",
+			omap->usbhs_rev, omap->nports);
 	return 0;
 
 err_alloc:
 	omap_usbhs_deinit(&pdev->dev);
-
-	pm_runtime_disable(dev);
 	iounmap(omap->uhh_base);
 
-	for (i = 0; i < MAX_HS_USB_PORTS; i++)
+	for (i = 0; i < omap->nports; i++)
 		clk_put(omap->port[i].utmi_clk);
 
 	clk_put(omap->init_60m_fclk);
@@ -619,6 +640,8 @@ err_xclk60mhsp2:
 err_xclk60mhsp1:
 	clk_put(omap->ehci_logic_fck);
 
+	pm_runtime_disable(dev);
+
 err_remap:
 	kfree(omap);
 	return ret;
@@ -639,7 +662,7 @@ static int __devexit usbhs_omap_remove(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	iounmap(omap->uhh_base);
 
-	for (i = 0; i < MAX_HS_USB_PORTS; i++)
+	for (i = 0; i < omap->nports; i++)
 		clk_put(omap->port[i].utmi_clk);
 
 	clk_put(omap->init_60m_fclk);
-- 
1.7.4.1

Re: [PATCH 08/16] mfd: omap-usb-host: know about number of ports from revision register

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:06PM +0200, Roger Quadros wrote:
> prevents getting clocks that don't exist on the platform.
> 
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
>  drivers/mfd/omap-usb-host.c |   47 ++++++++++++++++++++++++++++++++-----------
>  1 files changed, 35 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 44772ae..ad89939 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -94,6 +94,7 @@ struct usbhs_port {
>  };
>  
>  struct usbhs_hcd_omap {
> +	int				nports;
>  	struct usbhs_port		port[MAX_HS_USB_PORTS];
>  
>  	struct clk			*xclk60mhsp1_ck;
> @@ -291,7 +292,7 @@ static int usbhs_runtime_resume(struct device *dev)
>  	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
>  		clk_enable(omap->ehci_logic_fck);
>  
> -	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
> +	for (i = 0; i < omap->nports; i++) {
>  		if (is_ehci_tll_mode(pdata->port_mode[i])) {
>  			if (omap->port[i].utmi_clk) {
>  				r = clk_enable(omap->port[i].utmi_clk);
> @@ -320,7 +321,7 @@ static int usbhs_runtime_suspend(struct device *dev)
>  
>  	spin_lock_irqsave(&omap->lock, flags);
>  
> -	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
> +	for (i = 0; i < omap->nports; i++) {
>  		if (is_ehci_tll_mode(pdata->port_mode[i])) {
>  			if (omap->port[i].utmi_clk)
>  				clk_disable(omap->port[i].utmi_clk);
> @@ -360,8 +361,6 @@ static void omap_usbhs_init(struct device *dev)
>  
>  	pm_runtime_get_sync(dev);
>  	spin_lock_irqsave(&omap->lock, flags);
> -	omap->usbhs_rev = usbhs_read(omap->uhh_base, OMAP_UHH_REVISION);
> -	dev_dbg(dev, "OMAP UHH_REVISION 0x%x\n", omap->usbhs_rev);
>  
>  	reg = usbhs_read(omap->uhh_base, OMAP_UHH_HOSTCONFIG);
>  	/* setup ULPI bypass and burst configurations */
> @@ -502,8 +501,32 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  	omap->pdata = pdata;
>  	platform_set_drvdata(pdev, omap);
>  
> +	pm_runtime_enable(dev);
> +	pm_runtime_get_sync(dev);
> +	omap->usbhs_rev = usbhs_read(omap->uhh_base, OMAP_UHH_REVISION);
> +
> +	/* we need to call runtime suspend before we update omap->nports
> +	 * to prevent unbalanced clk_disable()
> +	 */

wrong comment style.

> +	pm_runtime_put_sync(dev);

does it *really* need to be a synchronous put ?

> +
> +	switch (omap->usbhs_rev) {
> +	case OMAP_USBHS_REV1:
> +		omap->nports = 3;
> +		break;
> +	case OMAP_USBHS_REV2:
> +		omap->nports = 2;
> +		break;
> +	default:
> +		omap->nports = MAX_HS_USB_PORTS;
> +		dev_info(dev,
> +		  "USB HOST Rev : 0x%d not recognized, assuming %d ports\n",
> +		   omap->usbhs_rev, omap->nports);

please make this dev_dbg().

> +		break;
> +	}
> +
>  	need_logic_fck = false;
> -	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
> +	for (i = 0; i < omap->nports; i++) {
>  		if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
>  			is_ehci_hsic_mode(i))
>  				need_logic_fck |= true;
> @@ -538,7 +561,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  		goto err_init60m;
>  	}
>  
> -	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
> +	for (i = 0; i < omap->nports; i++) {
>  		struct clk *pclk;
>  		char utmi_clk[] = "usb_host_hs_utmi_px_clk";
>  
> @@ -588,8 +611,6 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  	}
>  
>  
> -	pm_runtime_enable(dev);

moving this part around isn't part of $SUBJECT aparently.

> -
>  	omap_usbhs_init(dev);
>  	ret = omap_usbhs_alloc_children(pdev);
>  	if (ret) {
> @@ -597,15 +618,15 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  		goto err_alloc;
>  	}
>  
> +	pr_info("OMAP USB HOST : revision 0x%x, ports %d\n",
> +			omap->usbhs_rev, omap->nports);

please remove this pr_info() as it doesn't add anything other than noise
to bootup, IMHO.

>  	return 0;
>  
>  err_alloc:
>  	omap_usbhs_deinit(&pdev->dev);
> -
> -	pm_runtime_disable(dev);
>  	iounmap(omap->uhh_base);
>  
> -	for (i = 0; i < MAX_HS_USB_PORTS; i++)
> +	for (i = 0; i < omap->nports; i++)
>  		clk_put(omap->port[i].utmi_clk);
>  
>  	clk_put(omap->init_60m_fclk);
> @@ -619,6 +640,8 @@ err_xclk60mhsp2:
>  err_xclk60mhsp1:
>  	clk_put(omap->ehci_logic_fck);
>  
> +	pm_runtime_disable(dev);
> +
>  err_remap:
>  	kfree(omap);
>  	return ret;
> @@ -639,7 +662,7 @@ static int __devexit usbhs_omap_remove(struct platform_device *pdev)
>  	pm_runtime_disable(&pdev->dev);
>  	iounmap(omap->uhh_base);
>  
> -	for (i = 0; i < MAX_HS_USB_PORTS; i++)
> +	for (i = 0; i < omap->nports; i++)
>  		clk_put(omap->port[i].utmi_clk);
>  
>  	clk_put(omap->init_60m_fclk);
> -- 
> 1.7.4.1
> 

-- 
balbi

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

Re: [PATCH 08/16] mfd: omap-usb-host: know about number of ports from revision register

[Roger Quadros]

On 11/21/2012 03:43 PM, Felipe Balbi wrote:
> On Thu, Nov 15, 2012 at 04:34:06PM +0200, Roger Quadros wrote:
>> prevents getting clocks that don't exist on the platform.
>>
>> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>> ---
>>  drivers/mfd/omap-usb-host.c |   47 ++++++++++++++++++++++++++++++++-----------
>>  1 files changed, 35 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 44772ae..ad89939 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -94,6 +94,7 @@ struct usbhs_port {
>>  };
>>  
>>  struct usbhs_hcd_omap {
>> +	int				nports;
>>  	struct usbhs_port		port[MAX_HS_USB_PORTS];
>>  
>>  	struct clk			*xclk60mhsp1_ck;
>> @@ -291,7 +292,7 @@ static int usbhs_runtime_resume(struct device *dev)
>>  	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
>>  		clk_enable(omap->ehci_logic_fck);
>>  
>> -	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
>> +	for (i = 0; i < omap->nports; i++) {
>>  		if (is_ehci_tll_mode(pdata->port_mode[i])) {
>>  			if (omap->port[i].utmi_clk) {
>>  				r = clk_enable(omap->port[i].utmi_clk);
>> @@ -320,7 +321,7 @@ static int usbhs_runtime_suspend(struct device *dev)
>>  
>>  	spin_lock_irqsave(&omap->lock, flags);
>>  
>> -	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
>> +	for (i = 0; i < omap->nports; i++) {
>>  		if (is_ehci_tll_mode(pdata->port_mode[i])) {
>>  			if (omap->port[i].utmi_clk)
>>  				clk_disable(omap->port[i].utmi_clk);
>> @@ -360,8 +361,6 @@ static void omap_usbhs_init(struct device *dev)
>>  
>>  	pm_runtime_get_sync(dev);
>>  	spin_lock_irqsave(&omap->lock, flags);
>> -	omap->usbhs_rev = usbhs_read(omap->uhh_base, OMAP_UHH_REVISION);
>> -	dev_dbg(dev, "OMAP UHH_REVISION 0x%x\n", omap->usbhs_rev);
>>  
>>  	reg = usbhs_read(omap->uhh_base, OMAP_UHH_HOSTCONFIG);
>>  	/* setup ULPI bypass and burst configurations */
>> @@ -502,8 +501,32 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>>  	omap->pdata = pdata;
>>  	platform_set_drvdata(pdev, omap);
>>  
>> +	pm_runtime_enable(dev);
>> +	pm_runtime_get_sync(dev);
>> +	omap->usbhs_rev = usbhs_read(omap->uhh_base, OMAP_UHH_REVISION);
>> +
>> +	/* we need to call runtime suspend before we update omap->nports
>> +	 * to prevent unbalanced clk_disable()
>> +	 */
> 
> wrong comment style.
> 
>> +	pm_runtime_put_sync(dev);
> 
> does it *really* need to be a synchronous put ?

No, I'll replace it by the asynchronous variant.

> 
>> +
>> +	switch (omap->usbhs_rev) {
>> +	case OMAP_USBHS_REV1:
>> +		omap->nports = 3;
>> +		break;
>> +	case OMAP_USBHS_REV2:
>> +		omap->nports = 2;
>> +		break;
>> +	default:
>> +		omap->nports = MAX_HS_USB_PORTS;
>> +		dev_info(dev,
>> +		  "USB HOST Rev : 0x%d not recognized, assuming %d ports\n",
>> +		   omap->usbhs_rev, omap->nports);
> 
> please make this dev_dbg().
> 

IMHO, I think this should be displayed on the console as the driver
doesn't really support that revision and might need to be upgraded. It
won't be displayed for existing hardware that we know about till date.

>> +		break;
>> +	}
>> +
>>  	need_logic_fck = false;
>> -	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
>> +	for (i = 0; i < omap->nports; i++) {
>>  		if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
>>  			is_ehci_hsic_mode(i))
>>  				need_logic_fck |= true;
>> @@ -538,7 +561,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>>  		goto err_init60m;
>>  	}
>>  
>> -	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
>> +	for (i = 0; i < omap->nports; i++) {
>>  		struct clk *pclk;
>>  		char utmi_clk[] = "usb_host_hs_utmi_px_clk";
>>  
>> @@ -588,8 +611,6 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>>  	}
>>  
>>  
>> -	pm_runtime_enable(dev);
> 
> moving this part around isn't part of $SUBJECT aparently.

pm_runtime_enable is moved earlier so that we can read the REVISION
register, so it is part of $SUBJECT.

> 
>> -
>>  	omap_usbhs_init(dev);
>>  	ret = omap_usbhs_alloc_children(pdev);
>>  	if (ret) {
>> @@ -597,15 +618,15 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>>  		goto err_alloc;
>>  	}
>>  
>> +	pr_info("OMAP USB HOST : revision 0x%x, ports %d\n",
>> +			omap->usbhs_rev, omap->nports);
> 
> please remove this pr_info() as it doesn't add anything other than noise
> to bootup, IMHO.

OK.

> 
>>  	return 0;
>>  
>>  err_alloc:
>>  	omap_usbhs_deinit(&pdev->dev);
>> -
>> -	pm_runtime_disable(dev);
>>  	iounmap(omap->uhh_base);
>>  
>> -	for (i = 0; i < MAX_HS_USB_PORTS; i++)
>> +	for (i = 0; i < omap->nports; i++)
>>  		clk_put(omap->port[i].utmi_clk);
>>  
>>  	clk_put(omap->init_60m_fclk);
>> @@ -619,6 +640,8 @@ err_xclk60mhsp2:
>>  err_xclk60mhsp1:
>>  	clk_put(omap->ehci_logic_fck);
>>  
>> +	pm_runtime_disable(dev);
>> +
>>  err_remap:
>>  	kfree(omap);
>>  	return ret;
>> @@ -639,7 +662,7 @@ static int __devexit usbhs_omap_remove(struct platform_device *pdev)
>>  	pm_runtime_disable(&pdev->dev);
>>  	iounmap(omap->uhh_base);
>>  
>> -	for (i = 0; i < MAX_HS_USB_PORTS; i++)
>> +	for (i = 0; i < omap->nports; i++)
>>  		clk_put(omap->port[i].utmi_clk);
>>  
>>  	clk_put(omap->init_60m_fclk);
>> -- 
>> 1.7.4.1
>>
> 

--
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 08/16] mfd: omap-usb-host: know about number of ports from revision register

[Felipe Balbi]

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

Hi,

On Wed, Nov 21, 2012 at 04:45:27PM +0200, Roger Quadros wrote:
> >> +	switch (omap->usbhs_rev) {
> >> +	case OMAP_USBHS_REV1:
> >> +		omap->nports = 3;
> >> +		break;
> >> +	case OMAP_USBHS_REV2:
> >> +		omap->nports = 2;
> >> +		break;
> >> +	default:
> >> +		omap->nports = MAX_HS_USB_PORTS;
> >> +		dev_info(dev,
> >> +		  "USB HOST Rev : 0x%d not recognized, assuming %d ports\n",
> >> +		   omap->usbhs_rev, omap->nports);
> > 
> > please make this dev_dbg().
> > 
> 
> IMHO, I think this should be displayed on the console as the driver
> doesn't really support that revision and might need to be upgraded. It
> won't be displayed for existing hardware that we know about till date.

Ok, there are two ways to see this:

a) (my preferred) you don't treat it as an error, you assume that newer
HW is backwards compatible until proven otherwise. If that's the case,
you don't need this message because driver will just work.

b) you treat it as an error, you assume that newer HW is *not* backwards
compatible until prove otherwise. If that's the case, you don't need
this message because driver won't probe.

In both situations the message is pretty much meaningless. I prefer to
assume driver will work with newer HW and if it doesn't, it just means
(NOTICE, THIS IS MY OWN OPINION, NOT MY EMPLOYER'S OPINION BY ANY MEANS)
we're not fast enough delivering code to mainline kernel. We are the
first ones to have access to the HW afterall ;-)

> >> +		break;
> >> +	}
> >> +
> >>  	need_logic_fck = false;
> >> -	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
> >> +	for (i = 0; i < omap->nports; i++) {
> >>  		if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
> >>  			is_ehci_hsic_mode(i))
> >>  				need_logic_fck |= true;
> >> @@ -538,7 +561,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
> >>  		goto err_init60m;
> >>  	}
> >>  
> >> -	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
> >> +	for (i = 0; i < omap->nports; i++) {
> >>  		struct clk *pclk;
> >>  		char utmi_clk[] = "usb_host_hs_utmi_px_clk";
> >>  
> >> @@ -588,8 +611,6 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
> >>  	}
> >>  
> >>  
> >> -	pm_runtime_enable(dev);
> > 
> > moving this part around isn't part of $SUBJECT aparently.
> 
> pm_runtime_enable is moved earlier so that we can read the REVISION
> register, so it is part of $SUBJECT.

fair enough, but then it needs to be mentioned on commit log.

-- 
balbi

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

[PATCH 09/16] mfd: omap-usb-host: override number of ports from platform data

[Roger Quadros]

For some platforms e.g. OMAP5, we cannot rely on USBHOST revision
to determine the number of ports available. In such cases we have
to rely on platform data (or FDT) to give us the right number of
ports.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/mach-omap2/usb-host.c        |    1 +
 arch/arm/plat-omap/include/plat/usb.h |    2 +
 drivers/mfd/omap-usb-host.c           |   46 +++++++++++++++++++++++----------
 3 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 3c43449..eb85528 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -504,6 +504,7 @@ void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
 	ohci_data.es2_compatibility = pdata->es2_compatibility;
 	usbhs_data.ehci_data = &ehci_data;
 	usbhs_data.ohci_data = &ohci_data;
+	usbhs_data.nports = pdata->nports;
 
 	if (cpu_is_omap34xx()) {
 		setup_ehci_io_mux(pdata->port_mode);
diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
index 87ee140..6b618a1 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -27,6 +27,7 @@ enum usbhs_omap_port_mode {
 };
 
 struct usbhs_omap_board_data {
+	int				nports;
 	enum usbhs_omap_port_mode	port_mode[OMAP3_HS_USB_PORTS];
 
 	/* have to be valid if phy_reset is true and portx is in phy mode */
@@ -59,6 +60,7 @@ struct ohci_hcd_omap_platform_data {
 };
 
 struct usbhs_omap_platform_data {
+	int					nports;
 	enum usbhs_omap_port_mode		port_mode[OMAP3_HS_USB_PORTS];
 
 	struct ehci_hcd_omap_platform_data	*ehci_data;
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index ad89939..c20234b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -500,8 +500,8 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 
 	omap->pdata = pdata;
 	platform_set_drvdata(pdev, omap);
-
 	pm_runtime_enable(dev);
+
 	pm_runtime_get_sync(dev);
 	omap->usbhs_rev = usbhs_read(omap->uhh_base, OMAP_UHH_REVISION);
 
@@ -510,19 +510,37 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 	 */
 	pm_runtime_put_sync(dev);
 
-	switch (omap->usbhs_rev) {
-	case OMAP_USBHS_REV1:
-		omap->nports = 3;
-		break;
-	case OMAP_USBHS_REV2:
-		omap->nports = 2;
-		break;
-	default:
-		omap->nports = MAX_HS_USB_PORTS;
-		dev_info(dev,
-		  "USB HOST Rev : 0x%d not recognized, assuming %d ports\n",
-		   omap->usbhs_rev, omap->nports);
-		break;
+	/*
+	 * If platform data contains nports then use that
+	 * else make out number of ports from USBHS revision
+	 */
+	if (pdata->nports) {
+		if (omap->nports > MAX_HS_USB_PORTS) {
+			dev_err(dev,
+			 "Platform data says %d ports but MAX_HS_USB_PORTS is %d\n",
+			 omap->nports, MAX_HS_USB_PORTS);
+		} else {
+			omap->nports = pdata->nports;
+		}
+	} else {
+		switch (omap->usbhs_rev) {
+		case OMAP_USBHS_REV1:
+			omap->nports = 3;
+			break;
+		case OMAP_USBHS_REV2:
+		/* Both OMAP4 and 5 show the same revision but they have
+		 * different number of ports i.e. 2 and 3 respectively.
+		 * OMAP5 platforms must supply nports via platform data.
+		 */
+			omap->nports = 2;
+			break;
+		default:
+			omap->nports = MAX_HS_USB_PORTS;
+			dev_info(dev,
+			"USB HOST Rev:0x%d not recognized, assuming %d ports\n",
+				omap->usbhs_rev, omap->nports);
+			break;
+		}
 	}
 
 	need_logic_fck = false;
-- 
1.7.4.1

Re: [PATCH 09/16] mfd: omap-usb-host: override number of ports from platform data

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:07PM +0200, Roger Quadros wrote:
> For some platforms e.g. OMAP5, we cannot rely on USBHOST revision
> to determine the number of ports available. In such cases we have

you need to make it clear *why* we can't. Imagine someone reading this 5
years from now... he'll be all like: "why can't I find any documentation
about this OMAP5 ? Why was it so special that its revision register
wasn't enough to figure out number of ports ?"

> to rely on platform data (or FDT) to give us the right number of
> ports.
> 
> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> ---
>  arch/arm/mach-omap2/usb-host.c        |    1 +
>  arch/arm/plat-omap/include/plat/usb.h |    2 +
>  drivers/mfd/omap-usb-host.c           |   46 +++++++++++++++++++++++----------
>  3 files changed, 35 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
> index 3c43449..eb85528 100644
> --- a/arch/arm/mach-omap2/usb-host.c
> +++ b/arch/arm/mach-omap2/usb-host.c
> @@ -504,6 +504,7 @@ void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
>  	ohci_data.es2_compatibility = pdata->es2_compatibility;
>  	usbhs_data.ehci_data = &ehci_data;
>  	usbhs_data.ohci_data = &ohci_data;
> +	usbhs_data.nports = pdata->nports;
>  
>  	if (cpu_is_omap34xx()) {
>  		setup_ehci_io_mux(pdata->port_mode);
> diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
> index 87ee140..6b618a1 100644
> --- a/arch/arm/plat-omap/include/plat/usb.h
> +++ b/arch/arm/plat-omap/include/plat/usb.h
> @@ -27,6 +27,7 @@ enum usbhs_omap_port_mode {
>  };
>  
>  struct usbhs_omap_board_data {
> +	int				nports;
>  	enum usbhs_omap_port_mode	port_mode[OMAP3_HS_USB_PORTS];
>  
>  	/* have to be valid if phy_reset is true and portx is in phy mode */
> @@ -59,6 +60,7 @@ struct ohci_hcd_omap_platform_data {
>  };
>  
>  struct usbhs_omap_platform_data {
> +	int					nports;
>  	enum usbhs_omap_port_mode		port_mode[OMAP3_HS_USB_PORTS];
>  
>  	struct ehci_hcd_omap_platform_data	*ehci_data;
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index ad89939..c20234b 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -500,8 +500,8 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  
>  	omap->pdata = pdata;
>  	platform_set_drvdata(pdev, omap);
> -
>  	pm_runtime_enable(dev);
> +

trailing change, not part of $SUBJECT.

>  	pm_runtime_get_sync(dev);
>  	omap->usbhs_rev = usbhs_read(omap->uhh_base, OMAP_UHH_REVISION);
>  
> @@ -510,19 +510,37 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  	 */
>  	pm_runtime_put_sync(dev);
>  
> -	switch (omap->usbhs_rev) {
> -	case OMAP_USBHS_REV1:
> -		omap->nports = 3;
> -		break;
> -	case OMAP_USBHS_REV2:
> -		omap->nports = 2;
> -		break;
> -	default:
> -		omap->nports = MAX_HS_USB_PORTS;
> -		dev_info(dev,
> -		  "USB HOST Rev : 0x%d not recognized, assuming %d ports\n",
> -		   omap->usbhs_rev, omap->nports);
> -		break;
> +	/*
> +	 * If platform data contains nports then use that
> +	 * else make out number of ports from USBHS revision
> +	 */
> +	if (pdata->nports) {
> +		if (omap->nports > MAX_HS_USB_PORTS) {
> +			dev_err(dev,
> +			 "Platform data says %d ports but MAX_HS_USB_PORTS is %d\n",
> +			 omap->nports, MAX_HS_USB_PORTS);
> +		} else {
> +			omap->nports = pdata->nports;
> +		}
> +	} else {
> +		switch (omap->usbhs_rev) {
> +		case OMAP_USBHS_REV1:
> +			omap->nports = 3;
> +			break;
> +		case OMAP_USBHS_REV2:
> +		/* Both OMAP4 and 5 show the same revision but they have
> +		 * different number of ports i.e. 2 and 3 respectively.
> +		 * OMAP5 platforms must supply nports via platform data.
> +		 */

comment indentation is wrong.

> +			omap->nports = 2;
> +			break;
> +		default:
> +			omap->nports = MAX_HS_USB_PORTS;
> +			dev_info(dev,
> +			"USB HOST Rev:0x%d not recognized, assuming %d ports\n",
> +				omap->usbhs_rev, omap->nports);

dev_dbg().

-- 
balbi

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

Re: [PATCH 09/16] mfd: omap-usb-host: override number of ports from platform data

[Roger Quadros]

On 11/21/2012 03:45 PM, Felipe Balbi wrote:
> On Thu, Nov 15, 2012 at 04:34:07PM +0200, Roger Quadros wrote:
>> For some platforms e.g. OMAP5, we cannot rely on USBHOST revision
>> to determine the number of ports available. In such cases we have
> 
> you need to make it clear *why* we can't. Imagine someone reading this 5
> years from now... he'll be all like: "why can't I find any documentation
> about this OMAP5 ? Why was it so special that its revision register
> wasn't enough to figure out number of ports ?"

OK, i'll add a note like this "both OMAP5 and OMAP4 exhibit the same
revision ID in the USBHOST_REVISION register, but in fact have different
number of ports physically available on the SoC (i.e. 2 for OMAP4 and 3
for OMAP5 respectively). So we can't rely on REVISION register to
determine number of ports for OMAP5 and depend on platform data/Device
tree instead"

cheers,
-roger

Re: [PATCH 09/16] mfd: omap-usb-host: override number of ports from platform data

[Felipe Balbi]

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

Hi,

On Wed, Nov 21, 2012 at 04:50:42PM +0200, Roger Quadros wrote:
> On 11/21/2012 03:45 PM, Felipe Balbi wrote:
> > On Thu, Nov 15, 2012 at 04:34:07PM +0200, Roger Quadros wrote:
> >> For some platforms e.g. OMAP5, we cannot rely on USBHOST revision
> >> to determine the number of ports available. In such cases we have
> > 
> > you need to make it clear *why* we can't. Imagine someone reading this 5
> > years from now... he'll be all like: "why can't I find any documentation
> > about this OMAP5 ? Why was it so special that its revision register
> > wasn't enough to figure out number of ports ?"
> 
> OK, i'll add a note like this "both OMAP5 and OMAP4 exhibit the same
> revision ID in the USBHOST_REVISION register, but in fact have different
> number of ports physically available on the SoC (i.e. 2 for OMAP4 and 3
> for OMAP5 respectively). So we can't rely on REVISION register to
> determine number of ports for OMAP5 and depend on platform data/Device
> tree instead"

perfect ;-)

-- 
balbi

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

[PATCH 10/16] mfd: omap-usb-host: Intialize all available ports

[Roger Quadros]

OMAPs till date can have upto 3 ports. We need to initialize
the port mode in HOSTCONFIG register for all of them.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/mfd/omap-usb-host.c |   31 ++++++++++++-------------------
 1 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index c20234b..0d39bd7 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -67,12 +67,9 @@
 #define OMAP4_UHH_SYSCONFIG_NOSTDBY			(1 << 4)
 #define OMAP4_UHH_SYSCONFIG_SOFTRESET			(1 << 0)
 
-#define OMAP4_P1_MODE_CLEAR				(3 << 16)
+#define OMAP4_P1_MODE_MASK				(3 << 16)
 #define OMAP4_P1_MODE_TLL				(1 << 16)
 #define OMAP4_P1_MODE_HSIC				(3 << 16)
-#define OMAP4_P2_MODE_CLEAR				(3 << 18)
-#define OMAP4_P2_MODE_TLL				(1 << 18)
-#define OMAP4_P2_MODE_HSIC				(3 << 18)
 
 #define	OMAP_UHH_DEBUG_CSR				(0x44)
 
@@ -343,6 +340,7 @@ static void omap_usbhs_init(struct device *dev)
 	struct usbhs_omap_platform_data	*pdata = omap->pdata;
 	unsigned long			flags;
 	unsigned			reg;
+	int i;
 
 	dev_dbg(dev, "starting TI HSUSB Controller\n");
 
@@ -403,21 +401,16 @@ static void omap_usbhs_init(struct device *dev)
 				reg |= OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS;
 		}
 	} else if (is_omap_usbhs_rev2(omap)) {
-		/* Clear port mode fields for PHY mode*/
-		reg &= ~OMAP4_P1_MODE_CLEAR;
-		reg &= ~OMAP4_P2_MODE_CLEAR;
-
-		if (is_ehci_tll_mode(pdata->port_mode[0]) ||
-			(is_ohci_port(pdata->port_mode[0])))
-			reg |= OMAP4_P1_MODE_TLL;
-		else if (is_ehci_hsic_mode(pdata->port_mode[0]))
-			reg |= OMAP4_P1_MODE_HSIC;
-
-		if (is_ehci_tll_mode(pdata->port_mode[1]) ||
-			(is_ohci_port(pdata->port_mode[1])))
-			reg |= OMAP4_P2_MODE_TLL;
-		else if (is_ehci_hsic_mode(pdata->port_mode[1]))
-			reg |= OMAP4_P2_MODE_HSIC;
+		for (i = 0; i < omap->nports; i++) {
+			/* Clear port mode fields for PHY mode*/
+			reg &= ~(OMAP4_P1_MODE_MASK << 2*i);
+
+			if (is_ehci_tll_mode(pdata->port_mode[i]) ||
+				(is_ohci_port(pdata->port_mode[i])))
+				reg |= OMAP4_P1_MODE_TLL << 2*i;
+			else if (is_ehci_hsic_mode(pdata->port_mode[i]))
+				reg |= OMAP4_P1_MODE_HSIC << 2*i;
+		}
 	}
 
 	usbhs_write(omap->uhh_base, OMAP_UHH_HOSTCONFIG, reg);
-- 
1.7.4.1

Re: [PATCH 10/16] mfd: omap-usb-host: Intialize all available ports

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:08PM +0200, Roger Quadros wrote:
> OMAPs till date can have upto 3 ports. We need to initialize

s/upto/up to/

> the port mode in HOSTCONFIG register for all of them.

why *all* of them ? Isn't it enough to initialize only the ones we're
going to use ? If not, why ?

> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
>  drivers/mfd/omap-usb-host.c |   31 ++++++++++++-------------------
>  1 files changed, 12 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index c20234b..0d39bd7 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -67,12 +67,9 @@
>  #define OMAP4_UHH_SYSCONFIG_NOSTDBY			(1 << 4)
>  #define OMAP4_UHH_SYSCONFIG_SOFTRESET			(1 << 0)
>  
> -#define OMAP4_P1_MODE_CLEAR				(3 << 16)
> +#define OMAP4_P1_MODE_MASK				(3 << 16)

changing this name isn't part of $SUBJECT.

>  #define OMAP4_P1_MODE_TLL				(1 << 16)
>  #define OMAP4_P1_MODE_HSIC				(3 << 16)
> -#define OMAP4_P2_MODE_CLEAR				(3 << 18)
> -#define OMAP4_P2_MODE_TLL				(1 << 18)
> -#define OMAP4_P2_MODE_HSIC				(3 << 18)

why do you delete these ? Also not part of $SUBJECT.

>  
>  #define	OMAP_UHH_DEBUG_CSR				(0x44)
>  
> @@ -343,6 +340,7 @@ static void omap_usbhs_init(struct device *dev)
>  	struct usbhs_omap_platform_data	*pdata = omap->pdata;
>  	unsigned long			flags;
>  	unsigned			reg;
> +	int i;
>  
>  	dev_dbg(dev, "starting TI HSUSB Controller\n");
>  
> @@ -403,21 +401,16 @@ static void omap_usbhs_init(struct device *dev)
>  				reg |= OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS;
>  		}
>  	} else if (is_omap_usbhs_rev2(omap)) {
> -		/* Clear port mode fields for PHY mode*/
> -		reg &= ~OMAP4_P1_MODE_CLEAR;
> -		reg &= ~OMAP4_P2_MODE_CLEAR;
> -
> -		if (is_ehci_tll_mode(pdata->port_mode[0]) ||
> -			(is_ohci_port(pdata->port_mode[0])))
> -			reg |= OMAP4_P1_MODE_TLL;
> -		else if (is_ehci_hsic_mode(pdata->port_mode[0]))
> -			reg |= OMAP4_P1_MODE_HSIC;
> -
> -		if (is_ehci_tll_mode(pdata->port_mode[1]) ||
> -			(is_ohci_port(pdata->port_mode[1])))
> -			reg |= OMAP4_P2_MODE_TLL;
> -		else if (is_ehci_hsic_mode(pdata->port_mode[1]))
> -			reg |= OMAP4_P2_MODE_HSIC;
> +		for (i = 0; i < omap->nports; i++) {
> +			/* Clear port mode fields for PHY mode*/
> +			reg &= ~(OMAP4_P1_MODE_MASK << 2*i);

add spaces around '*' operator.

> +			if (is_ehci_tll_mode(pdata->port_mode[i]) ||
> +				(is_ohci_port(pdata->port_mode[i])))
> +				reg |= OMAP4_P1_MODE_TLL << 2*i;

ditto

> +			else if (is_ehci_hsic_mode(pdata->port_mode[i]))
> +				reg |= OMAP4_P1_MODE_HSIC << 2*i;

ditto

in fact, I would convert this construct into a switch which would look
like:

reg &= ~(OMAP4_P1_MODE_MASK << i * 2);

switch (port_mode[i]) {
case OMAP4_P1_MODE_TLL:
	reg |= OMAP4_P1_MODE_TLL << i * 2;
	break;
case OMAP_P1_MODE_HSIC:
	reg |= OMAP4_P1_MODE_HSIC << i * 2;
	break;
}

Also, it looks like the whoel for loop with port mode settings could be
re-factored to a separate function to aid readability.

-- 
balbi

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

Re: [PATCH 10/16] mfd: omap-usb-host: Intialize all available ports

[Roger Quadros]

On 11/21/2012 03:52 PM, Felipe Balbi wrote:
> On Thu, Nov 15, 2012 at 04:34:08PM +0200, Roger Quadros wrote:
>> OMAPs till date can have upto 3 ports. We need to initialize
> 
> s/upto/up to/
> 
>> the port mode in HOSTCONFIG register for all of them.
> 
> why *all* of them ? Isn't it enough to initialize only the ones we're
> going to use ? If not, why ?

Right. I'll correct the $SUBJECT and comment.

> 
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>>  drivers/mfd/omap-usb-host.c |   31 ++++++++++++-------------------
>>  1 files changed, 12 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index c20234b..0d39bd7 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -67,12 +67,9 @@
>>  #define OMAP4_UHH_SYSCONFIG_NOSTDBY			(1 << 4)
>>  #define OMAP4_UHH_SYSCONFIG_SOFTRESET			(1 << 0)
>>  
>> -#define OMAP4_P1_MODE_CLEAR				(3 << 16)
>> +#define OMAP4_P1_MODE_MASK				(3 << 16)
> 
> changing this name isn't part of $SUBJECT.
> 
>>  #define OMAP4_P1_MODE_TLL				(1 << 16)
>>  #define OMAP4_P1_MODE_HSIC				(3 << 16)
>> -#define OMAP4_P2_MODE_CLEAR				(3 << 18)
>> -#define OMAP4_P2_MODE_TLL				(1 << 18)
>> -#define OMAP4_P2_MODE_HSIC				(3 << 18)
> 
> why do you delete these ? Also not part of $SUBJECT.
> 
>>  
>>  #define	OMAP_UHH_DEBUG_CSR				(0x44)
>>  
>> @@ -343,6 +340,7 @@ static void omap_usbhs_init(struct device *dev)
>>  	struct usbhs_omap_platform_data	*pdata = omap->pdata;
>>  	unsigned long			flags;
>>  	unsigned			reg;
>> +	int i;
>>  
>>  	dev_dbg(dev, "starting TI HSUSB Controller\n");
>>  
>> @@ -403,21 +401,16 @@ static void omap_usbhs_init(struct device *dev)
>>  				reg |= OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS;
>>  		}
>>  	} else if (is_omap_usbhs_rev2(omap)) {
>> -		/* Clear port mode fields for PHY mode*/
>> -		reg &= ~OMAP4_P1_MODE_CLEAR;
>> -		reg &= ~OMAP4_P2_MODE_CLEAR;
>> -
>> -		if (is_ehci_tll_mode(pdata->port_mode[0]) ||
>> -			(is_ohci_port(pdata->port_mode[0])))
>> -			reg |= OMAP4_P1_MODE_TLL;
>> -		else if (is_ehci_hsic_mode(pdata->port_mode[0]))
>> -			reg |= OMAP4_P1_MODE_HSIC;
>> -
>> -		if (is_ehci_tll_mode(pdata->port_mode[1]) ||
>> -			(is_ohci_port(pdata->port_mode[1])))
>> -			reg |= OMAP4_P2_MODE_TLL;
>> -		else if (is_ehci_hsic_mode(pdata->port_mode[1]))
>> -			reg |= OMAP4_P2_MODE_HSIC;
>> +		for (i = 0; i < omap->nports; i++) {
>> +			/* Clear port mode fields for PHY mode*/
>> +			reg &= ~(OMAP4_P1_MODE_MASK << 2*i);
> 
> add spaces around '*' operator.
> 
>> +			if (is_ehci_tll_mode(pdata->port_mode[i]) ||
>> +				(is_ohci_port(pdata->port_mode[i])))
>> +				reg |= OMAP4_P1_MODE_TLL << 2*i;
> 
> ditto
> 
>> +			else if (is_ehci_hsic_mode(pdata->port_mode[i]))
>> +				reg |= OMAP4_P1_MODE_HSIC << 2*i;
> 
> ditto
> 
> in fact, I would convert this construct into a switch which would look
> like:
> 
> reg &= ~(OMAP4_P1_MODE_MASK << i * 2);
> 
> switch (port_mode[i]) {
> case OMAP4_P1_MODE_TLL:
> 	reg |= OMAP4_P1_MODE_TLL << i * 2;
> 	break;
> case OMAP_P1_MODE_HSIC:
> 	reg |= OMAP4_P1_MODE_HSIC << i * 2;
> 	break;
> }
> 
> Also, it looks like the whoel for loop with port mode settings could be
> re-factored to a separate function to aid readability.
> 

To clarify, did you mean to use a function for the above code snippet
where we set the HOSTCONFIG part?

cheers,
-roger

Re: [PATCH 10/16] mfd: omap-usb-host: Intialize all available ports

[Felipe Balbi]

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

hi,

On Wed, Nov 21, 2012 at 05:47:06PM +0200, Roger Quadros wrote:
> On 11/21/2012 03:52 PM, Felipe Balbi wrote:
> > On Thu, Nov 15, 2012 at 04:34:08PM +0200, Roger Quadros wrote:
> >> OMAPs till date can have upto 3 ports. We need to initialize
> > 
> > s/upto/up to/
> > 
> >> the port mode in HOSTCONFIG register for all of them.
> > 
> > why *all* of them ? Isn't it enough to initialize only the ones we're
> > going to use ? If not, why ?
> 
> Right. I'll correct the $SUBJECT and comment.

good, thanks.

> >> @@ -403,21 +401,16 @@ static void omap_usbhs_init(struct device *dev)
> >>  				reg |= OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS;
> >>  		}
> >>  	} else if (is_omap_usbhs_rev2(omap)) {
> >> -		/* Clear port mode fields for PHY mode*/
> >> -		reg &= ~OMAP4_P1_MODE_CLEAR;
> >> -		reg &= ~OMAP4_P2_MODE_CLEAR;
> >> -
> >> -		if (is_ehci_tll_mode(pdata->port_mode[0]) ||
> >> -			(is_ohci_port(pdata->port_mode[0])))
> >> -			reg |= OMAP4_P1_MODE_TLL;
> >> -		else if (is_ehci_hsic_mode(pdata->port_mode[0]))
> >> -			reg |= OMAP4_P1_MODE_HSIC;
> >> -
> >> -		if (is_ehci_tll_mode(pdata->port_mode[1]) ||
> >> -			(is_ohci_port(pdata->port_mode[1])))
> >> -			reg |= OMAP4_P2_MODE_TLL;
> >> -		else if (is_ehci_hsic_mode(pdata->port_mode[1]))
> >> -			reg |= OMAP4_P2_MODE_HSIC;
> >> +		for (i = 0; i < omap->nports; i++) {
> >> +			/* Clear port mode fields for PHY mode*/
> >> +			reg &= ~(OMAP4_P1_MODE_MASK << 2*i);
> > 
> > add spaces around '*' operator.
> > 
> >> +			if (is_ehci_tll_mode(pdata->port_mode[i]) ||
> >> +				(is_ohci_port(pdata->port_mode[i])))
> >> +				reg |= OMAP4_P1_MODE_TLL << 2*i;
> > 
> > ditto
> > 
> >> +			else if (is_ehci_hsic_mode(pdata->port_mode[i]))
> >> +				reg |= OMAP4_P1_MODE_HSIC << 2*i;
> > 
> > ditto
> > 
> > in fact, I would convert this construct into a switch which would look
> > like:
> > 
> > reg &= ~(OMAP4_P1_MODE_MASK << i * 2);
> > 
> > switch (port_mode[i]) {
> > case OMAP4_P1_MODE_TLL:
> > 	reg |= OMAP4_P1_MODE_TLL << i * 2;
> > 	break;
> > case OMAP_P1_MODE_HSIC:
> > 	reg |= OMAP4_P1_MODE_HSIC << i * 2;
> > 	break;
> > }
> > 
> > Also, it looks like the whoel for loop with port mode settings could be
> > re-factored to a separate function to aid readability.
> > 
> 
> To clarify, did you mean to use a function for the above code snippet
> where we set the HOSTCONFIG part?

correct. In fact the entire OMAP USB Host needs quite some love. By
quickly looking at the driver one can easily see many details which can
be greatly improved ;-)

thanks for starting this out ;-)

-- 
balbi

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

Re: [PATCH 10/16] mfd: omap-usb-host: Intialize all available ports

[Roger Quadros]

On 11/21/2012 03:52 PM, Felipe Balbi wrote:
> On Thu, Nov 15, 2012 at 04:34:08PM +0200, Roger Quadros wrote:
>> OMAPs till date can have upto 3 ports. We need to initialize
> 
> s/upto/up to/
> 
>> the port mode in HOSTCONFIG register for all of them.
> 
> why *all* of them ? Isn't it enough to initialize only the ones we're
> going to use ? If not, why ?
> 
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>>  drivers/mfd/omap-usb-host.c |   31 ++++++++++++-------------------
>>  1 files changed, 12 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index c20234b..0d39bd7 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -67,12 +67,9 @@
>>  #define OMAP4_UHH_SYSCONFIG_NOSTDBY			(1 << 4)
>>  #define OMAP4_UHH_SYSCONFIG_SOFTRESET			(1 << 0)
>>  
>> -#define OMAP4_P1_MODE_CLEAR				(3 << 16)
>> +#define OMAP4_P1_MODE_MASK				(3 << 16)
> 
> changing this name isn't part of $SUBJECT.
> 
>>  #define OMAP4_P1_MODE_TLL				(1 << 16)
>>  #define OMAP4_P1_MODE_HSIC				(3 << 16)
>> -#define OMAP4_P2_MODE_CLEAR				(3 << 18)
>> -#define OMAP4_P2_MODE_TLL				(1 << 18)
>> -#define OMAP4_P2_MODE_HSIC				(3 << 18)
> 
> why do you delete these ? Also not part of $SUBJECT.
> 
>>  
>>  #define	OMAP_UHH_DEBUG_CSR				(0x44)
>>  
>> @@ -343,6 +340,7 @@ static void omap_usbhs_init(struct device *dev)
>>  	struct usbhs_omap_platform_data	*pdata = omap->pdata;
>>  	unsigned long			flags;
>>  	unsigned			reg;
>> +	int i;
>>  
>>  	dev_dbg(dev, "starting TI HSUSB Controller\n");
>>  
>> @@ -403,21 +401,16 @@ static void omap_usbhs_init(struct device *dev)
>>  				reg |= OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS;
>>  		}
>>  	} else if (is_omap_usbhs_rev2(omap)) {
>> -		/* Clear port mode fields for PHY mode*/
>> -		reg &= ~OMAP4_P1_MODE_CLEAR;
>> -		reg &= ~OMAP4_P2_MODE_CLEAR;
>> -
>> -		if (is_ehci_tll_mode(pdata->port_mode[0]) ||
>> -			(is_ohci_port(pdata->port_mode[0])))
>> -			reg |= OMAP4_P1_MODE_TLL;
>> -		else if (is_ehci_hsic_mode(pdata->port_mode[0]))
>> -			reg |= OMAP4_P1_MODE_HSIC;
>> -
>> -		if (is_ehci_tll_mode(pdata->port_mode[1]) ||
>> -			(is_ohci_port(pdata->port_mode[1])))
>> -			reg |= OMAP4_P2_MODE_TLL;
>> -		else if (is_ehci_hsic_mode(pdata->port_mode[1]))
>> -			reg |= OMAP4_P2_MODE_HSIC;
>> +		for (i = 0; i < omap->nports; i++) {
>> +			/* Clear port mode fields for PHY mode*/
>> +			reg &= ~(OMAP4_P1_MODE_MASK << 2*i);
> 
> add spaces around '*' operator.
> 
>> +			if (is_ehci_tll_mode(pdata->port_mode[i]) ||
>> +				(is_ohci_port(pdata->port_mode[i])))
>> +				reg |= OMAP4_P1_MODE_TLL << 2*i;
> 
> ditto
> 
>> +			else if (is_ehci_hsic_mode(pdata->port_mode[i]))
>> +				reg |= OMAP4_P1_MODE_HSIC << 2*i;
> 
> ditto
> 
> in fact, I would convert this construct into a switch which would look
> like:
> 
> reg &= ~(OMAP4_P1_MODE_MASK << i * 2);
> 
> switch (port_mode[i]) {
> case OMAP4_P1_MODE_TLL:
> 	reg |= OMAP4_P1_MODE_TLL << i * 2;
> 	break;
> case OMAP_P1_MODE_HSIC:
> 	reg |= OMAP4_P1_MODE_HSIC << i * 2;
> 	break;
> }
> 

Just realized that is_ohci_port() takes care of 10 cases, so I'll leave
it the way it was with if statement.

> Also, it looks like the whoel for loop with port mode settings could be
> re-factored to a separate function to aid readability.
> 

it seems that the purpose of omap_usbhs_init() is to initialize
HOSTCONFIG so I see no point in adding another function for it. I can
clean it up for better readability though.

--
cheers,
-roger

Re: [PATCH 10/16] mfd: omap-usb-host: Intialize all available ports

[Felipe Balbi]

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

Hi,

On Tue, Nov 27, 2012 at 02:10:50PM +0200, Roger Quadros wrote:
> > in fact, I would convert this construct into a switch which would look
> > like:
> > 
> > reg &= ~(OMAP4_P1_MODE_MASK << i * 2);
> > 
> > switch (port_mode[i]) {
> > case OMAP4_P1_MODE_TLL:
> > 	reg |= OMAP4_P1_MODE_TLL << i * 2;
> > 	break;
> > case OMAP_P1_MODE_HSIC:
> > 	reg |= OMAP4_P1_MODE_HSIC << i * 2;
> > 	break;
> > }
> > 
> 
> Just realized that is_ohci_port() takes care of 10 cases, so I'll leave
> it the way it was with if statement.

fair enough.

> > Also, it looks like the whoel for loop with port mode settings could be
> > re-factored to a separate function to aid readability.
> > 
> 
> it seems that the purpose of omap_usbhs_init() is to initialize
> HOSTCONFIG so I see no point in adding another function for it. I can
> clean it up for better readability though.

when functions get too big, it starts to become a little difficult to
see bugs. Re-factoring parts of a bigger function, into smaller
functions helps with that as long as the new functions are
self-contained and logical. At the end of the day, GCC will inline the
new smaller functions anyway.

cheers

-- 
balbi

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

Re: [PATCH 10/16] mfd: omap-usb-host: Intialize all available ports

[Roger Quadros]

On 11/27/2012 03:28 PM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Nov 27, 2012 at 02:10:50PM +0200, Roger Quadros wrote:
>>> in fact, I would convert this construct into a switch which would look
>>> like:
>>>
>>> reg &= ~(OMAP4_P1_MODE_MASK << i * 2);
>>>
>>> switch (port_mode[i]) {
>>> case OMAP4_P1_MODE_TLL:
>>> 	reg |= OMAP4_P1_MODE_TLL << i * 2;
>>> 	break;
>>> case OMAP_P1_MODE_HSIC:
>>> 	reg |= OMAP4_P1_MODE_HSIC << i * 2;
>>> 	break;
>>> }
>>>
>>
>> Just realized that is_ohci_port() takes care of 10 cases, so I'll leave
>> it the way it was with if statement.
> 
> fair enough.
> 
>>> Also, it looks like the whoel for loop with port mode settings could be
>>> re-factored to a separate function to aid readability.
>>>
>>
>> it seems that the purpose of omap_usbhs_init() is to initialize
>> HOSTCONFIG so I see no point in adding another function for it. I can
>> clean it up for better readability though.
> 
> when functions get too big, it starts to become a little difficult to
> see bugs. Re-factoring parts of a bigger function, into smaller
> functions helps with that as long as the new functions are
> self-contained and logical. At the end of the day, GCC will inline the
> new smaller functions anyway.
> 

OK. I'll split the initialization of different revisions into different
functions.

regards,
-roger
--
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 04/16] mfd: omap-usb-tll: Move port clock handling out of runtime ops

[Roger Quadros]

The port clocks are not required to access the port registers,
they are only needed when the PORT is used. So we move the port clock
handling code to omap_tll_enable/disable().

Also get of unnecessary spinlock code in probe function and check for
missing platform data.

Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
---
 drivers/mfd/omap-usb-tll.c |  102 +++++++++++++++++---------------------------
 1 files changed, 39 insertions(+), 63 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 7054395e..31ac7db 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -114,8 +114,8 @@ struct usbtll_omap {
 
 /*-------------------------------------------------------------------------*/
 
-const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
-struct platform_device	*tll_pdev;
+static const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
+static struct device *tll_dev;
 
 /*-------------------------------------------------------------------------*/
 
@@ -217,7 +217,6 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 	struct resource				*res;
 	struct usbtll_omap			*tll;
 	unsigned				reg;
-	unsigned long				flags;
 	int					ret = 0;
 	int					i, ver;
 	bool needs_tll;
@@ -230,6 +229,11 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
+	if (!pdata) {
+		dev_err(dev, "%s : Platform data mising\n", __func__);
+		return -ENODEV;
+	}
+
 	spin_lock_init(&tll->lock);
 
 	tll->pdata = pdata;
@@ -253,8 +257,6 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 	pm_runtime_enable(dev);
 	pm_runtime_get_sync(dev);
 
-	spin_lock_irqsave(&tll->lock, flags);
-
 	ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
 	switch (ver) {
 	case OMAP_USBTLL_REV1:
@@ -331,13 +333,13 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 		}
 	}
 
-	tll_pdev = pdev;
+	/* only after this can omap_tll_enable/disable work */
+	tll_dev = dev;
 
 err_clk:
 	for (--i; i >= 0 ; i--)
 		clk_put(tll->ch_clk[i]);
 
-	spin_unlock_irqrestore(&tll->lock, flags);
 	pm_runtime_put_sync(dev);
 	if (ret == 0) {
 		pr_info("OMAP USB TLL : revision 0x%x, channels %d\n",
@@ -364,6 +366,7 @@ static int __devexit usbtll_omap_remove(struct platform_device *pdev)
 	struct usbtll_omap *tll = platform_get_drvdata(pdev);
 	int i;
 
+	tll_dev = NULL;
 	iounmap(tll->base);
 	for (i = 0; i < tll->nch; i++)
 		clk_put(tll->ch_clk[i]);
@@ -373,98 +376,71 @@ static int __devexit usbtll_omap_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static int usbtll_runtime_resume(struct device *dev)
+static struct platform_driver usbtll_omap_driver = {
+	.driver = {
+		.name		= (char *)usbtll_driver_name,
+		.owner		= THIS_MODULE,
+	},
+	.probe		= usbtll_omap_probe,
+	.remove		= __devexit_p(usbtll_omap_remove),
+};
+
+int omap_tll_enable(void)
 {
-	struct usbtll_omap			*tll = dev_get_drvdata(dev);
-	struct usbtll_omap_platform_data	*pdata = tll->pdata;
+	struct usbtll_omap			*tll;
 	unsigned long				flags;
 	int i;
 
-	dev_dbg(dev, "usbtll_runtime_resume\n");
-
-	if (!pdata) {
-		dev_dbg(dev, "missing platform_data\n");
+	if (!tll_dev) {
+		pr_err("%s: OMAP USB TLL not initialized\n", __func__);
 		return  -ENODEV;
 	}
 
+	tll = dev_get_drvdata(tll_dev);
 	spin_lock_irqsave(&tll->lock, flags);
 
 	for (i = 0; i < tll->nch; i++) {
-		if (mode_needs_tll(pdata->port_mode[i])) {
+		if (mode_needs_tll(tll->pdata->port_mode[i])) {
 			int r;
 			r = clk_enable(tll->ch_clk[i]);
 			if (r) {
-				dev_err(dev,
-				 "%s : Error enabling ch %d clock: %d\n",
-				 __func__, i, r);
+				dev_err(tll_dev,
+				  "%s : Error enabling ch %d clock: %d\n",
+				  __func__, i, r);
 			}
 		}
 	}
 
+	i = pm_runtime_get_sync(tll_dev);
 	spin_unlock_irqrestore(&tll->lock, flags);
 
-	return 0;
+	return i;
 }
+EXPORT_SYMBOL_GPL(omap_tll_enable);
 
-static int usbtll_runtime_suspend(struct device *dev)
+int omap_tll_disable(void)
 {
-	struct usbtll_omap			*tll = dev_get_drvdata(dev);
-	struct usbtll_omap_platform_data	*pdata = tll->pdata;
+	struct usbtll_omap			*tll;
 	unsigned long				flags;
 	int i;
 
-	dev_dbg(dev, "usbtll_runtime_suspend\n");
-
-	if (!pdata) {
-		dev_dbg(dev, "missing platform_data\n");
+	if (!tll_dev) {
+		pr_err("%s: OMAP USB TLL not initialized\n", __func__);
 		return  -ENODEV;
 	}
 
+	tll = dev_get_drvdata(tll_dev);
 	spin_lock_irqsave(&tll->lock, flags);
 
 	for (i = 0; i < tll->nch; i++) {
-		if (mode_needs_tll(pdata->port_mode[i]))
+		if (mode_needs_tll(tll->pdata->port_mode[i]))
 			clk_disable(tll->ch_clk[i]);
 	}
 
+	i = pm_runtime_put_sync(tll_dev);
 	spin_unlock_irqrestore(&tll->lock, flags);
 
-	return 0;
-}
-
-static const struct dev_pm_ops usbtllomap_dev_pm_ops = {
-	SET_RUNTIME_PM_OPS(usbtll_runtime_suspend,
-			   usbtll_runtime_resume,
-			   NULL)
-};
-
-static struct platform_driver usbtll_omap_driver = {
-	.driver = {
-		.name		= (char *)usbtll_driver_name,
-		.owner		= THIS_MODULE,
-		.pm		= &usbtllomap_dev_pm_ops,
-	},
-	.probe		= usbtll_omap_probe,
-	.remove		= __devexit_p(usbtll_omap_remove),
-};
-
-int omap_tll_enable(void)
-{
-	if (!tll_pdev) {
-		pr_err("missing omap usbhs tll platform_data\n");
-		return  -ENODEV;
-	}
-	return pm_runtime_get_sync(&tll_pdev->dev);
-}
-EXPORT_SYMBOL_GPL(omap_tll_enable);

Re: [PATCH 04/16] mfd: omap-usb-tll: Move port clock handling out of runtime ops

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:02PM +0200, Roger Quadros wrote:
> The port clocks are not required to access the port registers,
> they are only needed when the PORT is used. So we move the port clock
> handling code to omap_tll_enable/disable().
> 
> Also get of unnecessary spinlock code in probe function and check for
> missing platform data.

this second sentence needs some rephrasing, I don't fully understand
what you mean.

This patch also does more than what $SUBJECT says, should be splitted
up.

> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> ---
>  drivers/mfd/omap-usb-tll.c |  102 +++++++++++++++++---------------------------
>  1 files changed, 39 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> index 7054395e..31ac7db 100644
> --- a/drivers/mfd/omap-usb-tll.c
> +++ b/drivers/mfd/omap-usb-tll.c
> @@ -114,8 +114,8 @@ struct usbtll_omap {
>  
>  /*-------------------------------------------------------------------------*/
>  
> -const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
> -struct platform_device	*tll_pdev;
> +static const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
> +static struct device *tll_dev;
>  
>  /*-------------------------------------------------------------------------*/
>  
> @@ -217,7 +217,6 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  	struct resource				*res;
>  	struct usbtll_omap			*tll;
>  	unsigned				reg;
> -	unsigned long				flags;
>  	int					ret = 0;
>  	int					i, ver;
>  	bool needs_tll;
> @@ -230,6 +229,11 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  	}
>  
> +	if (!pdata) {
> +		dev_err(dev, "%s : Platform data mising\n", __func__);
> +		return -ENODEV;
> +	}
> +
>  	spin_lock_init(&tll->lock);
>  
>  	tll->pdata = pdata;
> @@ -253,8 +257,6 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  	pm_runtime_enable(dev);
>  	pm_runtime_get_sync(dev);
>  
> -	spin_lock_irqsave(&tll->lock, flags);
> -
>  	ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
>  	switch (ver) {
>  	case OMAP_USBTLL_REV1:
> @@ -331,13 +333,13 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> -	tll_pdev = pdev;
> +	/* only after this can omap_tll_enable/disable work */
> +	tll_dev = dev;

I'd like to get rid of that, actually. But for now we can keep it...

>  err_clk:
>  	for (--i; i >= 0 ; i--)
>  		clk_put(tll->ch_clk[i]);
>  
> -	spin_unlock_irqrestore(&tll->lock, flags);
>  	pm_runtime_put_sync(dev);
>  	if (ret == 0) {
>  		pr_info("OMAP USB TLL : revision 0x%x, channels %d\n",
> @@ -364,6 +366,7 @@ static int __devexit usbtll_omap_remove(struct platform_device *pdev)
>  	struct usbtll_omap *tll = platform_get_drvdata(pdev);
>  	int i;
>  
> +	tll_dev = NULL;
>  	iounmap(tll->base);
>  	for (i = 0; i < tll->nch; i++)
>  		clk_put(tll->ch_clk[i]);
> @@ -373,98 +376,71 @@ static int __devexit usbtll_omap_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> -static int usbtll_runtime_resume(struct device *dev)
> +static struct platform_driver usbtll_omap_driver = {
> +	.driver = {
> +		.name		= (char *)usbtll_driver_name,
> +		.owner		= THIS_MODULE,
> +	},
> +	.probe		= usbtll_omap_probe,
> +	.remove		= __devexit_p(usbtll_omap_remove),

there is a big patchset floating around dropping CONFIG_HOTPLUG, that
means that __devinit, __devexit, __devexit_p(), __devinitdata,
__devinitconst will all vanish. Please don't re-add them ;-)

> +};
> +
> +int omap_tll_enable(void)
>  {
> -	struct usbtll_omap			*tll = dev_get_drvdata(dev);
> -	struct usbtll_omap_platform_data	*pdata = tll->pdata;
> +	struct usbtll_omap			*tll;
>  	unsigned long				flags;
>  	int i;
>  
> -	dev_dbg(dev, "usbtll_runtime_resume\n");
> -
> -	if (!pdata) {
> -		dev_dbg(dev, "missing platform_data\n");
> +	if (!tll_dev) {
> +		pr_err("%s: OMAP USB TLL not initialized\n", __func__);
>  		return  -ENODEV;
>  	}
>  
> +	tll = dev_get_drvdata(tll_dev);
>  	spin_lock_irqsave(&tll->lock, flags);
>  
>  	for (i = 0; i < tll->nch; i++) {
> -		if (mode_needs_tll(pdata->port_mode[i])) {
> +		if (mode_needs_tll(tll->pdata->port_mode[i])) {
>  			int r;
>  			r = clk_enable(tll->ch_clk[i]);
>  			if (r) {
> -				dev_err(dev,
> -				 "%s : Error enabling ch %d clock: %d\n",
> -				 __func__, i, r);
> +				dev_err(tll_dev,
> +				  "%s : Error enabling ch %d clock: %d\n",
> +				  __func__, i, r);

no need for __func__

>  			}
>  		}
>  	}
>  
> +	i = pm_runtime_get_sync(tll_dev);

fair enough, you're trying to re-use the variable. But I would be more
explicit and create another ret variable. I'm sure GCC will optimize
variable usage here anyway.

>  	spin_unlock_irqrestore(&tll->lock, flags);
>  
> -	return 0;
> +	return i;
>  }
> +EXPORT_SYMBOL_GPL(omap_tll_enable);
>  
> -static int usbtll_runtime_suspend(struct device *dev)
> +int omap_tll_disable(void)

why ?? Why are you actually dropping runtime PM from this driver ? have
you tested PM transitions after applying this patch ?

-- 
balbi

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

Re: [PATCH 04/16] mfd: omap-usb-tll: Move port clock handling out of runtime ops

[Roger Quadros]

On 11/21/2012 02:06 PM, Felipe Balbi wrote:
> On Thu, Nov 15, 2012 at 04:34:02PM +0200, Roger Quadros wrote:
>> The port clocks are not required to access the port registers,
>> they are only needed when the PORT is used. So we move the port clock
>> handling code to omap_tll_enable/disable().
>>
>> Also get of unnecessary spinlock code in probe function and check for
>> missing platform data.
> 
> this second sentence needs some rephrasing, I don't fully understand
> what you mean.

Oops. should have been "get _rid_ of".
> 
> This patch also does more than what $SUBJECT says, should be splitted
> up.

OK.

> 
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>>  drivers/mfd/omap-usb-tll.c |  102 +++++++++++++++++---------------------------
>>  1 files changed, 39 insertions(+), 63 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
>> index 7054395e..31ac7db 100644
>> --- a/drivers/mfd/omap-usb-tll.c
>> +++ b/drivers/mfd/omap-usb-tll.c
>> @@ -114,8 +114,8 @@ struct usbtll_omap {
>>  
>>  /*-------------------------------------------------------------------------*/
>>  
>> -const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
>> -struct platform_device	*tll_pdev;
>> +static const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
>> +static struct device *tll_dev;
>>  
>>  /*-------------------------------------------------------------------------*/
>>  
>> @@ -217,7 +217,6 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>>  	struct resource				*res;
>>  	struct usbtll_omap			*tll;
>>  	unsigned				reg;
>> -	unsigned long				flags;
>>  	int					ret = 0;
>>  	int					i, ver;
>>  	bool needs_tll;
>> @@ -230,6 +229,11 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>>  		return -ENOMEM;
>>  	}
>>  
>> +	if (!pdata) {
>> +		dev_err(dev, "%s : Platform data mising\n", __func__);
>> +		return -ENODEV;
>> +	}
>> +
>>  	spin_lock_init(&tll->lock);
>>  
>>  	tll->pdata = pdata;
>> @@ -253,8 +257,6 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>>  	pm_runtime_enable(dev);
>>  	pm_runtime_get_sync(dev);
>>  
>> -	spin_lock_irqsave(&tll->lock, flags);
>> -
>>  	ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
>>  	switch (ver) {
>>  	case OMAP_USBTLL_REV1:
>> @@ -331,13 +333,13 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
>>  		}
>>  	}
>>  
>> -	tll_pdev = pdev;
>> +	/* only after this can omap_tll_enable/disable work */
>> +	tll_dev = dev;
> 
> I'd like to get rid of that, actually. But for now we can keep it...
> 
>>  err_clk:
>>  	for (--i; i >= 0 ; i--)
>>  		clk_put(tll->ch_clk[i]);
>>  
>> -	spin_unlock_irqrestore(&tll->lock, flags);
>>  	pm_runtime_put_sync(dev);
>>  	if (ret == 0) {
>>  		pr_info("OMAP USB TLL : revision 0x%x, channels %d\n",
>> @@ -364,6 +366,7 @@ static int __devexit usbtll_omap_remove(struct platform_device *pdev)
>>  	struct usbtll_omap *tll = platform_get_drvdata(pdev);
>>  	int i;
>>  
>> +	tll_dev = NULL;
>>  	iounmap(tll->base);
>>  	for (i = 0; i < tll->nch; i++)
>>  		clk_put(tll->ch_clk[i]);
>> @@ -373,98 +376,71 @@ static int __devexit usbtll_omap_remove(struct platform_device *pdev)
>>  	return 0;
>>  }
>>  
>> -static int usbtll_runtime_resume(struct device *dev)
>> +static struct platform_driver usbtll_omap_driver = {
>> +	.driver = {
>> +		.name		= (char *)usbtll_driver_name,
>> +		.owner		= THIS_MODULE,
>> +	},
>> +	.probe		= usbtll_omap_probe,
>> +	.remove		= __devexit_p(usbtll_omap_remove),
> 
> there is a big patchset floating around dropping CONFIG_HOTPLUG, that
> means that __devinit, __devexit, __devexit_p(), __devinitdata,
> __devinitconst will all vanish. Please don't re-add them ;-)
> 

OK. good to know.

>> +};
>> +
>> +int omap_tll_enable(void)
>>  {
>> -	struct usbtll_omap			*tll = dev_get_drvdata(dev);
>> -	struct usbtll_omap_platform_data	*pdata = tll->pdata;
>> +	struct usbtll_omap			*tll;
>>  	unsigned long				flags;
>>  	int i;
>>  
>> -	dev_dbg(dev, "usbtll_runtime_resume\n");
>> -
>> -	if (!pdata) {
>> -		dev_dbg(dev, "missing platform_data\n");
>> +	if (!tll_dev) {
>> +		pr_err("%s: OMAP USB TLL not initialized\n", __func__);
>>  		return  -ENODEV;
>>  	}
>>  
>> +	tll = dev_get_drvdata(tll_dev);
>>  	spin_lock_irqsave(&tll->lock, flags);
>>  
>>  	for (i = 0; i < tll->nch; i++) {
>> -		if (mode_needs_tll(pdata->port_mode[i])) {
>> +		if (mode_needs_tll(tll->pdata->port_mode[i])) {
>>  			int r;
>>  			r = clk_enable(tll->ch_clk[i]);
>>  			if (r) {
>> -				dev_err(dev,
>> -				 "%s : Error enabling ch %d clock: %d\n",
>> -				 __func__, i, r);
>> +				dev_err(tll_dev,
>> +				  "%s : Error enabling ch %d clock: %d\n",
>> +				  __func__, i, r);
> 
> no need for __func__
> 
>>  			}
>>  		}
>>  	}
>>  
>> +	i = pm_runtime_get_sync(tll_dev);
> 
> fair enough, you're trying to re-use the variable. But I would be more
> explicit and create another ret variable. I'm sure GCC will optimize
> variable usage here anyway.
> 

fine.

>>  	spin_unlock_irqrestore(&tll->lock, flags);
>>  
>> -	return 0;
>> +	return i;
>>  }
>> +EXPORT_SYMBOL_GPL(omap_tll_enable);
>>  
>> -static int usbtll_runtime_suspend(struct device *dev)
>> +int omap_tll_disable(void)
> 
> why ?? Why are you actually dropping runtime PM from this driver ? have
> you tested PM transitions after applying this patch ?
> 

I'm not dropping runtime PM as such. Just separating enabling of channel
clocks from runtime PM (read enabling hwmod). The only user for this
driver is omap-usb-host.c via the omap_tll_enable/disable() calls.

These calls still call pm_runtime_get/put() to enable the TLL hwmod.

I have tested PM transitions on bus suspend/resume and modprobe/rmmod.
They still work fine.

cheers,
-roger

Re: [PATCH 04/16] mfd: omap-usb-tll: Move port clock handling out of runtime ops

[Felipe Balbi]

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

Hi,

On Wed, Nov 21, 2012 at 02:45:46PM +0200, Roger Quadros wrote:
> >>  	spin_unlock_irqrestore(&tll->lock, flags);
> >>  
> >> -	return 0;
> >> +	return i;
> >>  }
> >> +EXPORT_SYMBOL_GPL(omap_tll_enable);
> >>  
> >> -static int usbtll_runtime_suspend(struct device *dev)
> >> +int omap_tll_disable(void)
> > 
> > why ?? Why are you actually dropping runtime PM from this driver ? have
> > you tested PM transitions after applying this patch ?
> > 
> 
> I'm not dropping runtime PM as such. Just separating enabling of channel
> clocks from runtime PM (read enabling hwmod). The only user for this
> driver is omap-usb-host.c via the omap_tll_enable/disable() calls.
> 
> These calls still call pm_runtime_get/put() to enable the TLL hwmod.
> 
> I have tested PM transitions on bus suspend/resume and modprobe/rmmod.
> They still work fine.

weird, I didn't see any dev_pm_ops being re-added to your
platform_driver structure :-s

On your original patch I see this:

-static const struct dev_pm_ops usbtllomap_dev_pm_ops = {
-	SET_RUNTIME_PM_OPS(usbtll_runtime_suspend,
-			   usbtll_runtime_resume,
-			   NULL)
-};
-
-static struct platform_driver usbtll_omap_driver = {
-	.driver = {
-		.name		= (char *)usbtll_driver_name,
-		.owner		= THIS_MODULE,
-		.pm		= &usbtllomap_dev_pm_ops,
-	},
-	.probe		= usbtll_omap_probe,
-	.remove		= __devexit_p(usbtll_omap_remove),
-};

but there is never anythying re-adding that dev_pm_ops, so runtime pm
callbacks are literally dropped from this driver. If that's still fine,
please make it clear on commit log.

-- 
balbi

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

[PATCH 05/16] mfd: omap-usb-tll: Add OMAP5 revision and HSIC support

[Roger Quadros]

The TLL module on OMAP5 has 3 channels.
HSIC mode requires the TLL channel to be in Transparent UTMI mode.

Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
---
 drivers/mfd/omap-usb-tll.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 31ac7db..c48d545 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -54,10 +54,13 @@
 
 #define	OMAP_TLL_CHANNEL_CONF(num)			(0x040 + 0x004 * num)
 #define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT		24
+#define OMAP_TLL_CHANNEL_CONF_DRVVBUS			(1 << 16)
+#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS			(1 << 15)
 #define	OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF		(1 << 11)
 #define	OMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE		(1 << 10)
 #define	OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE		(1 << 9)
 #define	OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE		(1 << 8)
+#define OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI	(2 << 1)
 #define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS		(1 << 1)
 #define	OMAP_TLL_CHANNEL_CONF_CHANEN			(1 << 0)
 
@@ -96,6 +99,7 @@
 #define OMAP_USBTLL_REV1		0x00000015	/* OMAP3 */
 #define OMAP_USBTLL_REV2		0x00000018	/* OMAP 3630 */
 #define OMAP_USBTLL_REV3		0x00000004	/* OMAP4 */
+#define OMAP_USBTLL_REV4		0x6		/* OMAP5 */
 
 #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
 
@@ -260,6 +264,7 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 	ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
 	switch (ver) {
 	case OMAP_USBTLL_REV1:
+	case OMAP_USBTLL_REV4:
 		tll->nch = DEFAULT_TLL_CHANNEL_COUNT;
 		break;
 	case OMAP_USBTLL_REV2:
@@ -321,6 +326,15 @@ static int __devinit usbtll_omap_probe(struct platform_device *pdev)
 				reg &= ~(OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE
 					| OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF
 					| OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE);
+			} else if (pdata->port_mode[i] ==
+					OMAP_EHCI_PORT_MODE_HSIC) {
+				/*
+				 * HSIC Mode requires UTMI port configurations
+				 */
+				reg |= OMAP_TLL_CHANNEL_CONF_DRVVBUS
+				 | OMAP_TLL_CHANNEL_CONF_CHRGVBUS
+				 | OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI
+				 | OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF;
 			} else {
 				continue;
 			}
-- 
1.7.4.1

--
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 05/16] mfd: omap-usb-tll: Add OMAP5 revision and HSIC support

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:03PM +0200, Roger Quadros wrote:
> The TLL module on OMAP5 has 3 channels.
> HSIC mode requires the TLL channel to be in Transparent UTMI mode.
> 
> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> ---
>  drivers/mfd/omap-usb-tll.c |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> index 31ac7db..c48d545 100644
> --- a/drivers/mfd/omap-usb-tll.c
> +++ b/drivers/mfd/omap-usb-tll.c
> @@ -54,10 +54,13 @@
>  
>  #define	OMAP_TLL_CHANNEL_CONF(num)			(0x040 + 0x004 * num)
>  #define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT		24
> +#define OMAP_TLL_CHANNEL_CONF_DRVVBUS			(1 << 16)
> +#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS			(1 << 15)
>  #define	OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF		(1 << 11)
>  #define	OMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE		(1 << 10)
>  #define	OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE		(1 << 9)
>  #define	OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE		(1 << 8)
> +#define OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI	(2 << 1)
>  #define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS		(1 << 1)
>  #define	OMAP_TLL_CHANNEL_CONF_CHANEN			(1 << 0)
>  
> @@ -96,6 +99,7 @@
>  #define OMAP_USBTLL_REV1		0x00000015	/* OMAP3 */
>  #define OMAP_USBTLL_REV2		0x00000018	/* OMAP 3630 */
>  #define OMAP_USBTLL_REV3		0x00000004	/* OMAP4 */
> +#define OMAP_USBTLL_REV4		0x6		/* OMAP5 */

looks wrong to me. Are you sure this is what that 32-bit register reads
out ? Bits[31:30] should read as 0b01 as per internal documentation.

-- 
balbi

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

Re: [PATCH 05/16] mfd: omap-usb-tll: Add OMAP5 revision and HSIC support

[Roger Quadros]

On 11/21/2012 02:12 PM, Felipe Balbi wrote:
> On Thu, Nov 15, 2012 at 04:34:03PM +0200, Roger Quadros wrote:
>> The TLL module on OMAP5 has 3 channels.
>> HSIC mode requires the TLL channel to be in Transparent UTMI mode.
>>
>> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>> ---
>>  drivers/mfd/omap-usb-tll.c |   14 ++++++++++++++
>>  1 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
>> index 31ac7db..c48d545 100644
>> --- a/drivers/mfd/omap-usb-tll.c
>> +++ b/drivers/mfd/omap-usb-tll.c
>> @@ -54,10 +54,13 @@
>>  
>>  #define	OMAP_TLL_CHANNEL_CONF(num)			(0x040 + 0x004 * num)
>>  #define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT		24
>> +#define OMAP_TLL_CHANNEL_CONF_DRVVBUS			(1 << 16)
>> +#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS			(1 << 15)
>>  #define	OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF		(1 << 11)
>>  #define	OMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE		(1 << 10)
>>  #define	OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE		(1 << 9)
>>  #define	OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE		(1 << 8)
>> +#define OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI	(2 << 1)
>>  #define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS		(1 << 1)
>>  #define	OMAP_TLL_CHANNEL_CONF_CHANEN			(1 << 0)
>>  
>> @@ -96,6 +99,7 @@
>>  #define OMAP_USBTLL_REV1		0x00000015	/* OMAP3 */
>>  #define OMAP_USBTLL_REV2		0x00000018	/* OMAP 3630 */
>>  #define OMAP_USBTLL_REV3		0x00000004	/* OMAP4 */
>> +#define OMAP_USBTLL_REV4		0x6		/* OMAP5 */
> 
> looks wrong to me. Are you sure this is what that 32-bit register reads
> out ? Bits[31:30] should read as 0b01 as per internal documentation.
> 

Yes I'm pretty sure about that. I'm on 5432 though. Not sure if 5430
shows different.

cheers,
-roger
--
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 05/16] mfd: omap-usb-tll: Add OMAP5 revision and HSIC support

[Felipe Balbi]

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

Hi,

On Wed, Nov 21, 2012 at 02:49:41PM +0200, Roger Quadros wrote:
> On 11/21/2012 02:12 PM, Felipe Balbi wrote:
> > On Thu, Nov 15, 2012 at 04:34:03PM +0200, Roger Quadros wrote:
> >> The TLL module on OMAP5 has 3 channels.
> >> HSIC mode requires the TLL channel to be in Transparent UTMI mode.
> >>
> >> Signed-off-by: Roger Quadros <rogerq@ti.com>
> >> ---
> >>  drivers/mfd/omap-usb-tll.c |   14 ++++++++++++++
> >>  1 files changed, 14 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> >> index 31ac7db..c48d545 100644
> >> --- a/drivers/mfd/omap-usb-tll.c
> >> +++ b/drivers/mfd/omap-usb-tll.c
> >> @@ -54,10 +54,13 @@
> >>  
> >>  #define	OMAP_TLL_CHANNEL_CONF(num)			(0x040 + 0x004 * num)
> >>  #define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT		24
> >> +#define OMAP_TLL_CHANNEL_CONF_DRVVBUS			(1 << 16)
> >> +#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS			(1 << 15)
> >>  #define	OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF		(1 << 11)
> >>  #define	OMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE		(1 << 10)
> >>  #define	OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE		(1 << 9)
> >>  #define	OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE		(1 << 8)
> >> +#define OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI	(2 << 1)
> >>  #define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS		(1 << 1)
> >>  #define	OMAP_TLL_CHANNEL_CONF_CHANEN			(1 << 0)
> >>  
> >> @@ -96,6 +99,7 @@
> >>  #define OMAP_USBTLL_REV1		0x00000015	/* OMAP3 */
> >>  #define OMAP_USBTLL_REV2		0x00000018	/* OMAP 3630 */
> >>  #define OMAP_USBTLL_REV3		0x00000004	/* OMAP4 */
> >> +#define OMAP_USBTLL_REV4		0x6		/* OMAP5 */
> > 
> > looks wrong to me. Are you sure this is what that 32-bit register reads
> > out ? Bits[31:30] should read as 0b01 as per internal documentation.
> > 
> 
> Yes I'm pretty sure about that. I'm on 5432 though. Not sure if 5430
> shows different.

this is really peculiar about these IPs... Anyway, if you made sure,
fair enough. Just make the 0x6 more explicitly 32-bits like the other
macros (0x00000006)

-- 
balbi

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

[PATCH 06/16] mfd: omap-usb-host: cleanup clock management code

[Roger Quadros]

All ports have similarly named port clocks so we can
bunch them into a port data structure and use for loop
to enable/disable the clocks.

Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
---
 drivers/mfd/omap-usb-host.c |  208 +++++++++++++++++++++----------------------
 1 files changed, 101 insertions(+), 107 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 23cec57..7303c41 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -76,6 +76,8 @@
 
 #define	OMAP_UHH_DEBUG_CSR				(0x44)
 
+#define MAX_HS_USB_PORTS	3	/* Increase this if any chip has more */
+
 /* Values of UHH_REVISION - Note: these are not given in the TRM */
 #define OMAP_USBHS_REV1		0x00000010	/* OMAP3 */
 #define OMAP_USBHS_REV2		0x50700100	/* OMAP4 */
@@ -87,14 +89,15 @@
 #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
 #define is_ehci_hsic_mode(x)	(x == OMAP_EHCI_PORT_MODE_HSIC)
 
+struct usbhs_port {
+	struct clk	*utmi_clk;
+};
 
 struct usbhs_hcd_omap {
+	struct usbhs_port		port[MAX_HS_USB_PORTS];
+
 	struct clk			*xclk60mhsp1_ck;
 	struct clk			*xclk60mhsp2_ck;
-	struct clk			*utmi_p1_fck;
-	struct clk			*usbhost_p1_fck;
-	struct clk			*utmi_p2_fck;
-	struct clk			*usbhost_p2_fck;
 	struct clk			*init_60m_fclk;
 	struct clk			*ehci_logic_fck;
 
@@ -278,6 +281,7 @@ static int usbhs_runtime_resume(struct device *dev)
 	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
 	struct usbhs_omap_platform_data	*pdata = &omap->platdata;
 	unsigned long			flags;
+	int i, r;
 
 	dev_dbg(dev, "usbhs_runtime_resume\n");
 
@@ -292,13 +296,18 @@ static int usbhs_runtime_resume(struct device *dev)
 	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
 		clk_enable(omap->ehci_logic_fck);
 
-	if (is_ehci_tll_mode(pdata->port_mode[0]))
-		clk_enable(omap->usbhost_p1_fck);
-	if (is_ehci_tll_mode(pdata->port_mode[1]))
-		clk_enable(omap->usbhost_p2_fck);
-
-	clk_enable(omap->utmi_p1_fck);
-	clk_enable(omap->utmi_p2_fck);
+	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
+		if (is_ehci_tll_mode(pdata->port_mode[i])) {
+			if (omap->port[i].utmi_clk) {
+				r = clk_enable(omap->port[i].utmi_clk);
+				if (r) {
+					dev_err(dev,
+					 "%s: Can't enable port %d clk : %d\n",
+					 __func__, i, r);
+				}
+			}
+		}
+	}
 
 	spin_unlock_irqrestore(&omap->lock, flags);
 
@@ -310,6 +319,7 @@ static int usbhs_runtime_suspend(struct device *dev)
 	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
 	struct usbhs_omap_platform_data	*pdata = &omap->platdata;
 	unsigned long			flags;
+	int i;
 
 	dev_dbg(dev, "usbhs_runtime_suspend\n");
 
@@ -320,13 +330,12 @@ static int usbhs_runtime_suspend(struct device *dev)
 
 	spin_lock_irqsave(&omap->lock, flags);
 
-	if (is_ehci_tll_mode(pdata->port_mode[0]))
-		clk_disable(omap->usbhost_p1_fck);
-	if (is_ehci_tll_mode(pdata->port_mode[1]))
-		clk_disable(omap->usbhost_p2_fck);
-
-	clk_disable(omap->utmi_p2_fck);
-	clk_disable(omap->utmi_p1_fck);
+	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
+		if (is_ehci_tll_mode(pdata->port_mode[i])) {
+			if (omap->port[i].utmi_clk)
+				clk_disable(omap->port[i].utmi_clk);
+		}
+	}
 
 	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
 		clk_disable(omap->ehci_logic_fck);
@@ -472,101 +481,105 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 	struct resource			*res;
 	int				ret = 0;
 	int				i;
+	bool				need_logic_fck;
 
 	if (!pdata) {
 		dev_err(dev, "Missing platform data\n");
-		ret = -ENOMEM;
-		goto end_probe;
+		return -ENODEV;
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "uhh");
+	if (!res) {
+		dev_err(dev, "UHH EHCI get resource failed\n");
+		return -ENODEV;
 	}
 
 	omap = kzalloc(sizeof(*omap), GFP_KERNEL);
 	if (!omap) {
 		dev_err(dev, "Memory allocation failed\n");
+		return -ENOMEM;
+	}
+
+	omap->uhh_base = ioremap(res->start, resource_size(res));
+	if (!omap->uhh_base) {
+		dev_err(dev, "UHH ioremap failed\n");
 		ret = -ENOMEM;
-		goto end_probe;
+		goto err_remap;
 	}
 
 	spin_lock_init(&omap->lock);
 
-	for (i = 0; i < OMAP3_HS_USB_PORTS; i++)
+	need_logic_fck = false;
+	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
 		omap->platdata.port_mode[i] = pdata->port_mode[i];
 
+		if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
+			is_ehci_hsic_mode(i))
+				need_logic_fck |= true;
+	}
+
 	omap->platdata.ehci_data = pdata->ehci_data;
 	omap->platdata.ohci_data = pdata->ohci_data;
 
-	pm_runtime_enable(dev);
-
 
-	for (i = 0; i < OMAP3_HS_USB_PORTS; i++)
-		if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
-			is_ehci_hsic_mode(i)) {
-			omap->ehci_logic_fck = clk_get(dev, "ehci_logic_fck");
-			if (IS_ERR(omap->ehci_logic_fck)) {
-				ret = PTR_ERR(omap->ehci_logic_fck);
-				dev_warn(dev, "ehci_logic_fck failed:%d\n",
-					 ret);
-			}
-			break;
+	if (need_logic_fck) {
+		omap->ehci_logic_fck = clk_get(dev, "ehci_logic_fck");
+		if (IS_ERR(omap->ehci_logic_fck)) {
+			ret = PTR_ERR(omap->ehci_logic_fck);
+			dev_warn(dev, "ehci_logic_fck failed:%d\n", ret);
 		}
-
-	omap->utmi_p1_fck = clk_get(dev, "utmi_p1_gfclk");
-	if (IS_ERR(omap->utmi_p1_fck)) {
-		ret = PTR_ERR(omap->utmi_p1_fck);
-		dev_err(dev, "utmi_p1_gfclk failed error:%d\n",	ret);
-		goto err_end;
 	}
 
 	omap->xclk60mhsp1_ck = clk_get(dev, "xclk60mhsp1_ck");
 	if (IS_ERR(omap->xclk60mhsp1_ck)) {
 		ret = PTR_ERR(omap->xclk60mhsp1_ck);
 		dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
-		goto err_utmi_p1_fck;
-	}
-
-	omap->utmi_p2_fck = clk_get(dev, "utmi_p2_gfclk");
-	if (IS_ERR(omap->utmi_p2_fck)) {
-		ret = PTR_ERR(omap->utmi_p2_fck);
-		dev_err(dev, "utmi_p2_gfclk failed error:%d\n", ret);
-		goto err_xclk60mhsp1_ck;
+		goto err_xclk60mhsp1;
 	}
 
 	omap->xclk60mhsp2_ck = clk_get(dev, "xclk60mhsp2_ck");
 	if (IS_ERR(omap->xclk60mhsp2_ck)) {
 		ret = PTR_ERR(omap->xclk60mhsp2_ck);
 		dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
-		goto err_utmi_p2_fck;
-	}
-
-	omap->usbhost_p1_fck = clk_get(dev, "usb_host_hs_utmi_p1_clk");
-	if (IS_ERR(omap->usbhost_p1_fck)) {
-		ret = PTR_ERR(omap->usbhost_p1_fck);
-		dev_err(dev, "usbhost_p1_fck failed error:%d\n", ret);
-		goto err_xclk60mhsp2_ck;
-	}
-
-	omap->usbhost_p2_fck = clk_get(dev, "usb_host_hs_utmi_p2_clk");
-	if (IS_ERR(omap->usbhost_p2_fck)) {
-		ret = PTR_ERR(omap->usbhost_p2_fck);
-		dev_err(dev, "usbhost_p2_fck failed error:%d\n", ret);
-		goto err_usbhost_p1_fck;
+		goto err_xclk60mhsp2;
 	}
 
 	omap->init_60m_fclk = clk_get(dev, "init_60m_fclk");
 	if (IS_ERR(omap->init_60m_fclk)) {
 		ret = PTR_ERR(omap->init_60m_fclk);
 		dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
-		goto err_usbhost_p2_fck;
+		goto err_init60m;
+	}
+
+	for (i = 0; i < MAX_HS_USB_PORTS; i++) {
+		struct clk *pclk;
+		char utmi_clk[] = "usb_host_hs_utmi_px_clk";
+
+		/* clock names are indexed from 1*/
+		sprintf(utmi_clk, "usb_host_hs_utmi_p%d_clk", i + 1);
+
+		/* If a clock is not found we won't bail out as not all
+		 * platforms have all clocks and we can function without
+		 * them
+		 */
+		pclk = clk_get(dev, utmi_clk);
+		if (IS_ERR(pclk))
+			dev_err(dev, "Failed to get clock : %s : %ld\n",
+				utmi_clk, PTR_ERR(pclk));
+		else
+			omap->port[i].utmi_clk = pclk;
+
 	}
 
 	if (is_ehci_phy_mode(pdata->port_mode[0])) {
 		/* for OMAP3 , the clk set paretn fails */
-		ret = clk_set_parent(omap->utmi_p1_fck,
+		ret = clk_set_parent(omap->port[0].utmi_clk,
 					omap->xclk60mhsp1_ck);
 		if (ret != 0)
 			dev_err(dev, "xclk60mhsp1_ck set parent"
 				"failed error:%d\n", ret);
 	} else if (is_ehci_tll_mode(pdata->port_mode[0])) {
-		ret = clk_set_parent(omap->utmi_p1_fck,
+		ret = clk_set_parent(omap->port[0].utmi_clk,
 					omap->init_60m_fclk);
 		if (ret != 0)
 			dev_err(dev, "init_60m_fclk set parent"
@@ -574,35 +587,23 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 	}
 
 	if (is_ehci_phy_mode(pdata->port_mode[1])) {
-		ret = clk_set_parent(omap->utmi_p2_fck,
+		ret = clk_set_parent(omap->port[1].utmi_clk,
 					omap->xclk60mhsp2_ck);
 		if (ret != 0)
 			dev_err(dev, "xclk60mhsp2_ck set parent"
 					"failed error:%d\n", ret);
 	} else if (is_ehci_tll_mode(pdata->port_mode[1])) {
-		ret = clk_set_parent(omap->utmi_p2_fck,
+		ret = clk_set_parent(omap->port[1].utmi_clk,
 						omap->init_60m_fclk);
 		if (ret != 0)
 			dev_err(dev, "init_60m_fclk set parent"
 				"failed error:%d\n", ret);
 	}
 
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "uhh");
-	if (!res) {
-		dev_err(dev, "UHH EHCI get resource failed\n");
-		ret = -ENODEV;
-		goto err_init_60m_fclk;
-	}
-
-	omap->uhh_base = ioremap(res->start, resource_size(res));
-	if (!omap->uhh_base) {
-		dev_err(dev, "UHH ioremap failed\n");
-		ret = -ENOMEM;
-		goto err_init_60m_fclk;
-	}
-
 	platform_set_drvdata(pdev, omap);
 
+	pm_runtime_enable(dev);
+
 	omap_usbhs_init(dev);
 	ret = omap_usbhs_alloc_children(pdev);
 	if (ret) {
@@ -610,39 +611,30 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 		goto err_alloc;
 	}
 
-	goto end_probe;
+	return 0;
 
 err_alloc:
 	omap_usbhs_deinit(&pdev->dev);
-	iounmap(omap->uhh_base);
 
-err_init_60m_fclk:
-	clk_put(omap->init_60m_fclk);
+	pm_runtime_disable(dev);
+	iounmap(omap->uhh_base);
 
-err_usbhost_p2_fck:
-	clk_put(omap->usbhost_p2_fck);
+	for (i = 0; i < MAX_HS_USB_PORTS; i++)
+		clk_put(omap->port[i].utmi_clk);
 
-err_usbhost_p1_fck:
-	clk_put(omap->usbhost_p1_fck);
+	clk_put(omap->init_60m_fclk);
 
-err_xclk60mhsp2_ck:
+err_init60m:
 	clk_put(omap->xclk60mhsp2_ck);
 
-err_utmi_p2_fck:
-	clk_put(omap->utmi_p2_fck);
-
-err_xclk60mhsp1_ck:
+err_xclk60mhsp2:
 	clk_put(omap->xclk60mhsp1_ck);
 
-err_utmi_p1_fck:
-	clk_put(omap->utmi_p1_fck);
-
-err_end:
+err_xclk60mhsp1:
 	clk_put(omap->ehci_logic_fck);
-	pm_runtime_disable(dev);
-	kfree(omap);
 
-end_probe:
+err_remap:
+	kfree(omap);
 	return ret;
 }
 
@@ -655,18 +647,20 @@ end_probe:
 static int __devexit usbhs_omap_remove(struct platform_device *pdev)
 {
 	struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
+	int i;
 
 	omap_usbhs_deinit(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
 	iounmap(omap->uhh_base);
+
+	for (i = 0; i < MAX_HS_USB_PORTS; i++)
+		clk_put(omap->port[i].utmi_clk);
+
 	clk_put(omap->init_60m_fclk);
-	clk_put(omap->usbhost_p2_fck);
-	clk_put(omap->usbhost_p1_fck);
 	clk_put(omap->xclk60mhsp2_ck);
-	clk_put(omap->utmi_p2_fck);
 	clk_put(omap->xclk60mhsp1_ck);
-	clk_put(omap->utmi_p1_fck);
 	clk_put(omap->ehci_logic_fck);
-	pm_runtime_disable(&pdev->dev);
+
 	kfree(omap);
 
 	return 0;
-- 
1.7.4.1

--
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 06/16] mfd: omap-usb-host: cleanup clock management code

[Felipe Balbi]

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

Hi,

On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
> All ports have similarly named port clocks so we can
> bunch them into a port data structure and use for loop
> to enable/disable the clocks.
> 
> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> ---
>  drivers/mfd/omap-usb-host.c |  208 +++++++++++++++++++++----------------------
>  1 files changed, 101 insertions(+), 107 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 23cec57..7303c41 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -76,6 +76,8 @@
>  
>  #define	OMAP_UHH_DEBUG_CSR				(0x44)
>  
> +#define MAX_HS_USB_PORTS	3	/* Increase this if any chip has more */
> +
>  /* Values of UHH_REVISION - Note: these are not given in the TRM */
>  #define OMAP_USBHS_REV1		0x00000010	/* OMAP3 */
>  #define OMAP_USBHS_REV2		0x50700100	/* OMAP4 */
> @@ -87,14 +89,15 @@
>  #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
>  #define is_ehci_hsic_mode(x)	(x == OMAP_EHCI_PORT_MODE_HSIC)
>  
> +struct usbhs_port {
> +	struct clk	*utmi_clk;
> +};

I rather not since this will make it a lot more difficult to use
pm_clk_add() :-s Also, this sort of thing should be dynamically
allocated anyway ;-)

-- 
balbi

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

Re: [PATCH 06/16] mfd: omap-usb-host: cleanup clock management code

[Roger Quadros]

Felipe,

On 11/21/2012 03:39 PM, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
>> All ports have similarly named port clocks so we can
>> bunch them into a port data structure and use for loop
>> to enable/disable the clocks.
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>>  drivers/mfd/omap-usb-host.c |  208 +++++++++++++++++++++----------------------
>>  1 files changed, 101 insertions(+), 107 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 23cec57..7303c41 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -76,6 +76,8 @@
>>  
>>  #define	OMAP_UHH_DEBUG_CSR				(0x44)
>>  
>> +#define MAX_HS_USB_PORTS	3	/* Increase this if any chip has more */
>> +
>>  /* Values of UHH_REVISION - Note: these are not given in the TRM */
>>  #define OMAP_USBHS_REV1		0x00000010	/* OMAP3 */
>>  #define OMAP_USBHS_REV2		0x50700100	/* OMAP4 */
>> @@ -87,14 +89,15 @@
>>  #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
>>  #define is_ehci_hsic_mode(x)	(x == OMAP_EHCI_PORT_MODE_HSIC)
>>  
>> +struct usbhs_port {
>> +	struct clk	*utmi_clk;
>> +};
> 
> I rather not since this will make it a lot more difficult to use
> pm_clk_add() :-s Also, this sort of thing should be dynamically
> allocated anyway ;-)
> 

Why do you say so? The whole point of this patch is to group similarly
named clocks so that we can use a for loop and set number of ports (or
clocks) dynamically. I suppose it would be just a matter of replacing
clk_enable/disable() with pm_clk_add() later, right?

If you see patch 11, we are adding 2 HSIC related clocks to this
structure. This means 9 clocks (i.e. 3 clocks for 3 ports) can be
managed using a simple for loop instead of coding each clock name by hand.

--
cheers,
-roger

Re: [PATCH 06/16] mfd: omap-usb-host: cleanup clock management code

[Felipe Balbi]

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

Hi,

On Mon, Nov 26, 2012 at 05:14:45PM +0200, Roger Quadros wrote:
> Felipe,
> 
> On 11/21/2012 03:39 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
> >> All ports have similarly named port clocks so we can
> >> bunch them into a port data structure and use for loop
> >> to enable/disable the clocks.
> >>
> >> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> >> ---
> >>  drivers/mfd/omap-usb-host.c |  208 +++++++++++++++++++++----------------------
> >>  1 files changed, 101 insertions(+), 107 deletions(-)
> >>
> >> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> >> index 23cec57..7303c41 100644
> >> --- a/drivers/mfd/omap-usb-host.c
> >> +++ b/drivers/mfd/omap-usb-host.c
> >> @@ -76,6 +76,8 @@
> >>  
> >>  #define	OMAP_UHH_DEBUG_CSR				(0x44)
> >>  
> >> +#define MAX_HS_USB_PORTS	3	/* Increase this if any chip has more */
> >> +
> >>  /* Values of UHH_REVISION - Note: these are not given in the TRM */
> >>  #define OMAP_USBHS_REV1		0x00000010	/* OMAP3 */
> >>  #define OMAP_USBHS_REV2		0x50700100	/* OMAP4 */
> >> @@ -87,14 +89,15 @@
> >>  #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
> >>  #define is_ehci_hsic_mode(x)	(x == OMAP_EHCI_PORT_MODE_HSIC)
> >>  
> >> +struct usbhs_port {
> >> +	struct clk	*utmi_clk;
> >> +};
> > 
> > I rather not since this will make it a lot more difficult to use
> > pm_clk_add() :-s Also, this sort of thing should be dynamically
> > allocated anyway ;-)
> > 
> 
> Why do you say so? The whole point of this patch is to group similarly
> named clocks so that we can use a for loop and set number of ports (or
> clocks) dynamically. I suppose it would be just a matter of replacing
> clk_enable/disable() with pm_clk_add() later, right?
> 
> If you see patch 11, we are adding 2 HSIC related clocks to this
> structure. This means 9 clocks (i.e. 3 clocks for 3 ports) can be
> managed using a simple for loop instead of coding each clock name by hand.

that's usually not what you want, actually. You want clock management to
be explicit so you can have micro-power optimizations. I fear that the
time omap-usb-host.c gets *truly* stabilized and we move to more
aggressive PM, we will undo these changes just to have a more granular
control of the clocks, at which point your patch would be rendered
useless.

-- 
balbi

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

Re: [PATCH 06/16] mfd: omap-usb-host: cleanup clock management code

[Roger Quadros]

On 11/26/2012 10:02 PM, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Nov 26, 2012 at 05:14:45PM +0200, Roger Quadros wrote:
>> Felipe,
>>
>> On 11/21/2012 03:39 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
>>>> All ports have similarly named port clocks so we can
>>>> bunch them into a port data structure and use for loop
>>>> to enable/disable the clocks.
>>>>
>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>>> ---
>>>>  drivers/mfd/omap-usb-host.c |  208 +++++++++++++++++++++----------------------
>>>>  1 files changed, 101 insertions(+), 107 deletions(-)
>>>>
>>>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>>>> index 23cec57..7303c41 100644
>>>> --- a/drivers/mfd/omap-usb-host.c
>>>> +++ b/drivers/mfd/omap-usb-host.c
>>>> @@ -76,6 +76,8 @@
>>>>  
>>>>  #define	OMAP_UHH_DEBUG_CSR				(0x44)
>>>>  
>>>> +#define MAX_HS_USB_PORTS	3	/* Increase this if any chip has more */
>>>> +
>>>>  /* Values of UHH_REVISION - Note: these are not given in the TRM */
>>>>  #define OMAP_USBHS_REV1		0x00000010	/* OMAP3 */
>>>>  #define OMAP_USBHS_REV2		0x50700100	/* OMAP4 */
>>>> @@ -87,14 +89,15 @@
>>>>  #define is_ehci_tll_mode(x)	(x == OMAP_EHCI_PORT_MODE_TLL)
>>>>  #define is_ehci_hsic_mode(x)	(x == OMAP_EHCI_PORT_MODE_HSIC)
>>>>  
>>>> +struct usbhs_port {
>>>> +	struct clk	*utmi_clk;
>>>> +};
>>>
>>> I rather not since this will make it a lot more difficult to use
>>> pm_clk_add() :-s Also, this sort of thing should be dynamically
>>> allocated anyway ;-)
>>>
>>
>> Why do you say so? The whole point of this patch is to group similarly
>> named clocks so that we can use a for loop and set number of ports (or
>> clocks) dynamically. I suppose it would be just a matter of replacing
>> clk_enable/disable() with pm_clk_add() later, right?
>>
>> If you see patch 11, we are adding 2 HSIC related clocks to this
>> structure. This means 9 clocks (i.e. 3 clocks for 3 ports) can be
>> managed using a simple for loop instead of coding each clock name by hand.
> 
> that's usually not what you want, actually. You want clock management to
> be explicit so you can have micro-power optimizations. I fear that the
> time omap-usb-host.c gets *truly* stabilized and we move to more
> aggressive PM, we will undo these changes just to have a more granular
> control of the clocks, at which point your patch would be rendered
> useless.
> 

The granularity is still there, just that port clocks are grouped
together. Do you think it is better if I get rid of 'struct usbhs_port'
and keep the clocks in the main structure instead?

e.g.

struct usbhs_hcd_omap {
	struct clk	**utmi_clk;
	struct clk	**hsic1_clk;
	struct clk	**hsic2_clk;
...
}

The clocks can then be accessed as follows

	omap->utmi_clk[i];	/* i is port number */

Does this sound OK to you?

cheers,
-roger

[PATCH 11/16] mfd: omap-usb-host: Manage HSIC clocks for HSIC mode

[Roger Quadros]

Enable the optional HSIC clocks (60MHz and 480MHz) for the ports
that are configured in HSIC mode.

Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
---
 drivers/mfd/omap-usb-host.c |   56 +++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0d39bd7..e5ba193 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -88,6 +88,8 @@
 
 struct usbhs_port {
 	struct clk	*utmi_clk;
+	struct clk	*hsic60m_clk;
+	struct clk	*hsic480m_clk;
 };
 
 struct usbhs_hcd_omap {
@@ -300,6 +302,26 @@ static int usbhs_runtime_resume(struct device *dev)
 				}
 			}
 		}
+
+		/* Enable HSIC clocks if required */
+		if (is_ehci_hsic_mode(pdata->port_mode[i])) {
+			if (omap->port[i].hsic60m_clk) {
+				r = clk_enable(omap->port[i].hsic60m_clk);
+				if (r) {
+					dev_err(dev,
+					 "%s: Can't enable port %d hsic60m clk : %d\n",
+					 __func__, i, r);
+				}
+			}
+			if (omap->port[i].hsic480m_clk) {
+				r = clk_enable(omap->port[i].hsic480m_clk);
+				if (r) {
+					dev_err(dev,
+					 "%s: Can't enable port %d hsic480m clk : %d\n",
+					 __func__, i, r);
+				}
+			}
+		}
 	}
 
 	spin_unlock_irqrestore(&omap->lock, flags);
@@ -323,6 +345,14 @@ static int usbhs_runtime_suspend(struct device *dev)
 			if (omap->port[i].utmi_clk)
 				clk_disable(omap->port[i].utmi_clk);
 		}
+
+		if (is_ehci_hsic_mode(pdata->port_mode[i])) {
+			if (omap->port[i].hsic60m_clk)
+				clk_disable(omap->port[i].hsic60m_clk);
+
+			if (omap->port[i].hsic480m_clk)
+				clk_disable(omap->port[i].hsic480m_clk);
+		}
 	}
 
 	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
@@ -575,6 +605,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 	for (i = 0; i < omap->nports; i++) {
 		struct clk *pclk;
 		char utmi_clk[] = "usb_host_hs_utmi_px_clk";
+		char hsic_clk[] = "usb_host_hs_hsic480m_px_clk";
 
 		/* clock names are indexed from 1*/
 		sprintf(utmi_clk, "usb_host_hs_utmi_p%d_clk", i + 1);
@@ -590,6 +621,21 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 		else
 			omap->port[i].utmi_clk = pclk;
 
+		sprintf(hsic_clk, "usb_host_hs_hsic480m_p%d_clk", i + 1);
+		pclk = clk_get(dev, hsic_clk);
+		if (IS_ERR(pclk))
+			dev_err(dev, "Failed to get clock : %s : %ld\n",
+				hsic_clk, PTR_ERR(pclk));
+		else
+			omap->port[i].hsic480m_clk = pclk;
+
+		sprintf(hsic_clk, "usb_host_hs_hsic60m_p%d_clk", i + 1);
+		pclk = clk_get(dev, hsic_clk);
+		if (IS_ERR(pclk))
+			dev_err(dev, "Failed to get clock : %s : %ld\n",
+				hsic_clk, PTR_ERR(pclk));
+		else
+			omap->port[i].hsic60m_clk = pclk;
 	}
 
 	if (is_ehci_phy_mode(pdata->port_mode[0])) {
@@ -637,8 +683,11 @@ err_alloc:
 	omap_usbhs_deinit(&pdev->dev);
 	iounmap(omap->uhh_base);
 
-	for (i = 0; i < omap->nports; i++)
+	for (i = 0; i < omap->nports; i++) {
 		clk_put(omap->port[i].utmi_clk);
+		clk_put(omap->port[i].hsic60m_clk);
+		clk_put(omap->port[i].hsic480m_clk);
+	}
 
 	clk_put(omap->init_60m_fclk);
 
@@ -673,8 +722,11 @@ static int __devexit usbhs_omap_remove(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	iounmap(omap->uhh_base);
 
-	for (i = 0; i < omap->nports; i++)
+	for (i = 0; i < omap->nports; i++) {
 		clk_put(omap->port[i].utmi_clk);
+		clk_put(omap->port[i].hsic60m_clk);
+		clk_put(omap->port[i].hsic480m_clk);
+	}
 
 	clk_put(omap->init_60m_fclk);
 	clk_put(omap->xclk60mhsp2_ck);
-- 
1.7.4.1

--
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 11/16] mfd: omap-usb-host: Manage HSIC clocks for HSIC mode

[Felipe Balbi]

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

Hi,

On Thu, Nov 15, 2012 at 04:34:09PM +0200, Roger Quadros wrote:
> Enable the optional HSIC clocks (60MHz and 480MHz) for the ports
> that are configured in HSIC mode.
> 
> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> ---
>  drivers/mfd/omap-usb-host.c |   56 +++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 54 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 0d39bd7..e5ba193 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -88,6 +88,8 @@
>  
>  struct usbhs_port {
>  	struct clk	*utmi_clk;
> +	struct clk	*hsic60m_clk;
> +	struct clk	*hsic480m_clk;
>  };
>  
>  struct usbhs_hcd_omap {
> @@ -300,6 +302,26 @@ static int usbhs_runtime_resume(struct device *dev)
>  				}
>  			}
>  		}
> +
> +		/* Enable HSIC clocks if required */
> +		if (is_ehci_hsic_mode(pdata->port_mode[i])) {
> +			if (omap->port[i].hsic60m_clk) {
> +				r = clk_enable(omap->port[i].hsic60m_clk);
> +				if (r) {
> +					dev_err(dev,
> +					 "%s: Can't enable port %d hsic60m clk : %d\n",
> +					 __func__, i, r);
> +				}
> +			}
> +			if (omap->port[i].hsic480m_clk) {
> +				r = clk_enable(omap->port[i].hsic480m_clk);
> +				if (r) {
> +					dev_err(dev,
> +					 "%s: Can't enable port %d hsic480m clk : %d\n",
> +					 __func__, i, r);
> +				}
> +			}
> +		}
>  	}

with this deep indentation, it should've caught your attention that
something can definitely be re-factored.

> @@ -323,6 +345,14 @@ static int usbhs_runtime_suspend(struct device *dev)
>  			if (omap->port[i].utmi_clk)
>  				clk_disable(omap->port[i].utmi_clk);
>  		}
> +
> +		if (is_ehci_hsic_mode(pdata->port_mode[i])) {
> +			if (omap->port[i].hsic60m_clk)
> +				clk_disable(omap->port[i].hsic60m_clk);
> +
> +			if (omap->port[i].hsic480m_clk)
> +				clk_disable(omap->port[i].hsic480m_clk);
> +		}
>  	}
>  
>  	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
> @@ -575,6 +605,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  	for (i = 0; i < omap->nports; i++) {
>  		struct clk *pclk;
>  		char utmi_clk[] = "usb_host_hs_utmi_px_clk";
> +		char hsic_clk[] = "usb_host_hs_hsic480m_px_clk";

same comment from another patch. Was this lazyness ?

> @@ -590,6 +621,21 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>  		else
>  			omap->port[i].utmi_clk = pclk;
>  
> +		sprintf(hsic_clk, "usb_host_hs_hsic480m_p%d_clk", i + 1);

will overflow if 'i' ever goes over 8.

> +		pclk = clk_get(dev, hsic_clk);
> +		if (IS_ERR(pclk))
> +			dev_err(dev, "Failed to get clock : %s : %ld\n",
> +				hsic_clk, PTR_ERR(pclk));
> +		else
> +			omap->port[i].hsic480m_clk = pclk;
> +
> +		sprintf(hsic_clk, "usb_host_hs_hsic60m_p%d_clk", i + 1);

ditto.

-- 
balbi

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

Re: [PATCH 11/16] mfd: omap-usb-host: Manage HSIC clocks for HSIC mode

[Roger Quadros]

On 11/21/2012 03:54 PM, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Nov 15, 2012 at 04:34:09PM +0200, Roger Quadros wrote:
>> Enable the optional HSIC clocks (60MHz and 480MHz) for the ports
>> that are configured in HSIC mode.
>>
>> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>> ---
>>  drivers/mfd/omap-usb-host.c |   56 +++++++++++++++++++++++++++++++++++++++++-
>>  1 files changed, 54 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 0d39bd7..e5ba193 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -88,6 +88,8 @@
>>  
>>  struct usbhs_port {
>>  	struct clk	*utmi_clk;
>> +	struct clk	*hsic60m_clk;
>> +	struct clk	*hsic480m_clk;
>>  };
>>  
>>  struct usbhs_hcd_omap {
>> @@ -300,6 +302,26 @@ static int usbhs_runtime_resume(struct device *dev)
>>  				}
>>  			}
>>  		}
>> +
>> +		/* Enable HSIC clocks if required */
>> +		if (is_ehci_hsic_mode(pdata->port_mode[i])) {
>> +			if (omap->port[i].hsic60m_clk) {
>> +				r = clk_enable(omap->port[i].hsic60m_clk);
>> +				if (r) {
>> +					dev_err(dev,
>> +					 "%s: Can't enable port %d hsic60m clk : %d\n",
>> +					 __func__, i, r);
>> +				}
>> +			}
>> +			if (omap->port[i].hsic480m_clk) {
>> +				r = clk_enable(omap->port[i].hsic480m_clk);
>> +				if (r) {
>> +					dev_err(dev,
>> +					 "%s: Can't enable port %d hsic480m clk : %d\n",
>> +					 __func__, i, r);
>> +				}
>> +			}
>> +		}
>>  	}
> 
> with this deep indentation, it should've caught your attention that
> something can definitely be re-factored.

OK.

> 
>> @@ -323,6 +345,14 @@ static int usbhs_runtime_suspend(struct device *dev)
>>  			if (omap->port[i].utmi_clk)
>>  				clk_disable(omap->port[i].utmi_clk);
>>  		}
>> +
>> +		if (is_ehci_hsic_mode(pdata->port_mode[i])) {
>> +			if (omap->port[i].hsic60m_clk)
>> +				clk_disable(omap->port[i].hsic60m_clk);
>> +
>> +			if (omap->port[i].hsic480m_clk)
>> +				clk_disable(omap->port[i].hsic480m_clk);
>> +		}
>>  	}
>>  
>>  	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
>> @@ -575,6 +605,7 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>>  	for (i = 0; i < omap->nports; i++) {
>>  		struct clk *pclk;
>>  		char utmi_clk[] = "usb_host_hs_utmi_px_clk";
>> +		char hsic_clk[] = "usb_host_hs_hsic480m_px_clk";
> 
> same comment from another patch. Was this lazyness ?

:)

> 
>> @@ -590,6 +621,21 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
>>  		else
>>  			omap->port[i].utmi_clk = pclk;
>>  
>> +		sprintf(hsic_clk, "usb_host_hs_hsic480m_p%d_clk", i + 1);
> 
> will overflow if 'i' ever goes over 8.
> 
>> +		pclk = clk_get(dev, hsic_clk);
>> +		if (IS_ERR(pclk))
>> +			dev_err(dev, "Failed to get clock : %s : %ld\n",
>> +				hsic_clk, PTR_ERR(pclk));
>> +		else
>> +			omap->port[i].hsic480m_clk = pclk;
>> +
>> +		sprintf(hsic_clk, "usb_host_hs_hsic60m_p%d_clk", i + 1);
> 
> ditto.
> 
--
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 15/16] ARM: OMAP4: omap4panda: Don't enable USB PHY clock from board

[Roger Quadros]

Instead of enabling the USB PHY clock in the board file we
provide the PHY clock details to the driver via board platform
data so that driver code can manage the clock.

Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
---
 arch/arm/mach-omap2/board-omap4panda.c |   14 +++-----------
 1 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..b942abe 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -151,7 +151,9 @@ static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
 	.phy_reset  = false,
 	.reset_gpio_port[0]  = -EINVAL,
 	.reset_gpio_port[1]  = -EINVAL,
-	.reset_gpio_port[2]  = -EINVAL
+	.reset_gpio_port[2]  = -EINVAL,
+	.clk[0] = "auxclk3_ck", /* FREF_CLK3 provides 19.2 MHz clock to PHY */
+	.clkrate[0] = 19200000,
 };
 
 static struct gpio panda_ehci_gpios[] __initdata = {
@@ -162,16 +164,6 @@ static struct gpio panda_ehci_gpios[] __initdata = {
 static void __init omap4_ehci_init(void)
 {
 	int ret;
-	struct clk *phy_ref_clk;

Re: [PATCH 15/16] ARM: OMAP4: omap4panda: Don't enable USB PHY clock from board

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:13PM +0200, Roger Quadros wrote:
> Instead of enabling the USB PHY clock in the board file we
> provide the PHY clock details to the driver via board platform
> data so that driver code can manage the clock.
> 
> Signed-off-by: Roger Quadros <rogerq@ti.com>

this patch is ok-ish. But clock should be managed by PHY driver instead.

> ---
>  arch/arm/mach-omap2/board-omap4panda.c |   14 +++-----------
>  1 files changed, 3 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
> index bfcd397..b942abe 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -151,7 +151,9 @@ static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
>  	.phy_reset  = false,
>  	.reset_gpio_port[0]  = -EINVAL,
>  	.reset_gpio_port[1]  = -EINVAL,
> -	.reset_gpio_port[2]  = -EINVAL
> +	.reset_gpio_port[2]  = -EINVAL,
> +	.clk[0] = "auxclk3_ck", /* FREF_CLK3 provides 19.2 MHz clock to PHY */
> +	.clkrate[0] = 19200000,
>  };
>  
>  static struct gpio panda_ehci_gpios[] __initdata = {
> @@ -162,16 +164,6 @@ static struct gpio panda_ehci_gpios[] __initdata = {
>  static void __init omap4_ehci_init(void)
>  {
>  	int ret;
> -	struct clk *phy_ref_clk;
> -
> -	/* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
> -	phy_ref_clk = clk_get(NULL, "auxclk3_ck");
> -	if (IS_ERR(phy_ref_clk)) {
> -		pr_err("Cannot request auxclk3\n");
> -		return;
> -	}
> -	clk_set_rate(phy_ref_clk, 19200000);
> -	clk_prepare_enable(phy_ref_clk);
>  
>  	/* disable the power to the usb hub prior to init and reset phy+hub */
>  	ret = gpio_request_array(panda_ehci_gpios,
> -- 
> 1.7.4.1
> 

-- 
balbi

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

Re: [PATCH 00/16] OMAP USB Host cleanup

[Kevin Hilman]

Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:

> Hi,
>
> This patchset addresses the following
>
> - Avoid addressing clocks one by one by name and use a for loop + bunch
>   of cleanups.
> - Get number of channels/ports dynamically either from revision register
>   or from platform data. Avoids getting clocks that are not present.
> - Add OMAP5 and HSIC mode (Not tested)
> - Save power on Panda when EHCI driver is not loaded.
>

Seeing the clock changes/cleanups, I gave this a spin on OMAP3
(3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it
fixed up the problem where CORE does not hit retention in idle when USB
host is enabled, even with no devices attached.

Unfortunately, it didn't help. :(

Felipe, Keshava, any plans to address this problem which has been around
for a couple cycles now and led me to disable USB host in
omap2plus_defconfig?[1]

Kevin

[1] https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=06b4ba529528fbf9c24ce37b7618f4b0264750e2


--
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 00/16] OMAP USB Host cleanup

[Roger Quadros]

Kevin,

On 11/16/2012 10:08 PM, Kevin Hilman wrote:
> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
> 
>> Hi,
>>
>> This patchset addresses the following
>>
>> - Avoid addressing clocks one by one by name and use a for loop + bunch
>>   of cleanups.
>> - Get number of channels/ports dynamically either from revision register
>>   or from platform data. Avoids getting clocks that are not present.
>> - Add OMAP5 and HSIC mode (Not tested)
>> - Save power on Panda when EHCI driver is not loaded.
>>
> 
> Seeing the clock changes/cleanups, I gave this a spin on OMAP3
> (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it
> fixed up the problem where CORE does not hit retention in idle when USB
> host is enabled, even with no devices attached.
> 
> Unfortunately, it didn't help. :(

oh that's bad. But this series wasn't meant to fix that ;).

I could take a look at it once I get hold of the serial cable to connect
to the beagle.

regards,
-roger
--
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 00/16] OMAP USB Host cleanup

[Kevin Hilman]

Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:

> Kevin,
>
> On 11/16/2012 10:08 PM, Kevin Hilman wrote:
>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> writes:
>> 
>>> Hi,
>>>
>>> This patchset addresses the following
>>>
>>> - Avoid addressing clocks one by one by name and use a for loop + bunch
>>>   of cleanups.
>>> - Get number of channels/ports dynamically either from revision register
>>>   or from platform data. Avoids getting clocks that are not present.
>>> - Add OMAP5 and HSIC mode (Not tested)
>>> - Save power on Panda when EHCI driver is not loaded.
>>>
>> 
>> Seeing the clock changes/cleanups, I gave this a spin on OMAP3
>> (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it
>> fixed up the problem where CORE does not hit retention in idle when USB
>> host is enabled, even with no devices attached.
>> 
>> Unfortunately, it didn't help. :(
>
> oh that's bad. But this series wasn't meant to fix that ;).

Oh, sorry.  Yeah, I didn't mean this as a nak.  Just an opportunity to
complain to the maintainers that a long-standing issue needs to be
addressed.

Kevin
--
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 00/16] OMAP USB Host cleanup

[Tony Lindgren]

Hi Roger,

* Kevin Hilman <khilman@deeprootsystems.com> [121119 15:24]:
> Roger Quadros <rogerq@ti.com> writes:
> 
> > Kevin,
> >
> > On 11/16/2012 10:08 PM, Kevin Hilman wrote:
> >> Roger Quadros <rogerq@ti.com> writes:
> >> 
> >>> Hi,
> >>>
> >>> This patchset addresses the following
> >>>
> >>> - Avoid addressing clocks one by one by name and use a for loop + bunch
> >>>   of cleanups.
> >>> - Get number of channels/ports dynamically either from revision register
> >>>   or from platform data. Avoids getting clocks that are not present.
> >>> - Add OMAP5 and HSIC mode (Not tested)
> >>> - Save power on Panda when EHCI driver is not loaded.
> >>>
> >> 
> >> Seeing the clock changes/cleanups, I gave this a spin on OMAP3
> >> (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it
> >> fixed up the problem where CORE does not hit retention in idle when USB
> >> host is enabled, even with no devices attached.
> >> 
> >> Unfortunately, it didn't help. :(
> >
> > oh that's bad. But this series wasn't meant to fix that ;).
> 
> Oh, sorry.  Yeah, I didn't mean this as a nak.  Just an opportunity to
> complain to the maintainers that a long-standing issue needs to be
> addressed.

It seems that drivers/mfd/omap-usb-host.c is one of the last users
of cpu_is_omap macros blocking enabling ARM multiplatform support for
omap2+.

Please fix that ASAP as early as possible in this patch series to
remove the dependencies between core omap code development and driver
development.

Basically you need to remove #include <plat/cpu.h> and pass the
revision information in platform data (and device tree compatible
flag when that is supported).

Regards,

Tony

Re: [PATCH 00/16] OMAP USB Host cleanup

[Roger Quadros]

Hi Tony,

On 11/21/2012 01:13 AM, Tony Lindgren wrote:
> Hi Roger,
> 
> * Kevin Hilman <khilman@deeprootsystems.com> [121119 15:24]:
>> Roger Quadros <rogerq@ti.com> writes:
>>
>>> Kevin,
>>>
>>> On 11/16/2012 10:08 PM, Kevin Hilman wrote:
>>>> Roger Quadros <rogerq@ti.com> writes:
>>>>
>>>>> Hi,
>>>>>
>>>>> This patchset addresses the following
>>>>>
>>>>> - Avoid addressing clocks one by one by name and use a for loop + bunch
>>>>>   of cleanups.
>>>>> - Get number of channels/ports dynamically either from revision register
>>>>>   or from platform data. Avoids getting clocks that are not present.
>>>>> - Add OMAP5 and HSIC mode (Not tested)
>>>>> - Save power on Panda when EHCI driver is not loaded.
>>>>>
>>>>
>>>> Seeing the clock changes/cleanups, I gave this a spin on OMAP3
>>>> (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it
>>>> fixed up the problem where CORE does not hit retention in idle when USB
>>>> host is enabled, even with no devices attached.
>>>>
>>>> Unfortunately, it didn't help. :(
>>>
>>> oh that's bad. But this series wasn't meant to fix that ;).
>>
>> Oh, sorry.  Yeah, I didn't mean this as a nak.  Just an opportunity to
>> complain to the maintainers that a long-standing issue needs to be
>> addressed.
> 
> It seems that drivers/mfd/omap-usb-host.c is one of the last users
> of cpu_is_omap macros blocking enabling ARM multiplatform support for
> omap2+.
> 
> Please fix that ASAP as early as possible in this patch series to
> remove the dependencies between core omap code development and driver
> development.
> 
> Basically you need to remove #include <plat/cpu.h> and pass the
> revision information in platform data (and device tree compatible
> flag when that is supported).
> 

Okay I'll send a patch to fix that ASAP.

Felipe, any comments on the patches in this series?

regards,
-roger

Re: [PATCH 00/16] OMAP USB Host cleanup

[Felipe Balbi]

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

Hi,

On Wed, Nov 21, 2012 at 12:05:12PM +0200, Roger Quadros wrote:
> Hi Tony,
> 
> On 11/21/2012 01:13 AM, Tony Lindgren wrote:
> > Hi Roger,
> > 
> > * Kevin Hilman <khilman@deeprootsystems.com> [121119 15:24]:
> >> Roger Quadros <rogerq@ti.com> writes:
> >>
> >>> Kevin,
> >>>
> >>> On 11/16/2012 10:08 PM, Kevin Hilman wrote:
> >>>> Roger Quadros <rogerq@ti.com> writes:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> This patchset addresses the following
> >>>>>
> >>>>> - Avoid addressing clocks one by one by name and use a for loop + bunch
> >>>>>   of cleanups.
> >>>>> - Get number of channels/ports dynamically either from revision register
> >>>>>   or from platform data. Avoids getting clocks that are not present.
> >>>>> - Add OMAP5 and HSIC mode (Not tested)
> >>>>> - Save power on Panda when EHCI driver is not loaded.
> >>>>>
> >>>>
> >>>> Seeing the clock changes/cleanups, I gave this a spin on OMAP3
> >>>> (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it
> >>>> fixed up the problem where CORE does not hit retention in idle when USB
> >>>> host is enabled, even with no devices attached.
> >>>>
> >>>> Unfortunately, it didn't help. :(
> >>>
> >>> oh that's bad. But this series wasn't meant to fix that ;).
> >>
> >> Oh, sorry.  Yeah, I didn't mean this as a nak.  Just an opportunity to
> >> complain to the maintainers that a long-standing issue needs to be
> >> addressed.
> > 
> > It seems that drivers/mfd/omap-usb-host.c is one of the last users
> > of cpu_is_omap macros blocking enabling ARM multiplatform support for
> > omap2+.
> > 
> > Please fix that ASAP as early as possible in this patch series to
> > remove the dependencies between core omap code development and driver
> > development.
> > 
> > Basically you need to remove #include <plat/cpu.h> and pass the
> > revision information in platform data (and device tree compatible
> > flag when that is supported).
> > 
> 
> Okay I'll send a patch to fix that ASAP.
> 
> Felipe, any comments on the patches in this series?

I'm waiting for Keshava's comments since he's the one who has been
dealing with omap usb host the most. I can look into this series too
shortly.

-- 
balbi

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

Re: [PATCH 00/16] OMAP USB Host cleanup

[Roger Quadros]

On 11/20/2012 01:22 AM, Kevin Hilman wrote:
> Roger Quadros <rogerq@ti.com> writes:
> 
>> Kevin,
>>
>> On 11/16/2012 10:08 PM, Kevin Hilman wrote:
>>> Roger Quadros <rogerq@ti.com> writes:
>>>
>>>> Hi,
>>>>
>>>> This patchset addresses the following
>>>>
>>>> - Avoid addressing clocks one by one by name and use a for loop + bunch
>>>>   of cleanups.
>>>> - Get number of channels/ports dynamically either from revision register
>>>>   or from platform data. Avoids getting clocks that are not present.
>>>> - Add OMAP5 and HSIC mode (Not tested)
>>>> - Save power on Panda when EHCI driver is not loaded.
>>>>
>>>
>>> Seeing the clock changes/cleanups, I gave this a spin on OMAP3
>>> (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it
>>> fixed up the problem where CORE does not hit retention in idle when USB
>>> host is enabled, even with no devices attached.
>>>
>>> Unfortunately, it didn't help. :(
>>
>> oh that's bad. But this series wasn't meant to fix that ;).
> 
> Oh, sorry.  Yeah, I didn't mean this as a nak.  Just an opportunity to
> complain to the maintainers that a long-standing issue needs to be
> addressed.
> 

Kevin,

I gave a quick look at the issue. It seems that the High Speed USB Host
module is kept in Software forced wakeup mode as a quick fix workaround
to a bunch of silicon erratas. And we do nothing on USB global suspend.
That's why CORE does not hit retention.

If we runtime_suspend the USB host module on USB global suspend then it
will be put in Force Idle mode. This will allow CORE to hit retention
but then we will no longer be able to detect USB device connect events.

So, till we have a better solution I will suggest to keep EHCI_HCD as a
module in omap2plus_defconfig.

--
regards,
-roger

Re: [PATCH 00/16] OMAP USB Host cleanup

[Felipe Balbi]

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

On Tue, Nov 27, 2012 at 04:42:47PM +0200, Roger Quadros wrote:
> On 11/20/2012 01:22 AM, Kevin Hilman wrote:
> > Roger Quadros <rogerq@ti.com> writes:
> > 
> >> Kevin,
> >>
> >> On 11/16/2012 10:08 PM, Kevin Hilman wrote:
> >>> Roger Quadros <rogerq@ti.com> writes:
> >>>
> >>>> Hi,
> >>>>
> >>>> This patchset addresses the following
> >>>>
> >>>> - Avoid addressing clocks one by one by name and use a for loop + bunch
> >>>>   of cleanups.
> >>>> - Get number of channels/ports dynamically either from revision register
> >>>>   or from platform data. Avoids getting clocks that are not present.
> >>>> - Add OMAP5 and HSIC mode (Not tested)
> >>>> - Save power on Panda when EHCI driver is not loaded.
> >>>>
> >>>
> >>> Seeing the clock changes/cleanups, I gave this a spin on OMAP3
> >>> (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it
> >>> fixed up the problem where CORE does not hit retention in idle when USB
> >>> host is enabled, even with no devices attached.
> >>>
> >>> Unfortunately, it didn't help. :(
> >>
> >> oh that's bad. But this series wasn't meant to fix that ;).
> > 
> > Oh, sorry.  Yeah, I didn't mean this as a nak.  Just an opportunity to
> > complain to the maintainers that a long-standing issue needs to be
> > addressed.
> > 
> 
> Kevin,
> 
> I gave a quick look at the issue. It seems that the High Speed USB Host
> module is kept in Software forced wakeup mode as a quick fix workaround
> to a bunch of silicon erratas. And we do nothing on USB global suspend.
> That's why CORE does not hit retention.
> 
> If we runtime_suspend the USB host module on USB global suspend then it
> will be put in Force Idle mode. This will allow CORE to hit retention
> but then we will no longer be able to detect USB device connect events.
> 
> So, till we have a better solution I will suggest to keep EHCI_HCD as a
> module in omap2plus_defconfig.

I guess that "better solution" would be I/O pads wakeup interrupts ? But
I don't think that's already in mainline, is it ?

-- 
balbi

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

Re: [PATCH 00/16] OMAP USB Host cleanup

[Grazvydas Ignotas]

On Tue, Nov 27, 2012 at 6:30 PM, Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> wrote:
> On Tue, Nov 27, 2012 at 04:42:47PM +0200, Roger Quadros wrote:
>> Kevin,
>>
>> I gave a quick look at the issue. It seems that the High Speed USB Host
>> module is kept in Software forced wakeup mode as a quick fix workaround
>> to a bunch of silicon erratas. And we do nothing on USB global suspend.
>> That's why CORE does not hit retention.
>>
>> If we runtime_suspend the USB host module on USB global suspend then it
>> will be put in Force Idle mode. This will allow CORE to hit retention
>> but then we will no longer be able to detect USB device connect events.
>>
>> So, till we have a better solution I will suggest to keep EHCI_HCD as a
>> module in omap2plus_defconfig.
>
> I guess that "better solution" would be I/O pads wakeup interrupts ? But
> I don't think that's already in mainline, is it ?

I believe there was attempt to mainline that but it was rejected by Tony:
http://marc.info/?l=linux-omap&m=134727428329745&w=2

Hopefully someone can come up with a suitable solution, not being able
to suspend and broken power saving with EHCI sucks :(

-- 
Gražvydas
--
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 12/16] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk

[Roger Quadros]

There is no such clock as utmi_p1_gfclk. It is only a clock selector
bit to select th the parent of usb_host_hs_utmi_p1_clk.
So we get rid of utmi_p1_gfclk and utmi_p2_gfclk by merging them into
usb_host_hs_utmi_p1_clk and usb_host_hs_utmi_p2_clk respectively.

CC: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/mach-omap2/clock3xxx_data.c |    2 --
 arch/arm/mach-omap2/clock44xx_data.c |   30 ++++++++----------------------
 2 files changed, 8 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index 1f42c9d..0d2ee04 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3400,8 +3400,6 @@ static struct omap_clk omap3xxx_clks[] = {
 	CLK(NULL,	"usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
 	CLK(NULL,	"usbhost_ick",	&usbhost_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
 	CLK("usbhs_omap",	"usbhost_ick",	&usbhost_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
-	CLK(NULL,	"utmi_p1_gfclk",	&dummy_ck,	CK_3XXX),
-	CLK(NULL,	"utmi_p2_gfclk",	&dummy_ck,	CK_3XXX),
 	CLK(NULL,	"xclk60mhsp1_ck",	&dummy_ck,	CK_3XXX),
 	CLK(NULL,	"xclk60mhsp2_ck",	&dummy_ck,	CK_3XXX),
 	CLK(NULL,	"usb_host_hs_utmi_p1_clk",	&dummy_ck,	CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index 6efc30c..fc3e490 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2462,25 +2462,19 @@ static const struct clksel utmi_p1_gfclk_sel[] = {
 	{ .parent = NULL },
 };
 
-static struct clk utmi_p1_gfclk = {
-	.name		= "utmi_p1_gfclk",
+/* Merged utmi_p1_gfclk into usb_host_hs_utmi_p1_clk */
+static struct clk usb_host_hs_utmi_p1_clk = {
+	.name		= "usb_host_hs_utmi_p1_clk",
 	.parent		= &init_60m_fclk,
 	.clksel		= utmi_p1_gfclk_sel,
 	.init		= &omap2_init_clksel_parent,
 	.clksel_reg	= OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
 	.clksel_mask	= OMAP4430_CLKSEL_UTMI_P1_MASK,
-	.ops		= &clkops_null,
-	.recalc		= &omap2_clksel_recalc,
-};
-
-static struct clk usb_host_hs_utmi_p1_clk = {
-	.name		= "usb_host_hs_utmi_p1_clk",
 	.ops		= &clkops_omap2_dflt,
 	.enable_reg	= OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
 	.enable_bit	= OMAP4430_OPTFCLKEN_UTMI_P1_CLK_SHIFT,
 	.clkdm_name	= "l3_init_clkdm",
-	.parent		= &utmi_p1_gfclk,
-	.recalc		= &followparent_recalc,
+	.recalc		= &omap2_clksel_recalc,
 };
 
 static const struct clksel utmi_p2_gfclk_sel[] = {
@@ -2489,25 +2483,19 @@ static const struct clksel utmi_p2_gfclk_sel[] = {
 	{ .parent = NULL },
 };
 
-static struct clk utmi_p2_gfclk = {
-	.name		= "utmi_p2_gfclk",
+/* Merged utmi_p2_gfclk into usb_host_hs_utmi_p2_clk */
+static struct clk usb_host_hs_utmi_p2_clk = {
+	.name		= "usb_host_hs_utmi_p2_clk",
 	.parent		= &init_60m_fclk,
 	.clksel		= utmi_p2_gfclk_sel,
 	.init		= &omap2_init_clksel_parent,
 	.clksel_reg	= OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
 	.clksel_mask	= OMAP4430_CLKSEL_UTMI_P2_MASK,
-	.ops		= &clkops_null,
-	.recalc		= &omap2_clksel_recalc,
-};
-
-static struct clk usb_host_hs_utmi_p2_clk = {
-	.name		= "usb_host_hs_utmi_p2_clk",
 	.ops		= &clkops_omap2_dflt,
 	.enable_reg	= OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
 	.enable_bit	= OMAP4430_OPTFCLKEN_UTMI_P2_CLK_SHIFT,
 	.clkdm_name	= "l3_init_clkdm",
-	.parent		= &utmi_p2_gfclk,
-	.recalc		= &followparent_recalc,
+	.recalc		= &omap2_clksel_recalc,
 };
 
 static struct clk usb_host_hs_utmi_p3_clk = {
@@ -3246,9 +3234,7 @@ static struct omap_clk omap44xx_clks[] = {
 	CLK(NULL,	"uart4_fck",			&uart4_fck,	CK_443X),
 	CLK("usbhs_omap",	"fs_fck",		&usb_host_fs_fck,	CK_443X),
 	CLK(NULL,	"usb_host_fs_fck",		&usb_host_fs_fck,	CK_443X),
-	CLK(NULL,	"utmi_p1_gfclk",		&utmi_p1_gfclk,	CK_443X),
 	CLK(NULL,	"usb_host_hs_utmi_p1_clk",	&usb_host_hs_utmi_p1_clk,	CK_443X),
-	CLK(NULL,	"utmi_p2_gfclk",		&utmi_p2_gfclk,	CK_443X),
 	CLK(NULL,	"usb_host_hs_utmi_p2_clk",	&usb_host_hs_utmi_p2_clk,	CK_443X),
 	CLK(NULL,	"usb_host_hs_utmi_p3_clk",	&usb_host_hs_utmi_p3_clk,	CK_443X),
 	CLK(NULL,	"usb_host_hs_hsic480m_p1_clk",	&usb_host_hs_hsic480m_p1_clk,	CK_443X),
-- 
1.7.4.1

[PATCH 13/16] mfd: omap-usb-host: Get rid of unnecessary spinlock

[Roger Quadros]

We don't really need a spinlock here, so get rid of it.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 drivers/mfd/omap-usb-host.c |   16 ----------------
 1 files changed, 0 insertions(+), 16 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index e5ba193..4289847 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -23,7 +23,6 @@
 #include <linux/delay.h>
 #include <linux/clk.h>
 #include <linux/dma-mapping.h>
-#include <linux/spinlock.h>
 #include <linux/gpio.h>
 #include <plat/cpu.h>
 #include <plat/usb.h>
@@ -106,7 +105,6 @@ struct usbhs_hcd_omap {
 	struct usbhs_omap_platform_data	*pdata;
 
 	u32				usbhs_rev;
-	spinlock_t			lock;
 };
 /*-------------------------------------------------------------------------*/
 
@@ -279,14 +277,12 @@ static bool is_ohci_port(enum usbhs_omap_port_mode pmode)
 static int usbhs_runtime_resume(struct device *dev)
 {
 	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
-	unsigned long			flags;
 	struct usbhs_omap_platform_data *pdata = omap->pdata;
 	int i, r;
 
 	dev_dbg(dev, "usbhs_runtime_resume\n");
 
 	omap_tll_enable();
-	spin_lock_irqsave(&omap->lock, flags);
 
 	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
 		clk_enable(omap->ehci_logic_fck);
@@ -324,22 +320,17 @@ static int usbhs_runtime_resume(struct device *dev)
 		}
 	}
 
-	spin_unlock_irqrestore(&omap->lock, flags);
-
 	return 0;
 }
 
 static int usbhs_runtime_suspend(struct device *dev)
 {
 	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
-	unsigned long			flags;
 	struct usbhs_omap_platform_data *pdata = omap->pdata;
 	int i;
 
 	dev_dbg(dev, "usbhs_runtime_suspend\n");
 
-	spin_lock_irqsave(&omap->lock, flags);
-
 	for (i = 0; i < omap->nports; i++) {
 		if (is_ehci_tll_mode(pdata->port_mode[i])) {
 			if (omap->port[i].utmi_clk)
@@ -358,7 +349,6 @@ static int usbhs_runtime_suspend(struct device *dev)
 	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
 		clk_disable(omap->ehci_logic_fck);
 
-	spin_unlock_irqrestore(&omap->lock, flags);
 	omap_tll_disable();
 
 	return 0;
@@ -368,7 +358,6 @@ static void omap_usbhs_init(struct device *dev)
 {
 	struct usbhs_hcd_omap		*omap = dev_get_drvdata(dev);
 	struct usbhs_omap_platform_data	*pdata = omap->pdata;
-	unsigned long			flags;
 	unsigned			reg;
 	int i;
 
@@ -388,7 +377,6 @@ static void omap_usbhs_init(struct device *dev)
 	}
 
 	pm_runtime_get_sync(dev);
-	spin_lock_irqsave(&omap->lock, flags);
 
 	reg = usbhs_read(omap->uhh_base, OMAP_UHH_HOSTCONFIG);
 	/* setup ULPI bypass and burst configurations */
@@ -446,8 +434,6 @@ static void omap_usbhs_init(struct device *dev)
 	usbhs_write(omap->uhh_base, OMAP_UHH_HOSTCONFIG, reg);
 	dev_dbg(dev, "UHH setup done, uhh_hostconfig=%x\n", reg);
 
-	spin_unlock_irqrestore(&omap->lock, flags);
-
 	pm_runtime_put_sync(dev);
 	if (pdata->ehci_data->phy_reset) {
 		/* Hold the PHY in RESET for enough time till
@@ -519,8 +505,6 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 		goto err_remap;
 	}
 
-	spin_lock_init(&omap->lock);
-
 	omap->pdata = pdata;
 	platform_set_drvdata(pdev, omap);
 	pm_runtime_enable(dev);
-- 
1.7.4.1

Re: [PATCH 13/16] mfd: omap-usb-host: Get rid of unnecessary spinlock

[Felipe Balbi]

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

Hi,

On Thu, Nov 15, 2012 at 04:34:11PM +0200, Roger Quadros wrote:
> We don't really need a spinlock here, so get rid of it.

can you prove it ? what if an IRQ happens right after disabling clocks
on ->runtime_suspend() but before it returns ? Will this not cause a
problem for you ?

(note that I have not dug pm_runtime code to make sure this wouldn't
cause a race).

-- 
balbi

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

Re: [PATCH 13/16] mfd: omap-usb-host: Get rid of unnecessary spinlock

[Roger Quadros]

On 11/21/2012 03:57 PM, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Nov 15, 2012 at 04:34:11PM +0200, Roger Quadros wrote:
>> We don't really need a spinlock here, so get rid of it.
> 
> can you prove it ? what if an IRQ happens right after disabling clocks
> on ->runtime_suspend() but before it returns ? Will this not cause a
> problem for you ?
>

Which IRQ are you referring to? I don't see any IRQ handler in
omap-usb-hot.c

In the original code, the spinlock is used only in
runtime_suspend/resume and probe functions and it didn't make any sense
to me why it was there in the first place.

> (note that I have not dug pm_runtime code to make sure this wouldn't
> cause a race).
> 

cheers,
-roger
--
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 13/16] mfd: omap-usb-host: Get rid of unnecessary spinlock

[Felipe Balbi]

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

Hi,

On Wed, Nov 21, 2012 at 05:55:19PM +0200, Roger Quadros wrote:
> On 11/21/2012 03:57 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Nov 15, 2012 at 04:34:11PM +0200, Roger Quadros wrote:
> >> We don't really need a spinlock here, so get rid of it.
> > 
> > can you prove it ? what if an IRQ happens right after disabling clocks
> > on ->runtime_suspend() but before it returns ? Will this not cause a
> > problem for you ?
> >
> 
> Which IRQ are you referring to? I don't see any IRQ handler in
> omap-usb-hot.c

oops, silly old me ;-)

> In the original code, the spinlock is used only in
> runtime_suspend/resume and probe functions and it didn't make any sense
> to me why it was there in the first place.

fair enough, I should've looked at the code before assuming there was an
IRQ handler. Carry on :-)

-- 
balbi

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

[PATCH 14/16] mfd: omap-usb-host: Support an auxiliary clock per port

[Roger Quadros]

Boards like Panda require an auxiliary clock to clock the PHY
that is connected to one of the USB ports. This patch enables
board support code to  provide the name and the rate of such
a clock for each of the USB ports. omap-usb-host driver can
then manage the clock.

Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/mach-omap2/usb-host.c        |    2 ++
 arch/arm/plat-omap/include/plat/usb.h |    6 ++++++
 drivers/mfd/omap-usb-host.c           |   33 +++++++++++++++++++++++++++++++++
 3 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index eb85528..bfab301 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -494,6 +494,8 @@ void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
 
 	for (i = 0; i < OMAP3_HS_USB_PORTS; i++) {
 		usbhs_data.port_mode[i] = pdata->port_mode[i];
+		usbhs_data.clk[i] = pdata->clk[i];
+		usbhs_data.clkrate[i] = pdata->clkrate[i];
 		usbtll_data.port_mode[i] = pdata->port_mode[i];
 		ohci_data.port_mode[i] = pdata->port_mode[i];
 		ehci_data.port_mode[i] = pdata->port_mode[i];
diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
index 6b618a1..0f89890 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -43,6 +43,9 @@ struct usbhs_omap_board_data {
 	 * Each PHY can have a separate regulator.
 	 */
 	struct regulator		*regulator[OMAP3_HS_USB_PORTS];
+
+	const char			*clk[OMAP3_HS_USB_PORTS];
+	unsigned long int		clkrate[OMAP3_HS_USB_PORTS];
 };
 
 #ifdef CONFIG_ARCH_OMAP2PLUS
@@ -65,6 +68,9 @@ struct usbhs_omap_platform_data {
 
 	struct ehci_hcd_omap_platform_data	*ehci_data;
 	struct ohci_hcd_omap_platform_data	*ohci_data;
+
+	const char			*clk[OMAP3_HS_USB_PORTS];
+	unsigned long int		clkrate[OMAP3_HS_USB_PORTS];
 };
 
 struct usbtll_omap_platform_data {
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 4289847..a1ea8e6 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -89,6 +89,7 @@ struct usbhs_port {
 	struct clk	*utmi_clk;
 	struct clk	*hsic60m_clk;
 	struct clk	*hsic480m_clk;
+	struct clk	*aux_clk;	/* board dependent clock */
 };
 
 struct usbhs_hcd_omap {
@@ -288,6 +289,15 @@ static int usbhs_runtime_resume(struct device *dev)
 		clk_enable(omap->ehci_logic_fck);
 
 	for (i = 0; i < omap->nports; i++) {
+		if (omap->port[i].aux_clk) {
+			r = clk_enable(omap->port[i].aux_clk);
+			if (r) {
+				dev_err(dev,
+				 "%s: Can't enable port %d aux clk %d\n",
+				 __func__, i, r);
+			}
+		}
+
 		if (is_ehci_tll_mode(pdata->port_mode[i])) {
 			if (omap->port[i].utmi_clk) {
 				r = clk_enable(omap->port[i].utmi_clk);
@@ -344,6 +354,9 @@ static int usbhs_runtime_suspend(struct device *dev)
 			if (omap->port[i].hsic480m_clk)
 				clk_disable(omap->port[i].hsic480m_clk);
 		}
+
+		if (omap->port[i].aux_clk)
+			clk_disable(omap->port[i].aux_clk);
 	}
 
 	if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
@@ -620,6 +633,24 @@ static int __devinit usbhs_omap_probe(struct platform_device *pdev)
 				hsic_clk, PTR_ERR(pclk));
 		else
 			omap->port[i].hsic60m_clk = pclk;
+
+		/* get the auxiliary clock if required and set its rate */
+		if (pdata->clk[i] && pdata->clkrate[i]) {
+			pclk = clk_get(dev, pdata->clk[i]);
+			if (IS_ERR(pclk)) {
+				dev_err(dev,
+				 "Failed to get clock %s\n", pdata->clk[i]);
+			} else {
+				omap->port[i].aux_clk = pclk;
+
+				ret = clk_set_rate(pclk, pdata->clkrate[i]);
+				if (ret) {
+					dev_err(dev,
+					 "Failed to set clock %s to %luHz\n",
+					 pdata->clk[i], pdata->clkrate[i]);
+				}
+			}
+		}
 	}
 
 	if (is_ehci_phy_mode(pdata->port_mode[0])) {
@@ -671,6 +702,7 @@ err_alloc:
 		clk_put(omap->port[i].utmi_clk);
 		clk_put(omap->port[i].hsic60m_clk);
 		clk_put(omap->port[i].hsic480m_clk);
+		clk_put(omap->port[i].aux_clk);
 	}
 
 	clk_put(omap->init_60m_fclk);
@@ -710,6 +742,7 @@ static int __devexit usbhs_omap_remove(struct platform_device *pdev)
 		clk_put(omap->port[i].utmi_clk);
 		clk_put(omap->port[i].hsic60m_clk);
 		clk_put(omap->port[i].hsic480m_clk);
+		clk_put(omap->port[i].aux_clk);
 	}
 
 	clk_put(omap->init_60m_fclk);
-- 
1.7.4.1

Re: [PATCH 14/16] mfd: omap-usb-host: Support an auxiliary clock per port

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:12PM +0200, Roger Quadros wrote:
> Boards like Panda require an auxiliary clock to clock the PHY
> that is connected to one of the USB ports. This patch enables
> board support code to  provide the name and the rate of such
> a clock for each of the USB ports. omap-usb-host driver can
> then manage the clock.

that clock is part of the PHY. What we need is a proper PHY driver and
teach [ouex]hci-core about PHYs.

I'd rather this wasn't merged...

-- 
balbi

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

Re: [PATCH 14/16] mfd: omap-usb-host: Support an auxiliary clock per port

[Roger Quadros]

On 11/21/2012 03:58 PM, Felipe Balbi wrote:
> On Thu, Nov 15, 2012 at 04:34:12PM +0200, Roger Quadros wrote:
>> Boards like Panda require an auxiliary clock to clock the PHY
>> that is connected to one of the USB ports. This patch enables
>> board support code to  provide the name and the rate of such
>> a clock for each of the USB ports. omap-usb-host driver can
>> then manage the clock.
> 
> that clock is part of the PHY. What we need is a proper PHY driver and
> teach [ouex]hci-core about PHYs.
> 
> I'd rather this wasn't merged...
> 

Okay.

cheers,
-roger
--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Roger Quadros]

From: Andy Green <andy.green@linaro.org>

This patch changes the management of the two GPIO for
"hub reset" (actually controls enable of ULPI PHY and hub reset) and
"hub power" (controls power to hub + eth).

Because the only connection from the ULPI PHY output is to the hub+eth
chip, there is no meaning in having the ULPI PHY running but not the
hub+eth chip.

The patch adds two regulators, the hub power one being the parent of the
reset one, and binds the reset one to the hsusb driver by using the magic
name "hsusb.0".

The end result is the usb and eth driver may now be built modular, and
when ehci-hcd is not inserted, the ULPI PHY, hub and ethernet are all
depowered or held in reset.

Signed-off-by: Andy Green <andy.green@linaro.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
 arch/arm/mach-omap2/board-omap4panda.c |   80 +++++++++++++++++++++++--------
 1 files changed, 59 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index b942abe..90fb2c4 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -156,32 +156,68 @@ static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
 	.clkrate[0] = 19200000,
 };
 
-static struct gpio panda_ehci_gpios[] __initdata = {
-	{ GPIO_HUB_POWER,	GPIOF_OUT_INIT_LOW,  "hub_power"  },
-	{ GPIO_HUB_NRESET,	GPIOF_OUT_INIT_LOW,  "hub_nreset" },
+/*
+ * hub_nreset also enables the ULPI PHY
+ * ULPI PHY is always powered
+ * hub_power enables a 3.3V regulator for (hub + eth) chip
+ * however there's no point having ULPI PHY in use alone
+ * since it's only connected to the (hub + eth) chip
+ */
+
+static struct regulator_init_data panda_hub = {
+	.constraints = {
+		.name = "vhub",
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
 };
 
-static void __init omap4_ehci_init(void)
-{
-	int ret;
+static struct fixed_voltage_config panda_vhub = {
+	.supply_name = "vhub",
+	.microvolts = 3300000,
+	.gpio = GPIO_HUB_POWER,
+	.startup_delay = 70000, /* 70msec */
+	.enable_high = 1,
+	.enabled_at_boot = 0,
+	.init_data = &panda_hub,
+};
 
-	/* disable the power to the usb hub prior to init and reset phy+hub */
-	ret = gpio_request_array(panda_ehci_gpios,
-				 ARRAY_SIZE(panda_ehci_gpios));
-	if (ret) {
-		pr_err("Unable to initialize EHCI power/reset\n");
-		return;
-	}
+static struct platform_device omap_vhub_device = {
+	.name		= "reg-fixed-voltage",
+	.id		= 2,
+	.dev = {
+		.platform_data = &panda_vhub,
+	},
+};
 
-	gpio_export(GPIO_HUB_POWER, 0);
-	gpio_export(GPIO_HUB_NRESET, 0);
-	gpio_set_value(GPIO_HUB_NRESET, 1);
+static struct regulator_init_data panda_ulpireset = {
+	/*
+	 * idea is that when operating ulpireset, regulator api will make
+	 * sure that the hub+eth chip is powered, since it's the "parent"
+	 */
+	.supply_regulator = "vhub", /* we are a child of vhub */
+	.constraints = {
+		.name = "hsusb0",
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+};
 
-	usbhs_init(&usbhs_bdata);
+static struct fixed_voltage_config panda_vulpireset = {
+	.supply_name = "hsusb0",  /* this name is magic for hsusb driver */
+	.microvolts = 3300000,
+	.gpio = GPIO_HUB_NRESET,
+	.startup_delay = 70000, /* 70msec */
+	.enable_high = 1,
+	.enabled_at_boot = 0,
+	.init_data = &panda_ulpireset,
+};
 
-	/* enable power to hub */
-	gpio_set_value(GPIO_HUB_POWER, 1);
-}
+static struct platform_device omap_vulpireset_device = {
+	.name		= "reg-fixed-voltage",
+	.id		= 3,
+	.dev = {
+		.platform_data = &panda_vulpireset,
+	},
+};
 
 static struct omap_musb_board_data musb_board_data = {
 	.interface_type		= MUSB_INTERFACE_UTMI,
@@ -496,10 +532,12 @@ static void __init omap4_panda_init(void)
 	omap4_panda_i2c_init();
 	platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
 	platform_device_register(&omap_vwlan_device);
+	platform_device_register(&omap_vhub_device);
+	platform_device_register(&omap_vulpireset_device);
 	omap_serial_init();
 	omap_sdrc_init(NULL, NULL);
 	omap4_twl6030_hsmmc_init(mmc);
-	omap4_ehci_init();
+	usbhs_init(&usbhs_bdata);
 	usb_musb_init(&musb_board_data);
 	omap4_panda_display_init();
 }
-- 
1.7.4.1

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

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

On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
> From: Andy Green <andy.green@linaro.org>
> 
> This patch changes the management of the two GPIO for
> "hub reset" (actually controls enable of ULPI PHY and hub reset) and
> "hub power" (controls power to hub + eth).

looks like this should be done by the hub driver. Alan, what would you
say ? Should the hub driver know how to power itself up ?

> Because the only connection from the ULPI PHY output is to the hub+eth
> chip, there is no meaning in having the ULPI PHY running but not the
> hub+eth chip.
> 
> The patch adds two regulators, the hub power one being the parent of the
> reset one, and binds the reset one to the hsusb driver by using the magic
> name "hsusb.0".
> 
> The end result is the usb and eth driver may now be built modular, and
> when ehci-hcd is not inserted, the ULPI PHY, hub and ethernet are all
> depowered or held in reset.
> 
> Signed-off-by: Andy Green <andy.green@linaro.org>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
>  arch/arm/mach-omap2/board-omap4panda.c |   80 +++++++++++++++++++++++--------
>  1 files changed, 59 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
> index b942abe..90fb2c4 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -156,32 +156,68 @@ static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
>  	.clkrate[0] = 19200000,
>  };
>  
> -static struct gpio panda_ehci_gpios[] __initdata = {
> -	{ GPIO_HUB_POWER,	GPIOF_OUT_INIT_LOW,  "hub_power"  },
> -	{ GPIO_HUB_NRESET,	GPIOF_OUT_INIT_LOW,  "hub_nreset" },
> +/*
> + * hub_nreset also enables the ULPI PHY
> + * ULPI PHY is always powered
> + * hub_power enables a 3.3V regulator for (hub + eth) chip
> + * however there's no point having ULPI PHY in use alone
> + * since it's only connected to the (hub + eth) chip
> + */
> +
> +static struct regulator_init_data panda_hub = {
> +	.constraints = {
> +		.name = "vhub",
> +		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
> +	},
>  };
>  
> -static void __init omap4_ehci_init(void)
> -{
> -	int ret;
> +static struct fixed_voltage_config panda_vhub = {
> +	.supply_name = "vhub",
> +	.microvolts = 3300000,
> +	.gpio = GPIO_HUB_POWER,
> +	.startup_delay = 70000, /* 70msec */
> +	.enable_high = 1,
> +	.enabled_at_boot = 0,
> +	.init_data = &panda_hub,
> +};
>  
> -	/* disable the power to the usb hub prior to init and reset phy+hub */
> -	ret = gpio_request_array(panda_ehci_gpios,
> -				 ARRAY_SIZE(panda_ehci_gpios));
> -	if (ret) {
> -		pr_err("Unable to initialize EHCI power/reset\n");
> -		return;
> -	}
> +static struct platform_device omap_vhub_device = {
> +	.name		= "reg-fixed-voltage",
> +	.id		= 2,
> +	.dev = {
> +		.platform_data = &panda_vhub,
> +	},
> +};
>  
> -	gpio_export(GPIO_HUB_POWER, 0);
> -	gpio_export(GPIO_HUB_NRESET, 0);
> -	gpio_set_value(GPIO_HUB_NRESET, 1);
> +static struct regulator_init_data panda_ulpireset = {
> +	/*
> +	 * idea is that when operating ulpireset, regulator api will make
> +	 * sure that the hub+eth chip is powered, since it's the "parent"
> +	 */
> +	.supply_regulator = "vhub", /* we are a child of vhub */
> +	.constraints = {
> +		.name = "hsusb0",
> +		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
> +	},
> +};
>  
> -	usbhs_init(&usbhs_bdata);
> +static struct fixed_voltage_config panda_vulpireset = {
> +	.supply_name = "hsusb0",  /* this name is magic for hsusb driver */
> +	.microvolts = 3300000,
> +	.gpio = GPIO_HUB_NRESET,
> +	.startup_delay = 70000, /* 70msec */
> +	.enable_high = 1,
> +	.enabled_at_boot = 0,
> +	.init_data = &panda_ulpireset,
> +};
>  
> -	/* enable power to hub */
> -	gpio_set_value(GPIO_HUB_POWER, 1);
> -}
> +static struct platform_device omap_vulpireset_device = {
> +	.name		= "reg-fixed-voltage",
> +	.id		= 3,
> +	.dev = {
> +		.platform_data = &panda_vulpireset,
> +	},
> +};
>  
>  static struct omap_musb_board_data musb_board_data = {
>  	.interface_type		= MUSB_INTERFACE_UTMI,
> @@ -496,10 +532,12 @@ static void __init omap4_panda_init(void)
>  	omap4_panda_i2c_init();
>  	platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
>  	platform_device_register(&omap_vwlan_device);
> +	platform_device_register(&omap_vhub_device);
> +	platform_device_register(&omap_vulpireset_device);
>  	omap_serial_init();
>  	omap_sdrc_init(NULL, NULL);
>  	omap4_twl6030_hsmmc_init(mmc);
> -	omap4_ehci_init();
> +	usbhs_init(&usbhs_bdata);
>  	usb_musb_init(&musb_board_data);
>  	omap4_panda_display_init();
>  }
> -- 
> 1.7.4.1
> 

-- 
balbi

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Alan Stern]

On Wed, 21 Nov 2012, Felipe Balbi wrote:

> On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
> > From: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > 
> > This patch changes the management of the two GPIO for
> > "hub reset" (actually controls enable of ULPI PHY and hub reset) and
> > "hub power" (controls power to hub + eth).
> 
> looks like this should be done by the hub driver. Alan, what would you
> say ? Should the hub driver know how to power itself up ?

Not knowing the context, I'm a little confused.  What is this hub 
you're talking about?  Is it a separate USB hub incorporated into the 
IP (like Intel's "rate-matching" hubs in their later chipsets)?  Or is 
it the root hub?

Under what circumstances would the hub not be powered (i.e., when is it
not in use)?  If it isn't powered, can it be suspended?  Or enumerated?

Is this the sort of thing that should be handled by a PM domain?

As much as possible, the hub driver tries to ignore the differences
between root hubs and non-root hubs.  So for example, all hubs have to
be told to turn on VBUS power to their ports; therefore the hub driver
tells them.  But external hubs are either self-powered or bus-powered;
there's no need and no way for the hub driver to turn the hub power on
or off.  Therefore it doesn't try, not even for root hubs.

Alan Stern

--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Roger Quadros]

On 11/21/2012 04:52 PM, Alan Stern wrote:
> On Wed, 21 Nov 2012, Felipe Balbi wrote:
> 
>> On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
>>> From: Andy Green <andy.green@linaro.org>
>>>
>>> This patch changes the management of the two GPIO for
>>> "hub reset" (actually controls enable of ULPI PHY and hub reset) and
>>> "hub power" (controls power to hub + eth).
>>
>> looks like this should be done by the hub driver. Alan, what would you
>> say ? Should the hub driver know how to power itself up ?
> 
> Not knowing the context, I'm a little confused.  What is this hub 
> you're talking about?  Is it a separate USB hub incorporated into the 
> IP (like Intel's "rate-matching" hubs in their later chipsets)?  Or is 
> it the root hub?
> 

This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard
wired on the panda board with its Power and Reset pins controlled by 2
GPIOs from the OMAP SoC.

When powered, this chip can consume significant power (~0.7 W) because
of the (integrated Ethernet even when suspended. I suppose the ethernet
driver SMSC95XX) doesn't put it into a low enough power state on suspend.

It doesn't make sense to power the chip when USB is not required on the
whole (e.g. ehci_hcd module is not loaded). This is what this patch is
trying to fix.

cheers,
-roger

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Alan Stern]

On Wed, 21 Nov 2012, Roger Quadros wrote:

> On 11/21/2012 04:52 PM, Alan Stern wrote:
> > On Wed, 21 Nov 2012, Felipe Balbi wrote:
> > 
> >> On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
> >>> From: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>>
> >>> This patch changes the management of the two GPIO for
> >>> "hub reset" (actually controls enable of ULPI PHY and hub reset) and
> >>> "hub power" (controls power to hub + eth).
> >>
> >> looks like this should be done by the hub driver. Alan, what would you
> >> say ? Should the hub driver know how to power itself up ?
> > 
> > Not knowing the context, I'm a little confused.  What is this hub 
> > you're talking about?  Is it a separate USB hub incorporated into the 
> > IP (like Intel's "rate-matching" hubs in their later chipsets)?  Or is 
> > it the root hub?
> > 
> 
> This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard
> wired on the panda board with its Power and Reset pins controlled by 2
> GPIOs from the OMAP SoC.
> 
> When powered, this chip can consume significant power (~0.7 W) because
> of the (integrated Ethernet even when suspended. I suppose the ethernet
> driver SMSC95XX) doesn't put it into a low enough power state on suspend.
> 
> It doesn't make sense to power the chip when USB is not required on the
> whole (e.g. ehci_hcd module is not loaded). This is what this patch is
> trying to fix.

Ah, okay.  Then yes, assuming you want to power this chip only when 
either ehci-hcd or the ethernet driver is loaded, the right places 
to manage the power GPIO are in the init and exit routines of the two 
drivers.

Alan Stern


--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Roger Quadros]

On 11/21/2012 05:32 PM, Alan Stern wrote:
> On Wed, 21 Nov 2012, Roger Quadros wrote:
> 
>> On 11/21/2012 04:52 PM, Alan Stern wrote:
>>> On Wed, 21 Nov 2012, Felipe Balbi wrote:
>>>
>>>> On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
>>>>> From: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>>
>>>>> This patch changes the management of the two GPIO for
>>>>> "hub reset" (actually controls enable of ULPI PHY and hub reset) and
>>>>> "hub power" (controls power to hub + eth).
>>>>
>>>> looks like this should be done by the hub driver. Alan, what would you
>>>> say ? Should the hub driver know how to power itself up ?
>>>
>>> Not knowing the context, I'm a little confused.  What is this hub 
>>> you're talking about?  Is it a separate USB hub incorporated into the 
>>> IP (like Intel's "rate-matching" hubs in their later chipsets)?  Or is 
>>> it the root hub?
>>>
>>
>> This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard
>> wired on the panda board with its Power and Reset pins controlled by 2
>> GPIOs from the OMAP SoC.
>>
>> When powered, this chip can consume significant power (~0.7 W) because
>> of the (integrated Ethernet even when suspended. I suppose the ethernet
>> driver SMSC95XX) doesn't put it into a low enough power state on suspend.
>>
>> It doesn't make sense to power the chip when USB is not required on the
>> whole (e.g. ehci_hcd module is not loaded). This is what this patch is
>> trying to fix.
> 
> Ah, okay.  Then yes, assuming you want to power this chip only when 
> either ehci-hcd or the ethernet driver is loaded, the right places 
> to manage the power GPIO are in the init and exit routines of the two 
> drivers.
> 

The Ethernet function actually connects over USB within the chip. So
managing the power only in the ehci-hcd driver should suffice.

cheers,
-roger
--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

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

Hi,

On Wed, Nov 21, 2012 at 06:07:57PM +0200, Roger Quadros wrote:
> On 11/21/2012 05:32 PM, Alan Stern wrote:
> > On Wed, 21 Nov 2012, Roger Quadros wrote:
> > 
> >> On 11/21/2012 04:52 PM, Alan Stern wrote:
> >>> On Wed, 21 Nov 2012, Felipe Balbi wrote:
> >>>
> >>>> On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
> >>>>> From: Andy Green <andy.green@linaro.org>
> >>>>>
> >>>>> This patch changes the management of the two GPIO for
> >>>>> "hub reset" (actually controls enable of ULPI PHY and hub reset) and
> >>>>> "hub power" (controls power to hub + eth).
> >>>>
> >>>> looks like this should be done by the hub driver. Alan, what would you
> >>>> say ? Should the hub driver know how to power itself up ?
> >>>
> >>> Not knowing the context, I'm a little confused.  What is this hub 
> >>> you're talking about?  Is it a separate USB hub incorporated into the 
> >>> IP (like Intel's "rate-matching" hubs in their later chipsets)?  Or is 
> >>> it the root hub?
> >>>
> >>
> >> This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard
> >> wired on the panda board with its Power and Reset pins controlled by 2
> >> GPIOs from the OMAP SoC.
> >>
> >> When powered, this chip can consume significant power (~0.7 W) because
> >> of the (integrated Ethernet even when suspended. I suppose the ethernet
> >> driver SMSC95XX) doesn't put it into a low enough power state on suspend.
> >>
> >> It doesn't make sense to power the chip when USB is not required on the
> >> whole (e.g. ehci_hcd module is not loaded). This is what this patch is
> >> trying to fix.
> > 
> > Ah, okay.  Then yes, assuming you want to power this chip only when 
> > either ehci-hcd or the ethernet driver is loaded, the right places 
> > to manage the power GPIO are in the init and exit routines of the two 
> > drivers.
> > 
> 
> The Ethernet function actually connects over USB within the chip. So
> managing the power only in the ehci-hcd driver should suffice.

the thing is that this could cause code duplication all over. LAN95xx is
a generic USB Hub + Ethernet combo on one of ports from SMSC. *Any*
platform could use it and could hook those power and reset pins to a
GPIO. If we handle this at ehci-omap level, we risk having to duplicate
the same piece of code for ehci-*.c

Since that's a hub driver anyway, I wonder if it would be better to play
with those gpios somewhere else ?!?

-- 
balbi

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Andy Green]

On 11/22/12 03:54, the mail apparently from Felipe Balbi included:
> Hi,
>
> On Wed, Nov 21, 2012 at 06:07:57PM +0200, Roger Quadros wrote:
>> On 11/21/2012 05:32 PM, Alan Stern wrote:
>>> On Wed, 21 Nov 2012, Roger Quadros wrote:
>>>
>>>> On 11/21/2012 04:52 PM, Alan Stern wrote:
>>>>> On Wed, 21 Nov 2012, Felipe Balbi wrote:
>>>>>
>>>>>> On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
>>>>>>> From: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>>>>
>>>>>>> This patch changes the management of the two GPIO for
>>>>>>> "hub reset" (actually controls enable of ULPI PHY and hub reset) and
>>>>>>> "hub power" (controls power to hub + eth).
>>>>>>
>>>>>> looks like this should be done by the hub driver. Alan, what would you
>>>>>> say ? Should the hub driver know how to power itself up ?
>>>>>
>>>>> Not knowing the context, I'm a little confused.  What is this hub
>>>>> you're talking about?  Is it a separate USB hub incorporated into the
>>>>> IP (like Intel's "rate-matching" hubs in their later chipsets)?  Or is
>>>>> it the root hub?
>>>>>
>>>>
>>>> This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard
>>>> wired on the panda board with its Power and Reset pins controlled by 2
>>>> GPIOs from the OMAP SoC.
>>>>
>>>> When powered, this chip can consume significant power (~0.7 W) because
>>>> of the (integrated Ethernet even when suspended. I suppose the ethernet
>>>> driver SMSC95XX) doesn't put it into a low enough power state on suspend.
>>>>
>>>> It doesn't make sense to power the chip when USB is not required on the
>>>> whole (e.g. ehci_hcd module is not loaded). This is what this patch is
>>>> trying to fix.
>>>
>>> Ah, okay.  Then yes, assuming you want to power this chip only when
>>> either ehci-hcd or the ethernet driver is loaded, the right places
>>> to manage the power GPIO are in the init and exit routines of the two
>>> drivers.
>>>
>>
>> The Ethernet function actually connects over USB within the chip. So
>> managing the power only in the ehci-hcd driver should suffice.
>
> the thing is that this could cause code duplication all over. LAN95xx is

I can see this point.  However DT will soak up these regulator 
definitions, at that point it's "for free".  On Linaro tilt-3.4 we 
already have this on the dts

	hubpower: fixedregulator@0 {
			compatible = "regulator-fixed";
			regulator-name = "vhub0";
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			gpio = <&gpio1 1 0>;		/* gpio 1 : HUB Power */
			startup-delay-us = <70000>;
			enable-active-high;
	};

	hubreset: fixedregulator@1 {
			compatible = "regulator-fixed";
			regulator-name = "hsusb0";	/* tag to associate with PORT 1 */
			regulator-min-microvolt = <3300000>;
			regulator-max-microvolt = <3300000>;
			gpio = <&gpio2 30 0>;	/* gpio 62 : HUB & PHY Reset */
			startup-delay-us = <70000>;
			enable-active-high;
			vin-supply = "vhub0"; /* Makes regulator f/w enable power before reset */
	};

which is the equivalent to my patch: I don't think we need to sweat 
about code duplication.

> a generic USB Hub + Ethernet combo on one of ports from SMSC. *Any*
> platform could use it and could hook those power and reset pins to a
> GPIO. If we handle this at ehci-omap level, we risk having to duplicate
> the same piece of code for ehci-*.c

We need to consider power and reset separately.  Reset is a safe bet as 
a GPIO but power to the smsc chip is not.

On panda they happen to fit a gpio-controlled linear regulator to 
provide the smsc 3.3V supply.  On another device that can just as easily 
be a PMIC regulator channel: it boils down to controlling a power rail. 
  So using struct regulator as the abstraction for the power is the 
right way already.

> Since that's a hub driver anyway, I wonder if it would be better to play
> with those gpios somewhere else ?!?

The patch creates a regulator that binds to a magic regulator name 
defined by the hsusb driver, "hsusb0".

That regulator is taken up and down by hsusb driver with the lifecycle 
of the logical hsusb device.  So inserting ehci-hcd module powers the 
regulator until the module is removed.

Originally I bound the regulator to the smsc95xx driver, which also 
offers a struct regulator.  But there is a quirk on Panda that means 
that is not workable.

On Panda, they share one SoC gpio to reset both an external ULPI PHY 
chip and the smsc95xx that is downstream of it.

After you power up the smsc95xx, you must reset it in order for correct 
operation.  This actually resets the ULPI PHY too.

The ULPI PHY is permanently powered, only nRESET is provided to control it.

For that reason, as an attribute of being on a Panda board, we need to 
do the (shared) reset meddling once at hsusb init, and that is why the 
patch is as it is.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

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

Hi,

On Thu, Nov 22, 2012 at 09:13:16AM +0800, Andy Green wrote:
> On 11/22/12 03:54, the mail apparently from Felipe Balbi included:
> >Hi,
> >
> >On Wed, Nov 21, 2012 at 06:07:57PM +0200, Roger Quadros wrote:
> >>On 11/21/2012 05:32 PM, Alan Stern wrote:
> >>>On Wed, 21 Nov 2012, Roger Quadros wrote:
> >>>
> >>>>On 11/21/2012 04:52 PM, Alan Stern wrote:
> >>>>>On Wed, 21 Nov 2012, Felipe Balbi wrote:
> >>>>>
> >>>>>>On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
> >>>>>>>From: Andy Green <andy.green@linaro.org>
> >>>>>>>
> >>>>>>>This patch changes the management of the two GPIO for
> >>>>>>>"hub reset" (actually controls enable of ULPI PHY and hub reset) and
> >>>>>>>"hub power" (controls power to hub + eth).
> >>>>>>
> >>>>>>looks like this should be done by the hub driver. Alan, what would you
> >>>>>>say ? Should the hub driver know how to power itself up ?
> >>>>>
> >>>>>Not knowing the context, I'm a little confused.  What is this hub
> >>>>>you're talking about?  Is it a separate USB hub incorporated into the
> >>>>>IP (like Intel's "rate-matching" hubs in their later chipsets)?  Or is
> >>>>>it the root hub?
> >>>>>
> >>>>
> >>>>This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard
> >>>>wired on the panda board with its Power and Reset pins controlled by 2
> >>>>GPIOs from the OMAP SoC.
> >>>>
> >>>>When powered, this chip can consume significant power (~0.7 W) because
> >>>>of the (integrated Ethernet even when suspended. I suppose the ethernet
> >>>>driver SMSC95XX) doesn't put it into a low enough power state on suspend.
> >>>>
> >>>>It doesn't make sense to power the chip when USB is not required on the
> >>>>whole (e.g. ehci_hcd module is not loaded). This is what this patch is
> >>>>trying to fix.
> >>>
> >>>Ah, okay.  Then yes, assuming you want to power this chip only when
> >>>either ehci-hcd or the ethernet driver is loaded, the right places
> >>>to manage the power GPIO are in the init and exit routines of the two
> >>>drivers.
> >>>
> >>
> >>The Ethernet function actually connects over USB within the chip. So
> >>managing the power only in the ehci-hcd driver should suffice.
> >
> >the thing is that this could cause code duplication all over. LAN95xx is
> 
> I can see this point.  However DT will soak up these regulator
> definitions, at that point it's "for free".  On Linaro tilt-3.4 we
> already have this on the dts
> 
> 	hubpower: fixedregulator@0 {
> 			compatible = "regulator-fixed";
> 			regulator-name = "vhub0";
> 			regulator-min-microvolt = <3300000>;
> 			regulator-max-microvolt = <3300000>;
> 			gpio = <&gpio1 1 0>;		/* gpio 1 : HUB Power */
> 			startup-delay-us = <70000>;
> 			enable-active-high;
> 	};
> 
> 	hubreset: fixedregulator@1 {
> 			compatible = "regulator-fixed";
> 			regulator-name = "hsusb0";	/* tag to associate with PORT 1 */
> 			regulator-min-microvolt = <3300000>;
> 			regulator-max-microvolt = <3300000>;
> 			gpio = <&gpio2 30 0>;	/* gpio 62 : HUB & PHY Reset */
> 			startup-delay-us = <70000>;
> 			enable-active-high;
> 			vin-supply = "vhub0"; /* Makes regulator f/w enable power before reset */
> 	};
> 
> which is the equivalent to my patch: I don't think we need to sweat
> about code duplication.

why not ? Just because you have some ready DT files outside of the
mailine kernel ? Sorry, not a good argument.

> >a generic USB Hub + Ethernet combo on one of ports from SMSC. *Any*
> >platform could use it and could hook those power and reset pins to a
> >GPIO. If we handle this at ehci-omap level, we risk having to duplicate
> >the same piece of code for ehci-*.c
> 
> We need to consider power and reset separately.  Reset is a safe bet
> as a GPIO but power to the smsc chip is not.

so ? I'm saying that it *can* be attached to other architectures and
they *can* decide to put both on GPIOs. I'm not considering the
likelyhood of the situation.

> On panda they happen to fit a gpio-controlled linear regulator to
> provide the smsc 3.3V supply.  On another device that can just as

good to know, then we need a regulator driver (as you added on your DT
file the bindings for it) instead of poking into the GPIO directly.

Again it sounds like something that should be done at the hub driver
level. I mean using the GPIO (for reset) and Power Regulator.

not implementing the regulator part itself, but using it.

> easily be a PMIC regulator channel: it boils down to controlling a
> power rail.  So using struct regulator as the abstraction for the
> power is the right way already.

I agree with you here. Nevertheless, I'm arguing that this all should be
handled by the hub driver, not ehci-omap.

> >Since that's a hub driver anyway, I wonder if it would be better to play
> >with those gpios somewhere else ?!?
> 
> The patch creates a regulator that binds to a magic regulator name
> defined by the hsusb driver, "hsusb0".
> 
> That regulator is taken up and down by hsusb driver with the
> lifecycle of the logical hsusb device.  So inserting ehci-hcd module
> powers the regulator until the module is removed.

but this is wrong. What if we use a different HUB part, what if the same
HUB part is used in e.g. Tegra-based platform ?

This is why I say it's *wrong* to handle that at the OMAP USB Host part.
This is why I'm arguing that this whole thing should be handled by the
hub driver itself.

> Originally I bound the regulator to the smsc95xx driver, which also

that's wrong too. You can't assume that the network part of the device
knows when the USB part needs to be powered up. That's just plain wrong.

> offers a struct regulator.  But there is a quirk on Panda that means
> that is not workable.
> 
> On Panda, they share one SoC gpio to reset both an external ULPI PHY
> chip and the smsc95xx that is downstream of it.

of course. the Network part is attached to one of the Hub ports, that's
why the hub exposes only two ports.

> After you power up the smsc95xx, you must reset it in order for
> correct operation.  This actually resets the ULPI PHY too.
> 
> The ULPI PHY is permanently powered, only nRESET is provided to
> control it.
> 
> For that reason, as an attribute of being on a Panda board, we need
> to do the (shared) reset meddling once at hsusb init, and that is why
> the patch is as it is.

yeah, yeah, but it's not correct to push all that code is the OMAP USB
Part when the hub driver is the only one who knows when the hub is going
to be reset and the like.

You're poking into a HUB, not into the EHCI controller.

-- 
balbi

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Andy Green]

On 11/22/12 20:21, the mail apparently from Felipe Balbi included:
> Hi,
>
> On Thu, Nov 22, 2012 at 09:13:16AM +0800, Andy Green wrote:
>> On 11/22/12 03:54, the mail apparently from Felipe Balbi included:
>>> Hi,
>>>
>>> On Wed, Nov 21, 2012 at 06:07:57PM +0200, Roger Quadros wrote:
>>>> On 11/21/2012 05:32 PM, Alan Stern wrote:
>>>>> On Wed, 21 Nov 2012, Roger Quadros wrote:
>>>>>
>>>>>> On 11/21/2012 04:52 PM, Alan Stern wrote:
>>>>>>> On Wed, 21 Nov 2012, Felipe Balbi wrote:
>>>>>>>
>>>>>>>> On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
>>>>>>>>> From: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>>>>>>
>>>>>>>>> This patch changes the management of the two GPIO for
>>>>>>>>> "hub reset" (actually controls enable of ULPI PHY and hub reset) and
>>>>>>>>> "hub power" (controls power to hub + eth).
>>>>>>>>
>>>>>>>> looks like this should be done by the hub driver. Alan, what would you
>>>>>>>> say ? Should the hub driver know how to power itself up ?
>>>>>>>
>>>>>>> Not knowing the context, I'm a little confused.  What is this hub
>>>>>>> you're talking about?  Is it a separate USB hub incorporated into the
>>>>>>> IP (like Intel's "rate-matching" hubs in their later chipsets)?  Or is
>>>>>>> it the root hub?
>>>>>>>
>>>>>>
>>>>>> This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard
>>>>>> wired on the panda board with its Power and Reset pins controlled by 2
>>>>>> GPIOs from the OMAP SoC.
>>>>>>
>>>>>> When powered, this chip can consume significant power (~0.7 W) because
>>>>>> of the (integrated Ethernet even when suspended. I suppose the ethernet
>>>>>> driver SMSC95XX) doesn't put it into a low enough power state on suspend.
>>>>>>
>>>>>> It doesn't make sense to power the chip when USB is not required on the
>>>>>> whole (e.g. ehci_hcd module is not loaded). This is what this patch is
>>>>>> trying to fix.
>>>>>
>>>>> Ah, okay.  Then yes, assuming you want to power this chip only when
>>>>> either ehci-hcd or the ethernet driver is loaded, the right places
>>>>> to manage the power GPIO are in the init and exit routines of the two
>>>>> drivers.
>>>>>
>>>>
>>>> The Ethernet function actually connects over USB within the chip. So
>>>> managing the power only in the ehci-hcd driver should suffice.
>>>
>>> the thing is that this could cause code duplication all over. LAN95xx is
>>
>> I can see this point.  However DT will soak up these regulator
>> definitions, at that point it's "for free".  On Linaro tilt-3.4 we
>> already have this on the dts
>>
>> 	hubpower: fixedregulator@0 {
>> 			compatible = "regulator-fixed";
>> 			regulator-name = "vhub0";
>> 			regulator-min-microvolt = <3300000>;
>> 			regulator-max-microvolt = <3300000>;
>> 			gpio = <&gpio1 1 0>;		/* gpio 1 : HUB Power */
>> 			startup-delay-us = <70000>;
>> 			enable-active-high;
>> 	};
>>
>> 	hubreset: fixedregulator@1 {
>> 			compatible = "regulator-fixed";
>> 			regulator-name = "hsusb0";	/* tag to associate with PORT 1 */
>> 			regulator-min-microvolt = <3300000>;
>> 			regulator-max-microvolt = <3300000>;
>> 			gpio = <&gpio2 30 0>;	/* gpio 62 : HUB & PHY Reset */
>> 			startup-delay-us = <70000>;
>> 			enable-active-high;
>> 			vin-supply = "vhub0"; /* Makes regulator f/w enable power before reset */
>> 	};
>>
>> which is the equivalent to my patch: I don't think we need to sweat
>> about code duplication.
>
> why not ? Just because you have some ready DT files outside of the
> mailine kernel ? Sorry, not a good argument.

That's not my argument: it's the whole basis for bothering with DT, but 
never mind.

>>> a generic USB Hub + Ethernet combo on one of ports from SMSC. *Any*
>>> platform could use it and could hook those power and reset pins to a
>>> GPIO. If we handle this at ehci-omap level, we risk having to duplicate
>>> the same piece of code for ehci-*.c
>>
>> We need to consider power and reset separately.  Reset is a safe bet
>> as a GPIO but power to the smsc chip is not.
>
> so ? I'm saying that it *can* be attached to other architectures and
> they *can* decide to put both on GPIOs. I'm not considering the
> likelyhood of the situation.

There's some confusion here --->

>> On panda they happen to fit a gpio-controlled linear regulator to
>> provide the smsc 3.3V supply.  On another device that can just as
>
> good to know, then we need a regulator driver (as you added on your DT
> file the bindings for it) instead of poking into the GPIO directly.

Assuming you mean "regulator device", if you look at the patch, that is 
what it does.

The original board file code just sets the GPIO as a one-off and forgets 
about it, so the whole show is permanently powered, which is 
objectionable since ~50% of Panda idle power is burned on that.

My patch uses regulator definitions in the board file - I only touch the 
board file - to allow the omap ehci driver to control the power.

> Again it sounds like something that should be done at the hub driver
> level. I mean using the GPIO (for reset) and Power Regulator.
>
> not implementing the regulator part itself, but using it.

If you mean change the regulator managing code from living in omap-hsusb 
to ehci-hcd, it sounds like a good idea.

>> easily be a PMIC regulator channel: it boils down to controlling a
>> power rail.  So using struct regulator as the abstraction for the
>> power is the right way already.
>
> I agree with you here. Nevertheless, I'm arguing that this all should be
> handled by the hub driver, not ehci-omap.

If "hub driver" means ehci-hcd then I agree, why not let all the ehci 
platforms have the same regulator management option instead of just OMAP.

>>> Since that's a hub driver anyway, I wonder if it would be better to play
>>> with those gpios somewhere else ?!?
>>
>> The patch creates a regulator that binds to a magic regulator name
>> defined by the hsusb driver, "hsusb0".
>>
>> That regulator is taken up and down by hsusb driver with the
>> lifecycle of the logical hsusb device.  So inserting ehci-hcd module
>> powers the regulator until the module is removed.
>
> but this is wrong. What if we use a different HUB part, what if the same
> HUB part is used in e.g. Tegra-based platform ?
>
> This is why I say it's *wrong* to handle that at the OMAP USB Host part.
> This is why I'm arguing that this whole thing should be handled by the
> hub driver itself.

Yes if we mean ehci-hcd manages the regulator, it will be better.  AFAIK 
it doesn't right now and the omap bit does, so my patch used what exists 
and works.

>> Originally I bound the regulator to the smsc95xx driver, which also
>
> that's wrong too. You can't assume that the network part of the device
> knows when the USB part needs to be powered up. That's just plain wrong.

 From the POV of the original goal of the patch, it was just to give us 
a way to control static power consumption by modprobe.  It would work 
fine to do that by modprobe [-r] smsc95xx same as ehci-hcd actually, 
although I agree it's backward from usual discover -> udev -> modprobe 
POV.  Anyway that is not what we ended up with so no need to worry about it.

>> offers a struct regulator.  But there is a quirk on Panda that means
>> that is not workable.
>>
>> On Panda, they share one SoC gpio to reset both an external ULPI PHY
>> chip and the smsc95xx that is downstream of it.
>
> of course. the Network part is attached to one of the Hub ports, that's
> why the hub exposes only two ports.

I am not sure how that makes it an "of course".  It's not like there's a 
shortage of SoC gpio to separate them and allow cleaner software.  But 
never mind that either.

>> After you power up the smsc95xx, you must reset it in order for
>> correct operation.  This actually resets the ULPI PHY too.
>>
>> The ULPI PHY is permanently powered, only nRESET is provided to
>> control it.
>>
>> For that reason, as an attribute of being on a Panda board, we need
>> to do the (shared) reset meddling once at hsusb init, and that is why
>> the patch is as it is.
>
> yeah, yeah, but it's not correct to push all that code is the OMAP USB
> Part when the hub driver is the only one who knows when the hub is going
> to be reset and the like.
>
> You're poking into a HUB, not into the EHCI controller.

My patch is just using what's there at the moment.  It only touches the 
board file and does not "push all that code is the OMAP USB part".

I agree with you what's in the OMAP USB part is better in the generic 
part, but I didn't put it there.

If you want that moved and nobody else wants to do it, I can probably do 
that in a new, additional patch.  If so you might want to confirm you're 
OK with the magic naming convention for regulators or (as Roger 
suggested earlier) pass it in by platform_data.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

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

Hi,

On Thu, Nov 22, 2012 at 09:49:05PM +0800, Andy Green wrote:
> >Again it sounds like something that should be done at the hub driver
> >level. I mean using the GPIO (for reset) and Power Regulator.
> >
> >not implementing the regulator part itself, but using it.
> 
> If you mean change the regulator managing code from living in
> omap-hsusb to ehci-hcd, it sounds like a good idea.

I mean that drivers/usb/core/hub.c should manage it, since that's what
actually manages the HUB entity.

> >>easily be a PMIC regulator channel: it boils down to controlling a
> >>power rail.  So using struct regulator as the abstraction for the
> >>power is the right way already.
> >
> >I agree with you here. Nevertheless, I'm arguing that this all should be
> >handled by the hub driver, not ehci-omap.
> 
> If "hub driver" means ehci-hcd then I agree, why not let all the ehci
> platforms have the same regulator management option instead of just
> OMAP.

the reasoning is in alignment with mine, but the "target driver" is
wrong :-)

> From the POV of the original goal of the patch, it was just to give
> us a way to control static power consumption by modprobe.  It would
> work fine to do that by modprobe [-r] smsc95xx same as ehci-hcd
> actually, although I agree it's backward from usual discover -> udev
> -> modprobe POV.  Anyway that is not what we ended up with so no need
> to worry about it.

fair enough, but I would only accept $SUBJECT if in the same series came
the patch moving the code to the right place, otherwise things such as
those never get done because other tasks are prioritized over a "simple
cleanup".

> >>offers a struct regulator.  But there is a quirk on Panda that means
> >>that is not workable.
> >>
> >>On Panda, they share one SoC gpio to reset both an external ULPI PHY
> >>chip and the smsc95xx that is downstream of it.
> >
> >of course. the Network part is attached to one of the Hub ports, that's
> >why the hub exposes only two ports.
> 
> I am not sure how that makes it an "of course".  It's not like
> there's a shortage of SoC gpio to separate them and allow cleaner
> software.  But never mind that either.

fair enough ;-)

> >>After you power up the smsc95xx, you must reset it in order for
> >>correct operation.  This actually resets the ULPI PHY too.
> >>
> >>The ULPI PHY is permanently powered, only nRESET is provided to
> >>control it.
> >>
> >>For that reason, as an attribute of being on a Panda board, we need
> >>to do the (shared) reset meddling once at hsusb init, and that is why
> >>the patch is as it is.
> >
> >yeah, yeah, but it's not correct to push all that code is the OMAP USB
> >Part when the hub driver is the only one who knows when the hub is going
> >to be reset and the like.
> >
> >You're poking into a HUB, not into the EHCI controller.
> 
> My patch is just using what's there at the moment.  It only touches
> the board file and does not "push all that code is the OMAP USB
> part".
> 
> I agree with you what's in the OMAP USB part is better in the generic
> part, but I didn't put it there.

not saying you did, merely checking if Alan would be ok with that code
living in the hub driver, and if he would, I'd ask you or Roger to move
the to it's proper location ;-)

> If you want that moved and nobody else wants to do it, I can probably
> do that in a new, additional patch.  If so you might want to confirm

as long as Alan is ok and it comes in the same series, I'd be really,
really glad to see such a patch and would happily review it.

> you're OK with the magic naming convention for regulators or (as
> Roger suggested earlier) pass it in by platform_data.

I'm not sure if regulator names should be passed via platform_data. I
think Mark Brown would get quite upset if we did such a thing, but I
could be wrong.

-- 
balbi

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Roger Quadros]

On 11/22/2012 03:56 PM, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Nov 22, 2012 at 09:49:05PM +0800, Andy Green wrote:
>>> Again it sounds like something that should be done at the hub driver
>>> level. I mean using the GPIO (for reset) and Power Regulator.
>>>
>>> not implementing the regulator part itself, but using it.
>>
>> If you mean change the regulator managing code from living in
>> omap-hsusb to ehci-hcd, it sounds like a good idea.
> 
> I mean that drivers/usb/core/hub.c should manage it, since that's what
> actually manages the HUB entity.

Yes. I agree that powering up the on-board hubs should be done
generically and not in ehci-omap.c. I'm not sure how it can be done in
hub.c.

I'm assuming that such problem is limited to root hub ports where system
designers have the flexibility to provide power to the peripherals
outside the USB Hub specification.

I can think of two solutions

1) Associate the regulators with the root hub _ports_ and enable them as
part of port's power-up routine.

2) Have a global list of regulators that are registered by platform code
and enabled them all at once on hcd init.

Any clues on how (1) could be implemented?

--
cheers,
-roger

--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

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

Hi,

On Thu, Nov 22, 2012 at 05:00:45PM +0200, Roger Quadros wrote:
> On 11/22/2012 03:56 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Nov 22, 2012 at 09:49:05PM +0800, Andy Green wrote:
> >>> Again it sounds like something that should be done at the hub driver
> >>> level. I mean using the GPIO (for reset) and Power Regulator.
> >>>
> >>> not implementing the regulator part itself, but using it.
> >>
> >> If you mean change the regulator managing code from living in
> >> omap-hsusb to ehci-hcd, it sounds like a good idea.
> > 
> > I mean that drivers/usb/core/hub.c should manage it, since that's what
> > actually manages the HUB entity.
> 
> Yes. I agree that powering up the on-board hubs should be done
> generically and not in ehci-omap.c. I'm not sure how it can be done in
> hub.c.
> 
> I'm assuming that such problem is limited to root hub ports where system

an external LAN95xx HUB is not the roothub. LAN95xx is connected to the
roothub.

> designers have the flexibility to provide power to the peripherals
> outside the USB Hub specification.
> 
> I can think of two solutions
> 
> 1) Associate the regulators with the root hub _ports_ and enable them as
> part of port's power-up routine.

doesn't make sense. We need to figure out a way to attach the regulator
to the ports which actually have them. In this case it's the external
LAN95xx, right ?

> 2) Have a global list of regulators that are registered by platform code
> and enabled them all at once on hcd init.

also wrong as it might cause increased power consumption even when only
a single USB port is currently in use.

The patch below is *CLEARLY WRONG* it's just to illustrate how this
could be started:

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1af04bd..662d4cf 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,7 @@
 #include <linux/mutex.h>
 #include <linux/freezer.h>
 #include <linux/random.h>
+#include <linux/regulator/consumer.h>
 
 #include <asm/uaccess.h>
 #include <asm/byteorder.h>
@@ -44,6 +45,7 @@ struct usb_port {
 	struct device dev;
 	struct dev_state *port_owner;
 	enum usb_port_connect_type connect_type;
+	struct regulator *port_regulator;
 };
 
 struct usb_hub {
@@ -847,8 +849,41 @@ static unsigned hub_power_on(struct usb_hub *hub, bool do_delay)
 	else
 		dev_dbg(hub->intfdev, "trying to enable port power on "
 				"non-switchable hub\n");
-	for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++)
+	for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++) {
+		regulator_enable(hub->ports[port1]->port_regulator);
 		set_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
+	}
+
+	/* Wait at least 100 msec for power to become stable */
+	delay = max(pgood_delay, (unsigned) 100);
+	if (do_delay)
+		msleep(delay);
+	return delay;
+}
+
+static unsigned hub_power_off(struct usb_hub *hub, bool do_delay)
+{
+	int port1;
+	unsigned pgood_delay = hub->descriptor->bPwrOn2PwrGood * 2;
+	unsigned delay;
+	u16 wHubCharacteristics =
+			le16_to_cpu(hub->descriptor->wHubCharacteristics);
+
+	/* Disable power on each port.  Some hubs have reserved values
+	 * of LPSM (> 2) in their descriptors, even though they are
+	 * USB 2.0 hubs.  Some hubs do not implement port-power switching
+	 * but only emulate it.  In all cases, the ports won't work
+	 * unless we send these messages to the hub.
+	 */
+	if ((wHubCharacteristics & HUB_CHAR_LPSM) < 2)
+		dev_dbg(hub->intfdev, "disabling power on all ports\n");
+	else
+		dev_dbg(hub->intfdev, "trying to disable port power on "
+				"non-switchable hub\n");
+	for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++) {
+		regulator_disable(hub->ports[port1]->port_regulator);
+		clear_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
+	}
 
 	/* Wait at least 100 msec for power to become stable */
 	delay = max(pgood_delay, (unsigned) 100);
@@ -1336,6 +1371,9 @@ static int hub_configure(struct usb_hub *hub,
 		goto fail;
 	}
 
+	if (hub->has_external_port_regulator) /* maybe implement with a quirk flag ??? */
+		regulator_get(hub_dev, "hub_port_supply\n");
+
 	wHubCharacteristics = le16_to_cpu(hub->descriptor->wHubCharacteristics);
 
 	/* FIXME for USB 3.0, skip for now */
@@ -4205,8 +4243,10 @@ static void hub_port_connect_change(struct usb_hub *hub, int port1,
 
 		/* maybe switch power back on (e.g. root hub was reset) */
 		if ((wHubCharacteristics & HUB_CHAR_LPSM) < 2
-				&& !port_is_power_on(hub, portstatus))
+				&& !port_is_power_on(hub, portstatus)) {
+			regulator_enable(hub->ports[port1]->port_regulator);
 			set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
+		}
 
 		if (portstatus & USB_PORT_STAT_ENABLE)
   			goto done;

Note that if we have a single regulator, than all ports' regulators
should point to the same struct regulator so that regulator_get() and
regulator_put() can do proper reference counting.

This is just an idea though.

-- 
balbi

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Roger Quadros]

On 11/22/2012 06:12 PM, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Nov 22, 2012 at 05:00:45PM +0200, Roger Quadros wrote:
>> On 11/22/2012 03:56 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Thu, Nov 22, 2012 at 09:49:05PM +0800, Andy Green wrote:
>>>>> Again it sounds like something that should be done at the hub driver
>>>>> level. I mean using the GPIO (for reset) and Power Regulator.
>>>>>
>>>>> not implementing the regulator part itself, but using it.
>>>>
>>>> If you mean change the regulator managing code from living in
>>>> omap-hsusb to ehci-hcd, it sounds like a good idea.
>>>
>>> I mean that drivers/usb/core/hub.c should manage it, since that's what
>>> actually manages the HUB entity.
>>
>> Yes. I agree that powering up the on-board hubs should be done
>> generically and not in ehci-omap.c. I'm not sure how it can be done in
>> hub.c.
>>
>> I'm assuming that such problem is limited to root hub ports where system
> 
> an external LAN95xx HUB is not the roothub. LAN95xx is connected to the
> roothub.
> 

I didn't say LAN95xx is the root hub. It is connected to the root hub.
So it is in theory, the root hub port's responsibility to power the LAN95xx.

>> designers have the flexibility to provide power to the peripherals
>> outside the USB Hub specification.
>>
>> I can think of two solutions
>>
>> 1) Associate the regulators with the root hub _ports_ and enable them as
>> part of port's power-up routine.
> 
> doesn't make sense. We need to figure out a way to attach the regulator
> to the ports which actually have them. In this case it's the external
> LAN95xx, right ?

I think you are confused here. The LAN95xx's ports are compatible with
USB hub specification and they work using the in-band set_port_feature
mechanism already. We have a problem powering the LAN95xx itself which
ideally should have been powered with set_port_feature on the root hub.
(or ehci_port_power() in this case).

> 
>> 2) Have a global list of regulators that are registered by platform code
>> and enabled them all at once on hcd init.
> 
> also wrong as it might cause increased power consumption even when only
> a single USB port is currently in use.

Yes that is true. I'm not for (2) certainly.
> 
> The patch below is *CLEARLY WRONG* it's just to illustrate how this
> could be started:
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 1af04bd..662d4cf 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -26,6 +26,7 @@
>  #include <linux/mutex.h>
>  #include <linux/freezer.h>
>  #include <linux/random.h>
> +#include <linux/regulator/consumer.h>
>  
>  #include <asm/uaccess.h>
>  #include <asm/byteorder.h>
> @@ -44,6 +45,7 @@ struct usb_port {
>  	struct device dev;
>  	struct dev_state *port_owner;
>  	enum usb_port_connect_type connect_type;
> +	struct regulator *port_regulator;
>  };
>  
>  struct usb_hub {
> @@ -847,8 +849,41 @@ static unsigned hub_power_on(struct usb_hub *hub, bool do_delay)
>  	else
>  		dev_dbg(hub->intfdev, "trying to enable port power on "
>  				"non-switchable hub\n");
> -	for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++)
> +	for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++) {
> +		regulator_enable(hub->ports[port1]->port_regulator);
>  		set_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
> +	}
> +
> +	/* Wait at least 100 msec for power to become stable */
> +	delay = max(pgood_delay, (unsigned) 100);
> +	if (do_delay)
> +		msleep(delay);
> +	return delay;
> +}
> +
> +static unsigned hub_power_off(struct usb_hub *hub, bool do_delay)
> +{
> +	int port1;
> +	unsigned pgood_delay = hub->descriptor->bPwrOn2PwrGood * 2;
> +	unsigned delay;
> +	u16 wHubCharacteristics =
> +			le16_to_cpu(hub->descriptor->wHubCharacteristics);
> +
> +	/* Disable power on each port.  Some hubs have reserved values
> +	 * of LPSM (> 2) in their descriptors, even though they are
> +	 * USB 2.0 hubs.  Some hubs do not implement port-power switching
> +	 * but only emulate it.  In all cases, the ports won't work
> +	 * unless we send these messages to the hub.
> +	 */
> +	if ((wHubCharacteristics & HUB_CHAR_LPSM) < 2)
> +		dev_dbg(hub->intfdev, "disabling power on all ports\n");
> +	else
> +		dev_dbg(hub->intfdev, "trying to disable port power on "
> +				"non-switchable hub\n");
> +	for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++) {
> +		regulator_disable(hub->ports[port1]->port_regulator);
> +		clear_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
> +	}
>  
>  	/* Wait at least 100 msec for power to become stable */
>  	delay = max(pgood_delay, (unsigned) 100);
> @@ -1336,6 +1371,9 @@ static int hub_configure(struct usb_hub *hub,
>  		goto fail;
>  	}
>  
> +	if (hub->has_external_port_regulator) /* maybe implement with a quirk flag ??? */
> +		regulator_get(hub_dev, "hub_port_supply\n");
> +
>  	wHubCharacteristics = le16_to_cpu(hub->descriptor->wHubCharacteristics);
>  
>  	/* FIXME for USB 3.0, skip for now */
> @@ -4205,8 +4243,10 @@ static void hub_port_connect_change(struct usb_hub *hub, int port1,
>  
>  		/* maybe switch power back on (e.g. root hub was reset) */
>  		if ((wHubCharacteristics & HUB_CHAR_LPSM) < 2
> -				&& !port_is_power_on(hub, portstatus))
> +				&& !port_is_power_on(hub, portstatus)) {
> +			regulator_enable(hub->ports[port1]->port_regulator);
>  			set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
> +		}
>  
>  		if (portstatus & USB_PORT_STAT_ENABLE)
>    			goto done;
> 
> Note that if we have a single regulator, than all ports' regulators
> should point to the same struct regulator so that regulator_get() and
> regulator_put() can do proper reference counting.
> 
> This is just an idea though.
> 

Thanks for the example. The only problem is, how do we associate a
regulator to a specific port in the system.

cheers,
-roger
--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

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

On Fri, Nov 23, 2012 at 12:23:52PM +0200, Roger Quadros wrote:
> On 11/22/2012 06:12 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Nov 22, 2012 at 05:00:45PM +0200, Roger Quadros wrote:
> >> On 11/22/2012 03:56 PM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Thu, Nov 22, 2012 at 09:49:05PM +0800, Andy Green wrote:
> >>>>> Again it sounds like something that should be done at the hub driver
> >>>>> level. I mean using the GPIO (for reset) and Power Regulator.
> >>>>>
> >>>>> not implementing the regulator part itself, but using it.
> >>>>
> >>>> If you mean change the regulator managing code from living in
> >>>> omap-hsusb to ehci-hcd, it sounds like a good idea.
> >>>
> >>> I mean that drivers/usb/core/hub.c should manage it, since that's what
> >>> actually manages the HUB entity.
> >>
> >> Yes. I agree that powering up the on-board hubs should be done
> >> generically and not in ehci-omap.c. I'm not sure how it can be done in
> >> hub.c.
> >>
> >> I'm assuming that such problem is limited to root hub ports where system
> > 
> > an external LAN95xx HUB is not the roothub. LAN95xx is connected to the
> > roothub.
> > 
> 
> I didn't say LAN95xx is the root hub. It is connected to the root hub.
> So it is in theory, the root hub port's responsibility to power the LAN95xx.

no, it's LAN95xx's responsibility to power itself up. What if you had
multiple tiers of LAN95xx ?

> >> designers have the flexibility to provide power to the peripherals
> >> outside the USB Hub specification.
> >>
> >> I can think of two solutions
> >>
> >> 1) Associate the regulators with the root hub _ports_ and enable them as
> >> part of port's power-up routine.
> > 
> > doesn't make sense. We need to figure out a way to attach the regulator
> > to the ports which actually have them. In this case it's the external
> > LAN95xx, right ?
> 
> I think you are confused here. The LAN95xx's ports are compatible with
> USB hub specification and they work using the in-band set_port_feature
> mechanism already. We have a problem powering the LAN95xx itself which
> ideally should have been powered with set_port_feature on the root hub.
> (or ehci_port_power() in this case).

I don't set_port_feature() has anything to do with the problem here.
It's not working because the controller's supply isn't turned on. How
can any port be turned on if the supply isn't turned on ?

I still think, however, the hub needs to know how to power itself up.

> > The patch below is *CLEARLY WRONG* it's just to illustrate how this
> > could be started:
> > 
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index 1af04bd..662d4cf 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -26,6 +26,7 @@
> >  #include <linux/mutex.h>
> >  #include <linux/freezer.h>
> >  #include <linux/random.h>
> > +#include <linux/regulator/consumer.h>
> >  
> >  #include <asm/uaccess.h>
> >  #include <asm/byteorder.h>
> > @@ -44,6 +45,7 @@ struct usb_port {
> >  	struct device dev;
> >  	struct dev_state *port_owner;
> >  	enum usb_port_connect_type connect_type;
> > +	struct regulator *port_regulator;
> >  };
> >  
> >  struct usb_hub {
> > @@ -847,8 +849,41 @@ static unsigned hub_power_on(struct usb_hub *hub, bool do_delay)
> >  	else
> >  		dev_dbg(hub->intfdev, "trying to enable port power on "
> >  				"non-switchable hub\n");
> > -	for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++)
> > +	for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++) {
> > +		regulator_enable(hub->ports[port1]->port_regulator);
> >  		set_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
> > +	}
> > +
> > +	/* Wait at least 100 msec for power to become stable */
> > +	delay = max(pgood_delay, (unsigned) 100);
> > +	if (do_delay)
> > +		msleep(delay);
> > +	return delay;
> > +}
> > +
> > +static unsigned hub_power_off(struct usb_hub *hub, bool do_delay)
> > +{
> > +	int port1;
> > +	unsigned pgood_delay = hub->descriptor->bPwrOn2PwrGood * 2;
> > +	unsigned delay;
> > +	u16 wHubCharacteristics =
> > +			le16_to_cpu(hub->descriptor->wHubCharacteristics);
> > +
> > +	/* Disable power on each port.  Some hubs have reserved values
> > +	 * of LPSM (> 2) in their descriptors, even though they are
> > +	 * USB 2.0 hubs.  Some hubs do not implement port-power switching
> > +	 * but only emulate it.  In all cases, the ports won't work
> > +	 * unless we send these messages to the hub.
> > +	 */
> > +	if ((wHubCharacteristics & HUB_CHAR_LPSM) < 2)
> > +		dev_dbg(hub->intfdev, "disabling power on all ports\n");
> > +	else
> > +		dev_dbg(hub->intfdev, "trying to disable port power on "
> > +				"non-switchable hub\n");
> > +	for (port1 = 1; port1 <= hub->descriptor->bNbrPorts; port1++) {
> > +		regulator_disable(hub->ports[port1]->port_regulator);
> > +		clear_port_feature(hub->hdev, port1, USB_PORT_FEAT_POWER);
> > +	}
> >  
> >  	/* Wait at least 100 msec for power to become stable */
> >  	delay = max(pgood_delay, (unsigned) 100);
> > @@ -1336,6 +1371,9 @@ static int hub_configure(struct usb_hub *hub,
> >  		goto fail;
> >  	}
> >  
> > +	if (hub->has_external_port_regulator) /* maybe implement with a quirk flag ??? */
> > +		regulator_get(hub_dev, "hub_port_supply\n");
> > +
> >  	wHubCharacteristics = le16_to_cpu(hub->descriptor->wHubCharacteristics);
> >  
> >  	/* FIXME for USB 3.0, skip for now */
> > @@ -4205,8 +4243,10 @@ static void hub_port_connect_change(struct usb_hub *hub, int port1,
> >  
> >  		/* maybe switch power back on (e.g. root hub was reset) */
> >  		if ((wHubCharacteristics & HUB_CHAR_LPSM) < 2
> > -				&& !port_is_power_on(hub, portstatus))
> > +				&& !port_is_power_on(hub, portstatus)) {
> > +			regulator_enable(hub->ports[port1]->port_regulator);
> >  			set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
> > +		}
> >  
> >  		if (portstatus & USB_PORT_STAT_ENABLE)
> >    			goto done;
> > 
> > Note that if we have a single regulator, than all ports' regulators
> > should point to the same struct regulator so that regulator_get() and
> > regulator_put() can do proper reference counting.
> > 
> > This is just an idea though.
> > 
> 
> Thanks for the example. The only problem is, how do we associate a
> regulator to a specific port in the system.

heh, that's the 1 million dollar question, isn't it ? :-)

that's what we need to figure out now. Luckily we have Alan Stern
helping us out ;-)

-- 
balbi

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Alan Stern]

On Fri, 23 Nov 2012, Felipe Balbi wrote:

> > Thanks for the example. The only problem is, how do we associate a
> > regulator to a specific port in the system.
> 
> heh, that's the 1 million dollar question, isn't it ? :-)
> 
> that's what we need to figure out now. Luckily we have Alan Stern
> helping us out ;-)

Some people might think having me around to interfere was not so lucky
after all...  :-)

First question: Should we worry about individual ports?  Ordinarily I'd
say No, because hubs always power up all of their ports.  But with Lan
Tianyu's recent work, that won't be true any more.  In this case, it's
conceivable that the user might want to power-off the LAN95xx in order
to save energy, even though ehci-hcd is still loaded and managing other
USB devices.

Either way, the regulator has to be associated with _something_: either
a root-hub port or the host controller itself.  And this will most
likely have to be done before the port's or the controller's struct
device exists.

Something like Andy's scheme might work.  It would require the kernel
to parse name strings in various formats, which could get complicated.  
It would be great if the difficult parts could be stuck in the PM core
somewhere.

Alan Stern

--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Andy Green]

On 11/24/12 00:25, the mail apparently from Alan Stern included:
> On Fri, 23 Nov 2012, Felipe Balbi wrote:
>
>>> Thanks for the example. The only problem is, how do we associate a
>>> regulator to a specific port in the system.
>>
>> heh, that's the 1 million dollar question, isn't it ? :-)
>>
>> that's what we need to figure out now. Luckily we have Alan Stern
>> helping us out ;-)
>
> Some people might think having me around to interfere was not so lucky
> after all...  :-)
>
> First question: Should we worry about individual ports?  Ordinarily I'd
> say No, because hubs always power up all of their ports.  But with Lan
> Tianyu's recent work, that won't be true any more.  In this case, it's
> conceivable that the user might want to power-off the LAN95xx in order
> to save energy, even though ehci-hcd is still loaded and managing other
> USB devices.
>
> Either way, the regulator has to be associated with _something_: either
> a root-hub port or the host controller itself.  And this will most
> likely have to be done before the port's or the controller's struct
> device exists.
>
> Something like Andy's scheme might work.  It would require the kernel
> to parse name strings in various formats, which could get complicated.
> It would be great if the difficult parts could be stuck in the PM core
> somewhere.

If we're just looking at fixing the current "magic regulator name" 
scheme of "hsusb0" so that it can work with abstract devices like any 
hub / port, we could invert what my original "device path" scheme did.

So instead of having a parser (which boiled down quite small, but is 
complicated by usb%d being the same for different usb drivers), we could 
just add a helper function that walks the device parents to generate a 
string representing the device instance.  Like

int device_path_generate(struct device *device, char *name, int len);

if you called it from the hub driver's probe function (or anything 
else's probe function) with the new hub device pointer, it might fill 
name with "ehci1/usbhub1-1/1-1.1" or somesuch.

That is then used in the hub probe function as the magic regulator name, 
if a regulator exists of that name it gets managed according to logical 
hub device lifecycle, same as the omap bit does at the moment.

That way it'll work with DT alright (you just arrange the regulator name 
to be "ehci1/usbhub1-1/1-1.1" or whatever) and you're just trying to 
sell device_path_generate() to someone else, which should be pretty small.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Alan Stern]

On Sat, 24 Nov 2012, Andy Green wrote:

> If we're just looking at fixing the current "magic regulator name" 
> scheme of "hsusb0" so that it can work with abstract devices like any 
> hub / port, we could invert what my original "device path" scheme did.
> 
> So instead of having a parser (which boiled down quite small, but is 
> complicated by usb%d being the same for different usb drivers), we could 
> just add a helper function that walks the device parents to generate a 
> string representing the device instance.  Like
> 
> int device_path_generate(struct device *device, char *name, int len);
> 
> if you called it from the hub driver's probe function (or anything 
> else's probe function) with the new hub device pointer, it might fill 
> name with "ehci1/usbhub1-1/1-1.1" or somesuch.

It's not that simple.  In your example, the very same device might show 
up, after rebooting, as "ehci2/usbhub2-1/2-1.1".  Even if a more or 
less stable name for the controller is used, the bus-number parts of 
the name (the '2's in this example) are always subject to change.  The 
device_path_generate routine would have to possess special knowledge 
about the USB subsystem's naming scheme to generate a truly stable 
name.

Presumably the same would hold for other subsystems too.

Alan Stern

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Andy Green]

On 11/24/12 23:38, the mail apparently from Alan Stern included:
> On Sat, 24 Nov 2012, Andy Green wrote:
>
>> If we're just looking at fixing the current "magic regulator name"
>> scheme of "hsusb0" so that it can work with abstract devices like any
>> hub / port, we could invert what my original "device path" scheme did.
>>
>> So instead of having a parser (which boiled down quite small, but is
>> complicated by usb%d being the same for different usb drivers), we could
>> just add a helper function that walks the device parents to generate a
>> string representing the device instance.  Like
>>
>> int device_path_generate(struct device *device, char *name, int len);
>>
>> if you called it from the hub driver's probe function (or anything
>> else's probe function) with the new hub device pointer, it might fill
>> name with "ehci1/usbhub1-1/1-1.1" or somesuch.
>
> It's not that simple.  In your example, the very same device might show
> up, after rebooting, as "ehci2/usbhub2-1/2-1.1".  Even if a more or
> less stable name for the controller is used, the bus-number parts of
> the name (the '2's in this example) are always subject to change.  The

Agreed; I pointed this out in a previous mail in this thread already, 
after someone else pointed it out to me some months ago.  Indeed we 
can't use "usb%d", the nth "usb" bus because the ordering of driver 
insertion for the various drivers that can create "usb%d"s breaks the 
determinism of it.

So we can only use in the matching paths a %d that represents the nth 
instance of a device from a specific driver, the "nth ehci host 
controller" for example.

> device_path_generate routine would have to possess special knowledge
> about the USB subsystem's naming scheme to generate a truly stable
> name.

I think there's enough info exposed to do everything generically with no 
access to driver-private info.

When walking struct device "path" one of the things we know at each 
stage is matched driver name.  So we might meet a device of name "usb2" 
but afaik we can trivially also see the matched driver has the name 
"ehci-hcd".

If we can walk a list of "usb%d"s, we can determine that our device is 
the nth device of that type belonging to "ehci-hcd" driver.  That list 
may be nondeterministic in terms of drivers getting modprobed in and 
out, say inserting themselves randomly in the ordering of the list 
before and after we modprobe ehci-hcd, but afaics no amount of insertion 
or removal will change the sequencing of other entries of the same type 
already there (first ehci-hcd one will always appear in the list in the 
same relative order to the second ehci-hcd one).  I think this would be 
reliable for getting as far as "ehci1/" and it's generic code walking 
device path and bus member lists that will work on all buses with that 
problem.

> Presumably the same would hold for other subsystems too.

Although it looks like that method will bounce off of usbhub%d since the 
driver name does not vary, I think it can also be alright.

If we can walk a list of usbhubs finding the ones that have the same 
parent pointer as the parent we arrived at in our walking, we should 
again get an ordinal we can use representing the nth hub on that 
particular host controller.  Afaics that should work for m hub levels 
too if we just filter by an opaque parent device pointer.

Of course the code should not particularly know it's looking at "usb%d" 
or "usbhub" just generic buses or classes or whatever it sees in use 
while walking the device path.  And although there's some walking around 
described, we only do it at probe time and only for devices that are 
interested in getting a deterministic device name to bind assets with.

The above is logically workable I think but to find out if it's 
practical to "walk usbhubs" and so on for me anyway the code needs to be 
attempted.  So I'm curious if you see any flaw already with this scheme.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Alan Stern]

On Sun, 25 Nov 2012, Andy Green wrote:

> On 11/24/12 23:38, the mail apparently from Alan Stern included:
> > On Sat, 24 Nov 2012, Andy Green wrote:
> >
> >> If we're just looking at fixing the current "magic regulator name"
> >> scheme of "hsusb0" so that it can work with abstract devices like any
> >> hub / port, we could invert what my original "device path" scheme did.
> >>
> >> So instead of having a parser (which boiled down quite small, but is
> >> complicated by usb%d being the same for different usb drivers), we could
> >> just add a helper function that walks the device parents to generate a
> >> string representing the device instance.  Like
> >>
> >> int device_path_generate(struct device *device, char *name, int len);
> >>
> >> if you called it from the hub driver's probe function (or anything
> >> else's probe function) with the new hub device pointer, it might fill
> >> name with "ehci1/usbhub1-1/1-1.1" or somesuch.
> >
> > It's not that simple.  In your example, the very same device might show
> > up, after rebooting, as "ehci2/usbhub2-1/2-1.1".  Even if a more or
> > less stable name for the controller is used, the bus-number parts of
> > the name (the '2's in this example) are always subject to change.  The
> 
> Agreed; I pointed this out in a previous mail in this thread already, 
> after someone else pointed it out to me some months ago.  Indeed we 
> can't use "usb%d", the nth "usb" bus because the ordering of driver 
> insertion for the various drivers that can create "usb%d"s breaks the 
> determinism of it.
> 
> So we can only use in the matching paths a %d that represents the nth 
> instance of a device from a specific driver, the "nth ehci host 
> controller" for example.

That's not right.  The order in which devices are discovered and 
registered is not deterministic.  Something better is needed.

> > device_path_generate routine would have to possess special knowledge
> > about the USB subsystem's naming scheme to generate a truly stable
> > name.
> 
> I think there's enough info exposed to do everything generically with no 
> access to driver-private info.
> 
> When walking struct device "path" one of the things we know at each 
> stage is matched driver name.  So we might meet a device of name "usb2" 
> but afaik we can trivially also see the matched driver has the name 
> "ehci-hcd".
> 
> If we can walk a list of "usb%d"s, we can determine that our device is 
> the nth device of that type belonging to "ehci-hcd" driver.  That list 
> may be nondeterministic in terms of drivers getting modprobed in and 
> out, say inserting themselves randomly in the ordering of the list 
> before and after we modprobe ehci-hcd, but afaics no amount of insertion 
> or removal will change the sequencing of other entries of the same type 
> already there (first ehci-hcd one will always appear in the list in the 
> same relative order to the second ehci-hcd one).

No, that's not true either.  The order in which devices are bound to 
drivers is not deterministic.

>  I think this would be 
> reliable for getting as far as "ehci1/" and it's generic code walking 
> device path and bus member lists that will work on all buses with that 
> problem.
> 
> > Presumably the same would hold for other subsystems too.
> 
> Although it looks like that method will bounce off of usbhub%d since the 
> driver name does not vary, I think it can also be alright.
> 
> If we can walk a list of usbhubs finding the ones that have the same 
> parent pointer as the parent we arrived at in our walking, we should 
> again get an ordinal we can use representing the nth hub on that 
> particular host controller.  Afaics that should work for m hub levels 
> too if we just filter by an opaque parent device pointer.
> 
> Of course the code should not particularly know it's looking at "usb%d" 
> or "usbhub" just generic buses or classes or whatever it sees in use 
> while walking the device path.  And although there's some walking around 
> described, we only do it at probe time and only for devices that are 
> interested in getting a deterministic device name to bind assets with.
> 
> The above is logically workable I think but to find out if it's 
> practical to "walk usbhubs" and so on for me anyway the code needs to be 
> attempted.  So I'm curious if you see any flaw already with this scheme.

It simply will not be reliable.

For the case we have been discussing, we do in fact know the device
name of the controller in question (at least, I assume we do).  Let's
say it is "ehci-panda".  We also have to assume that we know which port
the LAN95xx hub is attached to; say it is port 3.  Then the device path
to search for would be something like "ehci-panda/usb*/*-3" or maybe
"ehci-panda/usb*/port-3", where the * would have to match any number
(that part of the name is not a stable value).  But you wouldn't know
this unless you were familiar with the details of the USB device naming
scheme.

Maybe some sort of specialized wildcard parser could do the matching.

Alan Stern

--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Alan Stern]

On Thu, 22 Nov 2012, Felipe Balbi wrote:

> > If you mean change the regulator managing code from living in
> > omap-hsusb to ehci-hcd, it sounds like a good idea.
> 
> I mean that drivers/usb/core/hub.c should manage it, since that's what
> actually manages the HUB entity.

This is an interesting problem.  How should we handle devices which
live on a discoverable bus but whose power is controlled by an
undiscoverable platform-specific regulator?

Has this sort of thing come up in the past with other types of devices?

A big part of the problem is associating the hub, which is created
dynamically by the USB core code, with the regulator, which is known
from platform data at boot time.  The suggestion that the regulator
should really be associated with a port on the hub's parent is
reasonable at first glance.  But what if we don't know which port that
is?

Once we can solve this part of the problem, I think the rest of it will 
fall into place.

> as long as Alan is ok and it comes in the same series, I'd be really,
> really glad to see such a patch and would happily review it.

If we can figure out a good way to set up the necessary association, I
won't mind adding the appropriate calls to the USB core.  But is the
hub driver the right place?  What if a similar power arrangement is
used for a different kind of USB-connected chip (for example, a webcam
or a fingerprint reader)?

Alan Stern

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

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

Hi,

On Thu, Nov 22, 2012 at 12:36:43PM -0500, Alan Stern wrote:
> On Thu, 22 Nov 2012, Felipe Balbi wrote:
> 
> > > If you mean change the regulator managing code from living in
> > > omap-hsusb to ehci-hcd, it sounds like a good idea.
> > 
> > I mean that drivers/usb/core/hub.c should manage it, since that's what
> > actually manages the HUB entity.
> 
> This is an interesting problem.  How should we handle devices which
> live on a discoverable bus but whose power is controlled by an
> undiscoverable platform-specific regulator?

a quirk on the hub's product ID/vendor ID pair ? All you need is to put
a requirement on the format of the regulator name. Not the best
solution, I agree, but that's all we can do.

> Has this sort of thing come up in the past with other types of
> devices?

I'm not sure.

> A big part of the problem is associating the hub, which is created
> dynamically by the USB core code, with the regulator, which is known
> from platform data at boot time.  The suggestion that the regulator

It doesn't matter, IMO, when do we know the regulator exists. As long as
the regulator is registered early enough (or we rely on -EPROBE_DEFER to
synchronize things) and we have a known naming format (perhaps something
like usb_hub_port%d_supply, or something), we should be able to request
the regulator and toggle it at any time.

> should really be associated with a port on the hub's parent is
> reasonable at first glance.  But what if we don't know which port that
> is?

What do you mean ? I'd expect all ports to have a regulator. Either one
for each, or sharing the same supply. It all boils down to how the hub
is integrated.

I'm guessing the the problem here is that this hub can't control the
external Hub when its port gets a PORT_POWER feature cleared or set.
That's what I'm assuming.

> Once we can solve this part of the problem, I think the rest of it
> will fall into place.

I agree with you.

> > as long as Alan is ok and it comes in the same series, I'd be really,
> > really glad to see such a patch and would happily review it.
> 
> If we can figure out a good way to set up the necessary association, I
> won't mind adding the appropriate calls to the USB core.  But is the
> hub driver the right place?  What if a similar power arrangement is
> used for a different kind of USB-connected chip (for example, a webcam
> or a fingerprint reader)?

Then the camera's driver or the fingerprint reader's driver should
manage the regulator, no ? Or do you want to let teach the regulator to
struct usb_device and manage it at usbcore level ?

-- 
balbi

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Alan Stern]

On Thu, 22 Nov 2012, Felipe Balbi wrote:

> Hi,

Hello.

> > This is an interesting problem.  How should we handle devices which
> > live on a discoverable bus but whose power is controlled by an
> > undiscoverable platform-specific regulator?
> 
> a quirk on the hub's product ID/vendor ID pair ? All you need is to put
> a requirement on the format of the regulator name. Not the best
> solution, I agree, but that's all we can do.

That sounds a little too simple.  For example, what if there are two 
chips of the same type on the system, attached to two different 
regulators and two different host controllers?

> > from platform data at boot time.  The suggestion that the regulator
> > should really be associated with a port on the hub's parent is
> > reasonable at first glance.  But what if we don't know which port that
> > is?
> 
> What do you mean ? I'd expect all ports to have a regulator. Either one
> for each, or sharing the same supply. It all boils down to how the hub
> is integrated.

I wasn't clear enough.  I wasn't talking about downstream ports on that
hub, but about where its upstream port is connected.  This hub is
permanently wired to one of the root ports on the EHCI controller.  In
this case, we know which port it is attached to.  In other systems we
may not know, or it may be different on different revisions of the same
board.

> > If we can figure out a good way to set up the necessary association, I
> > won't mind adding the appropriate calls to the USB core.  But is the
> > hub driver the right place?  What if a similar power arrangement is
> > used for a different kind of USB-connected chip (for example, a webcam
> > or a fingerprint reader)?
> 
> Then the camera's driver or the fingerprint reader's driver should
> manage the regulator, no ? Or do you want to let teach the regulator to
> struct usb_device and manage it at usbcore level ?

The latter, more or less.  For example, maybe we can tell usbcore
somehow that regulator X is in control of a device attached to host
controller Y (not sure how we would express X and Y though).  Then when
usb_add_hcd() sees that the host controller being added is Y, it will
know to turn on regulator X.  Similarly for usb_remove_hcd().

Alan Stern

--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

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

Hi,

On Thu, Nov 22, 2012 at 01:32:25PM -0500, Alan Stern wrote:
> On Thu, 22 Nov 2012, Felipe Balbi wrote:
> 
> > Hi,
> 
> Hello.
> 
> > > This is an interesting problem.  How should we handle devices which
> > > live on a discoverable bus but whose power is controlled by an
> > > undiscoverable platform-specific regulator?
> > 
> > a quirk on the hub's product ID/vendor ID pair ? All you need is to put
> > a requirement on the format of the regulator name. Not the best
> > solution, I agree, but that's all we can do.
> 
> That sounds a little too simple.  For example, what if there are two 
> chips of the same type on the system, attached to two different 
> regulators and two different host controllers?

hehe, good point :-)

> > > from platform data at boot time.  The suggestion that the regulator
> > > should really be associated with a port on the hub's parent is
> > > reasonable at first glance.  But what if we don't know which port that
> > > is?
> > 
> > What do you mean ? I'd expect all ports to have a regulator. Either one
> > for each, or sharing the same supply. It all boils down to how the hub
> > is integrated.
> 
> I wasn't clear enough.  I wasn't talking about downstream ports on that
> hub, but about where its upstream port is connected.  This hub is
> permanently wired to one of the root ports on the EHCI controller.  In
> this case, we know which port it is attached to.  In other systems we
> may not know, or it may be different on different revisions of the same
> board.

ok, makes sense now. You're right.

> > > If we can figure out a good way to set up the necessary association, I
> > > won't mind adding the appropriate calls to the USB core.  But is the
> > > hub driver the right place?  What if a similar power arrangement is
> > > used for a different kind of USB-connected chip (for example, a webcam
> > > or a fingerprint reader)?
> > 
> > Then the camera's driver or the fingerprint reader's driver should
> > manage the regulator, no ? Or do you want to let teach the regulator to
> > struct usb_device and manage it at usbcore level ?
> 
> The latter, more or less.  For example, maybe we can tell usbcore
> somehow that regulator X is in control of a device attached to host
> controller Y (not sure how we would express X and Y though).  Then when
> usb_add_hcd() sees that the host controller being added is Y, it will
> know to turn on regulator X.  Similarly for usb_remove_hcd().

that'd look very nice indeed. Perhaps we could even take care of such
details for the roothub, even. Maybe some systems might show up where
roothub need external regulators provided by e.g. PMIC ?!?

-- 
balbi

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Alan Stern]

On Thu, 22 Nov 2012, Felipe Balbi wrote:

> > The latter, more or less.  For example, maybe we can tell usbcore
> > somehow that regulator X is in control of a device attached to host
> > controller Y (not sure how we would express X and Y though).  Then when
> > usb_add_hcd() sees that the host controller being added is Y, it will
> > know to turn on regulator X.  Similarly for usb_remove_hcd().
> 
> that'd look very nice indeed. Perhaps we could even take care of such
> details for the roothub, even. Maybe some systems might show up where
> roothub need external regulators provided by e.g. PMIC ?!?

As far as I can see, that ought to work provided the controller's 
platform driver is careful not to access the controller hardware before 
calling usb_add_hcd().

And maybe the same sort of scheme could be used for clocks, although I 
don't know how to do it in a generic way that will work on all 
platforms.

Alan Stern

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

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

Hi,

On Thu, Nov 22, 2012 at 09:35:06PM -0500, Alan Stern wrote:
> On Thu, 22 Nov 2012, Felipe Balbi wrote:
> 
> > > The latter, more or less.  For example, maybe we can tell usbcore
> > > somehow that regulator X is in control of a device attached to host
> > > controller Y (not sure how we would express X and Y though).  Then when
> > > usb_add_hcd() sees that the host controller being added is Y, it will
> > > know to turn on regulator X.  Similarly for usb_remove_hcd().
> > 
> > that'd look very nice indeed. Perhaps we could even take care of such
> > details for the roothub, even. Maybe some systems might show up where
> > roothub need external regulators provided by e.g. PMIC ?!?
> 
> As far as I can see, that ought to work provided the controller's 
> platform driver is careful not to access the controller hardware before 
> calling usb_add_hcd().
> 
> And maybe the same sort of scheme could be used for clocks, although I 
> don't know how to do it in a generic way that will work on all 
> platforms.

perhaps making use of pm_clk_add() and letting PM layer do the rest for
us ? If that doesn't work then it means PM layer's clk handling could be
improved, I suppose.

-- 
balbi

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Alan Stern]

On Fri, 23 Nov 2012, Felipe Balbi wrote:

> > And maybe the same sort of scheme could be used for clocks, although I 
> > don't know how to do it in a generic way that will work on all 
> > platforms.
> 
> perhaps making use of pm_clk_add() and letting PM layer do the rest for
> us ? If that doesn't work then it means PM layer's clk handling could be
> improved, I suppose.

Is the clock framework sufficiently generic at this point that it can
be used by core code (like the PM layer)?

Alan Stern

--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

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

Hi,

On Fri, Nov 23, 2012 at 11:27:34AM -0500, Alan Stern wrote:
> On Fri, 23 Nov 2012, Felipe Balbi wrote:
> 
> > > And maybe the same sort of scheme could be used for clocks, although I 
> > > don't know how to do it in a generic way that will work on all 
> > > platforms.
> > 
> > perhaps making use of pm_clk_add() and letting PM layer do the rest for
> > us ? If that doesn't work then it means PM layer's clk handling could be
> > improved, I suppose.
> 
> Is the clock framework sufficiently generic at this point that it can
> be used by core code (like the PM layer)?

It already is :-) See drivers/base/power/clock_ops.c

-- 
balbi

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Andy Green]

On 11/23/12 01:36, the mail apparently from Alan Stern included:
> On Thu, 22 Nov 2012, Felipe Balbi wrote:

Hi -

>>> If you mean change the regulator managing code from living in
>>> omap-hsusb to ehci-hcd, it sounds like a good idea.
>>
>> I mean that drivers/usb/core/hub.c should manage it, since that's what
>> actually manages the HUB entity.
>
> This is an interesting problem.  How should we handle devices which
> live on a discoverable bus but whose power is controlled by an
> undiscoverable platform-specific regulator?
>
> Has this sort of thing come up in the past with other types of devices?
>
> A big part of the problem is associating the hub, which is created
> dynamically by the USB core code, with the regulator, which is known
> from platform data at boot time.  The suggestion that the regulator
> should really be associated with a port on the hub's parent is
> reasonable at first glance.  But what if we don't know which port that
> is?
>
> Once we can solve this part of the problem, I think the rest of it will
> fall into place.
>
>> as long as Alan is ok and it comes in the same series, I'd be really,
>> really glad to see such a patch and would happily review it.
>
> If we can figure out a good way to set up the necessary association, I
> won't mind adding the appropriate calls to the USB core.  But is the
> hub driver the right place?  What if a similar power arrangement is
> used for a different kind of USB-connected chip (for example, a webcam
> or a fingerprint reader)?

About 18 months ago I sent out an RFC for "platform_data for 
asynchronously probed devices", aimed at exactly this problem.  It got 
flamed to death.

The core idea there was matching "device paths" like 
"usb1/1-1/1-1.1/1-1.1:1.0" to bind platform data to an 
asynchronously-probed device, where the device is on hardwired connection.

I provided an implementation that worked on both SDIO and usb buses on 
Panda, for the WLAN module and smsc95xx chip respectively.  We have used 
this implementation to solve lack of hardware or assigned MAC addresses 
for wlan0 and eth0 on Panda in Linaro tilt kernels ever since.

Most of the arguments against it were of the form, "do MAC address 
setting in userspace" which I felt did not understand the general use 
case outside of setting MAC addresses; such as we're talking about now 
with binding regulators for example.  Some of the objectors did not seem 
to know what "platform_data" was either, others killed it because 
platform_data != device tree.

There was one genuine objection that I did not solve, "what about if 
people modprobe usb buses in different order", like ehci, xhci etc.  So 
the "device path" would need to be qualified by the name of the driver 
targeted as well as the bus index of that driver we targeted, but that's 
easy enough.

Anyway as a generic thing I think its ship has sailed (on a river of 
flames), but since you bring up attaching kernel objects to 
asynchronously probed devices: there's one way to do it for hardwired 
platform devices.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
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