On Thu, May 05, 2016 at 04:02:55PM +0000, Andrew Goodbody wrote: > > From: Bin Liu [mailto:b-...@ti.com] > > On Thu, May 05, 2016 at 03:12:00PM +0000, Andrew Goodbody wrote: > > > > From: Bin Liu [mailto:b-...@ti.com] > > > > Hi, > > > > > > > > On Thu, May 05, 2016 at 12:22:33PM +0000, Andrew Goodbody wrote: > > > > > > From: Bin Liu [mailto:b-...@ti.com] Hi, > > > > > > > > > > > > On Wed, May 04, 2016 at 03:48:50PM +0000, Andrew Goodbody > > wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I have been investigating communication issues with iPads. > > > > > > > When the system is busy it seems that the musb driver is > > > > > > > silently dropping occasional packets. I have a usbmon trace > > > > > > > that does not show the packet and I have a trace from a > > > > > > > hardware USB analyser that does show the packet. So the device > > > > > > > is correctly sending the packet, it is even being ACKed, but > > > > > > > it is not passed up to the application. The packet is a bulk > > > > > > > transfer packet of 20 bytes. Can anyone please give me > > > > > > > pointers to where to go looking for the problem? The syslog shows > > nothing relevant. > > > > > > > > > > > > What is the part number on the am3352 chip? > > > > > > > > > > AM3352BZCZ100 > > > > > > > > > > > What kernel version do you use? > > > > > > > > > > 4.5.0 > > > > > > > > > > > Is musb cppi dma enabled? If so, does the problem still happen > > > > > > when CPPI disabled? > > > > > > > > > > Yes. Yes. When testing with PIO I did get the message "Rx > > > > > interrupt with no > > > > errors or packet!". > > > > > > > > > > > First try to turn on dynamic debug log in musb_host.c to check > > > > > > if musb receives the packet or not. > > > > > > > > > > > > Regards, > > > > > > -Bin. > > > > > > > > > > I am having problems doing this. If I enable the whole file then I > > > > > get lots of messages on the console about /dev/kmsg buffer > > > > > overrun. There are more then 26 million packets in the hardware > > > > > trace and I have not worked out how to correlate any of the > > > > > possible message from dynamic debug with those packets even when I > > > > > enable some of the dynamic debug lines. I can see a few messages > > > > > about "DMA complete but packet still in FIFO, CSR 2103" and just the > > occasional "extra TX2 ready, csr 2100" > > > > > when I enable some of the lines for dynamic debug. > > > > > > > > Well, this issue would not be easy to debug. Is this with your custom > > board? > > > > If so, have you run EyeDiagram test to rule out signal integrity > > > > problem? Are you able to reproduce it with any TI EVM, such as > > > > Beaglebone Black? If so, please explain the detail of the test case, > > > > I could try to reproduce it on my side. > > > > > > Yes this is on a custom board and yes we did EyeDiagram tests. Also > > > the ACK from the controller is seen, so that should rule out signal > > > integrity issues. I have just reproduced this on the Beaglebone Black > > > using the latest TI SDK. Do you have access to 16 iPads with lightning > > > connectors and do you have a Mac running 10.10.x? > > > > No, I don't have those :( > > > > 16 devices connecting to musb sounds too many. what is the ep info in the > > descriptor of the ipad device? > > T: Bus=02 Lev=04 Prnt=06 Port=06 Cnt=07 Dev#= 19 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 4 > P: Vendor=05ac ProdID=12ab Rev= 3.40 > S: Manufacturer=Apple Inc. > S: Product=iPad > S: SerialNumber=1da5f4610eafb36fa1e9eead80a56cb2db11dfce > C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=500mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver= > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=1250us > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=64ms > C: #Ifs= 3 Cfg#= 2 Atr=c0 MxPwr=500mA > I: If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver= > I: If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver= > I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver= > E: Ad=81(I) Atr=01(Isoc) MxPS= 192 Ivl=1ms > I: If#= 2 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver= > E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=125us > C:* #Ifs= 2 Cfg#= 3 Atr=c0 MxPwr=500mA > I:* If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver=usbfs > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=1250us > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=64ms > I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=fe Prot=02 Driver=usbfs > E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > C: #Ifs= 3 Cfg#= 4 Atr=c0 MxPwr=500mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver= > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=1250us > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=64ms > I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=fe Prot=02 Driver= > E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > I: If#= 2 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=fd Prot=01 Driver= > I: If#= 2 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=fd Prot=01 Driver= > E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > I: If#= 2 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=fd Prot=01 Driver= > E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > Config #4 is the relevant one. Interface #0 quickly uses up the > controller endpoints and then starts to return -ENOSPC thereafter for > the interrupt URBs from later iPads, but that does not matter for my > use case. Interface #1 is the one that is actually used, just a bulk > in and a bulk out endpoint. So some URBs get opened on controller > endpoints 2-15, but most are just queued up on controller endpoint 1. > Yes this will keep the controller busy.
Well, I am not sure musb is able to support your use case. As you just said, the required endpoints are more than musb provides, so some urbs are queued to ep1, which is not ideal, but the driver is just designed that way. Honestly, I haven't checked what would happen if some bulk endpoint urbs are queued to ep1. > > Although I said 16 iPads, this problem will happen with fewer, it just > becomes rarer. How many? Please keep in mind that you probably have 5 hubs connected, which take 5 INT endpoints permanently. > > Andrew > > > > > > > > > > > Andrew > > > > > > > > Regards, > > > > -Bin. Regards, -Bin. -- 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
