On Wednesday 03 May 2006 1:03 pm, Christopher Montgomery wrote:
> I've done some of the requisite homework myself for getting full speed
> audio devices to work properly through ehci and TTs on a 2.0 hub
> (playback *and* capture). At this point it all works although my
> changes are not production-ready.
Good; the ISO stuff has always been a bit iffy, in that some things
have worked and others haven't. Capture has been iffiest.
> I have three specific questions for now.
>
> The primary reason DIR_IN iso modes didn't work comes down to schedule
> mask bugs. However, there's also an explicit test to see that IN
> csplits are not wrapped into a following frame; if they would have to
> be, the schedule attempt is rejected. I see no reason for this
> restriction anywhere in the spec docs (and indeed, ISO IN can't work
> properly unless the restriction is removed; the 'start capture' OUT
> plus the 'get capture data' IN don't fit in one frame for > stereo
> capture). AFAICT, the restriction was there to hide/prevent a c_mask
> overflow.
And the question is .. why? Probably because what you see is the
very first implementation for the split iso support, and the goal
was to have something work at all (for the test devices at hand,
mostly USB speakers) and defer the more complex scheduling issues
until later when they were better understood.
So that restriction is a simplification. And you're wrong about
the "can't work"; the "start split" plus N* "complete split" messages
can certainly fit into a single frame in cases like SSPLIT in uframe 0
and needing only a couple CSPLITs.
> Second question: The official USB 2.0 spec shows no examples that do
> this, but the Intel echi spec examples all pipeline transfers heavily
> by overlapping the final c-split of the current transfer and the
> initial s-split of the following transfer into the same uframe. I've
> implemented the same strategy myself and it works as the Intel docs
> suggest... but is there a reason the preexisting scheduler does not do
> this? Is there a contention issue I'm not seing (eg, is this only
> working because my final csplit and overlapping intiial ssplit are
> small enough to fit in one uframe, but it's possible that wouldn't
> work in the future? Or is the final c-split always padding anyway?)
That sort of pipelining was always on the "to do" list, but the
initial scheduling for periodic split transfers (iso and interrupt)
was simplistic, in order to get something working.
I have some patches from Dan Streetman that I need to go back and
re-review. As you implied, the USB 2.0 spec and the EHCI spec are
not quite in lockstep ... not that there's necessarily any kind of
conflic, but split iso scheduling is not at all simple, and time
has been lacking. (I'll forward his patches to you, with some
comments about one issue I need to make time to investigate.)
> Third: In ehci-sched.c:check_intr_sched():
>
> if (qh->c_usecs && uframe >= 6){ /* FSTN territory? */
> goto done;
> }
>
> Huh? Reject any csplit that falls into uframe 6 or 7 for an intr?
> That doesn't make any sense (yes, a s-split can't fall into uframe 6,
> but that's something different that, ironically, the code doesn't
> check for).
At this point I don't recall what was going on there. Likely it's
the same sort of "take some shortcuts to get something working"
thing I mentioned already. That might even predate the existence
of the interrupt schedule tree.
- Dave
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
