概要で説明したように、ホストコントローラーのサポートレベルは、特定のイベントが発生したときに高いレベルを引き起こし、高いレベルが機能するために必要な機能を提供するはずです。

便宜上、サポートコードのさまざまな要素について、制御を受ける順序で説明します。

USBサブシステムの起動

準備：PCIデバイスのリストにあるUSBコントローラー

USBサブシステムは、システムの起動中にusb_init



からusb_initを呼び出すことで開始されます。



USBが起動するまでに、見つかったpcidev_list



PCIデバイスのリストはすでに準備されています。 USBコントローラは、クラス、サブクラス、およびインターフェイスコードによってすべてのPCIデバイス間で認識されます。

種類	クラス	サブクラス	インターフェース
UHCI	0Ch	03h	00h
OHCI	0Ch	03h	10時間
エーチ	0Ch	03h	20時間
Xhci	0Ch	03h	30時間

usb_init



は、USBデバイスを強調表示するたびに、PCIデバイスのリストを数回usb_init



ます。

BIOSコントロールを無効にする

一部のBIOSは、USBマウス、USBキーボード、およびUSBフラッシュドライブを処理でき、USBを知らないオペレーティングシステムにデータを提供します。 マウスとキーボードからのデータはPS / 2形式に変換され、何らかの方法でオペレーティングシステムに持ち込まれます。これは、システムに実際のPS / 2マウスやキーボードが存在する場合と同じです。 int 13h



の観点からは、USBフラッシュドライブはハードドライブのように見えます。このようなサポートは、フラッシュドライブからダウンロードするために必要なため、マウスのサポートよりも頻繁に見つかります。

オペレーティングシステムは、任意のプロセッサモードを使用して、それ自体で中断を処理できます。 このような条件下でBIOSが予測可能な環境で制御できるように、486に戻って（正確にはi386SLの特別なバージョンから）、IntelはBIOSが動作して動作を中断する特別なプロセッサモードSystem Management Mode（SMM）を考案しましたシステム。 プロセッサ自体を使用してSMMに入ることは不可能です。 マザーボードハードウェアが特別なシステム管理割り込み（SMI）信号を送信すると、プロセッサはこのモードに入ります。 原則として、チップセットに組み込まれたUSBコントローラーは、設定に応じて、中断する代わりにSMIを生成できます。



pcidev_list



の最初のパスは、USBコントローラーがオペレーティングシステムの制御下にあることをBIOSに伝えることです。したがって、BIOSはそれらに対して何もしません。



このパスでは、すべてのコンパニオンがペアのEHCIコントローラーに処理されることが重要です。 たとえば、昇順のPCI座標を走査すると、これが保証されます。 コードの最初のバージョンでは、このパッセージは個別に割り当てられず、すべてのEHCIコントローラーが最初に処理されました。 これは多くの構成で機能しましたが、 テスト中にすべてのBIOSが正しく書き込まれているわけではなく、間違った順序でSMM内のシステムがクラッシュする可能性があることがわかりました。 具体的には、次のシナリオが可能です。

• BIOSはEHCIシャットダウン要求を検出します。
• BIOSはコントローラーを構成解除し、それを忘れます。
• ポートの所有権が仲間に移転
• ポートに接続されたフラッシュドライブもコンパニオンに移動します。
• コンパニオンは新しいデバイスに信号を送ります。
• コンパニオンはまだBIOSの制御下にあるため、デバイスを独自のものと見なし、デバイスの種類を調べます。 古いフラッシュドライブが表示されます。
• そして、USBフラッシュドライブについて、BIOSは、それがコントローラ上にあったことを記憶していることがわかりました。 忘れられたコントローラーのデータを使用しようとすると、すぐに悲しい結果につながります。

EHCIの前にコンパニオンを処理すると、このシナリオの可能性がなくなります。



コントローラを譲渡する必要があることをBIOSに報告する方法は、コントローラによって異なります。 対応する関数は{u,o,e}hci_kickoff_bios



