Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver

2013-05-17 Thread Linus Walleij 
On Wed, May 15, 2013 at 10:14 PM, Fabio Baltieri
fabio.balti...@linaro.org wrote:
 On Wed, May 15, 2013 at 07:18:01PM +0200, Linus Walleij wrote:
 On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote:

  For all ux500 based platforms the maximum number of end-points are used.
  Move this knowledge into the driver so we can relinquish the burden from
  platform data. This also removes quite a bit of complexity from the driver
  and will aid us when we come to enable the driver for Device Tree.
 
  Cc: Felipe Balbi ba...@ti.com
  Cc: linux-usb@vger.kernel.org
  Acked-by: Linus Walleij linus.wall...@linaro.org
  Acked-by: Fabio Baltieri fabio.balti...@linaro.org
  Signed-off-by: Lee Jones lee.jo...@linaro.org

 I guess this stuff is dependent on the stuff Fabio has recently sent to
 Felipe for the ux500 musb DMA so these musb patches should
 primarily go through his tree.

 Not really, I only sent some coding style fix for the dma driver, as
 almost all of my work was in the usb phy files.  I also checked my
 latest series against Lee's tree and the two seems to merge without any
 conflict, so as far as I'm concerned it's really up to you and Felipe.

OK so Felipe can merge these smallish patches to musb, fine...

The other (DMA) stuff needs to be merged together with the rest
of the DMA40 series, so here basically Felipe needs an indication
if he can ACK it so I merge it through ARM SoC without colissions
and it sounds like we can make the assumption that this will work.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] staging: dwc2: miscellaneous cleanups

2013-05-17 Thread Matthijs Kooijman 
Hi Greg,

On Thu, May 16, 2013 at 03:26:25PM -0700, Greg KH wrote:
 On Mon, May 13, 2013 at 07:08:05PM -0700, Paul Zimmerman wrote:
  Here are some dwc2 patches which Matthijs submitted just before the merge
  window opened, looks like they did not get picked up. Please apply.
 
 I think I just got all of these, right?
Yup, you did.

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

Re: [PATCH 03/10] usb: phy: ab8500-usb: add transceiver clock control

2013-05-17 Thread Ulf Hansson 
On 15 May 2013 14:03, Fabio Baltieri fabio.balti...@linaro.org wrote:
 From: Mian Yousaf Kaukab mian.yousaf.kau...@stericsson.com

 Add common clock support code for the ab8500-usb phy driver.

 Acked-by: Linus Walleij linus.wall...@linaro.org
 Acked-by: Maxime Coquelin maxime.coque...@st.com
 Signed-off-by: Mian Yousaf Kaukab mian.yousaf.kau...@stericsson.com
 Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org
 ---
  drivers/usb/phy/phy-ab8500-usb.c | 14 ++
  1 file changed, 14 insertions(+)

 diff --git a/drivers/usb/phy/phy-ab8500-usb.c 
 b/drivers/usb/phy/phy-ab8500-usb.c
 index b043faa..cc0d7e5 100644
 --- a/drivers/usb/phy/phy-ab8500-usb.c
 +++ b/drivers/usb/phy/phy-ab8500-usb.c
 @@ -29,6 +29,8 @@
  #include linux/notifier.h
  #include linux/interrupt.h
  #include linux/delay.h
 +#include linux/clk.h
 +#include linux/err.h
  #include linux/mfd/abx500.h
  #include linux/mfd/abx500/ab8500.h
  #include linux/usb/musb-ux500.h
 @@ -126,6 +128,7 @@ struct ab8500_usb {
 unsigned vbus_draw;
 struct work_struct phy_dis_work;
 enum ab8500_usb_mode mode;
 +   struct clk *sysclk;
 struct regulator *v_ape;
 struct regulator *v_musb;
 struct regulator *v_ulpi;
 @@ -252,6 +255,9 @@ static void ab8500_usb_phy_enable(struct ab8500_usb *ab, 
 bool sel_host)
 if (IS_ERR(ab-pinctrl))
 dev_err(ab-dev, could not get/set default pinstate\n);

 +   if (clk_prepare_enable(ab-sysclk))
 +   dev_err(ab-dev, can't prepare/enable clock\n);
 +
 ab8500_usb_regulator_enable(ab);

 abx500_mask_and_set_register_interruptible(ab-dev,
 @@ -274,6 +280,8 @@ static void ab8500_usb_phy_disable(struct ab8500_usb *ab, 
 bool sel_host)
 /* Needed to disable the phy.*/
 ab8500_usb_wd_workaround(ab);

 +   clk_disable_unprepare(ab-sysclk);
 +
 ab8500_usb_regulator_disable(ab);

 if (!IS_ERR(ab-pinctrl)) {
 @@ -784,6 +792,12 @@ static int ab8500_usb_probe(struct platform_device *pdev)
 if (err)
 return err;

 +   ab-sysclk = devm_clk_get(ab-dev, sysclk);
 +   if (IS_ERR(ab-sysclk)) {
 +   dev_err(ab-dev, Could not get sysclk.\n);
 +   return PTR_ERR(ab-sysclk);
 +   }
 +
 err = ab8500_usb_irq_setup(pdev, ab);
 if (err  0)
 return err;
 --
 1.8.2

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

Acked-by: Ulf Hansson ulf.hans...@linaro.org
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/12] usb: chipidea: ci13xxx_imx: Remove redundant platform_set_drvdata()

2013-05-17 Thread Sachin Kamat 
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Marek Vasut ma...@denx.de
Cc: Alexander Shishkin alexander.shish...@linux.intel.com
---
 drivers/usb/chipidea/ci13xxx_imx.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/chipidea/ci13xxx_imx.c 
b/drivers/usb/chipidea/ci13xxx_imx.c
index 8faec9d..b8ad556 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -251,8 +251,6 @@ static int ci13xxx_imx_remove(struct platform_device *pdev)
 
clk_disable_unprepare(data-clk);
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
1.7.9.5

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

[PATCH 02/12] usb: gadget: mv_u3d_core: Remove redundant platform_set_drvdata()

2013-05-17 Thread Sachin Kamat 
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Yu Xu y...@marvell.com
---
 drivers/usb/gadget/mv_u3d_core.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/usb/gadget/mv_u3d_core.c b/drivers/usb/gadget/mv_u3d_core.c
index 58288e9..751b17a 100644
--- a/drivers/usb/gadget/mv_u3d_core.c
+++ b/drivers/usb/gadget/mv_u3d_core.c
@@ -1786,8 +1786,6 @@ static int mv_u3d_remove(struct platform_device *dev)
 
clk_put(u3d-clk);
 
-   platform_set_drvdata(dev, NULL);
-
kfree(u3d);
 
return 0;
@@ -1997,7 +1995,6 @@ err_map_cap_regs:
 err_get_cap_regs:
 err_get_clk:
clk_put(u3d-clk);
-   platform_set_drvdata(dev, NULL);
kfree(u3d);
 err_alloc_private:
 err_pdata:
-- 
1.7.9.5

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

[PATCH 03/12] usb: gadget: pxa27x_udc: Remove redundant platform_set_drvdata()

2013-05-17 Thread Sachin Kamat 
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Eric Miao eric.y.m...@gmail.com
---
 drivers/usb/gadget/pxa27x_udc.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index 6b4c7d9..41cea95 100644
--- a/drivers/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -2505,7 +2505,6 @@ static int pxa_udc_remove(struct platform_device *_dev)
usb_put_phy(udc-transceiver);
 
udc-transceiver = NULL;
-   platform_set_drvdata(_dev, NULL);
the_controller = NULL;
clk_put(udc-clk);
iounmap(udc-regs);
-- 
1.7.9.5

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

[PATCH 04/12] usb: host: ehci-tilegx: Remove redundant platform_set_drvdata()

2013-05-17 Thread Sachin Kamat 
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Alan Stern st...@rowland.harvard.edu
---
 drivers/usb/host/ehci-tilegx.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/host/ehci-tilegx.c b/drivers/usb/host/ehci-tilegx.c
index b083a35..d72b292 100644
--- a/drivers/usb/host/ehci-tilegx.c
+++ b/drivers/usb/host/ehci-tilegx.c
@@ -193,7 +193,6 @@ static int ehci_hcd_tilegx_drv_remove(struct 
platform_device *pdev)
tilegx_stop_ehc();
gxio_usb_host_destroy(pdata-usb_ctx);
destroy_irq(pdata-irq);
-   platform_set_drvdata(pdev, NULL);
 
return 0;
 }
-- 
1.7.9.5

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

[PATCH 05/12] usb: host: ohci-da8xx: Remove redundant platform_set_drvdata()

2013-05-17 Thread Sachin Kamat 
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/usb/host/ohci-da8xx.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 0b815a8..6aaa9c9 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -401,7 +401,6 @@ static int ohci_hcd_da8xx_drv_remove(struct platform_device 
*dev)
struct usb_hcd  *hcd = platform_get_drvdata(dev);
 
usb_hcd_da8xx_remove(hcd, dev);
-   platform_set_drvdata(dev, NULL);
 
return 0;
 }
-- 
1.7.9.5

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

[PATCH 06/12] usb: host: ohci-nxp: Remove redundant platform_set_drvdata()

2013-05-17 Thread Sachin Kamat 
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Dmitry Chigirev sou...@mvista.com
---
 drivers/usb/host/ohci-nxp.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index f4988fb..292be50 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -366,8 +366,6 @@ static int usb_hcd_nxp_remove(struct platform_device *pdev)
i2c_unregister_device(isp1301_i2c_client);
isp1301_i2c_client = NULL;
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
1.7.9.5

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

[PATCH 07/12] usb: host: ohci-octeon: Remove redundant platform_set_drvdata()

2013-05-17 Thread Sachin Kamat 
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/usb/host/ohci-octeon.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/host/ohci-octeon.c b/drivers/usb/host/ohci-octeon.c
index d44430d..342dc7e 100644
--- a/drivers/usb/host/ohci-octeon.c
+++ b/drivers/usb/host/ohci-octeon.c
@@ -196,8 +196,6 @@ static int ohci_octeon_drv_remove(struct platform_device 
*pdev)
release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
 
-   platform_set_drvdata(pdev, NULL);
-
return 0;
 }
 
