[PATCH 0/5] usb: musb: am335x support

[PATCH 0/5] usb: musb: am335x support

[Afzal Mohammed]

Hi Balbi,

This series adds usb support to am335x SoC's found on boards like
Beagle Bone. Here only first instance is supported, as currently
multiple phy's of same type is not supported (am335x has two USB2
phy's).

This series is based on your musb branch,
 (HEAD - 2f77116 usb: musb: remove hand-crafted id handling)
and is made over my series,
 (usb: musb: dsps: fixes for -rc)
and has been tested on Beagle Bone by ethernet gadget.

First two may qualify as -rc material, with these two it is actually
possible to get USB working assuming bootloader leaves phy enabled
and provides Kernel with DT blob.

Last one configures control module to enable bultin phy.

Proper solution is to make use of control module driver, but it is
not expected to be ready soon and this would block USB support for
am335x.

Here dsps wrapper driver is provided with control module register
physical address. Even though this a hack, there is no other option
left till control module driver is ready. As of now only am335x is
using dsps wrapper, and so driver is made aware of am335x control
module physical address.

Please note that this is a temporary arrangment till omap control
module driver is available.

Other options are providing control module register space as memory
resource via DT or using omap hwmod.

DT approach has been rejected by Rob Herring, while resources are
being moved from hwmod to DT. And both of the above approaches
require that control module registers be configured in wrapper driver
itself requring a quirk in driver as well as DT or hwmod.


Regards
Afzal 


Afzal Mohammed (4):
  usb: musb: dsps: remove platform callback
  usb: musb: dsps: reduce musb instance to one
  usb: musb: dsps: get resources by index
  usb: musb: dsps: dt binding - add resources, example

Santhapuri, Damodar (1):
  usb: musb: dsps: control module handling (quirk)

 .../devicetree/bindings/usb/am33xx-usb.txt         | 21 +++++
 drivers/usb/musb/musb_dsps.c                       | 95 ++++++++++++++++------
 2 files changed, 89 insertions(+), 27 deletions(-)

-- 
1.7.12

[PATCH 1/5] usb: musb: dsps: remove platform callback

[Afzal Mohammed]

dsps wrapper is dt only, it cannot execute platform callbacks.
Presence of this would cause NULL dereference, hence remove it.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 drivers/usb/musb/musb_dsps.c | 26 --------------------------
 1 file changed, 26 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 625400f..2396bcd 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -365,11 +365,9 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
 static int dsps_musb_init(struct musb *musb)
 {
 	struct device *dev = musb->controller;
-	struct musb_hdrc_platform_data *plat = dev->platform_data;
 	struct platform_device *pdev = to_platform_device(dev);
 	struct dsps_glue *glue = dev_get_drvdata(dev->parent);
 	const struct dsps_musb_wrapper *wrp = glue->wrp;
-	struct omap_musb_board_data *data = plat->board_data;
 	void __iomem *reg_base = musb->ctrl_base;
 	u32 rev, val;
 	int status;
@@ -395,10 +393,6 @@ static int dsps_musb_init(struct musb *musb)
 	/* Reset the musb */
 	dsps_writel(reg_base, wrp->control, (1 << wrp->reset));
 
-	/* Start the on-chip PHY and its PLL. */
-	if (data->set_phy_power)
-		data->set_phy_power(1);
-
 	musb->isr = dsps_interrupt;
 
 	/* reset the otgdisable bit, needed for host mode to work */
@@ -419,17 +413,11 @@ err0:
 static int dsps_musb_exit(struct musb *musb)
 {
 	struct device *dev = musb->controller;
-	struct musb_hdrc_platform_data *plat = dev->platform_data;
-	struct omap_musb_board_data *data = plat->board_data;
 	struct platform_device *pdev = to_platform_device(dev);
 	struct dsps_glue *glue = dev_get_drvdata(dev->parent);
 
 	del_timer_sync(&glue->timer[pdev->id]);
 
-	/* Shutdown the on-chip PHY and its PLL. */
-	if (data->set_phy_power)
-		data->set_phy_power(0);
-
 	/* NOP driver needs change if supporting dual instance */
 	usb_put_phy(musb->xceiv);
 	usb_nop_xceiv_unregister();
@@ -650,25 +638,11 @@ static int __devexit dsps_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int dsps_suspend(struct device *dev)
 {
-	struct musb_hdrc_platform_data *plat = dev->platform_data;
-	struct omap_musb_board_data *data = plat->board_data;
-
-	/* Shutdown the on-chip PHY and its PLL. */
-	if (data->set_phy_power)
-		data->set_phy_power(0);
-
 	return 0;
 }
 
 static int dsps_resume(struct device *dev)
 {
-	struct musb_hdrc_platform_data *plat = dev->platform_data;
-	struct omap_musb_board_data *data = plat->board_data;
-
-	/* Start the on-chip PHY and its PLL. */
-	if (data->set_phy_power)
-		data->set_phy_power(1);
-
 	return 0;
 }
 #endif
-- 
1.7.12

[PATCH 2/5] usb: musb: dsps: reduce musb instance to one

[Afzal Mohammed]

Currently multiple phy's of the same type are not supported, hence
reduce musb instances to one. This helps in supporting at least one
instance of musb, rather than having none. Even without this, it was
observed that both instances were working (by luck), but this holds
good iff wrapper is part of Image. And it is not correct for both
controller's to be associated with same phy, here it was working
because phy is a nop one. And having wrapper as a module and
rmmod'ing would crash.

This can be reverted once multi phy support for same type is available
and driver is enhanced to make use of it.

Signed-off-by: Afzal Mohammed <afzal-l0cyMroinI0@public.gmane.org>
---
 drivers/usb/musb/musb_dsps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2396bcd..524c003 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -677,7 +677,7 @@ static const struct dsps_musb_wrapper ti81xx_driver_data __devinitconst = {
 	.rxep_bitmap		= (0xfffe << 16),
 	.musb_core_offset	= 0x400,
 	.poll_seconds		= 2,
-	.instances		= 2,
+	.instances		= 1,
 };
 
 static const struct platform_device_id musb_dsps_id_table[] __devinitconst = {
-- 
1.7.12

--
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 3/5] usb: musb: dsps: get resources by index

[Afzal Mohammed]

dsps wrapper is now dt only. This requires that resources be obtained
using index and not name, modify accordingly.

Signed-off-by: Afzal Mohammed <afzal-l0cyMroinI0@public.gmane.org>
---
 drivers/usb/musb/musb_dsps.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 524c003..c90e4d3 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -450,22 +450,20 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue *glue, u8 id)
 	char res_name[10];
 	int ret;
 
-	/* get memory resource */
-	sprintf(res_name, "musb%d", id);
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, res_name);
+	/* first resource is for usbss, so start index from 1 */
+	res = platform_get_resource(pdev, IORESOURCE_MEM, id + 1);
 	if (!res) {
-		dev_err(dev, "%s get mem resource failed\n", res_name);
+		dev_err(dev, "failed to get memory for instance %d\n", id);
 		ret = -ENODEV;
 		goto err0;
 	}
 	res->parent = NULL;
 	resources[0] = *res;
 
-	/* get irq resource */
-	sprintf(res_name, "musb%d-irq", id);
-	res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, res_name);
+	/* first resource is for usbss, so start index from 1 */
+	res = platform_get_resource(pdev, IORESOURCE_IRQ, id + 1);
 	if (!res) {
-		dev_err(dev, "%s get irq resource failed\n", res_name);
+		dev_err(dev, "failed to get irq for instance %d\n", id);
 		ret = -ENODEV;
 		goto err0;
 	}
-- 
1.7.12

--
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 4/5] usb: musb: dsps: dt binding - add resources, example

[Afzal Mohammed]

OMAP2+ family of devices are now obtaining resources via DT, earlier
it was obtained from hwmod. Update binding document accrodingly, while
at it add example.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 .../devicetree/bindings/usb/am33xx-usb.txt          | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index a922505..6b7e3bd 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -1,5 +1,7 @@
 AM33XX MUSB GLUE
  - compatible : Should be "ti,musb-am33xx"
+ - reg : offset and length of register sets, first usbss, then for musb instances
+ - interrupts : usbss, musb instance interrupts in order
  - ti,hwmods : must be "usb_otg_hs"
  - multipoint : Should be "1" indicating the musb controller supports
    multipoint. This is a MUSB configuration-specific setting.
@@ -12,3 +14,22 @@ AM33XX MUSB GLUE
    represents PERIPHERAL.
  - power : Should be "250". This signifies the controller can supply upto
    500mA when operating in host mode.
+
+Example:
+
+usb_otg_hs@47400000  {
+	compatible = "ti,musb-am33xx";
+	reg = <0x47400000 0x1000	/* usbss */
+	       0x47401000 0x800		/* musb instance 0 */
+	       0x47401800 0x800>;	/* musb instance 1 */
+	interrupts = <17		/* usbss */
+		      18		/* musb instance 0 */
+		      19>;		/* musb instance 1 */
+	multipoint = <1>;
+	num-eps = <16>;
+	ram-bits = <12>;
+	port0-mode = <3>;
+	port1-mode = <3>;
+	power = <250>;
+	ti,hwmods = "usb_otg_hs";
+};
-- 
1.7.12

[PATCH 5/5] usb: musb: dsps: control module handling (quirk)

[Afzal Mohammed]

From: "Santhapuri, Damodar" <damodar.santhapuri@ti.com>

am335x uses nop transceiver driver and need to enable builtin phy
by writing into usb_ctrl register available in system control
module register space. This is being added at musb glue driver
layer until a separate system control module driver is available.

Proper solution is to make use of control module driver, but it is
not expected to be ready soon.

Other options available are providing control module register space
as memory resource via DT or using omap hwmod.

DT approach has been rejected by Rob Herring, while resources are
being moved from hwmod to DT. And both of the above approaches
require that control module registers be configured in wrapper
itself requring a quirk in driver as well as DT or hwmod.

Here another option is used, providing driver with control module
register physical address. Even though this a hack, there is no other
option left till control module driver is ready. As of now only
am335x is using dsps wrapper, and so driver is made aware of am335x
control module physical address.

Please note that this is a temporary arrangment till omap control
module driver is available.

[afzal@ti.com: limit quirk to dsps wrapper]

