Originally, it is a part of the Linux Kernel source code, so it will be treated as GPLv2 (recognition that it should be).
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing
https://www.kernel.org/doc/html/latest/cpu-freq/core.html I will read.
General description of the CPUFreq core and CPUFreq notifiers
Authors: Dominik Brodowski [email protected] David Kimdon [email protected] Rafael J. Wysocki [email protected] Viresh Kumar [email protected]
The CPUFreq core code is located in drivers/cpufreq/cpufreq.c. This cpufreq code offers a standardized interface for the CPUFreq architecture drivers (those pieces of code that do actual frequency transitions), as well as to “notifiers”. These are device drivers or other part of the kernel that need to be informed of policy changes (ex. thermal modules like ACPI) or of all frequency changes (ex. timing code) or even need to force certain speed limits (like LCD drivers on ARM architecture). Additionally, the kernel “constant” loops_per_jiffy is updated on frequency changes here.
The CPUFreq core code is located in derivers / cpufreq / cpufreq.c. This CPUFreq core code provides a standard interface to CPUFreq architecture drivers. (Part of the code performs frequency changes) Also includes "notifiers" as well. Depending on the device driver or part of the kernel, policy changes (eg thermal modules like ACPI), all frequency changes (timing code etc.) or certain speed limit enforcement (eg in ARM architecture) LCD driver) is required. Furthermore, the kernel constant "loops_per_jiffy" is updated at the frequency change timing.
Reference counting of the cpufreq policies is done by cpufreq_cpu_get and cpufreq_cpu_put, which make sure that the cpufreq driver is correctly registered with the core, and will not be unloaded until cpufreq_put_cpu is called. That also ensures that the respective cpufreq policy doesn’t get freed while being used.
Reference counters for cpufreq policies are implemented by cpufreq_cpu_get () and cpufreq_cpu_put (). This will cause the cpufreq driver to be properly registered with the core and will not be unloaded until cpufreq_put_cpu () is called. This ensures that each cpufreq policy is not released during use.
CPUFreq notifiers conform to the standard kernel notifier interface. See linux/include/linux/notifier.h for details on notifiers.
CPUFreq notifiers follow the standard kernel notifier interface. For more information on notifiers, see linux / include / linux / notifier.h.
There are two different CPUFreq notifiers - policy notifiers and transition notifiers.
There are two different CPU Freq notifiers. One is policy notifiers and the other is transition notifiers.
2.1 CPUFreq policy notifiers
These are notified when a new policy is created or removed. There is a notify when a new policy is created or deleted.
The phase is specified in the second argument to the notifier. The phase is CPUFREQ_CREATE_POLICY when the policy is first created and it is CPUFREQ_REMOVE_POLICY when the policy is removed.
This phase is shown in the second argument to the notifier. This phase is CPUFREQ_CREATE_POLCY when the policy was first created. And CPUFREQ_REMOVE_POLICY when the policy is deleted.
The third argument, a void *pointer, points to a struct cpufreq_policy consisting of several values, including min, max (the lower and upper frequencies (in kHz) of the new policy).
The third argument is of type void * pointer. This is a pointer to the cpufreq_policy structure, which consists of several values, including the min, max frequencies (in kHz) of the new policy.
2.2 CPUFreq transition notifiers
These are notified twice for each online CPU in the policy, when the CPUfreq driver switches the CPU core frequency and this change has no any external implications.
In policy, it may notify again for each online CPU. This is because the CPU Freq driver switches CPU core freency and this change has no external impact.
The second argument specifies the phase - CPUFREQ_PRECHANGE or CPUFREQ_POSTCHANGE.
The second argument indicates the phase. CPUFREQ_PRECHANGE or CPUFREQ_POSTCHANGE.
The third argument is a struct cpufreq_freqs with the following values:
The third argument is a cpufreq_freqs structure that contains the following values:
cpu number of the affected CPU
old old frequency
new new frequency
flags flags of the cpufreq driver
For details about OPP, see Documentation/power/opp.rst
See Documentation / power / opp.rst for more information on OPP.
dev_pm_opp_init_cpufreq_table -
This function provides a ready to use conversion routine to translate the OPP layer’s internal information about the available frequencies into a format readily providable to cpufreq.
This function makes available a conversion routine that converts the internal information of the OPP layers about the currently enabled frequencies into a format that cpufreq can decipher.
Warning Do not use this function in interrupt context.
Do not use this function in the interrupt context.
Example
soc_pm_init()
{
/* Do things */
r = dev_pm_opp_init_cpufreq_table(dev, &freq_table);
if (!r)
policy->freq_table = freq_table;
/* Do other things */
}
Note This function is available only if CONFIG_CPU_FREQ is enabled in addition to CONFIG_PM_OPP.
This function is valid only when CONFIG_CPUFREQ is enabled and CONFIG_PM_OPP is also added.
dev_pm_opp_free_cpufreq_table
Free up the table allocated by dev_pm_opp_init_cpufreq_table
Release the table allocated by dev_pm_opp_init_cpufreq_table.
Recommended Posts