Hi, Julie, 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? > 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. 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. 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