Signed-off-by: Santhapuri, Damodar <damodar.santhapuri@ti.com>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 drivers/usb/musb/musb_dsps.c | 69 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index c90e4d3..e770f79 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -124,8 +124,44 @@ struct dsps_glue {
 	const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
 	struct timer_list timer[2];	/* otg_workaround timer */
 	unsigned long last_timer[2];    /* last timer data for each instance */
+	u32 __iomem *usb_ctrl[2];
 };
 
+#define	DSPS_AM33XX_CONTROL_MODULE_PHYS_0	0x44e10620
+#define	DSPS_AM33XX_CONTROL_MODULE_PHYS_1	0x44e10628
+
+static const resource_size_t dsps_control_module_phys[] = {
+	DSPS_AM33XX_CONTROL_MODULE_PHYS_0,
+	DSPS_AM33XX_CONTROL_MODULE_PHYS_1,
+};
+
+/**
+ * musb_dsps_phy_control - phy on/off
+ * @glue: struct dsps_glue *
+ * @id: musb instance
+ * @on: flag for phy to be switched on or off
+ *
+ * This is to enable the PHY using usb_ctrl register in system control
+ * module space.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 id, u8 on)
+{
+	u32 usbphycfg;
+
+	usbphycfg = readl(glue->usb_ctrl[id]);
+
+	if (on) {
+		usbphycfg &= ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN);
+		usbphycfg |= USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN;
+	} else {
+		usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
+	}
+
+	writel(usbphycfg, glue->usb_ctrl[id]);
+}
 /**
  * dsps_musb_enable - enable interrupts
  */
@@ -393,6 +429,9 @@ static int dsps_musb_init(struct musb *musb)
 	/* Reset the musb */
 	dsps_writel(reg_base, wrp->control, (1 << wrp->reset));
 
+	/* Start the on-chip PHY and its PLL. */
+	musb_dsps_phy_control(glue, pdev->id, 1);
+
 	musb->isr = dsps_interrupt;
 
 	/* reset the otgdisable bit, needed for host mode to work */
@@ -418,6 +457,9 @@ static int dsps_musb_exit(struct musb *musb)
 
 	del_timer_sync(&glue->timer[pdev->id]);
 
+	/* Shutdown the on-chip PHY and its PLL. */
+	musb_dsps_phy_control(glue, pdev->id, 0);
+
 	/* NOP driver needs change if supporting dual instance */
 	usb_put_phy(musb->xceiv);
 	usb_nop_xceiv_unregister();
@@ -450,6 +492,17 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue *glue, u8 id)
 	char res_name[10];
 	int ret;
 
+	resources[0].start = dsps_control_module_phys[id];
+	resources[0].end = resources[0].start + SZ_4 - 1;
+	resources[0].flags = IORESOURCE_MEM;
+
+	glue->usb_ctrl[id] = devm_request_and_ioremap(&pdev->dev, resources);
+	if (glue->usb_ctrl[id] == NULL) {
+		dev_err(dev, "Failed to obtain usb_ctrl%d memory\n", id);
+		ret = -ENODEV;
+		goto err0;
+	}
+
 	/* first resource is for usbss, so start index from 1 */
 	res = platform_get_resource(pdev, IORESOURCE_MEM, id + 1);
 	if (!res) {
@@ -636,11 +689,27 @@ static int __devexit dsps_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int dsps_suspend(struct device *dev)
 {
+	struct platform_device *pdev = to_platform_device(dev->parent);
+	struct dsps_glue *glue = platform_get_drvdata(pdev);
+	const struct dsps_musb_wrapper *wrp = glue->wrp;
+	int i;
+
+	for (i = 0; i < wrp->instances; i++)
+		musb_dsps_phy_control(glue, i, 0);
+
 	return 0;
 }
 
 static int dsps_resume(struct device *dev)
 {
+	struct platform_device *pdev = to_platform_device(dev->parent);
+	struct dsps_glue *glue = platform_get_drvdata(pdev);
+	const struct dsps_musb_wrapper *wrp = glue->wrp;
+	int i;
+
+	for (i = 0; i < wrp->instances; i++)
+		musb_dsps_phy_control(glue, i, 1);
+
 	return 0;
 }
 #endif
-- 
1.7.12

Re: [PATCH 0/5] usb: musb: am335x support

[Daniel Mack]

Hi Afzal,

On 02.11.2012 17:31, Afzal Mohammed wrote:
> This series adds usb support to am335x SoC's found on boards like
> Beagle Bone. Here only first instance is supported, as currently
> multiple phy's of same type is not supported (am335x has two USB2
> phy's).

I'm testing these patches with an AM33xx board that has the first musb
port wired to an USB type A plug, but it doesn't yet work for me.

The messages I'm getting are:

[    1.219339] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.226568] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.233444] usbcore: registered new interface driver uas
[    1.239066] Initializing USB Mass Storage driver...
[    1.244395] usbcore: registered new interface driver usb-storage
[    1.250732] USB Mass Storage support registered.
[    1.255573] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[    1.262671] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
[    1.262889] musb-hdrc: MHDRC RTL version 2.0
[    1.262907] musb-hdrc: setup fifo_mode 4
[    1.262940] musb-hdrc: 28/31 max ep, 16384/16384 memory

So there is no host interface registered. I'm unsure on how to fix this,
and I didn't get an answer yet to that question when I asked Felipe
about how interface drivers like dsps are supposed to act in order to
get host mode back after the recent musb cleanups.

What type of hardware do you test this with? Does host mode work for you?


Many thanks,
Daniel

RE: [PATCH 0/5] usb: musb: am335x support

[B, Ravi]

> 
> On 02.11.2012 17:31, Afzal Mohammed wrote:
> > This series adds usb support to am335x SoC's found on boards like 
> > Beagle Bone. Here only first instance is supported, as currently 
> > multiple phy's of same type is not supported (am335x has two USB2 
> > phy's).
> 
> I'm testing these patches with an AM33xx board that has the 
> first musb port wired to an USB type A plug, but it doesn't 
> yet work for me.
> 
> The messages I'm getting are:
> 
> [    1.219339] ehci_hcd: USB 2.0 'Enhanced' Host Controller 
> (EHCI) Driver
> [    1.226568] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver

Why ehci, ohci has selected for am335xx platform?

> [    1.233444] usbcore: registered new interface driver uas
> [    1.239066] Initializing USB Mass Storage driver...
> [    1.244395] usbcore: registered new interface driver usb-storage
> [    1.250732] USB Mass Storage support registered.
> [    1.255573] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
> [    1.262671] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
> combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
> [    1.262889] musb-hdrc: MHDRC RTL version 2.0
> [    1.262907] musb-hdrc: setup fifo_mode 4
> [    1.262940] musb-hdrc: 28/31 max ep, 16384/16384 memory
> 
> So there is no host interface registered. I'm unsure on how 

The host interface will be registered when you load the gadget driver, (like insmod g_zero.ko ,etc).

> to fix this, and I didn't get an answer yet to that question 
> when I asked Felipe about how interface drivers like dsps are 
> supposed to act in order to get host mode back after the 
> recent musb cleanups.
> 
> What type of hardware do you test this with? Does host mode 
> work for you?
> 

By default only otg build is supported, you must insert the gadget module for each usb port in order to enable the host/device functionality. Have you checked with loading any gadget module (g_ether.ko, or g_ether.ko etc)? 

-RaviBabu
> 
> Many thanks,
> Daniel
> 
> 
> 

RE: [PATCH 0/5] usb: musb: am335x support

[Mohammed, Afzal]

Hi Daniel,

* Daniel Mack, November 03, 2012 1:06 AM:

> I'm testing these patches with an AM33xx board that has the first musb
> port wired to an USB type A plug, but it doesn't yet work for me.

> So there is no host interface registered. I'm unsure on how to fix this,
> and I didn't get an answer yet to that question when I asked Felipe
> about how interface drivers like dsps are supposed to act in order to
> get host mode back after the recent musb cleanups.

> What type of hardware do you test this with? Does host mode work for you?

To add to those details mentioned by Ravi,

This was tested on Beagle Bone with USB0 as usb-ethernet.

For purely Kernel part, this series is sufficient (along with
dependency mentioned in cover letter), considering
the fact that dt node is strictly not a part of Kernel.

To test this series, node for usbss should be present in dt.
Example in dt documentation can be pasted onto dtsi file
to get USB0 working.

Alternatively, you can fetch from,

git://gitorious.org/x0148406-public/linux-kernel.git usb

it has dt updated with usbss node.

Regards
Afzal

Re: [PATCH 4/5] usb: musb: dsps: dt binding - add resources, example

[Felipe Balbi]

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

On Fri, Nov 02, 2012 at 10:02:47PM +0530, Afzal Mohammed wrote:
> OMAP2+ family of devices are now obtaining resources via DT, earlier
> it was obtained from hwmod. Update binding document accrodingly, while
> at it add example.
> 
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>  .../devicetree/bindings/usb/am33xx-usb.txt          | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> index a922505..6b7e3bd 100644
> --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> @@ -1,5 +1,7 @@
>  AM33XX MUSB GLUE
>   - compatible : Should be "ti,musb-am33xx"
> + - reg : offset and length of register sets, first usbss, then for musb instances
> + - interrupts : usbss, musb instance interrupts in order
>   - ti,hwmods : must be "usb_otg_hs"
>   - multipoint : Should be "1" indicating the musb controller supports
>     multipoint. This is a MUSB configuration-specific setting.
> @@ -12,3 +14,22 @@ AM33XX MUSB GLUE
>     represents PERIPHERAL.
>   - power : Should be "250". This signifies the controller can supply upto
>     500mA when operating in host mode.
> +
> +Example:
> +
> +usb_otg_hs@47400000  {

this should be usb@47400000.

> +	compatible = "ti,musb-am33xx";
> +	reg = <0x47400000 0x1000	/* usbss */
> +	       0x47401000 0x800		/* musb instance 0 */
> +	       0x47401800 0x800>;	/* musb instance 1 */
> +	interrupts = <17		/* usbss */
> +		      18		/* musb instance 0 */
> +		      19>;		/* musb instance 1 */
> +	multipoint = <1>;
> +	num-eps = <16>;
> +	ram-bits = <12>;
> +	port0-mode = <3>;
> +	port1-mode = <3>;
> +	power = <250>;
> +	ti,hwmods = "usb_otg_hs";
> +};
> -- 
> 1.7.12
> 

-- 
balbi

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

Re: [PATCH 4/5] usb: musb: dsps: dt binding - add resources, example

[Afzal Mohammed]

Hi Balbi,

On Tuesday 06 November 2012 06:32 PM, Felipe Balbi wrote:
> On Fri, Nov 02, 2012 at 10:02:47PM +0530, Afzal Mohammed wrote:

>> +Example:
>> +
>> +usb_otg_hs@47400000  {

> this should be usb@47400000.

Updated version with the above change has been posted.

Regards
Afzal
--
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 0/5] usb: musb: am335x support

[Daniel Mack]

Hi Afzal, everyone,

On 03.11.2012 08:33, Mohammed, Afzal wrote:
> * Daniel Mack, November 03, 2012 1:06 AM:
> 
>> I'm testing these patches with an AM33xx board that has the first musb
>> port wired to an USB type A plug, but it doesn't yet work for me.
> 
>> So there is no host interface registered. I'm unsure on how to fix this,
>> and I didn't get an answer yet to that question when I asked Felipe
>> about how interface drivers like dsps are supposed to act in order to
>> get host mode back after the recent musb cleanups.
> 
>> What type of hardware do you test this with? Does host mode work for you?
> 
> To add to those details mentioned by Ravi,
> 
> This was tested on Beagle Bone with USB0 as usb-ethernet.
> 
> For purely Kernel part, this series is sufficient (along with
> dependency mentioned in cover letter), considering
> the fact that dt node is strictly not a part of Kernel.
> 
> To test this series, node for usbss should be present in dt.
> Example in dt documentation can be pasted onto dtsi file
> to get USB0 working.

I have to pick up this old thread because I'm still having trouble
understanding how the AM335x musb driver is meant to be used as HCD.

I used to have it working based on 3.7 with a terrible hack that reverts
a couple of old commits partly. Now I started over with a fresh setup
based on Linus' current soon-to-be 3.9-rc tip, actually hoping that the
issues are solved.

On my board, the USB is purely used as host interface, with a type B
plug soldered. In the DT, I'm using the following sniplet in accordance
to the documentation of the bindings:

	usb_otg_hs: usb@47400000 {
		compatible = "ti,musb-am33xx";
		reg = <0x47400000 0x1000	/* usbss */
		       0x47401000 0x800		/* musb instance 0 */
		       0x47401800 0x800>;	/* musb instance 1 */
		interrupt-parent = <&intc>;
		interrupts = <17		/* usbss */
			      18		/* musb instance 0 */
			      19>;		/* musb instance 1 */
		multipoint = <1>;
		num-eps = <16>;
		ram-bits = <12>;
		port0-mode = <3>;
		port1-mode = <3>;
		power = <250>;
		ti,hwmods = "usb_otg_hs";
	};

The relevant config options are

CONFIG_USB_MUSB_HDRC=y
# CONFIG_USB_MUSB_TUSB6010 is not set
# CONFIG_USB_MUSB_OMAP2PLUS is not set
# CONFIG_USB_MUSB_AM35X is not set
CONFIG_USB_MUSB_DSPS=y
CONFIG_MUSB_PIO_ONLY=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_DEBUG=y
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_GADGET_DEBUG_FS=y
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
CONFIG_USB_GADGET_MUSB_HDRC=y
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_MIDI_GADGET is not set
CONFIG_USB_ZERO=m

At boot time, I only see the following message:

[    1.534776] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)

And when g_zero.ko is loaded, I get:

[   12.137023] udc musb-hdrc.0.auto: registering UDC driver [zero]
[   12.196906]  gadget: adding 'source/sink'/cec4e840 to config
'source/sink'/bf00d544
[   12.205800]  gadget: dual speed source/sink: IN/ep1in, OUT/ep1out,
ISO-IN/ep13, ISO-OUT/ep14
[   12.215862]  gadget: adding 'loopback'/cec4e7c0 to config
'loopback'/bf00d5b8
[   12.224321]  gadget: dual speed loopback: IN/ep1in, OUT/ep1out
[   12.231323]  gadget: Gadget Zero, version: Cinco de Mayo 2008
[   12.238164]  gadget: zero ready
[   12.242250] musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
[   12.249111] musb-hdrc musb-hdrc.0.auto: new USB bus registered,
assigned bus number 1
[   12.258151] musb-hdrc musb-hdrc.0.auto: supports USB remote wakeup
[   12.265507] usb usb1: default language 0x0409
[   12.271007] usb usb1: udev 1, busnum 1, minor = 0
[   12.276699] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   12.284632] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[   12.292992] usb usb1: Product: MUSB HDRC host driver
[   12.298959] usb usb1: Manufacturer: Linux 3.8.0-10238-gbfbdcec-dirty
musb-hcd
[   12.307166] usb usb1: SerialNumber: musb-hdrc.0.auto
[   12.323645] usb usb1: no of_node; not parsing pinctrl DT
[   12.330172] usb usb1: usb_probe_device
[   12.335181] usb usb1: configuration #1 chosen from 1 choice
[   12.342090] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[   12.355237] hub 1-0:1.0: no of_node; not parsing pinctrl DT
[   12.361988] hub 1-0:1.0: usb_probe_interface
[   12.367497] hub 1-0:1.0: usb_probe_interface - got id
[   12.373774] hub 1-0:1.0: USB hub found
[   12.378631] hub 1-0:1.0: 1 port detected
[   12.383515] hub 1-0:1.0: standalone hub
[   12.388330] hub 1-0:1.0: individual port power switching
[   12.394599] hub 1-0:1.0: no over-current protection
[   12.400497] hub 1-0:1.0: Single TT
[   12.404770] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns)
[   12.412203] hub 1-0:1.0: power on to power good time: 10ms
[   12.418776] hub 1-0:1.0: local power source is good
[   12.424812] hub 1-0:1.0: enabling power on all ports
[   12.527985] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
[   12.533836] hub 1-0:1.0: hub_suspend
[   12.537634] usb usb1: bus auto-suspend, wakeup 1

... but lsusb only shows the root hub, not the device which is connected
to the plug.

Also, when statically compiled into the kernel, the zero gadget driver
fails initialization with error code -2, but that's probably a whole
different story. Eventually, what I need is USB host support without
loading any module, as I boot the rootfs from USB under some circumstances.

I'm not sure what I'm missing here. Is there anything that needs extra
configuration to get this going? Is it worth debugging this deeper, or
is anyone else facing the same problem?


Thanks,
Daniel
--
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 0/5] usb: musb: am335x support

[Daniel Mack]

On 01.03.2013 22:57, Daniel Mack wrote:
> Hi Afzal, everyone,
> 
> On 03.11.2012 08:33, Mohammed, Afzal wrote:
>> * Daniel Mack, November 03, 2012 1:06 AM:
>>
>>> I'm testing these patches with an AM33xx board that has the first musb
>>> port wired to an USB type A plug, but it doesn't yet work for me.
>>
>>> So there is no host interface registered. I'm unsure on how to fix this,
>>> and I didn't get an answer yet to that question when I asked Felipe
>>> about how interface drivers like dsps are supposed to act in order to
>>> get host mode back after the recent musb cleanups.
>>
>>> What type of hardware do you test this with? Does host mode work for you?
>>
>> To add to those details mentioned by Ravi,
>>
>> This was tested on Beagle Bone with USB0 as usb-ethernet.
>>
>> For purely Kernel part, this series is sufficient (along with
>> dependency mentioned in cover letter), considering
>> the fact that dt node is strictly not a part of Kernel.
>>
>> To test this series, node for usbss should be present in dt.
>> Example in dt documentation can be pasted onto dtsi file
>> to get USB0 working.
> 
> I have to pick up this old thread because I'm still having trouble
> understanding how the AM335x musb driver is meant to be used as HCD.
> 
> I used to have it working based on 3.7 with a terrible hack that reverts
> a couple of old commits partly. Now I started over with a fresh setup
> based on Linus' current soon-to-be 3.9-rc tip, actually hoping that the
> issues are solved.
> 
> On my board, the USB is purely used as host interface, with a type B
> plug soldered. In the DT, I'm using the following sniplet in accordance
> to the documentation of the bindings:
> 
> 	usb_otg_hs: usb@47400000 {
> 		compatible = "ti,musb-am33xx";
> 		reg = <0x47400000 0x1000	/* usbss */
> 		       0x47401000 0x800		/* musb instance 0 */
> 		       0x47401800 0x800>;	/* musb instance 1 */
> 		interrupt-parent = <&intc>;
> 		interrupts = <17		/* usbss */
> 			      18		/* musb instance 0 */
> 			      19>;		/* musb instance 1 */
> 		multipoint = <1>;
> 		num-eps = <16>;
> 		ram-bits = <12>;
> 		port0-mode = <3>;
> 		port1-mode = <3>;

Btw, same happens for:

 		port0-mode = <1>;


Daniel

--
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 0/5] usb: musb: am335x support

[Koen Kooi]

