Poulsbo System Controller Hub（US15W）のLPCバスのコンフィギュレーションレジスタ

Question

Atom Z510/Intel SCH US15W Q7カード（Debian Linuxを実行）をベースにしたシステムがあります。Lowのデバイスからデータのブロックを転送する必要がありますピンカウントバス。私が知る限り、このチップセットはDMA機能を提供しません。つまり、プロセッサはソフトウェアループで一度に1バイトずつデータを読み取らなければなりません。 （デバイスドライバは実際には "rep insb" x86命令を使ってこれを実装しているので、正しく理解すればループはCPUによって実際に実装されます）。

これは最適ではありませんが、転送速度14Mb/sの代わりに、スレーブデバイスへの各読み取りが560nsで実行されても、バス上のトランザクションが2us離れていなくても、4Mb/sを辛うじて管理できます。私はバス上の他の交通量が原因だとは信じていないが、まだ調査中だ。

私の質問は：LPCバスタイミングに影響を与える可能性のSCH上の任意のコンフィギュレーション・レジスタがある場合はいずれも

知っていますか？

IntelのWebサイト上でデバイスに関する有用な情報を見つけることができず、Linuxカーネルのコードでこのようなレジスタを掘り下げているように見えるものは見つかりませんでした（しかし、Linuxになると、

私はx86の専門家ではありません。このデバイスに関する他の「戦争物語」やその他の要因も知っておくとよいでしょう。

編集：私はdatasheetを見つけました。私はこの動作を説明しているものは見ていませんが、ファームウェアバスサイクルが同じ遅延を被らないように見えるので、デバイスをファームウェアデバイスとしてマッピングする可能性を検討しています。

Answer 1

解決策は、チップのデータ入出力レジスタが4つの隣接アドレスにマッピングされ、ドライバが32ビットのinb/outb命令を実行するようにFPGAファームウェアを変更することでした。 SCHは32ビットのLPC読み取り/書き込み操作を実装していませんが、結果は4つの連続した8ビット操作に続いて、以前は1バイトで取得していたのと同じデッドタイムです。理想的ではありませんが、依然としてスループットが倍増します。

ファームウェアのフラッシュからSCHが64バイトを一度に転送するため、ファームウェアのサイクルが速くなりました.64バイト後に同じ1.4usのギャップがあり、これがデバイスのトランザクションごとの待ち時間であることを示しています。これを利用することは、上記の解決策よりもわずかに速いかもしれませんが、ファームウェアを読み取るために必要な追加サイクルのために、64バイトのチャンクに制限され、各バイトには（680nsのIIRC）時間がかかります。