svn commit: r44632 - head/en_US.ISO8859-1/books/arch-handbook/usb
Dru Lavigne
dru at FreeBSD.org
Wed Apr 23 14:57:23 UTC 2014
Author: dru
Date: Wed Apr 23 14:57:23 2014
New Revision: 44632
URL: http://svnweb.freebsd.org/changeset/doc/44632
Log:
Update URLs in USB sections and put them in Synopsis.
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
Modified:
head/en_US.ISO8859-1/books/arch-handbook/usb/chapter.xml
Modified: head/en_US.ISO8859-1/books/arch-handbook/usb/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/arch-handbook/usb/chapter.xml Tue Apr 22 20:03:45 2014 (r44631)
+++ head/en_US.ISO8859-1/books/arch-handbook/usb/chapter.xml Wed Apr 23 14:57:23 2014 (r44632)
@@ -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
More information about the svn-doc-all
mailing list