On Fri, 2013-03-01 at 22:57 +0100, Daniel Mack wrote:
> Hi Afzal, everyone,
> 
> On 03.11.2012 08:33, Mohammed, Afzal wrote:
> > * Daniel Mack, November 03, 2012 1:06 AM:
> > 
> >> I'm testing these patches with an AM33xx board that has the first musb
> >> port wired to an USB type A plug, but it doesn't yet work for me.
> > 
> >> So there is no host interface registered. I'm unsure on how to fix this,
> >> and I didn't get an answer yet to that question when I asked Felipe
> >> about how interface drivers like dsps are supposed to act in order to
> >> get host mode back after the recent musb cleanups.
> > 
> >> What type of hardware do you test this with? Does host mode work for you?
> > 
> > To add to those details mentioned by Ravi,
> > 
> > This was tested on Beagle Bone with USB0 as usb-ethernet.
> > 
> > For purely Kernel part, this series is sufficient (along with
> > dependency mentioned in cover letter), considering
> > the fact that dt node is strictly not a part of Kernel.
> > 
> > To test this series, node for usbss should be present in dt.
> > Example in dt documentation can be pasted onto dtsi file
> > to get USB0 working.
> 
> I have to pick up this old thread because I'm still having trouble
> understanding how the AM335x musb driver is meant to be used as HCD.
> 
> I used to have it working based on 3.7 with a terrible hack that reverts
> a couple of old commits partly. Now I started over with a fresh setup
> based on Linus' current soon-to-be 3.9-rc tip, actually hoping that the
> issues are solved.
> 
> On my board, the USB is purely used as host interface, with a type B
> plug soldered. In the DT, I'm using the following sniplet in accordance
> to the documentation of the bindings:
> 
> 	usb_otg_hs: usb@47400000 {
> 		compatible = "ti,musb-am33xx";
> 		reg = <0x47400000 0x1000	/* usbss */
> 		       0x47401000 0x800		/* musb instance 0 */
> 		       0x47401800 0x800>;	/* musb instance 1 */
> 		interrupt-parent = <&intc>;
> 		interrupts = <17		/* usbss */
> 			      18		/* musb instance 0 */
> 			      19>;		/* musb instance 1 */
> 		multipoint = <1>;
> 		num-eps = <16>;
> 		ram-bits = <12>;
> 		port0-mode = <3>;
> 		port1-mode = <3>;
> 		power = <250>;
> 		ti,hwmods = "usb_otg_hs";
> 	};
> 
> The relevant config options are
> 
> CONFIG_USB_MUSB_HDRC=y
> # CONFIG_USB_MUSB_TUSB6010 is not set
> # CONFIG_USB_MUSB_OMAP2PLUS is not set
> # CONFIG_USB_MUSB_AM35X is not set
> CONFIG_USB_MUSB_DSPS=y
> CONFIG_MUSB_PIO_ONLY=y
> CONFIG_USB_GADGET=y
> CONFIG_USB_GADGET_DEBUG=y
> CONFIG_USB_GADGET_DEBUG_FILES=y
> CONFIG_USB_GADGET_DEBUG_FS=y
> CONFIG_USB_GADGET_VBUS_DRAW=2
> CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
> CONFIG_USB_GADGET_MUSB_HDRC=y
> # CONFIG_USB_GADGETFS is not set
> # CONFIG_USB_MIDI_GADGET is not set
> CONFIG_USB_ZERO=m
> 
> At boot time, I only see the following message:
> 
> [    1.534776] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
> 
> And when g_zero.ko is loaded, I get:
> 
> [   12.137023] udc musb-hdrc.0.auto: registering UDC driver [zero]
> [   12.196906]  gadget: adding 'source/sink'/cec4e840 to config
> 'source/sink'/bf00d544
> [   12.205800]  gadget: dual speed source/sink: IN/ep1in, OUT/ep1out,
> ISO-IN/ep13, ISO-OUT/ep14
> [   12.215862]  gadget: adding 'loopback'/cec4e7c0 to config
> 'loopback'/bf00d5b8
> [   12.224321]  gadget: dual speed loopback: IN/ep1in, OUT/ep1out
> [   12.231323]  gadget: Gadget Zero, version: Cinco de Mayo 2008
> [   12.238164]  gadget: zero ready
> [   12.242250] musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
> [   12.249111] musb-hdrc musb-hdrc.0.auto: new USB bus registered,
> assigned bus number 1
> [   12.258151] musb-hdrc musb-hdrc.0.auto: supports USB remote wakeup
> [   12.265507] usb usb1: default language 0x0409
> [   12.271007] usb usb1: udev 1, busnum 1, minor = 0
> [   12.276699] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [   12.284632] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [   12.292992] usb usb1: Product: MUSB HDRC host driver
> [   12.298959] usb usb1: Manufacturer: Linux 3.8.0-10238-gbfbdcec-dirty
> musb-hcd
> [   12.307166] usb usb1: SerialNumber: musb-hdrc.0.auto
> [   12.323645] usb usb1: no of_node; not parsing pinctrl DT
> [   12.330172] usb usb1: usb_probe_device
> [   12.335181] usb usb1: configuration #1 chosen from 1 choice
> [   12.342090] usb usb1: adding 1-0:1.0 (config #1, interface 0)
> [   12.355237] hub 1-0:1.0: no of_node; not parsing pinctrl DT
> [   12.361988] hub 1-0:1.0: usb_probe_interface
> [   12.367497] hub 1-0:1.0: usb_probe_interface - got id
> [   12.373774] hub 1-0:1.0: USB hub found
> [   12.378631] hub 1-0:1.0: 1 port detected
> [   12.383515] hub 1-0:1.0: standalone hub
> [   12.388330] hub 1-0:1.0: individual port power switching
> [   12.394599] hub 1-0:1.0: no over-current protection
> [   12.400497] hub 1-0:1.0: Single TT
> [   12.404770] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns)
> [   12.412203] hub 1-0:1.0: power on to power good time: 10ms
> [   12.418776] hub 1-0:1.0: local power source is good
> [   12.424812] hub 1-0:1.0: enabling power on all ports
> [   12.527985] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
> [   12.533836] hub 1-0:1.0: hub_suspend
> [   12.537634] usb usb1: bus auto-suspend, wakeup 1
> 
> ... but lsusb only shows the root hub, not the device which is connected
> to the plug.
> 
> Also, when statically compiled into the kernel, the zero gadget driver
> fails initialization with error code -2, but that's probably a whole
> different story. Eventually, what I need is USB host support without
> loading any module, as I boot the rootfs from USB under some circumstances.
> 
> I'm not sure what I'm missing here. Is there anything that needs extra
> configuration to get this going? Is it worth debugging this deeper, or
> is anyone else facing the same problem?

For 3.8 I use the following hack on beaglebone:
https://github.com/beagleboard/kernel/blob/3.8/patches/usb/0009-MUSB-Hack-around-to-make-host-port-to-work.patch

It's only a partial solution but better than nothing :)

regards,

Koen

Re: [PATCH 0/5] usb: musb: am335x support

[Daniel Mack]

On 02.03.2013 17:05, Koen Kooi wrote:
> On Fri, 2013-03-01 at 22:57 +0100, Daniel Mack wrote:
>> Hi Afzal, everyone,
>>
>> On 03.11.2012 08:33, Mohammed, Afzal wrote:
>>> * Daniel Mack, November 03, 2012 1:06 AM:
>>>
>>>> I'm testing these patches with an AM33xx board that has the first musb
>>>> port wired to an USB type A plug, but it doesn't yet work for me.
>>>
>>>> So there is no host interface registered. I'm unsure on how to fix this,
>>>> and I didn't get an answer yet to that question when I asked Felipe
>>>> about how interface drivers like dsps are supposed to act in order to
>>>> get host mode back after the recent musb cleanups.
>>>
>>>> What type of hardware do you test this with? Does host mode work for you?
>>>
>>> To add to those details mentioned by Ravi,
>>>
>>> This was tested on Beagle Bone with USB0 as usb-ethernet.
>>>
>>> For purely Kernel part, this series is sufficient (along with
>>> dependency mentioned in cover letter), considering
>>> the fact that dt node is strictly not a part of Kernel.
>>>
>>> To test this series, node for usbss should be present in dt.
>>> Example in dt documentation can be pasted onto dtsi file
>>> to get USB0 working.
>>
>> I have to pick up this old thread because I'm still having trouble
>> understanding how the AM335x musb driver is meant to be used as HCD.
>>
>> I used to have it working based on 3.7 with a terrible hack that reverts
>> a couple of old commits partly. Now I started over with a fresh setup
>> based on Linus' current soon-to-be 3.9-rc tip, actually hoping that the
>> issues are solved.
>>
>> On my board, the USB is purely used as host interface, with a type B
>> plug soldered. In the DT, I'm using the following sniplet in accordance
>> to the documentation of the bindings:
>>
>> 	usb_otg_hs: usb@47400000 {
>> 		compatible = "ti,musb-am33xx";
>> 		reg = <0x47400000 0x1000	/* usbss */
>> 		       0x47401000 0x800		/* musb instance 0 */
>> 		       0x47401800 0x800>;	/* musb instance 1 */
>> 		interrupt-parent = <&intc>;
>> 		interrupts = <17		/* usbss */
>> 			      18		/* musb instance 0 */
>> 			      19>;		/* musb instance 1 */
>> 		multipoint = <1>;
>> 		num-eps = <16>;
>> 		ram-bits = <12>;
>> 		port0-mode = <3>;
>> 		port1-mode = <3>;
>> 		power = <250>;
>> 		ti,hwmods = "usb_otg_hs";
>> 	};
>>
>> The relevant config options are
>>
>> CONFIG_USB_MUSB_HDRC=y
>> # CONFIG_USB_MUSB_TUSB6010 is not set
>> # CONFIG_USB_MUSB_OMAP2PLUS is not set
>> # CONFIG_USB_MUSB_AM35X is not set
>> CONFIG_USB_MUSB_DSPS=y
>> CONFIG_MUSB_PIO_ONLY=y
>> CONFIG_USB_GADGET=y
>> CONFIG_USB_GADGET_DEBUG=y
>> CONFIG_USB_GADGET_DEBUG_FILES=y
>> CONFIG_USB_GADGET_DEBUG_FS=y
>> CONFIG_USB_GADGET_VBUS_DRAW=2
>> CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
>> CONFIG_USB_GADGET_MUSB_HDRC=y
>> # CONFIG_USB_GADGETFS is not set
>> # CONFIG_USB_MIDI_GADGET is not set
>> CONFIG_USB_ZERO=m
>>
>> At boot time, I only see the following message:
>>
>> [    1.534776] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
>>
>> And when g_zero.ko is loaded, I get:
>>
>> [   12.137023] udc musb-hdrc.0.auto: registering UDC driver [zero]
>> [   12.196906]  gadget: adding 'source/sink'/cec4e840 to config
>> 'source/sink'/bf00d544
>> [   12.205800]  gadget: dual speed source/sink: IN/ep1in, OUT/ep1out,
>> ISO-IN/ep13, ISO-OUT/ep14
>> [   12.215862]  gadget: adding 'loopback'/cec4e7c0 to config
>> 'loopback'/bf00d5b8
>> [   12.224321]  gadget: dual speed loopback: IN/ep1in, OUT/ep1out
>> [   12.231323]  gadget: Gadget Zero, version: Cinco de Mayo 2008
>> [   12.238164]  gadget: zero ready
>> [   12.242250] musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
>> [   12.249111] musb-hdrc musb-hdrc.0.auto: new USB bus registered,
>> assigned bus number 1
>> [   12.258151] musb-hdrc musb-hdrc.0.auto: supports USB remote wakeup
>> [   12.265507] usb usb1: default language 0x0409
>> [   12.271007] usb usb1: udev 1, busnum 1, minor = 0
>> [   12.276699] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
>> [   12.284632] usb usb1: New USB device strings: Mfr=3, Product=2,
>> SerialNumber=1
>> [   12.292992] usb usb1: Product: MUSB HDRC host driver
>> [   12.298959] usb usb1: Manufacturer: Linux 3.8.0-10238-gbfbdcec-dirty
>> musb-hcd
>> [   12.307166] usb usb1: SerialNumber: musb-hdrc.0.auto
>> [   12.323645] usb usb1: no of_node; not parsing pinctrl DT
>> [   12.330172] usb usb1: usb_probe_device
>> [   12.335181] usb usb1: configuration #1 chosen from 1 choice
>> [   12.342090] usb usb1: adding 1-0:1.0 (config #1, interface 0)
>> [   12.355237] hub 1-0:1.0: no of_node; not parsing pinctrl DT
>> [   12.361988] hub 1-0:1.0: usb_probe_interface
>> [   12.367497] hub 1-0:1.0: usb_probe_interface - got id
>> [   12.373774] hub 1-0:1.0: USB hub found
>> [   12.378631] hub 1-0:1.0: 1 port detected
>> [   12.383515] hub 1-0:1.0: standalone hub
>> [   12.388330] hub 1-0:1.0: individual port power switching
>> [   12.394599] hub 1-0:1.0: no over-current protection
>> [   12.400497] hub 1-0:1.0: Single TT
>> [   12.404770] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns)
>> [   12.412203] hub 1-0:1.0: power on to power good time: 10ms
>> [   12.418776] hub 1-0:1.0: local power source is good
>> [   12.424812] hub 1-0:1.0: enabling power on all ports
>> [   12.527985] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000
>> [   12.533836] hub 1-0:1.0: hub_suspend
>> [   12.537634] usb usb1: bus auto-suspend, wakeup 1
>>
>> ... but lsusb only shows the root hub, not the device which is connected
>> to the plug.
>>
>> Also, when statically compiled into the kernel, the zero gadget driver
>> fails initialization with error code -2, but that's probably a whole
>> different story. Eventually, what I need is USB host support without
>> loading any module, as I boot the rootfs from USB under some circumstances.
>>
>> I'm not sure what I'm missing here. Is there anything that needs extra
>> configuration to get this going? Is it worth debugging this deeper, or
>> is anyone else facing the same problem?
> 
> For 3.8 I use the following hack on beaglebone:
> https://github.com/beagleboard/kernel/blob/3.8/patches/usb/0009-MUSB-Hack-around-to-make-host-port-to-work.patch
> 
> It's only a partial solution but better than nothing :)

