JavaScript is required to for searching.
ナビゲーションリンクをスキップ
印刷ビューの終了
デバイスドライバの記述     Oracle Solaris 11.1 Information Library (日本語)
このドキュメントの評価
search filter icon
search icon

ドキュメントの情報

はじめに

パート I Oracle Solaris プラットフォーム用デバイスドライバの設計

1.  Oracle Solaris デバイスドライバの概要

2.  Oracle Solaris カーネルとデバイスツリー

3.  マルチスレッド

4.  プロパティー

5.  イベントの管理とタスクのキュー

6.  ドライバの自動構成

7.  デバイスアクセス: プログラム式入出力

8.  割り込みハンドラ

9.  ダイレクトメモリーアクセス (DMA)

10.  デバイスメモリーおよびカーネルメモリーのマッピング

11.  デバイスコンテキスト管理

12.  電源管理

13.  Oracle Solaris ドライバの強化

14.  階層化ドライバインタフェース (LDI)

パート II 特定の種類のデバイスドライバの設計

15.  文字デバイスのドライバ

16.  ブロックデバイスのドライバ

17.  SCSI ターゲットドライバ

18.  SCSI ホストバスアダプタドライバ

19.  ネットワークデバイスのドライバ

20.  USB ドライバ

Oracle Solaris 環境での USB

USBA 2.0 フレームワーク

USB クライアントドライバ

クライアントドライバのバインド

USB デバイスがシステムからどのように見えるか

USB デバイスと Oracle Solaris デバイスツリー

互換デバイス名

複数のインタフェースを備えたデバイス

インタフェース関連付け記述子を含むデバイス

デバイスドライバのバインディングのチェック

基本的なデバイスアクセス

クライアントドライバが接続される前

記述子ツリー

デバイスアクセスを取得するためのドライバの登録

デバイス通信

USB エンドポイント

デフォルトパイプ

パイプの状態

パイプのオープン

パイプのクローズ

データ転送

同期および非同期転送とコールバック

要求

パイプのフラッシュ

デバイス状態管理

USB デバイスのホットプラグ

ホットプラグコールバック

電源を入れたまま挿入

電源を入れたまま取り外し

電源を入れたまま再挿入

電源管理

デバイス電源管理

システム電源管理

直列化

ユーティリティー関数

デバイス構成機能

インタフェース番号の取得

デバイス全体の管理

複数の構成を持つデバイス

代替設定の変更または取得

その他のユーティリティー関数

文字列記述子の取得

パイプの非公開データ機能

USB 状態のクリア

デバイス、インタフェース、エンドポイントの各ステータスの取得

デバイスのバスアドレスの取得

サンプル USB デバイスドライバ

21.  SR-IOV ドライバ

パート III デバイスドライバの構築

22.  ドライバのコンパイル、ロード、パッケージ化、およびテスト

23.  デバイスドライバのデバッグ、テスト、およびチューニング

24.  推奨されるコーティング方法

パート IV 付録

A.  ハードウェアの概要

B.  Oracle Solaris DDI/DKI サービスのサマリー

C.  64 ビットデバイスドライバの準備

D.  コンソールフレームバッファードライバ

E.  pci.conf ファイル

索引

ドキュメントの品質向上のためのご意見をください
簡潔すぎた
読みづらかった、または難し過ぎた
重要な情報が欠けていた
内容が間違っていた
翻訳版が必要
その他
Your rating has been updated
貴重なご意見を有り難うございました!

あなたの貴重なご意見はより良いドキュメント作成の手助けとなります 内容の品質向上と追加コメントのためのアンケートに参加されますか?

デバイス状態管理

USB デバイスの管理では、ホットプラグ、システム電源管理 (チェックポイントと復元再開)、およびデバイス電源管理を考慮する必要があります。クライアントドライバは必ず、次の図に示す基本的な状態マシンを実装するべきです。詳細については、/usr/include/sys/usb/usbai.h を参照してください。

図 20-4 USB デバイスの状態マシン

