On Tue, 31 May 2011, Sarah Sharp wrote: > I originally implemented the max interval for FS devices as 10 because > the version of the xHCI 0.96 spec I have says to. Table 56 says that > "The legal range of values is 3 to 10 for Full- or Low-speed Interrupt > endpoints (1 to 256 ms.)" I think maybe that got changed in an errata > to the 0.96 spec, but I'm not sure. It sure looks like the sort of thing that would be fixed in an addendum. The "1 - 256" part is clearly wrong in two respects. First, since the bInterval value is a single byte, it can't possibly take on the value 256. Second, the binary exponents corresponding to 1 - 256 are 0 - 8, and converting to microframes by adding 3 yields 3 - 11, not 3 - 10. (This also ignores the fact that for low-speed devices, bInterval is not allowed to be smaller than 10. This would mean the minimum acceptable exponent should be 6 rather than 3. But never mind that...) > The xHCI 1.0 spec says something different in the same table "The legal > range of values is 3 to 11 for Full- or Low-speed Interrupt endpoints (1 > to 256 ms.)" That makes a little more sense, but it's still not right. > So maybe we need to have a different clamping interval based on whether > the host is 0.96 or 1.0 based? You can check xhci->hci_version, and > clamp it to 10 for hosts with xhci->hci_version < 0x100, and clamp it to > 11 otherwise. Why go to the trouble? Always clamp it to 10. The host system software is allowed to poll interrupt endpoints more frequently than the endpoint descriptor calls for. 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