Yeah, I've seen that, but that doesn't work as expected anymore on 3.9,
and also I believe that there must be a clean solution to this ...


Thanks,
Daniel

Re: [PATCH 0/5] usb: musb: am335x support

[Peter Korsgaard]

>>>>> "Daniel" == Daniel Mack <zonque@gmail.com> writes:

Hi,

 Daniel> On my board, the USB is purely used as host interface, with a
 Daniel> type B plug soldered. In the DT, I'm using the following
 Daniel> sniplet in accordance to the documentation of the bindings:

 Daniel> 	usb_otg_hs: usb@47400000 {
 Daniel> 		compatible = "ti,musb-am33xx";
 Daniel> 		reg = <0x47400000 0x1000	/* usbss */
 Daniel> 		       0x47401000 0x800		/* musb instance 0 */
 Daniel> 		       0x47401800 0x800>;	/* musb instance 1 */
 Daniel> 		interrupt-parent = <&intc>;
 Daniel> 		interrupts = <17		/* usbss */
 Daniel> 			      18		/* musb instance 0 */
 19> ;		/* musb instance 1 */
 Daniel> 		multipoint = <1>;
 Daniel> 		num-eps = <16>;
 Daniel> 		ram-bits = <12>;
 Daniel> 		port0-mode = <3>;
 Daniel> 		port1-mode = <3>;
 Daniel> 		power = <250>;
 Daniel> 		ti,hwmods = "usb_otg_hs";
 Daniel> 	};

 Daniel> The relevant config options are

 Daniel> CONFIG_USB_MUSB_HDRC=y
 Daniel> # CONFIG_USB_MUSB_TUSB6010 is not set
 Daniel> # CONFIG_USB_MUSB_OMAP2PLUS is not set
 Daniel> # CONFIG_USB_MUSB_AM35X is not set
 Daniel> CONFIG_USB_MUSB_DSPS=y
 Daniel> CONFIG_MUSB_PIO_ONLY=y
 Daniel> CONFIG_USB_GADGET=y
 Daniel> CONFIG_USB_GADGET_DEBUG=y
 Daniel> CONFIG_USB_GADGET_DEBUG_FILES=y
 Daniel> CONFIG_USB_GADGET_DEBUG_FS=y
 Daniel> CONFIG_USB_GADGET_VBUS_DRAW=2
 Daniel> CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
 Daniel> CONFIG_USB_GADGET_MUSB_HDRC=y

Ehh, I'm confused here. You talk about host mode, a single 'B' (gadget)
connector and your device tree mentions 2 OTG ports.

What is the configuration exactly?

-- 
Bye, Peter Korsgaard

Re: [PATCH 0/5] usb: musb: am335x support

[Daniel Mack]

Hi Peter,

On 03.03.2013 23:24, Peter Korsgaard wrote:
>>>>>> "Daniel" == Daniel Mack <zonque@gmail.com> writes:
> 
> Hi,
> 
>  Daniel> On my board, the USB is purely used as host interface, with a
>  Daniel> type B plug soldered. In the DT, I'm using the following
>  Daniel> sniplet in accordance to the documentation of the bindings:
> 
>  Daniel> 	usb_otg_hs: usb@47400000 {
>  Daniel> 		compatible = "ti,musb-am33xx";
>  Daniel> 		reg = <0x47400000 0x1000	/* usbss */
>  Daniel> 		       0x47401000 0x800		/* musb instance 0 */
>  Daniel> 		       0x47401800 0x800>;	/* musb instance 1 */
>  Daniel> 		interrupt-parent = <&intc>;
>  Daniel> 		interrupts = <17		/* usbss */
>  Daniel> 			      18		/* musb instance 0 */
>  19> ;		/* musb instance 1 */
>  Daniel> 		multipoint = <1>;
>  Daniel> 		num-eps = <16>;
>  Daniel> 		ram-bits = <12>;
>  Daniel> 		port0-mode = <3>;
>  Daniel> 		port1-mode = <3>;
>  Daniel> 		power = <250>;
>  Daniel> 		ti,hwmods = "usb_otg_hs";
>  Daniel> 	};
> 
>  Daniel> The relevant config options are
> 
>  Daniel> CONFIG_USB_MUSB_HDRC=y
>  Daniel> # CONFIG_USB_MUSB_TUSB6010 is not set
>  Daniel> # CONFIG_USB_MUSB_OMAP2PLUS is not set
>  Daniel> # CONFIG_USB_MUSB_AM35X is not set
>  Daniel> CONFIG_USB_MUSB_DSPS=y
>  Daniel> CONFIG_MUSB_PIO_ONLY=y
>  Daniel> CONFIG_USB_GADGET=y
>  Daniel> CONFIG_USB_GADGET_DEBUG=y
>  Daniel> CONFIG_USB_GADGET_DEBUG_FILES=y
>  Daniel> CONFIG_USB_GADGET_DEBUG_FS=y
>  Daniel> CONFIG_USB_GADGET_VBUS_DRAW=2
>  Daniel> CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
>  Daniel> CONFIG_USB_GADGET_MUSB_HDRC=y
> 
> Ehh, I'm confused here. You talk about host mode, a single 'B' (gadget)
> connector

I'm sorry for the confusion caused. This is a stupid mistake - I'm in
fact talking about an 'A' type plug of course (host mode).

> and your device tree mentions 2 OTG ports.

That's what I said in a follow up - the same happens for mode '1'.

> What is the configuration exactly?

Again to summarize: host-only mode, type 'A' plug.

The gadget driver is is enabled in the config because the only
occurrence of usb_add_hcd() in the musb driver is in the gagdget part,
so supposedly, there has to be a gadget driver loaded in order to make
the host interface going.


Thanks,
Daniel

Re: [PATCH 0/5] usb: musb: am335x support

[Daniel Mack]

On 04.03.2013 00:53, Daniel Mack wrote:
> Hi Peter,
> 
> On 03.03.2013 23:24, Peter Korsgaard wrote:
>>>>>>> "Daniel" == Daniel Mack <zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>> Hi,
>>
>>  Daniel> On my board, the USB is purely used as host interface, with a
>>  Daniel> type B plug soldered. In the DT, I'm using the following
>>  Daniel> sniplet in accordance to the documentation of the bindings:
>>
>>  Daniel> 	usb_otg_hs: usb@47400000 {
>>  Daniel> 		compatible = "ti,musb-am33xx";
>>  Daniel> 		reg = <0x47400000 0x1000	/* usbss */
>>  Daniel> 		       0x47401000 0x800		/* musb instance 0 */
>>  Daniel> 		       0x47401800 0x800>;	/* musb instance 1 */
>>  Daniel> 		interrupt-parent = <&intc>;
>>  Daniel> 		interrupts = <17		/* usbss */
>>  Daniel> 			      18		/* musb instance 0 */
>>  19> ;		/* musb instance 1 */
>>  Daniel> 		multipoint = <1>;
>>  Daniel> 		num-eps = <16>;
>>  Daniel> 		ram-bits = <12>;
>>  Daniel> 		port0-mode = <3>;
>>  Daniel> 		port1-mode = <3>;
>>  Daniel> 		power = <250>;
>>  Daniel> 		ti,hwmods = "usb_otg_hs";
>>  Daniel> 	};
>>
>>  Daniel> The relevant config options are
>>
>>  Daniel> CONFIG_USB_MUSB_HDRC=y
>>  Daniel> # CONFIG_USB_MUSB_TUSB6010 is not set
>>  Daniel> # CONFIG_USB_MUSB_OMAP2PLUS is not set
>>  Daniel> # CONFIG_USB_MUSB_AM35X is not set
>>  Daniel> CONFIG_USB_MUSB_DSPS=y
>>  Daniel> CONFIG_MUSB_PIO_ONLY=y
>>  Daniel> CONFIG_USB_GADGET=y
>>  Daniel> CONFIG_USB_GADGET_DEBUG=y
>>  Daniel> CONFIG_USB_GADGET_DEBUG_FILES=y
>>  Daniel> CONFIG_USB_GADGET_DEBUG_FS=y
>>  Daniel> CONFIG_USB_GADGET_VBUS_DRAW=2
>>  Daniel> CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
>>  Daniel> CONFIG_USB_GADGET_MUSB_HDRC=y
>>
>> Ehh, I'm confused here. You talk about host mode, a single 'B' (gadget)
>> connector
> 
> I'm sorry for the confusion caused. This is a stupid mistake - I'm in
> fact talking about an 'A' type plug of course (host mode).
> 
>> and your device tree mentions 2 OTG ports.
> 
> That's what I said in a follow up - the same happens for mode '1'.
> 
>> What is the configuration exactly?
> 
> Again to summarize: host-only mode, type 'A' plug.
> 
> The gadget driver is is enabled in the config because the only
> occurrence of usb_add_hcd() in the musb driver is in the gagdget part,
> so supposedly, there has to be a gadget driver loaded in order to make
> the host interface going.

