On Tue, Aug 25, 2009 at 2:02 PM, Julie Zhu<julie.zhu@xxxxxxxxxx> wrote: > Hello, all, > > 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. 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? 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
