> > The portable way to get a one-shot interrupt transfer should be
> > to submit the transfer as usual (real period) then unlink it in the
> > completion handler for that transfer.
>
> That won't work with uhci.o or usb-uhci.o. You can't unlink a
> resubmitting interrupt urb in the completion handler.
And that's exactly why I said "should be ..." :)
Current EHCI and OHCI drivers do handle that correctly.
Is there some reason not to treat that as a UHCI bug?
Interrupt transfers aren't wholly portable between drivers,
except for the HID-IN style where fixed size (but maybe
short-read enabled) INTR transfers fire until some thread
unlinks the URB. Bleech.
> Maybe we should drop the auto resubmitting for 2.5 and require drivers
> to use ->next?
I'd rather keep that current model, just fix the glitches.
Changing the model would forgo the whole reason that
USB has interrupt transfers in the first place! I can think
of two main glitches just now:
- INTR-OUT transfer sizes should be changeable.
The IN transfer sizes are controlled by sender (device),
but the OUT ones (sent by host) are fixed size.
- There's that unlink-in-completion issue for UHCI.
Forcing interrupt transfer bandwidth to be rescheduled
after every transfer can mean dropping the bandwidth
and latency guarantee. It's also a needless waste of
CPU cycles (especially for split transactions) in the typical
case, and would increase interrupt latencies.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
