Linux動態頻率調節系統CPUFreq之二：核心（core）架構與API
上一節中，我們大致地講解了一下CPUFreq在用戶空間的sysfs介面和它的幾個重要的資料結構，同時也提到，CPUFreq子系統把一些公共的代碼邏輯組織在一起，構成了CPUFreq的核心部分，這些公共邏輯向CPUFreq和其它內核模塊提供了必要的API，像cpufreq_governor、cpufreq_driver等模塊通過這些API來完成一個完整的CPUFreq體系，這一節我們就來討論一下核心架構的代碼架構以及如何使用這些公共的API介面，
核心部分的代碼都在：/drivers/cpufreq/cpufreq.c中，本系列文章我使用的內核版本是3.10.0.
1. CPUFreq子系統的初始化
先看看具體的代碼：
static int __init cpufreq_core_init(void)
{
int cpu;
if (cpufreq_disabled())
return -ENODEV;
for_each_possible_cpu(cpu) {
per_cpu(cpufreq_policy_cpu, cpu) = -1;
init_rwsem(&per_cpu(cpu_policy_rwsem, cpu));
}
cpufreq_global_kobject = kobject_create_and_add("cpufreq", &cpu_subsys.dev_root->kobj);
BUG_ON(!cpufreq_global_kobject);
register_syscore_ops(&cpufreq_syscore_ops);
return 0;
}
core_initcall(cpufreq_core_init);
可見，在系統的啟動階段，經由initcall機制，cpufreq_core_init被呼叫，由它來完成核心部分的初始化作業，其中：
cpufreq_policy_cpu 是一個per_cpu變數，在smp的系統下，每個cpu可以有自己獨立的調頻policy，也可以所有的cpu都是用一種policy，這時候就有可能出現其中一個cpu管理著某個policy，而其它cpu因為也使用同一個policy，這些cpu的policy的就交由那個管理cpu代管，這個per_cpu變數就是用來記錄各個cpu的policy實際上是由那個cpu進行管理的，初始化時都被初始化為-1了，代表現在還沒有開始進行policy的管理，
接下來的kobject_create_and_add函式在/sys/devices/system/cpu這個節點下建立了一個cpufreq節點，該節點的下面以后會用來放置當前governor的一些配置引數，引數cpu_subsys是內核的一個全域變數，是由更早期的初始化時初始化的，代碼在drivers/base/cpu.c中：
struct bus_type cpu_subsys = {
.name = "cpu",
.dev_name = "cpu",
};
EXPORT_SYMBOL_GPL(cpu_subsys);
void __init cpu_dev_init(void)
{
if (subsys_system_register(&cpu_subsys, cpu_root_attr_groups))
panic("Failed to register CPU subsystem");
cpu_dev_register_generic();
}
這將會建立一根cpu總線，總線下掛著系統中所有的cpu，cpu總線設備的根目錄就位于：/sys/devices/system/cpu，同時，/sys/bus下也會出現一個cpu的總線節點，，cpu總線設備的根目錄下會依次出現cpu0，cpu1，...... cpux節點，每個cpu對應其中的一個設備節點，CPUFreq子系統利用這個cpu_subsys來獲取系統中的cpu設備，并在這些cpu設備下面建立相應的cpufreq物件，這個我們在后面再討論，
這樣看來，cpufreq子系統的初始化其實沒有做什么重要的事情，只是初始化了幾個per_cpu變數和建立了一個cpufreq檔案節點，下圖是初始化程序的序列圖：
圖 1.1 核心層初始化
2. 注冊cpufreq_governor
系統中可以同時存在多個governor策略，一個policy通過cpufreq_policy結構中的governor指標和某個governor相關聯，要想一個governor被policy使用，首先要把該governor注冊到cpufreq的核心中，我們可以通過核心層提供的API來完成注冊：
int cpufreq_register_governor(struct cpufreq_governor *governor)
{
int err;
......
governor->initialized = 0;
err = -EBUSY;
if (__find_governor(governor->name) == NULL) {
err = 0;
list_add(&governor->governor_list, &cpufreq_governor_list);
}
......
return err;
}
核心層定義了一個全域鏈表變數：cpufreq_governor_list，注冊函式首先根據governor的名稱，通過__find_governor()函式查找該governor是否已經被注冊過，如果沒有被注冊過，則把代表該governor的結構體添加到cpufreq_governor_list鏈表中，在上一篇中我們提到，目前的內核版本提供了5種governor供我們使用，我們可以通過內核的配置項來選擇需要編譯的governor，同時需要指定一個默認的governor，在cpufreq.h中，將會根據配置項的選擇，把CPUFREQ_DEFAULT_GOVERNOR宏指向默認governor結構體變數的地址，在注冊cpufreq_driver的階段需要使用這個宏來設定系統默認使用的governor，
3. 注冊一個cpufreq_driver驅動
與governor不同，系統中只會存在一個cpufreq_driver驅動，根據上一篇Linux動態頻率調節系統CPUFreq之一：概述的介紹，cpufreq_driver是平臺相關的，負責最終實施頻率的調整動作，而選擇作業頻率的策略是由governor完成的，所以，系統中只需要注冊一個cpufreq_driver即可，它只負責知道如何控制該平臺的時鐘系統，從而設定由governor確定的作業頻率，注冊cpufreq_driver驅動會觸發cpufreq核心的一系列額外的初始化動作，第一節所說的核心初始化作業非常簡單，實際上，更多的初始化動作在注冊cpufreq_driver階段完成，核心提供了一個API：cpufreq_register_driver來完成注冊作業，下面我們分析一下這個函式的作業程序：
int cpufreq_register_driver(struct cpufreq_driver *driver_data)
{
......
if (cpufreq_disabled())
return -ENODEV;
if (!driver_data || !driver_data->verify || !driver_data->init ||
((!driver_data->setpolicy) && (!driver_data->target)))
return -EINVAL;
該API只有一個引數：一個cpufreq_driver指標，driver_data，該結構事先在驅動的代碼中定義，呼叫該API時作為引數傳入，函式先判斷系統目前是否禁止了調頻功能，然后檢查cpufreq_driver的幾個回呼函式是否被實作，由代碼可以看出，verify和init回呼函式必須要實作，而setpolicy和target回呼則至少要被實作其中的一個，這幾個回呼的作用請參考本系列的第一篇文章，接下來：
write_lock_irqsave(&cpufreq_driver_lock, flags);
if (cpufreq_driver) {
write_unlock_irqrestore(&cpufreq_driver_lock, flags);
return -EBUSY;
}
cpufreq_driver = driver_data;
write_unlock_irqrestore(&cpufreq_driver_lock, flags);
檢查全域變數cpufreq_driver是否已經被賦值，如果沒有，則傳入的引數被賦值給全域變數cpufreq_driver，從而保證了系統中只會注冊一個cpufreq_driver驅動，然后：
ret = subsys_interface_register(&cpufreq_interface);
......
......
register_hotcpu_notifier(&cpufreq_cpu_notifier);
通過subsys_interface_register給每一個cpu建立一個cpufreq_policy，最后注冊cpu hot plug通知，以便在cpu hot plug的時候，能夠動態地處理各個cpu policy之間的關系（比如遷移負責管理的cpu等等），這里要重點討論一下subsys_interface_register的程序，回到第一節的內容，我們知道初始化階段，cpu_subsys被建立，從而每個cpu都會在cpu總線設備下建立一個屬于自己的設備：sys/devices/system/cpu/cpux，subsys_interface_register負責在cpu_subsys子系統的子設備下面注冊公共的介面，我們看看引數cpufreq_interface的定義：
static struct subsys_interface cpufreq_interface = {
.name = "cpufreq",
.subsys = &cpu_subsys,
.add_dev = cpufreq_add_dev,
.remove_dev = cpufreq_remove_dev,
};
subsys_interface_register函式的代碼我就不再展開了，它的大致作用就是：遍歷子系統下面的每一個子設備，然后用這個子設備作為引數，呼叫cpufrq_interface結構的add_dev回呼函式，這里的回呼函式被指向了cpufreq_add_dev，它的具體作業方式我們在下一節中討論，
driver注冊完成后，驅動被保存在全域變數cpufreq_driver中，供核心層使用，同時，每個cpu也會建立自己的policy策略，governor也開始作業，實時地監控著cpu的負載并計算合適的作業頻率，然后通過driver調整真正的作業頻率，下圖是cpufreq_driver注冊程序的序列圖：
4. 為每個cpu建立頻率調整策略（policy）
為每個cpu建立頻率調整策略實在注冊cpufreq_driver階段的subsys_interface_registe函式中完成的，上一節已經提到，該函式最侄訓呼叫cpufreq_add_dev回呼函式，現在展開這個函式分析一下：
因為subsys_interface_registe會列舉各個cpu設備，不管該cpu處于offline還是online狀態，cpufreq_add_dev都會被呼叫，所以函式的一開始，判斷如果cpu處于offline狀態，直接回傳，
static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
{
......
if (cpu_is_offline(cpu))
return 0;
如果是smp系統，本cpu的policy可能和其他cpu共同使用同一個policy，并委托另一個叫做管理cpu的cpu進行管理，下面的代碼判斷這種情況，如果已經委托別的cpu管理，則直接回傳，核心層定義了另一個per_cpu變數：cpufreq_cpu_data，用來保存各個cpu所使用的cpufreq_policy結構的指標，cpufreq_cpu_get函式實際上就是通過這個per_cpu變數，獲取該指標，如果該指標非0，代表該cpu已經建立好了它自身的policy（可能是在他之前的管理cpu建立policy期間一并建立的），
policy = cpufreq_cpu_get(cpu);
if (unlikely(policy)) {
cpufreq_cpu_put(policy);
return 0;
}
因為cpu hot plug期間，cpufreq_add_dev也會被呼叫，下面的代碼片段檢測該cpu之前是否被hot-unpluged過，如果是，找到其中一個相關的cpu（這些相關的cpu都委托給同一個托管它cpu進行管理，呼叫cpufreq_add_policy_cpu函式，該函式只是簡單地建立一個cpufreq鏈接，鏈接到管理cpu的cpufreq節點，
for_each_online_cpu(sibling) {
struct cpufreq_policy *cp = per_cpu(cpufreq_cpu_data, sibling);
if (cp && cpumask_test_cpu(cpu, cp->related_cpus)) {
read_unlock_irqrestore(&cpufreq_driver_lock, flags);
return cpufreq_add_policy_cpu(cpu, sibling, dev);
}
}
當這是系統初始化階段第一次呼叫cpufreq_add_dev時（subsys_interface_register列舉到的第一個cpu，通常就是cpu0），cpufreq_cpu_data應該為NULL，所以我們要為這樣的cpu分配一個cpufreq_policy結構，并初始化該policy所管理的cpu，包括online的cpus欄位和online+offline的cpu_related欄位，并把自己設定為這個policy的管理cpu，使用默認governor初始化policy->governor欄位，同時吧自己加入到online的cpus欄位中：
policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
if (!policy)
goto nomem_out;
if (!alloc_cpumask_var(&policy->cpus, GFP_KERNEL))
goto err_free_policy;
if (!zalloc_cpumask_var(&policy->related_cpus, GFP_KERNEL))
goto err_free_cpumask;
policy->cpu = cpu;
policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
cpumask_copy(policy->cpus, cpumask_of(cpu));
/* Initially set CPU itself as the policy_cpu */
per_cpu(cpufreq_policy_cpu, cpu) = cpu;
接下來初始化一個供kobject系統注銷時使用的同步變數，初始化一個workqueue，某些時候不能馬上執行對該policy的更新操作，可以使用該workqueue來延遲執行，
init_completion(&policy->kobj_unregister);
INIT_WORK(&policy->update, handle_update);
接著，呼叫cpufreq_driver的init回呼，進一步初始化該policy：
ret = cpufreq_driver->init(policy);
if (ret) {
pr_debug("initialization failed\n");
goto err_set_policy_cpu;
}
在上述驅動的初始化內部，應該完成以下作業：
- 設定該cpu的最大和最小作業頻率
- 設定該policy的最大和最小作業頻率
- 設定該policy可供調節的頻率檔位
- 設定cpu調節頻率時的延遲時間特性
- 該policy可以管理的cpu個數（policy->cpus）
繼續：
/* related cpus should atleast have policy->cpus */
cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
注釋已經寫的很清楚了，把online的cpu加到代表online+offline的related欄位中，接著，剔除offline的cpu：
cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
然后，發出CPUFREQ_START通知：
blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
CPUFREQ_START, policy);
如果是hot-plug加入的cpu，找出它上次使用的governor：
#ifdef CONFIG_HOTPLUG_CPU
gov = __find_governor(per_cpu(cpufreq_cpu_governor, cpu));
if (gov) {
policy->governor = gov;
pr_debug("Restoring governor %s for cpu %d\n",
policy->governor->name, cpu);
}
#endif
最后，建立cpu設備下的sysfs檔案節點：cpufreq，它的完整路徑是：/sys/devices/system/cpu/cpux/cpufreq，同時，在他的下面，相應的sysfs節點也同時被建立，節點的內容請參考本系列的第一篇文章：Linux動態頻率調節系統CPUFreq之一：概述：
ret = cpufreq_add_dev_interface(cpu, policy, dev);
至此，一個cpu的policy建立完成，它的頻率限制條件、使用的governor策略，sysfs檔案節點都已經建立完成，需要注意點是，系統中有多少個cpu，cpufreq_add_dev函式就會被呼叫多少次，最后，每個cpu都會建立自己的policy，當然，也有可能只有部分cpu建立了真正的policy，而其它cpu則委托這些cpu進行policy的管理，關于這一點，一開始讀代碼的時候可能有點困擾，為了搞清楚他們之間的關系，我們再跟入cpufreq_add_dev_interface函式看看：
static int cpufreq_add_dev_interface(unsigned int cpu,
struct cpufreq_policy *policy,
struct device *dev)
{
......
/* prepare interface data */
ret = kobject_init_and_add(&policy->kobj, &ktype_cpufreq,
&dev->kobj, "cpufreq");
......
/* set up files for this cpu device */
drv_attr = cpufreq_driver->attr;
while ((drv_attr) && (*drv_attr)) {
ret = sysfs_create_file(&policy->kobj, &((*drv_attr)->attr));
if (ret)
goto err_out_kobj_put;
drv_attr++;
}
函式的一開始，建立cpufreq檔案節點，然后在它的下面再建立一系列節點，用戶可以通過這些檔案節點控制該policy的一些引數，這不是我們的重點，我們看下面這一段代碼：
for_each_cpu(j, policy->cpus) {
per_cpu(cpufreq_cpu_data, j) = policy;
per_cpu(cpufreq_policy_cpu, j) = policy->cpu;
}
前面的代碼已經設定了該policy所管理的online cpu：policy->cpus，通過兩個per_cpu變數，這里把每個online cpu的policy都設定為了本cpu（管理cpu）的policy，并且把所有online的cpu的管理cpu也指定為了本cpu，接下來，cpufreq_add_dev_symlink被呼叫，所有policy->cpus指定的cpu會建立一個cpufreq鏈接，指向本cpu（管理cpu）的真實cpufreq節點：
ret = cpufreq_add_dev_symlink(cpu, policy);
注意，假如這時的cpu是cpu0，也就是說，其它cpu的cpufreq_add_dev還沒有被呼叫，但是在cpufreq_cpu_data中，與之對應的policy指標已經被賦值為cpu0所對應的policy，這樣，回到cpufreq_add_dev函式的開頭部分，當接下其它被認為使用cpu0托管他們的policy的cpu也會進入cpufreq_add_dev函式，但是，因為cpufreq_cpu_data中對應的policy已經在cpu0的建立階段被賦值，所以這些cpu他們不會走完所有的流程，在函式的開頭的判斷部分，判斷cpufreq_cpu_data中cpu對應的policy已經被賦值，就直接回傳了，
接著往下看cpufreq_add_dev_interface的代碼：
memcpy(&new_policy, policy, sizeof(struct cpufreq_policy));
/* assure that the starting sequence is run in __cpufreq_set_policy */
policy->governor = NULL;
/* set default policy */
ret = __cpufreq_set_policy(policy, &new_policy);
policy->user_policy.policy = policy->policy;
policy->user_policy.governor = policy->governor;
通過__cpufreq_set_policy函式，最終使得該policy正式生效，到這里，每個cpu的policy已經建立完畢，并正式開始作業，關于__cpufreq_set_policy的代碼這里就不展開了，我只給出它的序列圖：
5. 其它API
cpufreq的核心層除了提供上面幾節討論的注冊governor，注冊cpufreq_driver等API外，還提供了其他一些輔助的API，以方便其它模塊的使用，
- int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list);
- int cpufreq_unregister_notifier(struct notifier_block *nb, unsigned int list);
以上兩個API用于注冊和注銷cpufreq系統的通知訊息，第二個引數可以選擇通知的型別，可以有以下兩種型別：
-
CPUFREQ_TRANSITION_NOTIFIER 收到頻率變更通知
-
CPUFREQ_POLICY_NOTIFIER 收到policy更新通知
-
int cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation); -
int __cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation);
以上兩個API用來設定cpu的作業頻率，區別在于cpufreq_driver_target是帶鎖的版本，而__cpufreq_driver_target是不帶鎖的版本，如果確定是在governor的背景關系中，使用不帶鎖的版本，否則需要使用帶鎖的版本，
- void cpufreq_verify_within_limits(struct cpufreq_policy *policy, unsigned int min, unsigned int max)；
這個API用來檢查并重新設定policy的最大和最小頻率，
- int cpufreq_update_policy(unsigned int cpu);
這個API用來觸發cpufreq核心進行policy的更新操作，
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/4940.html
標籤：嵌入式
上一篇：Linux動態頻率調節系統CPUFreq之一：概述【轉】
下一篇：樹莓派學習P1（安裝與連接）