Am Donnerstag, 3. Januar 2008 schrieb Karsten Wiese: > Am Donnerstag, 3. Januar 2008 schrieb David Brownell: > > On Wednesday 02 January 2008, Karsten Wiese wrote: > > > > > > Disagree: with your patches ITDs can still be removed from ehci's > > > hardware schedule, while a frame is active, no? > > > > Which is a perfectly valid thing to do. And a frame is still > > a frame. :) > > > > > > > In scan_periodic()'s case Q_TYPE_ITD: > > > those lines: > > > *q_p = q.itd->itd_next; > > > *hw_p = q.itd->hw_next; > > > IMO should only execute once the frame has elapsed. > > > > And that would be ... why? > > > > Absolutely the strongest statement you can make in this area > > is that some silicon *might* cache that part of a frame's > > schedule but not have any invalidation mechanism. > > > > Now, if it doesn't do that caching, or invalidates sanely, > > then it's obviously safe. > > > > And if it doesn't, and those assumptions are met, then how > > could anything go wrong? > > My snd-usb-us122l driver tries to be too clever. > it resubmits a completed earlier urb when it runs the completion of > a second urb: > In- and Out-urbs are submitted so they complete at the same uFrame. > Of such an In- Out- pair > - The first completing urb isn't submitted from the completion callback. > - The second completing urb's completion callback resubmits both urbs. > Why? Because Out-urb's packet-lengths and nr_of_packets are taken from > in-urb (and its predecessor) and in-urb's nr_of_packets is set to > out-urb's. > Your patch "ehci delays recycling ISO DMA descriptors" doesn't help > here. To let it help, the completion callback has to resubmit. > > An idea to make snd-usb-us122l work with your patches would depend on a > "complete iso urbs sharing equal start- and stop-uFrames in the sequence > they were submitted in." ehci patch. > Something along s/itd_next/itd_prev/ and "make ehci->pshadow[frame] > point at the frame's hardware-schedule's last (S)ITD or QH". Reversing > the shadow linkage. Sensible approach?
Reversing the shadow linkage propably isn't. Does "Add ehci->pshadow_last_itd[] to contain a pointer to a frame's latest linked (S)ITD and link (S)ITDs there." sound better? - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html