Skip to content

GitLab

Switch branch/tag
  1. 12 Jan, 2006 5 commits
  3. 09 Jan, 2006 2 commits
  5. 06 Jan, 2006 3 commits
  7. 07 Dec, 2005 3 commits
    • Venkatesh Pallipadi's avatar
      [CPUFREQ] CPU frequency display in /proc/cpuinfo · 95235ca2
      Venkatesh Pallipadi authored 
      

What is the value shown in "cpu MHz" of /proc/cpuinfo when CPUs are capable of
changing frequency?

Today the answer is: It depends.
On i386:
SMP kernel - It is always the boot frequency
UP kernel - Scales with the frequency change and shows that was last set.

On x86_64:
There is one single variable cpu_khz that gets written by all the CPUs. So,
the frequency set by last CPU will be seen on /proc/cpuinfo of all the
CPUs in the system. What you see also depends on whether you have constant_tsc
capable CPU or not.

On ia64:
It is always boot time frequency of a particular CPU that gets displayed.

The patch below changes this to:
Show the last known frequency of the particular CPU, when cpufreq is present. If
cpu doesnot support changing of frequency through cpufreq, then boot frequency
will be shown. The patch affects i386, x86_64 and ia64 architectures.

Signed-off-by: Venkatesh Pallipadi<venkatesh.pallipadi@intel.com>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
      95235ca2
    • Mattia Dongili's avatar
      [CPUFREQ] Move PMBASE reading away and do it only once at initialization time · 9a7d82a8
      Mattia Dongili authored 
      

This patch moves away PMBASE reading and only performs it at
cpufreq_register_driver time by exiting with -ENODEV if unable to read
the value.
Signed-off-by: default avatarMattia Dongili <malattia@linux.it>
Acked-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
      9a7d82a8
    • Mattia Dongili's avatar
      [CPUFREQ] Measure transition latency at driver initialization · 1a10760c
      Mattia Dongili authored 
      

The attached patch introduces runtime latency measurement for ICH[234]
based chipsets instead of using CPUFREQ_ETERNAL. It includes
some sanity checks in case the measured value is out of range and
assigns a safe value of 500uSec that should still be enough on
problematics chipsets (current testing report values ~200uSec). The
measurement is currently done in speedstep_get_freqs in order to avoid
further unnecessary transitions and in the hope it'll come handy for SMI
also.
Signed-off-by: default avatarMattia Dongili <malattia@linux.it>
Acked-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: default avatarDave Jones <davej@redhat.com>

 speedstep-ich.c |    4 ++--
 speedstep-lib.c |   32 +++++++++++++++++++++++++++++++-
 speedstep-lib.h |    1 +
 speedstep-smi.c |    1 +
 4 files changed, 35 insertions(+), 3 deletions(-)
      1a10760c
  9. 06 Dec, 2005 1 commit
  11. 01 Dec, 2005 1 commit
  13. 30 Nov, 2005 1 commit
  15. 29 Nov, 2005 1 commit
  17. 21 Nov, 2005 1 commit
  19. 15 Nov, 2005 4 commits
  21. 14 Nov, 2005 1 commit
  23. 07 Nov, 2005 2 commits
  25. 31 Oct, 2005 9 commits
  27. 22 Oct, 2005 1 commit
  29. 21 Oct, 2005 1 commit
    • Dave Jones's avatar
      [PATCH] cpufreq: fix pending powernow timer stuck condition · 0213df74
      Dave Jones authored 
      

AMD recently discovered that on some hardware, there is a race condition
possible when a C-state change request goes onto the bus at the same
time as a P-state change request.

Both requests happen, but the southbridge hardware only acknowledges the
C-state change.  The PowerNow! driver is then stuck in a loop, waiting
for the P-state change acknowledgement.  The driver eventually times
out, but can no longer perform P-state changes.

It turns out the solution is to resend the P-state change, which the
southbridge will acknowledge normally.

Thanks to Johannes Winkelmann for reporting this and testing the fix.
Signed-off-by: default avatarMark Langsdorf <mark.langsdorf@amd.com>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0213df74
  31. 20 Oct, 2005 1 commit
  33. 10 Oct, 2005 1 commit
  35. 29 Sep, 2005 1 commit
  37. 27 Sep, 2005 1 commit

Imprint & Privacy Policy