linux.git/arch/x86/kernel/cpu, branch v2.6.26 Linux kernel source tree [CPUFREQ] Crusoe: longrun cpufreq module reports false min freq 2008-05-19T22:17:28+00:00 maximilian attems max@stro.at 2008-05-08T20:10:01+00:00 667ad4f70110357e8f024e81741c7bd1d7906e7d The longrun cpufreq module reports a false minimum frequency 3MHz on 300-600MHz Crusoe processor. This may be due to a calculation bug in the module. Original patch from Kaz Sasayama <kazssym@hypercore.co.jp> submitted as http://bugs.debian.org/468149 patch ported to x86 Cc: Kaz Sasayama <kazssym@hypercore.co.jp> Signed-off-by: maximilian attems <max@stro.at> Signed-off-by: Dave Jones <davej@redhat.com> 
The longrun cpufreq module reports a false minimum frequency 3MHz on
300-600MHz Crusoe processor.  This may be due to a calculation bug
in the module.

Original patch from Kaz Sasayama <kazssym@hypercore.co.jp>
submitted as http://bugs.debian.org/468149 patch ported to x86

Cc: Kaz Sasayama <kazssym@hypercore.co.jp>
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Dave Jones <davej@redhat.com>
[CPUFREQ] powernow-k8: improve error messages 2008-05-19T22:17:27+00:00 Mark Langsdorf mark.langsdorf@amd.com 2008-03-18T20:24:32+00:00 eba9fe93a2959ec7f195c47c9db6ce7b5114ce1f The most common error with powernow-k8 is an ACPI _PSS error caused either by failure to load the ACPI processor module or a bad parse of the _PSS object. Make the error message returned to the user in these situations more straightforward and easier to understand. -Mark Langsdorf Operating System Research Center AMD Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Dave Jones <davej@redhat.com> 
The most common error with powernow-k8 is an ACPI _PSS error
caused either by failure to load the ACPI processor module
or a bad parse of the _PSS object.  Make the error message
returned to the user in these situations more straightforward
and easier to understand.

-Mark Langsdorf
Operating System Research Center
AMD

Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Dave Jones <davej@redhat.com>
x86: cleanup PAT cpu validation 2008-05-08T13:43:51+00:00 Thomas Gleixner tglx@linutronix.de 2008-05-08T07:18:43+00:00 8d4a4300854f3971502e81dacd930704cb88f606 Move the scattered checks for PAT support to a single function. Its moved to addon_cpuid_features.c as this file is shared between 32 and 64 bit. Remove the manipulation of the PAT feature bit and just disable PAT in the PAT layer, based on the PAT bit provided by the CPU and the current CPU version/model white list. Change the boot CPU check so it works on Voyager somewhere in the future as well :) Also panic, when a secondary has PAT disabled but the primary one has alrady switched to PAT. We have no way to undo that. The white list is kept for now to ensure that we can rely on known to work CPU types and concentrate on the software induced problems instead of fighthing CPU erratas and subtle wreckage caused by not yet verified CPUs. Once the PAT code has stabilized enough, we can remove the white list and open the can of worms. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
Move the scattered checks for PAT support to a single function. Its
moved to addon_cpuid_features.c as this file is shared between 32 and
64 bit.

Remove the manipulation of the PAT feature bit and just disable PAT in
the PAT layer, based on the PAT bit provided by the CPU and the
current CPU version/model white list.

Change the boot CPU check so it works on Voyager somewhere in the
future as well :) Also panic, when a secondary has PAT disabled but
the primary one has alrady switched to PAT. We have no way to undo
that.

The white list is kept for now to ensure that we can rely on known to
work CPU types and concentrate on the software induced problems
instead of fighthing CPU erratas and subtle wreckage caused by not yet
verified CPUs. Once the PAT code has stabilized enough, we can remove
the white list and open the can of worms.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-fixes 2008-04-29T16:03:19+00:00 Linus Torvalds torvalds@linux-foundation.org 2008-04-29T16:03:19+00:00 1f43c5393033de90bac4410352b1d2a69dcbe7ef * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-fixes: x86: fix PCI MSI breaks when booting with nosmp x86: vget_cycles() __always_inline x86: add more boot protocol documentation bootprotocol: cleanup x86: fix warning in "x86: clean up vSMP detection" x86: !x & y typo in mtrr code 
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-fixes:
  x86: fix PCI MSI breaks when booting with nosmp
  x86: vget_cycles() __always_inline
  x86: add more boot protocol documentation
  bootprotocol: cleanup
  x86: fix warning in "x86: clean up vSMP detection"
  x86: !x & y typo in mtrr code
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq 2008-04-29T15:18:49+00:00 Linus Torvalds torvalds@linux-foundation.org 2008-04-29T15:18:49+00:00 44473d991332053eb3fea1e08f8a6ee2c6fb409c * git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] state info wrong after resume [CPUFREQ] allow use of the powersave governor as the default one [CPUFREQ] document the currently undocumented parts of the sysfs interface [CPUFREQ] expose cpufreq coordination requirements regardless of coordination mechanism 
* git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
  [CPUFREQ] state info wrong after resume
  [CPUFREQ] allow use of the powersave governor as the default one
  [CPUFREQ] document the currently undocumented parts of the sysfs interface
  [CPUFREQ] expose cpufreq coordination requirements regardless of coordination mechanism
