os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Update URLs in USB sections and put them in Synopsis.

Browse source 
Fix some typos and inconsistencies noted in PR119545.
Add sentence indicating that this chapter discusses 2.0 implementation.
This whole chapter still needs an update for the 3.x implementation.

Sponsored by:	iXsystems
This commit is contained in:
Dru Lavigne 2014-04-23 14:57:23 +00:00
parent 376d565530
commit 5d064932b2
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44632
1 changed files with 57 additions and 32 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

89
en_US.ISO8859-1/books/arch-handbook/usb/chapter.xml
View file

@ -80,10 +80,34 @@
for the generic classes available in their operating system for the generic classes available in their operating system
MacOS and discouraging the use of separate drivers for each new MacOS and discouraging the use of separate drivers for each new
device. This chapter tries to collate essential information for a device. This chapter tries to collate essential information for a
basic understanding of the present implementation of the USB basic understanding of the USB 2.0 implementation
stack in FreeBSD/NetBSD. It is recommended however to read it stack in FreeBSD/NetBSD. It is recommended however to read it
together with the relevant specifications mentioned in the together with the relevant 2.0 specifications and other
references below.</para> developer resources:</para>
<itemizedlist>
<listitem>
<para>USB 2.0 Specification (<link
xlink:href="http://www.usb.org/developers/docs/usb20_docs/">http://www.usb.org/developers/docs/usb20_docs/</link>)</para>
</listitem>
<listitem>
<para>Universal Host Controller Interface
(<acronym>UHCI</acronym>) Specification (<link
xlink:href="ftp://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf">ftp://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf)</link></para>
</listitem>
<listitem>
<para>Open Host Controller Interface (<acronym>OHCI</acronym>)
Specification(<link
xlink:href="ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf">ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf</link>)</para>
</listitem>
<listitem>
<para>Developer section of <acronym>USB</acronym> home page (<link
xlink:href="http://www.usb.org/developers/">http://www.usb.org/developers/</link>)</para>
</listitem>
</itemizedlist>
<sect2> <sect2>
<title>Structure of the USB Stack</title> <title>Structure of the USB Stack</title>
@ -132,12 +156,11 @@
which the recipient of the data can return either ACK which the recipient of the data can return either ACK
(acknowledge reception), NAK (retry), STALL (error condition) or (acknowledge reception), NAK (retry), STALL (error condition) or
nothing (garbled data stage, device not available or nothing (garbled data stage, device not available or
disconnected). Section 8.5 of the <link xlink:href="http://www.usb.org/developers/docs.html">USB disconnected). Section 8.5 of the USB 2.0 Specification
specification</link> explains the details of packets in more explains the details of packets in more
detail. Four different types of transfers can occur on a USB detail. Four different types of transfers can occur on a USB
bus: control, bulk, interrupt and isochronous. The types of bus: control, bulk, interrupt and isochronous. The types of
transfers and their characteristics are described below (`Pipes' transfers and their characteristics are described below.</para>
subsection).</para>
<para>Large transfers between the device on the USB bus and the <para>Large transfers between the device on the USB bus and the
device driver are split up into multiple packets by the host device driver are split up into multiple packets by the host
@ -154,16 +177,17 @@
root ports and the changes that have occurred since the last root ports and the changes that have occurred since the last
reset of the status change register. Access to these registers reset of the status change register. Access to these registers
is provided through a virtualised hub as suggested in the USB is provided through a virtualised hub as suggested in the USB
specification [ 2]. The virtual hub must comply with the hub specification. The virtual hub must comply with the hub
device class given in chapter 11 of that specification. It must device class given in chapter 11 of that specification. It must
provide a default pipe through which device requests can be sent provide a default pipe through which device requests can be sent
to it. It returns the standard andhub class specific set of to it. It returns the standard andhub class specific set of
descriptors. It should also provide an interrupt pipe that descriptors. It should also provide an interrupt pipe that
reports changes happening at its ports. There are currently two reports changes happening at its ports. There are currently two
specifications for host controllers available: <link xlink:href="http://developer.intel.com/design/USB/UHCI11D.htm">Universal specifications for host controllers available: Universal Host
Host Controller Interface</link> (UHCI; Intel) and <link xlink:href="http://www.compaq.com/productinfo/development/openhci.html">Open Controller Interface (<acronym>UHCI</acronym>) from Intel
Host Controller Interface</link> (OHCI; Compaq, Microsoft, and Open Host Controller Interface (<acronym>OHCI</acronym>)
National Semiconductor). The UHCI specification has been from Compaq, Microsoft, and National
Semiconductor. The <acronym>UHCI</acronym> specification has been
designed to reduce hardware complexity by requiring the host designed to reduce hardware complexity by requiring the host
controller driver to supply a complete schedule of the transfers controller driver to supply a complete schedule of the transfers
for each frame. OHCI type controllers are much more independent for each frame. OHCI type controllers are much more independent
@ -220,8 +244,8 @@
service routine will locate all the finished transfers and service routine will locate all the finished transfers and
call their callbacks.</para> call their callbacks.</para>
<para>See for a more elaborate description the <link xlink:href="http://developer.intel.com/design/USB/UHCI11D.htm">UHCI <para>Refer to the <acronym>UHCI</acronym> Specification for a
specification.</link></para> more elaborate description.</para>
</sect2> </sect2>
@ -239,14 +263,13 @@
the controller hardware does the splitting into packets. The the controller hardware does the splitting into packets. The
pointers to the data buffers are updated after each transfer pointers to the data buffers are updated after each transfer
and when the start and end pointer are equal, the TD is and when the start and end pointer are equal, the TD is
retired to the done-queue. The four types of endpoints have retired to the done-queue. The four types of endpoints
their own queues. Control and bulk endpoints are queued each at (interrupt, isochronous, control, and bulk) have their
own queues. Control and bulk endpoints are queued each at
their own queue. Interrupt EDs are queued in a tree, with the their own queue. Interrupt EDs are queued in a tree, with the
level in the tree defining the frequency at which they level in the tree defining the frequency at which they
run.</para> run.</para>
<para>framelist interruptisochronous control bulk</para>
<para>The schedule being run by the host controller in each <para>The schedule being run by the host controller in each
frame looks as follows. The controller will first run the frame looks as follows. The controller will first run the
non-periodic control and bulk queues, up to a time limit set non-periodic control and bulk queues, up to a time limit set
@ -263,8 +286,8 @@
transfer and reschedule interrupt and isochronous transfer and reschedule interrupt and isochronous
endpoints.</para> endpoints.</para>
<para>See for a more elaborate description the <link xlink:href="http://www.compaq.com/productinfo/development/openhci.html"> <para>See the <acronym>UHCI</acronym> Specification for a more
OHCI specification</link>. Services layer The middle layer elaborate description. The middle layer
provides access to the device in a controlled way and provides access to the device in a controlled way and
maintains resources in use by the different drivers and the maintains resources in use by the different drivers and the
services layer. The layer takes care of the following services layer. The layer takes care of the following
@ -303,7 +326,7 @@
provide different frame sizes and numbers of frames per provide different frame sizes and numbers of frames per
second.</para> second.</para>
<para>Within each interface 0 or more endpoints can be <para>Within each interface, 0 or more endpoints can be
specified. Endpoints are the unidirectional access points for specified. Endpoints are the unidirectional access points for
communicating with a device. They provide buffers to communicating with a device. They provide buffers to
temporarily store incoming or outgoing data from the temporarily store incoming or outgoing data from the
@ -312,14 +335,16 @@
default endpoint, endpoint 0, is not part of any interface and default endpoint, endpoint 0, is not part of any interface and
available in all configurations. It is managed by the services available in all configurations. It is managed by the services
layer and not directly available to device drivers.</para> layer and not directly available to device drivers.</para>
<!--
This part is unclear, is it an unformatted code example?
<para>Level 0 Level 1 Level 2 Slot 0</para> <para>Level 0 Level 1 Level 2 Slot 0</para>
<para>Slot 3 Slot 2 Slot 1</para> <para>Slot 3 Slot 2 Slot 1</para>
<para>(Only 4 out of 32 slots shown)</para> <para>(Only 4 out of 32 slots shown)</para>
-->
<para>This hierarchical configuration information is described <para>This hierarchical configuration information is described
in the device by a standard set of descriptors (see section 9.6 in the device by a standard set of descriptors (see section 9.6
of the USB specification [ 2]). They can be requested through of the USB specification). They can be requested through
the Get Descriptor Request. The services layer caches these the Get Descriptor Request. The services layer caches these
descriptors to avoid unnecessary transfers on the USB descriptors to avoid unnecessary transfers on the USB
bus. Access to the descriptors is provided through function bus. Access to the descriptors is provided through function
@ -403,10 +428,10 @@
(endpoint 0). The pipe carries the device requests and (endpoint 0). The pipe carries the device requests and
associated data. The difference between transfers over the associated data. The difference between transfers over the
default pipe and other pipes is that the protocol for default pipe and other pipes is that the protocol for
the transfers is described in the USB specification [ 2]. These the transfers is described in the USB specification. These
requests are used to reset and configure the device. A basic requests are used to reset and configure the device. A basic
set of commands that must be supported by each device is set of commands that must be supported by each device is
provided in chapter 9 of the USB specification [ 2]. The provided in chapter 9 of the USB specification. The
commands supported on this pipe can be extended by a device commands supported on this pipe can be extended by a device
class specification to support additional class specification to support additional
functionality.</para> functionality.</para>
@ -444,9 +469,9 @@
bandwidth.</para> bandwidth.</para>
<para>More information on scheduling of transfers and bandwidth <para>More information on scheduling of transfers and bandwidth
reclamation can be found in chapter 5of the USB specification reclamation can be found in chapter 5of the USB specification,
[ 2], section 1.3 of the UHCI specification [ 3] and section section 1.3 of the UHCI specification, and section
3.4.2 of the OHCI specification [4].</para> 3.4.2 of the OHCI specification.</para>
</sect2> </sect2>
</sect1> </sect1>
@ -528,18 +553,18 @@
<para>The protocol used over pipes other than the default pipe is <para>The protocol used over pipes other than the default pipe is
undefined by the USB specification. Information on this can be undefined by the USB specification. Information on this can be
found from various sources. The most accurate source is the found from various sources. The most accurate source is the
developer's section on the USB home pages [ 1]. From these pages developer's section on the USB home pages.
a growing number of deviceclass specifications are From these pages, a growing number of deviceclass specifications are
available. These specifications specify what a compliant device available. These specifications specify what a compliant device
should look like from a driver perspective, basic functionality should look like from a driver perspective, basic functionality
it needs to provide and the protocol that is to be used over the it needs to provide and the protocol that is to be used over the
communication channels. The USB specification [ 2] includes the communication channels. The USB specification includes the
description of the Hub Class. A class specification for Human description of the Hub Class. A class specification for Human
Interface Devices (HID) has been created to cater for keyboards, Interface Devices (HID) has been created to cater for keyboards,
tablets, bar-code readers, buttons, knobs, switches, etc. A tablets, bar-code readers, buttons, knobs, switches, etc. A
third example is the class specification for mass storage third example is the class specification for mass storage
devices. For a full list of device classes see the developers devices. For a full list of device classes see the developers
section on the USB home pages [ 1].</para> section on the USB home pages.</para>
<para>For many devices the protocol information has not yet been <para>For many devices the protocol information has not yet been
published however. Information on the protocol being used might published however. Information on the protocol being used might