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

Reply via email to