Commit Graph

1184 Commits

Author SHA1 Message Date
Rafael J. Wysocki
57aa5ea0ee Revert "cpufreq: Enable big.LITTLE cpufreq driver on arm64"
This reverts commit 4920ab8497 (cpufreq: Enable big.LITTLE cpufreq
driver on arm64) that breaks build on arm64.

Fixes: 4920ab8497 (cpufreq: Enable big.LITTLE cpufreq driver on arm64)
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-06 22:50:18 +02:00
Viresh Kumar
00917ddc7c cpufreq: Tegra: implement intermediate frequency callbacks
Tegra has been switching to intermediate frequency (pll_p_clk) forever.
CPUFreq core has better support for handling notifications for these
frequencies and so we can adapt Tegra's driver to it.

Also do a WARN() if clk_set_parent() fails while moving back to pll_x
as we should have atleast restored to earlier frequency on error.

Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-05 23:34:07 +02:00
Viresh Kumar
1c03a2d04d cpufreq: add support for intermediate (stable) frequencies
Douglas Anderson, recently pointed out an interesting problem due to which
udelay() was expiring earlier than it should.

While transitioning between frequencies few platforms may temporarily switch to
a stable frequency, waiting for the main PLL to stabilize.

For example: When we transition between very low frequencies on exynos, like
between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz.
No CPUFREQ notification is sent for that. That means there's a period of time
when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz
and 300MHz. And so udelay behaves badly.

To get this fixed in a generic way, introduce another set of callbacks
get_intermediate() and target_intermediate(), only for drivers with
target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.

get_intermediate() should return a stable intermediate frequency platform wants
to switch to, and target_intermediate() should set CPU to that frequency,
before jumping to the frequency corresponding to 'index'. Core will take care of
sending notifications and driver doesn't have to handle them in
target_intermediate() or target_index().

NOTE: ->target_index() should restore to policy->restore_freq in case of
failures as core would send notifications for that.

Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-05 23:32:29 +02:00
Rafael J. Wysocki
5ece239918 Merge back earlier cpufreq material.
Conflicts:
	arch/mips/loongson/lemote-2f/clock.c
	drivers/cpufreq/intel_pstate.c
2014-06-03 15:03:27 +02:00
Doug Smythies
bf8102228a intel_pstate: Improve initial busy calculation
This change makes the busy calculation using 64 bit math which prevents
overflow for large values of aperf/mperf.

Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Doug Smythies <dsmythies@telus.net>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-02 12:46:01 +02:00
Dirk Brandewie
c4ee841f60 intel_pstate: add sample time scaling
The PID assumes that samples are of equal time, which for a deferable
timers this is not true when the system goes idle.  This causes the
PID to take a long time to converge to the min P state and depending
on the pattern of the idle load can make the P state appear stuck.

The hold-off value of three sample times before using the scaling is
to give a grace period for applications that have high performance
requirements and spend a lot of time idle,  The poster child for this
behavior is the ffmpeg benchmark in the Phoronix test suite.

Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-02 12:45:05 +02:00
Dirk Brandewie
f0fe3cd7e1 intel_pstate: Correct rounding in busy calculation
Changing to fixed point math throughout the busy calculation in
commit e66c1768 (Change busy calculation to use fixed point
math.) Introduced some inaccuracies by rounding the busy value at two
points in the calculation.  This change removes roundings and moves
the rounding to the output of the PID where the calculations are
complete and the value returned as an integer.

Fixes: e66c176837 (intel_pstate: Change busy calculation to use fixed point math.)
Reported-by: Doug Smythies <dsmythies@telus.net>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-02 12:44:59 +02:00
Dirk Brandewie
adacdf3f2b intel_pstate: Remove C0 tracking
Commit fcb6a15c (intel_pstate: Take core C0 time into account for core
busy calculation) introduced a regression referenced below.  The issue
with "lockup" after suspend that this commit was addressing is now dealt
with in the suspend path.

Fixes: fcb6a15c2e (intel_pstate: Take core C0 time into account for core busy calculation)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=66581
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75121
Reported-by: Doug Smythies <dsmythies@telus.net>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-02 12:44:48 +02:00
Viresh Kumar
8d65775d17 cpufreq: handle calls to ->target_index() in separate routine
Handling calls to ->target_index() has got complex over time and might become
more complex. So, its better to take target_index() bits out in another routine
__target_index() for better code readability. Shouldn't have any functional
impact.

Tested-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-29 01:27:38 +02:00
Paul Bolle
1ef546f22f cpufreq: s5pv210: drop check for CONFIG_PM_VERBOSE
A pr_err() was added in v3.1. It was guarded by a check for
CONFIG_PM_VERBOSE. The Kconfig symbol PM_VERBOSE was removed in v3.0. So
this pr_err() has never been used. Drop that check and clean up the
message a bit.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-27 01:06:44 +02:00
Stratos Karafotis
94f89e0760 cpufreq: intel_pstate: Remove unused member name of cpudata
Although, a value is assigned to member name of struct cpudata,
it is never used.

We can safely remove it.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-27 00:52:32 +02:00
Rafael J. Wysocki
9b961aa99b Merge branches 'pm-cpufreq' and 'acpi-thermal'
* pm-cpufreq:
  cpufreq: cpu0: drop wrong devm usage
  cpufreq: remove race while accessing cur_policy

