USB_PIPE_ISOC_XFER(9F) Kernel Functions for Drivers USB_PIPE_ISOC_XFER(9F)
NAME
usb_pipe_isoc_xfer, usb_pipe_stop_isoc_polling - USB isochronous
transfer and polling functions
SYNOPSIS
#include <sys/usb/usba.h>
int usb_pipe_isoc_xfer(
usb_pipe_handle_t pipe_handle,
usb_isoc_req_t *request,
usb_flags_t flags);
void usb_pipe_stop_isoc_polling(
usb_pipe_handle_t pipe_handle,
usb__flags_t flags);
INTERFACE LEVEL
illumos DDI specific (illumos DDI)
PARAMETERS
For
usb_pipe_isoc_xfer():
pipe_handle Isochronous pipe handle on which request is made.
request Pointer to isochronous transfer request.
flags USB_FLAGS_SLEEP is the only flag recognized. Wait for
needed resources if unavailable.
For
usb_pipe_stop_isoc_polling():
pipe_handle Isochronous pipe handle on which to stop polling for
input.
flags USB_FLAGS_SLEEP is the only flag recognized. Wait for
polling to stop.
DESCRIPTION
The
usb_pipe_isoc_xfer() function requests the USBA framework to
perform a transfer through a USB isochronous pipe. The request is
passed to the host controller driver (HCD), which performs the
necessary transactions to complete the request.
By their nature, isochronous transfers require several transactions
for completion. Each request may contain several packet descriptors.
Descriptors correspond to subtransfers to be made in different
frames. A request is deemed completed once all packets of that
request have been processed. It is illegal to specify the
USB_ATTRS_ONE_XFER attribute in an isochronous request. The
isochronous polling interval is always one millisecond, the period of
a full-speed frame.
All isochronous requests are asynchronous, and will notify the caller
of their completion via a callback function. All isochronous
requests must specify normal and exception callback handlers.
Requests will wait for needed, unavailable resources when
USB_FLAGS_SLEEP has been specified in flags. Requests made without
USB_FLAGS_SLEEP set will fail if needed resources are not readily
available.
No errors seen during request processing will result in aborted
transfers or exception callbacks. Such errors will instead be logged
in the packet descriptor's isoc_pkt_status field. These errors can be
examined when the completed request is returned through a normal
callback.
Isochronous-OUT TRANSFERS Allocate room for data when allocating isochronous-OUT requests via
usb_alloc_isoc_req(9F), by passing a positive value for the
len argument. The data will be divided among the request transactions,
each transaction represented by a packet descriptor. (See
usb_isoc_request(9S). When all of the data has been sent, regardless
of any errors encountered, a normal transfer callback will be
made to notify the client driver of completion.
If a request is submitted while other requests are active or queued,
and the new request has its USB_ATTRS_ISOC_XFER_ASAP attribute set,
the host controller driver will queue the request to start on a frame
which immediately follows the last frame of the last queued request.
Isochronous-IN TRANSFERS All isochronous-IN transfers start background polling, and require
only a single (original) request. The USBA framework will allocate a
new request each time polling has new data to return. Specify a zero
length when calling usb_alloc_isoc_req() to allocate the original
request, since it will not be used to return data. Set the
isoc_pkts_length in the request to specify how much data to poll per
interval (the length of one packet in the request).
The original request passed to
usb_pipe_isoc_xfer() will be used to
return status when polling termination is requested, or for error
condition notification. There can be only one isochronous-IN request
submitted at a time.
CALLBACKS
Isochronous transfer normal-completion callbacks cannot block for any
reason since they are called from interrupt context. They will have
USB_CB_INTR_CONTEXT set in their callback flags to note this.
Isochronous exception callbacks have the following restrictions for
blocking:
1. They can block for resources (for example to allocate
memory).
2. They cannot block for synchronous completion of a command
(for example
usb_pipe_close(9F)) done on the same pipe.
Asynchronous commands can be started, when the pipe's
policy pp_max_async_reqs field is initialized to
accommodate them.
3. They cannot block waiting for another callback to
complete.
4.
They cannot block waiting for a synchronous transfer
request to complete. They can, however, make an
asynchronous request (such as restarting polling with a
new isochronous-IN transfer).
Please see the section on callbacks in
usb_callback_flags(9S) for
more information.
All isochronous transfer exception callbacks signify that polling has
stopped. Polling requests are returned with the following completion
reasons:
USB_CR_STOPPED_POLLING
USB_CR_PIPE_CLOSING
Note: There are no exception callbacks for error conditions.
The
usb_pipe_stop_isoc_polling() function terminates polling on an
isochronous-IN pipe. The
usb_pipe_stop_isoc_polling() function does
the following:
1. Cease polling.
2. Allow any requests-in-progress to complete and be returned
to the client driver through the normal callback
mechanism.
3. Idle the pipe.
4. Return the original polling request to the client driver
through an exception callback with a completion reason of
USB_CR_STOPPED_POLLING.
RETURN VALUES
For
usb_pipe_isoc_xfer():
USB_SUCCESS Transfer was successful.
USB_INVALID_ARGS Request is
NULL.
USB_INVALID_CONTEXT Called from interrupt context with the
USB_FLAGS_SLEEP flag set.
USB_INVALID_REQUEST The request has been freed or otherwise
invalidated.
A set of conflicting attributes were
specified. See
usb_isoc_request(9S).
The normal and/or exception callback was
NULL, USB_FLAGS_SLEEP was not set and
USB_ATTRS_ONE_XFER was not set.
An isochronous request was specified with
a zeroed isoc_pkt_descr, a NULL
isoc_pkt_descr, or a NULL data argument.
An isochronous request was specified with
USB_ATTRS_ISOC_XFER_ASAP and a nonzero
isoc_frame_no.
USB_NO_FRAME_NUMBER An isochronous request was not specified
with one and only one of
USB_ATTRS_ISOC_START_FRAME or
USB_ATTRS_ISOC_XFER_ASAP specified.
An isochronous request was specified with
USB_ATTRS_ISOC_START_FRAME and a zero
isoc_frame_no.
USB_INVALID_START_FRAME An isochronous request was specified with
an invalid starting frame number (less
than current frame number, or zero) and
USB_ATTRS_ISOC_START_FRAME specified.
USB_INVALID_PIPE Pipe handle is NULL or invalid.
Pipe is closing or closed.
USB_PIPE_ERROR Pipe handle refers to a pipe which is in
the USB_PIPE_STATE_ERROR state.
USB_NO_RESOURCES Memory, descriptors or other resources
unavailable.
USB_HC_HARDWARE_ERROR Host controller is in error state.
USB_FAILURE An asynchronous transfer failed or an
internal error occurred.
An isoch request requested too much data:
(length > (usb_get_max_pkts_per_isoc_request() *
endpoint's wMaxPacketSize))
The pipe is in an unsuitable state (error,
busy, not ready).
Additional status information may be available in the
isoc_completion_reason and isoc_cb_flags fields of the request.
Please see
usb_completion_reason(9S) and
usb_callback_flags(9S) for
more information.
For
usb_pipe_stop_isoc_polling():
None, but will fail if called with USB_FLAGS_SLEEP specified from
interrupt context; the pipe handle is invalid, NULL or pertains to a
closing or closed pipe; or the pipe is in an error state. Messages
regarding these errors will be logged to the console logfile.
CONTEXT
Both of these functions may be called from kernel or user context
without regard to arguments. May be called from interrupt context
only when the USB_FLAGS_SLEEP flag is clear.
EXAMPLES
/* Start polling on an isochronous-IN pipe. */
usb_isoc_req_t isoc_req;
void isoc_pipe_callback(usb_pipe_handle_t, usb_isoc_req_t*);
void isoc_pipe_exception_callback(
usb_pipe_handle_t, usb_isoc_req_t*);
uint_t pkt_size;
usb_ep_data_t *isoc_ep_tree_node;
usb_ep_descr_t *isoc_ep_descr = ...; /* From usb_lookup_ep_data() */
isoc_ep_descr = &isoc_ep_tree_node->ep_descr;
pkt_size = isoc_ep_descr->wMaxPacketSize;
isoc_req = usb_alloc_isoc_req(
dip, num_pkts, NUM_PKTS * pkt_size, USB_FLAGS_SLEEP);
...
...
isoc_req->isoc_attributes = USB_ATTRS_ISOC_XFER_ASAP;
...
...
isoc_req->isoc_cb = isoc_pipe_callback;
isoc_req->isoc_exc_cb = isoc_pipe_exception_callback;
...
...
isoc_req->isoc_pkts_length = pkt_size;
isoc_req->isoc_pkts_count = NUM_PKTS;
for (pkt = 0; pkt < NUM_PKTS; pkt++) {
isoc_req->isoc_pkt_descr[pkt].isoc_pkt_length = pkt_size;
}
if ((rval = usb_pipe_isoc_xfer(pipe, isoc_req, USB_FLAGS_NOSLEEP))
!= USB_SUCCESS) {
cmn_err (CE_WARN,"%s%d: Error starting isochronous pipe polling.",
ddi_driver_name(dip), ddi_get_instance(dip));
}
-------
/* Stop polling before powering off device. Wait for polling to stop. */
usb_pipe_stop_isoc_polling(pipe, USB_FLAGS_SLEEP);
pm_idle_component(dip, 0);
ATTRIBUTES
See
attributes(7) for descriptions of the following attributes:
+--------------------+-------------------+
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
+--------------------+-------------------+
|Architecture | PCI-based systems |
+--------------------+-------------------+
|Interface stability | Evolving |
+--------------------+-------------------+
SEE ALSO
attributes(7),
usb_alloc_request(9F),
usb_get_cfg(9F),
usb_get_current_frame_number(9F),
usb_get_max_pkts_per_isoc_request(9F),
usb_get_status(9F),
usb_pipe_bulk_xfer(9F),
usb_pipe_ctrl_xfer(9F),
usb_pipe_get_state(9F),
usb_pipe_intr_xfer(9F),
usb_pipe_reset(9F),
usb_pipe_xopen(9F),
usb_bulk_request(9S),
usb_callback_flags(9S),
usb_completion_reason(9S),
usb_ctrl_request(9S),
usb_ep_descr(9S),
usb_intr_request(9S),
usb_isoc_request(9S) September 16, 2016 USB_PIPE_ISOC_XFER(9F)