LinuxI 2 Cサブシステムの1つであるIC 2デバイス(Client)をインスタンス化する4つの方法(三、四)
3355 ワード
オリジナル作品は、転載時に必ずハイパーリンク形式で文章の元の出所を明記してください.http://blog.csdn.net/gqb666/article/details/8698856,著者:gqb 666
やっと翻訳が終わりました.不正確なところがありますので、よろしくお願いします.
上接博文:LinuxI 2 Cサブシステムの1つでIC 2デバイス(Client)をインスタンス化する4つの方法(一、二)
元のファイルの場所:linuxソースディレクトリDocumentationi 2 cinstantiating-devices
===========================================
どのようにI 2 C設備をインスタンス化します
===========================================
PCIやUSBバスとは異なり、I 2 Cバスはハードウェア層でデバイスを列挙することはできない.逆に、ソフトウェアは、どのデバイスがどのI 2 Cバスに接続されているか、および各デバイスのアドレスIDを明らかにしなければならない.したがって、カーネルドライバコードは、I 2 Cデバイスを明示的に「手動」でインスタンス化する必要がある.異なる設備の操作の複雑さと項目とその他の需要に対して、現在4種類のI 2 C設備を実例化する方法がある:
第三に、特定のデバイスにI 2 Cバスを列挙する
I 2 Cデバイスの情報を十分に取得できない場合があります.i 2 cを呼び出す方法new_probed_device()はなおさら話にならない.1つの典型的な例は、多くのマザーボードとその上の複数のディスプレイチップであり、ここには数十種類の組み合わせがあり、それぞれのアドレスが25種類ある可能性があります(この理解はよくありません.よろしくお願いします).これらの膨大な数のマザーボード情報が与えられても、完全な利用可能な表示チップリストを構築することはほとんど不可能であり、幸いなことに、このような表示チップを使用してメーカーおよびデバイスIDレジスタを列挙し、一意に表示することができる.
この場合、I 2 Cデバイスは、事前に定義して登録することも、明示的にインスタンス化することもできない.逆に、i 2 c−coreコアドライバは、ドライバのロード時にできるだけ早く列挙され、列挙に成功すれば、これらのI 2 Cデバイスは自動的にインスタンス化される.このようなメカニズムの副作用を避けるためには、以下の2点を保証しなければならない.
(1)I 2 Cデバイスドライバは、デバイス専用レジスタを読み出して特定のデバイスを示すdetect()関数を実装しなければならない.
(2)マウントデバイスと列挙を許可するI 2 Cバスが存在する場合にのみ列挙される.例えば、TVアダプタに表示チップを列挙することは許されない.
例:
drivers/hwmon/lm 90を参照してください.cファイル中lm 90_driver and lm90_detect()関数.
列挙に成功してインスタンス化されたデバイスは、(1)デバイスのドライバがアンインストールされたことを検出したとき(2)掛けたバスがアンインストールされるとき(2)の2つの場合に自動的に解放される.
ここで説明する方法3は、実際には、カーネル2.4または2.6以前のI 2 Cサブシステムの駆動実装と非常に類似しているが、2つの重要な違いがある.
(1)できない場合の列挙法こそ,デバイスをインスタンス化する方法とすることができる.可能であれば、方法1および方法2は、いずれも(方法3よりも優れている)推奨すべき方法である.方法は思わぬ副作用を引き起こす可能性があるので、できない場合は使用しないでください.
(2)I 2 Cバスは、すべてのI 2 Cバスがデフォルト設定で列挙されるが、実際にはここのデフォルト設定は空であり、列挙は発生しない(この翻訳では論争がある可能性がある).クラスビットドメインの設定の目的は、上述した予期せぬ副作用を回避することである.
さらに、方法3は、使用を可能な限り回避し、デバイス(方法1および方法2)を明示的にインスタンス化することによって、より良い安全性とより高い効率を有することを強調する必要がある.
第四:ユーザ空間でデバイスをインスタンス化する
通常、カーネルは、I 2 CデバイスがどのI 2 Cバスに接続されているか、およびI 2 Cデバイスのアドレス(デバイスID)を知る必要がある.しかし、そうではない場合があるため、Linuxはsysfsインタフェースを使用してカーネルにこれらの情報をユーザ空間に提供します.このインタフェースは、各I 2 Cバスディレクトリの下に2つのファイルノード(new_deviceおよびdelete_device)を提供し、この2つのファイルノードはいずれも書き込みのみであり、ユーザはそれらに正しいパラメータを書き込んで(インスタンス化)I 2 Cデバイスを作成または削除しなければならない.
new_デバイスには、I 2 Cデバイスの名前(文字列)とI 2 Cデバイスのアドレス(0 xで始まる16進数で表すか、10進数で表すか)の2つのパラメータがあります.
delete_デバイスには1つのパラメータしかありません:I 2 Dデバイスアドレス.同じI 2 Cバス上で同じデバイスアドレスのデバイスを2つ掛けることは不可能であるため、このアドレスはデバイスを一意に示すことができる.
例:
デバイスの作成:
デバイスの削除:
sysfsインタフェースメソッドはカーネルコードがデバイスを定義できない場合にのみ使用できるが、(1)I 2 Cデバイス駆動が列挙バスによってデバイスを検出する場合に非常に有用であるが、デバイスが掛けているI 2 Cバスは列挙クラスビットドメインをセットアップしていない.列挙は起こり得ないためである.(2)I 2 Cデバイスがプローブデバイスを駆動する場合,デバイスのアドレスは予知されない.(3)I 2 Cデバイスがプローブデバイスを駆動する場合、プローブプロセスはプローブプロセスが厳しすぎたり、デバイスがプローブをサポートしていない(デバイスメーカーがサポートしていないことを事前に知らない)ために失敗します.(4)試験板に自己半田付けしたI 2 C機器のドライバテスト使用時.このsysfsインタフェースは、いくつかのI 2 Cドライバアーキテクチャで実装されるforce_*と考えられる.モジュールパラメータの代替として、インタフェースは、個別のI 2 Cデバイス駆動ではなく、I 2 Cコア層で実装されている.設定を変更するときにドライバを再ロードする必要がないという利点があります.さらに興味深いことに、デバイスドライバがマウントされる前に、またはドライバが使用可能かどうか分からない場合に、デバイスをインスタンス化(作成)することができ、このデバイスに対応するドライバがどれであるかに関心を持つ必要はありません.
やっと翻訳が終わりました.不正確なところがありますので、よろしくお願いします.
上接博文:LinuxI 2 Cサブシステムの1つでIC 2デバイス(Client)をインスタンス化する4つの方法(一、二)
元のファイルの場所:linuxソースディレクトリDocumentationi 2 cinstantiating-devices
===========================================
どのようにI 2 C設備をインスタンス化します
===========================================
PCIやUSBバスとは異なり、I 2 Cバスはハードウェア層でデバイスを列挙することはできない.逆に、ソフトウェアは、どのデバイスがどのI 2 Cバスに接続されているか、および各デバイスのアドレスIDを明らかにしなければならない.したがって、カーネルドライバコードは、I 2 Cデバイスを明示的に「手動」でインスタンス化する必要がある.異なる設備の操作の複雑さと項目とその他の需要に対して、現在4種類のI 2 C設備を実例化する方法がある:
第三に、特定のデバイスにI 2 Cバスを列挙する
I 2 Cデバイスの情報を十分に取得できない場合があります.i 2 cを呼び出す方法new_probed_device()はなおさら話にならない.1つの典型的な例は、多くのマザーボードとその上の複数のディスプレイチップであり、ここには数十種類の組み合わせがあり、それぞれのアドレスが25種類ある可能性があります(この理解はよくありません.よろしくお願いします).これらの膨大な数のマザーボード情報が与えられても、完全な利用可能な表示チップリストを構築することはほとんど不可能であり、幸いなことに、このような表示チップを使用してメーカーおよびデバイスIDレジスタを列挙し、一意に表示することができる.
この場合、I 2 Cデバイスは、事前に定義して登録することも、明示的にインスタンス化することもできない.逆に、i 2 c−coreコアドライバは、ドライバのロード時にできるだけ早く列挙され、列挙に成功すれば、これらのI 2 Cデバイスは自動的にインスタンス化される.このようなメカニズムの副作用を避けるためには、以下の2点を保証しなければならない.
(1)I 2 Cデバイスドライバは、デバイス専用レジスタを読み出して特定のデバイスを示すdetect()関数を実装しなければならない.
(2)マウントデバイスと列挙を許可するI 2 Cバスが存在する場合にのみ列挙される.例えば、TVアダプタに表示チップを列挙することは許されない.
例:
drivers/hwmon/lm 90を参照してください.cファイル中lm 90_driver and lm90_detect()関数.
列挙に成功してインスタンス化されたデバイスは、(1)デバイスのドライバがアンインストールされたことを検出したとき(2)掛けたバスがアンインストールされるとき(2)の2つの場合に自動的に解放される.
ここで説明する方法3は、実際には、カーネル2.4または2.6以前のI 2 Cサブシステムの駆動実装と非常に類似しているが、2つの重要な違いがある.
(1)できない場合の列挙法こそ,デバイスをインスタンス化する方法とすることができる.可能であれば、方法1および方法2は、いずれも(方法3よりも優れている)推奨すべき方法である.方法は思わぬ副作用を引き起こす可能性があるので、できない場合は使用しないでください.
(2)I 2 Cバスは、すべてのI 2 Cバスがデフォルト設定で列挙されるが、実際にはここのデフォルト設定は空であり、列挙は発生しない(この翻訳では論争がある可能性がある).クラスビットドメインの設定の目的は、上述した予期せぬ副作用を回避することである.
さらに、方法3は、使用を可能な限り回避し、デバイス(方法1および方法2)を明示的にインスタンス化することによって、より良い安全性とより高い効率を有することを強調する必要がある.
第四:ユーザ空間でデバイスをインスタンス化する
通常、カーネルは、I 2 CデバイスがどのI 2 Cバスに接続されているか、およびI 2 Cデバイスのアドレス(デバイスID)を知る必要がある.しかし、そうではない場合があるため、Linuxはsysfsインタフェースを使用してカーネルにこれらの情報をユーザ空間に提供します.このインタフェースは、各I 2 Cバスディレクトリの下に2つのファイルノード(new_deviceおよびdelete_device)を提供し、この2つのファイルノードはいずれも書き込みのみであり、ユーザはそれらに正しいパラメータを書き込んで(インスタンス化)I 2 Cデバイスを作成または削除しなければならない.
new_デバイスには、I 2 Cデバイスの名前(文字列)とI 2 Cデバイスのアドレス(0 xで始まる16進数で表すか、10進数で表すか)の2つのパラメータがあります.
delete_デバイスには1つのパラメータしかありません:I 2 Dデバイスアドレス.同じI 2 Cバス上で同じデバイスアドレスのデバイスを2つ掛けることは不可能であるため、このアドレスはデバイスを一意に示すことができる.
例:
デバイスの作成:
# echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_deviceデバイスの削除:
# echo 0x50 > /sys/bus/i2c/devices/i2c-3/delete_devicesysfsインタフェースメソッドはカーネルコードがデバイスを定義できない場合にのみ使用できるが、(1)I 2 Cデバイス駆動が列挙バスによってデバイスを検出する場合に非常に有用であるが、デバイスが掛けているI 2 Cバスは列挙クラスビットドメインをセットアップしていない.列挙は起こり得ないためである.(2)I 2 Cデバイスがプローブデバイスを駆動する場合,デバイスのアドレスは予知されない.(3)I 2 Cデバイスがプローブデバイスを駆動する場合、プローブプロセスはプローブプロセスが厳しすぎたり、デバイスがプローブをサポートしていない(デバイスメーカーがサポートしていないことを事前に知らない)ために失敗します.(4)試験板に自己半田付けしたI 2 C機器のドライバテスト使用時.このsysfsインタフェースは、いくつかのI 2 Cドライバアーキテクチャで実装されるforce_*と考えられる.モジュールパラメータの代替として、インタフェースは、個別のI 2 Cデバイス駆動ではなく、I 2 Cコア層で実装されている.設定を変更するときにドライバを再ロードする必要がないという利点があります.さらに興味深いことに、デバイスドライバがマウントされる前に、またはドライバが使用可能かどうか分からない場合に、デバイスをインスタンス化(作成)することができ、このデバイスに対応するドライバがどれであるかに関心を持つ必要はありません.