-- 
1.7.9.5

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

[PATCH 08/12] usb: host: ohci-omap: Remove redundant platform_set_drvdata()

2013-05-17 Thread Sachin Kamat 
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Tony Lindgren t...@atomide.com
---
 drivers/usb/host/ohci-omap.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index b1d32fb..8747fa6 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -498,7 +498,6 @@ static int ohci_hcd_omap_drv_remove(struct platform_device 
*dev)
struct usb_hcd  *hcd = platform_get_drvdata(dev);
 
usb_hcd_omap_remove(hcd, dev);
-   platform_set_drvdata(dev, NULL);
 
return 0;
 }
-- 
1.7.9.5

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

[PATCH 12/12] usb: host: uhci-platform: Remove redundant platform_set_drvdata()

2013-05-17 Thread Sachin Kamat 
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Tony Prisk li...@prisktech.co.nz
---
 drivers/usb/host/uhci-platform.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/host/uhci-platform.c b/drivers/usb/host/uhci-platform.c
index 8c4dace..55cc116 100644
--- a/drivers/usb/host/uhci-platform.c
+++ b/drivers/usb/host/uhci-platform.c
@@ -130,7 +130,6 @@ static int uhci_hcd_platform_remove(struct platform_device 
*pdev)
iounmap(hcd-regs);
release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
-   platform_set_drvdata(pdev, NULL);
 
return 0;
 }
-- 
1.7.9.5

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

Huawei 3276 with option and cdc_ncm

2013-05-17 Thread Thomas Schäfer 

Hi,

the LTE-stick huawei 3276 (in Germany also  alias Telekom Speedstick 
LTE III) works well with linux. (also IPv6)


Here is the output of dmesg (IPv4-connection).



at^ndisdup=1,1,internet.telekom
OK

^NDISSTAT:1,,,IPV4

[   97.342188] usb 1-1: new high-speed USB device number 3 using ehci-pci
[   97.457592] usb 1-1: New USB device found, idVendor=12d1, idProduct=14fe
[   97.457608] usb 1-1: New USB device strings: Mfr=2, Product=1, 
SerialNumber=0

[   97.457619] usb 1-1: Product: HUAWEI Mobile
[   97.457628] usb 1-1: Manufacturer: HUAWEI Technology
[   97.548179] Initializing USB Mass Storage driver...
[   97.550976] scsi4 : usb-storage 1-1:1.0
[   97.552479] scsi5 : usb-storage 1-1:1.1
[   97.552767] usbcore: registered new interface driver usb-storage
[   97.552776] USB Mass Storage support registered.
[   98.342756] usb 1-1: USB disconnect, device number 3
[   98.676180] usb 1-1: new high-speed USB device number 4 using ehci-pci
[   98.791457] usb 1-1: New USB device found, idVendor=12d1, idProduct=1506
[   98.791473] usb 1-1: New USB device strings: Mfr=2, Product=1, 
SerialNumber=0

[   98.791483] usb 1-1: Product: HUAWEI Mobile
[   98.791492] usb 1-1: Manufacturer: HUAWEI Technology
[   98.796847] scsi6 : usb-storage 1-1:1.3
[   98.798934] scsi7 : usb-storage 1-1:1.4
[   98.831738] usbcore: registered new interface driver usbserial
[   98.831819] usbcore: registered new interface driver usbserial_generic
[   98.831871] usbserial: USB Serial support registered for generic
[   98.849762] usbcore: registered new interface driver option
[   98.849827] usbserial: USB Serial support registered for GSM modem 
(1-port)

