Skip to contentSkip to conversation

usb: musb: am335x support

PATCH In review Afzal Mohammed 11 participants 31 messages Nov 2, 2012 – Apr 4, 2013 13 messages not in the archive

Subsystems (3)
Device tree bindings USB MUSB multipoint high speed dual-role controller
lore
Share & tools
lore

Afzal Mohammed

author
#0 lore raw

cover usb: musb: am335x support

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(-)
Signature · 1 line
1.7.12
author
#1 lore raw

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

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 <[email protected]>
---
 drivers/usb/musb/musb_dsps.c | 26 --------------------------
 1 file changed, 26 deletions(-)
drivers/usb/musb/musb_dsps.c +0 -26
index 625400f..2396bcd 100644
@@ -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
Signature · 1 line
1.7.12

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw

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

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 <[email protected]>
---
 drivers/usb/musb/musb_dsps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/musb/musb_dsps.c +1 -1
index 2396bcd..524c003 100644
@@ -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 = {
Signature · 6 lines
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#4 lore raw

PATCH 3/5 usb: musb: dsps: get resources by index

In reply to a message not in the archive

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

Signed-off-by Afzal Mohammed <[email protected]>
---
 drivers/usb/musb/musb_dsps.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)
drivers/usb/musb/musb_dsps.c +6 -8
index 524c003..c90e4d3 100644
@@ -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;
 	}
Signature · 6 lines
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#5 lore raw

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

In reply to 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 <[email protected]>
---
 .../devicetree/bindings/usb/am33xx-usb.txt          | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
Documentation/devicetree/bindings/usb/am33xx-usb.txt +21 -0
index a922505..6b7e3bd 100644
@@ -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";
+};
Signature · 1 line
1.7.12
#6 lore raw

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

Quoted 22 lines · 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 <[email protected]>
---
 .../devicetree/bindings/usb/am33xx-usb.txt          | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
Documentation/devicetree/bindings/usb/am33xx-usb.txt +2 -0
index a922505..6b7e3bd 100644
@@ -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.

Documentation/devicetree/bindings/usb/am33xx-usb.txt AM33XX MUSB GLUE · line 20

Quoted 7 lines
Documentation/devicetree/bindings/usb/am33xx-usb.txt +4 -0
@@ -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.

Quoted 18 lines
Documentation/devicetree/bindings/usb/am33xx-usb.txt +15 -0
+	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";
+};
Signature · 1 line
1.7.12
Signature · 1 line
balbi

A message that is not in the archive (sent off-list or not yet received): 20121106130245.GK11931-S8G//mZuvNWo5Im9Ml3/[email protected]

#8 lore raw

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

Hi Balbi,

Quoted 7 lines · Felipe Balbi

Documentation/devicetree/bindings/usb/am33xx-usb.txt AM33XX MUSB GLUE · line 20

Quoted 3 lines · Afzal Mohammed
Documentation/devicetree/bindings/usb/am33xx-usb.txt +3 -0
+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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#9 lore raw

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

In reply to Afzal Mohammed

From: "Santhapuri, Damodar" <[email protected]>

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.

[[email protected]: limit quirk to dsps wrapper]

Signed-off-by Santhapuri, Damodar <[email protected]>
Signed-off-by Ajay Kumar Gupta <[email protected]>
Signed-off-by Ravi Babu <[email protected]>
Signed-off-by Afzal Mohammed <[email protected]>
---
 drivers/usb/musb/musb_dsps.c | 69 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)
drivers/usb/musb/musb_dsps.c +69 -0
index c90e4d3..e770f79 100644
@@ -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
Signature · 1 line
1.7.12
#10 lore raw
In reply to Afzal Mohammed

Hi Afzal,

Quoted 4 lines · Afzal Mohammed

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

#11 lore raw
Quoted 11 lines · Afzal Mohammed
Quoted 4 lines

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.

Quoted 5 lines

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?