image:図は、異なる 7 つの各イベントの発生後にデバイスがどの状態に遷移するかを示しています。

この状態マシンと 4 つの状態は、ドライバ固有の状態で拡張できます。0x80 から 0xff のデバイス状態を定義して使用できるのは、クライアントドライバだけです。

USB デバイスのホットプラグ

USB デバイスはホットプラグをサポートします。USB デバイスの挿入や取り外しはいつでも行えます。クライアントドライバは、オープン状態のデバイスの取り外しと再挿入を処理する必要があります。オープン状態のデバイスを処理するには、ホットプラグコールバックを使用します。クローズ状態のデバイスの挿入と取り外しは、attach(9E) および detach(9E) エントリポイントによって処理されます。

ホットプラグコールバック

USBA 2.0 フレームワーク では次のイベント通知がサポートされています。

クライアントドライバは、usb_register_hotplug_cbs(9F) ルーチン内で attach(9E) を呼び出してイベントコールバック用の登録を行う必要があります。ドライバは、設定解除を行う前に、usb_unregister_hotplug_cbs(9F) ルーチン内で detach(9E) を呼び出す必要があります。

電源を入れたまま挿入

電源を入れたまま USB デバイスを挿入した場合のイベントシーケンスは、次のとおりです。

  1. ハブドライバ hubd(7D) が、ポート接続ステータスが変化するまで待ちます。

  2. hubd ドライバがポート接続を検出します。

  3. hubd ドライバがデバイス内の情報を列挙し、子デバイスノードを作成し、クライアントドライバを接続します。互換名の定義については、「クライアントドライバのバインド」を参照してください。

  4. クライアントドライバがデバイスを管理します。ドライバの状態は ONLINE です。

電源を入れたまま取り外し

電源を入れたまま USB デバイスを取り外した場合のイベントシーケンスは、次のとおりです。

  1. ハブドライバ hubd(7D) が、ポート接続ステータスが変化するまで待ちます。

  2. hubd ドライバがポート切り離しを検出します。

  3. hubd ドライバが、切り離しイベントを子クライアントドライバに送信します。子クライアントドライバが hubd ドライバまたは usb_mid(7D) マルチインタフェースドライバである場合、子クライアントドライバはそのイベントを子に伝播します。

  4. クライアントドライバが、カーネルスレッドコンテキストで切り離しイベント通知を受け取ります。カーネルスレッドコンテキストでは、ドライバの切り離しハンドラのブロックが可能となります。

  5. クライアントドライバの状態が DISCONNECTED に遷移します。device not responding という完了理由で未処理の入出力転送が失敗します。新しい入出力転送やデバイスノードのオープン試行もすべて失敗します。クライアントドライバがパイプを閉じる必要はありません。ドライバは、デバイスがふたたび接続された場合に復元する必要のあるデバイスやドライバのコンテキストを保存しておく必要があります。

  6. hubd ドライバは、OS デバイスノードとその子を下から順にオフラインにしようとします。

hubd ドライバがデバイスノードをオフラインにしようとした時点でデバイスノードが開いていなかった場合、次のイベントが発生します。

  1. クライアントドライバの detach(9E) エントリポイントが呼び出されます。

  2. デバイスノードが破棄されます。

  3. そのポートが新しいデバイスから使用可能になります。

  4. ホットプラグのイベントシーケンスが最初から始まります。hubd ドライバが、ポート接続ステータスが変化するまで待ちます。

hubd ドライバがデバイスノードをオフラインにしようとした時点でデバイスノードが開いていた場合、次のイベントが発生します。

  1. hubd ドライバが、定期的オフライン再試行キューにオフライン要求を置きます。

  2. そのポートは、新しいデバイスから使用不可能なままになります。

hubd ドライバがデバイスノードをオフラインにしようとした時点ではデバイスノードが開いていたが、その後ユーザーがそのデバイスノードを閉じた場合、hubd ドライバによるデバイスノードの定期的なオフライン化が成功し、次のイベントが発生します。

  1. クライアントドライバの detach(9E) エントリポイントが呼び出されます。

  2. デバイスノードが破棄されます。

  3. そのポートが新しいデバイスから使用可能になります。

  4. ホットプラグのイベントシーケンスが最初から始まります。hubd ドライバが、ポート接続ステータスが変化するまで待ちます。

