SDIO 仕様に従って、一連の操作 (書き込みトランザクションの場合) は次のように行われます。
Command53 -- CommandLatency -- Command53Response -- ResponseLatency -- startbit -- 書き込みバイト数 -- CRC -- endbit -- WriteLatency -- startbit -- CRC -- endbit -- busybit。
SDIO UART ドライバーのベンチマーク中に、得られた時間値は予想以上でした。特に書き込みトランザクション中に多くのレイテンシが見つかりました。
遅延の理由としては、スケジューラがプロセッサ時間を他のプロセスに割り当てている、ワーク キューの遅延などが考えられます。
レイテンシを分析して理解したいと思います。デバイス ドライバー コードとロジック アナライザーの波形の間のマッピングを理解すると、何らかの手がかりが得られる可能性があります。
誰かがこれに光を当てることができますか？
ありがとうございました。
編集1：ごめんなさい！私はいくつかのことを想定しました。
sdio_uart_transmit_chars ()には、sdio_writeb()sdio_out()を呼び出す呼び出しがあり、この呼び出しは SDIO UART デバイスにバイト単位で (一度に 1 バイトずつ) 書き込みます。sdio_writesb() 、つまりマルチバイトモードを使用するようにドライバーを変更しました。これにより、X バイトの書き込みにかかる時間が相対的に短縮されました。興味深いことに、書き込みデータのサイズが増加すると、WriteLatency が指数関数的に増加しました (前述のとおり)。
この待ち時間は、多くの理由で発生する可能性があります。これらの理由を理解したいと思います。
セットアップ: Linux (v 2.6.32) ラップトップとロード可能なカーネル モジュール (変更されたsdio_uart.c )を使用しています。
編集2：
この質問に「SDIO」を追加することは誤解を招く可能性があります..（現時点ではわかりません）。遅延の理由は、ハードウェアと対話しているときにデバイス ドライバーに共通する可能性があり、SDIO 書き込みプロセスとは無関係である可能性があります。
誰かが関連するオンライン リソースを教えてくれれば、ここで結果を調べて更新したいと思います。
今回はより明確にすることを願っています。質問がまだ明確でない場合はコメントしてください。
お時間をいただきありがとうございます。
編集3：
はい、ロジック アナライザー (LA) で信号を確認しましたが、書き込み中および書き込み間の遅延が予想よりも長くなっています。
512 バイトの転送の場合:
ハードウェア レベルでは、理論的には書き込みに 50 マイクロ秒 (us) かかるはずですが、実際には 200 秒かかりました。
この 150 us のギャップを理解したいと思います。
注:
1) ケースを単純化するために、時間の値を四捨五入しています。
2) すべての時間値はカーネル レベルで計算され、ここではユーザー スペースの問題は関係ありません。