CPU Dynamic FM (Linux 3.14.0) one

I recently made a project about CPU dynamic FM, and I'm working on it.
Code version: 3.14.0 (the version number can be seen in the top-level makefile of the Linxu directory)
Device: A manufacturer's mobile phone based on the Android 4.4 native system (The following XXX represents the device)
There are a lot of blog posts on the dynamic FM, all of which are first introduced to the whole framework, then understand the data structure, and finally analyze the key code, which is a very suitable and gradual process for learning.
While I am in touch with this project, is the need to look at the code, before the dynamic FM know nothing, so write notes according to my own learning process will be more natural.
That is, the idea of this article is-encounter specific problems, learning the relevant code, the final overall summary.

The first question that the

encounters is: How does the user intuitively see the CPU frequency?
This problem Baidu a bit to know: through the Sysfs file system, the specific directory is:
/sys/devices/system/cpu/cpu0/cpufreq/
This directory has the following properties files (different devices may differ slightly):
Affected_cpus
Cpuinfo_cur_freq
cpuinfo_max_freq
cpuinfo_min_freq
cpuinfo_transition_latency
Interactive
Related_cpus
scaling_available_frequencies
scaling_available_governors
Scaling_cur_ Freq
Scaling_driver
Scaling_governor
scaling_max_freq
scaling_min_freq
Scaling_setspeed
Stats
We only look at ourselves more concerned and commonly used some, where the prefix is the scaling property file that represents several properties that the software can adjust, the prefix is Cpuinfo's properties file represents several properties supported by the hardware.
about software tuning and hardware support, this should be a relationship: the final operating frequency of the device is determined by the software, and the frequency of the software regulation must be supported by the hardware (i.e. CPU), and further, the scope of software regulation must be a subset of the frequency range supported by the hardware.
Assume:
The value of Cpuinfo_max_freq is 1901000, the maximum hardware support frequency
Cpuinfo_min_freq is 900000, and the minimum frequency that the hardware supports
Then the scope of software regulation can only be between 900000~1901000, and is a certain number of values, with Scaling_avaliable_frequencies can be viewed.

We also see in the SYSFS, such as Scaling_available_governors, Scaling_driver and other interface, in the CPUFREQ subsystem (hereinafter referred to as Cpufreq), policy, governor, Driver is a few of the more core concepts. The ultimate goal of cpufreq is to dynamically adjust the frequency, as mentioned earlier, the software regulation is a certain range, and the range (can be called the frequency table) is a subset of hardware support, the maximum and minimum value of this frequency table is determined by policy , Of course, different policy uses a different range of frequency tables. OK, now we use policy to set the range of the frequency table, corresponding to the SYSFS under the Scaling_min_freq and Scaling_max_freq,governor will choose a value from the frequency table the most CPU of the final operating frequency . Governor can be understood as "regulators" and see Scaling_available_governors to know which governor the device supports, such as my device support OnDemand userspace interactive Performance, and so on, each governor has a different frequency selection criteria, such as OnDemand will be based on the workload of the system to select the frequency, if the current workload more than a certain threshold, the frequency table selection of the maximum frequency, Several other governor have the opportunity to introduce later. Assuming a governor chooses a frequency from the frequency table based on a mechanism, the driver is responsible for setting the frequency of the governor selection to the CPU's operating frequency .

Policy, Governor, driver is the core module in Cpufreq, corresponding to the structure cpufreq_policy, Cpufreq_governor, cpufreq_driver in the source code, There is no intention to interpret the members of the struct one by one.

To summarize:
1, the hardware has a frequency table, indicating the hardware support all the frequency (related to the hardware platform);
I should find the xxx,cpufreq-table = <111 222 333>; in the corresponding DTS file. (XXX is a manufacturer name, the number in table is meaningless)
2. The policy specifies the maximum and minimum frequency of software regulation, and updates the frequency table in 1 (independent of the hardware platform);
3. Governor Select a frequency from the Cpufreq table as the frequency at which the CPU will work (independent of the hardware platform);
4, the dirty live dirty to driver,driver responsible for setting the CPU operating frequency. (related to hardware platform)

CPU Dynamic FM (Linux 3.14.0) one