On Thu, Feb 14, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > > 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?
Yes, it is a bug. I'll submit a patch for uhci.c atleast to fix it. > 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. Good point, that would add some complications that aren't trivial to workaround. JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
