Interface Level

Parameters

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(9F). 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:

They can block for resources (for example to allocate memory).

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.

They cannot block waiting for another callback to complete.

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).

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.