Hi David,
I thought my post got lost; I never saw it appear and hadn't seen
replies. Scratch that, I was *hoping* it got lost, as more code
research later showed each question was at least partially
nonsensical.
At this point, the actual ISO transfer machinery all looks perfectly
solid. The problem is entirely the scheduler. It's not that the
scheduler is buggy, it's that it burns burns burns bandwidth as if
there's an infinite number of uFrames to stick requests into. Once
it's faced with, eg, full duplex audio using two endpoints each with a
data interval of one, it can't usually fit both requests into the
Hframe cmask/ssmask despite the fact they'd fit comfortably in half of
one full-speed frame.
But this we know.
> The primary reason DIR_IN iso modes didn't work comes down to schedule
> mask bugs.
And the question is .. why?
Actually, I retract this. The schedule mask code is not buggy, it's
just, as you say, an initial design.
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.)
I've also been reviewing the schedulers for other OSes to help with
spec understanding. They primarily schedule by counting microseconds
used in uFrames and full speed frames. SSPLITS and CSPLITS overlap
freely (so long as each endpoint only sees one per frame and the other
limitation restrictions are obeyed).
> 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.
[After more meditation] the code is for avoiding the need to
potentially schedule an FSTN, but I'm still not quite sure that just
checking uFrame number against '6' was sufficient... I'd have though
'4' was correct, or you'd have to look at the highest bit in the mask,
or count microseconds....
Popping back up in the conversation, I have a device that will never
fit all it needs to do in one Hframe using the bitmask scheduling
method. It needs to 'overlap' too tightly with two interval 1
endpoints and two interval 32 endpoints all in the periodic schedule.
The timing fits (obviously, it works fine under UHCI), but not if you
can't overlap transactions.
So, send me that patch and I'll read up on the spec sections detailing
budgeting timing. I need this bugger to work, or I need to buy a
MacMini ;-)
Monty
-------------------------------------------------------
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&kid0709&bid&3057&dat1642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
