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 nミリ秒ごずに凊理されたす。 次に、リンクのペアは「互いにくっ぀いお」いたす。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ハブドラむバヌ



All Articles