On Tue, 4 May 2010, Clemens Ladisch wrote: > 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. True. > 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.) It's actually worse than that. ehci-hcd uses a safety margin of 20 ms, so the available window is really only 236 ms. (On the bright side, I don't think any HCD has a window smaller than that.) To make matters worse, the window includes everything up to the next unallocated slot -- not just everything up to the last used slot. For example, suppose the period is 64 frames and there are 3 one-packet URBs in the queue, with the first scheduled to run in frame N, the second in N+64, and the third in N+128. At the moment the first URB completes, the queue will still be at least 191 frames long, not 128. This is because the next available slot is N+192 and the current frame is N or N+1. If the completion handler were to resubmit that first URB, it would require a window of length 191 + 64 = 255, which is beyond the limit of 236. Thus, an isoc endpoint with period 64 shouldn't try to use more than 2 URBs. If the period was 128 then the completion handler wouldn't be able to resubmit at all! The situation could be improved a little if URBs were scheduled with the delay first. That is, if scheduling a period-64 URB starting at frame N would cause the actual transfer to occur in frame N+63 instead of frame N, as it does now. > 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.) We certainly need such an API. I believe we need to report three parameters: The maximum scheduling delay (an isoc URB that pushes the window beyond this length won't be accepted); The minimum scheduling delay (an isoc URB starting before this delay won't be accepted, or it might be accepted but some of its packets might not get put on the schedule) -- this can vary depending on the device's speed; The maximum allowed period for interrupt URBs. To make things more complicated, we might want to report the minimum scheduling delay in both frames and microframes, since for high-speed devices it can be a fraction of a frame. Coupled with this is the usb_get_current_frame_number() routine. The values it provides are almost useless without the scheduling parameters, and it also has issues with frames vs. microframes. It isn't used in many places (an ISDN driver and a few sound drivers); maybe we can eliminate it entirely. 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
