On Thu, Oct 08, 2009 at 10:28:53AM -0400, Alan Stern wrote: > On Wed, 7 Oct 2009, Sarah Sharp wrote: > > > If I were to want the EHCI host controller to not schedule new iTDs > > within the IST, would this patch do that? It would have to be applied > > on top of my last patch for the isoc boundary checking bug fix. > > It sort of would. IMO a better approach would be to leave "now" as it > is and introduce a new variable > > next = (now + ehci->i_thresh) % mod; > > However there are a few problems with your approach. First of all, the > initial setting of ehci->i_thresh in ehci_init() is wrong; if the > controller uses frame caching then the value should be 9 rather than 8 > (i.e., a full frame plus one uframe uncertainty). > > Secondly, your patch would affect the way new streams are scheduled; > they would be delayed unnecessarily. SCHEDULE_SLOP is already bigger > than the threshold. > > Finally, I don't understand why you want to avoid scheduling new iTDs > during the scheduling threshold. Changing this could break > applications that require isochronous transfers to occur at a fixed > reliable rate. It turns out there is a bug in a new Intel platform that is triggered when the EHCI driver adds a new iTD within the isochronous scheduling threshold. It's a rather nasty one, so this work around is necessary. I've tried to address your three concerns in the following patches; let me know if I've missed any. I also found another bug in the boundary checking interval math. The patch for that will need to be applied before the IST scheduling patch. Sarah -- 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
