.\" .\" This file and its contents are supplied under the terms of the .\" Common Development and Distribution License ("CDDL"), version 1.0. .\" You may only use this file in accordance with the terms of version .\" 1.0 of the CDDL. .\" .\" A full copy of the text of the CDDL should have accompanied this .\" source. A copy of the CDDL is also available via the Internet at .\" http://www.illumos.org/license/CDDL. .\" .\" .\" Copyright 2016 Joyent, Inc. .\" .Dd Dec 22, 2016 .Dt USBA_HCDI_PIPE_INTR_XFER 9E .Os .Sh NAME .Nm usba_hcdi_pipe_intr_xfer .Nd perform a USB interrupt transfer .Sh SYNOPSIS .In sys/usb/usba/hcdi.h .Ft int .Fo prefix_hcdi_pipe_intr_xfer .Fa "usba_pipe_handle_data_t *ph" .Fa "usb_intr_req_t *uirp" .Fa "usb_flags_t usb_flags" .Fc .Sh INTERFACE LEVEL .Sy Volatile - illumos USB HCD private function .Pp This is a private function that is not part of the stable DDI. It may be removed or changed at any time. .Sh PARAMETERS .Bl -tag -width Fa .It Fa ph A pointer to a USB pipe handle as defined in .Xr usba_pipe_handle_data 9S . .It Fa uirp A pointer to a USB interrupt transfer request. The structure's members are documented in .Xr usb_intr_req 9S . .It Fa usb_flags Flags which describe how allocations should be performed. Valid flags are: .Bl -tag -width Sy .It Sy USB_FLAGS_NOSLEEP Do not block waiting for memory. If memory is not available the allocation will fail. .It Sy USB_FLAGS_SLEEP Perform a blocking allocation. If memory is not available, the function will wait until memory is made available. .Pp Note, the request may still fail even if .Sy USB_FLAGS_SLEEP is specified. .El .El .Sh DESCRIPTION The .Fn usba_hcdi_pipe_intr_xfer entry point is used to initiate an .Em asynchronous USB interrupt transfer on the pipe .Fa ph . The specific USB interrupt transfer is provided in .Fa uirp . For more background on transfer types, see .Xr usba_hcdi 9E . .Pp The host controller driver should first check the USB address of the pipe handle. It may correspond to the root hub. If it does, rather than initiating an I/O transfer, the driver may need to emulate it. .Pp Unlike other transfers, interrupt transfers may be periodic. If the transfer is meant to be a one-shot, then the .Sy USB_ATTRS_ONE_XFER flag will be set in the .Sy intr_attributes member of the .Fa uirp structure. If the .Sy USB_ATTRS_ONE_XFER flag is not set, then the transfer begins a periodic transfer. Periodic transfers have different handling and behavior. .Pp Interrupt transfers may send data to the device or receive data from the device. A given interrupt endpoint is uni-directional. The direction can be determined from the endpoint address based on the .Sy p_ep member of .Fa ubrp . See .Xr usb_ep_descr 9S for more information on how to determine the direction of the endpoint. .Pp The device driver should allocate memory, whether memory suitable for a DMA transfer or otherwise, to perform the transfer. For all memory allocated, it should honor the values in .Fa usb_flags to determine whether or not it should block for allocations. .Pp The length of the interrupt transfer and its data can be found in the .Sy intr_len and .Sy intr_data members of .Fa uirp respectively. The .Xr mblk 9S structure that should not be used directly and data should be copied to or from the data buffer that will go the controller. .Pp Unlike bulk and control transfers, the .Fa intr_data member may not be allocated for interrupt-IN transfers. In such cases, the device driver is required to allocate the message block through something like .Xr allocb 9F and assign it to the .Sy intr_data member. .Pp If the driver successfully schedules the I/O, then it should return .Sy USB_SUCCESS . When the I/O completes, it must call .Xr usba_hcdi_cb 9F with .Fa uirp . If the transfer fails, but the driver returned .Sy USB_SUCCESS , it still must call .Xr usba_hcdi_cb 9F and should specify an error there. .Pp It is the driver's responsibility to time out one-shot interrupt transfer requests. If the timeout in the request as indicated in the .Sy intr_timeout member of .Fa uirp is set to zero, then the driver should use the USBA default timeout of .Sy HCDI_DEFAULT_TIMEOUT . All timeout values are in .Em seconds . .Ss Periodic Transfers When the .Sy USB_ATTRS_ONE_XFER flag is not present, it indicates that a periodic interrupt transfer is being initiated. Once a periodic interrupt transfer is initiated, every time data is received the driver should call .Xr usba_hcdi_cb 9F with the updated data. .Pp When a periodic transfer is initiated, many controller drivers will allocate multiple transfers up front and schedule them all. Many drivers do this to ensure that data isn't lost between servicing the first transfer and scheduling the next. The number of such transfers used depends on the polling frequency specified in the endpoint descriptor. .Pp Unless an error occurs, the driver must not use the original interrupt request, .Fa uirp . Instead, it should duplicate the request through the .Xr usba_hcdi_dup_intr_req 9F function before calling .Xr usba_hcdi_cb 9F . .Pp The driver should return the original transfer in one of the following conditions: .Bl -bullet .It A pipe reset request came in from the .Xr usba_hcdi_pipe_reset 9E entry point. .It A request to stop polling came in from the .Xr usba_hcdi_pipe_stop_intr_polling 9E entry point. .It A request to close the pipe came in from the .Xr usba_hcdi_pipe_close 9E entry point. .It An out of memory condition occurred. The caller should call .Xr usba_hcdi_cb 9F with the code .Sy USB_CR_NO_RESOURCES . .It Some other transfer error occurred. .El .Pp If the periodic interrupt transfer is for the root hub, the driver will need to emulate the behavior of a hub as specified in the USB specification. For more information, see the .Sx Root Hub Management section in .Xr usba_hcdi 9E . .Ss Callback Handling When the interrupt transfer completes, the driver should consider the following items to determine what actions it should take on the callback: .Sy USB_SUCCESS . Otherwise, it should return the appropriate USB error. If uncertain, use .Sy USB_FAILURE . .Bl -bullet .It If the transfer timed out, it should remove the transfer from the outstanding list, queue the next transfer, and return the transfer back to the OS with the error code .Sy USB_CR_TIMEOUT with .Xr usba_hcdi_cb 9F . .It If the transfer failed, it should find the appropriate error and call .Xr usba_hcdi_cb 9F with that error. .It If the transfer succeeded, but less data was transferred than expected, consult the .Sy intr_attributes member of the .Fa uirp . If the .Sy USB_ATTRS_SHORT_XFER_OK flag is not present, then the driver should call .Xr usba_hcdi_cb 9F with the error .Sy USB_CR_DATA_UNDERRUN . .It If the transfer was going to the host, then the driver should copy the data into the transfer's message block and update the .Sy b_wptr member of the .Xr mblk 9S . .It If everything was successful, call .Xr usba_hcdi_cb 9F with the code .Sy USB_CR_OK . .It If this was a periodic transfer, it should reschedule the transfer. .El .Sh RETURN VALUES Upon successful completion, the .Fn usba_hcdi_pipe_intr_xfer function should return function should return .Sy USB_SUCCESS . Otherwise, it should return the appropriate USB error. If uncertain, use .Sy USB_FAILURE . .Sh SEE ALSO .Xr usba_hcdi 9E , .Xr usba_hcdi_pipe_close 9E , .Xr usba_hcdi_pipe_reset 9E , .Xr usba_hcdi_pipe_stop_intr_polling 9E , .Xr allocb 9F , .Xr usba_hcdi_cb 9F , .Xr usba_hcdi_dup_intr_req 9F , .Xr mblk 9S , .Xr usb_ep_descr 9S , .Xr usb_intr_req 9S , .Xr usba_pipe_handle_data 9S