Question regarding MUSB and dynamic fifo sizing

DISCUSSION Peter Barada 6 participants 24 messages Aug 6, 2009 – Aug 20, 2009

Subsystems (2)

USB MUSB multipoint high speed dual-role controller

lore

Share & tools

lore

Peter Barada

author

2009-08-06 20:06 UTC #0 lore raw

I'm running into a problem where the MUSB controller stops talking with the hardwired device on the other end, and I wasn to unload the musb as a module and reload it to the connection working again.

I can compile MSUB as a module, but when I load it the 2nd time it complains with:

OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0 musb_core_init 1421: reconfigure software for static FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19

This is due to the platform device wanting dynamic fifo sizing but the CONFIGDATA register has DYNFIFO bit cleared. Looking through the TRM, I can't find informaiton on how the MUSB controller changes the state of DYNFIFO - I'm guessing once any of the dynamic registers are written to that the controller switches to Dynamic Fifo sizing.

The code that aborts is:

	if (reg & MUSB_CONFIGDATA_DYNFIFO) {
		if (musb->config->dyn_fifo)
			status = ep_config_from_table(musb);
		else {
			ERR("reconfigure software for Dynamic FIFOs\n");
			status = -ENODEV;
		}
	} else {
		if (!musb->config->dyn_fifo)
			status = ep_config_from_hw(musb);
		else {
			ERR("reconfigure software for static FIFOs\n");
			return -ENODEV;
		}
	}

1) How can one change from dynamic to static fifo sizing in the MUSB?

2) Would it be safe to program for dynamic fifo sizing if CONFIG_DATA indicates the fifos are Statically sized?

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.

Gadiyar, Anand

2009-08-06 20:16 UTC #1 lore raw

Quoted 12 lines · Peter Barada

I'm running into a problem where the MUSB controller stops talking with the hardwired device on the other end, and I wasn to unload the musb as a module and reload it to the connection working again.
I can compile MSUB as a module, but when I load it the 2nd time it complains with:
OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0 musb_core_init 1421: reconfigure software for static FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19

Quoted 5 lines

This is due to the platform device wanting dynamic fifo sizing but the CONFIGDATA register has DYNFIFO bit cleared. Looking through the TRM, I can't find informaiton on how the MUSB controller changes the state of DYNFIFO - I'm guessing once any of the dynamic registers are written to that the controller switches to Dynamic Fifo sizing.

This patch from Ajay (already in mainline) should fix it for you.

<http://marc.info/?l=linux-usb&m=124881724122257&w=2>

The problem is not that the CONFIGDATA changes, but that we attempt to read from CONFIGDATA without having set the INDEX register to 0.

CONFIGDATA is a read-only register.

- Anand

Quoted 34 lines

The code that aborts is:
        if (reg & MUSB_CONFIGDATA_DYNFIFO) {
                if (musb->config->dyn_fifo)
                        status = ep_config_from_table(musb);
                else {
                        ERR("reconfigure software for Dynamic FIFOs\n");
                        status = -ENODEV;
                }
        } else {
                if (!musb->config->dyn_fifo)
                        status = ep_config_from_hw(musb);
                else {
                        ERR("reconfigure software for static FIFOs\n");
                        return -ENODEV;
                }
        }
1) How can one change from dynamic to static fifo sizing in the MUSB?
2) Would it be safe to program for dynamic fifo sizing if CONFIG_DATA indicates the fifos are Statically sized?
--
Peter Barada <[email protected]>
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Peter Barada

author

2009-08-07 17:19 UTC #2 lore raw

Quoted 19 lines · Anand

Quoted 12 lines · Peter Barada
I'm running into a problem where the MUSB controller stops talking with the hardwired device on the other end, and I wasn to unload the musb as a module and reload it to the connection working again.
I can compile MSUB as a module, but when I load it the 2nd time it complains with:
OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0 musb_core_init 1421: reconfigure software for static FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19
Quoted 5 lines
This is due to the platform device wanting dynamic fifo sizing but the CONFIGDATA register has DYNFIFO bit cleared. Looking through the TRM, I can't find informaiton on how the MUSB controller changes the state of DYNFIFO - I'm guessing once any of the dynamic registers are written to that the controller switches to Dynamic Fifo sizing.

Quoted 8 lines

This patch from Ajay (already in mainline) should fix it for you.
<http://marc.info/?l=linux-usb&m=124881724122257&w=2>
The problem is not that the CONFIGDATA changes, but that we attempt to read from CONFIGDATA without having set the INDEX register to 0.
CONFIGDATA is a read-only register.

Thanks, that patch allows me to modprobe/rmmod the musb_hdrc module, but shows another problem - after a modprobe/rmmod/modprobe of the musb_hdrc driver I don't see any USB devices downstream of the MUSB:

I have the following setup plugged in at boot(and left plugged in):

MUSB -> OTG cable -> Hub -> thumbdrive

When I modprobe the driver the first time I get:

OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, host, debug=0
musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd
usb usb1: SerialNumber: musb_hdrc
usb 1-1: new high speed USB device using musb_hdrc and address 2 usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub
hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110) OMAP-35x# lsusb
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc.
Bus 001 Device 001: ID 1d6b:0002
OMAP-35x#

Rmmod'ng the driver shows:

OMAP-35x# rmmod musb_hdrc
musb_hdrc musb_hdrc: remove, state 1
usb usb1: USB disconnect, address 1
usb 1-1: USB disconnect, address 2
musb_hdrc musb_hdrc: USB bus 1 deregistered

But modprobing the musb_hdrc driver a 2nd time shows:

And it fails to find the hub or thumbdrive.

1) Any idea why I'd see -ETIMEDOUT from musb_hdrc on the first modprobe?

2) Any ideas why musb_hdrc finds the hub/thumbdrive on the first modprobe, but not the 2nd?

3) I don't see any twl4030_usb interrupts from kernel boot - should I see them?

Thanks in advance!

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.

Pandita, Vikram

2009-08-07 17:26 UTC #3 lore raw

Quoted 49 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Peter Barada
Sent: Friday, August 07, 2009 12:24 PM
To: Gadiyar, Anand
Cc: linux-omap
Subject: RE: Question regarding MUSB and dynamic fifo sizing
Quoted 19 lines · Anand
Quoted 12 lines · Peter Barada
I'm running into a problem where the MUSB controller stops talking with the hardwired device on the other end, and I wasn to unload the musb as a module and reload it to the connection working again.
I can compile MSUB as a module, but when I load it the 2nd time it complains with:
OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0 musb_core_init 1421: reconfigure software for static FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19
Quoted 5 lines
This is due to the platform device wanting dynamic fifo sizing but the CONFIGDATA register has DYNFIFO bit cleared. Looking through the TRM, I can't find informaiton on how the MUSB controller changes the state of DYNFIFO - I'm guessing once any of the dynamic registers are written to that the controller switches to Dynamic Fifo sizing.
Quoted 8 lines
This patch from Ajay (already in mainline) should fix it for you.
<http://marc.info/?l=linux-usb&m=124881724122257&w=2>
The problem is not that the CONFIGDATA changes, but that we attempt to read from CONFIGDATA without having set the INDEX register to 0.
CONFIGDATA is a read-only register.
Thanks, that patch allows me to modprobe/rmmod the musb_hdrc module, but shows another problem - after a modprobe/rmmod/modprobe of the musb_hdrc driver I don't see any USB devices downstream of the MUSB:
I have the following setup plugged in at boot(and left plugged in):
MUSB -> OTG cable -> Hub -> thumbdrive
When I modprobe the driver the first time I get:

Quoted 7 lines

hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) OMAP-35x# lsusb
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Bus 001 Device 001: ID 1d6b:0002

Do things work fine without the hub for multiple insmod/rmmod? Case = MUSB -> OTG cable -> thumbdrive

Is hub introducing some issue here looking at above logs?

Peter Barada

author

2009-08-07 17:51 UTC #4 lore raw

Quoted 57 lines · Vikram

