On Tue, 25 Aug 2009, Julie Zhu 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. To make this clear: You've got 2 isochronous URBs, each URB contains 50 packets (i.e., urb->number_of_packets is 50), and each packet transfers 1 byte. Is that right? > 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. What do you mean by "constantly"? scan_periodic should be called only when an interrupt occurs, which should be only when one of those 2 URBs completes. Therefore scan_periodic should be called only twice. > 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. That shouldn't happen. Let's say URB #1 makes its last transfer in uframe N. There should be an interrupt when that uframe ends, and at that time scan_periodic should run and should update ehci->next_uframe to N+1. Then URB #2 should be submitted, and it should start approximately in uframe N+32 (4 ms = 32 uframes later). Therefore the next sitd should not be linked into uframe N+1. > I wonder whether the test setting is correct? What test setting? Alan Stern -- 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