proc: remove proc_root from drivers 2008-04-29T15:06:18+00:00 Alexey Dobriyan adobriyan@gmail.com 2008-04-29T08:01:44+00:00 c74c120a21d87b0b6925ada5830d8cac21e852d9 Remove proc_root export. Creation and removal works well if parent PDE is supplied as NULL -- it worked always that way. So, one useless export removed and consistency added, some drivers created PDEs with &proc_root as parent but removed them as NULL and so on. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Remove proc_root export.  Creation and removal works well if parent PDE is
supplied as NULL -- it worked always that way.

So, one useless export removed and consistency added, some drivers created
PDEs with &proc_root as parent but removed them as NULL and so on.

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
x86: !x & y typo in mtrr code 2008-04-29T11:45:24+00:00 Harvey Harrison harvey.harrison@gmail.com 2008-04-27T04:00:17+00:00 e686d34156ef0e56b2ebec505b809018bc0dc73b As written, this can never be true. Spotted by the Sparse checker. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
As written, this can never be true.

Spotted by the Sparse checker.

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
[CPUFREQ] expose cpufreq coordination requirements regardless of coordination mechanism 2008-04-28T20:27:08+00:00 Darrick J. Wong djwong@us.ibm.com 2008-04-18T20:31:12+00:00 e8628dd06d66f2e3965ec9742029b401d63434f1 Currently, affected_cpus shows which CPUs need to have their frequency coordinated in software. When hardware coordination is in use, the contents of this file appear the same as when no coordination is required. This can lead to some confusion among user-space programs, for example, that do not know that extra coordination is required to force a CPU core to a particular speed to control power consumption. To fix this, create a "related_cpus" attribute that always displays the coordination map regardless of whatever coordination strategy the cpufreq driver uses (sw or hw). If the cpufreq driver does not provide a value, fall back to policy->cpus. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com> 
Currently, affected_cpus shows which CPUs need to have their frequency
coordinated in software.  When hardware coordination is in use, the contents
of this file appear the same as when no coordination is required.  This can
lead to some confusion among user-space programs, for example, that do not
know that extra coordination is required to force a CPU core to a particular
speed to control power consumption.

To fix this, create a "related_cpus" attribute that always displays the
coordination map regardless of whatever coordination strategy the cpufreq
driver uses (sw or hw).  If the cpufreq driver does not provide a value, fall
back to policy->cpus.

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
[CPUFREQ] Make acpi-cpufreq more robust against BIOS freq changes behind our back. 2008-04-28T19:16:46+00:00 Venkatesh Pallipadi venkatesh.pallipadi@intel.com 2008-04-28T19:13:43+00:00 e56a727b023d40d1adf660168883f30f2e6abe0a We checked the hardware freq with OS cached freq value in get_cur_freqon_cpu(). Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com> 
We checked the hardware freq with OS cached freq value in get_cur_freqon_cpu().

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Dave Jones <davej@redhat.com>
x86: remove NexGen support 2008-04-26T15:35:47+00:00 Dmitri Vorobiev dmitri.vorobiev@gmail.com 2008-04-20T20:47:55+00:00 f7f17a67c589f031c567d9fdc809dee7c5868c8a It is claimed that NexGen CPUs were never shipped: http://lkml.org/lkml/2008/4/20/179 Also, the kernel support for these chips has been broken for a long time, the code intended to support NexGen thereby being essentially dead. As an outcome of the discussion that can be found using the URL above, this patch removes the NexGen support altogether. The changes in this patch survived a defconfig build for i386, a couple of successful randconfig builds, as well as a runtime test, which consisted in booting a 32-bit x86 box up to the shell prompt. Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
It is claimed that NexGen CPUs were never shipped:

   http://lkml.org/lkml/2008/4/20/179

Also, the kernel support for these chips has been broken for
a long time, the code intended to support NexGen thereby being
essentially dead.

As an outcome of the discussion that can be found using the URL
above, this patch removes the NexGen support altogether.

The changes in this patch survived a defconfig build for i386, a
couple of successful randconfig builds, as well as a runtime test,
which consisted in booting a 32-bit x86 box up to the shell prompt.

Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>