RE: Errata for Freescale root-hub TT?
Le Mon, 29 Jun 2015 16:40:52 +0800, Peter Chen peter.c...@freescale.com a écrit : I am not sure if you have noticed the patch[1], it is the solution for this issue, in the RTL, the default reserved time for one packet is 1023 bytes for siTD, so after 4 * 64 packets has transfered, the reserved time is not enough for 1023 bytes packet. This issue should exist at all ARC/Chipidea cores. In that case can't we enable the patch for all cores instead of using platform data flags ? Hi Matthieu This bit may also affects QH, we only make sure Freescale's part QH design does not be affected by this tt ctrl bits, but doesn't know other vender's. Peter
Re: Errata for Freescale root-hub TT?
Hi Peter, Le Mon, 29 Jun 2015 16:40:52 +0800, Peter Chen peter.c...@freescale.com a écrit : I am not sure if you have noticed the patch[1], it is the solution for this issue, in the RTL, the default reserved time for one packet is 1023 bytes for siTD, so after 4 * 64 packets has transfered, the reserved time is not enough for 1023 bytes packet. This issue should exist at all ARC/Chipidea cores. In that case can't we enable the patch for all cores instead of using platform data flags ? Matthieu -- 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
Re: Errata for Freescale root-hub TT?
On Mon, 29 Jun 2015, Peter Chen wrote: Hi Alan, I am not sure if you have noticed the patch[1], it is the solution for this issue, in the RTL, the default reserved time for one packet is 1023 bytes for siTD, so after 4 * 64 packets has transfered, the reserved time is not enough for 1023 bytes packet. This issue should exist at all ARC/Chipidea cores. [1] http://www.spinics.net/lists/linux-usb/msg126278.html No, I did not notice it. Thank you for pointing it out. It's kind of surprising that this bug has existed for so long and nobody realized until recently. Alan Stern -- 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
Re: Errata for Freescale root-hub TT?
On Tue, Mar 31, 2015 at 10:02:52AM -0400, Alan Stern wrote: On Tue, 31 Mar 2015, Peter Chen wrote: I reproduced this issue, I can't see the fifth endpoints during the SoFs although the time to SoF boundary is about 800us, see attached. - At transaction 3749, the third UAC2 gadget is ready to send/receive data. - At next SoF periods, the first and the second devices send/receive data. - At transaction 3754, the third device's OUT is on the bus, but the address 11's OUT is disappeared. I reported this problem to IC team, but they are on new SoC validation periods, they said they will simulate it after new project has finished. That's great! I'm happy that you were able to duplicate the problem. Please let me know what the IC team has to say when they look at it. Do you know whether Freescale's root-hub TT implementation was done in-house? Or was it based on the old ARC/TDI IP? It's possible that a lot of different kinds of host controllers suffer from this problem. Alan Stern Hi Alan, I am not sure if you have noticed the patch[1], it is the solution for this issue, in the RTL, the default reserved time for one packet is 1023 bytes for siTD, so after 4 * 64 packets has transfered, the reserved time is not enough for 1023 bytes packet. This issue should exist at all ARC/Chipidea cores. [1] http://www.spinics.net/lists/linux-usb/msg126278.html -- Best Regards, Peter Chen -- 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
Re: Errata for Freescale root-hub TT?
On Thu, 2 Apr 2015, Peter Chen wrote: On Wed, Apr 01, 2015 at 10:35:16AM -0400, Alan Stern wrote: On Wed, 1 Apr 2015, Peter Chen wrote: This is bad. All the endpoints have maxpacket = 1023, and that's much too big for this test. We need a maxpacket size of 64 (maybe a little bigger but not much). Back to this issue, 1024 bytes is only ~70% for frame, why it reports iso sched full when I only wants to use one endpoint for playback or capture? The low/full-speed periodic scheduler in ehci-hcd is pretty bad. It doesn't follow the recommendations of the USB spec and it is sub-optimal in several respects. One consequence of these problems is that it is not able to schedule any isochronous transfer with a maximum packet size larger than about 990 bytes. Get it. That's why I got iso sched full with direct full-speed connection between UAC2 gadget (with wMaxPacketSize = 1023) and host controller. But why it does not allocate bandwidth according to frame rate, but according to wMaxPacketSize? Audio does requirement (through URB) for it? The host controller driver takes _both_ the frame rate (bInterval) and wMaxPacketSize into account. The problem is that with normal audio parameters (for example, 16-bit stereo at 48 KHz) the audio driver will use packets that are much shorter than wMaxPacketSize (192 bytes, not 1023 bytes). But the HCD doesn't know this, and it has to allocate bandwidth under the assumption that all the packets will be as large as possible. That's why real audio devices tend to have lots of alternate settings; each altsetting has a different wMaxPacketSize suitable for a particular set of audio parameters. In the past, people have discussed adding an API for drivers to tell the HCD what size packets they intend to use. This could override the wMaxPacketSize value in the bandwidth calculations. But it was not a high priority, and nobody has implemented it. Alan Stern -- 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
Re: Errata for Freescale root-hub TT?
On Mon, Mar 30, 2015 at 10:03:07AM -0400, Alan Stern wrote: On Mon, 30 Mar 2015, Peter Chen wrote: That's strange. Can you please post the /sys/kernel/debug/usb/devices file (with the UAC2 gadget plugged in), and also collect a usbmon trace of the test? It should be UAC2 gadget or chipidea driver problem, it is ok if I plug in USB audio card, but most of current audio cards support 44.1k+ frame rate, it can't handle the 3rd endpoint (176-184 bytes / endpoint), I don't know how to let it only read/writes 64 bytes, anyway, I will fix the UAC2 gadget problem first. Device file for UAC2: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=12 MxCh= 0 D: Ver= 0.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=15a2 ProdID=0054 Rev= 4.00 S: Manufacturer=Freescale S: Product=FSL i.mx6q sabreSD Board S: SerialNumber=123456ABCDEF C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr= 6mA A: FirstIf#= 0 IfCount= 3 Cls=01(audio) Sub=00 Prot=20 I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio I:* If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=01(O) Atr=05(Isoc) MxPS=1023 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=81(I) Atr=05(Isoc) MxPS=1023 Ivl=1ms This is bad. All the endpoints have maxpacket = 1023, and that's much too big for this test. We need a maxpacket size of 64 (maybe a little bigger but not much). Back to this issue, 1024 bytes is only ~70% for frame, why it reports iso sched full when I only wants to use one endpoint for playback or capture? -- Best Regards, Peter Chen -- 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
Re: Errata for Freescale root-hub TT?
On Wed, 1 Apr 2015, Peter Chen wrote: This is bad. All the endpoints have maxpacket = 1023, and that's much too big for this test. We need a maxpacket size of 64 (maybe a little bigger but not much). Back to this issue, 1024 bytes is only ~70% for frame, why it reports iso sched full when I only wants to use one endpoint for playback or capture? The low/full-speed periodic scheduler in ehci-hcd is pretty bad. It doesn't follow the recommendations of the USB spec and it is sub-optimal in several respects. One consequence of these problems is that it is not able to schedule any isochronous transfer with a maximum packet size larger than about 990 bytes. Your case is even worse, because with a full-speed hub plugged in, part of the periodic schedule is already committed for the hub's status URB. As a result, no isochronous transfer with maxpacket larger than about 830 bytes can be scheduled. Alan Stern -- 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
Re: Errata for Freescale root-hub TT?
On Wed, Apr 01, 2015 at 10:35:16AM -0400, Alan Stern wrote: On Wed, 1 Apr 2015, Peter Chen wrote: This is bad. All the endpoints have maxpacket = 1023, and that's much too big for this test. We need a maxpacket size of 64 (maybe a little bigger but not much). Back to this issue, 1024 bytes is only ~70% for frame, why it reports iso sched full when I only wants to use one endpoint for playback or capture? The low/full-speed periodic scheduler in ehci-hcd is pretty bad. It doesn't follow the recommendations of the USB spec and it is sub-optimal in several respects. One consequence of these problems is that it is not able to schedule any isochronous transfer with a maximum packet size larger than about 990 bytes. Get it. That's why I got iso sched full with direct full-speed connection between UAC2 gadget (with wMaxPacketSize = 1023) and host controller. But why it does not allocate bandwidth according to frame rate, but according to wMaxPacketSize? Audio does requirement (through URB) for it? Your case is even worse, because with a full-speed hub plugged in, part of the periodic schedule is already committed for the hub's status URB. As a result, no isochronous transfer with maxpacket larger than about 830 bytes can be scheduled. Alan Stern -- Best Regards, Peter Chen -- 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
Re: Errata for Freescale root-hub TT?
On Tue, 31 Mar 2015, Peter Chen wrote: I reproduced this issue, I can't see the fifth endpoints during the SoFs although the time to SoF boundary is about 800us, see attached. - At transaction 3749, the third UAC2 gadget is ready to send/receive data. - At next SoF periods, the first and the second devices send/receive data. - At transaction 3754, the third device's OUT is on the bus, but the address 11's OUT is disappeared. I reported this problem to IC team, but they are on new SoC validation periods, they said they will simulate it after new project has finished. That's great! I'm happy that you were able to duplicate the problem. Please let me know what the IC team has to say when they look at it. Do you know whether Freescale's root-hub TT implementation was done in-house? Or was it based on the old ARC/TDI IP? It's possible that a lot of different kinds of host controllers suffer from this problem. Alan Stern -- 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
Re: Errata for Freescale root-hub TT?
On Tue, Mar 31, 2015 at 10:02:52AM -0400, Alan Stern wrote: On Tue, 31 Mar 2015, Peter Chen wrote: I reproduced this issue, I can't see the fifth endpoints during the SoFs although the time to SoF boundary is about 800us, see attached. - At transaction 3749, the third UAC2 gadget is ready to send/receive data. - At next SoF periods, the first and the second devices send/receive data. - At transaction 3754, the third device's OUT is on the bus, but the address 11's OUT is disappeared. I reported this problem to IC team, but they are on new SoC validation periods, they said they will simulate it after new project has finished. That's great! I'm happy that you were able to duplicate the problem. Please let me know what the IC team has to say when they look at it. Sure Do you know whether Freescale's root-hub TT implementation was done in-house? Or was it based on the old ARC/TDI IP? It's possible that a lot of different kinds of host controllers suffer from this problem. Afaik, It is based on chipidea IP, should be the old ARC IP, since chipidea got this IP from ARC. -- Best Regards, Peter Chen -- 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
Re: Errata for Freescale root-hub TT?
On Fri, Mar 27, 2015 at 09:47:06AM -0400, Alan Stern wrote: On Fri, 27 Mar 2015, Peter Chen wrote: Hi Alan, I tried to your case today, but it seems full speed hub with siTD has some problems with latest greg's next tree, I use UAC2 with configfs for audio device, high speed hub works ok. The commands: aplay -D hw:1,0 audio32k16M.wav arecord -Dhw:1 -r 32000 -c 1 -f S16_LE -d 20 file_32.wav The corresponding failure logs: [ 81.542848] ci_hdrc ci_hdrc.0: iso sched full bd7d5100 [ 81.542884] usb 1-1.2: cannot submit urb 0, error -28: not enough bandwidth [ 355.078938] ci_hdrc ci_hdrc.0: iso sched full bd49cc00 [ 355.078969] usb 1-1.2: cannot submit urb 0, error -28: not enough bandwidth That's strange. Can you please post the /sys/kernel/debug/usb/devices file (with the UAC2 gadget plugged in), and also collect a usbmon trace of the test? It should be UAC2 gadget or chipidea driver problem, it is ok if I plug in USB audio card, but most of current audio cards support 44.1k+ frame rate, it can't handle the 3rd endpoint (176-184 bytes / endpoint), I don't know how to let it only read/writes 64 bytes, anyway, I will fix the UAC2 gadget problem first. Device file for UAC2: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=12 MxCh= 0 D: Ver= 0.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=15a2 ProdID=0054 Rev= 4.00 S: Manufacturer=Freescale S: Product=FSL i.mx6q sabreSD Board S: SerialNumber=123456ABCDEF C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr= 6mA A: FirstIf#= 0 IfCount= 3 Cls=01(audio) Sub=00 Prot=20 I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio I:* If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=01(O) Atr=05(Isoc) MxPS=1023 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=81(I) Atr=05(Isoc) MxPS=1023 Ivl=1ms usbmon trace: I did not trace it since I did not find any data traffic on the bus through USB Bus Analyzer. -- Best Regards, Peter Chen -- 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
Re: Errata for Freescale root-hub TT?
On Mon, 30 Mar 2015, Peter Chen wrote: That's strange. Can you please post the /sys/kernel/debug/usb/devices file (with the UAC2 gadget plugged in), and also collect a usbmon trace of the test? It should be UAC2 gadget or chipidea driver problem, it is ok if I plug in USB audio card, but most of current audio cards support 44.1k+ frame rate, it can't handle the 3rd endpoint (176-184 bytes / endpoint), I don't know how to let it only read/writes 64 bytes, anyway, I will fix the UAC2 gadget problem first. Device file for UAC2: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=12 MxCh= 0 D: Ver= 0.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=15a2 ProdID=0054 Rev= 4.00 S: Manufacturer=Freescale S: Product=FSL i.mx6q sabreSD Board S: SerialNumber=123456ABCDEF C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr= 6mA A: FirstIf#= 0 IfCount= 3 Cls=01(audio) Sub=00 Prot=20 I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio I:* If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=01(O) Atr=05(Isoc) MxPS=1023 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=81(I) Atr=05(Isoc) MxPS=1023 Ivl=1ms This is bad. All the endpoints have maxpacket = 1023, and that's much too big for this test. We need a maxpacket size of 64 (maybe a little bigger but not much). It may be possible to test the hardware without actually plugging in a USB audio device. I can write a testing patch for ehci-hcd that will cause it to create all the appropriate siTDs and link them into the periodic schedule. All you will need is a full-speed hub. The host controller will send the isochronous packets to the hub and you should be able to watch them on a bus analyzer. There won't be any response to the packets (obviously!), but for isochronous that's okay. Does that sound like it will work? Alan Stern -- 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
Re: Errata for Freescale root-hub TT?
On Mon, Mar 30, 2015 at 10:03:07AM -0400, Alan Stern wrote: On Mon, 30 Mar 2015, Peter Chen wrote: That's strange. Can you please post the /sys/kernel/debug/usb/devices file (with the UAC2 gadget plugged in), and also collect a usbmon trace of the test? It should be UAC2 gadget or chipidea driver problem, it is ok if I plug in USB audio card, but most of current audio cards support 44.1k+ frame rate, it can't handle the 3rd endpoint (176-184 bytes / endpoint), I don't know how to let it only read/writes 64 bytes, anyway, I will fix the UAC2 gadget problem first. Device file for UAC2: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 14 Spd=12 MxCh= 0 D: Ver= 0.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=15a2 ProdID=0054 Rev= 4.00 S: Manufacturer=Freescale S: Product=FSL i.mx6q sabreSD Board S: SerialNumber=123456ABCDEF C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr= 6mA A: FirstIf#= 0 IfCount= 3 Cls=01(audio) Sub=00 Prot=20 I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio I:* If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=01(O) Atr=05(Isoc) MxPS=1023 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio I: If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=81(I) Atr=05(Isoc) MxPS=1023 Ivl=1ms This is bad. All the endpoints have maxpacket = 1023, and that's much too big for this test. We need a maxpacket size of 64 (maybe a little bigger but not much). Thanks, after changing maxpacket to 64, this problem is fixed. Go back to UAC2 spec, it defines wMaxPacketSize like below: Maximum packet size this endpoint is capable of sending or receiving when this configuration is selected. This is determined by the audio bandwidth constraints of the endpoint. So, the UAC2 should calculate maxpacket according to frame rate, and channel number. I will see if I can reproduce your case today. It may be possible to test the hardware without actually plugging in a USB audio device. I can write a testing patch for ehci-hcd that will cause it to create all the appropriate siTDs and link them into the periodic schedule. All you will need is a full-speed hub. The host controller will send the isochronous packets to the hub and you should be able to watch them on a bus analyzer. There won't be any response to the packets (obviously!), but for isochronous that's okay. Does that sound like it will work? Alan Stern -- Best Regards, Peter Chen -- 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
Re: Errata for Freescale root-hub TT?
On Wed, Mar 25, 2015 at 10:11:27AM -0400, Alan Stern wrote: On Wed, 25 Mar 2015, Peter Chen wrote: How do you know the frame has filled already at that time? The software makes sure it fills frame in time before next time frame? I'm not sure I understand the question. The USB analyzer log showed something like this (this is a rough approximation because I didn't keep the original analyzer output file): Timestamp Transaction s.mmm uuu --- 0.000 000 SOF 0.000 030 Isoc OUT 0.000 091 Isoc OUT 0.000 162 Isoc OUT 0.000 224 Isoc OUT 0.001 000 SOF In this example, there are 4 OUT transfers taking about 290 us and then nothing else for the rest of the frame. I also know, from looking at the periodic file in the EHCI debugfs directory, that each frame was linked to 8 siTDs: siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 I did not debug too many for Host ISOC, I just want to make sure the siTD is ready before the controller read it? Yes, all the siTDs were ready before the controller read them. I know because it worked perfectly when I used a high-speed hub instead of a full-speed hub. Does it fail at the beginning or running several cycles? The isochronous streams did not all start at the same time. First one isoc-OUT stream started, then the second stream, then the third stream, then the fourth stream. After that, the isoc-IN streams started, one by one. The controller worked okay up until the time the isoc-IN streams began. Before that, it transmitted the OUT packets correctly. After the isoc-IN streams started, the controller sometimes transmitted only the four OUT packets (like in the example above), sometimes a mixture of OUT and IN packets, and sometimes only one or two IN packets. The behavior was very erratic. Hi Alan, I tried to your case today, but it seems full speed hub with siTD has some problems with latest greg's next tree, I use UAC2 with configfs for audio device, high speed hub works ok. The commands: aplay -D hw:1,0 audio32k16M.wav arecord -Dhw:1 -r 32000 -c 1 -f S16_LE -d 20 file_32.wav The corresponding failure logs: [ 81.542848] ci_hdrc ci_hdrc.0: iso sched full bd7d5100 [ 81.542884] usb 1-1.2: cannot submit urb 0, error -28: not enough bandwidth [ 355.078938] ci_hdrc ci_hdrc.0: iso sched full bd49cc00 [ 355.078969] usb 1-1.2: cannot submit urb 0, error -28: not enough bandwidth -- Best Regards, Peter Chen -- 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
Re: Errata for Freescale root-hub TT?
On Fri, 27 Mar 2015, Peter Chen wrote: Hi Alan, I tried to your case today, but it seems full speed hub with siTD has some problems with latest greg's next tree, I use UAC2 with configfs for audio device, high speed hub works ok. The commands: aplay -D hw:1,0 audio32k16M.wav arecord -Dhw:1 -r 32000 -c 1 -f S16_LE -d 20 file_32.wav The corresponding failure logs: [ 81.542848] ci_hdrc ci_hdrc.0: iso sched full bd7d5100 [ 81.542884] usb 1-1.2: cannot submit urb 0, error -28: not enough bandwidth [ 355.078938] ci_hdrc ci_hdrc.0: iso sched full bd49cc00 [ 355.078969] usb 1-1.2: cannot submit urb 0, error -28: not enough bandwidth That's strange. Can you please post the /sys/kernel/debug/usb/devices file (with the UAC2 gadget plugged in), and also collect a usbmon trace of the test? Thanks, Alan Stern -- 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
Re: Errata for Freescale root-hub TT?
On Wed, 25 Mar 2015, Peter Chen wrote: How do you know the frame has filled already at that time? The software makes sure it fills frame in time before next time frame? I'm not sure I understand the question. The USB analyzer log showed something like this (this is a rough approximation because I didn't keep the original analyzer output file): Timestamp Transaction s.mmm uuu --- 0.000 000 SOF 0.000 030 Isoc OUT 0.000 091 Isoc OUT 0.000 162 Isoc OUT 0.000 224 Isoc OUT 0.001 000 SOF In this example, there are 4 OUT transfers taking about 290 us and then nothing else for the rest of the frame. I also know, from looking at the periodic file in the EHCI debugfs directory, that each frame was linked to 8 siTDs: siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 I did not debug too many for Host ISOC, I just want to make sure the siTD is ready before the controller read it? Yes, all the siTDs were ready before the controller read them. I know because it worked perfectly when I used a high-speed hub instead of a full-speed hub. Does it fail at the beginning or running several cycles? The isochronous streams did not all start at the same time. First one isoc-OUT stream started, then the second stream, then the third stream, then the fourth stream. After that, the isoc-IN streams started, one by one. The controller worked okay up until the time the isoc-IN streams began. Before that, it transmitted the OUT packets correctly. After the isoc-IN streams started, the controller sometimes transmitted only the four OUT packets (like in the example above), sometimes a mixture of OUT and IN packets, and sometimes only one or two IN packets. The behavior was very erratic. Alan Stern -- 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
Re: Errata for Freescale root-hub TT?
On Tue, 24 Mar 2015, Peter Chen wrote: On Mon, Mar 23, 2015 at 10:11:04AM -0400, Alan Stern wrote: On Mon, 23 Mar 2015, Peter Chen wrote: For going on debugging this problem, we need I will have the hardware only for one more day, so I may not be able to get all the information you want. - Your bus analyzer file, I think there should be no enough IN/OUT tokens within one frame, does the remaining time to frame boundaries is enough? Here's an example: There are four OUT transfers near the start of the frame, and they take about 300 us. The remaining 700 us in the frame are completely idle, even though they should contain four IN transfers. How do you know the frame has filled already at that time? The software makes sure it fills frame in time before next time frame? I'm not sure I understand the question. The USB analyzer log showed something like this (this is a rough approximation because I didn't keep the original analyzer output file): Timestamp Transaction s.mmm uuu --- 0.000 000 SOF 0.000 030 Isoc OUT 0.000 091 Isoc OUT 0.000 162 Isoc OUT 0.000 224 Isoc OUT 0.001 000 SOF In this example, there are 4 OUT transfers taking about 290 us and then nothing else for the rest of the frame. I also know, from looking at the periodic file in the EHCI debugfs directory, that each frame was linked to 8 siTDs: siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 Alan Stern -- 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
Re: Errata for Freescale root-hub TT?
On Tue, Mar 24, 2015 at 10:15:38AM -0400, Alan Stern wrote: On Tue, 24 Mar 2015, Peter Chen wrote: On Mon, Mar 23, 2015 at 10:11:04AM -0400, Alan Stern wrote: On Mon, 23 Mar 2015, Peter Chen wrote: For going on debugging this problem, we need I will have the hardware only for one more day, so I may not be able to get all the information you want. - Your bus analyzer file, I think there should be no enough IN/OUT tokens within one frame, does the remaining time to frame boundaries is enough? Here's an example: There are four OUT transfers near the start of the frame, and they take about 300 us. The remaining 700 us in the frame are completely idle, even though they should contain four IN transfers. How do you know the frame has filled already at that time? The software makes sure it fills frame in time before next time frame? I'm not sure I understand the question. The USB analyzer log showed something like this (this is a rough approximation because I didn't keep the original analyzer output file): Timestamp Transaction s.mmm uuu --- 0.000 000 SOF 0.000 030 Isoc OUT 0.000 091 Isoc OUT 0.000 162 Isoc OUT 0.000 224 Isoc OUT 0.001 000 SOF In this example, there are 4 OUT transfers taking about 290 us and then nothing else for the rest of the frame. I also know, from looking at the periodic file in the EHCI debugfs directory, that each frame was linked to 8 siTDs: siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 I did not debug too many for Host ISOC, I just want to make sure the siTD is ready before the controller read it? Does it fail at the beginning or running several cycles? -- Best Regards, Peter Chen -- 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
Re: Errata for Freescale root-hub TT?
On Mon, Mar 23, 2015 at 10:11:04AM -0400, Alan Stern wrote: On Mon, 23 Mar 2015, Peter Chen wrote: For going on debugging this problem, we need I will have the hardware only for one more day, so I may not be able to get all the information you want. - Your bus analyzer file, I think there should be no enough IN/OUT tokens within one frame, does the remaining time to frame boundaries is enough? Here's an example: There are four OUT transfers near the start of the frame, and they take about 300 us. The remaining 700 us in the frame are completely idle, even though they should contain four IN transfers. How do you know the frame has filled already at that time? The software makes sure it fills frame in time before next time frame? -- Best Regards, Peter Chen -- 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
Re: Errata for Freescale root-hub TT?
On Mon, 23 Mar 2015, Peter Chen wrote: For going on debugging this problem, we need I will have the hardware only for one more day, so I may not be able to get all the information you want. - Your bus analyzer file, I think there should be no enough IN/OUT tokens within one frame, does the remaining time to frame boundaries is enough? Here's an example: There are four OUT transfers near the start of the frame, and they take about 300 us. The remaining 700 us in the frame are completely idle, even though they should contain four IN transfers. - Environment to reproduce, if you have similar libusb and gadgetfs apps, I have enough boards to try it. If no env, we may need data structure for siTDs. My environment was a full-speed (USB-1.1) hub and with four USB audio devices plugged in. You can probably get the similar effect with four audio gadgets plugged into a full-speed hub. The bus traffic was generated by running one aplay process and one arecord process for each of the audio devices, concurrently. - Since it is ok for high speed hub, it should not be buffer overrun/underrun problem, but have a try: 1. Disable all audio or video (framebuffer) There was no video or audio. Only USB, ethernet, and a serial console. 2. Enable Stream mode, $BASE+0x1A8, bit 4 = 0 3. Try to optimize the burst $BASE+0x90, bit0 - bit 2 = 0x0 $BASE+0x160 bit0 - bit 15 = 0x1010 $BASE+0x800 bit 1 = 1 (controller 1) $BASE+0x804 bit 1 = 1 (controller 2) The above have described at my chipidea tuning patch set: http://www.spinics.net/lists/linux-usb/msg122996.html I'll do this if I have time. But remember, we are not talking about high bandwidth usage. This is all audio, not video. The total bandwith should have been under 1 MB/s (i.e., eight isochronous packets per frame, each with a payload of 64 bytes -- that's 512000 bytes per second plus some overhead). Alan Stern -- 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
Re: Errata for Freescale root-hub TT?
On Sat, Mar 21, 2015 at 10:12:46AM -0400, Alan Stern wrote: On Sat, 21 Mar 2015, Peter Chen wrote: On Fri, Mar 20, 2015 at 10:16:49AM -0400, Alan Stern wrote: Peter: Are there any known errata for the root-hub Transaction Translator in the Freescale host controllers? When debugging some problems in an i.MX51 system, I found that the host controller would never issue more than 4 full-speed isochronous packets in any frame, no matter how many siTDs were linked into the EHCI schedule. Sometimes it would issue only 1 or 2 packets, even though eight were in the schedule! The behavior was very erratic. The controller seemed to work okay when the full-speed devices were behind a high-speed hub. The problems came up only when the host controller was connected to a full-speed hub. Alan Stern Hi Alan, When look at below imx51 errata, it does not describe this issue, I will talk with IC guys about it next Monday. http://cache.freescale.com/files/dsp/doc/errata/IMX51CE.pdf Okay, thanks. Here are some more details: After talking with IC engineers, there is no reported problem like this. In my test, the i.MX51 was connected to a 4-port USB-1.1 hub. Each port had an audio device attached. My test involved transmitting audio data in and out from all four devices at the same time. The audio was 16-bit mono at 32 KHz, so the isochronous bandwidth requirement was 64 bytes per frame for each of the eight endpoints (which is well within the capability of full-speed USB). The siTDs were linked to the frame list with all the OUT transfers before any of the IN transfers in each frame. On my bus analyzer I sometimes saw 4 OUT transfers and no IN transfers, sometimes a mixture, sometimes only 1 or 2 IN transfers. I never saw more than 4 transfers in any frame, even though there should have been 8. For going on debugging this problem, we need - Your bus analyzer file, I think there should be no enough IN/OUT tokens within one frame, does the remaining time to frame boundaries is enough? - Environment to reproduce, if you have similar libusb and gadgetfs apps, I have enough boards to try it. If no env, we may need data structure for siTDs. - Since it is ok for high speed hub, it should not be buffer overrun/underrun problem, but have a try: 1. Disable all audio or video (framebuffer) 2. Enable Stream mode, $BASE+0x1A8, bit 4 = 0 3. Try to optimize the burst $BASE+0x90, bit0 - bit 2 = 0x0 $BASE+0x160 bit0 - bit 15 = 0x1010 $BASE+0x800 bit 1 = 1 (controller 1) $BASE+0x804 bit 1 = 1 (controller 2) The above have described at my chipidea tuning patch set: http://www.spinics.net/lists/linux-usb/msg122996.html -- Best Regards, Peter Chen -- 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
Re: Errata for Freescale root-hub TT?
On Sat, 21 Mar 2015, Peter Chen wrote: On Fri, Mar 20, 2015 at 10:16:49AM -0400, Alan Stern wrote: Peter: Are there any known errata for the root-hub Transaction Translator in the Freescale host controllers? When debugging some problems in an i.MX51 system, I found that the host controller would never issue more than 4 full-speed isochronous packets in any frame, no matter how many siTDs were linked into the EHCI schedule. Sometimes it would issue only 1 or 2 packets, even though eight were in the schedule! The behavior was very erratic. The controller seemed to work okay when the full-speed devices were behind a high-speed hub. The problems came up only when the host controller was connected to a full-speed hub. Alan Stern Hi Alan, When look at below imx51 errata, it does not describe this issue, I will talk with IC guys about it next Monday. http://cache.freescale.com/files/dsp/doc/errata/IMX51CE.pdf Okay, thanks. Here are some more details: In my test, the i.MX51 was connected to a 4-port USB-1.1 hub. Each port had an audio device attached. My test involved transmitting audio data in and out from all four devices at the same time. The audio was 16-bit mono at 32 KHz, so the isochronous bandwidth requirement was 64 bytes per frame for each of the eight endpoints (which is well within the capability of full-speed USB). The siTDs were linked to the frame list with all the OUT transfers before any of the IN transfers in each frame. On my bus analyzer I sometimes saw 4 OUT transfers and no IN transfers, sometimes a mixture, sometimes only 1 or 2 IN transfers. I never saw more than 4 transfers in any frame, even though there should have been 8. Alan Stern -- 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
Re: Errata for Freescale root-hub TT?
On Fri, Mar 20, 2015 at 10:16:49AM -0400, Alan Stern wrote: Peter: Are there any known errata for the root-hub Transaction Translator in the Freescale host controllers? When debugging some problems in an i.MX51 system, I found that the host controller would never issue more than 4 full-speed isochronous packets in any frame, no matter how many siTDs were linked into the EHCI schedule. Sometimes it would issue only 1 or 2 packets, even though eight were in the schedule! The behavior was very erratic. The controller seemed to work okay when the full-speed devices were behind a high-speed hub. The problems came up only when the host controller was connected to a full-speed hub. Alan Stern Hi Alan, When look at below imx51 errata, it does not describe this issue, I will talk with IC guys about it next Monday. http://cache.freescale.com/files/dsp/doc/errata/IMX51CE.pdf -- Best Regards, Peter Chen -- 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
