Hi, Steve, > Try to put your answers after the statement that asked the question or > provoked the statement. Otherwise it gets very difficult to follow the > thread. > > > > > No, we are developing the EHCI USB host controller, which has built-in > Transaction Translator. So, the EHCI controller is > > involved in all the tests. > > > 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. > > > Passing cases are: > > > > HS root -> HS devices > > HS root -> FS devices > > HS root -> FS hub -> HS/FS devices > > HS root -> HS hub -> HS devices > > > >> HS root->HS hub -> FS dev fails. -- You stated > > > > Yes. > > > >> HS root->HS hub -> FS hub -> FS dev works or fails? This is not clear > >> from your emails. I suspect it will fail. If so it is probably the > >> kernel. > >> > > > > 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. 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
