こんな違いを反映してか、内部構造もかなり異なる。EHCIの場合、基本的にはUSB 2.0 Deviceのみをサポートすれば済むということもあってか、構造もシンプルである。Photo01はEHCIの大雑把な内部構造である。
|
Photo01: EHCI Specification for Universal Serial Bus Revision 1.0のFigure 1-3より抜粋 |
EHCIの場合、内部でAsyncronousとPeriodicという2種類のキューを管理している。AsyncronousではControlとBulkが、PeriodicではIsochronousとInterruptの各Transferがそれぞれ管理される形だ。ちなみにPeriodicの方は、Time base windowを使って定期的な転送管理が行われるが、Asyncronousの方はラウンドロビンで管理されることになっている。で、このPeriodicとAsynchronousの2つのキューに関しては、Host側のメモリをEHCI ControllerがShared Mappingする形で共用している。ではHost側は? というと、PCI Configuration RegisterにECHIの内部レジスタをMapするBase I/O Addressが格納されており、ここからCapabilities RegistersとOperational RegistersのI/O Addressが判断できる。このOperation Registerの中にはそれぞれのキューの先頭アドレスが入っており、これを参照することで実際にEHCI Controllerが管理している2つのキューをHost側からアクセスすることも出来る。
勿論通常はEHCI Controller側がこのキューの中身を見ながら順次転送を掛け、これにあわせてキューへのポインタなどを更新してゆくわけだ。とはいえ、Deviceの追加とか削除、Transfer Scheduleの更新などはHost側の(実際にはEHCI Base Driverの)お仕事である。
これがxHCIになるとどう変わるか? というのがPhoto02である。当たり前だがPCI Configuration Spaceにマッピングされている部分は大きくは変わらない。強いて言えば、xHCIはPCI Expressが前提となっているため、PCI Configuration Spaceも最初からPCIeを前提としたものになっているのが異なるところだ。ただ、そこから先は随分異なる。まずCapabilities RegistersとOperation Registersに加え、xHCI Extended Capabilities RegistersとRuntime Registers、Doorbell Arrayといったものが追加されている。
|
Photo02: xHCI Interface for USB Revision 1.0のFigure 3より抜粋 |
まずxHCI Extended Capabilities Registersだが、EHCIの場合Capabilities Registersは、
| CAPLENGTH(8bit) | Capabilities Registerのサイズ |
|---|---|
| Reserved(8bit) | 無し |
| HCIVERSION(16bit) | Interface Version Number |
| HCSPARAMS(32bit) | Structual Parameters |
| HCCPARAMS(32bit) | Capabilities Parameters |
| HCSP-PORTROUTE(64bit) | Companion Port Route Description |
といった構造になっており、一方xHCIは、
| CAPLENGTH(8bit) | Capabilities Registerのサイズ |
|---|---|
| Reserved(8bit) | 無し |
| HCIVERSION(16bit) | Interface Version Number |
| HCSPARAMS1(32bit) | Structual Parameters1 |
| HCSPARAMS2(32bit) | Structual Parameters2 |
| HCSPARAMS3(32bit) | Structual Parameters3 |
| HCCPARAMS(32bit) | Capabilities Parameters |
| DBOFF(32bit) | Doorbell Offset |
| RTSOFF(32bit) | Runtime Register Space Offset |
| Reserved(不定) | 無し |
といった具合に、大幅に拡張されている。もともと通信ハンドリング方式が異なるから、例えばEHCIのドライバを持ってきて、xHCI ControllerをUSB 2.0のみで使うといった形の互換性はそもそも考慮されていない(現実問題として不可能)だが、一応Registerの構造は似せる努力はしているようだ。続くStructual Parameterは名前の通り「構造」を示す部分で、EHCIの場合はここにDownstream Portの数とかDebug Portの番号、1つのCompanion Controllerあたり接続されるポート数といった、基本的な構造が含まれているわけだが、xHCIでは内部構造を大幅に拡張したため、ここで示すべき項目もまた大幅に増えており、結果としてレジスタが3つも並ぶことになっている。続くCapabilities Parameterは「能力」を示すものであるが、これもxHCIでは大幅に拡張されており、到底レジスタ1個では収まらなくなった。そこで、32bitレジスタの前半には色々な能力(例えば64bit Memory Pointerをサポートしているか否か、とかBandwidth Negotiationの機能を持っているか否か、など)をbit fieldで細かく示しているが、ここに収まりきらなかった分はxHCI Extended Capabilitiesという別レジスタで示すことにし、ここへのポインタを後半16bitで示している。
(続く)
