Skip to content

L
linux
Switch branch/tag
  1. 12 Mar, 2014 1 commit
  3. 11 Mar, 2014 1 commit
  5. 06 Mar, 2014 10 commits
    • Viresh Kumar's avatar
      cpufreq: Tegra: Use cpufreq_generic_suspend() · d351cb31
      Viresh Kumar authored 
      The cpufreq core now supports suspending and resuming of cpufreq
drivers and governors during systems suspend and resume, so use
the common infrastructure instead of defining special PM notifiers
for the same thing.
Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
Tested-by: default avatarStephen Warren <swarren@nvidia.com>
[rjw: Changelog]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d351cb31
    • Viresh Kumar's avatar
      cpufreq: s5pv210: Use cpufreq_generic_suspend() · 59625ba3
      Viresh Kumar authored 
      The cpufreq core now supports suspending and resuming of cpufreq
drivers and governors during systems suspend and resume, so use
the common infrastructure instead of defining special PM notifiers
for the same thing.
Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      59625ba3
    • Viresh Kumar's avatar
      cpufreq: exynos: Use cpufreq_generic_suspend() · d248bb89
      Viresh Kumar authored 
      The cpufreq core now supports suspending and resuming of cpufreq
drivers and governors during systems suspend and resume, so use
the common infrastructure instead of defining special PM notifiers
for the same thing.
Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d248bb89
    • Viresh Kumar's avatar
      cpufreq: Implement cpufreq_generic_suspend() · e28867ea
      Viresh Kumar authored 
      Multiple platforms need to set CPUs to a particular frequency before
suspending the system, so provide a common infrastructure for them.

Those platforms only need to point their ->suspend callback pointers
to the generic routine.
Tested-by: default avatarStephen Warren <swarren@nvidia.com>
Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e28867ea
    • Viresh Kumar's avatar
      cpufreq: suspend governors on system suspend/hibernate · 2f0aea93
      Viresh Kumar authored 
      This patch adds cpufreq suspend/resume calls to dpm_{suspend|resume}()
for handling suspend/resume of cpufreq governors.

Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found an issue where the
tunables configuration for clusters/sockets with non-boot CPUs was
lost after system suspend/resume, as we were notifying governors with
CPUFREQ_GOV_POLICY_EXIT on removal of the last CPU for that policy
which caused the tunables memory to be freed.

This is fixed by preventing any governor operations from being
carried out between the device suspend and device resume stages of
system suspend and resume, respectively.

We could have added these callbacks at dpm_{suspend|resume}_noirq()
level, but there is an additional problem that the majority of I/O
devices is already suspended at that point and if cpufreq drivers
want to change the frequency before suspending, then that not be
possible on some platforms (which depend on peripherals like i2c,
regulators, etc).
Reported-and-tested-by: default avatarLan Tianyu <tianyu.lan@intel.com>
Reported-by: default avatarJinhyuk Choi <jinchoi@broadcom.com>
Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2f0aea93
    • viresh kumar's avatar
      cpufreq: move call to __find_governor() to cpufreq_init_policy() · 6e2c89d1
      viresh kumar authored 
      We call __find_governor() during the addition of the first CPU of
each policy from __cpufreq_add_dev() to find the last governor used
for this CPU before it was hot-removed.

After that we call cpufreq_parse_governor() in cpufreq_init_policy(),
either with this governor, or with the default governor. Right after
that policy->governor is set to NULL.

While that code is not functionally problematic, the structure of it
is suboptimal, because some of the code required in cpufreq_init_policy()
is being executed by its caller, __cpufreq_add_dev(). So, it would make
more sense to get all of it together in a single place to make code more
readable.

Accordingly, move the code needed for policy initialization to
cpufreq_init_policy() and initialize policy->governor to NULL at the
beginning.

In order to clean up the code a bit more, some of the #ifdefs for
CONFIG_HOTPLUG_CPU are dropped too.
Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6e2c89d1
    • Rafael J. Wysocki's avatar
      Merge back earlier 'pm-cpufreq' material. · 3b4aff04
      Rafael J. Wysocki authored
      3b4aff04
    • Viresh Kumar's avatar
      cpufreq: Initialize governor for a new policy under policy->rwsem · 4e97b631
      Viresh Kumar authored 
      policy->rwsem is used to lock access to all parts of code modifying
struct cpufreq_policy, but it's not used on a new policy created by
__cpufreq_add_dev().

