http://bugzilla.kernel.org/show_bug.cgi?id=8860





------- Comment #24 from [EMAIL PROTECTED]  2007-11-13 19:07 -------
Hi, Aliaksandr 
   The folliwng is added for the comment #23:
1. In the boot phase OSPM will detect the cpu frequency and store the result to
cpu_khz. The /proc/info will use the cpu_khz to display the cpu frequency
before the cpufreq module is loaded.
2. In the previous kernel(for example 2.6.12) the /proc/info continues using
the cpu_khz to display the cpu frequency after the cpufreq module is loaded.
When the P-state is changed, the OSPM will update the cpu_khz using the
function of cpufreq_scale.In this case even when the cpu is overclocked the
OSPM can update the cpu_khz correctly.
   In smp system when the CPUs run in different p-states , the /proc/info for
all cpus will display the same frequency.It is uncorrect. Of course there is no
problem when the all cpus run in the same P-states. 

   So in the current kernel the above method is discarded and  the /proc/info
displays the cpu freqency obtained from the P-state table. It can still display
the cpu frequency correctly when all cpus run in different p-states.
   Of course there appears a new problem that OS can't display the cpu
frequency correctly when overclocked.The problem can be solved by adding
frequency ratio for every cpu. The frequency ration can be defined as :
        ratio = cpu_max_khz / cpu_khz_p0_states
    cpu_max_khz is calculated in the function of calibrate_delay.
    cpu_khz_p0_states is the max frequency in P0-states.

But I think that it is unnecessary to fix this problem because the
floating calculation will be involved.(The floating calculation can be
avoided if two variables are added for every cpu. And it is complex).


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla

Reply via email to