Product manual

Spinpoint M9TU-USB 3.0 Product Manual REV 1.0
54
USB INTERFACE AND USB COMMANDS
6.3.6.2.3 Configuration
A USB device must be configured before its function(s) may be used. The host is responsible for configuring a
USB device. The host typically requests configuration information from the USB device to determine the
device’s capabilities.
As part of the configuration process, the host sets the device configuration and, where necessary, selects the
appropriate alternate settings for the interfaces. Within a single configuration, a device may support multiple
interfaces. An interface is a related set of endpoints that present a single feature or function of the device to the
host. The protocol used to communicate with this related set of endpoints and the purpose of each endpoint
within the interface may be specified as part of a device class or vendor-specific definition.
In addition, an interface within a configuration may have alternate settings that redefine the number or
characteristics of the associated endpoints. If this is the case, the device must support the GetInterface() request
to report the current alternate setting for the specified interface and SetInterface() request to select the alternate
setting for the specified interface.
Within each configuration, each interface descriptor contains fields that identify the interface number and the
alternate setting. Interfaces are numbered from zero to one less than the number of concurrent interfaces
supported by the configuration. Alternate settings range from zero to one less than the number of alternate
settings for a specific interface. The default setting when a device is initially configured is alternate setting zero.
In support of adaptive device drivers that are capable of managing a related group of USB devices, the device
and interface descriptors contain Class, SubClass, and Protocol fields. These fields are used to identify the
function(s) provided by a USB device and the protocols used to communicate with the function(s) on the device.
A class code is assigned to a group of related devices that has been characterized as a part of a USB Class
Specification. A class of devices may be further subdivided into subclasses, and, within a class or subclass, a
protocol code may define how the Host Software communicates with the device.
Note: The assignment of class, subclass, and protocol codes must be coordinated but is beyond the scope of this
specification.
6.3.6.2.4 Data Transfer
Data may be transferred between a USB device endpoint and the host in one of four ways. An endpoint number
may be used for different types of data transfers in different alternate settings. However, once an alternate setting
is selected (including the default setting of an interface), a USB device endpoint uses only one data transfer
method until a different alternate setting is selected.
6.3.6.2.5 Power Management
■ Power Budgeting
USB bus power is a limited resource. During device enumeration, a host evaluates a device’s power
requirements. If the power requirements of a particular configuration exceed the power available to the device,
Host Software shall not select that configuration.
USB devices shall limit the power they consume from VBUS to one unit load or less until configured. Suspended
devices, whether configured or not, shall limit their bus power consumption. Depending on the power capabilities
of the port to which the device is attached, a USB device may be able to draw up to five unit loads from V
BUS
after configuration.
■ Remote WakeUp
Remote wakeup allows a suspended USB device to signal a host that may also be suspended. This notifies the
host that it should resume from its suspended mode, if necessary, and service the external event that triggered the
suspended USB device to signal the host. A USB device reports its ability to support remote wakeup in a
configuration descriptor. If a device supports remote wakeup, it must also allow the capability to be enabled and
disabled using the standard USB requests.
6.3.6.2.6 Request Processing
With the exception of SetAddress() requests, a device may begin processing of a request as soon as the device
returns the ACK following the Setup. The device is expected to “complete” processing of the request before it
allows the Status stage to complete successfully. Some requests initiate operations that take many milliseconds to
complete. For requests such as this, the device class is required to define a method other than Status stage
completion to indicate that the operation has completed. For example, a reset on a hub port takes at least 10 ms to
complete. The SetPortFeature(PORT_RESET) request “completes” when the reset on th
e port is initiated.
Completion of the reset operation is signaled when the port’s status change is set to indicate that the port is now
enabled
6.3.6.3 Standard USB Device Requests
All USB devices respond to requests from the host on the device’s Default Control Pipe. These requests are