一般的な Linux クロック インフラストラクチャはclk.rstに記載されています。ARM については、Sasha Hauer が最近 (過去 2 年間)共通のクロックフレームワークを作成しました。時計は親子関係で構成されています。典型的な SOC (システム オン チップ) には、クリスタルから作成されたメイン クロックがあり、これは (カウンターで) 縮小されるか、PLL で拡大されます。これらの階層は、省電力にとって重要です。通常、デバイスは、ツリー内の最下位/最古のクロックの 1 つだけを使用しています。デバイスがクロックを要求すると、インフラストラクチャはすべての親が開始されていることを確認します。
以前は (レガシー)、クロックはマシン ファイル(参照arch/arm/Board***/
) からプラットフォーム データを介してドライバー/デバイスに渡されていました。最終的に通過しplatform_device_register()
ます。場合によっては、クロックがデバイス名に由来することがあります。たとえば、fecドライバーはfec-clkを使用する場合があります。これは複数のマシン構成ではうまく機能しなかったため、プラットフォーム データメカニズムが導入されました。新しい機械でさえ、dt (またはデバイステーブル) を使用します。ここには、マシン ファイルはなく、ブート ローダーからカーネルに渡されるデバイス テーブルのみがあります。この場合、dtは使用するクロックをドライバーに通知します。
元々、dev_id
とはデバイスのクロックと接続されている(親/子)con_id
クロックを関連付けるものでした。必要な側面は 1 つだけなので、通常は または のいずれかが NULL です。私は、この見解が欠けていることが判明したと思います。特にクロックチェーン全体を開始する場合。したがって、Linux のバージョンによって、答えは異なります。現在のソースであっても、一部のプラットフォーム ( など) はまだ古いメカニズムを使用しています。デバイスツリーをサポートしているとは思わない。dev_id
con_id
orion
orion
具体的な答えは、使用している Linux のバージョンとマシン (および場合によってはプラットフォーム) によって異なります。
参照: clkdev.c、clk.c
オープン ソース - 多くの変異があります。それらはすべて異なる計画を持っています。BSG 再イメージ化
参照: ARM clkdev に関する Russell Kings メッセージ、オリジナルは順序付けを意味しませんでした。