Hi, Steve, > > > >> > We found an issue with FS isochronous device that is connected to the > >> > USB host controller through an HS hub. This is on an embedded PowerPC > >> > platform using an FPGA-based USB host controller. This issue exists > for > >> > both FS isochronous IN and OUT transfers behind an HS hub. > >> > > >> > The test setup is that the application submits 50 maxp 1 transfers, > with > >> > polling interval 4ms. The periodic frame list has 256 elements. The > >> > application submits 2 batches of transfers with 50 transfers each. > Other > >> > FS isochronous tests fail too if connected through an HS hub. > >> > > >> > Using direct connection, the test passes fine. However, if connected > >> > through an HS hub, there are less than 100 transfers happen on the > bus. > >> > > >> > What we found is that when connected through an HS hub, the periodic > >> > schedule is enabled, and scan_periodic is called constantly. Our > trace > >> > show that the mark of last scanned frame entry, ehci->next_uframe, > often > >> > is the frame entry that software links a new sitd in, and when next > >> > scan_periodic start, that sitd is considered as out of date and is > >> > unlinked. > >> > > >> > I wonder whether the test setting is correct? > >> > > >> > Thanks, > >> > Julie. > >> > >> You have wandered into a grey area of the usb spec. The usb 1.1 spec > >> (in table 9-10) it explicitly states that bInterval must be equal to 1 > >> for isoc. In usb 2.0 spec section 5.6.4 it explicitly states > >> "Full-/high-speed endpoints must specify a desired period as > >> (2**bInterval-1) x F, where bInterval is in the range one to (and > >> including) 16 and F is 125 μs for high-speed and 1ms for full-speed. > >> This allows full-/high-speed isochronous transfers to have rates > >> slower than one transaction per (micro)frame." and then weasels its > >> way out of the conflict by stating "However, an isochronous endpoint > >> must be prepared to handle poll rates faster than the one specified." > >> > >> Contrary to what a reasonable person might expect, INT transfers and > >> ISOC transfers have different rules in FS for bInterval. > >> > > > > Tests with polling interval 1ms fail the same way. So, I do not think > the polling interval is causing this. > > > >> You are testing untraveled areas in the kernel code, some bugs may > >> lurk. When connected to a root hub I wonder what is happening on the > >> bus then -- when controlled by [uo]hci? (use an analyzer). What > >> happens if you put a FS hub (usb 1.1) on one of the HS hub ports and > >> then connect the device to the FS hub? If you connect your strange > >> device to a usb 1.1 host system (like Windows 98 or an early Linux > >> 2.4), what does it think of your device? > >> > > > > The tests pass if connected through an FS hub. They also pass if > connected through a HS hub to a Linux PC. That is why that I do not think > it is the kernel issue, but some issues in our system. > > > > Thanks, > > Julie. > > > FS root -> FS dev works. -- You stated 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. 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. > Note if direct connect works, then your [uo]hci root driver works. > Ehci is not involved. > > If the device is connected via a HS hub then the EHCI driver invokes > SITD xfers in a new root->hub protocol implemented in usb 2.0. > > Try to be explicit about what works and what doesn't. And how do you > know it works, are you using a USB bus analyzer? Not hanging is not > the same as "working". > > Regards, Steve Hopefully, it is clear about my issue now. We are using bus analyzers. 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
