OMAP3430: MUSB host and hot-plugging
Using the default config omap_3430sdp_defconig, I'm doing some basic hot-plug tests of MUSB in host mode.
I noticed that after booting, the first time I connect my USB key, it is detected just fine, the usb/scsi storage modulesare loaded by hotplug and I can access the device just fine.
I then remove the key, and the kernel seems to detect the removal just fine, and does what seems to be a clean shutdown.
However, if I then plug the key back in, nothing happens.
Forcing a session start via "echo 'F' > /proc/driver/musb_hdrc" causes the device to be (re)detected and things look good again. It is not until I force the session start that I see the interrupt and the CONNECT event.
Any ideas why this isn't detected on insertion?
Thanks,
Kevin
Quoted 8 lines · Kevin Hilman
However, if I then plug the key back in, nothing happens.
Forcing a session start via "echo 'F' >
/proc/driver/musb_hdrc" causes the device to be (re)detected and things look good again. It is not until I force the session start that I see the interrupt and the CONNECT event.Any ideas why this isn't detected on insertion?
Just for the record ... that's always been a problem. There's some strange side-effect driven magic in the Mentor IP, right in that area, which has always been fragile.
For example, it seems to think something other than the state of the ID pin should control whether it's in the A-side state machine (default host) or the B-side one (default peripheral), and it gets fairly twitchey about VBUS levels too ... as in, it doesn't allow the specified 100 msec for it to stabilize, and enters a fault/shutdown mode if voltage drops because of, say, contact bounce or inrush current, while it stabilizes.
Needing that "force session start" is a warning flag. The very notion of that kind of "session" is something introduced by Mentor, which is not part of the OTG spec (at least, not in anything like that form). Multiple weeks have been wasted trying to sort out misbehavior in that area, and there seem to be revision-specific issues too.
- Dave
Quoted 23 lines · David Brownell
Quoted 8 lines · Kevin Hilman
However, if I then plug the key back in, nothing happens.
Forcing a session start via "echo 'F' >
/proc/driver/musb_hdrc" causes the device to be (re)detected and things look good again. It is not until I force the session start that I see the interrupt and the CONNECT event.Any ideas why this isn't detected on insertion?
Just for the record ... that's always been a problem. There's some strange side-effect driven magic in the Mentor IP, right in that area, which has always been fragile.
For example, it seems to think something other than the state of the ID pin should control whether it's in the A-side state machine (default host) or the B-side one (default peripheral), and it gets fairly twitchey about VBUS levels too ... as in, it doesn't allow the specified 100 msec for it to stabilize, and enters a fault/shutdown mode if voltage drops because of, say, contact bounce or inrush current, while it stabilizes.
Quoted 6 lines
Needing that "force session start" is a warning flag. The very notion of that kind of "session" is something introduced by Mentor, which is not part of the OTG spec (at least, not in anything like that form). Multiple weeks have been wasted trying to sort out misbehavior in that area, and there seem to be revision-specific issues too.
Looks like code is flakey again after merging usb stuff with mainline then?
But I tried with n800/n810 and it's working fine, this surely means the problem resides either in drivers/usb/musb/omap2430.c or driver/i2c/chips/twl4030-usb.c
I'm more into some flakeyness in omap2430.c as it looks like twl4030-usb.c generates the cable insertion interrupt. Could it be some problem in the ULPI support for omap3 that's preventing musb to wake up and switch to host role ? Maybe we're not getting wakeup events e.g. cable insertion interrupt is not waking up Mentor IP Core ?
Well, these still some thoughts I still need to debug more in order to really understand the problem there.
Signature · 5 lines
Best Regards, Felipe Balbi [email protected] http://blog.felipebalbi.com
Quoted 3 lines · Felipe Balbi
Could it be some
problem in the ULPI support for omap3 that's preventing musb to wake up and switch to host role ?
Your theory is as good as mine; I don't have that hardware.
I was just pointing out that this specific area has always been a significant PITA for the MUSB silicon ... I'm not the only developer who's ended up losing weeks of time chasing (undocumented) bogosity in the area of host-side startup.
The thing is that making it "switch to host role" is the very black magic that regularly misbehaved. ISTR there was a chicken/egg thing going on: it couldn't know it needed to switch to "host role" unless the oddball Mentor "session" was already active, but it couldn't be activated unless you somehow knew it should be in host role...
Quoted 12 lines · David Brownell
Quoted 3 lines · Felipe Balbi
Could it be some
problem in the ULPI support for omap3 that's preventing musb to wake up and switch to host role ?Your theory is as good as mine; I don't have that hardware.
I was just pointing out that this specific area has always been a significant PITA for the MUSB silicon ... I'm not the only developer who's ended up losing weeks of time chasing (undocumented) bogosity in the area of host-side startup.
Quoted 6 lines
The thing is that making it "switch to host role" is the very black magic that regularly misbehaved. ISTR there was a chicken/egg thing going on: it couldn't know it needed to switch to "host role" unless the oddball Mentor "session" was already active, but it couldn't be activated unless you somehow knew it should be in host role...
Hmm... thanks for the tips Dave, I'll re-check that programmers guide again tomorrow and try to debug a bit more.
Signature · 5 lines
Best Regards, Felipe Balbi [email protected] http://blog.felipebalbi.com
Quoted 15 lines
Sent: Friday, March 21, 2008 1:55 AM
Quoted 3 lines · Felipe Balbi
Could it be some
problem in the ULPI support for omap3 that's preventing musb to wake up and switch to host role ?Your theory is as good as mine; I don't have that hardware.
I was just pointing out that this specific area has always been a significant PITA for the MUSB silicon ... I'm not the only developer who's ended up losing weeks of time chasing (undocumented) bogosity in the area of host-side startup.
Quoted 6 lines
The thing is that making it "switch to host role" is the very black magic that regularly misbehaved. ISTR there was a chicken/egg thing going on: it couldn't know it needed to switch to "host role" unless the oddball Mentor "session" was already active, but it couldn't be activated unless you somehow knew it should be in host role...
The right way then to debug would be to do an LA probe of ULPI signals on re-attach.
To get around this problem, I have heard of implementations having a separate GPIO implemented to wakeup the system on cable attaches. Don't remember which implementation though. I will see if I get time to work on this and will keep posted.
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html