xref: /OK3568_Linux_fs/kernel/Documentation/usb/ohci.rst (revision 4882a59341e53eb6f0b4789bf948001014eff981)
1*4882a593Smuzhiyun====
2*4882a593SmuzhiyunOHCI
3*4882a593Smuzhiyun====
4*4882a593Smuzhiyun
5*4882a593Smuzhiyun23-Aug-2002
6*4882a593Smuzhiyun
7*4882a593SmuzhiyunThe "ohci-hcd" driver is a USB Host Controller Driver (HCD) that is derived
8*4882a593Smuzhiyunfrom the "usb-ohci" driver from the 2.4 kernel series.  The "usb-ohci" code
9*4882a593Smuzhiyunwas written primarily by Roman Weissgaerber <weissg@vienna.at> but with
10*4882a593Smuzhiyuncontributions from many others (read its copyright/licencing header).
11*4882a593Smuzhiyun
12*4882a593SmuzhiyunIt supports the "Open Host Controller Interface" (OHCI), which standardizes
13*4882a593Smuzhiyunhardware register protocols used to talk to USB 1.1 host controllers.  As
14*4882a593Smuzhiyuncompared to the earlier "Universal Host Controller Interface" (UHCI) from
15*4882a593SmuzhiyunIntel, it pushes more intelligence into the hardware.  USB 1.1 controllers
16*4882a593Smuzhiyunfrom vendors other than Intel and VIA generally use OHCI.
17*4882a593Smuzhiyun
18*4882a593SmuzhiyunChanges since the 2.4 kernel include
19*4882a593Smuzhiyun
20*4882a593Smuzhiyun	- improved robustness; bugfixes; and less overhead
21*4882a593Smuzhiyun	- supports the updated and simplified usbcore APIs
22*4882a593Smuzhiyun	- interrupt transfers can be larger, and can be queued
23*4882a593Smuzhiyun	- less code, by using the upper level "hcd" framework
24*4882a593Smuzhiyun	- supports some non-PCI implementations of OHCI
25*4882a593Smuzhiyun	- ... more
26*4882a593Smuzhiyun
27*4882a593SmuzhiyunThe "ohci-hcd" driver handles all USB 1.1 transfer types.  Transfers of all
28*4882a593Smuzhiyuntypes can be queued.  That was also true in "usb-ohci", except for interrupt
29*4882a593Smuzhiyuntransfers.  Previously, using periods of one frame would risk data loss due
30*4882a593Smuzhiyunto overhead in IRQ processing.  When interrupt transfers are queued, those
31*4882a593Smuzhiyunrisks can be minimized by making sure the hardware always has transfers to
32*4882a593Smuzhiyunwork on while the OS is getting around to the relevant IRQ processing.
33*4882a593Smuzhiyun
34*4882a593Smuzhiyun- David Brownell
35*4882a593Smuzhiyun  <dbrownell@users.sourceforge.net>
36