dvfs--Dynamic Voltage Frequency adjustment

Reprinted from Http://blog.chinaunix.net/uid-24666775-id-3328064.html

Linux Low-power Research also for some time, the basic idea of low-power implementation (mainly divided into mechanisms and strategies), this period of work is mainly in the mechanism. The main mechanism for the time being: CPU level, device drive level, system platform level. The management grain degree unceasingly increases, forms the three carriages to drive the situation.

CPU Level : The main implementation is relatively easy in the system in the target is frequent occurrence, higher granularity of power state changes, the main implementation of the idle, including today's main want to talk about the dynamic frequency.

device-driven level : mainly to achieve a single device-driven management (Suspend,resume, etc.), through the system monitoring will be idle equipment, through the SYS file directory dynamically from user state to the management of a single drive device

, placed in the power-saving mode.

system Platform Level : The goal is to manage large, uncommon major power-state changes to reduce the power consumption of product devices after a long period of inactivity. The main implementation is based on the support of the Linux kernel APM technology to achieve the entire system of sleep/recovery (sleeping)

These levels are not independent of each other, are mutually overlapping, such as the system platform-level sleep will inevitably involve the sleeping mode of the CPU and device-driven hang, and the realization of the dynamic frequency of the CPU itself in addition to the support of the external drive as the frequency changes to make corresponding adaptation activities. So the rating here is just a rough range, logical layering.

Some time ago also investigated IBM and Monta Vista made that set of DPM (Dynamic power Management) mechanism, read a lot of papers and views, the total feeling is too complex and is not very practical, feeling gimmicks outweigh actual effects, (so this mechanism has not yet been able to enter the core of the mainline), to the point, or focus on the next Cpufreq technology.

1. Why to Cpufreq.

about whether to implement Cpufreq technology, I also tangled, one reason is: At that time how the kernel provides such a set of dynamic frequency conversion mechanism is still not understood, only think it should be very troublesome, because it involves peripheral-driven parameter updates, another reason is: In the SEP4020 of this volume of the processor running Linux , even if the operation at the highest frequency of processing capacity may not be very rich, I give it has no meaning to reduce frequency. After struggling to realize it, I also gave myself a few reasons:

N Although the CPU in the board level has not been the main source of power, but still occupy a pivotal position in the end is a few ma several Ma buckle, frequency reduction must be in a certain program to save power so why I do not adopt.

N Refine the granularity of power management to provide more power-saving mechanisms for applications

N for ordinary applications, the system can be run in the maintenance of the lowest frequency platform operation, in the processing task, the frequency conversion mechanism will automatically switch to the appropriate high frequency, and at the end of the task to return to the low frequency of power, so that the resolution of my second doubt before.

øsep4020 power consumption at 88M board level: 222mA

øsep4020 power consumption at 56M board level: 190mA, Lower 14%

øsep4020 power consumption at 32M board level: 160mA, Lower 28%

n Some of the work that we've been needing to do, but we've never had the power to do it.

Ø inverter will involve a large number of modules of the reconfiguration of parameters, as the original CPU, we need to fully grasp these parameters

Ø full understanding of these parameters can optimize the existing system to improve the efficiency of the overall system, such as using the discovery of some parameters or too conservative (Sdram,nand), our common configuration in the system down to 32M can still function.

N Feasibility argument no problem: accidentally see Armkiller provided by the NAND driver code in the implementation of inverter (thank Armkiller here), the online article is very few, so read the Linux kernel source from the/documentation/ Cpufreq, there is probably a certain understanding of this mechanism (Linux documentation is a good dongdong), but also see some processor manufacturers for their own CPU has been implemented code, such as the SA1100,PXA series.

2. The mechanism of this cpufreq technology provided by the kernel

N Purpose:

Frequency conversion technology refers to the CPU hardware itself to support the operation at different frequencies, the system in the course of operation can be changed at any time depending on the system load situation dynamically in these different operating frequencies to switch between the performance and power consumption to achieve both the goal.

N Source:

Although multiple processor manufacturers provide support for frequency conversion technology, there is a slight or even huge difference in the way the hardware is implemented and used. This makes it necessary for each processor manufacturer to add code to the kernel in accordance with its special hardware implementation and usage, so that the inverter technology in its products is supported and used in Linux. However, the consequence of this kernel development model is that the implementation code for each manufacturer is scattered across the Linux kernel code tree, there is no code shared between the various implementations, which is costly to maintain the kernel and to support new products in the future, and leads directly to The birth of the Cpufreq kernel subsystem.

N Management Policy:

There are five kinds of management strategies for frequency within Linux Userspace,conservative,ondemand,powersave and performance

