20 Jun, 2018
1 commit
-
Commit bca5f557dcea "ACPI / processor: Make acpi_processor_ppc_has_changed()
void" changed one of the declarations of acpi_processor_ppc_has_changed()
to return void, but the !CPU_FREQ version still returns int. Let's return
void to be consistent.Fixes: bca5f557dcea "ACPI / processor: Make acpi_processor_ppc_has_changed() void"
Signed-off-by: Brian Norris
Signed-off-by: Rafael J. Wysocki
21 Mar, 2018
1 commit
-
All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and
changing only the acpi_id. For processors which P-state coordination type
is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information
(_PSD), because Xen will ignore any cpufreq domains created for past CPUs.Albeit for platforms which expose coordination types as SW_ANY or SW_ALL,
this will have some unintended side effects. Effectively, it will look at
the P-state domain existence and *if it already exists* it will skip the
acpi-cpufreq initialization and thus inherit the policy from the first CPU
in the cpufreq domain. This will finally lead to the original cpu not
changing target freq to P0 other than the first in the domain. Which will
make turbo boost not getting enabled (e.g. for 'performance' governor) for
all cpus.This patch fixes that, by also evaluating _PSD when we enumerate all ACPI
processors and thus always uploading the correct info to Xen. We export
acpi_processor_get_psd() for that this purpose, but change signature
to not assume an existent of acpi_processor given that ACPI isn't creating
an acpi_processor for non-dom0 CPUs.Signed-off-by: Joao Martins
Reviewed-by: Boris Ostrovsky
Acked-by: Rafael J. Wysocki
Signed-off-by: Boris Ostrovsky
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
21 Nov, 2016
1 commit
-
The return value of acpi_processor_ppc_has_changed() is never used,
so make it void.Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
18 Nov, 2016
1 commit
-
Currently, intel_pstate is unable to control P-states on my
IvyBridge-based Acer Aspire S5, because they are controlled by SMM
on that machine by default and it is necessary to request OS control
of P-states from it via the SMI Command register exposed in the ACPI
FADT. intel_pstate doesn't do that now, but acpi-cpufreq and other
cpufreq drivers for x86 platforms do.Address this problem by making intel_pstate use the ACPI-defined
mechanism as well. However, intel_pstate is not modular and it
doesn't need the module refcount tricks played by
acpi_processor_notify_smm(), so export the core of this function
to it as acpi_processor_pstate_control() and make it call that.
[The changes in processor_perflib.c related to this should not
make any functional difference for the acpi_processor_notify_smm()
users].To be safe, only call acpi_processor_notify_smm() from intel_pstate
if ACPI _PPC support is enabled in it.Suggested-by: Srinivas Pandruvada
Signed-off-by: Rafael J. Wysocki
Acked-by: Srinivas Pandruvada
20 Sep, 2016
1 commit
-
Install the callbacks via the state machine.
Signed-off-by: Sebastian Andrzej Siewior
Acked-by: "Rafael J. Wysocki"
Cc: Peter Zijlstra
Cc: linux-acpi@vger.kernel.org
Cc: rt@linutronix.de
Cc: Len Brown
Link: http://lkml.kernel.org/r/20160906170457.32393-12-bigeasy@linutronix.de
Signed-off-by: Thomas Gleixner
25 Jul, 2016
1 commit
-
* acpi-processor:
ACPI: enable ACPI_PROCESSOR_IDLE on ARM64
arm64: add support for ACPI Low Power Idle(LPI)
drivers: firmware: psci: initialise idle states using ACPI LPI
cpuidle: introduce CPU_PM_CPU_IDLE_ENTER macro for ARM{32, 64}
arm64: cpuidle: drop __init section marker to arm_cpuidle_init
ACPI / processor_idle: Add support for Low Power Idle(LPI) states
ACPI / processor_idle: introduce ACPI_PROCESSOR_CSTATE* acpi-cppc:
mailbox: pcc: Add PCC request and free channel declarations
ACPI / CPPC: Prevent cpc_desc_ptr points to the invalid data
ACPI: CPPC: Return error if _CPC is invalid on a CPU* acpi-apei:
ACPI / APEI: Add Boot Error Record Table (BERT) support
ACPI / einj: Make error paths more talkative
ACPI / einj: Convert EINJ_PFX to proper pr_fmt* acpi-sleep:
ACPI: Execute _PTS before system reboot
22 Jul, 2016
2 commits
-
ACPI 6.0 introduced an optional object _LPI that provides an alternate
method to describe Low Power Idle states. It defines the local power
states for each node in a hierarchical processor topology. The OSPM can
use _LPI object to select a local power state for each level of processor
hierarchy in the system. They used to produce a composite power state
request that is presented to the platform by the OSPM.Since multiple processors affect the idle state for any non-leaf hierarchy
node, coordination of idle state requests between the processors is
required. ACPI supports two different coordination schemes: Platform
coordinated and OS initiated.This patch adds initial support for Platform coordination scheme of LPI.
Signed-off-by: Sudeep Holla
Signed-off-by: Rafael J. Wysocki -
ACPI 6.0 adds a new method to specify the CPU idle states(C-states)
called Low Power Idle(LPI) states. Since new architectures like ARM64
use only LPIs, introduce ACPI_PROCESSOR_CSTATE to encapsulate all the
code supporting the old style C-states(_CST).This patch will help to extend the processor_idle module to support
LPI.Signed-off-by: Sudeep Holla
Signed-off-by: Rafael J. Wysocki
30 May, 2016
1 commit
-
Follow-on arm64 ACPI/NUMA patches need to map MADT entries very early
(before kmalloc is usable).Add acpi_map_madt_entry() which, indirectly, uses
early_memremap()/early_memunmap() to access the table and parse out
the mpidr. The existing implementation of map_madt_entry() is
modified to take a pointer to the MADT as a parameter and the callers
adjusted.Signed-off-by: David Daney
Acked-by: Catalin Marinas
Signed-off-by: Rafael J. Wysocki
22 Feb, 2016
2 commits
-
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 -
ACPI 6.0 adds support for optional processor container device which may
contain child objects that are either processor devices or other processor
containers. This allows representing hierarchical processor topologies.It is declared using the _HID of ACPI0010. It is an abstract container
used to represent CPU topology and should not be used to hotplug
purposes.If no matching handler is found for a device in acpi_scan_attach_handler,
acpi_bus_attach does a default enumeration for those devices with valid
HID in the acpi namespace. This patch adds a scan handler for these ACPI
processor containers to avoid default that enumeration and ensures the
platform devices are not created for them.Signed-off-by: Sudeep Holla
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
-
* pm-cpufreq: (53 commits)
cpufreq: speedstep-lib: Use monotonic clock
cpufreq: powernv: Increase the verbosity of OCC console messages
cpufreq: sfi: use kmemdup rather than duplicating its implementation
cpufreq: drop !cpufreq_driver check from cpufreq_parse_governor()
cpufreq: rename cpufreq_real_policy as cpufreq_user_policy
cpufreq: remove redundant 'policy' field from user_policy
cpufreq: remove redundant 'governor' field from user_policy
cpufreq: update user_policy.* on success
cpufreq: use memcpy() to copy policy
cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier event
cpufreq: mediatek: Add MT8173 cpufreq driver
dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings
intel_pstate: append more Oracle OEM table id to vendor bypass list
intel_pstate: Add SKY-S support
intel_pstate: Fix possible overflow complained by Coverity
cpufreq: Correct a freq check in cpufreq_set_policy()
cpufreq: Lock CPU online/offline in cpufreq_register_driver()
cpufreq: Replace recover_policy with new_policy in cpufreq_online()
cpufreq: Separate CPU device registration from CPU online
cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling
...
25 Aug, 2015
2 commits
-
This patch introduces a new Kconfig symbol, ACPI_PROCESSOR_IDLE,
which is auto selected by architectures which support the ACPI
based C states for CPU Idle management.The processor_idle driver in its present form contains declarations
specific to X86 and IA64. Since there are no reasonable defaults
for other architectures e.g. ARM64, the driver is selected only for
X86 or IA64.This helps in decoupling the ACPI processor_driver from the ACPI
processor_idle driver which is useful for the upcoming alternative
patchwork for controlling CPU Performance (CPPC) and CPU Idle (LPI).Signed-off-by: Ashwin Chaugule
Signed-off-by: Rafael J. Wysocki -
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
23 Jul, 2015
1 commit
-
acpi_processor_unregister_performance() actually doesn't use its
first argument, so drop it and update the callers accordingly.Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
26 Mar, 2015
1 commit
-
CPU hardware ID (phys_id) is defined as u32 in structure acpi_processor,
but phys_id is used as int in acpi processor driver, so it will lead to
some inconsistence for the drivers.Furthermore, to cater for ACPI arch ports that implement 64 bits CPU
ids a generic CPU physical id type is required.So introduce typedef u32 phys_cpuid_t in a common file, and introduce
a macro PHYS_CPUID_INVALID as (phys_cpuid_t)(-1) if it's not defined
by other archs, this will solve the inconsistence in acpi processor driver,
and will prepare for the ACPI on ARM64 for the 64 bit CPU hardware ID
in the following patch.CC: Rafael J Wysocki
Suggested-by: Lorenzo Pieralisi
Reviewed-by: Grant Likely
Acked-by: Sudeep Holla
Acked-by: Lorenzo Pieralisi
Acked-by: Rafael J. Wysocki
Signed-off-by: Catalin Marinas
[hj: reworked cpu physid map return codes]
Signed-off-by: Hanjun Guo
Signed-off-by: Will Deacon
06 Jan, 2015
1 commit
-
apic_id in MADT table is the CPU hardware id which identify
it self in the system for x86 and ia64, OSPM will use it for
SMP init to map APIC ID to logical cpu number in the early
boot, when the DSDT/SSDT (ACPI namespace) is scanned later, the
ACPI processor driver is probed and the driver will use acpi_id
in DSDT to get the apic_id, then map to the logical cpu number
which is needed by the processor driver.Before ACPI 5.0, only x86 and ia64 were supported in ACPI spec,
so apic_id is used both in arch code and ACPI core which is
pretty fine. Since ACPI 5.0, ARM is supported by ACPI and
APIC is not available on ARM, this will confuse people when
apic_id is both used by x86 and ARM in one function.So convert apic_id to phys_id (which is the original meaning)
in ACPI processor dirver to make it arch agnostic, but leave the
arch dependent code unchanged, no functional change.Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
26 Nov, 2014
1 commit
-
Few elements in the acpi_processor_power structure are unused. It could
be remnant in the header missed while the code got removed from the
corresponding driver file.This patch removes those unused variables in the structure declaration.
Signed-off-by: Sudeep Holla
Signed-off-by: Rafael J. Wysocki
12 Nov, 2014
1 commit
-
In commit 46ba51e (ACPI / processor: Introduce ARCH_MIGHT_HAVE_ACPI_PDC),
acpi_processor_set_pdc() was moved to processor_pdc.c, so update
the comments accordingly.Signed-off-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
17 Jun, 2014
1 commit
-
This patch fixes checkpatch warnings:
"WARNING: __packed is preferred over __attribute__((packed))"
Signed-off-by: Fabian Frederick
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
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