と呼ばれます。 UHCIは時系列的に最初のインターフェイスであるため、特別なメッセージを提供しないため、 uhci_kickoff_bios



単にSMI生成をオフにし、コントローラーを停止します。 OHCIおよびEHCIでは、BIOSと通信する手順は理論的に仕様で説明されていますが、実際には...詳細があります。 どちらの場合も、手順は次のとおりです。あるレジスタにあるビットを設定し、別のビットの目的の状態を待ちます。 BIOSがコントローラーで動作する場合、コントローラーはSMIを生成し、プロセッサーはSMMに切り替えてBIOSを呼び出し、BIOSはコントローラーを解放し、他のビットを目的の状態にして、SMMを終了します。 OHCIの手順の詳細は、 テスト中に判明したため、BIOSが割り込みソースをオンにしたままコントローラーを放置する可能性があることです。 イベントが割り込みを生成し、OHCIドライバーがそのハンドラーをインストールする前に割り込みが割り込みコントローラーでマスクされている場合、システムは再びハングします-OHCIは何度も割り込みを生成しますが、これは誰も処理しません。 したがって、 ohci_kickoff_bios



は、BIOSとの会話中の割り込みを禁止し、会話の終了時にすべてのOHCI割り込みソースをオフにします。 EHCIでは、実際に「オペレーティングシステムがコントローラーの所有権を要求しました」というビットを実際に設定することはできません。まず、BIOSがコントローラーを所有していることを確認する必要があります。 一部のBIOSは、システムを起動する前でもコントローラーを「解放」し、それを忘れ、SMI生成ビットを削除せず、要求を処理できません。SMIが何度も生成されるため、システムは再びハングします。

コントローラーの初期化

最初のパスでusb_init



がUSBコントローラーを検出しない場合、作業を停止します。 USBコントローラーがある場合、 usb_init



はUSB処理に割り当てられたストリームを作成し、PCIデバイスのリストをさらに2回パスし、各USBコントローラーに対してusb_init_controller



を呼び出し、 usb_hardware_func



適切なusb_hardware_func



構造体へのポインターを渡します。 2番目のパスはEHCIを処理し、3番目のパスはUHCIとOHCIを処理します。 ここでEHCIはコンパニオンの前で処理されるため、HSデバイスはコンパニオンに自分自身に信号を送ってすぐに彼から奪われるのではなく、EHCIの制御下にあります。



usb_init_controller



関数はhccommon.incにあります。 *hci_controller



/ usb_controller



ペアにメモリを割り当て、両方をゼロで初期化し、 usb_controller



フィールドを初期化します。そのうちusb_hardware_func



指すHardwareFunc



個別に記録する必要があります。 さらに、コントローラー固有のusb_hardware_func.Init



初期化も呼び出します。 最後のアクションでエラーが発生しなかった場合、 usb_init_controller



はコントローラーを一般的なusb_init_controller



登録し、USBストリームを起動して、次の起動時間に関する情報を更新できるようにします。



usb_hardware_func.Init



の特定の初期化はusb_hardware_func.Init



ことを行います。

• 割り込みチャネルのバイナリツリーなど、チャネルグループとそれらの間の関係を構成します。
• コントローラー*hci_irq
  
  
  
  から割り込みハンドラーをインストールします。
• *hci_controller
  
  
  
  構造体の物理アドレスの書き込みを含む、正しい値をホストコントローラーのレジスターに書き込みます。
• usb_controller.NumPorts
  
  
  
  ポート数を計算し、すべてのポートに電力を供給します。

割り込みチャネルのバイナリツリーは、すべてのコントローラーで同じ構造を持っています 。 前の記事で説明しました。 残りのタイプのチャネル間の接続は、コントローラーによって異なります。

チャネル間の通信：UHCI

UHCIは、年代順で最も単純なハードウェアを備えた最初のコントローラーです。 UhciBaseAddressReg



のテーブルを指すポインターUhciBaseAddressReg



