"> " = Vladimir Dergachev
"> > " = Vojtech Pavlik
"> > > " = David Brownell
> > > By the host controller driver. It's a "periodic" transfer,
> > > which _by design_ is going to be happening over and
> > > over and over again.
> >
> > Which is a problem. All uses of interrupt out I have met don't need to
> > be periodic - they're used for example in HID if the device has an
> > output interrupt endpoint for sending output reports, and for I-Force
> > devices to send outgoing data.
So, the INTR-OUT problem. For example, maxpacket size is 64,
period is maybe 8, but the driver needs to send 100 bytes. That
adds up to 64 bytes in one frame, then 36 bytes after a delay of
8 frames ... then wanting to stop/unlink. This is one problem that
the LEGO folk have been seeing.
Today, the model involves the completion for that first frame
copying the 36 bytes into the buffer, but getting annoyed because
(a) there's no way to change the OUT transfer size. And after the
second transfer, then getting annoyed because (b) unlinking the
URB in the completion handler doesn't work for all HC drivers.
(That is, those were my own reactions when I tried to solve that! :)
> What about usb_resubmit_urb ? The scheme would be as follows:
>
> We usb_submit_urb for an interrupt transfer, the driver allocates the
> bandwidth, sends _one_ packet to the device marks the urb as "done", keeps
> it in a queue and calls completion routine. The completion routine either
> updates the data and calls usb_resubmit_urb to send another packet or
> calls usb_unlink_urb to stop the transfer and deallocate the bandwidth.
What if it does nothing, like today's drivers, expecting that to mean
the URB should continue being submitted? I did end up thinking
that completion callbacks needed to have a new capability, but
I didn't want to change the existing model (it doesn't bother me).
My thought was pretty much to leave today's behavior alone, but
add a new usb_modify_urb() that's allowed to change the transfer
size for INTR-OUT urbs in their completion callbacks. That'd
handle annoyance (a) above. Every host controller driver would
need to change to handle this case, and I don't really like special
cases ... but I'm not sure I see a clean way around that. (And the
bandwidth reservation would have to handle the max transfer size
for the INTR-OUT endpoint, even if the initial URB didn't use it!)
I certainly agree that unlinking the urb in the completion handler
should work portably; that's annoyance (b). That's an issue for
both IN and OUT interrupt transfers.
> This way we both get one-shot interrupt transfers (which is the only thing
> that makes sense on a computer IMO) and preserve the bandwidth allocation
> accross the string of interrupt transfers.
I guess I don't see why one-shot interrupt transfers would be
"the only thing that makes sense". They really seem like the
exceptional case to me. I'd rather design for the typical case
(a sequence of transfers) but allow them to stop in a cleaner
and quicker way than they can portably achieve today.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