Quoted 48 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Peter Barada
Sent: Friday, August 07, 2009 12:24 PM
To: Gadiyar, Anand
Cc: linux-omap
Subject: RE: Question regarding MUSB and dynamic fifo sizing
Quoted 19 lines · Anand
Quoted 12 lines · Peter Barada
I'm running into a problem where the MUSB controller stops talking with the hardwired device on the other end, and I wasn to unload the musb as a module and reload it to the connection working again.
I can compile MSUB as a module, but when I load it the 2nd time it complains with:
OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0 musb_core_init 1421: reconfigure software for static FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19
Quoted 5 lines
This is due to the platform device wanting dynamic fifo sizing but the CONFIGDATA register has DYNFIFO bit cleared. Looking through the TRM, I can't find informaiton on how the MUSB controller changes the state of DYNFIFO - I'm guessing once any of the dynamic registers are written to that the controller switches to Dynamic Fifo sizing.
Quoted 8 lines
This patch from Ajay (already in mainline) should fix it for you.
<http://marc.info/?l=linux-usb&m=124881724122257&w=2>
The problem is not that the CONFIGDATA changes, but that we attempt to read from CONFIGDATA without having set the INDEX register to 0.
CONFIGDATA is a read-only register.
Thanks, that patch allows me to modprobe/rmmod the musb_hdrc module, but shows another problem - after a modprobe/rmmod/modprobe of the musb_hdrc driver I don't see any USB devices downstream of the MUSB:
I have the following setup plugged in at boot(and left plugged in):
MUSB -> OTG cable -> Hub -> thumbdrive
When I modprobe the driver the first time I get:
Quoted 7 lines
hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) OMAP-35x# lsusb
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Bus 001 Device 001: ID 1d6b:0002

Quoted 4 lines

Do things work fine without the hub for multiple insmod/rmmod? Case = MUSB -> OTG cable -> thumbdrive
Is hub introducing some issue here looking at above logs?

Hmm, if I use an mini-A -> Type A female adaptor, The MUSB driver finds the thumbdrive over multiple insmod/rmmod cycles.

1) What could the hub do that would prevent the MUSB from enumerating it?

Quoted 1 line

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.

Peter Barada

author

2009-08-07 19:18 UTC #5 lore raw

In reply to Pandita, Vikram

Quoted 57 lines · Vikram

Quoted 48 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Peter Barada
Sent: Friday, August 07, 2009 12:24 PM
To: Gadiyar, Anand
Cc: linux-omap
Subject: RE: Question regarding MUSB and dynamic fifo sizing
Quoted 19 lines · Anand
Quoted 12 lines · Peter Barada
I'm running into a problem where the MUSB controller stops talking with the hardwired device on the other end, and I wasn to unload the musb as a module and reload it to the connection working again.
I can compile MSUB as a module, but when I load it the 2nd time it complains with:
OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, otg (peripheral+host), debug=0 musb_core_init 1421: reconfigure software for static FIFOs musb_hdrc musb_hdrc: musb_init_controller failed with status -19
Quoted 5 lines
This is due to the platform device wanting dynamic fifo sizing but the CONFIGDATA register has DYNFIFO bit cleared. Looking through the TRM, I can't find informaiton on how the MUSB controller changes the state of DYNFIFO - I'm guessing once any of the dynamic registers are written to that the controller switches to Dynamic Fifo sizing.
Quoted 8 lines
This patch from Ajay (already in mainline) should fix it for you.
<http://marc.info/?l=linux-usb&m=124881724122257&w=2>
The problem is not that the CONFIGDATA changes, but that we attempt to read from CONFIGDATA without having set the INDEX register to 0.
CONFIGDATA is a read-only register.
Thanks, that patch allows me to modprobe/rmmod the musb_hdrc module, but shows another problem - after a modprobe/rmmod/modprobe of the musb_hdrc driver I don't see any USB devices downstream of the MUSB:
I have the following setup plugged in at boot(and left plugged in):
MUSB -> OTG cable -> Hub -> thumbdrive
When I modprobe the driver the first time I get:
Quoted 7 lines
hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) OMAP-35x# lsusb
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Bus 001 Device 001: ID 1d6b:0002

Quoted 4 lines

Do things work fine without the hub for multiple insmod/rmmod? Case = MUSB -> OTG cable -> thumbdrive
Is hub introducing some issue here looking at above logs?

Someting strange is going on. If I boot with the MUSB->OTG adapter -> thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter -> thumbdrive multiple times, and each time it is enumerated.

If I boot w/o the OTG adapter -> thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor ->thumbdrive, it is not enumerated.

Any idea why I need the OTG adapter -> thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive?

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.

Felipe Balbi

2009-08-07 20:16 UTC #6 lore raw

Quoted 11 lines · ext Peter Barada

Someting strange is going on. If I boot with the MUSB->OTG adapter -> thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter -> thumbdrive multiple times, and each time it is enumerated.
If I boot w/o the OTG adapter -> thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor ->thumbdrive, it is not enumerated.
Any idea why I need the OTG adapter -> thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive?

which board are you using ?

Signature · 1 line

balbi

Gupta, Ajay Kumar

2009-08-08 03:04 UTC #22 lore raw

In reply to Peter Barada

Quoted 10 lines

Someting strange is going on. If I boot with the MUSB->OTG adapter -> thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter -> thumbdrive multiple times, and each time it is enumerated.
If I boot w/o the OTG adapter -> thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor ->thumbdrive, it is not enumerated.
Any idea why I need the OTG adapter -> thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive?

It seems Vbus is off and thus nothing is detected.
There is already a fix for this (at least for host only driver) in mainline but as you are using v2.6.28-rc8 that fix is not in your driver.

Please try using below patch,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=743821717c611913a5a3f95010b141f0b4cb5463

This will solve the problem for host only driver but for otg build driver Vbus will be switched off as of now we don't have any entry to revive it.We use to start session and Vbus using $echo F >/proc/driver/musb_hdrc but now that proc entry is gone and equivalent debugfs entry is suppose to come.

I would suggest to pull in all musb specific patches from mainline tree into your driver or move to a newer kernel version.

-Ajay
--
Peter Barada <[email protected]>
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Pandita, Vikram

2009-08-08 05:03 UTC #23 lore raw

Quoted 10 lines

-----Original Message-----
From: Gupta, Ajay Kumar
Sent: Friday, August 07, 2009 10:04 PM
To: Peter Barada; Pandita, Vikram
Cc: Gadiyar, Anand; linux-omap
Subject: RE: Question regarding MUSB and dynamic fifo sizing

Quoted 8 lines

Please try using below patch,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
2.6.git;a=commitdiff;h=743821717c611913a5a3f95010b141f0b4cb5463
This will solve the problem for host only driver but for otg build driver Vbus will be switched off as of now we don't have any entry to revive it.We use to start session and Vbus using $echo F >/proc/driver/musb_hdrc but now that proc entry is gone and equivalent debugfs entry is suppose to come.

The sysfs entry is already there and working like charm -

echo "otg" > /sys/devices/platform/musb_hdrc/mode

Quoted 3 lines

I would suggest to pull in all musb specific patches from mainline tree into your driver or move to a newer kernel version.

Felipe Balbi

2009-08-08 06:42 UTC #7 lore raw

In reply to Felipe Balbi

Quoted 6 lines · Balbi Felipe (Nokia-D/Helsinki)

Quoted 5 lines · ext Peter Barada
Someting strange is going on. If I boot with the MUSB->OTG adapter -> thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter -> thumbdrive multiple times, and each time it is enumerated.

Quoted 8 lines

Quoted 6 lines
If I boot w/o the OTG adapter -> thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor ->thumbdrive, it is not enumerated.
Any idea why I need the OTG adapter -> thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive?
which board are you using ?

ok, got you. it's 35xx-based with twl4030.

when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c what happens. You should have a print about the link status, see if that is ID.

Then try something like this patch:

drivers/usb/otg/twl4030-usb.c +20 -0

index 9e3e7a5..4bc5b7f 100644
@@ -246,6 +246,8 @@ enum linkstat {
 };
 
 struct twl4030_usb {
+	/* used for driving or not vbus */
+	struct work_struct	work;
 	struct otg_transceiver	otg;
 	struct device		*dev;

@@ -347,6 +349,18 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8 reg, u8 bits)
 
 /*-------------------------------------------------------------------------*/
 