* acpi-thermal:
  ACPI / thermal: fix workqueue destroy order
2014-05-26 23:20:16 +02:00
Linus Torvalds
478c7cf7a8 ACPI and power management fixes for 3.15-rc6
- ACPICA fix for a stale pointer access introduced by a recent
    commit in the XSDT validation code from Lv Zheng.
 
  - ACPICA fix for the default value of the command line switch
    to favor 32-bit FADT addresses (in case there's a conflict
    between a 64-bit and a 32-bit address).  The previous default
    was that the 32-bit version would take precedence and we tried
    to change it to the other way around and it didn't work.
    From Lv Zheng.
 
  - A TPM commit related to ACPI _DSM in 3.14 caused the driver to
    refuse to load if a specific _DSM was missing and that broke
    resume from system suspend on Chromebooks that require the TPM
    hardware to be restored to a working state during resume by the
    OS.  Restore the old behavior to load the driver if the _DSM
    in question is not present, but prevent it from using the
    feature the _DSM is for.
 
  - ACPI AC driver conversion in 3.13 broke thermal management on
    at least one machine and has to be reverted.  From Guenter Roeck.
 
  - Two reverts of 3.13 commits that attempted to remove the old ACPI
    battery interface in /proc, but turned out to break some utilities
    still using that interface.  From Lan Tianyu.
 
  - ACPI processor driver fix to prevent acpi_processor_add() from
    modifying the CPU device's .offline field which leads to breakage
    if the initial online of the CPU fails.  From Igor Mammedov.
 
  - Two intel_pstate fixes, one to take a BayTrail documentation update
    into account and one to avoid forcing the maximum P-state on init
    which causes CPU PM trouble on systems with P-states coordination
    when one of the CPU cores is initialized after an offline/online
    cycle triggered by user space.  Both stable candidates, from
    Dirk Brandewie.
 
  - Fix for the ACPI video DMI blacklist entry for Dell Inspiron 7520
    from Aaron Lu.
 
  - Two new ACPI video blacklist entries for machines shipping with
    Win8 that need to use native backlight so that it can be controlled
    in a usual way (which doesn't work otherwise due bugs in the ACPI
    tables) from Hans de Goede.
 
  - Two ACPI _OSI quirks for systems that need them to work correctly
    with Linux from Edward Lin and Hans de Goede.
 
 /
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQIcBAABCAAGBQJTdow6AAoJEILEb/54YlRxUWcP/0nczFCxZ7C1c7l7Ya8r9iRZ
 HXT+AAbakanPs6Ms4VRxao65v1AcdlruWHPhJ6JiEoiO60yKxIIzy7f3mO5gVesr
 tcaxaFaCTNdUDFdRDhyN6y+RzO/ohYSKdOJng2tcz2IvcsRD93hXk+095BlVzfJV
 EFycqXPb3nmP6oZo1KjPebk4cmlC8Sw9aWcBxK0O1aRoIrAdObf3+rCXfc2/FvC0
 vAquOI2OaJ0bwNl7QhGHMLMnvoDvq+/y2mDQ+BvxPERbtDBDS66tkhjsxEx89kpi
 ow6WKX1vgfsWYGa5tCxFDZvYIYP5x4+YWPwvYfOFmCO520PUIojT81qT+P6hLHMy
 jf2G7QWvL/3qn89qKsR26YNE/fadNDZq0IHh3KD8kOaKtXBV30fIh2rLG3XZfB8q
 lhWAcx5ot2ZoQy5ppAuKNG+zA6MniWbN/a5acUIS6zsvVRFkGeZE5ORyEUgkWMjk
 QiiL3kcx/Fe528A1cMVXR2fb4kzKBpnVXxWQlzptKCX/3JAOxe6ElZqHMDff983b
 LHJjMfVUX9m1yGUZHqbH6CiK9kuQv2fQXSESLrkUDItVs9VFskYQb6AZE5Ow+k+A
 QKnDg7n81YlYiau997g0+yA7EqwQmQZx+EwfVtOIfppOlp4LFbCKC6Ytu9pcgbZB
 GuYsd/bPvEVswylJMu6U
 =v+oA
 -----END PGP SIGNATURE-----

