/Documentation/usb/URB.txt
https://bitbucket.org/evzijst/gittest · Plain Text · 252 lines · 177 code · 75 blank · 0 comment · 0 complexity · ab01e91e79046e623c9bdaec6c0088d8 MD5 · raw file
- Revised: 2000-Dec-05.
- Again: 2002-Jul-06
- NOTE:
- The USB subsystem now has a substantial section in "The Linux Kernel API"
- guide (in Documentation/DocBook), generated from the current source
- code. This particular documentation file isn't particularly current or
- complete; don't rely on it except for a quick overview.
- 1.1. Basic concept or 'What is an URB?'
- The basic idea of the new driver is message passing, the message itself is
- called USB Request Block, or URB for short.
- - An URB consists of all relevant information to execute any USB transaction
- and deliver the data and status back.
- - Execution of an URB is inherently an asynchronous operation, i.e. the
- usb_submit_urb(urb) call returns immediately after it has successfully queued
- the requested action.
- - Transfers for one URB can be canceled with usb_unlink_urb(urb) at any time.
- - Each URB has a completion handler, which is called after the action
- has been successfully completed or canceled. The URB also contains a
- context-pointer for passing information to the completion handler.
- - Each endpoint for a device logically supports a queue of requests.
- You can fill that queue, so that the USB hardware can still transfer
- data to an endpoint while your driver handles completion of another.
- This maximizes use of USB bandwidth, and supports seamless streaming
- of data to (or from) devices when using periodic transfer modes.
- 1.2. The URB structure
- Some of the fields in an URB are:
- struct urb
- {
- // (IN) device and pipe specify the endpoint queue
- struct usb_device *dev; // pointer to associated USB device
- unsigned int pipe; // endpoint information
- unsigned int transfer_flags; // ISO_ASAP, SHORT_NOT_OK, etc.
- // (IN) all urbs need completion routines
- void *context; // context for completion routine
- void (*complete)(struct urb *); // pointer to completion routine
- // (OUT) status after each completion
- int status; // returned status
- // (IN) buffer used for data transfers
- void *transfer_buffer; // associated data buffer
- int transfer_buffer_length; // data buffer length
- int number_of_packets; // size of iso_frame_desc
- // (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
- int actual_length; // actual data buffer length
- // (IN) setup stage for CTRL (pass a struct usb_ctrlrequest)
- unsigned char* setup_packet; // setup packet (control only)
- // Only for PERIODIC transfers (ISO, INTERRUPT)
- // (IN/OUT) start_frame is set unless ISO_ASAP isn't set
- int start_frame; // start frame
- int interval; // polling interval
- // ISO only: packets are only "best effort"; each can have errors
- int error_count; // number of errors
- struct usb_iso_packet_descriptor iso_frame_desc[0];
- };
- Your driver must create the "pipe" value using values from the appropriate
- endpoint descriptor in an interface that it's claimed.
- 1.3. How to get an URB?
- URBs are allocated with the following call
- struct urb *usb_alloc_urb(int isoframes, int mem_flags)
- Return value is a pointer to the allocated URB, 0 if allocation failed.
- The parameter isoframes specifies the number of isochronous transfer frames
- you want to schedule. For CTRL/BULK/INT, use 0. The mem_flags parameter
- holds standard memory allocation flags, letting you control (among other
- things) whether the underlying code may block or not.
- To free an URB, use
- void usb_free_urb(struct urb *urb)
- You may not free an urb that you've submitted, but which hasn't yet been
- returned to you in a completion callback.
- 1.4. What has to be filled in?
- Depending on the type of transaction, there are some inline functions
- defined in <linux/usb.h> to simplify the initialization, such as
- fill_control_urb() and fill_bulk_urb(). In general, they need the usb
- device pointer, the pipe (usual format from usb.h), the transfer buffer,
- the desired transfer length, the completion handler, and its context.
- Take a look at the some existing drivers to see how they're used.
- Flags:
- For ISO there are two startup behaviors: Specified start_frame or ASAP.
- For ASAP set URB_ISO_ASAP in transfer_flags.
- If short packets should NOT be tolerated, set URB_SHORT_NOT_OK in
- transfer_flags.
- 1.5. How to submit an URB?
- Just call
- int usb_submit_urb(struct urb *urb, int mem_flags)
- The mem_flags parameter, such as SLAB_ATOMIC, controls memory allocation,
- such as whether the lower levels may block when memory is tight.
- It immediately returns, either with status 0 (request queued) or some
- error code, usually caused by the following:
- - Out of memory (-ENOMEM)
- - Unplugged device (-ENODEV)
- - Stalled endpoint (-EPIPE)
- - Too many queued ISO transfers (-EAGAIN)
- - Too many requested ISO frames (-EFBIG)
- - Invalid INT interval (-EINVAL)
- - More than one packet for INT (-EINVAL)
- After submission, urb->status is -EINPROGRESS; however, you should never
- look at that value except in your completion callback.
- For isochronous endpoints, your completion handlers should (re)submit
- URBs to the same endpoint with the ISO_ASAP flag, using multi-buffering,
- to get seamless ISO streaming.
- 1.6. How to cancel an already running URB?
- For an URB which you've submitted, but which hasn't been returned to
- your driver by the host controller, call
- int usb_unlink_urb(struct urb *urb)
- It removes the urb from the internal list and frees all allocated
- HW descriptors. The status is changed to reflect unlinking. After
- usb_unlink_urb() returns with that status code, you can free the URB
- with usb_free_urb().
- There is also an asynchronous unlink mode. To use this, set the
- the URB_ASYNC_UNLINK flag in urb->transfer flags before calling
- usb_unlink_urb(). When using async unlinking, the URB will not
- normally be unlinked when usb_unlink_urb() returns. Instead, wait
- for the completion handler to be called.
- 1.7. What about the completion handler?
- The handler is of the following type:
- typedef void (*usb_complete_t)(struct urb *);
- i.e. it gets just the URB that caused the completion call.
- In the completion handler, you should have a look at urb->status to
- detect any USB errors. Since the context parameter is included in the URB,
- you can pass information to the completion handler.
- Note that even when an error (or unlink) is reported, data may have been
- transferred. That's because USB transfers are packetized; it might take
- sixteen packets to transfer your 1KByte buffer, and ten of them might
- have transferred succesfully before the completion is called.
- NOTE: ***** WARNING *****
- Don't use urb->dev field in your completion handler; it's cleared
- as part of giving urbs back to drivers. (Addressing an issue with
- ownership of periodic URBs, which was otherwise ambiguous.) Instead,
- use urb->context to hold all the data your driver needs.
- NOTE: ***** WARNING *****
- Also, NEVER SLEEP IN A COMPLETION HANDLER. These are normally called
- during hardware interrupt processing. If you can, defer substantial
- work to a tasklet (bottom half) to keep system latencies low. You'll
- probably need to use spinlocks to protect data structures you manipulate
- in completion handlers.
- 1.8. How to do isochronous (ISO) transfers?
- For ISO transfers you have to fill a usb_iso_packet_descriptor structure,
- allocated at the end of the URB by usb_alloc_urb(n,mem_flags), for each
- packet you want to schedule. You also have to set urb->interval to say
- how often to make transfers; it's often one per frame (which is once
- every microframe for highspeed devices). The actual interval used will
- be a power of two that's no bigger than what you specify.
- The usb_submit_urb() call modifies urb->interval to the implemented interval
- value that is less than or equal to the requested interval value. If
- ISO_ASAP scheduling is used, urb->start_frame is also updated.
- For each entry you have to specify the data offset for this frame (base is
- transfer_buffer), and the length you want to write/expect to read.
- After completion, actual_length contains the actual transferred length and
- status contains the resulting status for the ISO transfer for this frame.
- It is allowed to specify a varying length from frame to frame (e.g. for
- audio synchronisation/adaptive transfer rates). You can also use the length
- 0 to omit one or more frames (striping).
- For scheduling you can choose your own start frame or ISO_ASAP. As explained
- earlier, if you always keep at least one URB queued and your completion
- keeps (re)submitting a later URB, you'll get smooth ISO streaming (if usb
- bandwidth utilization allows).
- If you specify your own start frame, make sure it's several frames in advance
- of the current frame. You might want this model if you're synchronizing
- ISO data with some other event stream.
- 1.9. How to start interrupt (INT) transfers?
- Interrupt transfers, like isochronous transfers, are periodic, and happen
- in intervals that are powers of two (1, 2, 4 etc) units. Units are frames
- for full and low speed devices, and microframes for high speed ones.
- Currently, after you submit one interrupt URB, that urb is owned by the
- host controller driver until you cancel it with usb_unlink_urb(). You
- may unlink interrupt urbs in their completion handlers, if you need to.
- After a transfer completion is called, the URB is automagically resubmitted.
- THIS BEHAVIOR IS EXPECTED TO BE REMOVED!!
- Interrupt transfers may only send (or receive) the "maxpacket" value for
- the given interrupt endpoint; if you need more data, you will need to
- copy that data out of (or into) another buffer. Similarly, you can't
- queue interrupt transfers.
- THESE RESTRICTIONS ARE EXPECTED TO BE REMOVED!!
- Note that this automagic resubmission model does make it awkward to use
- interrupt OUT transfers. The portable solution involves unlinking those
- OUT urbs after the data is transferred, and perhaps submitting a final
- URB for a short packet.
- The usb_submit_urb() call modifies urb->interval to the implemented interval
- value that is less than or equal to the requested interval value.