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