Just be clear: I'd happily help and dig for the reason of this, I'd just
need to know how things are _supposed_ to work ...


Daniel

--
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 0/5] usb: musb: am335x support

[Daniel Mack]

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

On 07.03.2013 13:51, Daniel Mack wrote:
> On 04.03.2013 00:53, Daniel Mack wrote:
>> Hi Peter,
>>
>> On 03.03.2013 23:24, Peter Korsgaard wrote:
>>>>>>>> "Daniel" == Daniel Mack <zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>
>>> Hi,
>>>
>>>  Daniel> On my board, the USB is purely used as host interface, with a
>>>  Daniel> type B plug soldered. In the DT, I'm using the following
>>>  Daniel> sniplet in accordance to the documentation of the bindings:
>>>
>>>  Daniel> 	usb_otg_hs: usb@47400000 {
>>>  Daniel> 		compatible = "ti,musb-am33xx";
>>>  Daniel> 		reg = <0x47400000 0x1000	/* usbss */
>>>  Daniel> 		       0x47401000 0x800		/* musb instance 0 */
>>>  Daniel> 		       0x47401800 0x800>;	/* musb instance 1 */
>>>  Daniel> 		interrupt-parent = <&intc>;
>>>  Daniel> 		interrupts = <17		/* usbss */
>>>  Daniel> 			      18		/* musb instance 0 */
>>>  19> ;		/* musb instance 1 */
>>>  Daniel> 		multipoint = <1>;
>>>  Daniel> 		num-eps = <16>;
>>>  Daniel> 		ram-bits = <12>;
>>>  Daniel> 		port0-mode = <3>;
>>>  Daniel> 		port1-mode = <3>;
>>>  Daniel> 		power = <250>;
>>>  Daniel> 		ti,hwmods = "usb_otg_hs";
>>>  Daniel> 	};
>>>
>>>  Daniel> The relevant config options are
>>>
>>>  Daniel> CONFIG_USB_MUSB_HDRC=y
>>>  Daniel> # CONFIG_USB_MUSB_TUSB6010 is not set
>>>  Daniel> # CONFIG_USB_MUSB_OMAP2PLUS is not set
>>>  Daniel> # CONFIG_USB_MUSB_AM35X is not set
>>>  Daniel> CONFIG_USB_MUSB_DSPS=y
>>>  Daniel> CONFIG_MUSB_PIO_ONLY=y
>>>  Daniel> CONFIG_USB_GADGET=y
>>>  Daniel> CONFIG_USB_GADGET_DEBUG=y
>>>  Daniel> CONFIG_USB_GADGET_DEBUG_FILES=y
>>>  Daniel> CONFIG_USB_GADGET_DEBUG_FS=y
>>>  Daniel> CONFIG_USB_GADGET_VBUS_DRAW=2
>>>  Daniel> CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
>>>  Daniel> CONFIG_USB_GADGET_MUSB_HDRC=y
>>>
>>> Ehh, I'm confused here. You talk about host mode, a single 'B' (gadget)
>>> connector
>>
>> I'm sorry for the confusion caused. This is a stupid mistake - I'm in
>> fact talking about an 'A' type plug of course (host mode).
>>
>>> and your device tree mentions 2 OTG ports.
>>
>> That's what I said in a follow up - the same happens for mode '1'.
>>
>>> What is the configuration exactly?
>>
>> Again to summarize: host-only mode, type 'A' plug.
>>
>> The gadget driver is is enabled in the config because the only
>> occurrence of usb_add_hcd() in the musb driver is in the gagdget part,
>> so supposedly, there has to be a gadget driver loaded in order to make
>> the host interface going.
> 
> Just be clear: I'd happily help and dig for the reason of this, I'd just
> need to know how things are _supposed_ to work ...

So I dug a little on this topic, and restored the behaviour I need with
the attached patch.

The funny part is that the value set in the port0-mode/port1-mode DT
properties are not even looked at by the code.

