Hi, On Fri, Dec 14, 2012 at 01:53:07AM -0800, Ian Coolidge wrote: > Hi, > > We're using Linux 3.3 on DM3730 with TPS6595xx PMIC for an embedded > product. > For a particular board, we have musb-hdrc (RTL 1.4) configured in peripheral mode. > We use the Ethernet gadget configured for cdc_eem to use Ethernet > emulation over USB for this link, and the robustness of the link is > mission-critical. To assure this, we have performed some massive > reboot testing to ensure that this usb link reliably comes up. > > After working through an issue which required pulling in the following > patch, > ----- > commit b1b552a69b8805e7e338074a9e8b670b4a795218 > Author: Michael Grzeschik <m.grzeschik@xxxxxxxxxxxxxx> > Date: Wed Aug 8 11:48:10 2012 +0200 > > usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop > ----- > > 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. > > So, as a hack, I cleared MUSB_DEVCTL_SESSION in omap2430.c in the > notifier block from the VBUS interrupt. > This appears to reduce the frequency of the problem -- I now always at > least one instance of the musb-hdrc interrupt. > However, sometimes, it looks like the MUSB PHY dies shortly > thereafter. > So, I don't think this hack is fully effective. > > I reviewed commits that post-date 3.3 in omap2430.c, musb_core.c, > twl4030-usb.c, musb_gadget.c, and I couldn't find anything interesting > -- it looks like mostly reorganization has taken place. > > We have also engaged TI to try to get some silicon errata from Mentor > Graphics, and maybe a register manual for the MUSB HDRC IP, but this > is slow going, and that has little guarantee of paying off anyways. > > Are there any ideas, or patches that anyone might suggest? I don't think it's a silicon errata. Looks like a driver bug to me. But since you're using such an old kernel, your TI support channel is the only way forward, unless you can test with a more recent kernel like v3.7. From what you describe, however, it sounds like it's a problem with some ->set_vbus() call. -- balbi
Attachment:
signature.asc
Description: Digital signature