ユーザーがそのデバイスを使用するアプリケーションをすべて閉じると、そのポートがまた使用可能になります。アプリケーションが終了しない場合やデバイスがクローズされない場合、そのポートは使用不可能なままになります。

電源を入れたまま再挿入

デバイスのデバイスノードがまだ開いている間に以前に取り外されたデバイスが同じポートに再挿入された場合、次のイベントが発生します。

  1. ハブドライバ hubd(7D) がポート接続を検出します。

  2. hubd ドライバがバスアドレスとデバイス構成を復元します。

  3. hubd ドライバがオフライン再試行要求を取り消します。

  4. hubd ドライバが、接続イベントをクライアントドライバに送信します。

  5. クライアントドライバが接続イベントを受け取ります。

  6. クライアントドライバが、新しいデバイスが以前接続されていたデバイスと同じものかどうかを判定します。クライアントドライバはこの判定を行うために、まずデバイス記述子を比較します。クライアントドライバは、シリアル番号や構成記述子クラウドも比較する可能性があります。

クライアントドライバが、現在のデバイスが以前接続されていたデバイスと同じものでないと判定した場合、次のイベントが発生する可能性があります。

  1. クライアントドライバがコンソールに警告メッセージを発行する可能性があります。

  2. ユーザーがデバイスを再度取り外す可能性があります。ユーザーがデバイスを再度取り外した場合、電源を入れたまま取り外した場合のイベントシーケンスが最初から始まります。hubd ドライバがポート切り離しを検出します。ユーザーがデバイスを再度取り外さなかった場合、次のイベントが発生します。

    1. クライアントドライバの状態が DISCONNECTED のままになり、要求やオープンがすべて失敗します。

    2. そのポートは使用不可能なままになります。ユーザーはポートを解放するために、デバイスを閉じて取り外す必要があります。

    3. ポートが解放されると、ホットプラグのイベントシーケンスが最初から始まります。hubd ドライバが、ポート接続ステータスが変化するまで待ちます。

クライアントドライバが、現在のデバイスが以前接続されていたデバイスと同じものである判定した場合、次のイベントが発生する可能性があります。

  1. クライアントドライバが状態を復元し、通常の動作を継続する可能性があります。このポリシーに従うかどうかは、クライアントドライバしだいです。クライアントドライバが処理を継続するべきである場合の例として、オーディオスピーカーが挙げられます。

  2. 再接続されたデバイスを使用し続けても安全である場合には、ホットプラグのイベントシーケンスが最初から始まります。hubd ドライバが、ポート接続ステータスが変化するまで待ちます。デバイスがふたたびサービスを提供できる状態になります。

電源管理

このセクションでは、デバイス電源管理とシステム電源管理について説明します。

デバイス電源管理は、個々の USB デバイスをその入出力動作やアイドル状態かどうかに応じて管理します。

システム電源管理は、チェックポイントと復元再開を使用することで、システムの状態をファイル内にチェックポイントし、システムを完全に停止します (チェックポイントは「システム保存停止」と呼ばれることもあります)。システムの電源を再度入れると、システムは保存停止される前の状態に復元再開されます。

デバイス電源管理

次のサマリーは、USB デバイスの電源管理のためにドライバ内で行う必要のある処理を箇条書きにしたものです。電源管理の詳細については、このサマリーのあとで説明します。

  1. attach(9E) 内で電源管理コンポーネントを作成します。usb_create_pm_components(9F) のマニュアルページを参照してください。

  2. power(9E) エントリポイントを実装します。

  3. デバイスにアクセスする前に、pm_busy_component(9F)pm_raise_power(9F) を呼び出します。

  4. デバイスへのアクセスが終了したら pm_idle_component(9F) を呼び出します。

