Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   1) .. _usb-urb:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   2) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   3) USB Request Block (URB)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   4) ~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   5) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   6) :Revised: 2000-Dec-05
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   7) :Again:   2002-Jul-06
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   8) :Again:   2005-Sep-19
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   9) :Again:   2017-Mar-29
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  10) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  11) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  12) .. note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  13) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  14)     The USB subsystem now has a substantial section at :ref:`usb-hostside-api`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  15)     section, generated from the current source code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  16)     This particular documentation file isn't complete and may not be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  17)     updated to the last version; don't rely on it except for a quick
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  18)     overview.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  19) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  20) Basic concept or 'What is an URB?'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  21) ==================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  22) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  23) The basic idea of the new driver is message passing, the message itself is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  24) called USB Request Block, or URB for short.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  25) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  26) - An URB consists of all relevant information to execute any USB transaction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  27)   and deliver the data and status back.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  28) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  29) - Execution of an URB is inherently an asynchronous operation, i.e. the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  30)   :c:func:`usb_submit_urb` call returns immediately after it has successfully
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  31)   queued the requested action.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  32) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  33) - Transfers for one URB can be canceled with :c:func:`usb_unlink_urb`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  34)   at any time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  35) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  36) - Each URB has a completion handler, which is called after the action
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  37)   has been successfully completed or canceled. The URB also contains a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  38)   context-pointer for passing information to the completion handler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  39) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  40) - Each endpoint for a device logically supports a queue of requests.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  41)   You can fill that queue, so that the USB hardware can still transfer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  42)   data to an endpoint while your driver handles completion of another.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  43)   This maximizes use of USB bandwidth, and supports seamless streaming
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  44)   of data to (or from) devices when using periodic transfer modes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  45) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  46) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  47) The URB structure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  48) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  49) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  50) Some of the fields in struct urb are::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  51) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  52)   struct urb
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  53)   {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  54)   // (IN) device and pipe specify the endpoint queue
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  55) 	struct usb_device *dev;         // pointer to associated USB device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  56) 	unsigned int pipe;              // endpoint information
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  57) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  58) 	unsigned int transfer_flags;    // URB_ISO_ASAP, URB_SHORT_NOT_OK, etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  59) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  60)   // (IN) all urbs need completion routines
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  61) 	void *context;                  // context for completion routine
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  62) 	usb_complete_t complete;        // pointer to completion routine
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  63) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  64)   // (OUT) status after each completion
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  65) 	int status;                     // returned status
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  66) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  67)   // (IN) buffer used for data transfers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  68) 	void *transfer_buffer;          // associated data buffer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  69) 	u32 transfer_buffer_length;     // data buffer length
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  70) 	int number_of_packets;          // size of iso_frame_desc
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  71) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  72)   // (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  73) 	u32 actual_length;              // actual data buffer length
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  74) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  75)   // (IN) setup stage for CTRL (pass a struct usb_ctrlrequest)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  76) 	unsigned char *setup_packet;    // setup packet (control only)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  77) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  78)   // Only for PERIODIC transfers (ISO, INTERRUPT)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  79)     // (IN/OUT) start_frame is set unless URB_ISO_ASAP isn't set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  80) 	int start_frame;                // start frame
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  81) 	int interval;                   // polling interval
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  82) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  83)     // ISO only: packets are only "best effort"; each can have errors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  84) 	int error_count;                // number of errors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  85) 	struct usb_iso_packet_descriptor iso_frame_desc[0];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  86)   };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  87) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  88) Your driver must create the "pipe" value using values from the appropriate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  89) endpoint descriptor in an interface that it's claimed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  90) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  91) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  92) How to get an URB?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  93) ==================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  94) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  95) URBs are allocated by calling :c:func:`usb_alloc_urb`::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  96) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  97) 	struct urb *usb_alloc_urb(int isoframes, int mem_flags)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  98) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  99) Return value is a pointer to the allocated URB, 0 if allocation failed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) The parameter isoframes specifies the number of isochronous transfer frames
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) you want to schedule. For CTRL/BULK/INT, use 0.  The mem_flags parameter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) holds standard memory allocation flags, letting you control (among other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) things) whether the underlying code may block or not.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) To free an URB, use :c:func:`usb_free_urb`::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) 	void usb_free_urb(struct urb *urb)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) You may free an urb that you've submitted, but which hasn't yet been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) returned to you in a completion callback.  It will automatically be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) deallocated when it is no longer in use.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) What has to be filled in?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) =========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) Depending on the type of transaction, there are some inline functions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) defined in ``linux/usb.h`` to simplify the initialization, such as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) :c:func:`usb_fill_control_urb`, :c:func:`usb_fill_bulk_urb` and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) :c:func:`usb_fill_int_urb`.  In general, they need the usb device pointer,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) the pipe (usual format from usb.h), the transfer buffer, the desired transfer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) length, the completion handler, and its context. Take a look at the some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) existing drivers to see how they're used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) Flags:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) - For ISO there are two startup behaviors: Specified start_frame or ASAP.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) - For ASAP set ``URB_ISO_ASAP`` in transfer_flags.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) If short packets should NOT be tolerated, set ``URB_SHORT_NOT_OK`` in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) transfer_flags.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) How to submit an URB?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) Just call :c:func:`usb_submit_urb`::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) 	int usb_submit_urb(struct urb *urb, int mem_flags)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) The ``mem_flags`` parameter, such as ``GFP_ATOMIC``, controls memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) allocation, such as whether the lower levels may block when memory is tight.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) It immediately returns, either with status 0 (request queued) or some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) error code, usually caused by the following:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) - Out of memory (``-ENOMEM``)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) - Unplugged device (``-ENODEV``)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) - Stalled endpoint (``-EPIPE``)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) - Too many queued ISO transfers (``-EAGAIN``)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) - Too many requested ISO frames (``-EFBIG``)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) - Invalid INT interval (``-EINVAL``)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) - More than one packet for INT (``-EINVAL``)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) After submission, ``urb->status`` is ``-EINPROGRESS``; however, you should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) never look at that value except in your completion callback.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) For isochronous endpoints, your completion handlers should (re)submit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) URBs to the same endpoint with the ``URB_ISO_ASAP`` flag, using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) multi-buffering, to get seamless ISO streaming.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) How to cancel an already running URB?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) =====================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) There are two ways to cancel an URB you've submitted but which hasn't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) been returned to your driver yet.  For an asynchronous cancel, call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) :c:func:`usb_unlink_urb`::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) 	int usb_unlink_urb(struct urb *urb)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) It removes the urb from the internal list and frees all allocated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) HW descriptors. The status is changed to reflect unlinking.  Note
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) that the URB will not normally have finished when :c:func:`usb_unlink_urb`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) returns; you must still wait for the completion handler to be called.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) To cancel an URB synchronously, call :c:func:`usb_kill_urb`::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) 	void usb_kill_urb(struct urb *urb)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) It does everything :c:func:`usb_unlink_urb` does, and in addition it waits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) until after the URB has been returned and the completion handler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) has finished.  It also marks the URB as temporarily unusable, so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) that if the completion handler or anyone else tries to resubmit it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) they will get a ``-EPERM`` error.  Thus you can be sure that when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) :c:func:`usb_kill_urb` returns, the URB is totally idle.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) There is a lifetime issue to consider.  An URB may complete at any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) time, and the completion handler may free the URB.  If this happens
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) while :c:func:`usb_unlink_urb` or :c:func:`usb_kill_urb` is running, it will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) cause a memory-access violation.  The driver is responsible for avoiding this,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) which often means some sort of lock will be needed to prevent the URB
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) from being deallocated while it is still in use.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) On the other hand, since usb_unlink_urb may end up calling the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) completion handler, the handler must not take any lock that is held
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) when usb_unlink_urb is invoked.  The general solution to this problem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) is to increment the URB's reference count while holding the lock, then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) drop the lock and call usb_unlink_urb or usb_kill_urb, and then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) decrement the URB's reference count.  You increment the reference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) count by calling :c:func`usb_get_urb`::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) 	struct urb *usb_get_urb(struct urb *urb)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) (ignore the return value; it is the same as the argument) and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) decrement the reference count by calling :c:func:`usb_free_urb`.  Of course,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) none of this is necessary if there's no danger of the URB being freed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) by the completion handler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) What about the completion handler?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) ==================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) The handler is of the following type::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) 	typedef void (*usb_complete_t)(struct urb *)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) I.e., it gets the URB that caused the completion call. In the completion
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) handler, you should have a look at ``urb->status`` to detect any USB errors.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) Since the context parameter is included in the URB, you can pass
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) information to the completion handler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) Note that even when an error (or unlink) is reported, data may have been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) transferred.  That's because USB transfers are packetized; it might take
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) sixteen packets to transfer your 1KByte buffer, and ten of them might
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) have transferred successfully before the completion was called.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) .. warning::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)    NEVER SLEEP IN A COMPLETION HANDLER.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233)    These are often called in atomic context.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) In the current kernel, completion handlers run with local interrupts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) disabled, but in the future this will be changed, so don't assume that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) local IRQs are always disabled inside completion handlers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) How to do isochronous (ISO) transfers?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) ======================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) Besides the fields present on a bulk transfer, for ISO, you also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) have to set ``urb->interval`` to say how often to make transfers; it's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) often one per frame (which is once every microframe for highspeed devices).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) The actual interval used will be a power of two that's no bigger than what
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) you specify. You can use the :c:func:`usb_fill_int_urb` macro to fill
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) most ISO transfer fields.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) For ISO transfers you also have to fill a :c:type:`usb_iso_packet_descriptor`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) structure, allocated at the end of the URB by :c:func:`usb_alloc_urb`, for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) each packet you want to schedule.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) The :c:func:`usb_submit_urb` call modifies ``urb->interval`` to the implemented
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) interval value that is less than or equal to the requested interval value.  If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) ``URB_ISO_ASAP`` scheduling is used, ``urb->start_frame`` is also updated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) For each entry you have to specify the data offset for this frame (base is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) transfer_buffer), and the length you want to write/expect to read.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) After completion, actual_length contains the actual transferred length and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) status contains the resulting status for the ISO transfer for this frame.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) It is allowed to specify a varying length from frame to frame (e.g. for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) audio synchronisation/adaptive transfer rates). You can also use the length
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) 0 to omit one or more frames (striping).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) For scheduling you can choose your own start frame or ``URB_ISO_ASAP``. As
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) explained earlier, if you always keep at least one URB queued and your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) completion keeps (re)submitting a later URB, you'll get smooth ISO streaming
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) (if usb bandwidth utilization allows).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) If you specify your own start frame, make sure it's several frames in advance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) of the current frame.  You might want this model if you're synchronizing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) ISO data with some other event stream.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) How to start interrupt (INT) transfers?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) =======================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) Interrupt transfers, like isochronous transfers, are periodic, and happen
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) in intervals that are powers of two (1, 2, 4 etc) units.  Units are frames
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) for full and low speed devices, and microframes for high speed ones.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) You can use the :c:func:`usb_fill_int_urb` macro to fill INT transfer fields.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) The :c:func:`usb_submit_urb` call modifies ``urb->interval`` to the implemented
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) interval value that is less than or equal to the requested interval value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) In Linux 2.6, unlike earlier versions, interrupt URBs are not automagically
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) restarted when they complete.  They end when the completion handler is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) called, just like other URBs.  If you want an interrupt URB to be restarted,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) your completion handler must resubmit it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) s