> From: Bin Liu [mailto:b-...@ti.com] > 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.
Yes, musb 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? Not what I said. The device is of course re-enumerated after the reset. There can be multiple sessions of use of the device, but these multiple sessions occur without unplugging. Each session starts with a reset and continues as normal from there, but with the Android MTP devices only the first session is successful. > > 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 OK, I did some more digging on this. Firstly I found it also happens in PIO mode. I then put another hub in the chain. This time I see the packet on the wire between the hubs. The packet however never leaves the downstream hub to get to the device. So it looks like the device is somehow blocking the bus and preventing the packet being sent. As this can be caused by multiple different devices, although all Android MTP, and it can also be seen with a RasPi host, the fault looks to be in the Android MTP stack not expecting to be restarted without a complete unplug. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