1つだけあります。 各フレーム鉄は、テーブルの対応する要素をロードし、リンクをたどり始めます。 定期的な送信のチェーンの最後は、各フレームで処理される割り込みチャネルのリストです。 リストの最後のチャネルから、リンクは制御伝送のリストの最初のチャネルにつながります。 制御伝送のすべてのチャネルとデータ配列の伝送は、リングで接続されています。 コントローラーがすべての非周期的チャネルの処理を完了すると、コントローラーは非周期的チャネルのリストの先頭に戻ります。 このスキームでは、次のフレームを待たずに、新しい非周期的な送信がすぐに処理され始めます。



この方式の明らかな利点は、処理の優先順位に関するUSB​​仕様の要件に完全に準拠しながら、アイロンがシンプルであることです。 短所：重い負荷では、コントローラーがフレームの終わりまですべての転送を処理する時間がないとき、同じタイプのチャンネルは等しくありません-リストの最上位にいる幸運な人は大きな利点を受け取ります-そして、小さな負荷ではコントローラーは常にメモリからの読み取りに忙しいです新しい仕事がないことを確認します。 次のコントローラーの開発者は、UHCIの欠点を考慮しました。

チャネル間の通信：OHCI

OHCIには7つの整数レジスタがあり、そのうち6つはチャネルに関連付けられています。 OhciHCCAReg



のレジスタの1つは、他のコントローラー（アイソクロナス転送用に調整）と同様の周期チャンネルのテーブルを指し、2番目のOhciPeriodCurrentEDReg



は現在の周期チャンネルを示しているため、図には示されていません。



制御チャネルとデータ配列のチャネルは、独立したリストに収集されます。 各リストには2つのポインターがあります。リストの先頭へのポインターOhci{Control,Bulk}HeadEDReg



と、現在のチャンネルOhci{Control,Bulk}CurrentEDReg



へのポインターです。 コントローラーは、互いに独立して3つのリストで移動できます。 優先度リストはUSB要件に沿っています。 各フレームコントローラーは定期的なチャンネルのリストを実行しますが、UHCIとは異なり、他のリストの位置を失うことはありません。したがって、同じリスト内のすべてのチャンネルは等しくなります。 これにより、UHCIの最初のマイナスが閉じられます。 OHCIレジスタには、「リストに新しい伝送があります」という2ビットもあります。1つは制御チャネルのリスト、もう1つはデータ配列のチャネルのリストです。ソフトウェアは新しい伝送を追加するときに対応するビットを設定する必要があります。 コントローラがリストの検索を開始すると、ビットがリセットされます。 コントローラがリストの最後に到達すると、ビットを確認します。 ビットが設定されている場合、コントローラーはリストの先頭に移動し、そうでない場合はリストの処理を停止します。 これにより、UHCIの2番目のマイナスが閉じられます。

チャネル間のリンク：EHCI

EHCIは2つのポインタレジスタに制限されています。 それらの1つであるEhciPeriodicListReg



、他のコントローラーと同様に、周期的なチャネルのテーブルを指します。 別のEhciAsyncListReg



は、現在の非周期的なチャネルを指します。 非周期的なチャネルはすべてリングで閉じられますが、これは可能な実装の1つであるUHCIとは異なり、これが前提条件です。 周期的チャネルと非周期的チャネルに沿ったウォークは互いに独立しているため、すべての非周期的チャネルが等しくなります。 インテルは、ここでデータ配列チャネルに対する制御チャネル特権の要件を無視することにしました。 コントローラーは、非周期的なチャネルで作業がない場合、メモリからの無限の読み取りにあまり熱心ではないため、リング内のチャネルの1つがリングの「開始」としてマークされます。 コントローラーがアクティブなギアを検出せずにリングの「開始」に2回会うと、コントローラーはしばらくリングの処理を停止します。

USBデバイスの操作

デバイスのさまざまな状態とそれらの間の遷移を説明するUSB​​仕様の写真：

デバイス接続

