Hi, Steve, > >> 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? > Actually we do have a TT, however, when an FS iso device is connected through HS hub, TT is by-passed. The EHCI controller talks to the HS hub (which has a TT in there) directly. > 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/" > It will say "Xilinx-of-ehci" > > > >> >> > >> > > >> > 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. > I am reluctant to say cache coherency is an issue, how come other cases for the same FS iso device, direct connect/through FS hub, all pass fine? And for TT bypass case, we have HS iso transfer through HS hub work just fine too (which has as much as 125us high bandwidth case). For hardware, itd and sitd (for FS iso OUT) are handled exactly the same. The mystery to find out now is why active sitd's are unlinked before hardware sees them. Thanks, Julie. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- 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
