Lines Matching refs:completion
36 - Each URB has a completion handler, which is called after the action
38 context-pointer for passing information to the completion handler.
42 data to an endpoint while your driver handles completion of another.
60 // (IN) all urbs need completion routines
61 void *context; // context for completion routine
62 usb_complete_t complete; // pointer to completion routine
64 // (OUT) status after each completion
110 returned to you in a completion callback. It will automatically be
122 length, the completion handler, and its context. Take a look at the some
156 never look at that value except in your completion callback.
158 For isochronous endpoints, your completion handlers should (re)submit
175 returns; you must still wait for the completion handler to be called.
182 until after the URB has been returned and the completion handler
184 that if the completion handler or anyone else tries to resubmit it
189 time, and the completion handler may free the URB. If this happens
196 completion handler, the handler must not take any lock that is held
208 by the completion handler.
211 What about the completion handler?
218 I.e., it gets the URB that caused the completion call. In the completion
221 information to the completion handler.
226 have transferred successfully before the completion was called.
235 In the current kernel, completion handlers run with local interrupts
237 local IRQs are always disabled inside completion handlers.
259 After completion, actual_length contains the actual transferred length and
267 completion keeps (re)submitting a later URB, you'll get smooth ISO streaming
287 restarted when they complete. They end when the completion handler is
289 your completion handler must resubmit it.