2009/8/25 Julie Zhu <julie.zhu@xxxxxxxxxx>: > 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 HS root->HS hub -> FS dev fails. -- You stated 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. 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 -- 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