[   98.856298] usb 1-1: MAC-Address: 0c:5b:8f:27:9a:64
[   98.858361] cdc_ncm 1-1:1.2 wwan0: register 'cdc_ncm' at 
usb-:00:1d.7-1, Mobile Broadband Network Device, 0c:5b:8f:27:9a:64

[   98.858455] option 1-1:1.0: GSM modem (1-port) converter detected
[   98.858873] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
[   98.858954] option 1-1:1.1: GSM modem (1-port) converter detected
[   98.860613] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
[   98.862692] usbcore: registered new interface driver cdc_ncm
[   99.801682] scsi 6:0:0:0: CD-ROMHUAWEI   Mass Storage 
2.31 PQ: 0 ANSI: 2
[   99.802410] scsi 7:0:0:0: Direct-Access HUAWEI   TF CARD Storage  
2.31 PQ: 0 ANSI: 2

[   99.807347] sd 7:0:0:0: [sdb] Attached SCSI removable disk
[   99.807500] scsi 6:0:0:0: Attached scsi generic sg1 type 5
[   99.807807] sd 7:0:0:0: Attached scsi generic sg2 type 0
[   99.829118] sr0: scsi-1 drive
[   99.829131] cdrom: Uniform CD-ROM driver Revision: 3.20
[   99.830262] sr 6:0:0:0: Attached scsi CD-ROM sr0
[  130.330738] ISO 9660 Extensions: Microsoft Joliet Level 1
[  130.340973] ISOFS: changing to secondary root
[  398.807736] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
[  398.812756] usb 1-1: NCM: unexpected notification 0x03!
[  398.820518] NET: Registered protocol family 17
[  398.820755] usb 1-1: NCM: unexpected notification 0x03!
[  398.828767] usb 1-1: NCM: unexpected notification 0x03!
[  398.836762] usb 1-1: NCM: unexpected notification 0x03!
[  398.844770] cdc_ncm: wwan0: 43 mbit/s downlink 43 mbit/s uplink
[  398.852764] cdc_ncm: wwan0: network connection: connected
[  398.852913] IPv6: ADDRCONF(NETDEV_CHANGE): wwan0: link becomes ready


at^ndisdup=1,0
OK

^NDISSTAT:0,,,IPV4



[  948.121071] usb 1-1: NCM: unexpected notification 0x01!
[  948.129091] usb 1-1: NCM: unexpected notification 0x01!
[  948.137063] cdc_ncm: wwan0: network connection: disconnected


What does unexpected notification mean?  Should it be investigated, or 
is it harmless?


Regards,

Thomas






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

Re: Huawei 3276 with option and cdc_ncm

2013-05-17 Thread Bjørn Mork 
Thomas Schäfer tschae...@t-online.de writes:

 Hi,

 the LTE-stick huawei 3276 (in Germany also  alias Telekom Speedstick
 LTE III) works well with linux. (also IPv6)

Thanks.  We have many reports that it works as expected for IPv4, but I
believe this is the first one for IPv6.  Not that it is surprising, but
you never know what the firmware engineers come up with...

 [  948.121071] usb 1-1: NCM: unexpected notification 0x01!
 [  948.129091] usb 1-1: NCM: unexpected notification 0x01!
 [  948.137063] cdc_ncm: wwan0: network connection: disconnected


 What does unexpected notification mean?  Should it be investigated,
 or is it harmless?

It is harmless, and this message will be demoted to a debug message in
v3.10. So you won't see it under normal use anymore.

CDC notification 0x01 is RESPONSE AVAILABLE, which means that the
device has some message for the host/driver.  But we don't know what
protocol this device uses, so there is really no point requesting that
message.  I assume it is just reporting some connection related
information in some vendor specific protocol.  Maybe RNDIS?

Anyway, the device works fine using only AT commands for management and
that's what we currently support.

If you want to research the embedded management protocol, then you could
hack a cdc-wdm subdriver into the cdc_ncm driver temporarily, to have
access to those messages from userspace.  But this will require a few
changes to the cdc_ncm driver, since NCM is supposed to use the
notification endpoint.

I've also seen NCM: unexpected notification 0x03! from this device,
which is a little more unexpected.  Actually so unexpected that it has
suprised me twice - says a lot about my memory :)  AFAIK, 0x03 is still
reserved.  In CDC specs at least.  But then again this device isn't
really a CDC compliant device.  We just happen to support it using the
cdc_ncm driver because that's the framing the device uses.



Bjørn
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 3/4] usb: musb: omap: use the new API to get PHY reference by label

2013-05-17 Thread Kishon Vijay Abraham I 
After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So used the
new API devm_usb_get_phy_by_name to get the PHY reference.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/musb/musb_core.c |1 +
 drivers/usb/musb/musb_core.h |1 +
 drivers/usb/musb/omap2430.c  |2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..00fbaf4 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1864,6 +1864,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
musb-board_set_power = plat-set_power;
musb-min_power = plat-min_power;
musb-ops = plat-platform_ops;
+   musb-phy_name = plat-phy_name;
 
/* The musb_platform_init() call:
 *   - adjusts musb-mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..e9a9339 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -434,6 +434,7 @@ struct musb {
unsigneddouble_buffer_not_ok:1;
 
struct musb_hdrc_config *config;
+   const char  *phy_name;
 
 #ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 3551f1a..be29aa7 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -352,7 +352,7 @@ static int omap2430_musb_init(struct musb *musb)
musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
usb-phy, 0);
else
-   musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+   musb-xceiv = devm_usb_get_phy_by_name(dev, musb-phy_name);
 
if (IS_ERR(musb-xceiv)) {
status = PTR_ERR(musb-xceiv);
-- 
1.7.10.4

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

[RFC PATCH 0/4] Add usb2 link powermanagement BESL support

2013-05-17 Thread Mathias Nyman 
This series adds usb2 best effort service latency (BESL) link PM support
to xHCI. BESL is an updated alternative to host initated resume delay
(HIRD) method of describing idle link timeouts. 

Additionally this series fixes port capability checking
and replaces magic numbers with port register names.

Mathias Nyman (4):
  usb: xhci: check usb2 port capabilities before adding hw link PM
support
  usb: xhci: define port register names and use them instead of magic
numbers
  usb: xhci: add USB2 Link power management BESL support
  usb: add usb2 Link PM variables to sysfs and usb_device

 drivers/usb/core/sysfs.c |   54 +
 drivers/usb/host/xhci-ext-caps.h |1 +
 drivers/usb/host/xhci-hub.c  |   16 +--
 drivers/usb/host/xhci-mem.c  |   33 +-
 drivers/usb/host/xhci.c  |  234 +++---
 drivers/usb/host/xhci.h  |   31 +
 include/linux/usb.h  |   19 +++
 7 files changed, 308 insertions(+), 80 deletions(-)

-- 
1.7.4.1

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

[RFC PATCH 1/4] usb: xhci: check usb2 port capabilities before adding hw link PM support

2013-05-17 Thread Mathias Nyman 
Hardware link powermanagement in usb2 is a per-port capability.
Previously support for hw lpm was enabled for all ports if any usb2 port 
supported it.

Now instead cache the capability values and check them for each port 
individually

Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
 drivers/usb/host/xhci-mem.c |   33 +
 drivers/usb/host/xhci.c |   27 ++-
 drivers/usb/host/xhci.h |3 +++
 3 files changed, 58 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 965b539..5fd97d1 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1851,6 +1851,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
kfree(xhci-usb3_ports);
kfree(xhci-port_array);
kfree(xhci-rh_bw);
+   kfree(xhci-ext_caps);
 
xhci-page_size = 0;
xhci-page_shift = 0;
@@ -2038,7 +2039,7 @@ static void xhci_set_hc_event_deq(struct xhci_hcd *xhci)
 }
 
 static void xhci_add_in_port(struct xhci_hcd *xhci, unsigned int num_ports,
-   __le32 __iomem *addr, u8 major_revision)
+   __le32 __iomem *addr, u8 major_revision, int max_caps)
 {
u32 temp, port_offset, port_count;
int i;
@@ -2063,6 +2064,10 @@ static void xhci_add_in_port(struct xhci_hcd *xhci, 
unsigned int num_ports,
/* WTF? Valid values are ‘1’ to MaxPorts */
return;
 
+   /* cache usb2 port capabilities */
+   if (major_revision  0x03  xhci-num_ext_caps  max_caps)
+   xhci-ext_caps[xhci-num_ext_caps++] = temp;
+
/* Check the host's USB2 LPM capability */
if ((xhci-hci_version == 0x96)  (major_revision != 0x03) 
(temp  XHCI_L1C)) {
@@ -2120,10 +2125,11 @@ static void xhci_add_in_port(struct xhci_hcd *xhci, 
unsigned int num_ports,
  */
 static int xhci_setup_port_arrays(struct xhci_hcd *xhci, gfp_t flags)
 {
-   __le32 __iomem *addr;
-   u32 offset;
+   __le32 __iomem *addr, *tmp_addr;
+   u32 offset, tmp_offset;
unsigned int num_ports;
int i, j, port_index;
+   int cap_count = 0;
 
addr = xhci-cap_regs-hcc_params;
offset = XHCI_HCC_EXT_CAPS(xhci_readl(xhci, addr));
@@ -2156,13 +2162,32 @@ static int xhci_setup_port_arrays(struct xhci_hcd 
*xhci, gfp_t flags)
 * See section 5.3.6 for offset calculation.
 */
addr = xhci-cap_regs-hc_capbase + offset;
+
+   tmp_addr = addr;
+   tmp_offset = offset;
+
+   /* count extended protocol capability entries for later caching */
+   do {
+   u32 cap_id;
+   cap_id = xhci_readl(xhci, tmp_addr);
+   if (XHCI_EXT_CAPS_ID(cap_id) == XHCI_EXT_CAPS_PROTOCOL)
+   cap_count++;
+   tmp_offset = XHCI_EXT_CAPS_NEXT(cap_id);
+   tmp_addr += tmp_offset;
+   } while (tmp_offset);
+
+   xhci-ext_caps = kzalloc(sizeof(*xhci-ext_caps) * cap_count, flags);
+   if (!xhci-ext_caps)
+   return -ENOMEM;
+
while (1) {
u32 cap_id;
 
cap_id = xhci_readl(xhci, addr);
if (XHCI_EXT_CAPS_ID(cap_id) == XHCI_EXT_CAPS_PROTOCOL)
xhci_add_in_port(xhci, num_ports, addr,
-   (u8) XHCI_EXT_PORT_MAJOR(cap_id));
+   (u8) XHCI_EXT_PORT_MAJOR(cap_id),
+   cap_count);
offset = XHCI_EXT_CAPS_NEXT(cap_id);
if (!offset || (xhci-num_usb2_ports + xhci-num_usb3_ports)
== num_ports)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b4aa79d..e540a36 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4023,15 +4023,40 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
return 0;
 }
 
+/* check if a usb2 port supports a given extened capability protocol
+ * only USB2 ports extended protocol capability values are cached.
+ * Return 1 if capability is supported
+ */
+static int xhci_check_usb2_port_capability(struct xhci_hcd *xhci, int port,
+  unsigned capability)
+{
+   u32 port_offset, port_count;
+   int i;
+
+   for (i = 0; i  xhci-num_ext_caps; i++) {
+   if (xhci-ext_caps[i]  capability) {
+   /* port offsets starts at 1 */
+   port_offset = XHCI_EXT_PORT_OFF(xhci-ext_caps[i]) - 1;
+   port_count = XHCI_EXT_PORT_COUNT(xhci-ext_caps[i]);
+   if (port = port_offset 
+   port  port_offset + port_count)
+   return 1;
+   }
+   }
+   return 0;
+}
+
 int xhci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
 {
struct xhci_hcd *xhci = hcd_to_xhci(hcd);

[RFC PATCH 2/4] usb: xhci: define port register names and use them instead of magic numbers

2013-05-17 Thread Mathias Nyman 
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
 drivers/usb/host/xhci-hub.c |   16 +++-
 drivers/usb/host/xhci.c |4 ++--
 drivers/usb/host/xhci.h |5 +
 3 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 187a3ec..1d35459 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -867,18 +867,18 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
u16 wValue,
case USB_PORT_FEAT_U1_TIMEOUT:
if (hcd-speed != HCD_USB3)
goto error;
-   temp = xhci_readl(xhci, port_array[wIndex] + 1);
+   temp = xhci_readl(xhci, port_array[wIndex] + PORTPMSC);
temp = ~PORT_U1_TIMEOUT_MASK;
temp |= PORT_U1_TIMEOUT(timeout);
-   xhci_writel(xhci, temp, port_array[wIndex] + 1);
+   xhci_writel(xhci, temp, port_array[wIndex] + PORTPMSC);
break;
case USB_PORT_FEAT_U2_TIMEOUT:
if (hcd-speed != HCD_USB3)
goto error;
-   temp = xhci_readl(xhci, port_array[wIndex] + 1);
+   temp = xhci_readl(xhci, port_array[wIndex] + PORTPMSC);
temp = ~PORT_U2_TIMEOUT_MASK;
temp |= PORT_U2_TIMEOUT(timeout);
-   xhci_writel(xhci, temp, port_array[wIndex] + 1);
+   xhci_writel(xhci, temp, port_array[wIndex] + PORTPMSC);
break;
default:
goto error;
@@ -1098,10 +1098,8 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
__le32 __iomem *addr;
u32 tmp;
 
-   /* Add one to the port status register address to get
-* the port power control register address.
-*/
-   addr = port_array[port_index] + 1;
+   /* Get the port power control register address. */
+   addr = port_array[port_index] + PORTPMSC;
tmp = xhci_readl(xhci, addr);
tmp |= PORT_RWE;
xhci_writel(xhci, tmp, addr);
@@ -1193,7 +1191,7 @@ int xhci_bus_resume(struct usb_hcd *hcd)
/* Add one to the port status register address to get
 * the port power control register address.
 */
-   addr = port_array[port_index] + 1;
+   addr = port_array[port_index] + PORTPMSC;
tmp = xhci_readl(xhci, addr);
tmp = ~PORT_RWE;
xhci_writel(xhci, tmp, addr);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index e540a36..317bf08 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3901,7 +3901,7 @@ static int xhci_usb2_software_lpm_test(struct usb_hcd 
*hcd,
 * Check device's USB 2.0 extension descriptor to determine whether
 * HIRD or BESL shoule be used. See USB2.0 LPM errata.
 */
-   pm_addr = port_array[port_num] + 1;
+   pm_addr = port_array[port_num] + PORTPMSC;
hird = xhci_calculate_hird_besl(xhci, udev);
temp = PORT_L1DS(udev-slot_id) | PORT_HIRD(hird);
xhci_writel(xhci, temp, pm_addr);
@@ -3999,7 +3999,7 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
 
port_array = xhci-usb2_ports;
port_num = udev-portnum - 1;
-   pm_addr = port_array[port_num] + 1;
+   pm_addr = port_array[port_num] + PORTPMSC;
temp = xhci_readl(xhci, pm_addr);
 
xhci_dbg(xhci, %s port %d USB2 hardware LPM\n,
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 1dbc63f..b6cd55e 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -132,6 +132,11 @@ struct xhci_cap_regs {
 /* Number of registers per port */
 #defineNUM_PORT_REGS   4
 
+#define PORTSC 0
+#define PORTPMSC   1
+#define PORTLI 2
+#define PORTHLPMC  3
+
 /**
  * struct xhci_op_regs - xHCI Host Controller Operational Registers.
  * @command:   USBCMD - xHC command register
-- 
1.7.4.1

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

[RFC PATCH 3/4] usb: xhci: add USB2 Link power management BESL support

2013-05-17 Thread Mathias Nyman 
usb 2.0 devices with link power managment (LPM) can describe their idle link
timeouts either in BESL or HIRD format, so far xHCI has only supported HIRD but
later xHCI errata add BESL support as well

BESL timeouts need to inform exit latency changes with an evaluate
context command the same way USB 3.0 link PM code does.
The same xhci_change_max_exit_latency() function is used as with USB3
but code is pulled out from #ifdef CONFIG_PM as USB2.0 BESL LPM
funcionality does not depend on CONFIG_PM.

Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
 drivers/usb/host/xhci-ext-caps.h |1 +
 drivers/usb/host/xhci.c  |  201 ++
 drivers/usb/host/xhci.h  |   23 +
 include/linux/usb.h  |2 +
 4 files changed, 163 insertions(+), 64 deletions(-)

diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index 377f424..8d7a132 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -71,6 +71,7 @@
 
 /* USB 2.0 xHCI 1.0 hardware LMP capability - section 7.2.2.1.3.2 */
 #define XHCI_HLC   (1  19)
+#define XHCI_BLC   (1  19)
 
 /* command register values to disable interrupts and halt the HC */
 /* start/stop HC execution - do not write unless HC is halted*/
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 317bf08..22932d9 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3805,6 +3805,56 @@ int xhci_find_raw_port_number(struct usb_hcd *hcd, int 
port1)
return raw_port;
 }
 
+/*
+ * Issue an Evaluate Context command to change the Maximum Exit Latency in the
+ * slot context.  If that succeeds, store the new MEL in the xhci_virt_device.
+ */
+static int xhci_change_max_exit_latency(struct xhci_hcd *xhci,
+   struct usb_device *udev, u16 max_exit_latency)
+{
+   struct xhci_virt_device *virt_dev;
+   struct xhci_command *command;
+   struct xhci_input_control_ctx *ctrl_ctx;
+   struct xhci_slot_ctx *slot_ctx;
+   unsigned long flags;
+   int ret;
+
+   spin_lock_irqsave(xhci-lock, flags);
+   if (max_exit_latency == xhci-devs[udev-slot_id]-current_mel) {
+   spin_unlock_irqrestore(xhci-lock, flags);
+   return 0;
+   }
+
+   /* Attempt to issue an Evaluate Context command to change the MEL. */
+   virt_dev = xhci-devs[udev-slot_id];
+   command = xhci-lpm_command;
+   xhci_slot_copy(xhci, command-in_ctx, virt_dev-out_ctx);
+   spin_unlock_irqrestore(xhci-lock, flags);
+
+   ctrl_ctx = xhci_get_input_control_ctx(xhci, command-in_ctx);
+   ctrl_ctx-add_flags |= cpu_to_le32(SLOT_FLAG);
+   slot_ctx = xhci_get_slot_ctx(xhci, command-in_ctx);
+   slot_ctx-dev_info2 = cpu_to_le32(~((u32) MAX_EXIT));
+   slot_ctx-dev_info2 |= cpu_to_le32(max_exit_latency);
+
+   xhci_dbg(xhci, Set up evaluate context for LPM MEL change.\n);
+   xhci_dbg(xhci, Slot %u Input Context:\n, udev-slot_id);
+   xhci_dbg_ctx(xhci, command-in_ctx, 0);
+
+   /* Issue and wait for the evaluate context command. */
+   ret = xhci_configure_endpoint(xhci, udev, command,
+   true, true);
+   xhci_dbg(xhci, Slot %u Output Context:\n, udev-slot_id);
+   xhci_dbg_ctx(xhci, virt_dev-out_ctx, 0);
+
+   if (!ret) {
+   spin_lock_irqsave(xhci-lock, flags);
+   virt_dev-current_mel = max_exit_latency;
+   spin_unlock_irqrestore(xhci-lock, flags);
+   }
+   return ret;
+}
+
 #ifdef CONFIG_PM_RUNTIME
 
 /* BESL to HIRD Encoding array for USB2 LPM */
@@ -3846,6 +3896,25 @@ static int xhci_calculate_hird_besl(struct xhci_hcd 
*xhci,
return besl;
 }
 
+/* Calculate BESLD, L1 timeout and HIRDM for USB2 PORTHLPMC */
+static int xhci_calculate_usb2_hw_lpm_params(struct usb_device *udev)
+{
+   u32 field;
+   int l1 =  XHCI_L1_TIMEOUT;
+   int besld = 0;
+   int hirdm = 0;
+
+   field = le32_to_cpu(udev-bos-ext_cap-bmAttributes);
+
+   /* device has preferred BESLD */
+   if (field  USB_BESL_DEEP_VALID) {
+   besld = USB_GET_BESL_DEEP(field);
+   hirdm = 1;
+   }
+
+   return PORT_BESLD(besld) | PORT_L1_TIMEOUT(l1) | PORT_HIRDM(hirdm);
+}
+
 static int xhci_usb2_software_lpm_test(struct usb_hcd *hcd,
struct usb_device *udev)
 {
@@ -3978,11 +4047,12 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
 {
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
__le32 __iomem  **port_array;
-   __le32 __iomem  *pm_addr;
-   u32 temp;
+   __le32 __iomem  *pm_addr, *hlpm_addr;
+   u32 pm_val, hlpm_val, field;
unsigned intport_num;
unsigned long   flags;
-   int hird;
+   int hird, exit_latency;
+   int ret;
 
if (hcd-speed == HCD_USB3 ||

Re: [PATCH v7 7/9] rcar-phy: add platform data

2013-05-17 Thread Felipe Balbi 
On Wed, May 01, 2013 at 03:00:30AM +0400, Sergei Shtylyov wrote:
 Currently the driver hard-codes  USBPCTRL0 register to 0. It is wrong since 
 this
 register contains board-specific USB ports configuration and so its value 
 should
 be somehow passed via the platform data.  Add the global header file 
 containing
 'struct rcar_phy_platform_data' consisting of the various bit fields 
 describing
 USB ports' pin configuration.
 
 Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
 Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
 Acked-by: Simon Horman horms+rene...@verge.net.au

Acked-by: Felipe Balbi ba...@ti.com

-- 
balbi


signature.asc
Description: Digital signature

Re: usb:is that a bug?

2013-05-17 Thread Alan Stern 
On Fri, 17 May 2013, linux fddl wrote:

 Hi,
 
 When I used mass_storage as a gadget

You should CC: the maintainer of the g_mass_storage driver.

 (use a linux-3.0.77 kernel),

That kernel is pretty old.  You would be much better off using 3.9.  
The problem you found may already have been fixed.

 After the following operations:
 
 1.Turn my board into hibernation.
 2.Plug the usb into host before resume.
 3.Resume my board.

The gadget subsystem does not work well with suspend or hibernation.  
You are better off plugging the board into the host after resume 
instead of before.

 I saw some dump message like this, after some digging,
 I think the other devices' retore time is too long to make the gadget
 fail to response
 the command(GET_MAX_LUN) from the host.

That's part of the reason you shouldn't connect the gadget to the host 
while the gadget is asleep.

 What I hope to know is:
   Is it a bug?
   or I need some operations to cooperate them?

I don't know.

Alan Stern

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

Re: Crash in dwc3 driver on module unload

2013-05-17 Thread Alan Stern 
On Fri, 17 May 2013, Peter Chen wrote:

  I found out a couple more things about this.
 
  If I do rmmod dwc3 first, and then do rmmod dwc3-pci, it doesn't
  crash.
 
 
 dwc3-pci will release dwc3 and its resources at its removal.
 So, dwc3 core must be released first, then glue layer.

That makes no sense.  Obviously dwc3 can't be removed until all its
resources have been released.  And you said that dwc3-pci doesn't
release the dwc3 resources until dwc3-pci has been removed.

Therefore dwc3 can't be removed until dwc3-pci has been removed.  This 
is exactly the opposite of what you wrote above.

 Since there are no relationship between core and glue
 layer, If user unload module in incorrect order, the oops
 may occur, the phy driver is the same situation.
 
 For such kinds of case, do we need to fix at kernel layer?
 or using user space method to fix?

There _should_ be a relationship between the core and the glue layer.  
The glue layer uses the core's resources; therefore the glue layer
should contain references to symbols that are defined in the core.  
This will cause the kernel to prevent the core from being removed
before the glue layer.

PHY drivers will need different treatment.  I suspect that the right 
approach is to increment the phy driver's module count each time an HCD 
claims a PHY.

Alan Stern

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

[PATCH 1/5] usb: add Atmel USBA UDC DT support

2013-05-17 Thread Jean-Christophe PLAGNIOL-VILLARD 
Allow to compile the driver all the time if AT91 enabled.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: linux-usb@vger.kernel.org
---
 .../devicetree/bindings/usb/atmel-usb.txt  |   82 
 drivers/usb/gadget/Kconfig |2 +-
 drivers/usb/gadget/atmel_usba_udc.c|  214 +++-
 drivers/usb/gadget/atmel_usba_udc.h|1 +
 4 files changed, 244 insertions(+), 55 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt 
b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 60bd215..878556b2 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -47,3 +47,85 @@ usb1: gadget@fffa4000 {
interrupts = 10 4;
atmel,vbus-gpio = pioC 5 0;
 };
+
+Atmel High-Speed USB device controller
+
+Required properties:
+ - compatible: Should be atmel,at91sam9rl-udc
+ - reg: Address and length of the register set for the device
+ - interrupts: Should contain macb interrupt
+ - ep childnode: To specifiy the number of endpoints and their properties.
+
+Optional properties:
+ - atmel,vbus-gpio: If present, specifies a gpio that needs to be
+   activated for the bus to be powered.
+
+Required child node properties:
+ - name: Name of the endpoint.
+ - reg: Num of the endpoint.
+ - atmel,fifo-size: Size of the fifo.
+ - atmel,nb-banks: Number of banks.
+ - atmel,can-dma: Boolean to specify if the endpoint support DMA.
+ - atmel,can-isoc: Boolean to specify if the endpoint support ISOC.
+
+usb2: gadget at fff78000 {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = atmel,at91sam9rl-udc;
+   reg = 0x0060 0x8
+  0xfff78000 0x400;
+   interrupts = 27 4;
+   atmel,vbus-gpio = pioB 19 0;
+
+   ep0 {
+   reg = 0;
+   atmel,fifo-size = 64;
+   atmel,nb-banks = 1;
+   };
+
+   ep1 {
+   reg = 1;
+   atmel,fifo-size = 1024;
+   atmel,nb-banks = 2;
+   atmel,can-dma;
+   atmel,can-isoc;
+   };
+
+   ep2 {
+   reg = 2;
+   atmel,fifo-size = 1024;
+   atmel,nb-banks = 2;
+   atmel,can-dma;
+   atmel,can-isoc;
+   };
+
+   ep3 {
+   reg = 3;
+   atmel,fifo-size = 1024;
+   atmel,nb-banks = 3;
+   atmel,can-dma;
+   };
+
+   ep4 {
+   reg = 4;
+   atmel,fifo-size = 1024;
+   atmel,nb-banks = 3;
+   atmel,can-dma;
+   };
+
+   ep5 {
+   reg = 5;
+   atmel,fifo-size = 1024;
+   atmel,nb-banks = 3;
+   atmel,can-dma;
+   atmel,can-isoc;
+   };
+
+   ep6 {
+   reg = 6;
+   atmel,fifo-size = 1024;
+   atmel,nb-banks = 3;
+   atmel,can-dma;
+   atmel,can-isoc;
+   };
+};
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 83300d9..5e47d50 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -156,7 +156,7 @@ config USB_LPC32XX
 
 config USB_ATMEL_USBA
tristate Atmel USBA
-   depends on AVR32 || ARCH_AT91SAM9RL || ARCH_AT91SAM9G45
+   depends on AVR32 || ARCH_AT91
help
  USBA is the integrated high-speed USB Device controller on
  the AT32AP700x, some AT91SAM9 and AT91CAP9 processors from Atmel.
diff --git a/drivers/usb/gadget/atmel_usba_udc.c 
b/drivers/usb/gadget/atmel_usba_udc.c
index f2a970f..b3084b9 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -22,6 +22,8 @@
 #include linux/usb/atmel_usba_udc.h
 #include linux/delay.h
 #include linux/platform_data/atmel.h
+#include linux/of.h
+#include linux/of_gpio.h
 
 #include asm/gpio.h
 
@@ -1835,9 +1837,143 @@ static int atmel_usba_stop(struct usb_gadget *gadget,
return 0;
 }
 
-static int __init usba_udc_probe(struct platform_device *pdev)
+#ifdef CONFIG_OF
+static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
+   struct usba_udc *udc)
+{
+   u32 val;
+   const char *name;
+   enum of_gpio_flags flags;
+   struct device_node *np = pdev-dev.of_node;
+   struct device_node *pp;
+   int i, ret;
+   struct usba_ep *eps, *ep;
+
+   udc-num_ep = 0;
+
+   udc-vbus_pin = of_get_named_gpio_flags(np, atmel,vbus-gpio, 0,
+   flags);
+   udc-vbus_pin_inverted = (flags  OF_GPIO_ACTIVE_LOW) ? 1 : 0;
+
+   pp = NULL;
+   while ((pp = of_get_next_child(np, pp)))
+   udc-num_ep++;
+
+   eps = devm_kzalloc(pdev-dev, sizeof(struct usba_ep) * udc-num_ep,
+

Re: [RFC PATCH 4/4] usb: add usb2 Link PM variables to sysfs and usb_device

2013-05-17 Thread Alan Stern 
On Fri, 17 May 2013, Mathias Nyman wrote:

 Adds abitilty to tune L1 timeout (inactivity timer for usb2 link sleep)
 and BESL (best effort service latency)via sysfs.
 
 This also adds a new usb2_lpm_parameters structure with those variables to
 struct usb_device.

 +static ssize_t
 +set_usb2_lpm_l1_timeout(struct device *dev, struct device_attribute *attr,
 + const char *buf, size_t count)
 +{
 + struct usb_device *udev = to_usb_device(dev);
 + int timeout;
 +
 + if (sscanf(buf, %d, timeout) != 1 || timeout  0 || timeout  255)
 + return -EINVAL;

New code should use the kstrto* family of functions.  You also could 
remove a test if you declared timeout to be unsigned instead of int.

Alan Stern

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

drivers/usb/core/devio.c, USB3.0 and arbitrary limit for USB2

2013-05-17 Thread Federico Manzan 

With USB2.0 the max isochronous size can be 3x1024 byte every 125us

With USB3.0 the max isochronous size can be 1x1024 byte * Mult * 
bMaxBurst every 125us

super speed companion descriptor. bMaxBurst (0~15 allowed, 1~16 packets)
super speed companion descriptor. bmAttributes (bit 1:0, mult 0~2)
Maximum number of packtes = (bMaxBurst + 1) x (Mult + 1)

if Mult=3 and bMaxBurst=1 (6 packets x 1024),  libusb can allocate and 
submit a isocronous,
with bMaxBurst=2 (9 packets x 1024), and more the fuction 
libusb_submit_transfer() return a errors, because:


in the file of kernel 3.8 and 3.9
drivers/usb/core/devio.c:
...
 for (totlen = u = 0; u  uurb-number_of_packets; u++) {
 /* arbitrary limit,
  * sufficient for USB 2.0 high-bandwidth iso */
 if (isopkt[u].length  8192) {
 ret = -EINVAL;
 goto error;
 }
 totlen += isopkt[u].length;
 }
...

Now with USB 3.0 this arbitrary limit need to increment at not less of 
1024 * 3 * 16 byte

What do you think?

Fede

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

Re: Question about dummy_hcd

2013-05-17 Thread Alan Stern 
On Fri, 17 May 2013, Jean-Edouard Lejosne wrote:

 Hi,
 
 I'm Jed, I'm currently using dummy_hcd and g_hid to fake a USB HID 
 device, and I'm struggling with a problem.
 
 I'm sorry to bother you by e-mail. If I should ask my question on an IRC 
 channel, could you please point me to the right one?

No; email is appropriate.  But discussions like this should be carried 
out on the public mailing list.

 Anyway, here it is. Everything works right now, my device is up and 
 running. It is just awfully slow! I'm simulating an 8 fingers touch 
 device, but the gadget can't keep up with more than 2.
 After a lot of debugging, I realized that dummy_hcd seems to send only 
 one packet every 50 msec, instead of flushing the endpoint queue. It 
 even looks like it is by design...

dummy-hcd is supposed to run at roughly the same rate as a real host
controller.  But it has not been updated to use hrtimers, so it is 
limited by the resolution of the timer tick.  And it doesn't take the 
timer resolution into account in the proper way.

 My question is: is there a reason for that? What would be a good way to 
 make it faster?
 I know kernel programming, I'm just new to USB, especially gadgets...

What is HZ configured to be on your system?  If you set it to 1000,
does that help?  (Note the FIXME comment on line 1684 of dummy_hcd.c.)

Alan Stern

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

Re: Question about dummy_hcd

2013-05-17 Thread Jean-Edouard Lejosne 

On 05/17/2013 03:16 PM, Alan Stern wrote:

On Fri, 17 May 2013, Jean-Edouard Lejosne wrote:


Hi,

I'm Jed, I'm currently using dummy_hcd and g_hid to fake a USB HID
device, and I'm struggling with a problem.

I'm sorry to bother you by e-mail. If I should ask my question on an IRC
channel, could you please point me to the right one?


No; email is appropriate.  But discussions like this should be carried
out on the public mailing list.


Anyway, here it is. Everything works right now, my device is up and
running. It is just awfully slow! I'm simulating an 8 fingers touch
device, but the gadget can't keep up with more than 2.
After a lot of debugging, I realized that dummy_hcd seems to send only
one packet every 50 msec, instead of flushing the endpoint queue. It
even looks like it is by design...


dummy-hcd is supposed to run at roughly the same rate as a real host
controller.  But it has not been updated to use hrtimers, so it is
limited by the resolution of the timer tick.  And it doesn't take the
timer resolution into account in the proper way.


My question is: is there a reason for that? What would be a good way to
make it faster?
I know kernel programming, I'm just new to USB, especially gadgets...


What is HZ configured to be on your system?  If you set it to 1000,
does that help?  (Note the FIXME comment on line 1684 of dummy_hcd.c.)


Thanks a lot for the pointer!
Setting HZ to 1000 indeed fixes the problem!

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

Re: [PATCH v4 3/8] ARM: tegra: update device trees for USB binding rework

2013-05-17 Thread Stephen Warren 
On 05/16/2013 05:02 PM, Stephen Warren wrote:
 On 05/16/2013 08:12 AM, Venu Byravarasu wrote:
 This patch updates all Tegra board files so that they contain all the
 properties required by the updated USB DT binding. Note that this patch
 only adds the new properties and does not yet remove the old properties,
 in order to maintain bisectability. The old properties will be removed
 once the driver has been updated to assume the new bindings.
 
 This series looks almost OK now. The one remaining issue is that in this
 patch, the regulator-name properties don't match the schematics, and in
 the Whistler patch below, both regulators you added have the same
 regulator-name, which causes problems.
 
 To fix this, when I apply this patch, I'm going to fold in the patch
 I'll paste below.
 
 Right now, I can't get Whistler to see the SD card. This is true even
 without your patches. Once I've resolved that and tested Whistler,
 assuming no more problems, I'll apply patches 1-3 to the Tegra tree, and
 set up a branch that can be pulled into the USB tree so the rest of the
 series can be applied there.

I've made Whistler boot by reverting a few commits entirely unrelated to
USB or your patch series. I'll investigate those later, but for not your
patches test out fine on Whistler. So, I'll apply patches 1-3 in the
series and set up the pull request for the USB tree. Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] ARM: tegra: DT-related fixes needed by the USB tree

2013-05-17 Thread Stephen Warren 
Felipe, (and Alan, Greg),

These are the changes from the Tegra tree that need to be merged
before the Tegra USB driver patches 4-8 from Venu can be applied. Recall
that we had previously agreed on this approach for v3.9, but Venu's
patches didn't end up being ready until now, unfortunately. I note
that Venu's patches affect both the Tegra USB and PHY drivers.

Following this, I will soon send some patches that fix up some ARM multi-
platform issues in the Tegra EHCI driver. Those won't affect the Tegra
USB PHY driver, but I do expect I'll want to rebase them on top of Venu's
series, since they will probably interact a bit with Venu's patches.

I also soon hope to see patches to:
* Convert the Tegra USB and PHY drivers from the vbus-gpios DT property
  to the new vbus-supply regulator. This will affect both drivers, and
  I really hope will happen soon.
* Add support for Tegra30 and Tegra114 SoCs. I expect this would touch
  both the USB and PHY drivers. This may or may not happen in 3.11.

As such, there will be quite a lot of interaction between the Tegra USB
and PHY drivers in 3.10. I'll let you decide if it's better for them to
go through the main USB tree or the USB PHY tree, and hence who should
pull in this pull request.



Tag description:

The Tegra USB bindings were in bad shape. The patches in this branch
fix the binding definitions, and make all the necessary additions to
the DT files. Stale nodes/properties will be removed early in 3.12
once the USB driver has been updated for the new binding.

These changes are needed in both the USB tree, to allow the driver to
be updated to handle them, and the Tegra tree, so that various tree-
wide DT changes (e.g. conversion of IRQ/GPIO/clock constants to defines)
can be applied on top of them.



The following changes since commit f722406faae2d073cc1d01063d1123c35425939e:

  Linux 3.10-rc1

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git 
tegra-for-3.11-deps-for-usb

for you to fetch changes up to 4c94c8b5b3cc38b0d0b1ec79642f5710e19a3e01:

  ARM: tegra: update device trees for USB binding rework



Venu Byravarasu (3):
  ARM: tegra: finalize USB EHCI and PHY bindings
  ARM: tegra: modify ULPI reset GPIO properties
  ARM: tegra: update device trees for USB binding rework

 .../bindings/usb/nvidia,tegra20-ehci.txt|   27 ++
 .../bindings/usb/nvidia,tegra20-usb-phy.txt |   41 +--
 arch/arm/boot/dts/tegra20-colibri-512.dtsi  |6 ++-
 arch/arm/boot/dts/tegra20-harmony.dts   |   15 --
 arch/arm/boot/dts/tegra20-iris-512.dts  |9 +++-
 arch/arm/boot/dts/tegra20-paz00.dts |   15 --
 arch/arm/boot/dts/tegra20-seaboard.dts  |   26 --
 arch/arm/boot/dts/tegra20-tamonten.dtsi |4 ++
 arch/arm/boot/dts/tegra20-trimslice.dts |   25 +++--
 arch/arm/boot/dts/tegra20-ventana.dts   |   15 --
 arch/arm/boot/dts/tegra20-whistler.dts  |   28 ++
 arch/arm/boot/dts/tegra20.dtsi  |   49 +-
 12 files changed, 206 insertions(+), 54 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question about generic HID devices

2013-05-17 Thread Daniel Santos 
Hello.  I'm working on a driver for a USB to SPI bridge chip 
(Microchip's MCP2210) that acts as a HID device (generic subclass). Of 
course, it can be used from user-space via hid-generic, but I'm not 
really interested in that. I started this work from somebody else's 
implementation that was a HID-based driver, but didn't like the 
requirement to allocate 6k of data for the report for each 64 byte 
rep/req so I started over as a plane-jane USB driver.  I suppose this 
was a bit naive, having never written a USB driver before, I guess I 
relish challenges.  Also, I'm intending to use this driver on a 
low-memory embedded device.


So I have the basics of my driver all working, sending 64 byte interrupt 
URB requests (as per the datasheet - 
http://ww1.microchip.com/downloads/en/DeviceDoc/22288A.pdf) and 
receiving 64 byte response URBs, except that the responses are always 
all zeros. :(  So I ran usbmon and observed the traffic when the 
hid-core and hid-generic drivers use it and noticed quite a bit of 
traffic on the control endpoint leaving me guessing that this is some 
type of HID protocol that I naively omitted and that the chip just 
doesn't respond on it's interrupt endpoints until some HID thing happens 
on the control endpoint.


My other thought was that I was perhaps I'm just not waiting long enough 
before submitting the response URB (maybe the chip needs a little time 
to process the request and just returns all zeros when it doesn't have 
anything to say yet?) -- but to test this theory, I'll need to implement 
some type of bottom half (work queue or something).  I am supplying the 
interrupt interval specified by bInterval (which is 1, meaning 125 uS if 
I understand correctly).


Anyway, if somebody has some advice, I would greatly appreciate it. I'm 
combing through the USB 2 spec to try to find where the HID protocol is 
covered, but maybe that's an entirely different spec? Advice greatly 
appreciated!!


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

Re: Question about generic HID devices

2013-05-17 Thread Greg KH 
On Fri, May 17, 2013 at 06:14:28PM -0500, Daniel Santos wrote:
 Anyway, if somebody has some advice, I would greatly appreciate it.
 I'm combing through the USB 2 spec to try to find where the HID
 protocol is covered, but maybe that's an entirely different spec?
 Advice greatly appreciated!!

The HID protocol is a separate specification, see the usb-if.org web
site for it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html