+static void twl4030_vbus_work(struct work_struct *work)
+{
+	struct twl4030_usb	*twl = container_of(work, twl4030_usb, work);
+
+	if (twl->driver_vbus)
+		(void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+				TWL4030_OTG_DRVVBUS);
+	else
+		(void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+				TWL4030_OTG_DRVVBUS);
+}
+
 static enum linkstat twl4030_usb_linkstat(struct twl4030_usb *twl)
 {
 	int	status;

@@ -386,12 +400,16 @@ static enum linkstat twl4030_usb_linkstat(struct twl4030_usb *twl)
 	if (linkstat == USB_LINK_ID) {
 		twl->otg.default_a = true;
 		twl->otg.state = OTG_STATE_A_IDLE;
+		twl->drive_vbus = true;
 	} else {
 		twl->otg.default_a = false;
 		twl->otg.state = OTG_STATE_B_IDLE;
+		twl->driver_vbus = false;
 	}
 	spin_unlock_irq(&twl->lock);
 
+	schedule_work(&twl->vbus_work);
+
 	return linkstat;
 }

@@ -668,6 +686,8 @@ static int __devinit twl4030_usb_probe(struct platform_device *pdev)
 	if (!twl)
 		return -ENOMEM;
 
+	INIT_WORK(&twl->work, twl4030_vbus_work);
+
 	twl->dev		= &pdev->dev;
 	twl->irq		= platform_get_irq(pdev, 0);
 	twl->otg.dev		= twl->dev;

Signature · 1 line

balbi

Felipe Balbi

2009-08-08 07:16 UTC #8 lore raw

Hi,

Quoted 29 lines · Felipe Balbi

Quoted 6 lines · Balbi Felipe (Nokia-D/Helsinki)
Quoted 5 lines · ext Peter Barada
Someting strange is going on. If I boot with the MUSB->OTG adapter -> thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter -> thumbdrive multiple times, and each time it is enumerated.
Quoted 8 lines
Quoted 6 lines
If I boot w/o the OTG adapter -> thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor ->thumbdrive, it is not enumerated.
Any idea why I need the OTG adapter -> thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive?
which board are you using ?
ok, got you. it's 35xx-based with twl4030.
when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c what happens. You should have a print about the link status, see if that is ID.
Then try something like this patch:
drivers/usb/otg/twl4030-usb.c +0 -0
index 9e3e7a5..4bc5b7f 100644

drivers/usb/otg/twl4030-usb.c enum linkstat { · line 252

Quoted 7 lines

drivers/usb/otg/twl4030-usb.c +2 -0

@@ -246,6 +246,8 @@ enum linkstat {
 };
 
 struct twl4030_usb {
+	/* used for driving or not vbus */
+	struct work_struct	work;
 	struct otg_transceiver	otg;
 	struct device		*dev;

forgot to add the drive_vbus field here. Better patch right below

====== cut here =====

drivers/usb/otg/twl4030-usb.c +21 -0

index 9e3e7a5..2a2cc8e 100644
@@ -246,6 +246,8 @@ enum linkstat {
 };
 
 struct twl4030_usb {
+	/* used for driving or not vbus */
+	struct work_struct	work;
 	struct otg_transceiver	otg;
 	struct device		*dev;

@@ -264,6 +266,7 @@ struct twl4030_usb {
 	u8			linkstat;
 	u8			asleep;
 	bool			irq_enabled;
+	bool			drive_vbus;
 };
 
 /* internal define on top of container_of */

@@ -347,6 +350,18 @@ twl4030_usb_clear_bits(struct twl4030_usb *twl, u8 reg, u8 bits)
 
 /*-------------------------------------------------------------------------*/
 
+static void twl4030_vbus_work(struct work_struct *work)
+{
+	struct twl4030_usb	*twl = container_of(work, twl4030_usb, work);
+
+	if (twl->driver_vbus)
+		(void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+				TWL4030_OTG_DRVVBUS);
+	else
+		(void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+				TWL4030_OTG_DRVVBUS);
+}
+
 static enum linkstat twl4030_usb_linkstat(struct twl4030_usb *twl)
 {
 	int	status;

@@ -386,12 +401,16 @@ static enum linkstat twl4030_usb_linkstat(struct twl4030_usb *twl)
 	if (linkstat == USB_LINK_ID) {
 		twl->otg.default_a = true;
 		twl->otg.state = OTG_STATE_A_IDLE;
+		twl->drive_vbus = true;
 	} else {
 		twl->otg.default_a = false;
 		twl->otg.state = OTG_STATE_B_IDLE;
+		twl->drive_vbus = false;
 	}
 	spin_unlock_irq(&twl->lock);
 
+	schedule_work(&twl->vbus_work);
+
 	return linkstat;
 }

@@ -668,6 +687,8 @@ static int __devinit twl4030_usb_probe(struct platform_device *pdev)
 	if (!twl)
 		return -ENOMEM;
 
+	INIT_WORK(&twl->work, twl4030_vbus_work);
+
 	twl->dev		= &pdev->dev;
 	twl->irq		= platform_get_irq(pdev, 0);
 	twl->otg.dev		= twl->dev;

Signature · 1 line

balbi

Peter Barada

author

2009-08-10 14:29 UTC #9 lore raw

Quoted 25 lines · Felipe Balbi

Hi,
Quoted 22 lines · Felipe Balbi
Quoted 6 lines · Balbi Felipe (Nokia-D/Helsinki)
Quoted 5 lines · ext Peter Barada
Someting strange is going on. If I boot with the MUSB->OTG adapter -> thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter -> thumbdrive multiple times, and each time it is enumerated.
Quoted 8 lines
Quoted 6 lines
If I boot w/o the OTG adapter -> thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor ->thumbdrive, it is not enumerated.
Any idea why I need the OTG adapter -> thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive?
which board are you using ?
ok, got you. it's 35xx-based with twl4030.
when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c what happens. You should have a print about the link status, see if that is ID.

Quoted 6 lines

drivers/usb/otg/twl4030-usb.c
Quoted 6 lines
Then try something like this patch:
drivers/usb/otg/twl4030-usb.c +0 -0
index 9e3e7a5..4bc5b7f 100644

Felipe,

Thanks for the patch. With the following modified patch (to fit my tree as my pull was from the Kevin's PM tree, commit 7c5cb7862d32cb344be7831d466535d5255e35ac) it worked like a charm:

diff --exclude CVS -uNr linux-2.6.28-rc8/drivers/usb/otg/twl4030-usb.c linux-2.6.28-rc8.modified/drivers/usb/otg/twl4030-usb.c
--- linux-2.6.28-rc8/drivers/usb/otg/twl4030-usb.c 2009-08-09
12:52:51.000000000 -0400
+++ linux-2.6.28-rc8.modified/drivers/usb/otg/twl4030-usb.c 2009-08-09
03:38:20.000000000 -0400
@@ -250,6 +250,8 @@
};

struct twl4030_usb {
+ /* used for driving or not vbus */
+ struct work_struct vbus_work;
struct otg_transceiver otg;
struct device *dev;

@@ -263,6 +265,7 @@
u8 linkstat;
u8 asleep;
bool irq_enabled;
+ bool drive_vbus;
};

/* internal define on top of container_of */
@@ -344,6 +347,18 @@
return twl4030_usb_write(twl, reg + 2, bits);
}

+static void twl4030_vbus_work(struct work_struct *work)
+{
+ struct twl4030_usb *twl = container_of(work, struct
twl4030_usb, vbus_work);
+
+ if (twl->drive_vbus)
+ (void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+ TWL4030_OTG_CTRL_DRVVBUS);
+ else
+ (void) twl4030_usb_set_bits(twl, TWL4030_OTG_CTRL,
+ TWL4030_OTG_CTRL_DRVVBUS);
+}
+
/*-------------------------------------------------------------------------*/

static enum linkstat twl4030_usb_linkstat(struct twl4030_usb *twl)
@@ -374,12 +389,16 @@
if (linkstat == USB_LINK_ID) {
twl->otg.default_a = true; twl->otg.state = OTG_STATE_A_IDLE;
+ twl->drive_vbus = true;
} else {
twl->otg.default_a = false; twl->otg.state = OTG_STATE_B_IDLE;
+ twl->drive_vbus = false;
}
spin_unlock_irq(&twl->lock);

+ schedule_work(&twl->vbus_work);
+
return linkstat;
}

@@ -657,6 +676,8 @@
if (!twl)
return -ENOMEM;

+ INIT_WORK(&twl->vbus_work, twl4030_vbus_work);
+
twl->dev = &pdev->dev;
twl->irq = platform_get_irq(pdev, 0);
twl->otg.dev = twl->dev;

With it I can enumerate my OTG adapter/thumbdrive on insertion.

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.

Felipe Balbi

2009-08-10 16:16 UTC #10 lore raw

Hi,

Quoted 35 lines · Peter Barada

Quoted 25 lines · Felipe Balbi
Hi,
Quoted 22 lines · Felipe Balbi
Quoted 6 lines · Balbi Felipe (Nokia-D/Helsinki)
Quoted 5 lines · ext Peter Barada
Someting strange is going on. If I boot with the MUSB->OTG adapter -> thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter -> thumbdrive multiple times, and each time it is enumerated.
Quoted 8 lines
Quoted 6 lines
If I boot w/o the OTG adapter -> thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor ->thumbdrive, it is not enumerated.
Any idea why I need the OTG adapter -> thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive?
which board are you using ?
ok, got you. it's 35xx-based with twl4030.
when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c what happens. You should have a print about the link status, see if that is ID.
Quoted 6 lines
drivers/usb/otg/twl4030-usb.c
Quoted 6 lines
Then try something like this patch:
drivers/usb/otg/twl4030-usb.c +0 -0
index 9e3e7a5..4bc5b7f 100644
Felipe,

Quoted 3 lines

Thanks for the patch. With the following modified patch (to fit my tree as my pull was from the Kevin's PM tree, commit 7c5cb7862d32cb344be7831d466535d5255e35ac) it worked like a charm:

Great, I'll clean it up and send it to Greg for mainline integration.

Signature · 1 line

balbi

Peter Barada

author

2009-08-10 16:56 UTC #11 lore raw

Quoted 38 lines · Felipe Balbi

Hi,
Quoted 35 lines · Peter Barada
Quoted 25 lines · Felipe Balbi
Hi,
Quoted 22 lines · Felipe Balbi
Quoted 6 lines · Balbi Felipe (Nokia-D/Helsinki)
Quoted 5 lines · ext Peter Barada
Someting strange is going on. If I boot with the MUSB->OTG adapter -> thumbdrive plugged in, and then modprobe the driver, it finds the thumbdrive. I can then remove/reinsert the OTG adapter -> thumbdrive multiple times, and each time it is enumerated.
Quoted 8 lines
Quoted 6 lines
If I boot w/o the OTG adapter -> thumbdrive plugged in, modprobe the musb driver, and then plug in the OTG adaptor ->thumbdrive, it is not enumerated.
Any idea why I need the OTG adapter -> thumbdrive plugged in at kernel boot for it to enumerate the thumbdrive?
which board are you using ?
ok, got you. it's 35xx-based with twl4030.
when you plug the micro-a cable, see on drivers/usb/otg/twl4030-usb.c what happens. You should have a print about the link status, see if that is ID.
Quoted 6 lines
drivers/usb/otg/twl4030-usb.c
Quoted 6 lines
Then try something like this patch:
drivers/usb/otg/twl4030-usb.c +0 -0
index 9e3e7a5..4bc5b7f 100644
Felipe,

Quoted 5 lines

Quoted 3 lines
Thanks for the patch. With the following modified patch (to fit my tree as my pull was from the Kevin's PM tree, commit 7c5cb7862d32cb344be7831d466535d5255e35ac) it worked like a charm:
Great, I'll clean it up and send it to Greg for mainline integration.

Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it.
With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate.

I added code to decipher the link state, and on startup I now see:

Jan  1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:

HW_CONDITIONS 0x72/114; link 1 (None)

Then when I load the driver:

Jan  1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0xf2/242; link 2 (Vbus)
Jan  1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:

HW_CONDITIONS 0x72/114; link 1 (None)

And when I plug in the OTG adapter/thumbdrive:

Jan  1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:

HW_CONDITIONS 0x76/118; link 3 (ID)

and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle.

During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring.

I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not).

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.

Felipe Balbi

2009-08-10 17:02 UTC #12 lore raw

Hi,

Quoted 26 lines · Peter Barada

Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it.
With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate.
I added code to decipher the link state, and on startup I now see:
Jan  1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x72/114; link 1 (None)
Then when I load the driver:
Jan  1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0xf2/242; link 2 (Vbus)
Jan  1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x72/114; link 1 (None)
And when I plug in the OTG adapter/thumbdrive:
Jan  1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x76/118; link 3 (ID)
and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle.

Quoted 6 lines

During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring.
I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not).

good you reported :-)

I was about to send a version to linux-usb. Let's see what's going on:

on you setup:

# echo 3 > /sys/modules/musb_hdrc/parameters/debug
# echo 9 > /proc/sysrq-trigger

this will give you more verbose output of what musb sees. BTW, it's odd you get a VBUS link irq when there shouldn't be any unless you have the board attached to pc at that time.

Signature · 1 line

balbi

Peter Barada

author

2009-08-10 17:24 UTC #13 lore raw

Quoted 40 lines · Felipe Balbi

Hi,
Quoted 26 lines · Peter Barada
Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it.
With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate.
I added code to decipher the link state, and on startup I now see:
Jan  1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x72/114; link 1 (None)
Then when I load the driver:
Jan  1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0xf2/242; link 2 (Vbus)
Jan  1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x72/114; link 1 (None)
And when I plug in the OTG adapter/thumbdrive:
Jan  1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x76/118; link 3 (ID)
and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle.
Quoted 6 lines
During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring.
I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not).
good you reported :-)
I was about to send a version to linux-usb. Let's see what's going on:

Quoted 8 lines

on you setup:
# echo 3 > /sys/modules/musb_hdrc/parameters/debug
# echo 9 > /proc/sysrq-trigger
this will give you more verbose output of what musb sees. BTW, it's odd you get a VBUS link irq when there shouldn't be any unless you have the board attached to pc at that time.

Nothing's attached to the OTG port at that time. W/nothing plugged in from powerup, The log first shows:

Jan  1 12:26:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:

HW_CONDITIONS 0x72/114; link 1 (None)

I rebuild with musb_debug=3 to get messages from the module on startup, and nothing plugges in from powerup, loading the module comes back with:

OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, host, debug=3
HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0
musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn)
musb_hdrc: MHDRC RTL version 1.400
musb_hdrc: setup fifo_mode 4
musb_hdrc: 28/31 max ep, 16384/16384 memory
musb_hdrc: hw_ep 0shared, max 64
musb_hdrc: hw_ep 1tx, max 512
musb_hdrc: hw_ep 1rx, max 512
musb_hdrc: hw_ep 2tx, max 512
musb_hdrc: hw_ep 2rx, max 512
musb_hdrc: hw_ep 3tx, max 512
musb_hdrc: hw_ep 3rx, max 512
musb_hdrc: hw_ep 4tx, max 512
musb_hdrc: hw_ep 4rx, max 512
musb_hdrc: hw_ep 5tx, max 512
musb_hdrc: hw_ep 5rx, max 512
musb_hdrc: hw_ep 6tx, max 512
musb_hdrc: hw_ep 6rx, max 512
musb_hdrc: hw_ep 7tx, max 512
musb_hdrc: hw_ep 7rx, max 512
musb_hdrc: hw_ep 8tx, max 512
musb_hdrc: hw_ep 8rx, max 512
musb_hdrc: hw_ep 9tx, max 512
musb_hdrc: hw_ep 9rx, max 512
musb_hdrc: hw_ep 10tx, max 256
musb_hdrc: hw_ep 10rx, max 64
musb_hdrc: hw_ep 11tx, max 256
musb_hdrc: hw_ep 11rx, max 64
musb_hdrc: hw_ep 12tx, max 256
musb_hdrc: hw_ep 12rx, max 64
musb_hdrc: hw_ep 13shared, max 4096
musb_hdrc: hw_ep 14shared, max 1024
musb_hdrc: hw_ep 15shared, max 1024
musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
musb_start 883: <== devctl 80
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd
usb usb1: SerialNumber: musb_hdrc
musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None)

Looking at the schematics, outside of a 4.7uF between Vbus and ground, nothing else is connected to the OTG D+, D-, ID, or Vbus except the connector...

1) With the twl4030 triggering Vbus, the MUSB must think its a peripheral, and then goes into suspend - why would the twl4030 think its getting Vbus supplied to it?

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.

Felipe Balbi

2009-08-10 18:48 UTC #14 lore raw

Quoted 114 lines · Peter Barada

Quoted 40 lines · Felipe Balbi
Hi,
Quoted 26 lines · Peter Barada
Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it.
With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate.
I added code to decipher the link state, and on startup I now see:
Jan  1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x72/114; link 1 (None)
Then when I load the driver:
Jan  1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0xf2/242; link 2 (Vbus)
Jan  1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x72/114; link 1 (None)
And when I plug in the OTG adapter/thumbdrive:
Jan  1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x76/118; link 3 (ID)
and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle.
Quoted 6 lines
During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring.
I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not).
good you reported :-)
I was about to send a version to linux-usb. Let's see what's going on:
Quoted 8 lines
on you setup:
# echo 3 > /sys/modules/musb_hdrc/parameters/debug
# echo 9 > /proc/sysrq-trigger
this will give you more verbose output of what musb sees. BTW, it's odd you get a VBUS link irq when there shouldn't be any unless you have the board attached to pc at that time.
Nothing's attached to the OTG port at that time. W/nothing plugged in from powerup, The log first shows:
Jan  1 12:26:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x72/114; link 1 (None)
I rebuild with musb_debug=3 to get messages from the module on startup, and nothing plugges in from powerup, loading the module comes back with:
OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, host, debug=3
HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0
musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn)
musb_hdrc: MHDRC RTL version 1.400
musb_hdrc: setup fifo_mode 4
musb_hdrc: 28/31 max ep, 16384/16384 memory
musb_hdrc: hw_ep 0shared, max 64
musb_hdrc: hw_ep 1tx, max 512
musb_hdrc: hw_ep 1rx, max 512
musb_hdrc: hw_ep 2tx, max 512
musb_hdrc: hw_ep 2rx, max 512
musb_hdrc: hw_ep 3tx, max 512
musb_hdrc: hw_ep 3rx, max 512
musb_hdrc: hw_ep 4tx, max 512
musb_hdrc: hw_ep 4rx, max 512
musb_hdrc: hw_ep 5tx, max 512
musb_hdrc: hw_ep 5rx, max 512
musb_hdrc: hw_ep 6tx, max 512
musb_hdrc: hw_ep 6rx, max 512
musb_hdrc: hw_ep 7tx, max 512
musb_hdrc: hw_ep 7rx, max 512
musb_hdrc: hw_ep 8tx, max 512
musb_hdrc: hw_ep 8rx, max 512
musb_hdrc: hw_ep 9tx, max 512
musb_hdrc: hw_ep 9rx, max 512
musb_hdrc: hw_ep 10tx, max 256
musb_hdrc: hw_ep 10rx, max 64
musb_hdrc: hw_ep 11tx, max 256
musb_hdrc: hw_ep 11rx, max 64
musb_hdrc: hw_ep 12tx, max 256
musb_hdrc: hw_ep 12rx, max 64
musb_hdrc: hw_ep 13shared, max 4096
musb_hdrc: hw_ep 14shared, max 1024
musb_hdrc: hw_ep 15shared, max 1024
musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
musb_start 883: <== devctl 80
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd
usb usb1: SerialNumber: musb_hdrc
musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None)

Quoted 7 lines

Looking at the schematics, outside of a 4.7uF between Vbus and ground, nothing else is connected to the OTG D+, D-, ID, or Vbus except the connector...
1) With the twl4030 triggering Vbus, the MUSB must think its a peripheral, and then goes into suspend - why would the twl4030 think its getting Vbus supplied to it?

donno yet, no clue unfortunately.

but could you try the following

1. connect micro-a cable and see what happens and what musb tells you ?
2. disconnect micro-a and connect micro-b to pc, what happens in that case ?
3. remove micro-b and go back to micro-a, what happens now ?

please get such logs and post it here so we can discuss it further

Signature · 1 line

balbi

Peter Barada

author

2009-08-10 20:38 UTC #15 lore raw

Quoted 119 lines · Felipe Balbi

Quoted 118 lines · Peter Barada
Quoted 40 lines · Felipe Balbi
Hi,
Quoted 26 lines · Peter Barada
Actually, not quite. I noticed that twl4030_vbus_work only sets Vbus, never clears it.
With that change and the driver configured for OTG mode (I had it host when I tested), it doesn't enumerate.
I added code to decipher the link state, and on startup I now see:
Jan  1 00:00:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x72/114; link 1 (None)
Then when I load the driver:
Jan  1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0xf2/242; link 2 (Vbus)
Jan  1 00:01:30 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x72/114; link 1 (None)
And when I plug in the OTG adapter/thumbdrive:
Jan  1 00:02:24 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x76/118; link 3 (ID)
and Vbus goes to +5V 30mS after ID grounds, and stays at 5V for only 30mS then goes back to ground. Pulling out and reinserting repeast the cycle.
Quoted 6 lines
During this total time, only two interrupts occur ont he MUSB controller. It looks like the connect interrupt is not occuring.
I'm adding more code to track the interrupts for both the twl4030-usb and musb_hdrc so I can understand better what's happening (and more importantly what's not).
good you reported :-)
I was about to send a version to linux-usb. Let's see what's going on:
Quoted 8 lines
on you setup:
# echo 3 > /sys/modules/musb_hdrc/parameters/debug
# echo 9 > /proc/sysrq-trigger
this will give you more verbose output of what musb sees. BTW, it's odd you get a VBUS link irq when there shouldn't be any unless you have the board attached to pc at that time.
Nothing's attached to the OTG port at that time. W/nothing plugged in from powerup, The log first shows:
Jan  1 12:26:13 OMAP-35x user.debug kernel: twl4030_usb twl4030_usb:
HW_CONDITIONS 0x72/114; link 1 (None)
I rebuild with musb_debug=3 to get messages from the module on startup, and nothing plugges in from powerup, loading the module comes back with:
OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, host, debug=3
HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0
musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn)
musb_hdrc: MHDRC RTL version 1.400
musb_hdrc: setup fifo_mode 4
musb_hdrc: 28/31 max ep, 16384/16384 memory
musb_hdrc: hw_ep 0shared, max 64
musb_hdrc: hw_ep 1tx, max 512
musb_hdrc: hw_ep 1rx, max 512
musb_hdrc: hw_ep 2tx, max 512
musb_hdrc: hw_ep 2rx, max 512
musb_hdrc: hw_ep 3tx, max 512
musb_hdrc: hw_ep 3rx, max 512
musb_hdrc: hw_ep 4tx, max 512
musb_hdrc: hw_ep 4rx, max 512
musb_hdrc: hw_ep 5tx, max 512
musb_hdrc: hw_ep 5rx, max 512
musb_hdrc: hw_ep 6tx, max 512
musb_hdrc: hw_ep 6rx, max 512
musb_hdrc: hw_ep 7tx, max 512
musb_hdrc: hw_ep 7rx, max 512
musb_hdrc: hw_ep 8tx, max 512
musb_hdrc: hw_ep 8rx, max 512
musb_hdrc: hw_ep 9tx, max 512
musb_hdrc: hw_ep 9rx, max 512
musb_hdrc: hw_ep 10tx, max 256
musb_hdrc: hw_ep 10rx, max 64
musb_hdrc: hw_ep 11tx, max 256
musb_hdrc: hw_ep 11rx, max 64
musb_hdrc: hw_ep 12tx, max 256
musb_hdrc: hw_ep 12rx, max 64
musb_hdrc: hw_ep 13shared, max 4096
musb_hdrc: hw_ep 14shared, max 1024
musb_hdrc: hw_ep 15shared, max 1024
musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
musb_start 883: <== devctl 80
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd
usb usb1: SerialNumber: musb_hdrc
musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None)
Looking at the schematics, outside of a 4.7uF between Vbus and ground, nothing else is connected to the OTG D+, D-, ID, or Vbus except the connector...

Quoted 7 lines

Quoted 3 lines
1) With the twl4030 triggering Vbus, the MUSB must think its a peripheral, and then goes into suspend - why would the twl4030 think its getting Vbus supplied to it?
donno yet, no clue unfortunately.
but could you try the following

Since the twl4030 thinks its got Vbus, I've added code to dump the TWL4030 register accesses and other structure in the twl4030-usb.c code to understand what its doing. So, from power up(with nothing connected), I see:

twl4030_usb twl4030_usb: ++ twl4030_usb_ldo_init:
twl4030_usb twl4030_usb: -- twl4030_usb_ldo_init:
twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 72 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) twl4030_usb twl4030_usb: ++ twl4030_phy_suspend: controller_off 0 twl4030_usb twl4030_usb: -- twl4030_usb_irq:
twl4030_usb twl4030_usb: Initialized TWL4030 USB module twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20

