On Wednesday 02 January 2008, Karsten Wiese wrote: > Am Mittwoch, 2. Januar 2008 schrieb David Brownell: > > On Tuesday 01 January 2008, Karsten Wiese wrote: > > > The finishing urb doesn't recycle its last ITD, instead the starting urb > > > takes care of that. > > > > Also a different issue. The patch I posted to defer the recycling > > on URB completion paths suffices, > > Not I think. I don't mean its wrong, there's 1 thing missing though, > see below. > > > given the assumptions that only > > completions will add to the schedule and that drivers aren't doing > > silly stuff like more than two URBs per frame (for a given endpoint).
... note that the first assumption reflects standard practice, as does the second one. The second one is also testable, since it's equivalent to "no URB uses less than one frame". > > > IIRC it was also necessary to never change a running (USB1.1) frame's > > > hardware schedule... > > > > A frame is a frame is a frame; USB 2.0 didn't change that! > > > > Again, not an issue given those assumptions. > > 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? > > > I've once succesfully tested this scheme. > > > It made ITD (de)scheduling a bit more complex. > > > Good is it needs less memory and DMA bandwith. > > > > It's not clear to me what you mean by these comments. > > I meant: > "It worked fine here some month ago streaming iso urbs > containing odd nr_of_packets" But from what I can tell, you never tested patches that changed only one behavior at a time ... so "it" was more than that. > + some course cost/benefit analysis. > - 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