Merge tag 'pm+acpi-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull ACPI and power management fixes from Rafael Wysocki:
 "Still fixing regressions (partly by reverting commits that broke
  things for people), fixing other stable-candidate bugs and adding some
  blacklist entries for ACPI video and _OSI.

  Two ACPICA regression fixes (one recent and one for a 3.14 commit), a
  fix for an ACPI-related regression in TPM (introduced in 3.14), a
  revert of the ACPI AC driver conversion in 3.13 that went wrong for an
  unknown reason, two reverts of commits that attempted to remove an old
  user space interface in /proc and broke some utilities, in 3.13 too, a
  fix for a CPU hotplug bug in the ACPI processor driver (stable
  material), two (stable candidate) fixes for intel_pstate and a few new
  blacklist entries, mostly for systems that shipped with Windows 8.

  Specifics:

   - ACPICA fix for a stale pointer access introduced by a recent commit
     in the XSDT validation code from Lv Zheng.

   - ACPICA fix for the default value of the command line switch to
     favor 32-bit FADT addresses (in case there's a conflict between a
     64-bit and a 32-bit address).  The previous default was that the
     32-bit version would take precedence and we tried to change it to
     the other way around and it didn't work.  From Lv Zheng.

   - A TPM commit related to ACPI _DSM in 3.14 caused the driver to
     refuse to load if a specific _DSM was missing and that broke resume
     from system suspend on Chromebooks that require the TPM hardware to
     be restored to a working state during resume by the OS.  Restore
     the old behavior to load the driver if the _DSM in question is not
     present, but prevent it from using the feature the _DSM is for.

   - ACPI AC driver conversion in 3.13 broke thermal management on at
     least one machine and has to be reverted.  From Guenter Roeck.

   - Two reverts of 3.13 commits that attempted to remove the old ACPI
     battery interface in /proc, but turned out to break some utilities
     still using that interface.  From Lan Tianyu.

   - ACPI processor driver fix to prevent acpi_processor_add() from
     modifying the CPU device's .offline field which leads to breakage
     if the initial online of the CPU fails.  From Igor Mammedov.

   - Two intel_pstate fixes, one to take a BayTrail documentation update
     into account and one to avoid forcing the maximum P-state on init
     which causes CPU PM trouble on systems with P-states coordination
     when one of the CPU cores is initialized after an offline/online
     cycle triggered by user space.  Both stable candidates, from Dirk
     Brandewie.

   - Fix for the ACPI video DMI blacklist entry for Dell Inspiron 7520
     from Aaron Lu.

   - Two new ACPI video blacklist entries for machines shipping with
     Win8 that need to use native backlight so that it can be controlled
     in a usual way (which doesn't work otherwise due bugs in the ACPI
     tables) from Hans de Goede.

   - Two ACPI _OSI quirks for systems that need them to work correctly
     with Linux from Edward Lin and Hans de Goede"

* tag 'pm+acpi-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / video: Revert native brightness quirk for ThinkPad T530
  intel_pstate: remove setting P state to MAX on init
  ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses.
  ACPI / video: correct DMI tag for Dell Inspiron 7520
  intel_pstate: Set turbo VID for BayTrail
  ACPI / TPM: Fix resume regression on Chromebooks
  ACPI / proc: Do not say when /proc interfaces will be deleted in Kconfig
  ACPI / processor: do not mark present at boot but not onlined CPU as onlined
  ACPI: Revert "ACPI / AC: convert ACPI ac driver to platform bus"
  ACPI / blacklist: Add dmi_enable_osi_linux quirk for Asus EEE PC 1015PX
  ACPI: blacklist win8 OSI for Dell Inspiron 7737
  ACPI / video: Add use_native_backlight quirks for more systems
  ACPI: Revert "ACPI / Battery: Remove battery's proc directory"
  ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c"
  ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table().
2014-05-21 17:58:34 +09:00
Stratos Karafotis
1e4988563d cpufreq: Break out early when frequency equals target_freq
Many drivers keep frequencies in frequency table in ascending
or descending order. When governor tries to change to policy->min
or policy->max respectively then the cpufreq_frequency_table_target
could return on first iteration. This will save some iteration cycles.

So, break out early when a frequency in cpufreq_frequency_table
equals to target one.

