Question regarding MUSB and dynamic fifo sizing

Question regarding MUSB and dynamic fifo sizing

[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

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?


-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

RE: Question regarding MUSB and dynamic fifo sizing

[Gadiyar, Anand]

Peter Barada wrote:
> 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.

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


> 
> 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 <peterb@logicpd.com>
> Logic Product Development, Inc.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

RE: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Fri, 2009-08-07 at 01:41 +0530, Gadiyar, Anand wrote:
> Peter Barada wrote:
> > 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.
> 
> 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:

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
OMAP-35x#
OMAP-35x# lsusb
Bus 001 Device 001: ID 1d6b:0002

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!

-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

RE: Question regarding MUSB and dynamic fifo sizing

[Pandita, Vikram]

>-----Original Message-----
>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] 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
>
>On Fri, 2009-08-07 at 01:41 +0530, Gadiyar, Anand wrote:
>> Peter Barada wrote:
>> > 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.
>>
>> 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:
>
>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?

RE: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Fri, 2009-08-07 at 22:55 +0530, Pandita, Vikram wrote:
> 
> >-----Original Message-----
> >From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] 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
> >
> >On Fri, 2009-08-07 at 01:41 +0530, Gadiyar, Anand wrote:
> >> Peter Barada wrote:
> >> > 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.
> >>
> >> 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:
> >
> >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?

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?


> 
-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

RE: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Fri, 2009-08-07 at 22:55 +0530, Pandita, Vikram wrote:
> 
> >-----Original Message-----
> >From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] 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
> >
> >On Fri, 2009-08-07 at 01:41 +0530, Gadiyar, Anand wrote:
> >> Peter Barada wrote:
> >> > 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.
> >>
> >> 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:
> >
> >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?

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?


-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

Re: Question regarding MUSB and dynamic fifo sizing

[Felipe Balbi]

On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote:
> 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 ?

-- 
balbi

Re: Question regarding MUSB and dynamic fifo sizing

[Felipe Balbi]

On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote:
> On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote:
> > 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 ?

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:

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 9e3e7a5..4bc5b7f 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -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;
-- 
balbi

Re: Question regarding MUSB and dynamic fifo sizing

[Felipe Balbi]

Hi,

On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote:
> On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote:
> > On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote:
> > > 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 ?
> 
> 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:
> 
> diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
> index 9e3e7a5..4bc5b7f 100644
> --- a/drivers/usb/otg/twl4030-usb.c
> +++ b/drivers/usb/otg/twl4030-usb.c
> @@ -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 =====

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 9e3e7a5..2a2cc8e 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -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;

-- 
balbi

Re: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Sat, 2009-08-08 at 10:17 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote:
> > On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote:
> > > On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote:
> > > > 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 ?
> > 
> > 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:
> > 
> > diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
> > index 9e3e7a5..4bc5b7f 100644
> > --- a/drivers/usb/otg/twl4030-usb.c
> > +++ b/drivers/usb/otg/twl4030-usb.c

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.

-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

Re: Question regarding MUSB and dynamic fifo sizing

[Felipe Balbi]

Hi,

On Mon, Aug 10, 2009 at 10:33:19AM -0400, Peter Barada wrote:
> On Sat, 2009-08-08 at 10:17 +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote:
> > > On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote:
> > > > On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote:
> > > > > 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 ?
> > > 
> > > 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:
> > > 
> > > diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
> > > index 9e3e7a5..4bc5b7f 100644
> > > --- a/drivers/usb/otg/twl4030-usb.c
> > > +++ b/drivers/usb/otg/twl4030-usb.c
> 
> 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:

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

-- 
balbi

Re: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Mon, 2009-08-10 at 19:16 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Aug 10, 2009 at 10:33:19AM -0400, Peter Barada wrote:
> > On Sat, 2009-08-08 at 10:17 +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Sat, Aug 08, 2009 at 09:43:13AM +0300, Felipe Balbi wrote:
> > > > On Fri, Aug 07, 2009 at 10:17:12PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote:
> > > > > On Fri, Aug 07, 2009 at 09:22:33PM +0200, ext Peter Barada wrote:
> > > > > > 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 ?
> > > > 
> > > > 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:
> > > > 
> > > > diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
> > > > index 9e3e7a5..4bc5b7f 100644
> > > > --- a/drivers/usb/otg/twl4030-usb.c
> > > > +++ b/drivers/usb/otg/twl4030-usb.c
> > 
> > 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:
> 
> 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).