初期化中に、OHCIおよびEHCIコントローラーは、デバイスが接続または切断されたときに割り込みを生成するように構成されます。 UHCIでは、残念ながらこれは不可能です。したがって、UHCIコントローラーでは、USBストリームが定期的に自動的に起動し、コントローラーポートをポーリングして、接続状態の変化をチェックします。 ポーリング間隔はUHCI_POLL_INTERVAL



タイマーティックで、現在の値では1秒です。



接続されたUSBデバイスは、電源が入った状態でホストコントローラーとの対話を開始します。



新しいUSBデバイスの初期化は、100ミリ秒の一時停止で始まります。 USBデバイスは動的に接続されるため、接続すると、連絡先のチャタリングや、いくつかの連続した接続/切断イベントが発生する可能性があります。 同じポートで新しいイベントが発生するたびに、カウントダウンが再開されます。 Powered状態が連続して100ミリ秒続くと、接続は安定していると見なされ、コードは次の初期化ステージ*hci_new_port



ます。



少し後で説明する理由により、接続を処理する次のいくつかの段階は、いくつかのデバイスに対して並行して実行することはできません。 したがって、次の手順の前に、新しいUSBデバイスは、現在のデバイスがこれらの手順をすべて完了するまで待機する必要があります。 待機の終了は*hci_new_port.reset



でマークされます。これは、待機が不要であることが判明した場合に*hci_new_port



内部関数の一部であり、同時にusb_hardware_func.InitiateReset



より高いレベルのインターフェースに配置されます。



次に、 *hci_new_port.reset



コードは、新しいデバイスのポートのリセット信号を有効にする*hci_new_port.reset



コントローラーに*hci_new_port.reset



ます。 仕様によると、リセットは少なくとも10ミリ秒続く必要があります。 OHCIはそれ自体で時間をカウントし、インターバルの終わりにリセット信号をオフにして割り込みを生成します。割り込みのハンドラーはUSBストリームに信号を送り、次のステージに進みます。 UHCIとEHCIでは、プログラムで時間を読む必要があります。 アイドルスタンバイサイクルでプロセッサをロードしないために、リセット信号をオンにした後のUSBストリームは、システムタイマーに従って起動し、スリープ状態になる予定です。 KolibriOSのタイマーは、10ミリ秒ごとに1回、100 Hzの周波数で作動します。 最低10ミリ秒のリセットを保証するために、コードは2つのタイマーサンプルを待機します。 タイマーの2番目のティックの後、コードは新しいデバイスのポート*hci_port_reset_done



のリセット信号をオフにし、次のステップに進みます。



USB2では、リセットプロセスがデバイスの速度を決定します。 EHCIはHighSpeedデバイスでのみ動作し、USB1速度のいずれかで動作するすべてのデバイスはUSB1コンパニオンまたはハブに転送される必要があることを前のパートから思い出します。 ソフトウェアの観点からは、リセットの終了後、EHCIはポートへのデータ転送を許可するかどうかを決定します。 リセット後にポートが無効のままになっている場合、接続されたデバイスはUSB2の速度で動作しません。 この場合、コンパニオンへのポート転送の所有者を選択するロジックに通知するだけです。 その後、コンパニオンは通常の接続イベントを確認して処理します。



リセット後、多くのデバイスはすでにより高いレベルで設定する準備ができています。 しかし、すべてではありません。 仕様では、リセット後少なくとも10ミリ秒の一時停止が必要です。 テストが示すように、一部のデバイスでは実際にこの一時停止が必要です。 前のステップと同様に、USBストリームは2つのタイマーカウントでスリープ状態になりますが、今回はOHCIを含むすべてのコントローラーに対してです。



リセットとそれに続く一時停止の後、デバイスは電源が入った状態からデフォルト状態に切り替わります。デバイスがゼロエンドポイントのデータを送受信する準備ができているが、まだ完全に初期化されていないときの2つの「ハーフワーキング」状態の1つです。 デフォルト状態では、デバイスはUSBバスのゼロアドレスに応答します。 これが、2つのデバイスのリセットを並行して実行できない理由です。そうしないと、2つのデバイスが判明し、それぞれが後続の設定が特に適用されると考えられます。



