Hi, On Thu, Feb 05, 2015 at 02:21:42PM +0100, Maxime Ripard wrote: > Hi, > > On Thu, Jan 22, 2015 at 08:37:45AM +0100, Yegor Yefremov wrote: > > I have the same experience with 3.15. The switching is working when > > CONFIG_USB_MUSB_DUAL_ROLE is set and dr_mode = "otg". But since 3.16 > > it seems to be broken. Still had no time to bisect this. > > I've been giving a few versions (from v3.15 to Tuesday's linux-next) a > try, and I always see the same behaviour now: > > - Booting as a gadget (ie, with a USB cable plugged in), and > swapping the cable for a (real, this time) USB OTG cable with a > USB key never works. When the device is plugged, all I get is > > [ 262.944846] usb 1-1: new high-speed USB device number 2 using musb-hdrc > [ 278.064748] usb 1-1: device descriptor read/64, error -110 > > Putting in back in gadget results with a load of continuous: > [ 315.258839] musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active > > - Booting as a host, or with nothing connected to it actually work, > up to a few plug-a-device-then-plug-a-host cycles, where you end > up with the following logs when disconnecting the device (somehow, > it always happens when it is set in host mode). > > [ 12.969075] CAUTION: musb: Babble Interrupt Occurred > [ 12.974445] CAUTION: musb: Babble Interrupt Occurred > [ 12.979637] musb_stage0_irq 789: unhandled DISCONNECT transition (a_wait_bcon) > [ 12.988498] usb 1-1: USB disconnect, device number 2 > [ 13.071849] musb-hdrc musb-hdrc.0.auto: Restarting MUSB to recover from Babble > > Plugging back our USB cable, with the AM335x acting as a device > work once. Then, when it switches to the host mode, we end up with > the same scenario than in the coldplug as gadget case: USB read > error, before then having all the a_wait_vfall messages. I gave it some more testing these two days, with next-20150410, with pretty much the same results. Dumping the DSPS glue registers doesn't get anywhere, in both cases (booting as peripheral and then switching to host, or booting as host) they are identical. However, the musb registers vary greatly. In the first case, we boot as host, switch to peripheral, and then switch back to host, repeatedly until it fails: http://code.bulix.org/p0d964-88211?raw We can see that while it still works, value comes back to their original state when switching back to host, which makes sense. However, when it fails, some registers are not set back to their initial values, including TxMaxPp, TxCSRp, RxMaxPp, ConfigData, DevCtl, TxFIFOadd and RxFIFOadd. Some registers that were not changing while it was working also now have a different value: TxMaxPp, RxMaxPp, MISC, TxFIFOsz and RxFIFOsz. Starting with the device as peripheral, and then switching to host fails instantly, once again with exotic values for the registers compared to the configuration set whenever the host mode is working: http://code.bulix.org/uo8fmu-88210?raw However, the registers values are quite similar to the one we got previously when the host mode was failing after a while, which might indicate that we end up in the same case somehow. Since I've not been able to find the musb datasheet, I'm unfortunately unable to make any deduction from these besides that something looks fishy. I've also did some runs with the musb glue and core compiled with debug options: Booted as host: http://code.bulix.org/97jz3i-88207?raw Booted as peripheral: http://code.bulix.org/vqdqt6-88208?raw I hope it helps... Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