I know this patch reintroduces bits that have been intentionally removed
before, in particular by 032ec49f53 ("usb: musb: drop useless board_mode
usage"), but I don't know how this usb driver is supposed to work in
host mode without taking the configured port mode into account. If
anyone can explain to me which information I'm missing here, I can
happily test a patch. For now, this works for me.


Thanks,
Daniel


[-- Attachment #2: 0001-drivers-usb-musb-re-enable-host-only-mode.patch --]
[-- Type: text/x-patch, Size: 4955 bytes --]

>From a98a5d15332dc261bb3f366ccc2ef6e2cb924730 Mon Sep 17 00:00:00 2001
From: Daniel Mack <zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Fri, 8 Mar 2013 17:31:10 +0100
Subject: [PATCH] drivers: usb: musb: re-enable host-only mode

Currently, the port%d-mode properties in DT are completely unused, and
support code for enabling host-only mode configurations is missing,
partly due to the recent rework in the musb core driver.

Fix this with the following changes:

 - store the port mode information in struct musb
 - in case of host-only mode setups, add the HCD directly from
   musb_init_controller()
 - refuse to start a gadget on a host-only configured port

Store the port mode in struct musb and handle

Signed-off-by: Daniel Mack <zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/usb/musb/musb_core.c   | 47 ++++++++++++++++++++++++++++++++++--------
 drivers/usb/musb/musb_core.h   |  5 +++++
 drivers/usb/musb/musb_gadget.c |  5 +++++
 3 files changed, 48 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 60b41cc..726c4ec 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -937,15 +937,19 @@ void musb_start(struct musb *musb)
 	devctl = musb_readb(regs, MUSB_DEVCTL);
 	devctl &= ~MUSB_DEVCTL_SESSION;
 
-	/* session started after:
-	 * (a) ID-grounded irq, host mode;
-	 * (b) vbus present/connect IRQ, peripheral mode;
-	 * (c) peripheral initiates, using SRP
-	 */
-	if ((devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS)
-		musb->is_active = 1;
-	else
+	if (musb->port_mode == MUSB_PORT_MODE_HOST) {
 		devctl |= MUSB_DEVCTL_SESSION;
+	} else {
+		/* session started after:
+		 * (a) ID-grounded irq, host mode;
+		 * (b) vbus present/connect IRQ, peripheral mode;
+		 * (c) peripheral initiates, using SRP
+		 */
+		if ((devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS)
+			musb->is_active = 1;
+		else
+			devctl |= MUSB_DEVCTL_SESSION;
+	}
 
 	musb_platform_enable(musb);
 	musb_writeb(regs, MUSB_DEVCTL, devctl);
@@ -1007,6 +1011,9 @@ static void musb_shutdown(struct platform_device *pdev)
 
 	musb_gadget_cleanup(musb);
 
+	if (musb->port_mode == MUSB_PORT_MODE_HOST)
+		usb_remove_hcd(musb_to_hcd(musb));
+
 	spin_lock_irqsave(&musb->lock, flags);
 	musb_platform_disable(musb);
 	musb_generic_disable(musb);
@@ -1866,6 +1873,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->port_mode = plat->mode;
 
 	/* The musb_platform_init() call:
 	 *   - adjusts musb->mregs
@@ -1944,7 +1952,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 	/* host side needs more setup */
 	hcd = musb_to_hcd(musb);
 	otg_set_host(musb->xceiv->otg, &hcd->self);
-	hcd->self.otg_port = 1;
 	musb->xceiv->otg->host = &hcd->self;
 	hcd->power_budget = 2 * (plat->power ? : 250);
 
@@ -1960,6 +1967,26 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 	musb->xceiv->state = OTG_STATE_B_IDLE;
 
 	status = musb_gadget_setup(musb);
+	if (status < 0)
+		goto fail3;
+
+	/*
+	 * If the port is configured to 'host' mode only,
+	 * start the HCD here.
+	 */
+	if (musb->port_mode == MUSB_PORT_MODE_HOST) {
+		MUSB_HST_MODE(musb);
+		musb->xceiv->otg->default_a = 1;
+		musb->xceiv->state = OTG_STATE_A_IDLE;
+
+		status = usb_add_hcd(hcd, 0, 0);
+		if (status < 0)
+			goto fail3;
+
+		hcd->self.uses_pio_for_control = 1;
+	} else {
+		hcd->self.otg_port = 1;
+	}
 
 	if (status < 0)
 		goto fail3;
@@ -1983,6 +2010,8 @@ fail5:
 
 fail4:
 	musb_gadget_cleanup(musb);
+	if (musb->port_mode == MUSB_PORT_MODE_HOST)
+		usb_remove_hcd(hcd);
 
 fail3:
 	pm_runtime_put_sync(musb->controller);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..f89318d 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -51,6 +51,10 @@ struct musb;
 struct musb_hw_ep;
 struct musb_ep;
 
+#define MUSB_PORT_MODE_HOST	1
+#define MUSB_PORT_MODE_DEV	2
+#define MUSB_PORT_MODE_OTG	3
+
 /* Helper defines for struct musb->hwvers */
 #define MUSB_HWVERS_MAJOR(x)	((x >> 10) & 0x1f)
 #define MUSB_HWVERS_MINOR(x)	(x & 0x3ff)
@@ -369,6 +373,7 @@ struct musb {
 	u16 epmask;
 	u8 nr_endpoints;
 
+	int			port_mode;	/* MUSB_PORT_MODE_* */
 	int			(*board_set_power)(int state);
 
 	u8			min_power;	/* vbus for periph, in mA/2 */
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index be18537..4e1e993 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1948,6 +1948,11 @@ static int musb_gadget_start(struct usb_gadget *g,
 		goto err;
 	}
 
+	if (musb->port_mode == MUSB_PORT_MODE_HOST) {
+		retval = -EINVAL;
+		goto err;
+	}
+
 	pm_runtime_get_sync(musb->controller);
 
 	dev_dbg(musb->controller, "registering driver %s\n", driver->function);
-- 
1.8.1.4

Re: [PATCH 0/5] usb: musb: am335x support

[Daniel Mack]

On 08.03.2013 17:44, Daniel Mack wrote:
> On 07.03.2013 13:51, Daniel Mack wrote:
>> On 04.03.2013 00:53, Daniel Mack wrote:
>>> Hi Peter,
>>>
>>> On 03.03.2013 23:24, Peter Korsgaard wrote:
>>>>>>>>> "Daniel" == Daniel Mack <zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>
>>>> Hi,
>>>>
>>>>  Daniel> On my board, the USB is purely used as host interface, with a
>>>>  Daniel> type B plug soldered. In the DT, I'm using the following
>>>>  Daniel> sniplet in accordance to the documentation of the bindings:
>>>>
>>>>  Daniel> 	usb_otg_hs: usb@47400000 {
>>>>  Daniel> 		compatible = "ti,musb-am33xx";
>>>>  Daniel> 		reg = <0x47400000 0x1000	/* usbss */
>>>>  Daniel> 		       0x47401000 0x800		/* musb instance 0 */
>>>>  Daniel> 		       0x47401800 0x800>;	/* musb instance 1 */
>>>>  Daniel> 		interrupt-parent = <&intc>;
>>>>  Daniel> 		interrupts = <17		/* usbss */
>>>>  Daniel> 			      18		/* musb instance 0 */
>>>>  19> ;		/* musb instance 1 */
>>>>  Daniel> 		multipoint = <1>;
>>>>  Daniel> 		num-eps = <16>;
>>>>  Daniel> 		ram-bits = <12>;
>>>>  Daniel> 		port0-mode = <3>;
>>>>  Daniel> 		port1-mode = <3>;
>>>>  Daniel> 		power = <250>;
>>>>  Daniel> 		ti,hwmods = "usb_otg_hs";
>>>>  Daniel> 	};
>>>>
>>>>  Daniel> The relevant config options are
>>>>
>>>>  Daniel> CONFIG_USB_MUSB_HDRC=y
>>>>  Daniel> # CONFIG_USB_MUSB_TUSB6010 is not set
>>>>  Daniel> # CONFIG_USB_MUSB_OMAP2PLUS is not set
>>>>  Daniel> # CONFIG_USB_MUSB_AM35X is not set
>>>>  Daniel> CONFIG_USB_MUSB_DSPS=y
>>>>  Daniel> CONFIG_MUSB_PIO_ONLY=y
>>>>  Daniel> CONFIG_USB_GADGET=y
>>>>  Daniel> CONFIG_USB_GADGET_DEBUG=y
>>>>  Daniel> CONFIG_USB_GADGET_DEBUG_FILES=y
>>>>  Daniel> CONFIG_USB_GADGET_DEBUG_FS=y
>>>>  Daniel> CONFIG_USB_GADGET_VBUS_DRAW=2
>>>>  Daniel> CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
>>>>  Daniel> CONFIG_USB_GADGET_MUSB_HDRC=y
>>>>
>>>> Ehh, I'm confused here. You talk about host mode, a single 'B' (gadget)
>>>> connector
>>>
>>> I'm sorry for the confusion caused. This is a stupid mistake - I'm in
>>> fact talking about an 'A' type plug of course (host mode).
>>>
>>>> and your device tree mentions 2 OTG ports.
>>>
>>> That's what I said in a follow up - the same happens for mode '1'.
>>>
>>>> What is the configuration exactly?
>>>
>>> Again to summarize: host-only mode, type 'A' plug.
>>>
>>> The gadget driver is is enabled in the config because the only
>>> occurrence of usb_add_hcd() in the musb driver is in the gagdget part,
>>> so supposedly, there has to be a gadget driver loaded in order to make
>>> the host interface going.
>>
>> Just be clear: I'd happily help and dig for the reason of this, I'd just
>> need to know how things are _supposed_ to work ...
> 
> So I dug a little on this topic, and restored the behaviour I need with
> the attached patch.
> 
> The funny part is that the value set in the port0-mode/port1-mode DT
> properties are not even looked at by the code.
> 
> I know this patch reintroduces bits that have been intentionally removed
> before, in particular by 032ec49f53 ("usb: musb: drop useless board_mode
> usage"), but I don't know how this usb driver is supposed to work in
> host mode without taking the configured port mode into account. If
> anyone can explain to me which information I'm missing here, I can
> happily test a patch. For now, this works for me.

Hmm, nobody, really? Am I the only one who's running the musb driver in
host-only mode?


Daniel

--
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 0/5] usb: musb: am335x support

[Peter Korsgaard]

>>>>> "Daniel" == Daniel Mack <zonque@gmail.com> writes:

Hi,

 >> I know this patch reintroduces bits that have been intentionally
 >> removed before, in particular by 032ec49f53 ("usb: musb: drop
 >> useless board_mode usage"), but I don't know how this usb driver is
 >> supposed to work in host mode without taking the configured port
 >> mode into account. If anyone can explain to me which information I'm
 >> missing here, I can happily test a patch. For now, this works for
 >> me.

 Daniel> Hmm, nobody, really? Am I the only one who's running the musb
 Daniel> driver in host-only mode?

Sorry, I'll be needing host mode as well, but am currently stuck working
on non-am335x stuff - So I'm definately interested in getting it to
work, but don't have free cycles to look into it right now.

-- 
Bye, Peter Korsgaard

Re: [PATCH 0/5] usb: musb: am335x support

[Daniel Mack]

On 19.03.2013 14:27, Peter Korsgaard wrote:
>>>>>> "Daniel" == Daniel Mack <zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> 
> Hi,
> 
>  >> I know this patch reintroduces bits that have been intentionally
>  >> removed before, in particular by 032ec49f53 ("usb: musb: drop
>  >> useless board_mode usage"), but I don't know how this usb driver is
>  >> supposed to work in host mode without taking the configured port
>  >> mode into account. If anyone can explain to me which information I'm
>  >> missing here, I can happily test a patch. For now, this works for
>  >> me.
> 
>  Daniel> Hmm, nobody, really? Am I the only one who's running the musb
>  Daniel> driver in host-only mode?
> 
> Sorry, I'll be needing host mode as well, but am currently stuck working
> on non-am335x stuff - So I'm definately interested in getting it to
> work, but don't have free cycles to look into it right now.
> 

Another two weeks passed with no answer at all, which makes me wonder
whether the changes were made considering the setup at all that at least
Peter, Koen and me are using.

Felipe, could you explain the background on how the dsps driver is
supposed to work in host mode at boot time with the rework of the driver
you did for 3.7? It might just be me not understanding the rationale
behind all these changes, but appearantly, I'm not the only one who's
affected by that.


Thanks,
Daniel

--
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 0/5] usb: musb: am335x support

[Felipe Balbi]

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

Hi,

(sorry, being really busy lately)

On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote:
> >  >> I know this patch reintroduces bits that have been intentionally
> >  >> removed before, in particular by 032ec49f53 ("usb: musb: drop
> >  >> useless board_mode usage"), but I don't know how this usb driver is
> >  >> supposed to work in host mode without taking the configured port
> >  >> mode into account. If anyone can explain to me which information I'm
> >  >> missing here, I can happily test a patch. For now, this works for
> >  >> me.
> > 
> >  Daniel> Hmm, nobody, really? Am I the only one who's running the musb
> >  Daniel> driver in host-only mode?
> > 
> > Sorry, I'll be needing host mode as well, but am currently stuck working
> > on non-am335x stuff - So I'm definately interested in getting it to
> > work, but don't have free cycles to look into it right now.
> > 
> 
> Another two weeks passed with no answer at all, which makes me wonder
> whether the changes were made considering the setup at all that at least
> Peter, Koen and me are using.
> 
> Felipe, could you explain the background on how the dsps driver is
> supposed to work in host mode at boot time with the rework of the driver
> you did for 3.7? It might just be me not understanding the rationale
> behind all these changes, but appearantly, I'm not the only one who's
> affected by that.

right, so the idea with that was to drop the huge amount of ifdeferry
hack from the MUSB driver. It would be great if someone would send
*CLEAN* patches adding Kconfig-based role choices again.

DWC3 and Chipidea are doing it very nicely.

patches are highly welcome.

-- 
balbi

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

Re: [PATCH 0/5] usb: musb: am335x support

[Daniel Mack]

Hi Felipe,

On 03.04.2013 14:04, Felipe Balbi wrote:
> (sorry, being really busy lately)
> 
> On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote:
>>>  >> I know this patch reintroduces bits that have been intentionally
>>>  >> removed before, in particular by 032ec49f53 ("usb: musb: drop
>>>  >> useless board_mode usage"), but I don't know how this usb driver is
>>>  >> supposed to work in host mode without taking the configured port
>>>  >> mode into account. If anyone can explain to me which information I'm
>>>  >> missing here, I can happily test a patch. For now, this works for
>>>  >> me.
>>>
>>>  Daniel> Hmm, nobody, really? Am I the only one who's running the musb
>>>  Daniel> driver in host-only mode?
>>>
>>> Sorry, I'll be needing host mode as well, but am currently stuck working
>>> on non-am335x stuff - So I'm definately interested in getting it to
>>> work, but don't have free cycles to look into it right now.
>>>
>>
>> Another two weeks passed with no answer at all, which makes me wonder
>> whether the changes were made considering the setup at all that at least
>> Peter, Koen and me are using.
>>
>> Felipe, could you explain the background on how the dsps driver is
>> supposed to work in host mode at boot time with the rework of the driver
>> you did for 3.7? It might just be me not understanding the rationale
>> behind all these changes, but appearantly, I'm not the only one who's
>> affected by that.
> 
> right, so the idea with that was to drop the huge amount of ifdeferry
> hack from the MUSB driver. It would be great if someone would send
> *CLEAN* patches adding Kconfig-based role choices again.
> 
> DWC3 and Chipidea are doing it very nicely.

Thanks a lot for your answer! I'll look into that and send some patches
then.


Thanks,
Daniel

--
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 0/5] usb: musb: am335x support

[Daniel Mack]

On 03.04.2013 14:04, Felipe Balbi wrote:
> On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote:

>> Felipe, could you explain the background on how the dsps driver is
>> supposed to work in host mode at boot time with the rework of the driver
>> you did for 3.7? It might just be me not understanding the rationale
>> behind all these changes, but appearantly, I'm not the only one who's
>> affected by that.
> 
> right, so the idea with that was to drop the huge amount of ifdeferry
> hack from the MUSB driver. It would be great if someone would send
> *CLEAN* patches adding Kconfig-based role choices again.

Are Kconfig-based rules really what we want here after all? Wouldn't
run-time configured settings make much more sense, considering that
people might want to run a single kernel image on multiple platforms? I
believe it should be up to the DT to define the actual hardware wiring.


Daniel

Re: [PATCH 0/5] usb: musb: am335x support

[Felipe Balbi]

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

Hi,

On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote:
> On 03.04.2013 14:04, Felipe Balbi wrote:
> > On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote:
> 
> >> Felipe, could you explain the background on how the dsps driver is
> >> supposed to work in host mode at boot time with the rework of the driver
> >> you did for 3.7? It might just be me not understanding the rationale
> >> behind all these changes, but appearantly, I'm not the only one who's
> >> affected by that.
> > 
> > right, so the idea with that was to drop the huge amount of ifdeferry
> > hack from the MUSB driver. It would be great if someone would send
> > *CLEAN* patches adding Kconfig-based role choices again.
> 
> Are Kconfig-based rules really what we want here after all? Wouldn't
> run-time configured settings make much more sense, considering that

we need both. Say that you want to build a product with MUSB hardwired
as host, why would you enable gadget framework ?

I can think of at least am335x where this would be perfectly plausible
(no EHCI available, only MUSB).

> people might want to run a single kernel image on multiple platforms? I
> believe it should be up to the DT to define the actual hardware wiring.

Right, for runtime decision Ravi pointed me to a patch implementing that
(Ravi, could you post it by any chance as RFC ?) which we could start a
discussion and hopefully merge for v3.11

-- 
balbi

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

Re: [PATCH 0/5] usb: musb: am335x support

[Koen Kooi]

Op 3 apr. 2013, om 15:09 heeft Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> het volgende geschreven:

> Hi,
> 
> On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote:
>> On 03.04.2013 14:04, Felipe Balbi wrote:
>>> On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote:
>> 
>>>> Felipe, could you explain the background on how the dsps driver is
>>>> supposed to work in host mode at boot time with the rework of the driver
>>>> you did for 3.7? It might just be me not understanding the rationale
>>>> behind all these changes, but appearantly, I'm not the only one who's
>>>> affected by that.
>>> 
>>> right, so the idea with that was to drop the huge amount of ifdeferry
>>> hack from the MUSB driver. It would be great if someone would send
>>> *CLEAN* patches adding Kconfig-based role choices again.
>> 
>> Are Kconfig-based rules really what we want here after all? Wouldn't
>> run-time configured settings make much more sense, considering that
> 
> we need both. Say that you want to build a product with MUSB hardwired
> as host, why would you enable gadget framework ?
> 
> I can think of at least am335x where this would be perfectly plausible
> (no EHCI available, only MUSB).

Nice that you mention am335x, since the beaglebone has 2 MUSB controllers: one hardwired as host and one hardwired as slave. So how will KConfig options solve that?--
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 0/5] usb: musb: am335x support

[Daniel Mack]

On 03.04.2013 15:12, Koen Kooi wrote:
> 
> Op 3 apr. 2013, om 15:09 heeft Felipe Balbi <balbi@ti.com> het
> volgende geschreven:
> 
>> Hi,
>> 
>> On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote:
>>> On 03.04.2013 14:04, Felipe Balbi wrote:
>>>> On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote:
>>> 
>>>>> Felipe, could you explain the background on how the dsps
>>>>> driver is supposed to work in host mode at boot time with the
>>>>> rework of the driver you did for 3.7? It might just be me not
>>>>> understanding the rationale behind all these changes, but
>>>>> appearantly, I'm not the only one who's affected by that.
>>>> 
>>>> right, so the idea with that was to drop the huge amount of
>>>> ifdeferry hack from the MUSB driver. It would be great if
>>>> someone would send *CLEAN* patches adding Kconfig-based role
>>>> choices again.
>>> 
>>> Are Kconfig-based rules really what we want here after all?
>>> Wouldn't run-time configured settings make much more sense,
>>> considering that
>> 
>> we need both. Say that you want to build a product with MUSB
>> hardwired as host, why would you enable gadget framework ?
>> 
>> I can think of at least am335x where this would be perfectly
>> plausible (no EHCI available, only MUSB).
> 
> Nice that you mention am335x, since the beaglebone has 2 MUSB
> controllers: one hardwired as host and one hardwired as slave. So how
> will KConfig options solve that?
> 

You would enable DUAL_ROLE and then let run-time code sort out the
actual config. Which is what most people would do if they are uncertain,
and which leaves the Kconfig option only for opting out some binary size.

Also, we already have CONFIG_USB_GADGET_MUSB_HDRC which is there to
remove all the gadget-only bits, right?


Daniel

Re: [PATCH 0/5] usb: musb: am335x support

[Felipe Balbi]

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

Hi,

On Wed, Apr 03, 2013 at 03:12:11PM +0200, Koen Kooi wrote:
> > On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote:
> >> On 03.04.2013 14:04, Felipe Balbi wrote:
> >>> On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote:
> >> 
> >>>> Felipe, could you explain the background on how the dsps driver is
> >>>> supposed to work in host mode at boot time with the rework of the driver
> >>>> you did for 3.7? It might just be me not understanding the rationale
> >>>> behind all these changes, but appearantly, I'm not the only one who's
> >>>> affected by that.
> >>> 
> >>> right, so the idea with that was to drop the huge amount of ifdeferry
> >>> hack from the MUSB driver. It would be great if someone would send
> >>> *CLEAN* patches adding Kconfig-based role choices again.
> >> 
> >> Are Kconfig-based rules really what we want here after all? Wouldn't
> >> run-time configured settings make much more sense, considering that
> > 
> > we need both. Say that you want to build a product with MUSB hardwired
> > as host, why would you enable gadget framework ?
> > 
> > I can think of at least am335x where this would be perfectly plausible
> > (no EHCI available, only MUSB).
> 
> Nice that you mention am335x, since the beaglebone has 2 MUSB
> controllers: one hardwired as host and one hardwired as slave. So how
> will KConfig options solve that?

you can't be asking this... are you serious ? For beaglebone it won't
help in anything, but beaglebone is nothing but *ONE* user of am335x.

You need to consider a product, what if someone decides to build a
product with am335x but uses either a single port in host-only mode (or
peripheral-only) or, both ports in same mode ?

Will that not help ? Spend 5 minutes thinking harder before sending this
attack emails.

-- 
balbi

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

Re: [PATCH 0/5] usb: musb: am335x support

[Felipe Balbi]

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

Hi,

On Wed, Apr 03, 2013 at 03:16:05PM +0200, Daniel Mack wrote:
> On 03.04.2013 15:12, Koen Kooi wrote:
> > 
> > Op 3 apr. 2013, om 15:09 heeft Felipe Balbi <balbi@ti.com> het
> > volgende geschreven:
> > 
> >> Hi,
> >> 
> >> On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote:
> >>> On 03.04.2013 14:04, Felipe Balbi wrote:
> >>>> On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote:
> >>> 
> >>>>> Felipe, could you explain the background on how the dsps
> >>>>> driver is supposed to work in host mode at boot time with the
> >>>>> rework of the driver you did for 3.7? It might just be me not
> >>>>> understanding the rationale behind all these changes, but
> >>>>> appearantly, I'm not the only one who's affected by that.
> >>>> 
> >>>> right, so the idea with that was to drop the huge amount of
> >>>> ifdeferry hack from the MUSB driver. It would be great if
> >>>> someone would send *CLEAN* patches adding Kconfig-based role
> >>>> choices again.
> >>> 
> >>> Are Kconfig-based rules really what we want here after all?
> >>> Wouldn't run-time configured settings make much more sense,
> >>> considering that
> >> 
> >> we need both. Say that you want to build a product with MUSB
> >> hardwired as host, why would you enable gadget framework ?
> >> 
> >> I can think of at least am335x where this would be perfectly
> >> plausible (no EHCI available, only MUSB).
> > 
> > Nice that you mention am335x, since the beaglebone has 2 MUSB
> > controllers: one hardwired as host and one hardwired as slave. So how
> > will KConfig options solve that?
> > 
> 
> You would enable DUAL_ROLE and then let run-time code sort out the
> actual config. Which is what most people would do if they are uncertain,
> and which leaves the Kconfig option only for opting out some binary size.
> 
> Also, we already have CONFIG_USB_GADGET_MUSB_HDRC which is there to
> remove all the gadget-only bits, right?

kinda, it's there but it's unused :-) But you got the idea. We use
Kconfig to opt-out of some features if we're certain our product won'
use it.

-- 
balbi

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

RE: [PATCH 0/5] usb: musb: am335x support

[B, Ravi]

Felipe

> 
> Hi,
> 
> On Wed, Apr 03, 2013 at 02:43:00PM +0200, Daniel Mack wrote:
> > On 03.04.2013 14:04, Felipe Balbi wrote:
> > > On Wed, Apr 03, 2013 at 02:00:23PM +0200, Daniel Mack wrote:
> >
> > >> Felipe, could you explain the background on how the dsps driver is
> > >> supposed to work in host mode at boot time with the rework of the
> driver
> > >> you did for 3.7? It might just be me not understanding the rationale
> > >> behind all these changes, but appearantly, I'm not the only one who's
> > >> affected by that.
> > >
> > > right, so the idea with that was to drop the huge amount of ifdeferry
> > > hack from the MUSB driver. It would be great if someone would send
> > > *CLEAN* patches adding Kconfig-based role choices again.
> >
> > Are Kconfig-based rules really what we want here after all? Wouldn't
> > run-time configured settings make much more sense, considering that
> 
> we need both. Say that you want to build a product with MUSB hardwired
> as host, why would you enable gadget framework ?
> 
> I can think of at least am335x where this would be perfectly plausible
> (no EHCI available, only MUSB).
> 
> > people might want to run a single kernel image on multiple platforms? I
> > believe it should be up to the DT to define the actual hardware wiring.
> 
> Right, for runtime decision Ravi pointed me to a patch implementing that
> (Ravi, could you post it by any chance as RFC ?) which we could start a
> discussion and hopefully merge for v3.11

Ok. 

--
Ravi B