📄 nuhci_spec.html
字号:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html><head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>New UHCI Whitepaper</title></head><body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#0000FF" alink="#FF0000"><hr WIDTH="100%"><center><table><tr><td VALIGN=CENTER halign="left" border><a href="http://wwwbode.informatik.tu-muenchen.de/"><img SRC="LRR-TUM-voll.gif" ALT="LRR-TUM" BORDER=0 units="en" height=80 width=80></a></td><td><center><font size=+1><a href="http://www.informatik.tu-muenchen.de/">Institutfür Informatik </a><a href="http://www.tu-muenchen.de/">TU-München</a></font><br><font size=-1>Lehr- und Forschungseinheit Informatik X</font><br><b><font size=+1><a href="http://wwwbode.informatik.tu-muenchen.de">Lehrstuhlfür Rechnertechnik und Rechnerorganisation/Parallelrechner</a></font></b><br><font size=-1><a href="http://wwwbode.informatik.tu-muenchen.de/~bode/">Prof.Dr. A. Bode</a></font></center></td><td VALIGN=CENTER halign="right"><a href="http://www.informatik.tu-muenchen.de/"><img SRC="abakus.gif" ALT="TUM-INFO" BORDER=0 units="en" height=80 width=70></a></td></tr></table></center><center><hr WIDTH="100%"></center><p><br><center><table WIDTH="100%" NOSAVE ><tr ALIGN=CENTER BGCOLOR="#3366FF" NOSAVE><td NOSAVE><b><font face="Arial,Helvetica"><font color="#FFFFFF"><font size=+1>UniversalSerial Bus Development for Linux</font></font></font></b><br><i><font face="Arial,Helvetica"><font color="#FFFFFF">G. Acher &D. Fliegl & T. Sailer</font></font></i></td></tr></table></center><center><H1> Specification and Internals for the New UHCI Driver (Whitepaper...)</H1> brought to you by<p> Georg Acher, acher@in.tum.de (executive slave) (base guitar)<br> Deti Fliegl, deti@fliegl.de (executive slave) (lead voice)<br> Thomas Sailer, sailer@ife.ee.ethz.ch (chief consultant) (cheer leader)<p> $Id: nuhci_spec.html,v 1.5 1999/12/17 15:25:28 fliegl Exp $</center><H1> 1. General issues </H1><b> 1.1 Why a new UHCI driver, we already have one?!?</b><p>Correct, but its internal structure got more and more mixed up by the (stillongoing) efforts to get isochronous transfers (ISO) to work.Since there is an increasing need for reliable ISO-transfers (especially for USB-audio needed by TS and for a DAB-USB-Receiver build by GA and DF), this state was a bit unsatisfying in our opinion, so we've decided (basedon knowledge and experiences with the old UHCI driver) to start from scratch with a new approach, much simpler but at the same time more powerful.<P>It is inspired by the way Win98/Win2000 handles USB requests via URBs,but it's definitely 100% free of MS-code and doesn't crash while unplugging an used ISO-device like Win98 ;-) <P>Some code for HW setup and root hub management was taken from the original UHCI driver, but heavily modified to fit into the new code.The invention of the basic concept, and major coding were completed in two days (and nights) on the 16th and 17th of October 1999, now known as thegreat USB-October-Revolution started by GA, DF, and TS ;-)<P>Since the concept is in no way UHCI dependant, we hope that it will also be transfered to the OHCI-driver, so both drivers share a common API.<P><p><b>1.2. Advantages and disadvantages</b><p><ul><li> All USB transfer types work now!<li> Asynchronous operation<li> Simple, but powerful interface (only two calls for start and cancel)<li> Easy migration to the new API, simplified by a compatibility API<li> Simple usage of ISO transfers<li> Automatic linking of requests<li> ISO transfers allow variable length for each frame and striping<li> No CPU dependent and non-portable atomic memory access, no asm()-inlines<li> Tested on x86 and Alpha<p><li> Rewriting for ISO transfers needed</ul><p><b>1.3. Is there some compatibility to the old API?</b><p>Yes, but only for control, bulk and interrupt transfers. We've implemented some wrapper calls for these transfer types. The usbcore works fine with these wrappers. For ISO there's no compatibility, because the old ISO-API and its semantics were unnecessary complicated in our opinion.<p><b>1.4. What's really working?</b><p>As said above, CTRL und BULK already work fine even with the wrappers,so legacy code wouldn't notice the change.<p>Regarding to Thomas, ISO transfers now run stable with USB audio.INT transfers (e.g. mouse driver) work fine, too.<p><b>1.5. Are there any bugs?</b><p>No ;-)<p>Hm...<p>Well, of course this implementation needs extensive testing on all availablehardware, but we believe that any fixes shouldn't harm the overall concept.<p><b>1.6. What should be done next?</b><p>A large part of the request handling seems to be identical for UHCI and OHCI, so it would be a good idea to extract the common parts and have only the HW specific stuff in uhci.c. Furthermore, all other USB device driversshould need URBification, if they use isochronous or interrupt transfers.One thing missing in the current implementation (and the old UHCI driver) is fair queueing for BULK transfers. Since this would need (in principle) the alteration of already constructed TD chains (to switch from depth to breadth execution), another way has to be found. Maybe some simple heuristics work with the same effect.<p><hr><h1>2. Specification of the API</h1><b>2.1. Basic concept or 'What is an URB?'</b><p>The basic idea of the new driver is message passing, the message itself is called USB Request Block, or URB for short. <p><ul><li> An URB consists of all relevant information to execute any USB transaction and deliver the data and status back. <li> Execution of an URB is an inherently asynchronous operation, i.e. the submit_urb(urb) call returns immediately after it has successfully queued the requested action. <li> Ongoing transfers for one URB (e.g. ISO) can simply be canceled withunlink_urb(urb) at any time. <li> Each URB has a completion handler, which is called after the actionhas been successfully completed or canceled (INT transfers behave a bitdifferent, see below). The URB also contains a context-pointer for free usage and information passing to the completion handler.<li> URBs can be linked. After completing one URB, the next one can beautomatically submitted. This is especially useful for ISO transfers:You only have read/write the data from/to the buffers in the completion handler, the continous streaming itself is transparently done by the URB-machinery.</ul><p><b>2.2. The URB structure</b><p><center><table NOSAVE ><tr><td> typedef struct urb {</td></tr><tr><td>// ignore, for host controller/URB machine internal use</td></tr><tr><td> void *hcpriv; </td><td>// private data for host controller</td></tr><tr><td>struct list_head urb_list; </td><td> // list pointer to all active urbs </td></tr><tr><td>// This is used for urb linking</td></tr><tr><td> struct urb* next; </td><td> // pointer to next URB </td></tr><tr><td> struct usb_device *dev; </td><td>// pointer to associated USB device</td></tr><tr><td>// pipe is assembled by the various well known pipe-macros in usb.h</td></tr><tr><td> unsigned int pipe;</td><td> // pipe information</td></tr><tr><td> // status after each completion</td></tr><tr><td> int status; </td><td> // returned status</td></tr><tr><td> unsigned int transfer_flags; </td><td> // ASAP, SP_OK, EARLY_COMPLETE</td></tr><tr><td>// for data stage (CTRL), BULK, INT and ISO</td></tr><tr><td> void *transfer_buffer; </td><td> // associated data buffer</td></tr><tr><td>// expected length</td></tr><tr><td> int transfer_buffer_length; </td><td> // data buffer length</td></tr><tr><td> int actual_length; </td><td> // actual data buffer length </td></tr><tr><td>// setup stage for CTRL (always 8 bytes!)</td></tr><tr><td> unsigned char* setup_packet; </td><td> // setup packet (control only)</td></tr> <tr><td>// with ASAP, start_frame is set to the determined frame</td></tr><tr><td>int start_frame;</td><td> // start frame (iso/irq)</td></tr><tr><td>int number_of_packets; </td><td> // # of packets (iso/int)</td></tr><tr><td>int interval; </td><td> // polling interval (irq only)</td></tr><tr><td>int error_count; </td><td> // number of errors (iso only)</td></tr><tr><td>//</td></tr><tr><td>void *context; </td><td> // context for completion routine</td></tr><tr><td>usb_complete_t complete; </td><td> // pointer to completion routine</td></tr> <tr><td> //</td></tr><tr><td>// specification of the requested data offsets and length for ISO</td></tr><tr><td> iso_packet_descriptor_t </td><td> iso_frame_desc[0];</td></tr><tr><td>} urb_t, *purb_t;</td></tr></table></center><p><b>2.3. How to get an URB?</b><p>URBs are allocated with the following call<p><center><b> purb_t alloc_urb(int isoframes)</b> </center><p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -