30 Oct, 2013
1 commit
-
Function acpi_processor_load_module() used by the ACPI processor
driver can only really work if the acpi-cpufreq module is available
when acpi_processor_start() is executed which usually is not the case
for systems loading the processor driver module from an initramfs.Moreover, that used to be a hackish workaround for module autoloading
issues, but udev loads acpi-cpufreq just fine nowadays, so that
function isn't really necessary any more. For this reason, drop
acpi_processor_load_module() entirely.Signed-off-by: Rafael J. Wysocki
24 Sep, 2013
1 commit
-
For cpu hot add, we evaluate _MAT or parse MADT twice to get APIC id,
here is the code logic:
acpi_processor_add()
acpi_processor_get_info()
acpi_get_cpuid() will evaluate _MAT or parse MADT;
acpi_processor_hotadd_init()
acpi_map_lsapic() will evaluate _MAT again;This can be done more effectively, this patch introduces apic_id in struct
processor to save parsed APIC id, and then we can use it and remove the
duplicated _MAT evaluation.Signed-off-by: Jiang Liu
Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
12 May, 2013
2 commits
-
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
Reviewed-by: Toshi Kani -
The system suspend routine of the ACPI processor driver saves
the BUS_MASTER_RLD register and its resume routine restores it.
However, there can be only one such register in the system and it
really should be saved after non-boot CPUs have been offlined and
restored before they are put back online during resume.For this reason, move the saving and restoration of BUS_MASTER_RLD
to syscore suspend and syscore resume, respectively, and drop the no
longer necessary suspend/resume callbacks from the ACPI processor
driver.Signed-off-by: Rafael J. Wysocki
06 Mar, 2013
1 commit
-
The git commit d5aaffa9dd531c978c6f3fea06a2972653bd7fc8
(cpufreq: handle cpufreq being disabled for all exported function)
tightens the cpufreq API by returning errors when disable_cpufreq()
had been called.The problem we are hitting is that the module xen-acpi-processor which
uses the ACPI's functions: acpi_processor_register_performance,
acpi_processor_preregister_performance, and acpi_processor_notify_smm
fails at acpi_processor_register_performance with -22.Note that earlier during bootup in arch/x86/xen/setup.c there is also
an call to cpufreq's API: disable_cpufreq().This is b/c we want the Linux kernel to parse the ACPI data, but leave
the cpufreq decisions to the hypervisor.In v3.9 all the checks that d5aaffa9dd531c978c6f3fea06a2972653bd7fc8
added are now hit and the calls to cpufreq_register_notifier will now
fail. This means that acpi_processor_ppc_init ends up printing:"Warning: Processor Platform Limit not supported"
and the acpi_processor_ppc_status is not set.
The repercussions of that is that the call to
acpi_processor_register_performance fails right away at:if (!(acpi_processor_ppc_status & PPC_REGISTERED))
and we don't progress any further on parsing and extracting the _P*
objects.The only reason the Xen code called that function was b/c it was
exported and the only way to gather the P-states. But we can also
just make acpi_processor_get_performance_info be exported and not
use acpi_processor_register_performance. This patch does so.Acked-by: Rafael J. Wysocki
Signed-off-by: Konrad Rzeszutek Wilk
18 Sep, 2012
1 commit
-
Currently we have the cpuidle_device field in the acpi_processor_power structure.
This adds a dependency between processor.h and cpuidle.hAlthough it is not a real problem, removing this dependency has the benefit of
separating a bit more the cpuidle code from the rest of the acpi code.
Also, the compilation should be a bit improved because we do no longer
include cpuidle.h in processor.h. The preprocessor was generating 30418 loc
and with this patch it generates 30256 loc for processor_thermal.c, a file
which is not concerned at all by cpuidle, like processor_perflib.c and
processor_throttling.c.That may sound ridiculous, but "small streams make big rivers" :P
This patch moves this field into a static global per cpu variable like what is
done in the intel_idle driver.Signed-off-by: Daniel Lezcano
Signed-off-by: Rafael J. Wysocki
16 Sep, 2012
1 commit
-
The 'device' parameter is not used neither in acpi_processor_power_init
and acpi_processor_power_exit. This patch removes it.Signed-off-by: Daniel Lezcano
Signed-off-by: Rafael J. Wysocki
05 Sep, 2012
1 commit
-
Remove the unused power field from struct struct acpi_processor_cx.
[rjw: Modified changelog.]
Signed-off-by: Daniel Lezcano
Acked-by: Konrad Rzeszutek Wilk
Signed-off-by: Rafael J. Wysocki
19 Jul, 2012
1 commit
-
* pm-acpi: (24 commits)
olpc-xo15-sci: Use struct dev_pm_ops for power management
ACPI / PM: Drop PM callbacks from the ACPI bus type
ACPI / PM: Drop legacy driver PM callbacks that are not used any more
ACPI / PM: Do not execute legacy driver PM callbacks
acpi_power_meter: Use struct dev_pm_ops for power management
fujitsu-tablet: Use struct dev_pm_ops for power management
classmate-laptop: Use struct dev_pm_ops for power management
xo15-ebook: Use struct dev_pm_ops for power management
toshiba_bluetooth: Use struct dev_pm_ops for power management
panasonic-laptop: Use struct dev_pm_ops for power management
sony-laptop: Use struct dev_pm_ops for power management
hp_accel: Use struct dev_pm_ops for power management
toshiba_acpi: Use struct dev_pm_ops for power management
ACPI: Use struct dev_pm_ops for power management in the SBS driver
ACPI: Use struct dev_pm_ops for power management in the power driver
ACPI: Use struct dev_pm_ops for power management in the button driver
ACPI: Use struct dev_pm_ops for power management in the battery driver
ACPI: Use struct dev_pm_ops for power management in the AC driver
ACPI: Use struct dev_pm_ops for power management in processor driver
ACPI: Use struct dev_pm_ops for power management in the thermal driver
...
18 Jul, 2012
3 commits
-
Remove the time field as it is not used.
Signed-off-by: Daniel Lezcano
Signed-off-by: Rafael J. Wysocki -
Remove the usage field as it is not used.
Signed-off-by: Daniel Lezcano
Signed-off-by: Rafael J. Wysocki -
Remove the latency_ticks field as it is not used.
Signed-off-by: Daniel Lezcano
Signed-off-by: Rafael J. Wysocki
01 Jul, 2012
2 commits
-
Make the ACPI processor driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.Signed-off-by: Rafael J. Wysocki
-
None of the drivers implementing the ACPI device suspend callback
uses the pm_message_t argument of it, so this argument may be dropped
entirely from that callback. This will simplify switching the ACPI
bus type to PM handling based on struct dev_pm_ops.Signed-off-by: Rafael J. Wysocki
03 Feb, 2012
1 commit
-
This was done to resolve a merge and build problem with the
drivers/acpi/processor_driver.c file.Reported-by: Stephen Rothwell
Signed-off-by: Greg Kroah-Hartman
27 Jan, 2012
1 commit
-
The only left over hole in automatic cpufreq driver loading was the loading
of ACPI cpufreq. This driver should be loaded when ACPI supports a _PDC
method and the CPU vendor wants to use acpi cpufreq.Simply add a request module call to the acpi processor core driver
when this is true. This seems like the simplest solution for this.Cc: Len Brown
Signed-off-by: Andi Kleen
Signed-off-by: Thomas Renninger
Acked-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman
20 Jan, 2012
1 commit
-
Delay the setting up of features (cpuidle, throttling by calling
acpi_processor_start()) to the time when the hotplugged
core got onlined the first time and got fully
initialized.Signed-off-by: Thomas Renninger
Signed-off-by: Len Brown
07 Nov, 2011
1 commit
-
This patch makes the cpuidle_states structure global (single copy)
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory. Rare case
of asymmetric C-states can be handled within the cpuidle driver
and architectures such as POWER do not have asymmetric C-states.Having single/global registration of all the idle states,
dynamic C-state transitions on x86 are handled by
the boot cpu. Here, the boot cpu would disable all the devices,
re-populate the states and later enable all the devices,
irrespective of the cpu that would receive the notification first.Reference:
https://lkml.org/lkml/2011/4/25/83Signed-off-by: Deepthi Dharwar
Signed-off-by: Trinabh Gupta
Tested-by: Jean Pihet
Reviewed-by: Kevin Hilman
Acked-by: Arjan van de Ven
Acked-by: Kevin Hilman
Signed-off-by: Len Brown
17 Jul, 2011
1 commit
-
Structs battery_file, acpi_dock_ops, file_operations,
thermal_cooling_device_ops, thermal_zone_device_ops, kernel_param_ops
are not changed in runtime. It is safe to make them const.
register_hotplug_dock_device() was altered to take const "ops" argument
to respect acpi_dock_ops' const notion.Signed-off-by: Vasiliy Kulikov
Acked-by: Jeff Garzik
Signed-off-by: Len Brown
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
11 Jan, 2011
1 commit
-
After one CPU is offlined, it is unnecessary to switch T-state for it.
So it will be better that the throttling is disabled after the cpu
is offline.
At the same time after one cpu is online, we should check whether
the T-state is supported and then set the corresponding T-state
flag.Signed-off-by: Zhao Yakui
Signed-off-by: Len Brown
15 Aug, 2010
1 commit
-
Remove deprecated ACPI processor procfs I/F, including:
/proc/acpi/processor/CPUX/power
/proc/acpi/processor/CPUX/limit
/proc/acpi/processor/CPUX/info/proc/acpi/processor/CPUX/throttling still exists,
as we don't have sysfs I/F available for now.Signed-off-by: Zhang Rui
Signed-off-by: Len Brown
23 Jul, 2010
1 commit
-
It turns out that there is a bit in the _CST for Intel FFH C3
that tells the OS if we should be checking BM_STS or not.Linux has been unconditionally checking BM_STS.
If the chip-set is configured to enable BM_STS,
it can retard or completely prevent entry into
deep C-states -- as illustrated by turbostat:http://userweb.kernel.org/~lenb/acpi/utils/pmtools/turbostat/
ref: Intel Processor Vendor-Specific ACPI Interface Specification
table 4 "_CST FFH GAS Field Encoding"
Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-statehttps://bugzilla.kernel.org/show_bug.cgi?id=15886
Signed-off-by: Len Brown
22 May, 2010
1 commit
-
These were used before cpuidle by the native ACPI idle driver,
which tracked promotion and demotion between states.The code was referenced by CONFIG_ACPI_PROCFS
for /proc/acpi/processor/*/power,
but as we no longer do promotion/demotion, that
reference has been a NOP since the transition.Signed-off-by: Len Brown
15 Mar, 2010
2 commits
-
Rename static get_cpu_id() to acpi_get_cpuid() and export it.
This change also gives us an opportunity to remove the
#ifndef CONFIG_SMP from processor_driver.c and into a header file
where it properly belongs.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
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.
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
28 Jan, 2010
1 commit
-
acpi_integer is now obsolete and removed from the ACPICA code base,
replaced by u64.Signed-off-by: Lin Ming
Signed-off-by: Len Brown
22 Dec, 2009
5 commits
-
When we call _PDC, we get a handle to the processor, allocate the
object list buffer as needed, and free it immediately after calling
_PDC.There's no need to drag around this object list with us everywhere
else, so let's just get rid of it.Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
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 -
The x86 and ia64 implementations of the function in $subject are
exactly the same.Also, since the arch-specific implementations of setting _PDC have
been completely hollowed out, remove the empty shells.Cc: Tony Luck
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown -
The only thing arch-specific about calling _PDC is what bits get
set in the input obj_list buffer.There's no need for several levels of indirection to twiddle those
bits. Additionally, since we're just messing around with a buffer,
we can simplify the interface; no need to pass around the entire
struct acpi_processor * just to get at the buffer.Cc: Tony Luck
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
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
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
27 Aug, 2009
1 commit
-
If the BIOS reports an invalid throttling state (which seems to be
fairly common after system boot), a reset is done to state T0.
Because of a check in acpi_processor_get_throttling_ptc(), the reset
never actually gets executed, which results in the error reoccurring
on every access of for example /proc/acpi/processor/CPU0/throttling.Add a 'force' option to acpi_processor_set_throttling() to ensure
the reset really takes effect.Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389
This patch, together with the next one, fixes a regression introduced in
2.6.30, listed on the regression list. They have been available for 2.5
months now in bugzilla, but have not been picked up, despite various
reminders and without any reason given.Google shows that numerous people are hitting this issue. The issue is in
itself relatively minor, but the bug in the code is clear.The patches have been in all my kernels and today testing has shown that
throttling works correctly with the patches applied when the system
overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14).Signed-off-by: Frans Pop
Acked-by: Zhang Rui
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: Rusty Russell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 Jun, 2009
1 commit
-
arch_acpi_processor_cleanup_pdc() in x86 and ia64 results in memory allocated
for _PDC objects that is never freed and will cause memory leak in case of
physical CPU remove and add. Patch fixes the memory leak by freeing the
objects soon after _PDC is evaluated.Reported-by: Bjorn Helgaas
Signed-off-by: Venkatesh Pallipadi
Signed-off-by: Len Brown
23 Apr, 2009
1 commit
-
Linux-2.6.29 deleted the legacy ACPI idle handler, leaving
the CPU_IDLE handler, which does not track bus master activity.So delete the unused bm_activity field -- it is confusing to
print an always zero value.This patch could break programs that parse
/proc/acpi/processor/*/power, since it deletes this
line from that file:bus master activity: 00000000
http://bugzilla.kernel.org/show_bug.cgi?id=13145
is not fixed by this patch, but provoked this patch.Signed-off-by: Len Brown