22 Feb, 2016
1 commit
-
acpi_processor_sleep is neither related nor used by CPUIdle framework.
It's used in system suspend/resume path as a syscore operation. It makes
more sense to move it to acpi/sleep.c where all the S-state transition
(a.k.a. Linux system suspend/hiberate) related code are present.Also make it depend on CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT so that
it's not compiled on architecture like ARM64 where S-states are not
yet defined in ACPI.Signed-off-by: Sudeep Holla
Signed-off-by: Rafael J. Wysocki
21 Dec, 2015
1 commit
-
The processor cooling device is no longer present for passive thermal
control.Commit 239708a3af44 ("ACPI: Split out ACPI PSS from ACPI Processor driver")
moved the processing to a new function acpi_pss_perf_init(), but
missed "return 0" after successful creation. This causes the error
handling functions to be called, which will delete the previously
created processor cooling device.Fixes: 239708a3af44 (ACPI: Split out ACPI PSS from ACPI Processor driver)
Signed-off-by: Srinivas Pandruvada
Cc: 4.3+ # 4.3+
Signed-off-by: Rafael J. Wysocki
13 Oct, 2015
1 commit
-
For each detected ACPI Processor object (ACPI0007), search its
device handle for CPPC specific tables (i.e. _CPC) and extract
CPU specific performance capabilities.Signed-off-by: Ashwin Chaugule
Reviewed-by: Al Stone
Signed-off-by: Rafael J. Wysocki
01 Sep, 2015
1 commit
-
* acpi-scan:
ACPI / bus: Move ACPI bus type registration
ACPI / scan: Move bus operations and notification routines to bus.c
ACPI / scan: Move device matching code to bus.c
ACPI / scan: Move sysfs-related device code to a separate file* acpi-processor:
PCC: Disable compilation by default
ACPI: Decouple ACPI idle and ACPI processor drivers
ACPI: Split out ACPI PSS from ACPI Processor driver
PCC: Initialize PCC Mailbox earlier at boot
ACPI / processor: remove leftover __refdata annotations* acpi-assorted:
ACPI: fix acpi_debugfs_init prototype
ACPI: Remove FSF mailing addresses
25 Aug, 2015
1 commit
-
The ACPI processor driver is currently tied too closely
to the ACPI P-states (PSS) and other related constructs
for controlling CPU performance.The newer ACPI specification (v5.1 onwards) introduces
alternative methods to PSS. These new mechanisms are
described within each ACPI Processor object and so they
need to be scanned whenever a new Processor object is detected.
This patch introduces a new Kconfig symbol to allow for
finer configurability among the two options for controlling
performance states. There is no change in functionality and
the option is auto-selected by the architectures which support it.A future commit will introduce support for CPPC: A newer method of
controlling CPU performance. The OS is not expected to support
CPPC and PSS at the same time, so the Kconfig option lets us make
the two mutually exclusive at compile time.Signed-off-by: Ashwin Chaugule
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki
21 Jul, 2015
1 commit
-
The processor_handler structure does not reference any __init / __exit
code or data. Therefore the __refdata annotation is not needed. It used
to be prior to commit fe7bf106ebc2 ("acpi: delete __cpuinit usage from
all acpi files") due to the __cpuinit annotation of acpi_processor_add().
But with that commit in place that requirement has gone.The same is true for the acpi_cpu_notifier notifier block.
acpi_cpu_soft_notify() used to be marked __cpuinit but lost its
annotation in the above mentioned commit as well. Therefore the __refdata
annotation isn't needed there either.Just drop the unneded __refdata annotations to be able to catch future
section mismatches.Signed-off-by: Mathias Krause
Signed-off-by: Rafael J. Wysocki
08 Jul, 2015
1 commit
-
There is no need to carry potentially outdated Free Software Foundation
mailing address in file headers since the COPYING file includes it.Signed-off-by: Jarkko Nikula
Signed-off-by: Rafael J. Wysocki
07 Aug, 2014
1 commit
-
CPU hotplug happens during S2RAM and CPU notify event will be CPU_XXX_FROZEN.
acpi_cpu_soft_notify() ignores to check these events. This also may make
acpi_cpu_soft_notify() fall into sleep during CPU_DYING/STARTING_FROZEN
events which don't allow callbacks to sleep. This patch is to fix it.Signed-off-by: Lan Tianyu
Signed-off-by: Rafael J. Wysocki
16 May, 2014
1 commit
-
During CPU online/offline testing on a large system, one of the
processors got stuck after the message "bad: scheduling from the
idle thread!". The problem is that acpi_cpu_soft_notify() calls
acpi_bus_get_device() for all action types. CPU_STARTING and
CPU_DYING do not allow the notify handlers to sleep. However,
acpi_bus_get_device() can sleep in acpi_ut_acquire_mutex().Change acpi_cpu_soft_notify() to return immediately for CPU_STARTING
and CPU_DYING as they have no action in this handler.Signed-off-by: Toshi Kani
Signed-off-by: Rafael J. Wysocki
19 Mar, 2014
1 commit
-
We already have a macro for PREFIX of "ACPI: " in
drivers/acpi/internal.h, so remove the duplicate ones
in ACPI drivers when internal.h is included.Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
07 Dec, 2013
1 commit
-
Use ACPI_COMPANION() to get an ACPI device instead of
acpi_bus_get_device() in the processor driver.Signed-off-by: Lan Tianyu
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki
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
07 Oct, 2013
1 commit
-
Fixed a brace coding style issue. (Brace not on the good line)
Signed-off-by: Mathieu Rhéaume
Signed-off-by: Rafael J. Wysocki
27 Aug, 2013
1 commit
-
* acpi-processor:
ACPI / processor: Acquire writer lock to update CPU maps
ACPI / processor: Remove acpi_processor_get_limit_info()
15 Aug, 2013
1 commit
13 Aug, 2013
1 commit
-
acpi_processor_get_limit_info() is only called in the __acpi_processor_start()
and what it does actually is just to check pr->flags.throttling and set limit.
The pr pointer has been checked in the __acpi_processor_start() before
acpi_processor_get_limit_info() being called. It doesn't make sense still to
keep it as a function. So move code to __acpi_processor_start() and remove
acpi_processor_get_limit_info().Signed-off-by: Lan Tianyu
Acked-by: Zhang Rui
Signed-off-by: Rafael J. Wysocki
15 Jul, 2013
2 commits
-
It is quite some time that this one has been deprecated.
Get rid of it.Should some really important user be overseen, it may be reverted and
the userspace program worked on first, but it is time to do something
to get rid of this old stuff...Signed-off-by: Thomas Renninger
Acked-by: Matthew Garrett
Acked-by: Henrique de Moraes Holschuh
Signed-off-by: Rafael J. Wysocki -
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.This removes all the drivers/acpi uses of the __cpuinit macros
from all C files.[1] https://lkml.org/lkml/2013/5/20/589
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Paul Gortmaker
24 Jun, 2013
1 commit
-
ACPI_PROCESSOR_FILE_INFO, ACPI_PROCESSOR_FILE_THROTTLING and
ACPI_PROCESSOR_FILE_LIMIT are used for procfs, but this feature was removed
in commit d09fe555 (ACPI processor: remove deprecated ACPI procfs I/F) long
ago. So, these macros should also be removed.ACPI_PROCESSOR_LIMIT_USER and ACPI_PROCESSOR_LIMIT_THERMAL are not used
by any code, remove them too.Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
31 May, 2013
1 commit
-
Commit ac212b6 (ACPI / processor: Use common hotplug infrastructure)
forgot about initializing the per-CPU 'processors' variables which
lead to ACPI cpuidle failure to use C-states and caused boot slowdown
on multi-CPU machines.Fix the problem by adding per_cpu(processors, pr->id) initialization
to acpi_processor_add() and add make acpi_processor_remove() clean it
up as appropriate.Also modify acpi_processor_stop() so that it doesn't clear
per_cpu(processors, pr->id) on processor driver removal which would
then cause problems to happen when the driver is loaded again.This version of the patch contains fixes from Yinghai Lu.
Reported-and-tested-by: Yinghai Lu
Reported-and-tested-by: Daniel Lezcano
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
04 Mar, 2013
1 commit
-
pr->id is u32 which never < 0, so remove the redundant pr->id < 0
check from acpi_processor_add().[rjw: Changelog]
Signed-off-by: Chen Gang
Signed-off-by: Rafael J. Wysocki
24 Feb, 2013
1 commit
-
The node will be offlined when all memory/cpu on the node is hotremoved.
So we should try offline the node when hotremoving a cpu on the node.Signed-off-by: Wen Congyang
Signed-off-by: Tang Chen
Cc: Yasuaki Ishimatsu
Cc: David Rientjes
Cc: Jiang Liu
Cc: Minchan Kim
Cc: KOSAKI Motohiro
Cc: Mel Gorman
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Peter Zijlstra
Cc: Len Brown
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Feb, 2013
1 commit
-
This changeset is aimed at fixing a few different but related
problems in the ACPI hotplug infrastructure.First of all, since notify handlers may be run in parallel with
acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
and some of them are installed for ACPI handles that have no struct
acpi_device objects attached (i.e. before those objects are created),
those notify handlers have to take acpi_scan_lock to prevent races
from taking place (e.g. a struct acpi_device is found to be present
for the given ACPI handle, but right after that it is removed by
acpi_bus_trim() running in parallel to the given notify handler).
Moreover, since some of them call acpi_bus_scan() and
acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
should be acquired by the callers of these two funtions rather by
these functions themselves.For these reasons, make all notify handlers that can handle device
addition and eject events take acpi_scan_lock and remove the
acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
Accordingly, update all of their users to make sure that they
are always called under acpi_scan_lock.Furthermore, since eject operations are carried out asynchronously
with respect to the notify events that trigger them, with the help
of acpi_bus_hot_remove_device(), even if notify handlers take the
ACPI scan lock, it still is possible that, for example,
acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
the notify handler that scheduled its execution and that
acpi_bus_trim() will remove the device node passed to
acpi_bus_hot_remove_device() for ejection. In that case, the struct
acpi_device object obtained by acpi_bus_hot_remove_device() will be
invalid and not-so-funny things will ensue. To protect agaist that,
make the users of acpi_bus_hot_remove_device() run get_device() on
ACPI device node objects that are about to be passed to it and make
acpi_bus_hot_remove_device() run put_device() on them and check if
their ACPI handles are not NULL (make acpi_device_unregister() clear
the device nodes' ACPI handles for that check to work).Finally, observe that acpi_os_hotplug_execute() actually can fail,
in which case its caller ought to free memory allocated for the
context object to prevent leaks from happening. It also needs to
run put_device() on the device node that it ran get_device() on
previously in that case. Modify the code accordingly.Signed-off-by: Rafael J. Wysocki
Acked-by: Yinghai Lu
26 Jan, 2013
1 commit
-
The second argument of ACPI driver .remove() operation is only used
by the ACPI processor driver and the value passed to that driver
through it is always available from the given struct acpi_device
object's removal_type field. For this reason, the second ACPI driver
.remove() argument is in fact useless, so drop it.Signed-off-by: Rafael J. Wysocki
Reviewed-by: Jiang Liu
Acked-by: Toshi Kani
Acked-by: Yinghai Lu
19 Jan, 2013
1 commit
-
The only difference between acpi_bus_scan() and acpi_bus_add() is the
invocation of acpi_update_all_gpes() in the latter which in fact is
unnecessary, because acpi_update_all_gpes() has already been called
by acpi_scan_init() and the way it is implemented guarantees the next
invocations of it to do nothing.For this reason, drop acpi_bus_add() and make all its callers use
acpi_bus_scan() directly instead of it. Additionally, rearrange the
code in acpi_scan_init() slightly to improve the visibility of the
acpi_update_all_gpes() call in there.Signed-off-by: Rafael J. Wysocki
Acked-by: Yinghai Lu
15 Jan, 2013
1 commit
-
Should use acpi_device pointer directly instead of use handle and
get the device pointer again later.Signed-off-by: Yinghai Lu
Signed-off-by: Rafael J. Wysocki
03 Jan, 2013
2 commits
-
The callers of acpi_bus_add() usually assume that if it has
succeeded, then a struct acpi_device object has been attached to
the handle passed as the first argument. Unfortunately, however,
this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add()
too as a result, may return a pointer to a different struct
acpi_device object on success (it may be an object corresponding to
one of the descendant ACPI nodes in the namespace scope below that
handle).For this reason, the callers of acpi_bus_add() who care about
whether or not a struct acpi_device object has been created for
its first argument need to check that using acpi_bus_get_device()
anyway, so the second argument of acpi_bus_add() is not really
useful for them. The same observation applies to acpi_bus_scan()
executed directly from acpi_scan_init().Therefore modify the relevant callers of acpi_bus_add() to check the
existence of the struct acpi_device in question with the help of
acpi_bus_get_device() and drop the no longer necessary second
argument of acpi_bus_add(). Accordingly, modify acpi_scan_init() to
use acpi_bus_get_device() to get acpi_root and drop the no longer
needed second argument of acpi_bus_scan().Signed-off-by: Rafael J. Wysocki
Acked-by: Yinghai Lu
Acked-by: Toshi Kani -
Notice that acpi_bus_add() uses only 2 of its 4 arguments and
redefine its header to match the body. Update all of its callers as
necessary and observe that this leads to quite a number of removed
lines of code (Linus will like that).Add a kerneldoc comment documenting acpi_bus_add() and wonder how
its callers make wrong assumptions about the second argument (make
note to self to take care of that later).Signed-off-by: Rafael J. Wysocki
Acked-by: Yinghai Lu
Acked-by: Toshi Kani
22 Nov, 2012
1 commit
-
Updated CPU hotplug error messages with acpi_handle_(),
dev_() and pr_(). Modified some messages for
clarity. Added error status / id info to the messages where
needed.Signed-off-by: Toshi Kani
Tested-by: Vijay Mohan Pandarathil
Signed-off-by: Rafael J. Wysocki
15 Nov, 2012
2 commits
-
Added support of CPU hot-remove via an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation. acpi_os_hotplug_execute()
runs the hot-remove operation in kacpi_hotplug_wq and serializes
it between ACPI hot-remove and sysfs eject requests.Signed-off-by: Toshi Kani
Reviewed-by: Yasuaki Ishimatsu
Tested-by: IgorMammedov
Tested-by: Vijay Mohan Pandarathil
Tested-by: Prarit Bhargava
Signed-off-by: Rafael J. Wysocki -
Even if acpi_processor_handle_eject() offlines cpu, there is a chance
to online the cpu after that. So the patch closes the window by using
get/put_online_cpus().Why does the patch change _cpu_up() logic?
The patch cares the race of hot-remove cpu and _cpu_up(). If the patch
does not change it, there is the following race.hot-remove cpu | _cpu_up()
------------------------------------- ------------------------------------
call acpi_processor_handle_eject() |
call cpu_down() |
call get_online_cpus() |
| call cpu_hotplug_begin() and stop here
call arch_unregister_cpu() |
call acpi_unmap_lsapic() |
call put_online_cpus() |
| start and continue _cpu_up()
return acpi_processor_remove() |
continue hot-remove the cpu |So _cpu_up() can continue to itself. And hot-remove cpu can also continue
itself. If the patch changes _cpu_up() logic, the race disappears as below:hot-remove cpu | _cpu_up()
-----------------------------------------------------------------------
call acpi_processor_handle_eject() |
call cpu_down() |
call get_online_cpus() |
| call cpu_hotplug_begin() and stop here
call arch_unregister_cpu() |
call acpi_unmap_lsapic() |
cpu's cpu_present is set |
to false by set_cpu_present()|
call put_online_cpus() |
| start _cpu_up()
| check cpu_present() and return -EINVAL
return acpi_processor_remove() |
continue hot-remove the cpu |Signed-off-by: Yasuaki Ishimatsu
Reviewed-by: Srivatsa S. Bhat
Reviewed-by: Toshi Kani
Signed-off-by: Rafael J. Wysocki
26 Oct, 2012
1 commit
-
We handle NOTIFY_THROTTLING so don't then fall through to unsupported event.
Signed-off-by: Alan Cox
Signed-off-by: Rafael J. Wysocki
16 Sep, 2012
2 commits
-
The 'errata' variable is a global variable which is set to zero,
no need to do that with a memset in the init function.Signed-off-by: Daniel Lezcano
Signed-off-by: Rafael J. Wysocki -
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
03 Aug, 2012
2 commits
-
In commit 99b725084 "ACPI processor hotplug: Delay acpi_processor_start()
call for hotplugged cores", acpi_processor_hotplug(pr) was wrongly replaced
by acpi_processor_cst_has_changed() inside the acpi_cpu_soft_notify(). This
patch will restore it back, fixing the tick_broadcast_mask regression:
https://lkml.org/lkml/2012/7/30/169Signed-off-by: Feng Tang
Cc: Thomas Renninger
Cc: # 3.3+
Reviewed-by: Rafael J. Wysocki
Reviewed-by: Deepthi Dharwar
Signed-off-by: Len Brown
27 Jul, 2012
1 commit
-
Pull ACPI & power management update from Len Brown:
"Re-write of the turbostat tool.
lower overhead was necessary for measuring very large system when
they are very idle.IVB support in intel_idle
It's what I run on my IVB, others should be able to also:-)ACPICA core update
We have found some bugs due to divergence between Linux and the
upstream ACPICA base. Most of these patches are to reduce that
divergence to reduce the risk of future bugs.Some cpuidle updates, mostly for non-Intel
More will be coming, as they depend on this part.Some thermal management changes needed by non-ACPI systems.
Some _OST (OS Status Indication) updates for hot ACPI hot-plug."
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: (51 commits)
Thermal: Documentation update
Thermal: Add Hysteresis attributes
Thermal: Make Thermal trip points writeable
ACPI/AC: prevent OOPS on some boxes due to missing check power_supply_register() return value check
tools/power: turbostat: fix large c1% issue
tools/power: turbostat v2 - re-write for efficiency
ACPICA: Update to version 20120711
ACPICA: AcpiSrc: Fix some translation issues for Linux conversion
ACPICA: Update header files copyrights to 2012
ACPICA: Add new ACPI table load/unload external interfaces
ACPICA: Split file: tbxface.c -> tbxfload.c
ACPICA: Add PCC address space to space ID decode function
ACPICA: Fix some comment fields
ACPICA: Table manager: deploy new firmware error/warning interfaces
ACPICA: Add new interfaces for BIOS(firmware) errors and warnings
ACPICA: Split exception code utilities to a new file, utexcep.c
ACPI: acpi_pad: tune round_robin_time
ACPICA: Update to version 20120620
ACPICA: Add support for implicit notify on multiple devices
ACPICA: Update comments; no functional change
...
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
...
