Linux、ドライバーのロードの遅延、割り込みの破損

今日は、マトリックスキーボードをBercut-ETNデバイス（ETN- Bercut-ETの新しいハードウェアリビジョン）のLinux ARMボードに接続するときに発生した予期しない問題について説明します。 具体的には、adp5589ドライバーが割り込みを受信したくない理由と、これを実現する方法について説明しました。



誰が気にします-猫へようこそ。







目次：

• 鉄部分の説明
• 問題はどこにありますか？
• デバイスツリーについて一言
• デバイスとドライバーの登録について少し
• 遅延ドライバーのロードメカニズム
• すべてを機能させる方法

キーボードの周りの鉄の説明：



コントローラー自体のキーボードにはありません-特別なマトリックスキーボードコントローラー-adp5589チップを使用してI2Cバスを介して接続されています。 チップには、ARM SoC GPIOピンの1つに巻かれた割り込みラインがあります。 その結果、接続図は次のようになります。







portbは、ピンがキーボードコントローラーによって中断されるポートです。

intc-メイン割り込みコントローラー。

i2c0 - i2cバスコントローラー。



何らかの理由でadp5589ドライバーは、頑固に割り込み番号を取得したくありません。 この動作の理由は何でしょうか？ キーボードドライバーを読み込むためのリソースが不足している可能性があります。 依存するデバイスに起動する時間がなかったのでしょうか？ 依存できるデバイスを見てみましょう。



まず、接続されているI2Cバスコントローラーから。

第二に-ポートコントローラから、ピンに割り込みラインがあります。



次に、これらのデバイスのドライバーがロードされる順番を見てみましょう。



ギック

designware-i2c

adp5589

dw-apb-gpio-port



うん！ それが理由です-キーボードドライバーが読み込まれるとき、その割り込み親はまだ読み込まれていません。 その結果、キーボードドライバーは割り込み番号を受け取りません。 この問題の標準的な解決策は、ドライバーの遅延読み込みメカニズムです。



その本質は、必要なリソースがまだ利用可能でない場合、ドライバーがリロードを必要とする可能性があることです。 そして、彼はプローブ関数から値-EPROBE_DEFERを返すことでそれを要求できます。 その後、このドライバーは後でリロードされます。 その時までに、目的のリソースがすでに利用可能になっているか、ドライバーのダウンロードが再び遅延します。



キーボードドライバーのプローブドライバー機能にテストを追加します。

if (!client->irq) { dev_err(&client->dev, "no IRQ boss?\n"); return -EPROBE_DEFER; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しい起動順序を確認したい：

ギック

adp5589

designware-i2c

dw-apb-gpio-port

（延期）adp5589

（延期）adp5589

（延期）adp5589



何かがおかしい-GPIOドライバーの後にキーボードドライバーが再ロードされたが、割り込みを受信しなかった。 予想以上にソースコードを深く掘り下げる必要があるようです。



次の3つの解決策があります。

• 割り込み番号を直接ドライバーにハードコードする
• 何らかの方法で、ドライバーの起動順序を設定します
• 何らかの理由で機能しなかった、ドライバーの遅延読み込みのメカニズムに対処する

最初のオプション：



このオプションは機能していますが、望ましくありません。 一時的なものとして適していますが、ハードウェアで何かを変更する場合（たとえば、割り込み出力を別のGPIOポートに接続する場合）、デバイスツリーだけでなく、ドライバーのソースコードも変更する必要があります。



2番目のオプション：



ドライバーの起動順序を明示的に設定することはできません。 したがって、このオプションは適切ではありません。



3番目のオプション：



最も正しいもの。 検討します。



ここで、おそらく、デバイスツリーなどについて簡単に説明する価値があります。これについては後で参照するためです。



デバイスツリーは、Linuxを使用するデバイスのハードウェアを記述する形式です。 これは、必要な情報が設定されているノードのツリーの形式で表示されます。 DTは、人間が読み取れるテキストファイル（ .dts ; .dtsi ）と、それらから組み立てられたバイナリファイル（ .dtb ）の形式で存在します。



たとえば、キーボードコントローラーと他のSoCaデバイスの接続構造を記述した.dtsファイルの一部を考えてみましょう。

 i2c0: i2c@ffc04000 { compatible = "snps,designware-i2c"; keybs@34 { compatible = "adi,adp5589"; interrupts = <19 IRQ_TYPE_LEVEL_LOW>; interrupt-parent = <&portb>; }; }; intc: intc@fffed000 { compatible = "arm,cortex-a9-gic"; #interrupt-cells = <3>; interrupt-controller; }; portb: gpio-controller@0 { compatible = "snps,dw-apb-gpio-port"; interrupt-controller; #interrupt-cells = <2>; interrupts = <0 165 4>; interrupt-parent = <&intc>; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（理解しやすいように、現在興味のないノードとプロパティは省略されています）



i2c0 、 keybs 、 incおよびportbはノードであり、他のすべてはそれらのプロパティです。 コードから、キーボードコントローラーチップがI2Cバスに接続されていることがすぐにわかります。 compatibleプロパティで、デバイスのメーカーとモデルを説明する文字列。 OSがこのデバイスに関連付ける必要があるドライバーを認識するのは、このプロパティのためです。



interrupt-controllerは、このデバイスを割り込みコントローラーにできることを示すプロパティであり、 interrupt-parentは、現在のデバイスからの割り込みが誰に接続されているかを示します。



＃interrupt-cellsは、特定の割り込みコントローラーの割り込みを記述するパラメーターの数を示すプロパティであり、 interruptsは、この割り込みのパラメーターが設定されるプロパティです。



たとえば、 portbは次のように述べています。＃interrupt-cells = <2>これは、 portbがinterrupt-parentであるノードでは、 interruptsプロパティに 2つのパラメーターを記述する必要があることを意味します。 portbはkeybsの割り込み親です。 私たちはキーボードを調べます。 割り込み= <19 IRQ_TYPE_LEVEL_LOW>を示します。 これはどういう意味ですか？



ここでは、2つのパラメーターについて説明します。 1つ目はポートportのピン番号で、キーボードコントローラーからの割り込みラインがあります。 2番目は、割り込みのタイプ（低または高）です。 割り込みコントローラのパラメータをいくつ記述する必要があるのか​​、またそれぞれの意味はどのようにわかりますか？ 通常、これはドキュメントに書かれています。 したがって、 portbについては、次のファイルに記述されています： Documentation / devicetree / bindings / gpio / snps-dwapb-gpio.txt



＆portb - portbノードへのリンク（この場合、portbへのリンクは/ soc / gpio @ ff709000 / gpio-controller @ 0になります）

残りのプロパティはまだ必要ありません。それらについて、および一般的にデバイスツリーについては、 devicetree.org / Device_Tree_Usageで詳細を読むことができます。



デバイスとドライバーを登録するプロセスに言及することは不必要ではありません（心配しないでください。次の段落のメイントピックに戻ります）。 Linuxデバイスモデルによると：



デバイス -バスに接続されている物理オブジェクトまたは仮想オブジェクト（おそらく仮想）

ドライバーは、デバイスに接続でき、あらゆる制御機能を実行できるソフトウェアオブジェクトです。

バスは、他のデバイスの「接続ポイント」になるように設計されたデバイスです。 カーネルがサポートするすべてのバスの基本機能は、 bus_type構造によって決定されます。 この構造では、ネストされたsubsys_private構造が宣言され、2つのリストが宣言されます： klist_devicesおよびklist_drivers 。

klist_devices-バスに接続されているデバイスのリスト。

klist_drivers-このバス上のデバイスを制御できるドライバーのリスト。

device_registerおよびdriver_register関数を使用して、デバイスとドライバーがこれらのリストに追加されます 。 さらに、 device_registerおよびdriver_registerは、デバイスを適切なドライバーに関連付けます。 device_registerは、ドライバーのリストを調べて、このデバイスに適したドライバーを見つけようとします。 （ driver_registerはデバイスのリストを調べて、管理できるデバイスを見つけようとします）ドライバーがデバイスに適しているかどうかの確認は、 bus_type構造体へのポインターであるmatch （dev、drv）関数を使用して行われます。







ここで、メイントピック-遅延ドライバーのロードメカニズムの実装に進みます。 drivers / base / dd.cファイルを見てみましょう。



ドライバのリロードを制御するための2つのリスト-deferred_probe_pending_listとdeferred_probe_active_listがあります。



deferred_probe_pending_list-ドライバーにリソースが不足しているデバイスのリスト。

deferred_probe_active_list-ドライバーを再起動できるデバイスのリスト。



really_probe関数は、デバイスが配置されているバスのプローブ関数を呼び出します。 私たちの場合、これは関数i2c_device_probeで 、このdev- > bus- > probe（dev）のように見えます。 戻り値のエラーがチェックされ、 -EPROBE_DEFERの場合、デバイスはdeferred_probe_pending_listに追加されます。



しかし、最も興味深いのは、ドライバーがいつどのように呼び出されるかです。 ドライバーが-EPROBE_DEFERを返す間 、デバイスはdeferred_probe_pending_listに順次追加されます。 ただし、プローブ機能がドライバーに対して成功すると、 deferred_probe_pending_listのすべてのデバイスがdeferred_probe_active_listに転送されます。 論理的に見えます。最後に正常にロードしたドライバーが、保留中のドライバーの通常のロードには不十分だった可能性があります。 deferred_probe_active_listからドライバーを開始する2回目の試行は 、 deferred_probe_work_func関数によって行われます。 リスト内の各デバイスに対してbus_probe_deviceを呼び出します。



bus_probe_deviceを呼び出すと、最終的には、デバイスとそのドライバーからペアのreally_probe関数に戻ります（上記を参照）。







しかし、待ってください！ 現在、デバイスが配置されているバスに対してプローブ関数を呼び出すことについて話しています。 これはi2c_device_probeについてです 。 しかし、キーボードのプローブドライバー機能はどうでしょうか。 いいえ、忘れてはいません。i2c_device_probeから呼び出されるだけです 。 これを確認するには、 drivers / i2c / i2c-core.cファイルでコードを確認します 。





さて、リロードは機能しているように思えますが、キーボードドライバーが割り込み番号を取得しないのはなぜですか？

割り込み番号がどのようにドライバーに入るかを追跡してみましょう。



クライアント構造はadp5589_probe関数（struct i2c_client * client、const struct i2c_device_id * id）に渡され、そのフィールドの1つはirq-デバイス（キーボードコントローラー）が生成する割り込み番号です。 adp5589_probeは 、 i2c_device_probe関数（struct device * dev）から呼び出されます。 デバイス構造は、 i2c_client構造へのポインターが計算されるポインターから（ container_ofマクロmagicを使用して）渡されます。





そのため、 i2c_client構造体が配置されている場所を見つける必要があります。 関数i2c_new_device （struct i2c_adapter * adap、struct i2c_board_info const * info）に入力されます。 具体的には、irqフィールドはi2c_board_info構造体の同じフィールドからコピーされます。

 struct i2c_client *client; client->irq = info->irq;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

i2c_board_info構造体は 、 of_i2c_register_devices関数（struct i2c_adapter * adap）に入力されます。

 info.irq = irq_of_parse_and_map(node, 0);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

irq_of_parse_and_mapは、 of_irq_parse_oneとirq_create_of_mappingの 2つの関数のチェーンのラッパーです。 of_irq_parse_one関数は、現在のデバイスの割り込みコントローラーとしてデバイスツリーで宣言されているノードを見つけようとします。

デバイスツリーのこれらの数行を覚えていますか？

 expander: pca9535@20 { interrupt-parent = <&portb>; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

of_irq_parse_oneを検索するのはportbであり、その作業結果に応じて、 irq_create_of_mapping関数に渡される構造体of_phandle_argsを埋めます。 irq_create_of_mappingは既にあり、目的の割り込み番号を返します。



初めて、 of_irq_parse_oneはログで誓うGPIOポートを見つけません。



irq：/ soc / gpio @ ff709000 / gpio-controller @ 0のirqドメインが見つかりません！



そして、ドライバーがリロードされるとどうなりますか？ しかし、何も。 i2c_device_probeとadp5589_probeのみが呼び出されます。

それが問題です。 割り込みは初めてインストールされ、ドライバーをどれだけリロードしても、永久に残ります。



問題が見つかりましたが、それを修正する方法は？



割り込みコードをi2c_device_probeに転送してみてください。 これ以前は、どこにも割り込み番号は必要ないため、問題はないはずです。



しかし、より良いのは、カーネルの最新バージョン（バージョン3.18がインストールされている）のソースを調べてみましょう。

クライアントi2c割り込みの設定は、 i2c_device_probe関数に転送されました。

 if (!client->irq && dev->of_node) { int irq = of_irq_get(dev->of_node, 0); if (irq == -EPROBE_DEFER) return irq; if (irq < 0) irq = 0; client->irq = irq; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

irqフィールドはi2c_board_info構造に残りますが、使用されません。 そのため、カーネルの新しいバージョンでは、問題は修正されています。



変更をバージョンに転送するだけです。 すべての変更は、ファイルドライバー/ i2c / i2c-core.cに影響します

i2cクライアントの割り込み設定をi2c_device_probeに追加します。これは最新バージョンにあり、 of_i2c_register_devices関数の割り込み設定を削除します。





チェック-キーボードは機能しています。 / proc / interruptを調べます。

 $ grep 'adp5589_keys' /proc/interrupts 305: 2 - 20 adp5589_keys
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いくつかのボタンを押します。

 $ grep 'adp5589_keys' /proc/interrupts 305: 6 - 20 adp5589_keys
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題は解決しました。