Quoted 11 lines
[    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
Quoted 1 line

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).

Quoted 8 lines

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

Quoted 6 lines

Many thanks,
Daniel

author
#12 lore raw
In reply to Daniel Mack

Hi Daniel,

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

Quoted 9 lines

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

A message that is not in the archive (sent off-list or not yet received): C8443D0743D26F4388EA172BF4E2A7A93EA0A1F2-Er742YJ7I/eIQmiDNMet8wC/[email protected]

#14 lore raw

Hi Afzal, everyone,

Quoted 16 lines · Afzal

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

Quoted 9 lines

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.

Quoted 7 lines

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#16 lore raw
Quoted 39 lines · Daniel Mack

Hi Afzal, everyone,

Quoted 16 lines · Afzal

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

Quoted 9 lines

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.

Quoted 7 lines

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:

Quoted 14 lines
	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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#17 lore raw
In reply to Daniel Mack
Quoted 129 lines · Daniel Mack

Hi Afzal, everyone,

Quoted 16 lines · Afzal

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

Quoted 9 lines

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.

Quoted 7 lines

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.

Quoted 8 lines

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

#18 lore raw
Quoted 135 lines · Koen Kooi
Quoted 134 lines · Daniel Mack

Hi Afzal, everyone,

Quoted 16 lines · Afzal

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

Quoted 9 lines

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.

Quoted 7 lines

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.

Quoted 8 lines
Quoted 3 lines

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

#19 lore raw
In reply to Daniel Mack
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Daniel" == Daniel Mack <[email protected]> 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?

Signature · 1 line
Bye, Peter Korsgaard
#20 lore raw

Hi Peter,

Quoted 42 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Daniel" == Daniel Mack <[email protected]> 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

Quoted 2 lines

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).

Quoted 1 line

and your device tree mentions 2 OTG ports.

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

Quoted 1 line

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#22 lore raw
Quoted 55 lines · Daniel Mack

Hi Peter,

Quoted 42 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Daniel" == Daniel Mack <[email protected]> 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

Quoted 2 lines

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).

Quoted 1 line

and your device tree mentions 2 OTG ports.

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

Quoted 8 lines
Quoted 1 line

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#24 lore raw
Quoted 60 lines · Daniel Mack
Quoted 59 lines · Daniel Mack

Hi Peter,

Quoted 42 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Daniel" == Daniel Mack <[email protected]> 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

Quoted 2 lines

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).

Quoted 1 line

and your device tree mentions 2 OTG ports.

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

Quoted 1 line

What is the configuration exactly?

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

Quoted 7 lines
Quoted 4 lines

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

Quoted 1 line

From a98a5d15332dc261bb3f366ccc2ef6e2cb924730 Mon Sep 17 00:00:00 2001

From: Daniel Mack <[email protected]>
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 <[email protected]>
---
 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(-)
drivers/usb/musb/musb_core.c +38 -9
index 60b41cc..726c4ec 100644
@@ -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);
drivers/usb/musb/musb_core.h +5 -0
index 7fb4819..f89318d 100644
@@ -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 */
drivers/usb/musb/musb_gadget.c +5 -0
index be18537..4e1e993 100644
@@ -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);
Signature · 1 line
1.8.1.4

A message that is not in the archive (sent off-list or not yet received): [email protected]

#26 lore raw
Quoted 75 lines · Daniel Mack
Quoted 60 lines · Daniel Mack
Quoted 59 lines · Daniel Mack

Hi Peter,

Quoted 42 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Daniel" == Daniel Mack <[email protected]> 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

Quoted 2 lines

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).

Quoted 1 line

and your device tree mentions 2 OTG ports.

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

Quoted 1 line

What is the configuration exactly?

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

Quoted 7 lines
Quoted 4 lines

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.

Quoted 6 lines

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#27 lore raw
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Daniel" == Daniel Mack <[email protected]> writes:

Hi,