Because of that, if cpufreq_update_policy() is called in a tight loop
on one CPU in parallel with offline/online of another CPU, then the
following crash can be triggered:

Unable to handle kernel NULL pointer dereference at virtual address 00000020
pgd = c0003000
[00000020] *pgd=80000000004003, *pmd=00000000
Internal error: Oops: 206 [#1] PREEMPT SMP ARM

PC is at __cpufreq_governor+0x10/0x1ac
LR is at cpufreq_update_policy+0x114/0x150

---[ end trace f23a8defea6cd706 ]---
Kernel panic - not syncing: Fatal exception
CPU0: stopping
CPU: 0 PID: 7136 Comm: mpdecision Tainted: G      D W    3.10.0-gd727407-00074-g979ede8 #396

[<c0afe180>] (notifier_call_chain+0x40/0x68) from [<c02a23ac>] (__blocking_notifier_call_chain+0x40/0x58)
[<c02a23ac>] (__blocking_notifier_call_chain+0x40/0x58) from [<c02a23d8>] (blocking_notifier_call_chain+0x14/0x1c)
[<c02a23d8>] (blocking_notifier_call_chain+0x14/0x1c) from [<c0803c68>] (cpufreq_set_policy+0xd4/0x2b8)
[<c0803c68>] (cpufreq_set_policy+0xd4/0x2b8) from [<c0803e7c>] (cpufreq_init_policy+0x30/0x98)
[<c0803e7c>] (cpufreq_init_policy+0x30/0x98) from [<c0805a18>] (__cpufreq_add_dev.isra.17+0x4dc/0x7a4)
[<c0805a18>] (__cpufreq_add_dev.isra.17+0x4dc/0x7a4) from [<c0805d38>] (cpufreq_cpu_callback+0x58/0x84)
[<c0805d38>] (cpufreq_cpu_callback+0x58/0x84) from [<c0afe180>] (notifier_call_chain+0x40/0x68)
[<c0afe180>] (notifier_call_chain+0x40/0x68) from [<c02812dc>] (__cpu_notify+0x28/0x44)
[<c02812dc>] (__cpu_notify+0x28/0x44) from [<c0aeed90>] (_cpu_up+0xf4/0x1dc)
[<c0aeed90>] (_cpu_up+0xf4/0x1dc) from [<c0aeeed4>] (cpu_up+0x5c/0x78)
[<c0aeeed4>] (cpu_up+0x5c/0x78) from [<c0aec808>] (store_online+0x44/0x74)
[<c0aec808>] (store_online+0x44/0x74) from [<c03a40f4>] (sysfs_write_file+0x108/0x14c)
[<c03a40f4>] (sysfs_write_file+0x108/0x14c) from [<c03517d4>] (vfs_write+0xd0/0x180)
[<c03517d4>] (vfs_write+0xd0/0x180) from [<c0351ca8>] (SyS_write+0x38/0x68)
[<c0351ca8>] (SyS_write+0x38/0x68) from [<c0205de0>] (ret_fast_syscall+0x0/0x30)

Fix that by taking locks at appropriate places in __cpufreq_add_dev()
as well.
Reported-by: default avatarSaravana Kannan <skannan@codeaurora.org>
Suggested-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4e97b631
    • Viresh Kumar's avatar
      cpufreq: Initialize policy before making it available for others to use · 5a7e56a5
      Viresh Kumar authored 
      Policy must be fully initialized before it is being made available
for use by others. Otherwise cpufreq_cpu_get() would be able to grab
a half initialized policy structure that might not have affected_cpus
(for example) populated. Then, anybody accessing those fields will get
a wrong value and that will lead to unpredictable results.

In order to fix this, do all the necessary initialization before we
make the policy structure available via cpufreq_cpu_get(). That will
guarantee that any code accessing fields of the policy will get
correct data from them.
Reported-by: default avatarSaravana Kannan <skannan@codeaurora.org>
Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
[rjw: Changelog]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5a7e56a5
    • Aaron Plattner's avatar
      cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditions · 999976e0
      Aaron Plattner authored 
      If a module calls cpufreq_get while cpufreq is initializing, it's
possible for it to be called after cpufreq_driver is set but before
cpufreq_cpu_data is written during subsys_interface_register.  This
happens because cpufreq_get doesn't take the cpufreq_driver_lock
around its use of cpufreq_cpu_data.

Fix this by using cpufreq_cpu_get(cpu) to look up the policy rather
than reading it out of cpufreq_cpu_data directly.  cpufreq_cpu_get()
takes the appropriate locks to prevent this race from happening.

Since it's possible for policy to be NULL if the caller passes in an
invalid CPU number or calls the function before cpufreq is initialized,
delete the BUG_ON(!policy) and simply return 0.  Don't try to return
-ENOENT because that's negative and the function returns an unsigned
integer.

References: https://bbs.archlinux.org/viewtopic.php?id=177934Signed-off-by: default avatarAaron Plattner <aplattner@nvidia.com>
Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      999976e0
  7. 03 Mar, 2014 1 commit
  9. 02 Mar, 2014 15 commits
  11. 01 Mar, 2014 8 commits
  13. 28 Feb, 2014 4 commits
    • Rob Herring's avatar
      cpufreq: enable ARM drivers on arm64 · 52e7e816
      Rob Herring authored 
      Enable cpufreq and power kconfig menus on arm64 along with arm cpufreq
drivers. The power menu is needed for OPP support. At least on Calxeda
systems, the same cpufreq driver is used for arm and arm64 based
systems.
Signed-off-by: default avatarRob Herring <rob.herring@calxeda.com>
Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: default avatarMark Brown <broonie@linaro.org>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      52e7e816
    • Russell King's avatar
      MAINTAINERS: add maintainer entry for Armada DRM driver · 8427defd
      Russell King authored 
      Add a maintainers entry for the Armada DRM driver.
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8427defd
    • Linus Torvalds's avatar
      Merge tag 'dm-3.14-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · ebb7c197
      Linus Torvalds authored 
      Pull device mapper fixes from Mike Snitzer:
 "A few dm-cache fixes, an invalid ioctl handling fix for dm multipath,
  a couple immutable biovec fixups for dm mirror, and a few dm-thin
  fixes.

  There will likely be additional dm-thin metadata and data resize fixes
  to include in 3.14-rc6 next week.

  Note to stable-minded folks: Immutable biovecs were introduced in
  3.14, so the related fixups for dm mirror are not needed in stable@
  kernels"

* tag 'dm-3.14-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm cache: fix truncation bug when mapping I/O to >2TB fast device
  dm thin: allow metadata space larger than supported to go unused
  dm mpath: fix stalls when handling invalid ioctls
  dm thin: fix the error path for the thin device constructor
  dm raid1: fix immutable biovec related BUG when retrying read bio
  dm io: fix I/O to multiple destinations
  dm thin: avoid metadata commit if a pool's thin devices haven't changed
  dm cache: do not add migration to completed list before unhooking bio
  dm cache: move hook_info into common portion of per_bio_data structure
      ebb7c197
    • Linus Torvalds's avatar
      Merge tag 'sound-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 7aa48355
      Linus Torvalds authored 
      Pull sound fixes from Takashi Iwai:
 "It's a bad habit to get a higher volume of fixes often lately, but
  things happen again.

  All commits found here are real bug fixes, and are mostly trivial.
  Most of changes in ASoC are the fixes for enum items due to the wrong
  API usages, in addition to a few DAPM mutex deadlock and other fixes.
  In HD-audio, only fixups for HP laptops.  Although diffstat shows
  much, the changes are simple: there are just so many different device
  entries there"

* tag 'sound-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ASoC: sta32x: Fix wrong enum for limiter2 release rate
  ASoC: da732x: Mark DC offset control registers volatile
  ALSA: hda/realtek - Add more entry for enable HP mute led
  ALSA: hda - Add a fixup for HP Folio 13 mute LED
  ASoC: wm8958-dsp: Fix firmware block loading
  ASoC: sta32x: Fix cache sync
  ALSA: hda/realtek - Add more entry for enable HP mute led
  ASoC: dapm: Add locking to snd_soc_dapm_xxxx_pin functions
  Input - arizona-haptics: Fix double lock of dapm_mutex
  ASoC: wm8400: Fix the wrong number of enum items
  ASoC: isabelle: Fix the wrong number of items in enum ctls
  ASoC: ad1980: Fix wrong number of items for capture source
  ASoC: wm8994: Fix the wrong number of enum items
  ASoC: wm8900: Fix the wrong number of enum items
  ASoC: wm8770: Fix wrong number of enum items
  ASoC: sta32x: Fix array access overflow
  ASoC: dapm: Correct regulator bypass error messages
      7aa48355
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7