04 May, 2011
1 commit
-
With dynamic debug having gained the capability to report debug messages
also during the boot process, it offers a far superior interface for
debug messages than the custom cpufreq infrastructure. As a first step,
remove the old cpufreq_debug_printk() function and replace it with a call
to the generic pr_debug() function.How can dynamic debug be used on cpufreq? You need a kernel which has
CONFIG_DYNAMIC_DEBUG enabled.To enabled debugging during runtime, mount debugfs and
$ echo -n 'module cpufreq +p' > /sys/kernel/debug/dynamic_debug/control
for debugging the complete "cpufreq" module. To achieve the same goal during
boot, appendddebug_query="module cpufreq +p"
as a boot parameter to the kernel of your choice.
For more detailled instructions, please see
Documentation/dynamic-debug-howto.txtSigned-off-by: Dominik Brodowski
Signed-off-by: Dave Jones
29 Sep, 2010
1 commit
-
Signed-off-by: Len Brown
30 Mar, 2010
1 commit
-
…it slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
03 Mar, 2010
1 commit
-
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
percpu: add __percpu sparse annotations to what's left
percpu: add __percpu sparse annotations to fs
percpu: add __percpu sparse annotations to core kernel subsystems
local_t: Remove leftover local.h
this_cpu: Remove pageset_notifier
this_cpu: Page allocator conversion
percpu, x86: Generic inc / dec percpu instructions
local_t: Move local.h include to ringbuffer.c and ring_buffer_benchmark.c
module: Use this_cpu_xx to dynamically allocate counters
local_t: Remove cpu_local_xx macros
percpu: refactor the code in pcpu_[de]populate_chunk()
percpu: remove compile warnings caused by __verify_pcpu_ptr()
percpu: make accessors check for percpu pointer in sparse
percpu: add __percpu for sparse.
percpu: make access macros universal
percpu: remove per_cpu__ prefix.
19 Feb, 2010
1 commit
-
Earlier, Ingo Molnar posted a patch to make it so that the kernel would avoid
reading _PPC on his broken T60. Unfortunately, it seems that with Thomas
Renninger's patch last July to eliminate _PPC evaluations when the processor
driver loads, the kernel never actually reads _PPC at all! This is problematic
if you happen to boot your non-T60 computer in a state where the BIOS _wants_
_PPC to be something other than zero.So, put the _PPC evaluation back into acpi_processor_get_performance_info if
ignore_ppc isn't 1.Signed-off-by: Darrick J. Wong
Signed-off-by: Len Brown
17 Feb, 2010
1 commit
-
Add __percpu sparse annotations to places which didn't make it in one
of the previous patches. All converions are trivial.These annotations are to make sparse consider percpu variables to be
in a different address space and warn if accessed without going
through percpu accessors. This patch doesn't affect normal builds.Signed-off-by: Tejun Heo
Acked-by: Borislav Petkov
Cc: Dan Williams
Cc: Huang Ying
Cc: Len Brown
Cc: Neil Brown
16 Dec, 2009
1 commit
-
Conflicts:
include/acpi/processor.hSigned-off-by: Len Brown
25 Nov, 2009
1 commit
-
This interface is mainly intended (and implemented) for ACPI _PPC BIOS
frequency limitations, but other cpufreq drivers can also use it for
similar use-cases.Why is this needed:
Currently it's not obvious why cpufreq got limited.
People see cpufreq/scaling_max_freq reduced, but this could have
happened by:
- any userspace prog writing to scaling_max_freq
- thermal limitations
- hardware (_PPC in ACPI case) limitiationsTherefore export bios_limit (in kHz) to:
- Point the user that it's the BIOS (broken or intended) which limits
frequency
- Export it as a sysfs interface for userspace progs.
While this was a rarely used feature on laptops, there will appear
more and more server implemenations providing "Green IT" features like
allowing the service processor to limit the frequency. People want
to know about HW/BIOS frequency limitations.All ACPI P-state driven cpufreq drivers are covered with this patch:
- powernow-k8
- powernow-k7
- acpi-cpufreqTested with a patched DSDT which limits the first two cores (_PPC returns 1)
via _PPC, exposed by bios_limit:
# echo 2200000 >cpu2/cpufreq/scaling_max_freq
# cat cpu*/cpufreq/scaling_max_freq
2600000
2600000
2200000
2200000
# #scaling_max_freq shows general user/thermal/BIOS limitations# cat cpu*/cpufreq/bios_limit
2600000
2600000
2800000
2800000
# #bios_limit only shows the HW/BIOS limitationCC: Pallipadi Venkatesh
CC: Len Brown
CC: davej@codemonkey.org.uk
CC: linux@dominikbrodowski.netSigned-off-by: Thomas Renninger
Signed-off-by: Dave Jones
06 Nov, 2009
1 commit
-
According to the ACPI spec(section 8.4.4.3) OSPM should convey the _PPC
evaluations status to the platform if there exists the _OST object.
The _OST contains two arguments:
The first is the PERFORMANCE notificatin event.
The second is the status of _PPC object.
OSPM will convey the _PPC evaluation status to the platform.
Of course when the module parameter of "ignore_ppc" is added, OSPM won't
evaluate the _PPC object. But it will call the _OST object.At the same time the _OST object will be evaluated only when the PERFORMANCE
notification event is received.Signed-off-by: Zhao Yakui
Signed-off-by: Len Brown
24 Sep, 2009
1 commit
-
Remove open-coded zalloc_cpumask_var() and zalloc_cpumask_var_node().
Signed-off-by: Li Zefan
Signed-off-by: Rusty Russell
29 Aug, 2009
1 commit
-
Linux/ACPI core files using internal.h all PREFIX "ACPI: ",
however, not all ACPI drivers use/want it -- and they
should not have to #undef PREFIX to define their own.Add GPL commment to internal.h while we are there.
This does not change any actual console output,
asside from a whitespace fix.Signed-off-by: Len Brown
30 May, 2009
1 commit
-
When BIOS SETUP is changed to disable EIST, some BIOS
hand the OS an un-initialized _PSS:Name (_PSS, Package (0x06)
{
Package (0x06)
{
0x80000000, // frequency [MHz]
0x80000000, // power [mW]
0x80000000, // latency [us]
0x80000000, // BM latency [us]
0x80000000, // control
0x80000000 // status
},
...These are outrageous values for frequency,
power and latency, raising the question where to draw
the line between legal and illegal. We tend to survive
garbage in the power and latency fields, but we can BUG_ON
when garbage is in the frequency field.Cpufreq multiplies the frequency by 1000 and stores it in a u32 KHz.
So disregard a _PSS with a frequency so large
that it can't be represented by cpufreq.https://bugzilla.redhat.com/show_bug.cgi?id=500311
Signed-off-by: Len Brown
05 Apr, 2009
1 commit
-
Conflicts:
arch/x86/kernel/cpu/cpufreq/longhaul.cSigned-off-by: Len Brown
28 Mar, 2009
1 commit
-
When cpufreq driver call acpi_processor_preregister_performance() , function
will clean up pr->performance even if there is possibly already registered
other cpufreq driver. The patch fix this potential problem. It also remove
double checks in P domain basic validity code and move these checks to function
where _PSD data is captured.Signed-off-by: Stanislaw Gruszka
Signed-off-by: Len Brown
20 Feb, 2009
1 commit
-
Impact: cleanup
There are two allocated per-cpu accessor macros with almost identical
spelling. The original and far more popular is per_cpu_ptr (44
files), so change over the other 4 files.tj: kill percpu_ptr() and update UP too
Signed-off-by: Rusty Russell
Cc: mingo@redhat.com
Cc: lenb@kernel.org
Cc: cpufreq@vger.kernel.org
Signed-off-by: Tejun Heo
04 Feb, 2009
1 commit
-
They were long enough set deprecated...
Update Documentation/cpu-freq/users-guide.txt:
The deprecated files listed there seen not to exist for some time anymore
already.Signed-off-by: Thomas Renninger
Signed-off-by: Len Brown
04 Jan, 2009
1 commit
-
Impact: Reduce memory usage, use new API.
This is part of an effort to reduce structure sizes for machines
configured with large NR_CPUS. cpumask_t gets replaced by
cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or
struct cpumask * (large NR_CPUS).(Changes to powernow-k* by .)
Signed-off-by: Rusty Russell
Signed-off-by: Mike Travis
Signed-off-by: Ingo Molnar
08 Nov, 2008
1 commit
-
Move all the component definitions for drivers to a single shared place,
include/acpi/acpi_drivers.h.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
25 Oct, 2008
1 commit
-
When trying to build 2.6.28-rc1 on ia64, make aborts with:
CC drivers/acpi/processor_perflib.o
drivers/acpi/processor_perflib.c:41:28: error: asm/cpufeature.h: No such file or directory
drivers/acpi/processor_perflib.c: In function ‘acpi_processor_get_performance_info’:
drivers/acpi/processor_perflib.c:364: error: implicit declaration of function ‘boot_cpu_has’
drivers/acpi/processor_perflib.c:364: error: ‘X86_FEATURE_EST’ undeclared (first use in this function)
drivers/acpi/processor_perflib.c:364: error: (Each undeclared identifier is reported only once
drivers/acpi/processor_perflib.c:364: error: for each function it appears in.)
make[2]: *** [drivers/acpi/processor_perflib.o] Error 1
make[1]: *** [drivers/acpi] Error 2
make: *** [drivers] Error 2this patch fix it.
Signed-off-by: Miao Xie
Acked-by: Thomas Renninger
Signed-off-by: Len Brown
23 Oct, 2008
3 commits
-
Conflicts:
drivers/acpi/bay.c
drivers/acpi/dock.c
drivers/ata/libata-acpi.cSigned-off-by: Len Brown
-
ACPI_DB_ERROR and ACPI_DB_WARN were removed from ACPICA core.
So replace ACPI_DEBUG_PRINT((ACPI_DB_ERROR, ...) with printk(KERN_ERR PREFIX ...)
and ACPI_DEBUG_PRINT((ACPI_DB_WARN, ...) with printk(KERN_WARNING PREFIX ...)We do not use ACPI_ERROR/ACPI_WARNING since they're not exported, see
-------------------------------------------------------------
commit 6468463abd7051fcc29f3ee7c931f9bbbb26f5a4
Author: Len Brown
Date: Mon Jun 26 23:41:38 2006 -0400ACPI: un-export ACPI_ERROR() -- use printk(KERN_ERR...)
Signed-off-by: Len Brown
-------------------------------------------------------------Signed-off-by: Lin Ming
Signed-off-by: Len Brown
11 Oct, 2008
1 commit
-
As of version 2.0, ACPI can return 64-bit integers. The current
acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
Change the argument to take a pointer to an acpi_integer so we support
64-bit integers on all platforms.lenb: replaced use of "acpi_integer" with "unsigned long long"
lenb: fixed bug in acpi_thermal_trips_update()Signed-off-by: Matthew Wilcox
Signed-off-by: Len Brown
23 Sep, 2008
1 commit
-
On Intel CPUs it is rather common and a good hint that BIOSes which do provide
_PPC func, but not the frequencies itself in _PSS function, are old and need
to be updated for CPU freq support.Tell the user/vendor he has a BIOS/firmware problem.
Make use of FW_BUG interface to give vendors and users the ability to
automatically check with (or let linuxfirmwarekit do that):
dmesg |grep "Firmware Bug"Signed-off-by: Thomas Renninger
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown
18 Aug, 2008
1 commit
-
Signed-off-by: Milan Broz
Signed-off-by: Andi Kleen
15 Aug, 2008
1 commit
-
Do not use unsigned int if there is test for negative number...
See drivers/acpi/processor_perflib.c
static unsigned int ignore_ppc = -1;
...
if (event == CPUFREQ_START && ignore_ppc
Signed-off-by: Andi Kleen
31 Jul, 2008
2 commits
-
Signed-off-by: Thomas Renninger
Cc: Andi Kleen
Cc: Len Brown
Cc: Dave Jones
Cc: Ingo Molnar
Cc: Venkatesh Pallipadi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Ingo Molnar provided a fix to not call _PPC at processor driver
initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
commit e4233dec749a3519069d9390561b5636a75c7579)But it can still happen that _PPC is called at processor driver
initialization time.This patch should make sure that this is not possible anymore.
Signed-off-by: Thomas Renninger
Cc: Andi Kleen
Cc: Len Brown
Cc: Dave Jones
Cc: Ingo Molnar
Cc: Venkatesh Pallipadi
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Jul, 2008
1 commit
-
Change processors from an array sized by NR_CPUS to a per_cpu variable.
Signed-off-by: Mike Travis
Signed-off-by: Andrew Morton
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen
29 Apr, 2008
1 commit
-
Use proc_create()/proc_create_data() to make sure that ->proc_fops and ->data
be setup before gluing PDE to main tree.Add correct ->owner to proc_fops to fix reading/module unloading race.
Signed-off-by: Denis V. Lunev
Cc: Len Brown
Cc: Alexey Dobriyan
Cc: "Eric W. Biederman"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Feb, 2008
1 commit
-
enabled with CPU_FREQ_DEBUG
Signed-off-by: Thomas Renninger
Signed-off-by: Len Brown
02 Jan, 2008
1 commit
-
There have been fixes using _PPC, which seem to unhide a problem
on HP nx6125 (double cpufreq switch freezes the machine for
several seconds).This one should provide a workaround for the nx6125 and for
possible other machines that show any weird _PPC behaviour.Signed-off-by: Thomas Renninger
Signed-off-by: Len Brown
08 Aug, 2007
1 commit
-
This patch addresses some issues in x86/x86-64 acpi-cpufreq driver:
1. Current memory allocation for acpi_perf_data is actually open-coded
alloc_percpu(). The patch defines and handles acpi_perf_data as percpu
data. The code will be cleaner and easier to be maintained with this
change.2. Won't load driver in acpi_cpufreq_early_init() failure case.
3. Add __init for acpi_cpufreq_early_init().
Signed-off-by: Fenghua Yu
Acked-by: Venkatesh Pallipadi
Cc: Dave Jones
Signed-off-by: Andrew Morton
Signed-off-by: Len Brown
27 Apr, 2007
1 commit
-
Remove deprecated /proc/acpi/processor/performance write support
Writing to /proc/acpi/processor/xy/performance interferes with sysfs
cpufreq interface. Also removes buggy cpufreq_set_policy exported symbol.Signed-off-by: Thomas Renninger
Signed-off-by: Dave Jones
13 Feb, 2007
2 commits
-
Cosmetic only.
Except in a single case, #define ACPI_*_DRIVER_NAME
were invoked 0 or 1 times.Signed-off-by: Len Brown
-
cosmetic only
Make "module name" actually match the file name.
Invoke with ';' as leaving it off confuses Lindent and gcc doesn't care.
Fix indentation where Lindent did get confused.Signed-off-by: Len Brown
03 Feb, 2007
2 commits
-
Signed-off-by: Len Brown
-
Signed-off-by: Len Brown
27 Jan, 2007
1 commit
-
Recently cpufreq support on my laptop (Lenovo T60) broke completely: when
it's plugged into AC it would never go higher than 1 GHz - neither 1.3 GHz
nor 1.83 GHz is possible - no matter which governor (userspace, speed or
ondemand) is used.After some cpufreq debugging i tracked the regression back to the following
(totally correct) bug-fix commit:commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e
Author: Dave Jones
Date: Wed Nov 22 20:42:01 2006 -0500[PATCH] Correct bound checking from the value returned from _PPC method.
This bugfix, which makes other laptops work, made a previously hidden
(BIOS) bug visible on my laptop.The bug is the following: if the _PPC (Performance Present Capabilities)
optional ACPI object is queried /after/ bootup then the BIOS reports an
incorrect value of '2'.My laptop (Lenovo T60) has the following performance states supported:
0: 1833000
1: 1333000
2: 1000000Per ACPI specification, a _PPC value of '0' means that all 3 performance
states are usable. A _PPC value of '1' means states 1 .. 2 are usable, a
value of '2' means only state '2' (slowest) is usable.now, the _PPC object is optional, and it also comes with notification.
Furthermore, when a CPU object is initialized, the _PPC object is
initialized as well. So the following evaluation of the _PPC object is
superfluous:[] acpi_processor_get_platform_limit+0xa1/0xaf
[] acpi_processor_register_performance+0x3b9/0x3ef
[] acpi_cpufreq_cpu_init+0xb7/0x596
[] cpufreq_add_dev+0x160/0x4a8
[] sysdev_driver_register+0x5a/0xa0
[] cpufreq_register_driver+0xb4/0x176
[] acpi_cpufreq_init+0xe5/0xeb
[] init+0x14f/0x3ddAnd this is the point where my laptop's BIOS returns the incorrect value of
'2'. Note that it has not sent any notification event, so the value is
probably not really intentional (possibly spurious), and Windows likely
doesnt query it after bootup either. Maybe the value is kept at '2'
normally, and is only set to the real value when a true asynchronous event
(such as AC plug event, battery switch, etc.) occurs.So i /think/ this is a grey area of the ACPI spec: per the letter of the
spec the _PPC value only changes when notified, so there's no reason to
query it after the system has booted up. So in my opinion the best (and
most compatible) strategy would be to do the change below, and to not
evaluate the _PPC object in the acpi_processor_get_performance_info() call,
but only evaluate it if _PPC is present during CPU object init, or if it's
notified during an asynchronous event. This change is more permissive than
the previous logic, so it definitely shouldnt break any existing system.This also happens to fix my laptop, which is merrily chugging along at
1.83 GHz now. Yay!Signed-off-by: Ingo Molnar
Cc: Dave Jones
Acked-by: Len Brown
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Jan, 2007
1 commit
-
ACPI: Getting cpuindex for acpiid 0x4
acpi_processor-0742 [00] processor_preregister_: Error while parsing _PSD domain information. Assuming no coordination
http://bugzilla.kernel.org/show_bug.cgi?id=7286
Signed-off-by: Venkatesh Pallipadi
Signed-off-by: Len Brown
