From: Felipe Balbi <me@felipebalbi.com>
To: Peter Barada <peterb@logicpd.com>
Cc: me@felipebalbi.com, felipe.balbi@nokia.com, "Pandita,
Vikram" <vikram.pandita@ti.com>,
"Gadiyar, Anand" <gadiyar@ti.com>,
linux-omap <linux-omap@vger.kernel.org>
Subject: Re: Question regarding MUSB and dynamic fifo sizing
Date: Mon, 10 Aug 2009 21:48:19 +0300 [thread overview]
Message-ID: <20090810184818.GA4281@gandalf> (raw)
In-Reply-To: <1249925323.31495.31.camel@blitz>
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
next prev parent reply other threads:[~2009-08-10 18:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-06 20:10 Question regarding MUSB and dynamic fifo sizing Peter Barada
2009-08-06 20:11 ` Gadiyar, Anand
2009-08-07 17:23 ` Peter Barada
2009-08-07 17:25 ` Pandita, Vikram
2009-08-07 17:55 ` Peter Barada
2009-08-07 19:22 ` Peter Barada
2009-08-07 20:17 ` Felipe Balbi
2009-08-08 6:43 ` Felipe Balbi
2009-08-08 7:17 ` Felipe Balbi
2009-08-10 14:33 ` Peter Barada
2009-08-10 16:16 ` Felipe Balbi
2009-08-10 17:00 ` Peter Barada
2009-08-10 17:02 ` Felipe Balbi
2009-08-10 17:28 ` Peter Barada
2009-08-10 18:48 ` Felipe Balbi [this message]
2009-08-10 20:42 ` Peter Barada
2009-08-11 6:33 ` Felipe Balbi
2009-08-11 15:21 ` Peter Barada
2009-08-11 20:51 ` Felipe Balbi
2009-08-11 21:17 ` Peter Barada
2009-08-11 21:17 ` Felipe Balbi
2009-08-20 16:29 ` Peter Barada
2009-08-08 3:04 ` Gupta, Ajay Kumar
2009-08-08 5:03 ` Pandita, Vikram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090810184818.GA4281@gandalf \
--to=me@felipebalbi.com \
--cc=felipe.balbi@nokia.com \
--cc=gadiyar@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=peterb@logicpd.com \
--cc=vikram.pandita@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox