KolibriOSでのUSBサポート：内部には何がありますか？ パート2：ホストコントローラーの操作の基本

ホストコントローラーのサポートコードを説明する前に、鉄がどのように機能するかの原則と、使用されるデータ構造について話す必要があります。 テキストを書いているときにわかったように、ホストコントローラーのサポートレベル全体に関する1つの記事が大きすぎるため、今読んでいるサイクルの2番目の部分では、コードを理解するために知っておくべきことと、コードで発生するアクションの説明について説明します。次の部分に延期します。

割り込みとスレッド

ホストコントローラーは、発生するイベントをソフトウェアに通知し、割り込みを生成します。 割り込みが発生すると、いつでも現在のタスクからプロセッサが切断されます。 これにより、割り込みハンドラに厳しい要件が課されます。 割り込みハンドラーはロックをキャプチャーできません-割り込みされたコードがロックを所有し、ロックを解放できなくなった可能性があります。 唯一の例外はスピンロックオプションです。これはロック期間中の割り込みを禁止しますが、グローバル効果のため、スピンロックはコードの非常に短いセクションにはあまり使用しないでください。 シングルプロセッサ構成では、このオプションはスピンロックなしでcli / stiペアに縮退します;マルチプロセッサcli 、通常のスピンロックはcli / sti内に残ります。 さらに、1つの割り込みの処理中の割り込みコントローラーは、同じまたはより低い優先度で他の割り込みをブロックします。

これら2つの理由により、KolibriOSでは、USBホストコントローラーからの割り込みハンドラーは、USBストリーム専用のカーネルに作業の大部分を転送し、ホストコントローラーへの「ありがとう、信号を受信しました」というメッセージに制限されます。 思いやりのあるユーザーアプリケーションが処理を妨げないように、USBストリーム自体が最高の優先度を持っています。 ホストコントローラーから呼び出される上位レベルのすべての機能は、USBストリームのコンテキストでのレベル作業をサポートし、その結果、同期プリミティブを非常によく使用できます。 良い副作用は、呼び出しの自動シリアル化です：チャネルキューからの2番目の転送を完了するためのハンドラーも、チャネルキューからの最初の転送を完了するためのハンドラーが完了するまでDeviceDisconnected関数も呼び出されません。これは論理API要件です。

USBストリームは、時間遅延イベントを処理するために起動することもあります。 例については後で詳しく説明します。デバイス接続イベントの後、100ミリ秒待ってからさらに処理する必要があります。 この場合、スレッドはデバイスの接続を検出するとウェイクアップし、100ミリ秒後に次のウェイクアップをスケジュールします。これは、中断によるウェイクアップに関連付けられなくなりました。

データ構造

ホストコントローラーのサポートレベルでは、コントローラーデータ構造*_controller 、チャネルデータ構造*_pipe 、 *_pipeアイソクロナス転送データ構造*_gtd構造が*_gtdです。 それらはそれぞれ、ホストコントローラー*hci_*固有の部分と、すべてのusb_*コントローラーに共通の2つの部分で構成されています。 ホストコントローラーは、その構造のアライメントが必要です。 コントローラーデータは、ページアラインメント、つまり1000hバイトを使用します。 他のデータの配置は、コントローラーによって異なります。

KolibriOSでは、各構造の両方の部分が順次メモリに保存されます。 両方の構造のメモリは、必要なアライメントを考慮して、1ステップで割り当てられます。 メモリの最初の部分は、ホストコントローラと通信して位置合わせを保証する部分です。 両方の部分に対処するために、部分間の境界を指す単一のポインターが使用されます。 負のオフセットの場合は*hci_*データ、非負のオフセットの場合はusb_*データです。 usb_controllerへのポインターは、 esiレジスタに常に配置されます。 チャネルusb_pipeはusb_pipeへのusb_pipeです。 usb_pipeフィールドの1つは、対応するusb_controllerへのポインターusb_controller 。

構造にメモリを割り当てるコードは、両方の構造のサイズと必要なアライメントを知っている必要があります。 *_controller場合、ページ境界へのアライメントを自動的に保証するページネーションアロケーターが使用されます。 アロケーターはusb_controller担当するコードによって呼び出され、構造体のサイズ*hci_controllerはusb_hardware_func.DataSizeからusb_hardware_func.DataSizeされusb_hardware_func.DataSize 。 概要でusb_hardware_funcように、 usb_hardware_funcは、ホストコントローラーに固有の事柄を残りのコードに記述します。
*_pipeおよび*_gtd場合、各インスタンスにページを割り当てることは非常に無駄であり、小さなブロックに共通のカーネルヒープを使用することは、アライメント要件のために不便です。 したがって、それらの場合、コードは固定サイズのブロックアロケーターを使用します。このアロケーターは、ページを選択すると、ページを所定のサイズのブロックに分割し、それらを1つずつ与えます。 割り当てられたサイズが、たとえば16バイトの倍数である場合、すべての割り当てられたブロックは16のアドレス倍数になります。ここで、アロケーターはサイズごとに個別のデータを必要とします。 これらすべてをusb_hardware_func構造に含めないように、後者には*_pipe構造のペアのAllocPipe / FreePipe割り当て/リリースFreePipeと*_pipe構造のペアのAllocTD / FreeTDれています。

ホストコントローラーは、すべての構造を操作するために、すべての構造の物理アドレスを知る必要があります。 *hci_controller構造体のアドレスは、コントローラーの初期化中に入力されます。 非アイソクロナス転送のデータ構造のアドレスは、 *hci_pipe内の最初の要素の物理アドレスと*hci_gtd内の次の各要素の物理アドレスを含む単一リンクリストに収集されます。



チャネルはいくつかのリストにグループ化されます。 各リストの中には、3つの接続があります。ハードウェアの次のチャネルの物理アドレス、ソフトウェアの次と前のチャネルの仮想アドレスです。 1つのリストは、制御伝送用のすべてのチャネルで構成されます。 別のリストは、データ配列を送信するためのすべてのチャネルで構成されています。
図に示すように、割り込みチャネルのリストはバイナリツリーで構成されています。円は割り込みチャネルのリストを示し、矢印は次の要素の物理アドレスを示します。 ホストコントローラーは、フレーム番号の下位nビット（EHCIであってもフレームのみ）を取得することにより、各時間単位（UHCIおよびOHCIのフレーム、EHCIのマイクロフレーム）を開始し、 *hci_controller一部であるアドレステーブルの対応する要素を*hci_controller 。次の要素へのリンクをたどり始めます。 したがって、最初のリストは2 ⁿミリ秒ごとに処理されます。 次に、リンクのペアは「互いにくっついて」います。2つのリンクが次のリストにつながり、次のリストが2 ^n-1ミリ秒ごとに1回、アドレステーブルの全サイクルで2回コントローラーの注意を引きます。 最後に、ミリ秒ごとに要素が処理されるリストがあります。 このような割り込みチャネルの編成により、ミリ秒単位で2の累乗で表される処理間隔でチャネルを実装できます。 USB仕様により、実際のポーリング間隔を要求よりも短くすることができます。

EHCIでは、計画単位はマイクロフレームであり、フレームの8分の1です。 ただし、チャンネルリストのウォークは、フレーム番号によってガイドされます。 したがって、各割り込みチャネルには、各ビットがフレーム内の1つのマイクロフレームに対応する8ビットのビットマスクがあり、ビットの値が0の場合、リンクのウォークスルーが即座に継続されます。 一部のチャネルには、単一ビットで交差しない2つのマスクがありますが、後でさらに詳しく説明します。

アイソクロナス転送のサポートは現在開発中です。現在のところ、ハードウェアについて少し説明します。 OHCIでは、アイソクロナス転送は他の転送と同様にアドレス指定されますohci_pipeには、送信データ構造のフォーマットを担当するビットがあり、アイソクロナスと残りは異なるフォーマットを使用します。 UHCIとEHCIには、アイソクロナスチャネル自体のデータ構造がないため、アイソクロナス伝送構造が割り込みチャネル構造とともにアドレステーブルに挿入されます。 コントローラーがアドレスがチャネルを指すのか、アイソクロナス伝送（実際には2つの異なるタイプがある）を指すのかを理解できるように、アドレスの2ビットがこのアドレスにある構造のタイプに割り当てられます。 その結果、UHCIおよびEHCIの数nは10ですが、1秒以上のポーリング間隔をサポートしませんが、アイソクロナス転送のフラグメントを処理した後、ソフトウェアは次のフラグメントを要求するための秒を持ちます。 OHCIではn = 5。

転送とトランザクション

ギアの下のUSBアーキテクチャプロトコルはほとんど面白くありませんが、ドライバーレベルより下のレベルを実装するときに、それらについて知っておく必要があることがいくつかあります。
USBバス上の転送サイズはほぼ無制限です。 1つのデバイスがバスを長時間使用しないように、転送はトランザクションに分割されます。 あるトランザクションでは、制限された長さの次のデータが送信されます。 最大トランザクション長は、チャネルの特性の1つです。 1つの転送ステージ（コントロール転送は2つまたは3つのステージで構成され、残りは1つのステージから構成されることを思い出してください）では、最後を除くすべてのトランザクションのサイズが最大になります。 最後のトランザクションは残りのデータを転送し、残りよりも短い場合があります。

*_gtd構造の1つのペアが記述できるデータのサイズも制限されています。 すべてのデータが1つの*_gtd収まらない場合、転送をいくつかの部分に分割する必要があります。 デバイスの観点から、発生していることが1つの送信に残るように、つまり最後の部分を除くすべての部分のサイズを最大トランザクションサイズで割るように、分割場所を選択する必要があります。

UHCIは、Intelが作成した年代順の最初のインターフェイスです。 UHCIは、ハードウェア実装の単純さに焦点を当てています。 その結果、UHCIコントローラーは転送について何も認識せず、1つのuhci_gtd構造体が1つのトランザクションを記述します。 大規模な転送の場合、これにより、すべてのトランザクションで個別のメモリの大きなオーバーヘッドが発生します。
OHCIとEHCIでは、コントローラーはすでに長い転送をトランザクションに独立して分割することができます。ここでは制限が弱くなっています。 ohci_gtdは2ページのデータ用の2つのフィールドがあり、最良の場合は2000hバイト、最悪の場合（データがアドレスxxxxxFFFh始まる場合）-1001hバイト= 4キロバイト+ 1バイトです。 ehci_gtdはすでに5ページが配置されており、最悪の場合、4001hバイトの制限があります。 さらにデータがある場合、送信をいくつかのフラグメントに分割する必要があります。

USB2では、 スプリットトランザクションが登場しました。 USB2仕様は、480メガビット/秒（高速、HS）の新しいデータ転送速度を追加しましたが、2つの速度USB1、12メガビット/秒（フルスピード、FS）および1.5メガビット/秒（低速、LS ）を引き続きサポートします） 一度に1つのUSBバスで、1つのデバイスとのみ通信できます。 USB1では、1つのホストコントローラーによって制御されるバスは均一であり、LSデバイスへのトランザクション中（12メガビット/秒対応）、1.5メガビット/秒の速度で動作しました。 USB2では、同じ方法でHSバスを遅くすることは実用的ではないため、常に高速で動作する1つの共通バスと、FS / LSデバイスが接続される複数のFS / LSバスがあります。 バス間の通信は、低速デバイスが接続されているハブの役割です。 仕様では、 Transaction Translator（TT）ハブの対応する部分に名前を付けています。

ハブが低速バス上の低速デバイスとゆっくりと通信している間、高速バスは無料で、かなりの時間使用できます。 受信時間を適切に使用できるように、HSバス上のトランザクションは、初期（ 開始-分割トランザクション ）と最終（ 完全-分割トランザクション ）の2つに分割されます。



分割の詳細は、定期的なトランザクション（割り込みおよびアイソクロナス送信）と非定期（制御送信およびデータアレイ送信）でわずかに異なります。 上の図は、定期的なスプリットトランザクションのハブ内で行われていることの図を示しています。 良いニュース：非定期的なトランザクションの場合、追加のサポートアクションは最小限です-チャネル構造を適切に初期化する必要があり、HSバスに障害が発生した場合、ハブデータバッファーをクリアし、残りはコントローラー自体によって監視されます。 定期的なトランザクションの場合、すべてがより複雑です。 ここから、前述の割り込みチャネル構造の2番目のビットマスクが発生します-FS / LSデバイスの割り込みチャネルの場合、最初のビットマスクは最初の分割トランザクションを開始する必要があるマイクロフレームを担当し、2番目は最終を開始する必要があるマイクロフレームを担当します分割トランザクション。 ここから、EHCIに2番目のタイプのアイソクロナストランザクションが表示されます。通常のアイソクロナストランザクションとスプリットアイソクロナストランザクションの構造は異なります。

EHCIと仲間

USB2用のホストコントローラーを設計する際に、可能であれば、IntelはUHCI / OHCIハードウェアおよびソフトウェアサポートの形式で既存のベースを使用することを決定しました。 EHCIルートハブにはTransaction Translatorはありません。 代わりに、各ポートをコンパニオンコントローラに接続できます。UHCIまたはOHCIにできます。 複数のパートナーが存在する場合があります。 EHCIコントローラーが初期化されていない限り、すべてのポートはコンパニオンに接続されます。 UHCIとOHCIをプログラムできるコードは、すべてのデバイスとこの構成で、当然USB1の速度で動作できます。 EHCIコントローラーを初期化した後、各ポートに他のポートとは無関係に所有者を割り当てることができます。 非所有者コントローラーは、「デバイスなし」状態のポートを認識します。 デバイスが実際に存在しないポート、およびHSデバイスのあるポートは、EHCIコントローラーに割り当てられます。 低速デバイスのポートは、コンパニオンコントローラーに割り当てられます。



Intelは後に、EHCIの隣にUHCIを配置することをもはや望まないと判断しました。 仕様をやり直さず、ドライバーの書き換えを強制しないために、Intelはコントローラーを変更しませんでしたが、「実際の」ポートからコントローラーへの途中で、公式名Rate Matching Hub（RMH）の 「仮想」ハブをインストールし、コントローラー用に2つのポートのみを残しましたそのうちの1つは常にハブに接続されます。 残念ながら、2番目のポートの目的はわかりませんでした。 ソフトウェアの観点からは、「仮想」ハブは通常のものと変わりません。実装を作成するときは、一部の構成でデバイスにアクセスするには、EHCIサポートだけでなくハブサポートも実装する必要があることに注意してください。

シリーズのすべての記事

パート1：概要
パート2：ホストコントローラーの操作の基本
パート3：ホストコントローラーサポートコード
パート4：チャネルサポートレベル
パート5：論理デバイスレベル
パート6：ハブドライバー