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