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. 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
