Hi, On Thu, Oct 06, 2016 at 02:45:30PM +0000, Andrew Goodbody wrote: > I am trying to investigate an issue on a TI Sitara CPU, AM3352 with > the musb USB controller. > > The scenario is that a device has been in use and working correctly. > The device is an Android device and is presenting as an MTP device. AM3352 musb is the host or device? Sounds like it is the host. > That first session of use is finished and the port is reset but the > device is not unplugged, so enumeration and configuration starts again How this happened? How do you control the host reset the device but not re-enumerate it? > the next time it is needed. The transfers over EP0 using PIO all > proceed as expected. The problem is the first bulk packet sent to EP1, > which also happens to be the first dma packet. USBMON shows this > packet as being sent. However a hardware analyser does not show this > packet on the wire and of course there is no ACK either. Looking at > the debug info from the musb driver I can see the dma being started > and then the callback being called. MUSB_TXCSR_TXPKTRDY remains set as > does MUSB_TXCSR_TXFIFONOTEMPTY so nothing else happens. The TXCSR > register is 0x3403. The code is waiting for MUSB_TXCSR_TXPKTRDY to be > cleared but that will not happen until an ACK is received. It just > seems that the controller is not putting the packet onto the wire for > some reason. Sounds to me that the cppi teamdown before/during bus reset was not complete, so the channels are not in the ready state for next transfers. I don't have a better way to debug it, but you have to ensure the teardown sequence does follow that in the normal device detach. If the issue still happens, you would have to dump the cppi registers to see why the channels are in the wrong state. > > This is on 4.5.1. > > I would welcome some pointers on how to proceed to debug this or else > any information on possible applicable errata and workarounds for > this. It is more like software problem to me. Good luck. Regards, -Bin. > > Thanks, > Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