デバイスのゼロエンドポイントが動作する準備ができました。チャネルを開くときです。 チャネル構造には、チャネル自体の特性（たとえば、タイプ）とデバイス特性（デバイス速度、バス上のデバイスアドレス、 usb_controller



へのポインター）がusb_controller



ます。 この段階で呼び出される*hci_port_init



コードは、 usb_hardware_func.NewDevice



ハブのAPIで作成される*hci_new_device



関数の操作を委任します。 後者は、デバイスの特性が正しく満たされる擬似チャネル構造を準備し、チャネルの特性の値は重要ではありません。 これで、ホストコントローラーサポートコードは独立したアクションを完了し、論理デバイスレベルのusb_new_device



関数に制御を移します。 さらに、デバイスの電源がオフになるまで、ホストコントローラーサポートコードはより高いレベルからのリクエストのみを実行します。

チャンネル開設とチャンネル送信

コントローラーの観点から見ると、送信記述子のキュー（1つの記述子は送信全体、またはコントローラーに応じて一部）が単一リンクリストとして編成され、最初の記述子の物理アドレスはチャネル構造にあり、次の記述子の物理アドレスは前の記述子にあります。 コントローラーが1つのディスクリプターの処理を終了すると、次のディスクリプターのアドレスをそこに書き込むことにより、チャネル構造を更新します。 伝送キューが実行されている場合、ホストコントローラーサポートコードは、ハードウェアとの競合状態を回避するために、次の記述子自体のアドレスを更新できません。 作業を整理するには、キューの最後に追加の空の記述子が必要です。 空のハンドルは、コントローラーに対して非アクティブとしてマークされます。 コードが記述子を追加する場合、現在の空の記述子を埋め、次の空の記述子を選択し、古い記述子に新しい記述子へのリンクを配置し、最後のアクションで古い記述子をアクティブにします-これはすべて、コントローラーとレコードを交差させません。 コントローラーが非アクティブな記述子に達すると、キューの処理を停止し、チャネル構造内に非アクティブな記述子へのリンクを残します。



空の記述子の必要性を認識した後、チャネルを開いて送信をキューに入れるのはかなり簡単です。 usb_hardware_func.InitPipe = *hci_init_pipe



を開くときusb_hardware_func.InitPipe = *hci_init_pipe



次のものが必要です。

• 既存のチャネルまたは擬似チャネルからデバイス特性をコピーします。
• 送信されたデータに基づいてチャネルの特性を入力し、
• 空の記述子の物理アドレスをチャネル構造に登録します。
• 空の記述子を非アクティブとして初期化します。
• 最後のステップは、対応するリストにチャネルを挿入することです。

定期的なチャネルの場合、目的のリストを選択する必要があります。 これはプランナーのタスクであり、次の記事で説明します。 キューへの転送の追加は、転送usb_hardware_func.AllocTransfer = *hci_alloc_transfer



1ステージの充填記述子に分割されます。これは、制御転送のために2回または3回呼び出され、転送usb_hardware_func.InsertTransfer = *hci_insert_transfer



アクティブ化のためにusb_hardware_func.InsertTransfer = *hci_insert_transfer



ます。 AllocTransfer



, . InsertTransfer



.



IOC, Interrupt on completion. IOC, . - .

OHCI - , ( IOC) : , . ohci_controller



, , . OHCI «» , .

UHCI EHCI , UHCI EHCI , , , .

USB, *hci_process_finalized_td



. — , ; . — , callback- , .

. , , — ( « » ). , usb_hardware_func.SetDeviceAddress



: . , usb_hardware_func.SetEndpointPacketSize



: . UHCI — , , . , . , . EHCI , , , . , : , , , , .



OHCI EHCI , , . , . OHCI . EHCI Interrupt on Async Advance Doorbell : « , » . , . , .

: — OHCI EHCI, UHCI — usb_device_disconnected



, . , 100 , .

1:

2: -

3: -

4:

5:

6: