[PATCH] iso pipe support for usbatm

[Roman Kagan]

On Sat, Mar 19, 2005 at 07:28:04PM +0100, matthieu castet wrote:
> Roman Kagan wrote:
> >Anyway it may make more sense to use more urbs in this case, so that
> >some urbs are always submitted.  It's for that reason that I've
> >increased the default number of urbs in my patch.
> >
> Increasing the number of urb won't solve the extra cost of locking 
> unlocking : in order to keep the allocated bandwidth, you need to 
> resumit it as soon as possible. If you look in the driver/usb driver 
> that use iso pipe, you will see that's lot's of them resumit the urb in 
> the complete handler (I know this isn't a good argument).

I don't think locking matters here.  It might be the "slow" path through
tasklet that did, but multiple urbs should probably compensate for that.
OTOH I guess bandwidth allocation is preserved only when the same urb is
submitted, otherwise it's reallocated for each urb.  Dunno if it
matters, though...

> >BTW do you get -EILSEQ often?  Documentation/usb/error-codes.txt reads:
> >
> >(*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
> >hardware problems such as bad devices (including firmware) or cables.
> >
> I think this is specific to via controler (someone told me that there 
> windows driver have some trick for -EILSEQ error)

And are there many of those errors?

> >So this means the buffer size per urb is 1007 * 16 / 53 = 304 ATM cells,
> >which is almost 5 times the default 64 for bulk.  Maybe simply
> >increasing the buffer size in bulk mode will solve the problem of
> >dropped cells?
> It make it worse : I increase the size to 304, and I have lot's of 
> unknown vpi/vci error and my download rate is about 4Ko/s ...

Hmm, I'd expect a change in the number of dropped cells, but this
appears to be corrupted cells.  I wonder if I broke anything...  Can you
please send a log snippet?

> I thinks that's normal because before we detected errors only after 64 
> cells, now we wait 304 cells....

Where do we wait?

Roman.