Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 20 4月, 2006 25 次提交
  3. 19 4月, 2006 3 次提交
    • A
      [CPUFREQ] drivers/cpufreq/cpufreq.c: static functions mustn't be exported · 7b14dedd
      由 Adrian Bunk 提交于 
      This patch removes the EXPORT_SYMBOL_GPL of the static function cpufreq_parse_governor().
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDave Jones <davej@redhat.com>
      7b14dedd
    • T
      [CPUFREQ] If max_freq got reduced (e.g. by _PPC) a write to sysfs... · 7970e08b
      由 Thomas Renninger 提交于 
      [CPUFREQ] If max_freq got reduced (e.g. by _PPC) a write to sysfs scaling_governor let cpufreq core stuck at low max_freq for ever

The previous patch had bugs (locking and refcount).

This one could also be related to the latest DELL reports.
But they only slip into this if a user prog (e.g. powersave daemon does when
AC got (un) plugged due to a scheme change) echos something to
/sys/../cpufreq/scaling_governor
while the frequencies got limited by BIOS.

This one works:

Subject: Max freq stucks at low freq if reduced by _PPC and sysfs gov access

The problem is reproducable by(if machine is limiting freqs via BIOS):
 - Unplugging AC -> max freq gets limited
 - echo ${governor} >/sys/.../cpufreq/scaling_governor (policy->user_data.max
   gets overridden with policy->max and will never come up again.)

This patch exchanged the cpufreq_set_policy call to __cpufreq_set_policy and
duplicated it's functionality but did not override user_data.max.
The same happens with overridding min/max values. If freqs are limited and
you override the min freq value, the max freq global value will also get
stuck to the limited freq, even if BIOS allows all freqs again.
Last scenario does only happen if BIOS does not reduce the frequency
to the lowest value (should never happen, just for correctness...)

 drivers/cpufreq/cpufreq.c |   17 +++++++++++++++--
 1 files changed, 15 insertions(+), 2 deletions(-)
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: N"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>
      7970e08b
    • R
      [ARM] 3478/1: SharpSL SCOOP: Fix potenial build failure · 7ea3bbbc
      由 Richard Purdie 提交于 
      Patch from Richard Purdie

Move platform_scoop_config from the SharpSL scoop PCMCIA driver to
the SCOOP driver. This avoids build failures when PCMCIA is not built
or is modular (scoop.c itself cannot be modular).
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7ea3bbbc
  5. 18 4月, 2006 4 次提交
  7. 15 4月, 2006 8 次提交