USBA 2.0 フレームワーク は、USB インタフェースの電源管理仕様で規定されている 4 つの電源レベルをサポートしています。USB 電源レベルとオペレーティングシステム電源レベルとの対応関係については、/usr/include/sys/usb/usbai.h を参照してください。

デバイスの状態が USB_DEV_OS_PWR_OFF に遷移すると、hubd ドライバはポートを保存停止します。デバイスの状態が USB_DEV_OS_PWR_1 以上に遷移すると、hubd ドライバはポートを復元再開します。ポート保存停止とシステム保存停止は異なります。ポート保存停止の場合、停止されるのは USB ポートだけです。システム保存停止については、「システム電源管理」で定義します。

クライアントドライバでは、デバイスでのリモートウェイクアップを有効化できます。usb_handle_remote_wakeup(9F) のマニュアルページを参照してください。hubd ドライバがあるポート上でリモートウェイクアップを検出すると、 hubd ドライバはウェイクアップ処理を実行し、pm_raise_power(9F) を呼び出して子に通知します。

次の図は、電源管理のさまざまな部分の間の関係を示したものです。

図 20-5 USB 電源管理

image:図は、異なる 2 つの電源管理方式をどのような場合に採用するかを示しています。

ドライバは、図 20-5 の下部で説明した 2 つの電源管理方式のいずれかを実装できます。パッシブ方式は、デバイス転送中に電源管理を行わないので、アクティブ方式よりも単純です。

アクティブ電源管理

このセクションでは、アクティブ電源管理スキームを実装する際に使用する必要のある関数について説明します。

ドライバの attach(9E) エントリポイントで次の処理を行います。

  1. usb_create_pm_components(9F) を呼び出します。

  2. 必要に応じて、第 2 引数に USB_REMOTE_WAKEUP_ENABLE を指定して usb_handle_remote_wakeup(9F) を呼び出すことで、デバイスでのリモートウェイクアップを有効にします。

  3. pm_busy_component(9F) を呼び出します。

  4. pm_raise_power(9F) を呼び出して電源を USB_DEV_OS_FULL_PWR レベルにします。

  5. デバイスとの通信を行ってデバイスを初期化します。

  6. pm_idle_component(9F) を呼び出します。

ドライバの detach(9E) エントリポイントで次の処理を行います。

  1. pm_busy_component(9F) を呼び出します。

  2. pm_raise_power(9F) を呼び出して電源を USB_DEV_OS_FULL_PWR レベルにします。

  3. attach(9E) エントリポイントで usb_handle_remote_wakeup (9F) 関数を呼び出した場合、ここで第 2 引数に USB_REMOTE_WAKEUP_DISABLE を指定して usb_handle_remote_wakeup(9F) を呼び出します。

  4. デバイスとの通信を行ってデバイスを完全に停止させます。

  5. pm_lower_power(9F) を呼び出して電源を USB_DEV_OS_PWR_OFF レベルにします。

    これが、クライアントドライバ内で pm_lower_power(9F) を呼び出す唯一の場合です。

  6. pm_idle_component(9F) を呼び出します。

あるドライバスレッド内でデバイスへの入出力を開始する必要がある場合、そのスレッドで次のタスクを実行します。

  1. pm_busy_component(9F) を呼び出します。

  2. pm_raise_power(9F) を呼び出して電源を USB_DEV_OS_FULL_PWR レベルにします。

  3. 入出力転送を開始します。

ドライバ内で入出力転送が完了したという通知を受け取ったら、pm_idle_component(9F) を呼び出します。

ドライバの power(9E) エントリポイントでは、遷移先の電源レベルが有効かどうかをチェックします。また、複数のスレッドが同時に power(9E) への呼び出しを行うことを考慮しなければならない可能性もあります。

