Skip to content
  1. Sep 16, 2009
  3. Sep 02, 2009
    • Prarit Bhargava's avatar
      [CPUFREQ] Create a blacklist for processors that should not load the acpi-cpufreq module. · 1a8e42fa
      Prarit Bhargava authored 
      

Create a blacklist for processors that should not load the acpi-cpufreq module.

The initial entry in the blacklist function is the Intel 0f68 processor.  It's
specification update mentions errata AL30 which implies that cpufreq should not
run on this processor.

Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
      1a8e42fa
    • Mark Langsdorf's avatar
      [CPUFREQ] Powernow-k8: Enable more than 2 low P-states · db39d552
      Mark Langsdorf authored 
      

Remove an obsolete check that used to prevent there being more
than 2 low P-states.  Now that low-to-low P-states changes are
enabled, it prevents otherwise workable configurations with
multiple low P-states.

Signed-off-by: default avatarMark Langsdorf <mark.langsdorf@amd.com>
Tested-by: default avatarKrists Krilovs <pow@pow.za.net>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
      db39d552
    • Mathieu Desnoyers's avatar
      [CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site) · 395913d0
      Mathieu Desnoyers authored 
      

remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)

commit	42a06f21

Missed a call site for CPUFREQ_GOV_STOP to remove the rwlock taken around the
teardown. To make a long story short, the rwlock write-lock causes a circular
dependency with cancel_delayed_work_sync(), because the timer handler takes the
read lock.

Note that all callers to __cpufreq_set_policy are taking the rwsem. All sysfs
callers (writers) hold the write rwsem at the earliest sysfs calling stage.

However, the rwlock write-lock is not needed upon governor stop.

Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
CC: rjw@sisk.pl
CC: mingo@elte.hu
CC: Shaohua Li <shaohua.li@intel.com>
CC: Pekka Enberg <penberg@cs.helsinki.fi>
CC: Dave Young <hidave.darkstar@gmail.com>
CC: "Rafael J. Wysocki" <rjw@sisk.pl>
CC: Rusty Russell <rusty@rustcorp.com.au>
CC: trenn@suse.de
CC: sven.wegener@stealer.net
CC: cpufreq@vger.kernel.org
Signed-off-by: default avatarDave Jones <davej@redhat.com>
      395913d0
    • Thomas Renninger's avatar
      [CPUFREQ] ondemand - Use global sysfs dir for tuning settings · 0e625ac1
      Thomas Renninger authored 
      

Ondemand has only global variables for userspace tunings via sysfs.
But they were exposed per CPU which wrongly implies to the user that
his settings are applied per cpu. Also locking sysfs against concurrent
access won't be necessary anymore after deprecation time.

This means the ondemand config dir is moved:
/sys/devices/system/cpu/cpu*/cpufreq/ondemand ->
     /sys/devices/system/cpu/cpufreq/ondemand

The old files will still exist, but reading or writing to them will
result in one (printk_once) deprecation msg to syslog per file.

Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
      0e625ac1
    • Thomas Renninger's avatar
      [CPUFREQ] Introduce global, not per core: /sys/devices/system/cpu/cpufreq · 8aa84ad8
      Thomas Renninger authored 
      

Currently everything in the cpufreq layer is per core based.
This does not reflect reality, for example ondemand on conservative
governors have global sysfs variables.

Introduce a global cpufreq directory and add the kobject to the governor
struct, so that governors can easily access it.
The directory is initialized in the cpufreq_core_init initcall and thus will
always be created if cpufreq is compiled in, even if no cpufreq driver is
active later.

Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
      8aa84ad8
    • Thomas Renninger's avatar
      [CPUFREQ] Bail out of cpufreq_add_dev if the link for a managed CPU got created · 4bfa042c
      Thomas Renninger authored 
      

Doing:
echo 0 >cpu1/online
echo 1 >cpu1/online

on a managed CPU will result in:
Jul 22 15:15:37 linux kernel: [   80.013864] WARNING: at fs/sysfs/dir.c:487 sysfs_add_one+0xcf/0xe6()
Jul 22 15:15:37 linux kernel: [   80.013866] Hardware name: To Be Filled By O.E.M.
Jul 22 15:15:37 linux kernel: [   80.013868] sysfs: cannot create duplicate filename '/devices/system/cpu/cpu1/cpufreq'
Jul 22 15:15:37 linux kernel: [   80.013870] Modules linked in: powernow_k8
Jul 22 15:15:37 linux kernel: [   80.013874] Pid: 5750, comm: bash Not tainted 2.6.31-rc2 #40
Jul 22 15:15:37 linux kernel: [   80.013876] Call Trace:
Jul 22 15:15:37 linux kernel: [   80.013879]  [<ffffffff8112ebda>] ? sysfs_add_one+0xcf/0xe6
Jul 22 15:15:37 linux kernel: [   80.013884]  [<ffffffff81041926>] warn_slowpath_common+0x77/0xa4
Jul 22 15:15:37 linux kernel: [   80.013888]  [<ffffffff810419a0>] warn_slowpath_fmt+0x3c/0x3e
Jul 22 15:15:37 linux kernel: [   80.013891]  [<ffffffff8112ebda>] sysfs_add_one+0xcf/0xe6
Jul 22 15:15:37 linux kernel: [   80.013894]  [<ffffffff8112f213>] create_dir+0x58/0x87
Jul 22 15:15:37 linux kernel: [   80.013898]  [<ffffffff8112f27a>] sysfs_create_dir+0x38/0x4f
Jul 22 15:15:37 linux kernel: [   80.013902]  [<ffffffff811ffb8a>] kobject_add_internal+0x11f/0x1de
Jul 22 15:15:37 linux kernel: [   80.013905]  [<ffffffff811ffd21>] kobject_add_varg+0x41/0x4e
Jul 22 15:15:37 linux kernel: [   80.013908]  [<ffffffff811ffd7a>] kobject_init_and_add+0x4c/0x57
Jul 22 15:15:37 linux kernel: [   80.013913]  [<ffffffff810667bc>] ? mark_lock+0x22/0x228
Jul 22 15:15:37 linux kernel: [   80.013918]  [<ffffffff813e8a3b>] cpufreq_add_dev_interface+0x40/0x1e4
...

