================================== これは、 linux-2.6.16/Documentation/usb/ehci.txt の和訳（ドラフト） です。 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > 更新日 ： 2006/6/17 原著作者: David Brownell 翻訳者 ： Hiroshi.Suzuki < setter at reset dot jp > 校正者 ： Chie Nakatani さん 岡本 一幸 さん Masanori Kobayasi さん ================================== 27-Dec-2002 2002年12月27日 The EHCI driver is used to talk to high speed USB 2.0 devices using USB 2.0-capable host controller hardware. The USB 2.0 standard is compatible with the USB 1.1 standard. It defines three transfer speeds: EHCI ドライバは、USB 2.0 が使えるホストコントローラハードウェアを使って、 High Speed (HS) USB 2.0 デバイスと対話するのに使います。USB 2.0 規格は、 USB 1.1 規格と互換性があり、次の3種類の速度を定義しています。 - "High Speed" 480 Mbit/sec (60 MByte/sec) - "Full Speed" 12 Mbit/sec (1.5 MByte/sec) - "Low Speed" 1.5 Mbit/sec - "High Speed" (HS) 480 Mビット/秒 (60 Mバイト/秒) - "Full Speed" (FS) 12 Mビット/秒 (1.5 Mバイト/秒) - "Low Speed" (LS) 1.5 Mビット/秒 USB 1.1 only addressed full speed and low speed. High speed devices can be used on USB 1.1 systems, but they slow down to USB 1.1 speeds. USB 1.1 は、Full Speed と、Low Speed だけを指定できます。 High Speed (USB 2.0) デバイスは、USB 1.1 システムでも使えますが、 USB 1.1 の速度に落ちます。 USB 1.1 devices may also be used on USB 2.0 systems. When plugged into an EHCI controller, they are given to a USB 1.1 "companion" controller, which is a OHCI or UHCI controller as normally used with such devices. When USB 1.1 devices plug into USB 2.0 hubs, they interact with the EHCI controller through a "Transaction Translator" (TT) in the hub, which turns low or full speed transactions into high speed "split transactions" that don't waste transfer bandwidth. USB 1.1 デバイスは、USB 2.0 システムでも使えます。EHCI コントローラに(接続 したとき、それらは、USB 1.1 "コンパニオン" コントローラ (通常そのようなデバイス で使われる、OHCI または、UHCI コントローラ) に与えられ(で処理され)ます。 USB 1.1 デバイスを、USB 2.0 ハブに接続したとき、ハブ内の、"トランザクション変換 機構" (TT) (転送速度を犠牲にしないで、Low Speed または Full Speed のトランザク ションを、High Speed の "スプリット・トランザクション" に変換する) を通して EHCI コントローラと対話します。 At this writing, this driver has been seen to work with implementations of EHCI from (in alphabetical order): Intel, NEC, Philips, and VIA. Other EHCI implementations are becoming available from other vendors; you should expect this driver to work with them too. この文書の執筆時点で、このドライバは次の会社の EHCI 実装で動作することがわかっ ています (アルファベット順): インテル社, NEC 社, フィリップス社, VIA 社。 他社の EHCI 実装は、他のベンダからのものを入手するようになっています (このドライバがそれらでも動作するのを期待されているはずです)。 While usb-storage devices have been available since mid-2001 (working quite speedily on the 2.4 version of this driver), hubs have only been available since late 2001, and other kinds of high speed devices appear to be on hold until more systems come with USB 2.0 built-in. Such new systems have been available since early 2002, and became much more typical in the second half of 2002. USB ストレージ(記憶)デバイスは、2001年中ごろから使えるようになっています (2.4 版 のこのドライバでとても高速に動作しています) 。ハブだけは、2001年末頃から使える ようになっていて、また、他の種類の High Speed デバイスは、さらに多くのシステム が、USB 2.0 を内蔵するのを待っているようです。そのような新しいシステムは、 2002年初旬に使えるようになり、2002年中旬には、さらに標準的なものになりました。 Note that USB 2.0 support involves more than just EHCI. It requires other changes to the Linux-USB core APIs, including the hub driver, but those changes haven't needed to really change the basic "usbcore" APIs exposed to USB device drivers. USB 2.0 サポートは、EHCI に限らず広範囲にわたることに注意してください。 それは、Linux USB の核となる API の他の変更 (バブドライバを含む) を必要とします が、このような変更は、USB デバイスドライバに公開する、基本的な "usbcore" API の 実際の変更を必要としません。 USB 2.0 - David Brownell FUNCTIONALITY 機能 This driver is regularly tested on x86 hardware, and has also been used on PPC hardware so big/little endianness issues should be gone. It's believed to do all the right PCI magic so that I/O works even on systems with interesting DMA mapping issues. このドライバは通常、x86 ハードウェア上で検証しています。また、PPC ハードウェア を使っても検証しているので、ビッグ/リトルエンディアンの違いに起因する問題はな くなっているはずです。すべての、正しい PCI マジックが行われることを考慮している ので、興味深い DMA マッピング問題を持つシステムでも、その入出力は動作します。 Transfer Types 転送の種類 At this writing the driver should comfortably handle all control, bulk, and interrupt transfers, including requests to USB 1.1 devices through transaction translators (TTs) in USB 2.0 hubs. But you may find bugs. この文書執筆の時点では、ドライバは、すべてのコントロール転送、 バルク転送、イン タラプト転送、USB 2.0 ハブのトランザクション変換機構 (TT) を経由して USB 1.1 デ バイスへのリクエストを含めて、快適に扱えるはずです。しかし、バグがあるかもしれません。 High Speed Isochronous (ISO) transfer support is also functional, but at this writing no Linux drivers have been using that support. High Speed アイソクロナス 転送 (*) も機能しますが、これを書いているときに は、このサポートを使っている Linux ドライバはありません。 (*) 一定時間単位の転送量を保証 (逆に転送内容は保証しない) する転送方法で、 オーディオやビデオなどでリアルタイム性が要求されるものに使えます。 (等時転送) Full Speed Isochronous transfer support, through transaction translators, is not yet available. Note that split transaction support for ISO transfers can't share much code with the code for high speed ISO transfers, since EHCI represents these with a different data structure. So for now, most USB audio and video devices can't be connected to high speed buses. トランザクション変換機構 (TT) を経由した High Speed アイソクロナス (ISO) 転送サポートは、まだ使えません。 ISO 転送のためのスプリット・トランザクションのサポートは、EHCI が異なるデータ構 造でこれらを表わすので、High Speed ISO 転送のコードとたくさんのコードを共有でき ないことに注意してください。ですから、現時点で、ほとんどの USB オーディオと、 ビデオデバイスは High Speed バスに接続できません。 Driver Behavior ドライバの動作 Transfers of all types can be queued. This means that control transfers from a driver on one interface (or through usbfs) won't interfere with ones from another driver, and that interrupt transfers can use periods of one frame without risking data loss due to interrupt processing costs. すべての種類の転送は、待ち行列 (キュー) に入れられます。これは、ひとつの インタフェース (または、usbfs 経由) 上のドライバからのコントロール転送は、 他のドライバからのものに妨げられないということで、また、インタラプト転送は、 割り込み処理実行時間によるデータ消失の危険性なしに、ひとつのフレーム周期 を使えるということです。 The EHCI root hub code hands off USB 1.1 devices to its companion controller. This driver doesn't need to know anything about those drivers; a OHCI or UHCI driver that works already doesn't need to change just because the EHCI driver is also present. EHCI ルートハブコードは、USB 1.1 デバイスを、そのコンパニオンコントローラに渡します。 このドライバは、それらドライバについて何も知る必要がありません; OHCI、または UHCI ドライバは、(EHCI ドライバがそれらも提供しているので) まったく変更を必要と せずに動作しています。 There are some issues with power management; suspend/resume doesn't behave quite right at the moment. 電源管理でいくつかの問題があります;一時停止/復帰は、現時点では正しく動作しません。 (訳注: "現時点" が 2002/末 なので、2.6.16 でも同じかはわかりません。 drivers/usb/host/ ディレクトリ内の suspend/resume 関連部分も、 この時点 (2.5.x) と比較して大幅に変更されています) Also, some shortcuts have been taken with the scheduling periodic transactions (interrupt and isochronous transfers). These place some limits on the number of periodic transactions that can be scheduled, and prevent use of polling intervals of less than one frame. さらに、スケジューリングされた周期的トランザクション (インタラプト転送、 およびアイソクロナス転送) で、いくつかの省略された過程があります。 これらの箇所では、スケジューリング可能な周期的トランザクションの数に、 いくつかの制限があり、1フレーム未満の間隔でポーリングすることを防げます。 USE BY 使い方 Assuming you have an EHCI controller (on a PCI card or motherboard) and have compiled this driver as a module, load this like: (PCI カードか、マザーボード上に) EHCI コントローラがあり、 このドライバをモジュールとしてコンパイルしたと仮定すると、次のように組み込みます: # modprobe ehci-hcd and remove it by: また、取り外すには: # rmmod ehci-hcd You should also have a driver for a "companion controller", such as "ohci-hcd" or "uhci-hcd". In case of any trouble with the EHCI driver, remove its module and then the driver for that companion controller will take over (at lower speed) all the devices that were previously handled by the EHCI driver. "ohci-hcd" または "uhci-hcd" のような、"コンパニオンコントローラ" 用のドライバも なくてはなりません。EHCI ドライバで何か問題がある場合、そのモジュールを取り 外せば、その後、以前 EHCI ドライバが扱っていたすべてのデバイスは、コンパニオンコント ローラのためのドライバが、(Low Speed で) 引き受けるでしょう。 Module parameters (pass to "modprobe") include: ("modprobe" に渡す)モジュールパラメータには次のものもあります: log2_irq_thresh (default 0): Log2 of default interrupt delay, in microframes. The default value is 0, indicating 1 microframe (125 usec). Maximum value is 6, indicating 2^6 = 64 microframes. This controls how often the EHCI controller can issue interrupts. log2_irq_thresh (デフォルト 0): 割り込み遅延初期値 (マイクロフレーム) の Log2。初期値は 0 で、1 マイクロフレーム (125 マイクロ秒) を表わします。最大値は、6 で、 2^6 = 64 マイクロフレームを表わします。EHCI コントローラがどのくらい 頻繁に割り込みを発行できるかを制御します。 If you're using this driver on a 2.5 kernel, and you've enabled USB debugging support, you'll see three files in the "sysfs" directory for any EHCI controller: 2.5 カーネルでこのドライバを使い、また、USB デバッギングサポートを有効にしてい るなら、いずれかの EHCI コントローラの "sysfs" ディレクトリ内で3つのファイルが 見えるでしょう: "async" dumps the asynchronous schedule, used for control and bulk transfers. Shows each active qh and the qtds pending, usually one qtd per urb. (Look at it with usb-storage doing disk I/O; watch the request queues!) "periodic" dumps the periodic schedule, used for interrupt and isochronous transfers. Doesn't show qtds. "registers" show controller register state, and "async" は、コントロール転送とバルク転送に使う、非同期のスケジュールをダンプします。 それぞれの、活性化されている qh と、保留された qtds (通常、urb 毎 のひとつの qtd) を示します。(これは、usb 記憶装置での ディスク入出力で見られます;リクエスト待ち行列を見てください！) "periodic" は、インタラプト転送、およびアイソクロナス転送に使う周期的スケジュールをダンプします。 qtds は示しません。 "registers" コントローラレジスタの状態を示します。さらに、 The contents of those files can help identify driver problems. これらファイルの中身はドライバの問題を切り分ける助けになります。 Device drivers shouldn't care whether they're running over EHCI or not, but they may want to check for "usb_device->speed == USB_SPEED_HIGH". High speed devices can do things that full speed (or low speed) ones can't, such as "high bandwidth" periodic (interrupt or ISO) transfers. Also, some values in device descriptors (such as polling intervals for periodic transfers) use different encodings when operating at high speed. デバイスドライバは、それらが EHCI 上で動いているのかを気にしないほうがよいです が、"usb_device->speed == USB_SPEED_HIGH" を確認したいこともあります。 High Speed デバイスでは可能で、Full Speed (または Low Speed) デバイスでは不可能 な、"高帯域" な周期的 (インタラプトまたは ISO) 転送のようなことがあるからです。 デバイス・ディスクリプタのいくつかの値 (周期的転送のポーリング間隔のような) も、 High Speed で処理するときは異なるエンコードを使います。 However, do make a point of testing device drivers through USB 2.0 hubs. Those hubs report some failures, such as disconnections, differently when transaction translators are in use; some drivers have been seen to behave badly when they see different faults than OHCI or UHCI report. また、必ず USB 2.0 ハブを経由して、デバイスドライバを検証してください。 ハブは、機器の取り外し、トランザクション変換機構が異なった使い方をされているな どのような、いくつかの処理不能なことを報告します; いくつかのドライバは、OHCI、 または UHCI の報告とは異なる失敗が見られるとき、うまく動きませんでした。 PERFORMANCE 性能 USB 2.0 throughput is gated by two main factors: how fast the host controller can process requests, and how fast devices can respond to them. The 480 Mbit/sec "raw transfer rate" is obeyed by all devices, but aggregate throughput is also affected by issues like delays between individual high speed packets, driver intelligence, and of course the overall system load. Latency is also a performance concern. USB 2.0 のスループットは、主に2つの要因により制限されます: ホストコントローラが どれだけ早くリクエストを処理できるか、およびデバイスがどれだけ早く応答できるかです。 480M ビット/秒 "生の転送速度" は、すべてのデバイスが遵守していますが、 全体の処理速度は、個々の High Speed パケット間遅延、ドライバの能力、そして、言 うまでもなく、システム全体の負荷にも影響されます。 待ち時間(レイテンシ)も性能に関係します。 Bulk transfers are most often used where throughput is an issue. It's good to keep in mind that bulk transfers are always in 512 byte packets, and at most 13 of those fit into one USB 2.0 microframe. Eight USB 2.0 microframes fit in a USB 1.1 frame; a microframe is 1 msec/8 = 125 usec. スループットの観点から、バルク転送がもっとも頻繁に使われます。バルク転送は常に 512 バイトパケットで、最大で13パケットがひとつの USB 2.0 マイクロフレーム内に収めら れることを心に留めておくと良いでしょう。8つの USB 2.0 マイクロフレームが、ひと つの USB 1.1フレームに収められます; マイクロフレームは、8分の1ミリ秒 = 125マイ クロ秒。 So more than 50 MByte/sec is available for bulk transfers, when both hardware and device driver software allow it. Periodic transfer modes (isochronous and interrupt) allow the larger packet sizes which let you approach the quoted 480 MBit/sec transfer rate. ですから、ハードウェアと、デバイスドライバソフトウェアの両方でバルク転送が使え るとき、50Mバイト/秒以上の速度がでます。周期的転送モード (アイソクロナスおよびイン タラプト) は、480 Mビット/秒 に近い転送速度を引き出すのに、さらに大きいパケット サイズが使えます。 Hardware Performance ハードウェアの性能 At this writing, individual USB 2.0 devices tend to max out at around 20 MByte/sec transfer rates. This is of course subject to change; and some devices now go faster, while others go slower. これを書いているとき、個々の USB 2.0 デバイスは、転送速度が 最大 20Mバイト/秒前後に到達しています。これはもちろん、変化することがあります; 今だと、さらに速くなるデバイスもあれば、より遅くなるデバイスもあります。 The first NEC implementation of EHCI seems to have a hardware bottleneck at around 28 MByte/sec aggregate transfer rate. While this is clearly enough for a single device at 20 MByte/sec, putting three such devices onto one bus does not get you 60 MByte/sec. The issue appears to be that the controller hardware won't do concurrent USB and PCI access, so that it's only trying six (or maybe seven) USB transactions each microframe rather than thirteen. (Seems like a reasonable trade off for a product that beat all the others to market by over a year!) EHCI の最初の NEC 実装は、全体の転送速度が、28Mバイト/秒前後で、ハードウェア のボトルネックがあるようにみえます。単一のデバイスが 20Mバイト/秒を出すために は、明らかに十分ですが、そのようなデバイス3つをひとつのバスにつないでも 60Mバイト/秒の転送速度は得られません。問題は、USB と PCI を同時にアクセスできな いコントローラハードウェアにより発生するので、13 より少ない、6 (7 かもしれない) だけの USB 処理をそれぞれのマイクロフレームで試みます。(製品のための合理的取り 引き (出荷したすべての他のものを一年以上売るため) に見えます！) It's expected that newer implementations will better this, throwing more silicon real estate at the problem so that new motherboard chip sets will get closer to that 60 MByte/sec target. That includes an updated implementation from NEC, as well as other vendors' silicon. より新しい実装が、これをより良くすることが期待されています。この問題に、 より多くのシリコン基板を投入することで、新しいマザーボードのチップセットは、 目的の 60Mバイト/秒に近い速度になるでしょう。 それは、他のベンダのシリコンと同様に NEC からの更新された実装を含んでいます。 There's a minimum latency of one microframe (125 usec) for the host to receive interrupts from the EHCI controller indicating completion of requests. That latency is tunable; there's a module option. By default ehci-hcd driver uses the minimum latency, which means that if you issue a control or bulk request you can often expect to learn that it completed in less than 250 usec (depending on transfer size). リクエストの完了を示す EHCI コントローラからの割り込みを受けるホストのために、 1マイクロフレーム (125マイクロ秒) の最短の遅延があります。遅延は、モジュール オプションで調整できます。デフォルトで、ehci-hcd ドライバは、最短の遅延を使 い、このことは、コントロールやバルクのリクエストを出した場合、 250マイクロ秒以内で完了している (転送サイズに依ります) かを、 ほぼ予測できるということです。 Software Performance ソフトウェアの性能 To get even 20 MByte/sec transfer rates, Linux-USB device drivers will need to keep the EHCI queue full. That means issuing large requests, or using bulk queuing if a series of small requests needs to be issued. When drivers don't do that, their performance results will show it. 20Mバイト/秒と同等の転送速度を得るには、Linux USB デバイスドライバが、 常に EHCI 待ち行列を一杯にしておく必要があります。それには、 大量のリクエストを発行するか、 連続した小さなリクエストを出す必要がある場合なら、バルクの待ち行列を使うか、 いずれかの手段があります。ドライバがそれを行わないなら、 実行結果に表れるでしょう。 In typical situations, a usb_bulk_msg() loop writing out 4 KB chunks is going to waste more than half the USB 2.0 bandwidth. Delays between the I/O completion and the driver issuing the next request will take longer than the I/O. If that same loop used 16 KB chunks, it'd be better; a sequence of 128 KB chunks would waste a lot less. 標準的な環境で、usb_bulk_msg() ループの書き上げた 4kバイトのかたまりは、 USB 2.0 の帯域の半分以上をむだにします。入出力の完了と、ドライバが 次のリクエストを出す間の遅延は、入出力より長いでしょう。 同じループが、16kバイトのかたまりを使うなら、より良い結果をもたらし、 128kバイトの連続したかたまりは、さらにむだをなくします。 But rather than depending on such large I/O buffers to make synchronous I/O be efficient, it's better to just queue up several (bulk) requests to the HC, and wait for them all to complete (or be canceled on error). Such URB queuing should work with all the USB 1.1 HC drivers too. しかし、同期入出力効率をあげるための大きな入出力バッファに依存するより、 HC (ホストコントローラ) に対するいくつかの (バルク) リクエストを 単に待ち行列にいれ、それらすべてが完了する (またはエラーで取消される) の を待つほうがより良い方法です。このように URB を待ち行列に入れることは、 すべての USB 1.1 HC(ホストコントローラ)ドライバでも動くはずです。 In the Linux 2.5 kernels, new usb_sg_*() api calls have been defined; they queue all the buffers from a scatterlist. They also use scatterlist DMA mapping (which might apply an IOMMU) and IRQ reduction, all of which will help make high speed transfers run as fast as they can. Linux 2.5 カーネルでは、新たに usb_sg_*() API 呼び出しが定義されました; それらは、scatterlist(散在するリスト) からのバッファをすべて待ち行列にいれます。 また、scatterlist の DMA 割り当て (IOMMU を適用するかもしれない) と IRQ の削減も使 い、それらすべては、High Speed 転送ができるかぎり高速に動けるように手助けをします。 TBD: Interrupt and ISO transfer performance issues. Those periodic transfers are fully scheduled, so the main issue is likely to be how to trigger "high bandwidth" modes. 未定 (TBD => to be determined): インタラプト転送とISO 転送の性能問題。 これら周期的な転送は完全にスケジューリングされているので、主な問題は、 "高帯域"モードを開始する方法でしょう。