Alan Stern wrote: > ... > The problem is that with some types of hardware, ehci-hcd uses a > scheduling horizon of only 256 ms. It won't accept Isochronous URBs > that go farther than that into the future. However the usbaudio driver > is known to submit URBs for timing synchronization that will overrun > this limit. (The current version of ehci-hcd accepts these URBs even > though it shouldn't; that's the bug.) > > The default scheduling horizon is 1024 ms but ehci-hcd uses the > smaller value if the hardware supports it, in order to reduce the > amount of processing needed when updating the schedule. > > I can see two possible approaches. One is for ehci-hcd always to use > 1024 ms and not worry about the extra processing costs. The other is > to change the drivers that want to schedule URBs too far into the > future. When submitting sync URBs, the usb-audio driver uses the interval from the device's descriptor and its own hardcoded number of URBs. There is no attempt to conform to the HC's scheduling constraints; this needs to be changed since it could result in scheduling errors even now if a device wants to use a large enough interval. Is 256 ms a limit that works with every HC? (I could just limit the usb-audio driver to use at most 4 * 32 ms for sync URBs.) Wouldn't it be better to add an API through which the HC can tell what scheduling constraints it has? (There is also the matter of the _minimum_ scheduling horizont.) Regards, Clemens -- 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
