On Fri, Dec 14, 2012 at 05:38:10PM -0800, ian coolidge wrote: > Felipe, Tony, Grazvydas, Thanks for the responses, > > On Fri, Dec 14, 2012 at 4:13 AM, Felipe Balbi <balbi@xxxxxx> wrote: > > > Hi, > > > > On Fri, Dec 14, 2012 at 02:13:07PM +0200, Grazvydas Ignotas wrote: > > > On Fri, Dec 14, 2012 at 11:53 AM, Ian Coolidge <iancoolidge@xxxxxxxxx> > > wrote: > > > > we find that with about a 2% chance, the gadget comes up in some kind > > of firmware failed state, driving VBUS. > > > > In this condition, we found that MUSB_DEVCTL_SESSION bit was set. > > > > I understand this to be indicative of MUSB thinking it is in host > > mode, which agrees with the driven VBUS. > > > > Further, in this state, I found that usually, there was one interrupt > > from twl4030_usb, but NO interrupts from musb-hdrc. > > > > > > I'm also also often seeing this and don't know any workaround except > > > powercycling the board :( > > > This was kind or relieved for me after I changed it to deinit musb on > > > shutdown/reset (3.3 should have that patch merged), however if you > > > randomly reset the board, there is still something like 30-50% chance > > > musb will come up dead, and on proper reset it's still something like > > > 5% chance like you reported. > > > > hehe, then you should've reported earlier :-) > > > > Anyway, I really think this has something to do with some bogus > > set_vbus() calls. > > > > Likely that looking at probe() path for checks for MUSB_DEVCTL_VBUS will > > probably show you something which is wrong. Maybe the driver is assuming > > that if VBUS bitfield is zero, then it kicks host side, or something. > > > > Go over that part of the code and you probably will find something. > > > > -- > > balbi > > > > So, I did some more testing, just printing out MUSB_DEVCTL each time. At > omap2430.c "init", > musb_probe()->musb_init_controller()->omap2430_musb_init(), > I always saw 0x80. This corresponds to MUSB_DEVCTL_BDEVICE. > It appears, then, that the MUSB is initialized correctly, but becomes bad > somehow. I'll continue to dig into this, but it would be nice to have some > simple abstract description of what the SESSION bit actually does here. > It's used as both an input and an output throughout the MUSB Linux driver, > and judging by comments, appears to have different behavior in different > configurations. Felipe? Session bit, really means a session, a USB session. It has different meanings (to some extent) when working with Host or Gadget. For Gadget mode, the session bit also triggers SRP, on host mode, maybe it's used to start sourcing VBUS, who knows. Also look at the usage of musb->is_active. That's a flag use for host mode. IIRC, it tells other parts of the driver to connect the vbus charge pump, but my memory fails now :-s -- balbi
Attachment:
signature.asc
Description: Digital signature