Testing this during kernel compilation using ondemand governor
with a frequency table in ascending order, the
cpufreq_frequency_table_target returned early on the first
iteration at about 30% of times called.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-20 14:02:09 +02:00
Lucas Stach
e3beb0ac52 cpufreq: cpu0: drop wrong devm usage
This driver is using devres managed calls incorrectly, giving the cpu0
device as first parameter instead of the cpufreq platform device.
This results in resources not being freed if the cpufreq platform device
is unbound, for example if probing has to be deferred for a missing
regulator.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-20 01:29:20 +02:00
Bibek Basu
c5450db85b cpufreq: remove race while accessing cur_policy
While accessing cur_policy during executing events
CPUFREQ_GOV_START, CPUFREQ_GOV_STOP, CPUFREQ_GOV_LIMITS,
same mutex lock is not taken, dbs_data->mutex, which leads
to race and data corruption while running continious suspend
resume test. This is seen with ondemand governor with suspend
resume test using rtcwake.

 Unable to handle kernel NULL pointer dereference at virtual address 00000028
 pgd = ed610000
 [00000028] *pgd=adf11831, *pte=00000000, *ppte=00000000
 Internal error: Oops: 17 [] PREEMPT SMP ARM
 Modules linked in: nvhost_vi
 CPU: 1 PID: 3243 Comm: rtcwake Not tainted 3.10.24-gf5cf9e5 
 task: ee708040 ti: ed61c000 task.ti: ed61c000
 PC is at cpufreq_governor_dbs+0x400/0x634
 LR is at cpufreq_governor_dbs+0x3f8/0x634
 pc : [<c05652b8>] lr : [<c05652b0>] psr: 600f0013
 sp : ed61dcb0 ip : 000493e0 fp : c1cc14f0
 r10: 00000000 r9 : 00000000 r8 : 00000000
 r7 : eb725280 r6 : c1cc1560 r5 : eb575200 r4 : ebad7740
 r3 : ee708040 r2 : ed61dca8 r1 : 001ebd24 r0 : 00000000
 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
 Control: 10c5387d Table: ad61006a DAC: 00000015
 [<c05652b8>] (cpufreq_governor_dbs+0x400/0x634) from [<c055f700>] (__cpufreq_governor+0x98/0x1b4)
 [<c055f700>] (__cpufreq_governor+0x98/0x1b4) from [<c0560770>] (__cpufreq_set_policy+0x250/0x320)
 [<c0560770>] (__cpufreq_set_policy+0x250/0x320) from [<c0561dcc>] (cpufreq_update_policy+0xcc/0x168)
 [<c0561dcc>] (cpufreq_update_policy+0xcc/0x168) from [<c0561ed0>] (cpu_freq_notify+0x68/0xdc)
 [<c0561ed0>] (cpu_freq_notify+0x68/0xdc) from [<c008eff8>] (notifier_call_chain+0x4c/0x8c)
 [<c008eff8>] (notifier_call_chain+0x4c/0x8c) from [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68)
 [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) from [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28)
 [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) from [<c00aac6c>] (pm_qos_update_bounded_target+0xd8/0x310)
 [<c00aac6c>] (pm_qos_update_bounded_target+0xd8/0x310) from [<c00ab3b0>] (__pm_qos_update_request+0x64/0x70)
 [<c00ab3b0>] (__pm_qos_update_request+0x64/0x70) from [<c004b4b8>] (tegra_pm_notify+0x114/0x134)
 [<c004b4b8>] (tegra_pm_notify+0x114/0x134) from [<c008eff8>] (notifier_call_chain+0x4c/0x8c)
 [<c008eff8>] (notifier_call_chain+0x4c/0x8c) from [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68)
 [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) from [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28)
 [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) from [<c00ac228>] (pm_notifier_call_chain+0x1c/0x34)
 [<c00ac228>] (pm_notifier_call_chain+0x1c/0x34) from [<c00ad38c>] (enter_state+0xec/0x128)
 [<c00ad38c>] (enter_state+0xec/0x128) from [<c00ad400>] (pm_suspend+0x38/0xa4)
 [<c00ad400>] (pm_suspend+0x38/0xa4) from [<c00ac114>] (state_store+0x70/0xc0)
 [<c00ac114>] (state_store+0x70/0xc0) from [<c027b1e8>] (kobj_attr_store+0x14/0x20)
 [<c027b1e8>] (kobj_attr_store+0x14/0x20) from [<c019cd9c>] (sysfs_write_file+0x104/0x184)
 [<c019cd9c>] (sysfs_write_file+0x104/0x184) from [<c0143038>] (vfs_write+0xd0/0x19c)
 [<c0143038>] (vfs_write+0xd0/0x19c) from [<c0143414>] (SyS_write+0x4c/0x78)
 [<c0143414>] (SyS_write+0x4c/0x78) from [<c000f080>] (ret_fast_syscall+0x0/0x30)
 Code: e1a00006 eb084346 e59b0020 e5951024 (e5903028)
 ---[ end trace 0488523c8f6b0f9d ]---

Signed-off-by: Bibek Basu <bbasu@nvidia.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-20 01:25:15 +02:00
Viresh Kumar
e7b453d3dd cpufreq: Tegra: drop wrapper around tegra_update_cpu_speed()
Tegra has implemented an unnecessary wrapper over tegra_update_cpu_speed(), i.e.
tegra_target(), which wasn't doing anything apart of calling
tegra_update_cpu_speed(). Get rid of that and use tegra_target() directly.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 01:38:31 +02:00
Philipp Zabel
5ee73ebe09 cpufreq: imx6q: Remove unused include
There is no need to include delay.h.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 01:34:42 +02:00
Philipp Zabel
f8269c1922 cpufreq: imx6q: Drop devm_clk/regulator_get usage
This driver is using devres managed calls incorrectly, giving the cpu0
device as first parameter instead of the cpufreq platform device.
This results in resources not being freed if the cpufreq platform device
is unbound, for example if probing has to be deferred for a missing
regulator.
Supporting probe deferral properly is a prerequisite to enabling the
internal LDO bypass on i.MX6 and regulating the CPU voltage with an
external regulator.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 01:32:15 +02:00
Stratos Karafotis
e54173b4ed cpufreq: powernow-k8: Suppress checkpatch warnings
Suppress the following checkpatch.pl warnings:

 - WARNING: Prefer pr_err(... to printk(KERN_ERR ...
 - WARNING: Prefer pr_info(... to printk(KERN_INFO ...
 - WARNING: Prefer pr_warn(... to printk(KERN_WARNING ...
 - WARNING: quoted string split across lines
 - WARNING: please, no spaces at the start of a line

Also, define the pr_fmt macro instead of PFX for the module name.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 01:27:01 +02:00
Brian Norris
60d1ea4e0a cpufreq: powernv: make local function static
powernv_cpufreq_get() is only referenced in this file.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org> on V2.
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 01:25:46 +02:00
Mark Brown
4920ab8497 cpufreq: Enable big.LITTLE cpufreq driver on arm64
There are arm64 big.LITTLE systems so enable the big.LITTLE cpufreq driver.
While IKS is not available for these systems the driver is still useful
since it manages clusters with shared frequencies which is the common case
for these systems.

Long term combining the cpufreq-cpu0 and big.LITTLE drivers may be a
more sensible option but that is substantially more complex especially
in the case of IKS.

Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 01:22:14 +02:00
Jingoo Han
dfcb0a54a6 cpufreq: nforce2: remove DEFINE_PCI_DEVICE_TABLE macro
Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
is deprecated.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-17 01:16:15 +02:00
Dirk Brandewie
d40a63c45b intel_pstate: remove setting P state to MAX on init
Setting the P state of the core to max at init time is a hold over
from early implementation of intel_pstate where intel_pstate disabled
cpufreq and loaded VERY early in the boot sequence.  This was to
ensure that intel_pstate did not affect boot time. This in not needed
now that intel_pstate is a cpufreq driver.

Removing this covers the case where a CPU has gone through a manual
CPU offline/online cycle and the P state is set to MAX on init and the
CPU immediately goes idle.  Due to HW coordination the P state request
on the idle CPU will drag all cores to MAX P state until the load is
reevaluated when to core goes non-idle.

Reported-by: Patrick Marlier <patrick.marlier@gmail.com>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-13 17:39:13 +02:00
Dirk Brandewie
c7e241df59 intel_pstate: Add CPU IDs for Broadwell processors
Add support for Broadwell processors.

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-13 02:54:33 +02:00
Aaro Koskinen
8e8acb3296 MIPS/loongson2_cpufreq: Fix CPU clock rate setting
Loongson2 has been using (incorrectly) kHz for cpu_clk rate. This has
been unnoticed, as loongson2_cpufreq was the only place where the rate
was set/get. After commit 652ed95d5f
(cpufreq: introduce cpufreq_generic_get() routine) things however broke,
and now loops_per_jiffy adjustments are incorrect (1000 times too long).
The patch fixes this by changing cpu_clk rate to Hz.

Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: stable@vger.kernel.org
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: cpufreq@vger.kernel.org
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Patchwork: https://patchwork.linux-mips.org/patch/6678/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-05-13 00:29:41 +02:00
Dirk Brandewie
21855ff5bc intel_pstate: Set turbo VID for BayTrail
A documentation update exposed that there is a separate set of VID
values that must be used in the turbo/boost P state range.  Add
enumerating and setting the correct VID for P states in the turbo
range.

Cc: v3.13+ <stable@vger.kernel.org> # v3.13+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-12 01:58:58 +02:00
Stratos Karafotis
5eeaf1f189 cpufreq: Fix build error on some platforms that use cpufreq_for_each_*
On platforms that use cpufreq_for_each_* macros, build fails if
CONFIG_CPU_FREQ=n, e.g. ARM/shmobile/koelsch/non-multiplatform:

drivers/built-in.o: In function `clk_round_parent':
clkdev.c:(.text+0xcf168): undefined reference to `cpufreq_next_valid'
drivers/built-in.o: In function `clk_rate_table_find':
clkdev.c:(.text+0xcf820): undefined reference to `cpufreq_next_valid'
make[3]: *** [vmlinux] Error 1

Fix this making cpufreq_next_valid function inline and move it to
cpufreq.h.

Fixes: 27e289dce2 (cpufreq: Introduce macros for cpufreq_frequency_table iteration)
Reported-and-tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-08 13:10:56 +02:00
Nishanth Menon
a0dd7b7965 PM / OPP: Move cpufreq specific OPP functions out of generic OPP library
CPUFreq specific helper functions for OPP (Operating Performance Points)
now use generic OPP functions that allow CPUFreq to be be moved back
into CPUFreq framework. This allows for independent modifications
or future enhancements as needed isolated to just CPUFreq framework
alone.

Here, we just move relevant code and documentation to make this part of
CPUFreq infrastructure.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-07 00:39:03 +02:00
Srivatsa S. Bhat
ca654dc3a9 cpufreq: Catch double invocations of cpufreq_freq_transition_begin/end
Some cpufreq drivers were redundantly invoking the _begin() and _end()
APIs around frequency transitions, and this double invocation (one from
the cpufreq core and the other from the cpufreq driver) used to result
in a self-deadlock, leading to system hangs during boot. (The _begin()
API makes contending callers wait until the previous invocation is
complete. Hence, the cpufreq driver would end up waiting on itself!).

Now all such drivers have been fixed, but debugging this issue was not
very straight-forward (even lockdep didn't catch this). So let us add a
debug infrastructure to the cpufreq core to catch such issues more easily
in the future.

We add a new field called 'transition_task' to the policy structure, to keep
track of the task which is performing the frequency transition. Using this
field, we make note of this task during _begin() and print a warning if we
find a case where the same task is calling _begin() again, before completing
the previous frequency transition using the corresponding _end().

We have left out ASYNC_NOTIFICATION drivers from this debug infrastructure
for 2 reasons:

1. At the moment, we have no way to avoid a particular scenario where this
   debug infrastructure can emit false-positive warnings for such drivers.
   The scenario is depicted below:

         Task A						Task B

    /* 1st freq transition */
    Invoke _begin() {
            ...
            ...
    }

    Change the frequency

    /* 2nd freq transition */
    Invoke _begin() {
	    ...	//waiting for B to
            ... //finish _end() for
	    ... //the 1st transition
	    ...	      |				Got interrupt for successful
	    ...	      |				change of frequency (1st one).
	    ...       |
	    ...	      |				/* 1st freq transition */
	    ...	      |				Invoke _end() {
	    ...	      |					...
	    ...	      V				}
	    ...
	    ...
    }

   This scenario is actually deadlock-free because, once Task A changes the
   frequency, it is Task B's responsibility to invoke the corresponding
   _end() for the 1st frequency transition. Hence it is perfectly legal for
   Task A to go ahead and attempt another frequency transition in the meantime.
   (Of course it won't be able to proceed until Task B finishes the 1st _end(),
   but this doesn't cause a deadlock or a hang).

   The debug infrastructure cannot handle this scenario and will treat it as
   a deadlock and print a warning. To avoid this, we exclude such drivers
   from the purview of this code.

2. Luckily, we don't _need_ this infrastructure for ASYNC_NOTIFICATION drivers
   at all! The cpufreq core does not automatically invoke the _begin() and
   _end() APIs during frequency transitions in such drivers. Thus, the driver
   alone is responsible for invoking _begin()/_end() and hence there shouldn't
   be any conflicts which lead to double invocations. So, we can skip these
   drivers, since the probability that such drivers will hit this problem is
   extremely low, as outlined above.

Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-07 00:32:39 +02:00
Stratos Karafotis
6b17ddb2a5 intel_pstate: Remove sample parameter in intel_pstate_calc_busy
Since commit d37e2b7644 ("intel_pstate: remove unneeded sample buffers")
we use only one sample. So, there is no need to pass the sample
pointer to intel_pstate_calc_busy. Instead, get the pointer from
cpudata. Also, remove the unused SAMPLE_COUNT macro.

While at it, reformat the first line in this function.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-07 00:29:51 +02:00
Stratos Karafotis
735dc2498b cpufreq: Kconfig: Fix spelling errors
Fix 4 spelling errors in help sections.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-01 01:18:19 +02:00
Viresh Kumar
dec102aa9a cpufreq: Make linux-pm@vger.kernel.org official mailing list
There has been confusion all the time about which mailing list to follow
for cpufreq activities, linux-pm@vger.kernel.org or cpufreq@vger.kernel.org.

Since patches sent to cpufreq@vger.kernel.org don't go to Patchwork
which is a maintenance workflow problem, make linux-pm@vger.kernel.org
the official mailing list for cpufreq stuff and remove all references
of cpufreq@vger.kernel.org from kernel source.

Later, we can request that the list be dropped entirely.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-01 01:15:32 +02:00
Chanwoo Choi
e5eaa445b0 cpufreq: exynos: Use dev_err/info function instead of pr_err/info
This patch uses dev_err/info function to show accurate log message
with device name instead of pr_err/info function.

Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-01 01:00:39 +02:00
Rafael J. Wysocki
89d4f82aa5 Merge branch 'cpufreq-macros' into pm-cpufreq 2014-05-01 00:50:47 +02:00
Stratos Karafotis
041526f915 cpufreq: Use cpufreq_for_each_* macros for frequency table iteration
The cpufreq core now supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.

It should have no functional changes.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-30 00:06:21 +02:00
Stratos Karafotis
27e289dce2 cpufreq: Introduce macros for cpufreq_frequency_table iteration
Many cpufreq drivers need to iterate over the cpufreq_frequency_table
for various tasks.

This patch introduces two macros which can be used for iteration over
cpufreq_frequency_table keeping a common coding style across drivers:

- cpufreq_for_each_entry: iterate over each entry of the table
- cpufreq_for_each_valid_entry: iterate over each entry that contains
a valid frequency.

It should have no functional changes.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-30 00:05:31 +02:00
Tim Gardner
6712d29319 cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost error
bfa709bc82 (cpufreq: powerpc: add cpufreq
transition latency for FSL e500mc SoCs) introduced a modpost error:

ERROR: "__udivdi3" [drivers/cpufreq/ppc-corenet-cpufreq.ko] undefined!
make[1]: *** [__modpost] Error 1

Fix this by avoiding 64 bit integer division.

gcc version 4.8.2

Fixes: bfa709bc82 (cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-29 01:28:17 +02:00
Srivatsa S. Bhat
8997b18511 cpufreq: powernow-k7: Fix double invocation of cpufreq_freq_transition_begin/end
During frequency transitions, the cpufreq core takes the responsibility of
invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
for those cpufreq drivers that define the ->target_index callback but don't
set the ASYNC_NOTIFICATION flag.

The powernow-k7 cpufreq driver falls under this category, but this driver was
invoking the _begin() and _end() APIs itself around frequency transitions,
which led to double invocation of the _begin() API. The _begin API makes
contending callers wait until the previous invocation is complete. Hence,
the powernow-k7 driver ended up waiting on itself, leading to system hangs
during boot.

Fix this by removing the calls to the _begin() and _end() APIs from the
powernow-k7 driver, since they rightly belong to the cpufreq core.

Fixes: 12478cf0c5 (cpufreq: Make sure frequency transitions are serialized)
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-29 01:22:54 +02:00
Srivatsa S. Bhat
3221e55b72 cpufreq: powernow-k6: Fix double invocation of cpufreq_freq_transition_begin/end
During frequency transitions, the cpufreq core takes the responsibility of
invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
for those cpufreq drivers that define the ->target_index callback but don't
set the ASYNC_NOTIFICATION flag.

The powernow-k6 cpufreq driver falls under this category, but this driver was
invoking the _begin() and _end() APIs itself around frequency transitions,
which led to double invocation of the _begin() API. The _begin API makes
contending callers wait until the previous invocation is complete. Hence,
the powernow-k6 driver ended up waiting on itself, leading to system hangs
during boot.

Fix this by removing the calls to the _begin() and _end() APIs from the
powernow-k6 driver, since they rightly belong to the cpufreq core.

(Note that during ->exit(), the powernow-k6 driver sets the frequency
 without any help from the cpufreq core. So add explicit calls to the
 _begin() and _end() APIs around that frequency transition alone, to take
 care of that special case. Also, add a missing 'break' statement there.)

Fixes: 12478cf0c5 (cpufreq: Make sure frequency transitions are serialized)
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-29 01:22:53 +02:00
Srivatsa S. Bhat
237ede16ba cpufreq: powernow-k6: Fix incorrect comparison with max_multipler
The value of 'max_multiplier' is meant to be used for comparison with
clock_ratio[index].driver_data, not the index itself! Fix the code in
powernow_k6_cpu_exit() that has this bug.

Also, while at it, make the for-loop condition look for CPUFREQ_TABLE_END,
instead of hard-coding the loop count to 8.

Reported-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-29 01:22:53 +02:00
Srivatsa S. Bhat
7aa0557fae cpufreq: longhaul: Fix double invocation of cpufreq_freq_transition_begin/end
During frequency transitions, the cpufreq core takes the responsibility of
invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
for those cpufreq drivers that define the ->target_index callback but don't
set the ASYNC_NOTIFICATION flag.

The longhaul cpufreq driver falls under this category, but this driver was
invoking the _begin() and _end() APIs itself around frequency transitions,
which led to double invocation of the _begin() API. The _begin API makes
contending callers wait until the previous invocation is complete. Hence,
the longhaul driver ended up waiting on itself, leading to system hangs
during boot.

Fix this by removing the calls to the _begin() and _end() APIs from the
longhaul driver, since they rightly belong to the cpufreq core.

(Note that during module_exit(), the longhaul driver sets the frequency
 without any help from the cpufreq core. So add explicit calls to the
 _begin() and _end() APIs around that frequency transition alone, to take
 care of that special case.)

Fixes: 12478cf0c5 (cpufreq: Make sure frequency transitions are serialized)
Reported-and-tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-29 01:22:52 +02:00
Kefeng Wang
d76ae2eabc cpufreq: highbank: fix ARM_HIGHBANK_CPUFREQ dependency warning
When make ARCH=arm multi_v7_defconfig, we get the following warnings:

warning: (ARM_HIGHBANK_CPUFREQ) selects GENERIC_CPUFREQ_CPU0 which has
unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && HAVE_CLK
&& REGULATOR && OF && THERMAL && CPU_THERMAL)

To fix this, make ARM_HIGHBANK_CPUFREQ depend on ARCH_HAS_CPUFREQ and
REGULATOR instead of selecting them, PM_OPP will be selected by ARCH_HAS_CPUFREQ.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-22 00:09:09 +02:00
Geert Uytterhoeven
1612343a26 cpufreq: ppc: Fix integer overflow in expression
On 32-bit, "12 * NSEC_PER_SEC" doesn't fit in "unsigned long"
(NSEC_PER_SEC is a "long" constant), causing an integer overflow:

drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
drivers/cpufreq/ppc-corenet-cpufreq.c:211:9: warning: integer overflow in expression [-Woverflow]

Force the intermediate to be 64-bit by adding an "ULL" suffix to the
constant multiplier to fix this.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-21 23:47:06 +02:00
Srivatsa S. Bhat
f3cae355a9 cpufreq, powernv: Fix build failure on UP
Paul Gortmaker reported the following build failure of the powernv cpufreq
driver on UP configs:

drivers/cpufreq/powernv-cpufreq.c:241:2: error: implicit declaration of
function 'cpu_sibling_mask' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/cpufreq/powernv-cpufreq.o] Error 1
make[2]: *** [drivers/cpufreq] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2

The trouble here is that cpu_sibling_mask is defined only in <asm/smp.h>,
and <linux/smp.h> includes <asm/smp.h> only in SMP builds.

So fix this build failure by explicitly including <asm/smp.h> in the driver,
so that we get the definition of cpu_sibling_mask even in UP configurations.

Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-21 23:43:38 +02:00
Duan Jiong
8ab4e2b30a cpufreq: unicore32: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO
This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.

Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-21 23:42:27 +02:00
Rafael J. Wysocki
fe10739284 Merge branch 'pm-cpufreq'
* pm-cpufreq:
  cpufreq: ppc: Remove duplicate inclusion of fsl_soc.h
  cpufreq: create another field .flags in cpufreq_frequency_table
  cpufreq: use kzalloc() to allocate memory for cpufreq_frequency_table
  cpufreq: don't print value of .driver_data from core
  cpufreq: ia64: don't set .driver_data to index
  cpufreq: powernv: Select CPUFreq related Kconfig options for powernv
  cpufreq: powernv: Use cpufreq_frequency_table.driver_data to store pstate ids
  cpufreq: powernv: cpufreq driver for powernv platform
  cpufreq: at32ap: don't declare local variable as static
  cpufreq: loongson2_cpufreq: don't declare local variable as static
  cpufreq: unicore32: fix typo issue for 'clk'
  cpufreq: exynos: Disable on multiplatform build
2014-04-08 13:28:02 +02:00
Sachin Kamat
f334a1e843 cpufreq: ppc: Remove duplicate inclusion of fsl_soc.h
fsl_soc.h was included twice.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-08 12:34:05 +02:00
Linus Torvalds
467a9e1633 CPU hotplug notifiers registration fixes for 3.15-rc1
The purpose of this single series of commits from Srivatsa S Bhat (with
 a small piece from Gautham R Shenoy) touching multiple subsystems that use
 CPU hotplug notifiers is to provide a way to register them that will not
 lead to deadlocks with CPU online/offline operations as described in the
 changelog of commit 93ae4f978c (CPU hotplug: Provide lockless versions
 of callback registration functions).
 
 The first three commits in the series introduce the API and document it
 and the rest simply goes through the users of CPU hotplug notifiers and
 converts them to using the new method.
 
 /
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQIcBAABCAAGBQJTQow2AAoJEILEb/54YlRxW4QQAJlYRDUzwFJzJzYhltQYuVR+
 4D74XMtvXgoJfg3cwdSWvMKKpJZnA9BVN0f7Hcx9wYmgdexYUuHeZJmMNyc3S2+g
 KjKBIsugvgmZhHbbLd6TJ6GBbhGT5JLt9VmSfL9zIkveInU1YHFUUqL/mxdHm4J0
 BSGKjk2rN3waRJgmY+xfliFLtQjDKFwJpMuvrgtoUyfas3f4sIV43UNbqdvA/weJ
 rzedxXOlKH/id4b56lj/4iIzcoL3mwvJJ7r6n0CEMsKv87z09kqR0O+69Tsq/cgs
 j17CsvoJOmZGk3QTeKVMQWBsvk6aPoDu3zK83gLbQMt+qjOpSTbJLz/3HZw4/TrW
 ss4nuZne1DLMGS+6hoxYbTP+6Ni//Kn+l/LrHc5jb7m1X3lMO4W2aV3IROtIE1rv
 lEP1IG01NU4u9YwkVj1dyhrkSp8tLPul4SrUK8W+oNweOC5crjJV7vJbIPJgmYiM
 IZN55wln0yVRtR4TX+rmvN0PixsInE8MeaVCmReApyF9pdzul/StxlBze5BKLSJD
 cqo1kNPpsmdxoDucqUpQ/gSvy+IOl2qnlisB5PpV93sk7De6TFDYrGHxjYIW7jMf
 StXwdCDDQhzd2Q8Kfpp895A1dbIl8rKtwA6bTU2eX+BfMVFzuMdT44cvosx1+UdQ
 sWl//rg76nb13dFjvF+q
 =SW7Q
 -----END PGP SIGNATURE-----

Merge tag 'cpu-hotplug-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull CPU hotplug notifiers registration fixes from Rafael Wysocki:
 "The purpose of this single series of commits from Srivatsa S Bhat
  (with a small piece from Gautham R Shenoy) touching multiple
  subsystems that use CPU hotplug notifiers is to provide a way to
  register them that will not lead to deadlocks with CPU online/offline
  operations as described in the changelog of commit 93ae4f978c ("CPU
  hotplug: Provide lockless versions of callback registration
  functions").

  The first three commits in the series introduce the API and document
  it and the rest simply goes through the users of CPU hotplug notifiers
  and converts them to using the new method"

* tag 'cpu-hotplug-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (52 commits)
  net/iucv/iucv.c: Fix CPU hotplug callback registration
  net/core/flow.c: Fix CPU hotplug callback registration
  mm, zswap: Fix CPU hotplug callback registration
  mm, vmstat: Fix CPU hotplug callback registration
  profile: Fix CPU hotplug callback registration
  trace, ring-buffer: Fix CPU hotplug callback registration
  xen, balloon: Fix CPU hotplug callback registration
  hwmon, via-cputemp: Fix CPU hotplug callback registration
  hwmon, coretemp: Fix CPU hotplug callback registration
  thermal, x86-pkg-temp: Fix CPU hotplug callback registration
  octeon, watchdog: Fix CPU hotplug callback registration
  oprofile, nmi-timer: Fix CPU hotplug callback registration
  intel-idle: Fix CPU hotplug callback registration
  clocksource, dummy-timer: Fix CPU hotplug callback registration
  drivers/base/topology.c: Fix CPU hotplug callback registration
  acpi-cpufreq: Fix CPU hotplug callback registration
  zsmalloc: Fix CPU hotplug callback registration
  scsi, fcoe: Fix CPU hotplug callback registration
  scsi, bnx2fc: Fix CPU hotplug callback registration
  scsi, bnx2i: Fix CPU hotplug callback registration
  ...
2014-04-07 14:55:46 -07:00
Viresh Kumar
7f4b04614a cpufreq: create another field .flags in cpufreq_frequency_table
Currently cpufreq frequency table has two fields: frequency and driver_data.
driver_data is only for drivers' internal use and cpufreq core shouldn't use
it at all. But with the introduction of BOOST frequencies, this assumption
was broken and we started using it as a flag instead.

There are two problems due to this:
- It is against the description of this field, as driver's data is used by
  the core now.
- if drivers fill it with -3 for any frequency, then those frequencies are
  never considered by cpufreq core as it is exactly same as value of
  CPUFREQ_BOOST_FREQ, i.e. ~2.

The best way to get this fixed is by creating another field flags which
will be used for such flags. This patch does that. Along with that various
drivers need modifications due to the change of struct cpufreq_frequency_table.

Reviewed-by: Gautham R Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-07 14:43:50 +02:00