> 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?
Neither ... > 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? Submit one URB with a 64 byte buffer, and modify the contents of that buffer in the completion routine so that it includes only the next 36 bytes. Today there's a problem: you can't change the urb->transfer_length so that only 36 bytes will go. Setting the other bytes to some fixed state (zeroed?) would likely be a good idea; I'm told that for some of the LEGO stuff that does the job. The real solution is that we need an API to change the interrupt transfer length. That'll also be needed for Linux device-side support, including "On-the-Go" USB (a USB 2.0 followon for peer-to-peer USB), for INTR-IN (device-to-host) transfers. Workaround for today: unlink the INTR-OUT transfer just before that last short transfer. Submit a new INTR-OUT transfer for the 36 bytes, and unlink it immediately after it completes. > I still don't see why the packet is being retransmitted > though. If the device driver's completion routine left the original data in the transfer buffer, rather than updating it, that would be the result. > 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. No, the transfer was set to be 64 bytes the first time and that never changed. > 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. I posted the only currently portable solution in my first post on this thread. Johannes just posted a patch to make sure "uhci" can unlink in completion. - Dave > > 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. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