デバイスのアイドル状態が一定時間続いたか、またはシステムが停止しようとしている場合、デバイスの状態を USB_DEV_OS_PWR_OFF にするために power(9E) ルーチンが呼び出される可能性があります。この状態は、図 20-4 で示した PWRED_DWN 状態に対応しています。 デバイスの状態が USB_DEV_OS_PWR_OFF に遷移する場合、power(9E) ルーチンで次の処理を行います。

  1. 開かれたパイプをすべてアイドル状態にします。たとえば、割り込みパイプのポーリングを停止します。

  2. 保存する必要のあるデバイスやドライバのコンテキストをすべて保存します。

    power(9E) の呼び出しが完了したあと、デバイスが接続されているポートが保存停止されます。

デバイス起動のリモートウェイクアップまたはシステム起動のウェイクアップが受信されると、デバイスの電源を入れるために power(9E) ルーチンが呼び出される可能性があります。ウェイクアップ通知が発生するのは、アイドル時間が長く続いたかシステムが保存停止したために、デバイスの電源レベルが低下したあとです。デバイスの状態が USB_DEV_OS_PWR_1 に遷移する場合、power(9E) ルーチンで次の処理を行います。

  1. デバイスやドライバの必要なコンテキストをすべて復元します。

  2. 指定された電源レベルに適したアクティビティーをパイプ上で再開します。たとえば、割り込みパイプでポーリングを開始します。

デバイスが接続されているポートが以前保存停止されていた場合、power(9E) が呼び出される前にそのポートが復元再開されます。

パッシブ電源管理

パッシブ電源管理方式は、前述のアクティブ電源管理方式より単純です。このパッシブ方式では、転送中の電源管理は行われません。このパッシブ方式を実装するには、デバイスを開くときに pm_busy_component(9F)pm_raise_power(9F) を呼び出します。その後、デバイスを閉じるときに pm_idle_component(9F) を呼び出します。

システム電源管理

システム電源管理は、状態保存後のシステム全体の電源切断とシステム電源再投入後の状態復元とで構成されます。この処理は CPR (チェックポイントおよび復元再開) と呼ばれます。CPR に関する USB クライアントドライバの動作は、ほかのクライアントドライバの動作と同じです。デバイスを保存停止する場合は、ドライバの detach(9E) エントリポイントが cmd 引数 DDI_SUSPEND で呼び出されます。デバイスを復元再開する場合は、ドライバの attach(9E) エントリポイントが cmd 引数 DDI_RESUME で呼び出されます。detach(9E) ルーチンで DDI_SUSPEND コマンドを処理する場合、あとで完全な復元再開を行うのに必要な範囲で、デバイス状態やドライバ状態をクリーンアップします (この状態は図 20-4SUSPENDED に対応しています)。attach(9E) ルーチンで DDI_RESUME コマンドを処理する場合、システムとデバイスの同期が取れるように、必ずデバイスの電源レベルをフルにします。

USB デバイスの場合、保存停止/復元再開はホットプラグの切り離し/再接続 (「USB デバイスのホットプラグ」を参照) と同様に処理されます。CPR とホットプラグの重要な違いは、CPR では、デバイスが保存停止可能な状態にない場合にドライバでのチェックポイント処理が失敗する可能性があるという点です。たとえば、デバイスのエラー回復が進行中である場合、デバイスの保存停止は行えません。デバイスがビジー状態で安全に停止できない場合も、デバイスの保存停止は行えません。

直列化

ドライバでは一般に、相互排他を保持した状態で USBA 関数を呼び出するべきではありません。したがって、クライアントドライバ内で競合状態が発生することが避けられない可能性があります。

切り離しや CPR といった非同期イベントの処理コードと通常動作コードの同時実行を許可しないでください。これらのタイプの非同期イベントでは通常、パイプのクリーンアップと設定解除が行われるため、通常動作コードに悪影響が及ぶ可能性があります。

競合状態を管理して通常動作コードを保護する方法の 1 つは、排他アクセス権を持つ同期オブジェクトの取得と解放を行える直列化機能を記述することです。USBA 関数の呼び出し中に同期オブジェクトを安全に保持できるように、直列化機能を記述できます。usbskel サンプルドライバでこの手法が使用されています。