Re: Handling short transfers
Alan Stern <stern@...
2009-08-02 15:32:36 GMT
On Sat, 1 Aug 2009, David Moore wrote:
> On Fri, 2009-07-31 at 15:34 -0400, Alan Stern wrote:
> > Daniel and David:
> > This kernel patch implements the plan we discussed for handling short
> > bulk transfers. It adds a new URB flag: USBDEVFS_URB_XFER_START.
> I tried this patch, modified libusb accordingly, and it works!
> My test is a particular camera that sends a short packet to indicate
> that the host is not keeping up. I need the remaining URBs in the frame
> to be canceled in order to keep in sync with the frame boundaries.
> With your patch and the libusb modifications, keeping sync seems to be
> completely reliable. With the old method of doing the URB cancelation
> in libusb, I would often lose sync.
> Some more thoughts below...
> > But for bulk-IN URBs that do have this flag bit set, any fault other
> > than an unlink will cause the kernel to immediately cancel all the
> > following URBs for the same endpoint and refuse to accept any new ones.
> > This state of affairs will persist until an URB that also has
> > USBDEVFS_URB_XFER_START is encountered, at which point the behavior
> > reverts to normal. Such an URB would of course mark the beginning of a
> > new transfer.
> For backwards compatibility reasons, I am a little bit concerned about
> the change in semantics of USBDEVFS_URB_SHORT_NOT_OK. The old behavior
> would only cancel one URB (the short packet) automatically. The new
> behavior causes all packets to be canceled. Won't this cause unexpected
> behavior for apps that previously used USBDEVFS_URB_SHORT_NOT_OK?
I doubt there are any such apps. USBDEVFS_URB_SHORT_NOT_OK was added
in April last year, and there isn't any support for it in libusb.
> As a suggestion, maybe the meaning of USBDEVFS_URB_XFER_START could be
> exactly inverted and it could be renamed, perhaps to
> "USBDEVFS_URB_CANCEL_ON_ERROR"? The behavior would then be to cancel
> any URBs that immediately follow an URB with an error, but only up until
> an URB that has URB_CANCEL_ON_ERROR unset.
Or rather, up until an URB that has URB_SHORT_NOT_OK set and
Daniel, do you have any thoughts? I can change the code pretty easily.
> Also, what do you suggest as the best way to test at runtime whether a
> particular kernel has this flag available? With firewire, we have an
> ioctl that gives you a version for the API at run-time to test against.
It's simple: uname(2). If the release value is >= 2.6.32 (or whenever
this feature gets merged) then the new flag is available, otherwise it
> I suppose I could just try to submit an URB with the new flag set and
> see if it fails.
That also works.
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html