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