01 Nov, 2011
1 commit
-
These files were relying on module.h to come in via the path
in an include/acpi header file, but we don't want to have
instances of module.h being included from include/* files
if it can be avoided. Have the files include export.h instead.Signed-off-by: Paul Gortmaker
29 May, 2011
1 commit
-
Usually, there are multiple processors defined in ACPI table, for
exampleScope (_PR)
{
Processor (CPU0, 0x00, 0x00000410, 0x06) {}
Processor (CPU1, 0x01, 0x00000410, 0x06) {}
Processor (CPU2, 0x02, 0x00000410, 0x06) {}
Processor (CPU3, 0x03, 0x00000410, 0x06) {}
}processor_physically_present(...) will be called to check whether those
processors are physically present.Currently we have below codes in processor_physically_present,
cpuid = acpi_get_cpuid(...);
if ((cpuid == -1) && (num_possible_cpus() > 1))
return false;
return true;In UP kernel, acpi_get_cpuid(...) always return -1 and
num_possible_cpus() always return 1, so
processor_physically_present(...) always returns true for all passed in
processor handles.This is wrong for UP processor or SMP processor running UP kernel.
This patch removes the !SMP version of acpi_get_cpuid(), so both UP and
SMP kernel use the same acpi_get_cpuid function.And for UP kernel, only processor 0 is valid.
https://bugzilla.kernel.org/show_bug.cgi?id=16548
https://bugzilla.kernel.org/show_bug.cgi?id=16357Tested-by: Anton Kochkov
Tested-by: Ambroz Bizjak
Signed-off-by: Lin Ming
Signed-off-by: Len Brown
03 Mar, 2011
2 commits
-
Once acpi_map_lsapic() in ia64 follows how x86 treats it wrt section
placement, the whole tree from acpi_processor_set_pdc() can become
__cpuinit.Signed-off-by: Jan Beulich
Acked-by: Tony Luck
Signed-off-by: Len Brown -
Use __init for several functions, remove an unnecessary export and a
stray use of __ref.Signed-off-by: Jan Beulich
Signed-off-by: Len Brown
13 Jan, 2011
1 commit
-
Having four variables for the same thing:
idle_halt, idle_nomwait, force_mwait and boot_option_idle_overrides
is rather confusing and unnecessary complex.if idle= boot param is passed, only set up one variable:
boot_option_idle_overridesIntroduces following functional changes/fixes:
- intel_idle driver does not register if any idle=xy
boot param is passed.
- processor_idle.c will also not register a cpuidle driver
and get active if idle=halt is passed.
Before a cpuidle driver with one (C1, halt) state got registered
Now the default_idle function will be used which finally uses
the same idle call to enter sleep state (safe_halt()), but
without registering a whole cpuidle driver.That means idle= param will always avoid cpuidle drivers to register
with one exception (same behavior as before):
idle=nomwait
may still register acpi_idle cpuidle driver, but C1 will not use
mwait, but hlt. This can be a workaround for IO based deeper sleep
states where C1 mwait causes problems.Signed-off-by: Thomas Renninger
cc: x86@kernel.org
Signed-off-by: Len Brown
09 Oct, 2010
1 commit
01 Oct, 2010
1 commit
-
After
| commit d8191fa4a33fdc817277da4f2b7f771ff605a41c
| Author: Alex Chiang
| Date: Mon Feb 22 12:11:39 2010 -0700
|
| ACPI: processor: driver doesn't need to evaluate _PDC
|
| Now that the early _PDC evaluation path knows how to correctly
| evaluate _PDC on only physically present processors, there's no
| need for the processor driver to evaluate it later when it loads.
|
| To cover the hotplug case, push _PDC evaluation down into the
| hotplug paths.only cpu with Processor Statement get processed with _PDC
If bios is using Device object instead of Processor statement.
SSDTs for Pstate/Cstate/Tstate can not be loaded dynamically.Need to try to scan ACPI0007 in addition to Processor.
That commit is between 2.6.34-rc1 and 2.6.34-rc2, so stable tree for 2.6.34+
need this patch.Signed-off-by: Yinghai Lu
Reviewed-by: Bjorn Helgaas
Signed-off-by: Len Brown
29 Sep, 2010
1 commit
-
per comments in the bug report, this entry
seems to hurt at much as it helps.https://bugzilla.kernel.org/show_bug.cgi?id=10807
Signed-off-by: Len Brown
13 Jul, 2010
1 commit
-
The commit 5d554a7bb06 (ACPI: processor: add internal
processor_physically_present()) is broken on uniprocessor (UP)
configurations, as acpi_get_cpuid() will always return -1.We use the value of num_possible_cpus() to tell us whether we got
an invalid cpuid from acpi_get_cpuid() in the SMP case, or if
instead, we are UP, in which case num_possible_cpus() is #defined
as 1.We use num_possible_cpus() instead of num_online_cpus() to
protect ourselves against the scenario of CPU hotplug, and we've
taken down all the CPUs except one.Thanks to Jan Pogadl for initial report and analysis and Chen
Gong for review.https://bugzilla.kernel.org/show_bug.cgi?id=16357
Reported-by: Jan Pogadl :
Reviewed-by: Chen Gong
Signed-off-by: Alex Chiang
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>
15 Mar, 2010
10 commits
-
There's no real need for a pointer to the MADT to be global. The only
function who uses it is map_madt_entry.This allows us to remove some more ugly #ifdefs.
Acked-by: Venkatesh Pallipadi
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
Un-nest the if statements for readability.
Remove comments that re-state the obvious.
Change the control flow so that we no longer need a temp variable.
Acked-by: Venkatesh Pallipadi
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
Untangle the nested if conditions to make this function look
more similar to the other map_*apic_id() functions.Acked-by: Venkatesh Pallipadi
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
Untangle the if() statement a little for readability.
Acked-by: Venkatesh Pallipadi
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
Now that the early _PDC evaluation path knows how to correctly
evaluate _PDC on only physically present processors, there's no
need for the processor driver to evaluate it later when it loads.To cover the hotplug case, push _PDC evaluation down into the
hotplug paths.Cc: x86@kernel.org
Cc: Tony Luck
Acked-by: Venkatesh Pallipadi
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
Now that we check for physically present processors before blindly
evaluating _PDC, we no longer need to maintain a DMI opt-in table
nor a kernel param.Acked-by: Venkatesh Pallipadi
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
Detect if a processor is physically present before evaluating _PDC.
We want this because some BIOS will provide a _PDC even for processors
that are not present. These bogus _PDC methods then attempt to load
non-existent tables, which causes problems.Avoid those bogus landmines.
Acked-by: Venkatesh Pallipadi
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
Enumerating processors (via MADT/_MAT) belongs in the processor core,
which is always built-in, rather than living in the processor driver
which may not be built.Acked-by: Venkatesh Pallipadi
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
We've renamed the old processor_core.c to processor_driver.c, to
convey the idea that it can be built modular and has driver-like
bits.Now let's re-create a processor_core.c for the bits needed
statically by the rest of the kernel. The contents of processor_pdc.c
are a good starting spot, so let's just rename that file and
complete our three card monte.Acked-by: Venkatesh Pallipadi
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
The ACPI processor driver can be built as a module. But it has
pieces of code that should always be built statically into the
kernel.The plan is for processor_core.c to contain the static bits while
processor_driver.c contains the module-like bits.Since the bulk of the code in the current processor_core.c is
module-like, first step is to rename the file to processor_driver.cNext step will re-create processor_core.c and cherry-pick out
the static bits.Acked-by: Venkatesh Pallipadi
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown
08 Mar, 2010
1 commit
-
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
[CPUFREQ] Fix cast warning in pcc driver.
[CPUFREQ] Processor Clocking Control interface driver
13 Jan, 2010
1 commit
-
Processor Clocking Control (PCC) is an interface between the BIOS and OSPM.
Based on the server workload, OSPM can request what frequency it expects
from a logical CPU, and the BIOS will achieve that frequency transparently.This patch introduces driver support for PCC. OSPM uses the PCC driver to
communicate with the BIOS via the PCC interface.There is a Documentation file that provides a link to the PCC
Specification, and also provides a summary of the PCC interface.Currently, certain HP ProLiant platforms implement the PCC interface. However,
any platform whose BIOS implements the PCC Specification, can utilize this
driver.V2 --> V1 changes (based on Dominik's suggestions):
- Removed the dependency on CPU_FREQ_TABLE
- "cpufreq_stats" will no longer PANIC. Actually, it will not load anymore
because it is not applicable.
- Removed the sanity check for target frequency in the ->target routine.NOTE: A patch to sanitize the target frequency requested by "ondemand" is
needed to ensure that the target freq < policy->min.Can this driver be queued up for the 2.6.33 tree?
Signed-off-by: Naga Chumbalkar
Signed-off-by: Matthew Garrett
Signed-off-by: Thomas Renninger
Signed-off-by: Dave Jones
22 Dec, 2009
2 commits
-
When calling _PDC, we really only need the handle to the processor
to call the method; we don't look at any other parts of the
struct acpi_processor * given to us.In the early path, when we walk the namespace, we are given the
handle directly, so just pass it through to acpi_processor_set_pdc()
without stuffing it into a wasteful struct acpi_processor allocated
on the stack each timeThis saves 2834 bytes of stack.
Update the interface accordingly.
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
We discovered that at least one machine (HP Envy), methods in the DSDT
attempt to call external methods defined in a dynamically loaded SSDT.Unfortunately, the DSDT methods we are trying to call are part of the
EC initialization, which happens very early, and the the dynamic SSDT
is only loaded when a processor _PDC method runs much later.This results in namespace lookup errors for the (as of yet) undefined
methods.Since Windows doesn't have any issues with this machine, we take it
as a hint that they must be evaluating _PDC much earlier than we are.Thus, the proper thing for Linux to do should be to match the Windows
implementation more closely.Provide a mechanism to call _PDC before we enable the EC. Doing so loads
the dynamic tables, and allows the EC to be enabled correctly.The ACPI processor driver will still evaluate _PDC in its .add() method
to cover the hotplug case.Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=14824
Cc: ming.m.lin@intel.com
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown
17 Dec, 2009
2 commits
-
Due to the merge of processor_start() (declared with __cpuinit) into
processor_add(), a section mismatch warning appears:WARNING: drivers/built-in.o(.text+0x4d59d): Section mismatch in reference
from the function acpi_processor_add() to the function
.cpuinit.text:acpi_processor_power_init()
...This patch fixes the warning by declaring processor_add() as __cpuinit
and also declares acpi_processor_add_fs() as __cpuinit as it is only
used in acpi_processor_add().Signed-off-by: Thomas Renninger
Signed-off-by: Len Brown
16 Dec, 2009
2 commits
-
Conflicts:
include/acpi/processor.hSigned-off-by: Len Brown
-
This message shows up for each cpu. Print as debug messages.
[ 12.893967] processor ACPI0007:00: registered as cooling_device0
[ 12.907838] processor ACPI0007:01: registered as cooling_device1Signed-off-by: Mike Travis
Cc: Ingo Molnar
Cc: linux-acpi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Len Brown
25 Nov, 2009
1 commit
-
The existing interface only has a pre-order callback. This change
adds an additional parameter for a post-order callback which will
be more useful for bus scans. ACPICA BZ 779.Also update the external calls to acpi_walk_namespace.
http://www.acpica.org/bugzilla/show_bug.cgi?id=779
Signed-off-by: Lin Ming
Signed-off-by: Bob Moore
Signed-off-by: Len Brown
06 Nov, 2009
2 commits
-
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 -
Annote acpi_processor_add with cpuinit since it calls a cpuinit function
acpi_processor_power_init and fixes a section mismatch warning.We were warned by the following warning:
LD drivers/acpi/processor.o
WARNING: drivers/acpi/processor.o(.text+0x1829): Section mismatch in
reference from the function acpi_processor_add() to the function
.cpuinit.text:acpi_processor_power_init()
The function acpi_processor_add() references
the function __cpuinit acpi_processor_power_init().
This is often because acpi_processor_add lacks a __cpuinit
annotation or the annotation of acpi_processor_power_init is wrong.Signed-off-by: Rakib Mullick
Signed-off-by: Andrew Morton
Signed-off-by: Len Brown
03 Oct, 2009
1 commit
-
I was recently lucky enough to get a 64-CPU system. The processors
actually have T-states, so my kernel log ends up with 64 lines like:ACPI: Processor [CPU0] (supports xx throttling states)
This is pretty useless clutter because
- this info is already available after boot from
/proc/acpi/processor/CPUnn/throttling- there's also an ACPI_DEBUG_PRINT() in processor_throttling.c that
gives the same info on boot for anyone who *really* cares.So just delete the code that prints the throttling states in
processor_core.c.Signed-off-by: Roland Dreier
Signed-off-by: Andrew Morton
Signed-off-by: Len Brown
19 Sep, 2009
2 commits
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
27 Aug, 2009
1 commit
-
Jens reported early_ioremap messages with old ASUS board...
> [ 1.507461] pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling
> [ 1.532778] early_ioremap(3fffd080, 0000005c) [0] => Pid: 1, comm: swapper Not tainted 2.6.31-rc4 #36
> [ 1.561007] Call Trace:
> [ 1.568638] [] ? printk+0x18/0x1d
> [ 1.581734] [] __early_ioremap+0x74/0x1e9
> [ 1.596898] [] early_ioremap+0x1a/0x1c
> [ 1.611270] [] __acpi_map_table+0x18/0x1a
> [ 1.626451] [] acpi_os_map_memory+0x1d/0x25
> [ 1.642129] [] acpi_tb_verify_table+0x20/0x49
> [ 1.658321] [] acpi_get_table_with_size+0x53/0xa1
> [ 1.675553] [] acpi_get_table+0x10/0x15
> [ 1.690192] [] acpi_processor_init+0x23/0xab
> [ 1.706126] [] do_one_initcall+0x33/0x180
> [ 1.721279] [] ? acpi_processor_init+0x0/0xab
> [ 1.737479] [] ? register_irq_proc+0xaa/0xc0
> [ 1.753411] [] ? init_irq_proc+0x67/0x80
> [ 1.768316] [] kernel_init+0x120/0x176
> [ 1.782678] [] ? kernel_init+0x0/0x176
> [ 1.797062] [] kernel_thread_helper+0x7/0x10
> [ 1.812984] 00000080 + ffe00000that is rather later.
acpi_gbl_permanent_mmap should be set in acpi_early_init()
if acpi is not disabledand we have
> [ 0.000000] ASUS P2B-DS detected: force use of acpi=htjust don't load acpi_processor_init...
Reported-and-tested-by: Jens Rosenboom
Signed-off-by: Yinghai Lu
Acked-by: Ingo Molnar
Cc: Len Brown
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Jun, 2009
4 commits
-
This patch folds the .start() method into .add().
acpi_processor_start() is always called immediately after
acpi_processor_add(), so there's really no point in having them be
separate methods.Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Chiang
CC: Venkatesh Pallipadi
CC: Zhao Yakui
Signed-off-by: Len Brown -
Move acpi_processor_start() to just after acpi_processor_add().
A subsequent patch will merge them.Code movement only; no functional change.
Signed-off-by: Bjorn Helgaas
CC: Venkatesh Pallipadi
CC: Zhao Yakui
Signed-off-by: Len Brown -
We used to leave crud around if things failed in acpi_processor_start().
This patch cleans up as much as we can before returning.Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Chiang
CC: Venkatesh Pallipadi
CC: Zhao Yakui
Signed-off-by: Len Brown -
This patch removes the KOBJ_ONLINE/KOBJ_OFFLINE events the driver used
to generate for CPU hotplug. As far as I know, nobody consumes these.
The driver core still generates KOBJ_ADD and KOBJ_REMOVE, of course.Signed-off-by: Bjorn Helgaas
CC: Venkatesh Pallipadi
CC: Zhao Yakui
CC: Matthew Garrett
CC: Thomas Renninger
CC: Dave Jones
CC: Kay Sievers
CC: Greg Kroah-Hartman
Signed-off-by: Len Brown
