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
MacOS and discouraging the use of separate drivers for each new
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
together with the relevant specifications mentioned in the
references below.</para>
together with the relevant 2.0 specifications and other
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>
<title>Structure of the USB Stack</title>
@ -132,12 +156,11 @@
which the recipient of the data can return either ACK
(acknowledge reception), NAK (retry), STALL (error condition) 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
specification</link> explains the details of packets in more
disconnected). Section 8.5 of the USB 2.0 Specification
explains the details of packets in more
detail. Four different types of transfers can occur on a USB
bus: control, bulk, interrupt and isochronous. The types of
transfers and their characteristics are described below (`Pipes'
subsection).</para>
transfers and their characteristics are described below.</para>
<para>Large transfers between the device on the USB bus and the
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
reset of the status change register. Access to these registers
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
provide a default pipe through which device requests can be sent
to it. It returns the standard andhub class specific set of
descriptors. It should also provide an interrupt pipe that
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
Host Controller Interface</link> (UHCI; Intel) and <link xlink:href="http://www.compaq.com/productinfo/development/openhci.html">Open
Host Controller Interface</link> (OHCI; Compaq, Microsoft,
National Semiconductor). The UHCI specification has been
specifications for host controllers available: Universal Host
Controller Interface (<acronym>UHCI</acronym>) from Intel
and Open Host Controller Interface (<acronym>OHCI</acronym>)
from Compaq, Microsoft, and National
Semiconductor. The <acronym>UHCI</acronym> specification has been
designed to reduce hardware complexity by requiring the host
controller driver to supply a complete schedule of the transfers
for each frame. OHCI type controllers are much more independent
@ -220,8 +244,8 @@
service routine will locate all the finished transfers and
call their callbacks.</para>
<para>See for a more elaborate description the <link xlink:href="http://developer.intel.com/design/USB/UHCI11D.htm">UHCI
specification.</link></para>
<para>Refer to the <acronym>UHCI</acronym> Specification for a
more elaborate description.</para>
</sect2>
@ -239,14 +263,13 @@
the controller hardware does the splitting into packets. The
pointers to the data buffers are updated after each transfer
and when the start and end pointer are equal, the TD is
retired to the done-queue. The four types of endpoints have
their own queues. Control and bulk endpoints are queued each at
retired to the done-queue. The four types of endpoints
(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
level in the tree defining the frequency at which they
run.</para>
<para>framelist interruptisochronous control bulk</para>
<para>The schedule being run by the host controller in each
frame looks as follows. The controller will first run the
non-periodic control and bulk queues, up to a time limit set
@ -263,8 +286,8 @@
transfer and reschedule interrupt and isochronous
endpoints.</para>
<para>See for a more elaborate description the <link xlink:href="http://www.compaq.com/productinfo/development/openhci.html">
OHCI specification</link>. Services layer The middle layer
<para>See the <acronym>UHCI</acronym> Specification for a more
elaborate description. The middle layer
provides access to the device in a controlled way and
maintains resources in use by the different drivers and the
services layer. The layer takes care of the following
@ -303,7 +326,7 @@
provide different frame sizes and numbers of frames per
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
communicating with a device. They provide buffers to
temporarily store incoming or outgoing data from the
@ -312,14 +335,16 @@
default endpoint, endpoint 0, is not part of any interface and
available in all configurations. It is managed by the services
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>Slot 3 Slot 2 Slot 1</para>
<para>(Only 4 out of 32 slots shown)</para>
-->
<para>This hierarchical configuration information is described
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
descriptors to avoid unnecessary transfers on the USB
bus. Access to the descriptors is provided through function
@ -403,10 +428,10 @@
(endpoint 0). The pipe carries the device requests and
associated data. The difference between transfers over the
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
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
class specification to support additional
functionality.</para>
@ -444,9 +469,9 @@
bandwidth.</para>
<para>More information on scheduling of transfers and bandwidth
reclamation can be found in chapter 5of the USB specification
[ 2], section 1.3 of the UHCI specification [ 3] and section
3.4.2 of the OHCI specification [4].</para>
reclamation can be found in chapter 5of the USB specification,
section 1.3 of the UHCI specification, and section
3.4.2 of the OHCI specification.</para>
</sect2>
</sect1>
@ -528,18 +553,18 @@
<para>The protocol used over pipes other than the default pipe is
undefined by the USB specification. Information on this can be
found from various sources. The most accurate source is the
developer's section on the USB home pages [ 1]. From these pages
a growing number of deviceclass specifications are
developer's section on the USB home pages.
From these pages, a growing number of deviceclass specifications are
available. These specifications specify what a compliant device
should look like from a driver perspective, basic functionality
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
Interface Devices (HID) has been created to cater for keyboards,
tablets, bar-code readers, buttons, knobs, switches, etc. A
third example is the class specification for mass storage
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
published however. Information on the protocol being used might