Re: Control and Data Flow of DevFreq

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you Myungjoo.


On Mon, Apr 15, 2013 at 1:03 PM, <myungjoo.ham@xxxxxxxxx> wrote:
Hello,
 
 
Yes, I don’t see anything wrong in your summary.
 
The “data” part is intended be used by governors “exclusively”
The “profile” part is intended to be shared between governors and “devfreq” drivers.
 
Cheers,
MyungJoo.
 
 
Windows 메일에서 보냄
 
보낸 사람: Serge Yegiazarov
보낸 날짜: 2013년 4월 11일 목요일 오전 10:42
받는 사람: linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
참조: myungjoo.ham@xxxxxxxxxxx
 
I just want to make sure that I am properly understanding the control and data flow of DevFreq. Here is what I think I know: 

The connection between DevFreq and the hardware is made in two places: the first is in the add_device method which is declared and defined in devfreq.c but which is called in the driver of the device in question. This is where the "data" and "profile" pointers (which will later be used in the governor) are assigned to the representative devfreq struct. Since these are pointers, they can change dynamically as the hardware changes. The second place is in the update_devfreq method, in which DevFreq sends to the hardware the frequency decided on by the governor.

The connection between DevFreq and the governor is made in update_devfreq as well, where devfreq calls the main method of the governor (let's say it is simple-on-demand) by passing it a freq pointer and the devfreq struct. The devfreq struct contains "profile", which grants access to current_frequency, busy_time, and total_time. It also contains "data", which grants access to up_threshold and down_differential. To read the useful info in the profile, a call is made to its dev_status method, which is declared in the driver of the device (this is the only place where it can be said there's a direct connection between the governor and the device, although I guess it is debatable whether this should be considered a direct connection - other than this, all other connections must go through DevFreq first). 

After the governor decides on a frequency, it assigns it to the freq pointer, which is then passed back to the hardware also through the update_devfreq method.

Is this right?


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux