On Thu, Sep 16, 2010 at 8:32 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote:
Monty Montgomery wrote:
When I offered a fixed version, there was
relatively little interest in
accepting it (it needed a shakedown and debugging period; big change).
Could you point me to the last version of this patch?
Sure. I think the latest monolithic version of the patch is:
http://web.mit.edu/xiphmont/Public/ehci-sched-2.6.17-20060809.patch
I give it zero chance of working on a modern 2.6 kernel.
[The problem was that upstream would not accept the patch as the EHCI
scheduler rewrite it was... they wanted individual 'funcitonal
changes' so I had to replace the driver a tiny piece at a time... it
was about 50 seperate patches if I remember correctly. And every time
someone submitted a small conflicting change, they dropped my patch
set and told me to regenerate it from scratch. After three or four
rounds of this I gave up.]
This new driver *did* have bugs, and there were good reasons it could
not have gone mainline as is; regardless I ran it for years. It also
doesn't solve problems like momentary starvation causing the higher
level Linux USB stack to revoke your bandwidth allocation, which
there's no guarantee you can get back. This is a fundamental aspect of
the (weird) way the Linux USB stack is designed. It makes low-latency
nearly impossible, as any time the USB stack pulls the last submission
off the queue, it takes it as an implicit request to shut the device
down. You must have URBs in flight at all times to keep running, so
that doubles [minimum] the necessary playback latency on Linux, which
is already high.
Monty