-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

Re: Question regarding MUSB and dynamic fifo sizing

[Felipe Balbi]

Hi,

On Mon, Aug 10, 2009 at 01:00:07PM -0400, Peter Barada wrote:
> 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).

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.

-- 
balbi

Re: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Mon, 2009-08-10 at 20:02 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Aug 10, 2009 at 01:00:07PM -0400, Peter Barada wrote:
> > 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).
> 
> 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.

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?

-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

Re: Question regarding MUSB and dynamic fifo sizing

[Felipe Balbi]

On Mon, Aug 10, 2009 at 01:28:43PM -0400, Peter Barada wrote:
> On Mon, 2009-08-10 at 20:02 +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Aug 10, 2009 at 01:00:07PM -0400, Peter Barada wrote:
> > > 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).
> > 
> > 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.
> 
> 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?

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

-- 
balbi

Re: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Mon, 2009-08-10 at 21:48 +0300, Felipe Balbi wrote:
> On Mon, Aug 10, 2009 at 01:28:43PM -0400, Peter Barada wrote:
> > On Mon, 2009-08-10 at 20:02 +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Mon, Aug 10, 2009 at 01:00:07PM -0400, Peter Barada wrote:
> > > > 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).
> > > 
> > > 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.
> > 
> > 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?
> 
> 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.

> 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:


> 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:



> 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:

> please get such logs and post it here so we can discuss it further
> 
-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

Re: Question regarding MUSB and dynamic fifo sizing

[Felipe Balbi]

Hi,

On Mon, Aug 10, 2009 at 10:42:41PM +0200, ext Peter Barada wrote:
> 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.

that's ok, so far.

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

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.

> > 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:

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

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index c7c1ca0..9a615ee 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -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);

-- 
balbi

Re: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Tue, 2009-08-11 at 09:33 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Aug 10, 2009 at 10:42:41PM +0200, ext Peter Barada wrote:
> > 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.
> 
> that's ok, so far.
> 
> > 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.
> 
> 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.
> 
> > > 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:
> 
> 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.

-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

Re: Question regarding MUSB and dynamic fifo sizing

[Felipe Balbi]

Hi,

On Tue, Aug 11, 2009 at 11:21:17AM -0400, Peter Barada wrote:
> 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 ?

-- 
balbi

Re: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Tue, 2009-08-11 at 23:51 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Aug 11, 2009 at 11:21:17AM -0400, Peter Barada wrote:
> > 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 ?

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

-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

Re: Question regarding MUSB and dynamic fifo sizing

[Felipe Balbi]

On Tue, Aug 11, 2009 at 05:17:56PM -0400, Peter Barada wrote:
> On Tue, 2009-08-11 at 23:51 +0300, Felipe Balbi wrote:
> > Hi,
> > 
> > On Tue, Aug 11, 2009 at 11:21:17AM -0400, Peter Barada wrote:
> > > 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 ?
> 
> 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...

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.

-- 
balbi

Re: Question regarding MUSB and dynamic fifo sizing

[Peter Barada]

On Wed, 2009-08-12 at 00:17 +0300, Felipe Balbi wrote:
> On Tue, Aug 11, 2009 at 05:17:56PM -0400, Peter Barada wrote:
> > On Tue, 2009-08-11 at 23:51 +0300, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Tue, Aug 11, 2009 at 11:21:17AM -0400, Peter Barada wrote:
> > > > 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 ?
> > 
> > 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...
> 
> 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?

-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

RE: Question regarding MUSB and dynamic fifo sizing

[Gupta, Ajay Kumar]

>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 <peterb@logicpd.com>
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Question regarding MUSB and dynamic fifo sizing

[Pandita, Vikram]

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


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