>> > >> Interesting. I have heard that the ARC/TD/CHIPIDEA core has two >> different types of TTs. One is just putting a real hub on board, the >> other is to handle things as a HS device, but to downshift the speed >> of the transfers. You can tell the difference by what transfer you are >> using ITD or SITD for the FS transfer. If SITD then you must be using >> a "hub" internally and it should fail just like an external HS hub >> --if it is a kernel bug. >> >> Have you customized the ehci* driver for your ehci interface or is it >> already part of the kernel? >> > > We are using the existing kernel code. Our USB host controller is EHCI > with built-in Transaction Translator. > This is fascinating. How would ehci know how to run a FS isoc device? This comes back to my theory that the ARC core does not have a TT, it just downshifts the speed of the transfer for a direct connect FS device. Is there some standard ehci option for handling FS devices that I am not aware of? Could you please post lsusb -t and a cat /proc/bus/usb/devices You may need to mount usbfs with : "sudo mount -t usbfs u /proc/bus/usb/" >> >> >> > >> > HS root -> HS hub -> FS device (hub or not does not matter) fails on > not >> all software scheduled transfers occur on the bus. >> > Touching the sitd hw_buf[0] will make the tests pass, but I am not > sure >> whether it is the caching issue on PowerPC or it is >> > the timing issue in our system. >> >> I will assume that when you say touching you mean you put an >> instruction in your driver somewhere to load that register? If that is >> the case you may need a memory barrier (mb()) or EIEIO instruction >> somewhere to keep the caches straight. >> > > Kernel code already has mb() in sitd_link(). I do not suspect cache is > the issue, because without HS hub, tests run just fine. > > >> Showing the driver source code (or pointing to it if already in the >> kernel), and bringing in a powerpc maintainer mailing list might help >> find your problem. > > All code are in the kernel. Thank you for your suggestions, I do not > know what question to ask at this moment. > > Hardware trace shows that only part of the submitted sitd's are in there > when hardware going through the periodic frame list (and they all go > onto the bus), however, software saw all 100 submitted sitd's being > completed, and part of the completed sitd's have their active bit set. > This only happens when an HS hub is between the host controller and the > FS iso device (and scan_periodic is called all the time). What makes it > difficult is that printing in the code changed all the timing, and seems > not telling the situation I am debugging for. I do suspect that > scan_periodic() is updating counters too fast (without proof yet). Any > suggestions on how to debug this are appreciated. > I need more info. What is the hardware trace? The fact that software sees some things as being there and your "hardware trace" does not suggests to me a cache coherency issue. Regards, Steve -- 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