This bug slipped in by git commit:
150b06f7f223cfd0f808737a5243cceca8ea47fa

When splitting up cpufreq_add_dev, the whole cpufreq_add_dev function
is not left anymore, only cpufreq_add_dev_policy.
This patch should reconstruct the identical functionality again as it
was before the split.

CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
      4bfa042c
    • Dave Jones's avatar
      [CPUFREQ] Factor out policy setting from cpufreq_add_dev · ecf7e461
      Dave Jones authored 
      

Signed-off-by: default avatarDave Jones <davej@redhat.com>
      ecf7e461
    • Dave Jones's avatar
      [CPUFREQ] Factor out interface creation from cpufreq_add_dev · 909a694e
      Dave Jones authored 
      

Signed-off-by: default avatarDave Jones <davej@redhat.com>
      909a694e
    • Dave Jones's avatar
      [CPUFREQ] Factor out symlink creation from cpufreq_add_dev · 19d6f7ec
      Dave Jones authored 
      

Signed-off-by: default avatarDave Jones <davej@redhat.com>
      19d6f7ec
    • Dave Jones's avatar
      [CPUFREQ] cleanup up -ENOMEM handling in cpufreq_add_dev · 059019a3
      Dave Jones authored 
      

Signed-off-by: default avatarDave Jones <davej@redhat.com>
      059019a3
    • Dave Jones's avatar
      [CPUFREQ] Reduce scope of cpu_sys_dev in cpufreq_add_dev · 54e6fe16
      Dave Jones authored 
      

Signed-off-by: default avatarDave Jones <davej@redhat.com>
      54e6fe16
    • Naga Chumbalkar's avatar
      [CPUFREQ] update Doc for cpuinfo_cur_freq and scaling_cur_freq · da470db1
      Naga Chumbalkar authored 
      

I think the way "cpuinfo_cur_info" and "scaling_cur_info" are defined under
./Documentation/cpu-freq/user-guide.txt can be enhanced. Currently, they are
both defined the same way: "Current speed/frequency" of the CPU, in KHz".

Below is a patch that distinguishes one from the other.

Regards,
- naga -

-----------------------------------------
Update description for "cpuinfo_cur_freq" and "scaling_cur_freq".

Some of the wording is drawn from comments found in
./drivers/cpufreq/cpufreq.c: cpufreq_out_of_sync():

 *      @old_freq: CPU frequency the kernel thinks the CPU runs at
 *      @new_freq: CPU frequency the CPU actually runs at

Signed-off-by: default avatarNaga Chumbalkar <nagananda.chumbalkar@hp.com>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
      da470db1
    • Dominik Brodowski's avatar
      [CPUFREQ] Re-enable cpufreq suspend and resume code · ce6c3997
      Dominik Brodowski authored 
      

Commit 4bc5d341 is broken and causes regressions:

(1) cpufreq_driver->resume() and ->suspend() were only called on
__powerpc__, but you could set them on all architectures. In fact,
->resume() was defined and used before the PPC-related commit
42d4dc3f complained about in 4bc5d341.

(2) Therfore, the resume functions in acpi_cpufreq and speedstep-smi
would never be called.

(3) This means speedstep-smi would be unusuable after suspend or resume.

The _real_ problem was calling cpufreq_driver->get() with interrupts
off, but it re-enabling interrupts on some platforms. Why is ->get()
necessary?

Some systems like to change the CPU frequency behind our
back, especially during BIOS-intensive operations like suspend or
resume. If such systems also use a CPU frequency-dependant timing loop,
delays might be off by large factors. Therefore, we need to ascertain
as soon as possible that the CPU frequency is indeed at the speed we
think it is. You can do this two ways: either setting it anew, or trying
to get it. The latter is what was done, the former also has the same IRQ
issue.

So, let's try something different: defer the checking to after interrupts
are re-enabled, by calling cpufreq_update_policy() (via schedule_work()).
Timings may be off until this later stage, so let's watch out for
resume regressions caused by the deferred handling of frequency changes
behind the kernel's back.

Signed-off-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: default avatarDave Jones <davej@redhat.com>
      ce6c3997
  5. Sep 01, 2009
  7. Aug 31, 2009
  9. Aug 30, 2009
  11. Aug 29, 2009