Quoted 7 lines
Quoted 7 lines

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.

Signature · 1 line
Bye, Peter Korsgaard

A message that is not in the archive (sent off-list or not yet received): 87620nwmd2.fsf-D6SC8u56vOOJDPpyT6T3/[email protected]

#29 lore raw
Quoted 12 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Daniel" == Daniel Mack <[email protected]> writes:

Hi,

Quoted 7 lines
Quoted 7 lines

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.

Quoted 7 lines

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#31 lore raw

Hi,

(sorry, being really busy lately)

Quoted 20 lines · Daniel Mack
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Signature · 1 line
balbi

A message that is not in the archive (sent off-list or not yet received): 20130403120454.GX25837-S8G//mZuvNWo5Im9Ml3/[email protected]

#33 lore raw

Hi Felipe,

Quoted 29 lines · Felipe Balbi

(sorry, being really busy lately)

Quoted 20 lines · Daniel Mack
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 5 lines

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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#34 lore raw
In reply to Felipe Balbi
Quoted 11 lines · Felipe Balbi
Quoted 5 lines · Daniel Mack

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#36 lore raw

Hi,

Quoted 9 lines · Daniel Mack
Quoted 8 lines · Felipe Balbi
Quoted 5 lines · Daniel Mack

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.

Quoted 6 lines
Quoted 3 lines

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).

Quoted 2 lines

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

Signature · 1 line
balbi

A message that is not in the archive (sent off-list or not yet received): 20130403130807.GB14680-S8G//mZuvNWo5Im9Ml3/[email protected]

#38 lore raw

Op 3 apr. 2013, om 15:09 heeft Felipe Balbi <[email protected]> het volgende geschreven:

Quoted 16 lines

Hi,

Quoted 13 lines · Daniel Mack
Quoted 11 lines · Felipe Balbi
Quoted 5 lines · Daniel Mack

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.

Quoted 8 lines
Quoted 2 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#39 lore raw
Quoted 28 lines · Koen Kooi

Op 3 apr. 2013, om 15:09 heeft Felipe Balbi <[email protected]> het volgende geschreven:

Quoted 24 lines

Hi,

Quoted 9 lines · Daniel Mack
Quoted 8 lines · Felipe Balbi
Quoted 5 lines · Daniel Mack

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.

Quoted 8 lines
Quoted 4 lines

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 ?

Quoted 7 lines
Quoted 2 lines

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

#40 lore raw

Hi,

Quoted 37 lines · Daniel Mack
Quoted 28 lines · Koen Kooi

Op 3 apr. 2013, om 15:09 heeft Felipe Balbi <[email protected]> het volgende geschreven:

Quoted 24 lines

Hi,

Quoted 9 lines · Daniel Mack
Quoted 8 lines · Felipe Balbi
Quoted 5 lines · Daniel Mack

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.

Quoted 8 lines
Quoted 4 lines

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 ?

Quoted 7 lines
Quoted 2 lines

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?

Quoted 6 lines

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.

Signature · 1 line
balbi

A message that is not in the archive (sent off-list or not yet received): 62C108BE-894A-4F1D-BE85-14DB3217120E-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org

#42 lore raw

Hi,

Quoted 20 lines · Koen Kooi
Quoted 20 lines · Daniel Mack
Quoted 9 lines · Felipe Balbi
Quoted 8 lines · Daniel Mack
Quoted 6 lines

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.

Quoted 6 lines
Quoted 3 lines

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 ?

Quoted 6 lines
Quoted 2 lines

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.

Signature · 1 line
balbi
#43 lore raw
In reply to Felipe Balbi

Felipe

Quoted 27 lines

Hi,

Quoted 5 lines · Daniel Mack
Quoted 4 lines · Felipe Balbi
Quoted 2 lines · Daniel Mack

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

Quoted 10 lines
Quoted 7 lines
Quoted 3 lines

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).

Quoted 6 lines
Quoted 2 lines

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