Date: Wed, 23 Apr 2014 14:57:23 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44632 - head/en_US.ISO8859-1/books/arch-handbook/usb Message-ID: <201404231457.s3NEvNr4087606@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404231457.s3NEvNr4087606>