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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