1) The only write is from twl4030_vbus_work to clear DRVBUS in OTG_CTRL since HW_CONDITION shows Vbus and ID not set.

modprobe of the driver gives

OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, host, debug=3
twl4030_usb twl4030_usb: ++ twl4030_phy_resume:
twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 01 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 00
twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_usb_write: address fe data 06 twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: twl4030_i2c_access: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 07
twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: twl4030_usb_set_mode: mode 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 09 data 04 twl4030_usb twl4030_usb: twl4030_usb_write: address ad data 20 twl4030_usb twl4030_usb: twl4030_usb_write: address 06 data 1b twl4030_usb twl4030_usb: -- twl4030_usb_set_mode:
twl4030_usb twl4030_usb: twl4030_i2c_access: on 0 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 06
twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: -- twl4030_phy_resume:
HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0
musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn)
musb_hdrc: MHDRC RTL version 1.400
musb_hdrc: setup fifo_mode 4
musb_hdrc: 28/31 max ep, 16384/16384 memory
musb_hdrc: hw_ep 0shared, max 64
musb_hdrc: hw_ep 1tx, max 512
musb_hdrc: hw_ep 1rx, max 512
musb_hdrc: hw_ep 2tx, max 512
musb_hdrc: hw_ep 2rx, max 512
musb_hdrc: hw_ep 3tx, max 512
musb_hdrc: hw_ep 3rx, max 512
musb_hdrc: hw_ep 4tx, max 512
musb_hdrc: hw_ep 4rx, max 512
musb_hdrc: hw_ep 5tx, max 512
musb_hdrc: hw_ep 5rx, max 512
musb_hdrc: hw_ep 6tx, max 512
musb_hdrc: hw_ep 6rx, max 512
musb_hdrc: hw_ep 7tx, max 512
musb_hdrc: hw_ep 7rx, max 512
musb_hdrc: hw_ep 8tx, max 512
musb_hdrc: hw_ep 8rx, max 512
musb_hdrc: hw_ep 9tx, max 512
musb_hdrc: hw_ep 9rx, max 512
musb_hdrc: hw_ep 10tx, max 256
musb_hdrc: hw_ep 10rx, max 64
musb_hdrc: hw_ep 11tx, max 256
musb_hdrc: hw_ep 11rx, max 64
musb_hdrc: hw_ep 12tx, max 256
musb_hdrc: hw_ep 12rx, max 64
musb_hdrc: hw_ep 13shared, max 4096
musb_hdrc: hw_ep 14shared, max 1024
musb_hdrc: hw_ep 15shared, max 1024
musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
musb_start 883: <== devctl 80
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd
usb usb1: SerialNumber: musb_hdrc
musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data f2 twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) twl4030_usb twl4030_usb: ++ twl4030_phy_resume:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 72 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) twl4030_usb twl4030_usb: ++ twl4030_phy_suspend: controller_off 0 twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 0 twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 00 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 01
twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: -- twl4030_phy_suspend:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:

As you can see, the twl4030-usb interrupt triggers and HW_CONDITIONS shows that Vbus is set. At this point, musb_hdrc (apparently) tries to talk to the device that it assumes is attached, and since nothing is out there, triggers the SUSPEND interrupt and then the twl4030 triggers to pull Vbus.

Quoted 1 line

1. connect micro-a cable and see what happens and what musb tells you ?

twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 76 twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) twl4030_usb twl4030_usb: ++ twl4030_phy_resume:
twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 0b data 20 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 01 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 00
twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_usb_write: address fe data 06 twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: ++ twl4030_i2c_access: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 07
twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: ++ twl4030_usb_set_mode: mode 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 09 data 04 twl4030_usb twl4030_usb: twl4030_usb_write: address ad data 20 twl4030_usb twl4030_usb: twl4030_usb_write: address 06 data 1b twl4030_usb twl4030_usb: -- twl4030_usb_set_mode:
twl4030_usb twl4030_usb: twl4030_i2c_access: on 0 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 06
twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: -- twl4030_phy_resume:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:

Quoted 2 lines

2. disconnect micro-a and connect micro-b to pc, what happens in that case ?

twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 72 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) twl4030_usb twl4030_usb: ++ twl4030_phy_suspend: controller_off 0 twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 0 twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 00 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 01
twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: -- twl4030_phy_suspend:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:

Quoted 1 line

3. remove micro-b and go back to micro-a, what happens now ?

Connect micro-B to PC:

twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data f2 twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) twl4030_usb twl4030_usb: ++ twl4030_phy_resume:
twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 01 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 00
twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_usb_write: address fe data 06 twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: ++ twl4030_i2c_access: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 07
twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: ++ twl4030_usb_set_mode: mode 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 09 data 04 twl4030_usb twl4030_usb: twl4030_usb_write: address ad data 20 twl4030_usb twl4030_usb: twl4030_usb_write: address 06 data 1b twl4030_usb twl4030_usb: -- twl4030_usb_set_mode:
musb_stage2_irq 812: SUSPEND (b_idle) devctl 99 power e0 twl4030_usb twl4030_usb: twl4030_i2c_access: on 0 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 06
twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: -- twl4030_phy_resume:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:

Quoted 2 lines

please get such logs and post it here so we can discuss it further

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.

Felipe Balbi

2009-08-11 12:08 UTC #16 lore raw

Hi,

Quoted 15 lines · ext Peter Barada

Since the twl4030 thinks its got Vbus, I've added code to dump the TWL4030 register accesses and other structure in the twl4030-usb.c code to understand what its doing. So, from power up(with nothing connected), I see:
twl4030_usb twl4030_usb: ++ twl4030_usb_ldo_init:
twl4030_usb twl4030_usb: -- twl4030_usb_ldo_init:
twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 72 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) twl4030_usb twl4030_usb: ++ twl4030_phy_suspend: controller_off 0 twl4030_usb twl4030_usb: -- twl4030_usb_irq:
twl4030_usb twl4030_usb: Initialized TWL4030 USB module twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20

Quoted 2 lines

1) The only write is from twl4030_vbus_work to clear DRVBUS in OTG_CTRL since HW_CONDITION shows Vbus and ID not set.

that's ok, so far.

Quoted 100 lines

modprobe of the driver gives
OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, host, debug=3
twl4030_usb twl4030_usb: ++ twl4030_phy_resume:
twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 01 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 00
twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_usb_write: address fe data 06 twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: twl4030_i2c_access: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 07
twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: twl4030_usb_set_mode: mode 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 09 data 04 twl4030_usb twl4030_usb: twl4030_usb_write: address ad data 20 twl4030_usb twl4030_usb: twl4030_usb_write: address 06 data 1b twl4030_usb twl4030_usb: -- twl4030_usb_set_mode:
twl4030_usb twl4030_usb: twl4030_i2c_access: on 0 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 06
twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: -- twl4030_phy_resume:
HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0
musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn)
musb_hdrc: MHDRC RTL version 1.400
musb_hdrc: setup fifo_mode 4
musb_hdrc: 28/31 max ep, 16384/16384 memory
musb_hdrc: hw_ep 0shared, max 64
musb_hdrc: hw_ep 1tx, max 512
musb_hdrc: hw_ep 1rx, max 512
musb_hdrc: hw_ep 2tx, max 512
musb_hdrc: hw_ep 2rx, max 512
musb_hdrc: hw_ep 3tx, max 512
musb_hdrc: hw_ep 3rx, max 512
musb_hdrc: hw_ep 4tx, max 512
musb_hdrc: hw_ep 4rx, max 512
musb_hdrc: hw_ep 5tx, max 512
musb_hdrc: hw_ep 5rx, max 512
musb_hdrc: hw_ep 6tx, max 512
musb_hdrc: hw_ep 6rx, max 512
musb_hdrc: hw_ep 7tx, max 512
musb_hdrc: hw_ep 7rx, max 512
musb_hdrc: hw_ep 8tx, max 512
musb_hdrc: hw_ep 8rx, max 512
musb_hdrc: hw_ep 9tx, max 512
musb_hdrc: hw_ep 9rx, max 512
musb_hdrc: hw_ep 10tx, max 256
musb_hdrc: hw_ep 10rx, max 64
musb_hdrc: hw_ep 11tx, max 256
musb_hdrc: hw_ep 11rx, max 64
musb_hdrc: hw_ep 12tx, max 256
musb_hdrc: hw_ep 12rx, max 64
musb_hdrc: hw_ep 13shared, max 4096
musb_hdrc: hw_ep 14shared, max 1024
musb_hdrc: hw_ep 15shared, max 1024
musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
musb_start 883: <== devctl 80
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd
usb usb1: SerialNumber: musb_hdrc
musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data f2 twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) twl4030_usb twl4030_usb: ++ twl4030_phy_resume:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 72 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) twl4030_usb twl4030_usb: ++ twl4030_phy_suspend: controller_off 0 twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 0 twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 00 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 01
twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: -- twl4030_phy_suspend:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:

Quoted 5 lines

As you can see, the twl4030-usb interrupt triggers and HW_CONDITIONS shows that Vbus is set. At this point, musb_hdrc (apparently) tries to talk to the device that it assumes is attached, and since nothing is out there, triggers the SUSPEND interrupt and then the twl4030 triggers to pull Vbus.

weird you got a suspend irq. that should only come when musb sees 3 consecutive SOFs.

Anyways, that shouldn't harm, and that new device found is just the roothub. Should be fine as well.

Quoted 25 lines

Quoted 1 line
1. connect micro-a cable and see what happens and what musb tells you ?
twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 76 twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) twl4030_usb twl4030_usb: ++ twl4030_phy_resume:
twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 0b data 20 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 01 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 00
twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_usb_write: address fe data 06 twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: ++ twl4030_i2c_access: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 07
twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: ++ twl4030_usb_set_mode: mode 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 09 data 04 twl4030_usb twl4030_usb: twl4030_usb_write: address ad data 20 twl4030_usb twl4030_usb: twl4030_usb_write: address 06 data 1b

Quoted 8 lines

twl4030_usb twl4030_usb: -- twl4030_usb_set_mode:
twl4030_usb twl4030_usb: twl4030_i2c_access: on 0 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 06
twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: -- twl4030_phy_resume:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:

but this is weird. When you connect micro-A, vbus should go on and musb should set the session bit in the devctl register. Maybe that's what it's missing.

let's try some other hackish test, apply this patch and after connecting micro-a cable do: echo 1 > /sys/devices/platform/musb_hdrc/connect

drivers/usb/musb/musb_core.c +51 -0

index c7c1ca0..9a615ee 100644
@@ -1682,6 +1682,54 @@ musb_mode_store(struct device *dev, struct device_attribute *attr,
 static DEVICE_ATTR(mode, 0644, musb_mode_show, musb_mode_store);
 
 static ssize_t
+musb_connect_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+       struct musb     *musb = dev_to_musb(dev);
+       unsigned long   flags;
+       int             ret = -EINVAL;
+
+       spin_lock_irqsave(&musb->lock, flags);
+       ret = sprintf(buf, "%d\n", musb->softconnect);
+       spin_unlock_irqrestore(&musb->lock, flags);
+
+       return ret;
+}
+
+static ssize_t
+musb_connect_store(struct device *dev, struct device_attribute *attr,
+               const char *buf, size_t n)
+{
+       struct musb     *musb = dev_to_musb(dev);
+       unsigned long   flags;
+       unsigned        val;
+       int             status;
+       u8              power;
+
+       status = sscanf(buf, "%u", &val);
+       if (status < 1) {
+               printk(KERN_ERR "invalid parameter, %d\n", status);
+               return -EINVAL;
+       }
+
+       spin_lock_irqsave(&musb->lock, flags);
+
+       power = musb_readb(musb->mregs, MUSB_POWER);
+
+       if (val)
+               power |= MUSB_POWER_SOFTCONN;
+       else
+               power &= ~MUSB_POWER_SOFTCONN;
+
+       musb->softconnect = !!val;
+       musb_writeb(musb->mregs, MUSB_POWER, power);
+
+       spin_unlock_irqrestore(&musb->lock, flags);
+
+       return n;
+}
+static DEVICE_ATTR(connect, 0644, musb_connect_show, musb_connect_store);
+
+static ssize_t
 musb_vbus_store(struct device *dev, struct device_attribute *attr,
                const char *buf, size_t n)
 {

@@ -1828,6 +1876,7 @@ static void musb_free(struct musb *musb)
 
 #ifdef CONFIG_SYSFS
        device_remove_file(musb->controller, &dev_attr_mode);
+       device_remove_file(musb->controller, &dev_attr_connect);
        device_remove_file(musb->controller, &dev_attr_vbus);
 #ifdef CONFIG_USB_GADGET_MUSB_HDRC
        device_remove_file(musb->controller, &dev_attr_srp);

@@ -2074,6 +2123,7 @@ bad_config:
 
 #ifdef CONFIG_SYSFS
        status = device_create_file(dev, &dev_attr_mode);
+       status = device_create_file(dev, &dev_attr_connect);
        status = device_create_file(dev, &dev_attr_vbus);
 #ifdef CONFIG_USB_GADGET_MUSB_HDRC
        status = device_create_file(dev, &dev_attr_srp);

@@ -2088,6 +2138,7 @@ bad_config:
 fail2:
 #ifdef CONFIG_SYSFS
        device_remove_file(musb->controller, &dev_attr_mode);
+       device_remove_file(musb->controller, &dev_attr_connect);
        device_remove_file(musb->controller, &dev_attr_vbus);
 #ifdef CONFIG_USB_GADGET_MUSB_HDRC
        device_remove_file(musb->controller, &dev_attr_srp);

Signature · 1 line

balbi

Peter Barada

author

2009-08-11 15:17 UTC #17 lore raw

Quoted 169 lines · Felipe Balbi

Hi,
Quoted 15 lines · ext Peter Barada
Since the twl4030 thinks its got Vbus, I've added code to dump the TWL4030 register accesses and other structure in the twl4030-usb.c code to understand what its doing. So, from power up(with nothing connected), I see:
twl4030_usb twl4030_usb: ++ twl4030_usb_ldo_init:
twl4030_usb twl4030_usb: -- twl4030_usb_ldo_init:
twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 72 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) twl4030_usb twl4030_usb: ++ twl4030_phy_suspend: controller_off 0 twl4030_usb twl4030_usb: -- twl4030_usb_irq:
twl4030_usb twl4030_usb: Initialized TWL4030 USB module twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20
Quoted 2 lines
1) The only write is from twl4030_vbus_work to clear DRVBUS in OTG_CTRL since HW_CONDITION shows Vbus and ID not set.
that's ok, so far.
Quoted 100 lines
modprobe of the driver gives
OMAP-35x# modprobe musb_hdrc
musb_hdrc: version 6.0, pio, host, debug=3
twl4030_usb twl4030_usb: ++ twl4030_phy_resume:
twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 01 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 00
twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_usb_write: address fe data 06 twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: twl4030_i2c_access: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 07
twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: twl4030_usb_set_mode: mode 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 09 data 04 twl4030_usb twl4030_usb: twl4030_usb_write: address ad data 20 twl4030_usb twl4030_usb: twl4030_usb_write: address 06 data 1b twl4030_usb twl4030_usb: -- twl4030_usb_set_mode:
twl4030_usb twl4030_usb: twl4030_i2c_access: on 0 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 06
twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: -- twl4030_phy_resume:
HS USB OTG: revision 0x33, sysconfig 0x2010, sysstatus 0x1, intrfsel 0x1, simenable 0x0
musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine (X), bulk split (X), HB-ISO Rx, HB-ISO Tx, SoftConn)
musb_hdrc: MHDRC RTL version 1.400
musb_hdrc: setup fifo_mode 4
musb_hdrc: 28/31 max ep, 16384/16384 memory
musb_hdrc: hw_ep 0shared, max 64
musb_hdrc: hw_ep 1tx, max 512
musb_hdrc: hw_ep 1rx, max 512
musb_hdrc: hw_ep 2tx, max 512
musb_hdrc: hw_ep 2rx, max 512
musb_hdrc: hw_ep 3tx, max 512
musb_hdrc: hw_ep 3rx, max 512
musb_hdrc: hw_ep 4tx, max 512
musb_hdrc: hw_ep 4rx, max 512
musb_hdrc: hw_ep 5tx, max 512
musb_hdrc: hw_ep 5rx, max 512
musb_hdrc: hw_ep 6tx, max 512
musb_hdrc: hw_ep 6rx, max 512
musb_hdrc: hw_ep 7tx, max 512
musb_hdrc: hw_ep 7rx, max 512
musb_hdrc: hw_ep 8tx, max 512
musb_hdrc: hw_ep 8rx, max 512
musb_hdrc: hw_ep 9tx, max 512
musb_hdrc: hw_ep 9rx, max 512
musb_hdrc: hw_ep 10tx, max 256
musb_hdrc: hw_ep 10rx, max 64
musb_hdrc: hw_ep 11tx, max 256
musb_hdrc: hw_ep 11rx, max 64
musb_hdrc: hw_ep 12tx, max 256
musb_hdrc: hw_ep 12rx, max 64
musb_hdrc: hw_ep 13shared, max 4096
musb_hdrc: hw_ep 14shared, max 1024
musb_hdrc: hw_ep 15shared, max 1024
musb_hdrc: USB Host mode controller at d80ab000 using PIO, IRQ 92 musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
musb_start 883: <== devctl 80
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver
usb usb1: Manufacturer: Linux 2.6.28-rc8-omap1-05704-gf6ea2bb-dirty musb-hcd
usb usb1: SerialNumber: musb_hdrc
musb_init_controller 2057: HOST mode, status 0, devctl 81 B twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data f2 twl4030_usb twl4030_usb: HW_CONDITIONS 0xf2/242; link 2 (Vbus) twl4030_usb twl4030_usb: ++ twl4030_phy_resume:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 OMAP-35x# musb_stage2_irq 812: SUSPEND (b_idle) devctl 91 power e0 twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 72 twl4030_usb twl4030_usb: HW_CONDITIONS 0x72/114; link 1 (None) twl4030_usb twl4030_usb: ++ twl4030_phy_suspend: controller_off 0 twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 0 twl4030_usb twl4030_usb: twl4030_usb_write: address 0c data 20 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 00 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 01
twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: -- twl4030_phy_suspend:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:
Quoted 5 lines
As you can see, the twl4030-usb interrupt triggers and HW_CONDITIONS shows that Vbus is set. At this point, musb_hdrc (apparently) tries to talk to the device that it assumes is attached, and since nothing is out there, triggers the SUSPEND interrupt and then the twl4030 triggers to pull Vbus.
weird you got a suspend irq. that should only come when musb sees 3 consecutive SOFs.
Anyways, that shouldn't harm, and that new device found is just the roothub. Should be fine as well.
Quoted 25 lines
Quoted 1 line
1. connect micro-a cable and see what happens and what musb tells you ?
twl4030_usb twl4030_usb: ++ twl4030_usb_irq:
twl4030_usb twl4030_usb: twl4030_readb: module 12 address 0f data 76 twl4030_usb twl4030_usb: HW_CONDITIONS 0x76/118; link 3 (ID) twl4030_usb twl4030_usb: ++ twl4030_phy_resume:
twl4030_usb twl4030_usb: ++ twl4030_phy_power: on 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 0b data 20 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fd data 01 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fd data 00
twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_usb_write: address fe data 06 twl4030_usb twl4030_usb: -- twl4030_phy_power:
twl4030_usb twl4030_usb: ++ twl4030_i2c_access: on 1 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 06 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 07
twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: twl4030_readb: module 00 address ff data 01 twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: ++ twl4030_usb_set_mode: mode 1 twl4030_usb twl4030_usb: twl4030_usb_write: address 09 data 04 twl4030_usb twl4030_usb: twl4030_usb_write: address ad data 20 twl4030_usb twl4030_usb: twl4030_usb_write: address 06 data 1b
Quoted 8 lines
twl4030_usb twl4030_usb: -- twl4030_usb_set_mode:
twl4030_usb twl4030_usb: twl4030_i2c_access: on 0 twl4030_usb twl4030_usb: twl4030_readb: module 00 address fe data 07 twl4030_usb twl4030_usb: twl4030_i2c_write_u8_verify: module 00 address fe data 06
twl4030_usb twl4030_usb: -- twl4030_i2c_access:
twl4030_usb twl4030_usb: -- twl4030_phy_resume:
twl4030_usb twl4030_usb: -- twl4030_usb_irq:

Quoted 6 lines

but this is weird. When you connect micro-A, vbus should go on and musb should set the session bit in the devctl register. Maybe that's what it's missing.
let's try some other hackish test, apply this patch and after connecting micro-a cable do: echo 1 > /sys/devices/platform/musb_hdrc/connect

Unfortunately, with the patch, and:

1) modprobe musb_hdrc
2) modprobe g_ether
3) connect micro-a cable
4) echo 1 > /sys/devices/platform/musb_hdrc/connect

Nothing happens - no isr or output.

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.

Felipe Balbi

2009-08-11 20:51 UTC #18 lore raw

Hi,

Quoted 8 lines · Peter Barada

Unfortunately, with the patch, and:
1) modprobe musb_hdrc
2) modprobe g_ether
3) connect micro-a cable
4) echo 1 > /sys/devices/platform/musb_hdrc/connect
Nothing happens - no isr or output.

did you have anything at the other end of the micro-a cable ?

Signature · 1 line

balbi

Peter Barada

author

2009-08-11 21:13 UTC #19 lore raw

Quoted 5 lines · Felipe Balbi

Hi,
Quoted 2 lines · Peter Barada
Unfortunately, with the patch, and:

Quoted 8 lines

Quoted 6 lines
1) modprobe musb_hdrc
2) modprobe g_ether
3) connect micro-a cable
4) echo 1 > /sys/devices/platform/musb_hdrc/connect
Nothing happens - no isr or output.
did you have anything at the other end of the micro-a cable ?

Not then. :)

I just connected my OTG adapter/thumbdrive, in step three and nothing no isr or output.

I know my OTG adapter (micro-a -> female A) is valid as I ohm'd out ID and ground on the baseboard (with the SOM removed), and indeed ID is shorted to ground with the adapter plugged in and open with it removed...

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.

Felipe Balbi

2009-08-11 21:17 UTC #20 lore raw

Quoted 17 lines · Peter Barada

Quoted 5 lines · Felipe Balbi
Hi,
Quoted 2 lines · Peter Barada
Unfortunately, with the patch, and:
Quoted 8 lines
Quoted 6 lines
1) modprobe musb_hdrc
2) modprobe g_ether
3) connect micro-a cable
4) echo 1 > /sys/devices/platform/musb_hdrc/connect
Nothing happens - no isr or output.
did you have anything at the other end of the micro-a cable ?
Not then. :)

Quoted 7 lines

I just connected my OTG adapter/thumbdrive, in step three and nothing no isr or output.
I know my OTG adapter (micro-a -> female A) is valid as I ohm'd out ID and ground on the baseboard (with the SOM removed), and indeed ID is shorted to ground with the adapter plugged in and open with it removed...

Well, looks like I'll have to go back to my documentation tomorrow at the office and see if I can get it working on one board of mine, let's see what happens and if I have to patch anything and what.

Signature · 1 line

balbi

Peter Barada

author

2009-08-20 16:24 UTC #21 lore raw

Quoted 21 lines · Felipe Balbi

Quoted 20 lines · Peter Barada
Quoted 5 lines · Felipe Balbi
Hi,
Quoted 2 lines · Peter Barada
Unfortunately, with the patch, and:
Quoted 8 lines
Quoted 6 lines
1) modprobe musb_hdrc
2) modprobe g_ether
3) connect micro-a cable
4) echo 1 > /sys/devices/platform/musb_hdrc/connect
Nothing happens - no isr or output.
did you have anything at the other end of the micro-a cable ?
Not then. :)
I just connected my OTG adapter/thumbdrive, in step three and nothing no isr or output.

Quoted 8 lines

Quoted 4 lines
I know my OTG adapter (micro-a -> female A) is valid as I ohm'd out ID and ground on the baseboard (with the SOM removed), and indeed ID is shorted to ground with the adapter plugged in and open with it removed...
Well, looks like I'll have to go back to my documentation tomorrow at the office and see if I can get it working on one board of mine, let's see what happens and if I have to patch anything and what.

Felipe,

I was wondering if you've had a look at this?

Signature · 2 lines

Peter Barada <[email protected]>
Logic Product Development, Inc.