This is starting to make more sense now. I've been playing with the LEGO driver and that's why I started asking these types of questions several days ago.
When the original urb is submitted, are you supposed to put 64 bytes in the urb, and then 36 bytes in the next urb (you as in the driver writer), or is this supposed to happen transparently inside the urb resubmission code? ie do I submit an URB with 100 bytes of data, or do I submit an URB with 64 bytes and then deal with the rest of the buffer in the completion code? I still don't see why the packet is being retransmitted though. I can see that you might get 64 bytes, then 36 real bytes and 28 bytes of rubbish. Surely the hardware-specific code modifies the urb based on the response from the controller so that, when it's resumbitted, there is no data to write. If not, I don't see how you ever manage to stop interrupt writes going round and round since '0' only works for UHCI and you can't unlink in the completion handler. Roland On Tue, 19 February 2002, David Brownell wrote: > > "> " = 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 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