Ø1.PERFORMANCE:CPU will be fixed to the maximum operating frequency of its support;

Ø2.POWERSAVE:CPU will work on the minimum operating frequency that it supports. Therefore, both of these governors are static governor, that is, when using them, the CPU's operating frequency will not be adjusted according to the dynamic changes of the system's load. The two kinds of governors correspond to two extreme scenarios, using Performance governor embody the greatest pursuit of system performance, and the use of PowerSave governor is the greatest pursuit of low power consumption of the system.

Ø3.userspace: The earliest cpufreq subsystem provides this flexibility to users through userspace governor. The system gives the decision power of the frequency conversion policy to the user State application, and provides the corresponding interface for the user state application to adjust the CPU running frequency usage. (You can use Dominik and other people to develop the Cpufrequtils toolkit)

Ø4.ondemand:userspace is a kernel state of detection, low efficiency. OnDemand is what people have long wanted to see, a governor that works completely in a kernel state and can sample and analyze the system's load at a finer granularity of time.

The initial implementation of the Ø5.conservative:ondemand governor is to tune down to the next available frequency in an optional frequency range. The dominant idea of this frequency reduction strategy is to minimize the negative impact on the performance of the system, so that the system performance can not be reduced rapidly in a short time to affect the user experience. But after the initial implementation of the OnDemand governor was released in the community, the results of a large number of users showed that the fear was actually superfluous, and OnDemand governor's choice of target frequencies could be more radical when it comes to frequency reduction. Therefore, the latest OnDemand governor in frequency reduction will be at all optional frequencies at a time to ensure that the CPU can work at more than 80% of the load, of course, if not any one of the optional frequency to meet the requirements of the CPU will choose to support the minimum operating frequency. The test results of a large number of users show that the new algorithm can achieve more efficient energy saving without affecting the performance of the system. After the algorithm was improved, the name of the OnDemand governor did not change, and OnDemand governor's initial implementation was preserved, and it was named Conservative because of the conservatism of its algorithm.

OnDemand Lower frequency more radical, conservative lower frequency is relatively slow and conservative, the fact that the effect of using OnDemand is also better.

n Cpufreq the interface that is rendered in user state:

Øcpuinfo_max_freq Cpuinfo_min_freq: The maximum operating frequency and minimum operating frequency supported by CPU hardware are given respectively,

The øcpuinfo_cur_freq will read the CPU's current operating frequency from the CPU hardware registers.

Øgovernor Select the proper frequency of operation only in the frequency range determined by Scaling_max_freq and Scaling_min_freq.

Øscaling_cur_freq returns the current frequency of CPU running Cpufreq module cache without checking the CPU hardware registers.

Øscaling_available_governors will tell the user what governors are currently available for users to use

Øscaling_driver Displays the frequency converter driver used by the CPU

Øscaling_governor will display the current management strategy, where Echo's other types will change accordingly.

Øscaling_setspeed: Need to switch governor type to userspace, will appear, to this file echo value, will switch the frequency

The following is the configuration file that appears under the OnDemand folder that was generated after switching governor to OnDemand. (Conservative will not say, not ready to use)

Øsampling_rate: Sample interval currently in use, Unit: microseconds

Øsampling_rate_min: Minimum sampling interval allowed

Øsampling_rate_max: Maximum sample interval allowed

Øup_threshold: Indicates that the OnDemand governor automatically increases CPU frequency when the system load exceeds what percentage

The Øignore_nice_load:ignore_nice_load file can be set to 0 or 1 (0 is the default setting). When this parameter is set to 1 o'clock, any processor with a "nice" value does not count to the total processor utilization. When set to 0 o'clock, all processors are counted into utilization.

Øsampling_down_factor:

N Use Method:

ØCD sys/devices/system/cpu/cpu0/cpufreq/Directory

echo 32000 > Scaling_min_freq set Minimum operating frequency (khz,32000~88000)

If you want to use the userspace policy

# echo Userspace > Scaling_governor Switching mode of operation is userspace

echo 64000 > Scaling_setspeed set to desired frequency of work (khz)

If you want to use the OnDemand policy

# echo OnDemand > Scaling_governor Switching mode of operation is OnDemand

3. How to achieve.

first of all need to do some miscellaneous work, modify Kconfig makefile the system screen Cpufreq open, for us, the main core has two parts:

System Related: Main have cpu,timer (change frequency must update system timer, otherwise the system time is not allowed), SDRAM and so on.

The main thing is to implement the following structure:

static struct Cpufreq_driver Sep4020_driver =

{

. Flags = Cpufreq_sticky,

. Verify = Sep4020_verify_speed,

. target = Sep4020_target,

. get = Sep4020_getspeed,

. init = Sep4020_cpu_init,

. Name = "SEP4020 freq",

};

The code is still very simple, many details are not considered, so the specific temporarily first, we can first refer to PXA and sa1100 implementation.

And then there is the drive of the frequency effect:

In simple terms, the system will call Cpufreq_notify_transition (&freqs, Cpufreq_postchange) when it changes CPU frequency, and the function, which is mounted on this CPU, emits a signal to all the drivers, When the driver receives this signal, it invokes the corresponding handler function.

Here the implementation of the serial port is simplified, as follows:

#ifdef Config_cpu_freq

static int sep4020_serial_cpufreq_transition (struct notifier_block *nb, unsigned long val, void *data)

{

PRINTK ("In the serial cpufreq_transition/n");

int pmcr_pre;

unsigned long cpu_clk,baud,baudh,baudl;

Pmcr_pre = * (volatile unsigned long*) Pmu_pmcr_v;

if (Pmcr_pre > 0x4000)

CPU_CLK = (pmcr_pre-0x4000) *8000000;

Else

CPU_CLK = (pmcr_pre) *4000000;

baud = cpu_clk/16/115200;

Baudh = Baud >>8;

Baudl = baud&0xff;

* (volatile unsigned char*) Uart0_lcr_v |= (0x80);

* (volatile unsigned char*) Uart0_dlbl_v = baudl;

* (volatile unsigned char*) uart0_dlbh_v = Baudh;

* (volatile unsigned char*) Uart0_lcr_v &= ~ (0x80);

PRINTK ("In the serial cpufreq_transition/n");

return 0;

}

static inline int sep4020_serial_cpufreq_register (void)

{

Sep4020_serial_freq_transition.notifier_call = sep4020_serial_cpufreq_transition;

Return Cpufreq_register_notifier (&sep4020_serial_freq_transition,

Cpufreq_transition_notifier);

}

static inline void Sep4020_serial_cpufreq_deregister (void)

{

Cpufreq_unregister_notifier (&sep4020_serial_freq_transition,

Cpufreq_transition_notifier);

}

#else

#endif

4. Effect

Open Ondeman mode under SYS, string on ammeter:

1. Plate-level current from 220mA to 160mA (because at this time the kernel detection system without load, frequency reduction)

2. Execute a nandflash copy command, copy a 5M or so file to another folder,

3. In the copy execution time in 3 seconds (I give the kernel the scan period of 2.5 seconds) system found load, frequency, current from 160mA to 220mA (visible is the system's highest frequency)

4. Subsequent copies of the entire process of the current to maintain a 220mA

5. Shortly after the end of the copy (2-3S), the system current jumps to 160mA.

1. Kernel option:

Linux dynamic Variable Frequency management (CPUFREQ) provides the operating system-level frequency conversion function, and requires the user layer to formulate and execute the strategy. Cpufreq background Process CPUFREQD is used to monitor the operation of the system, and according to different conditions to set the CPU's operating frequency.

To use background process CPUFREQD at the user layer, you first need to select the CPU Frequency scaling feature option when configuring the Linux kernel compilation option, which has a number of sub options, including Governor selection and whether to enable CPUfreq Debugging. CPUfreq has five kinds of governor (will be introduced in 10.1.3), to make cpufreqd normal operation, you need to choose at least performance governor; in the testing phase, often want to see the system frequency conversion information, then need to enable CPUfreq Debugging. On the premise of the Enable CPUfreq debugging, the Linux startup parameters in U-boot Bootargs plus loglevel=8 cpufreq.debug=<value> You can see the appropriate level of running information for the cpufreq. The value of <value> can be 1, 2, 4, or their or (3, 5, 6, 7), as follows:

1 to activate CPUfreq core debugging,

2 To activate CPUfreq drivers debugging (this is related to SEP4020 debugging), and

4 to activate CPUfreq governor debugging

Background process CPUFREQD requires three libraries, cpufreqd-2.2.1, cpufrequtils-002, and sysfsutils-2.1.0, all of which are GNU free Open-source software, and we cpufreqd-2.2.1, Cpufrequtils-002 made some changes, because the compilation of these three libraries is still quite troublesome, so I was released in the cpufreqd of the development package on the arm platform for two times to compile, so reduced a lot of work (to stand on the shoulders of giants, First of all, you can June is the official FTP download this package.

The following is an introduction to the cross compilation and installation of CPUFREQD on ARM and the installation and operation of methods on the target board.

Report:

When the DVFS to do aging test when the condition of panic, this may be in the configuration of the core voltage when the condition of panic, so in the configuration of the core voltage can be a little higher. General voltage fluctuations are up and down 5%. If not, you can be a little taller.