linux.git/drivers/cpufreq/cpufreq.c, branch v3.13

cpufreq: preserve user_policy across suspend/resume

2013-12-29T14:31:21+00:00

Prevent __cpufreq_add_dev() from overwriting the existing values of
user_policy.{min|max|policy|governor} with defaults during resume
from system suspend.

Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Reported-by: Bjørn Mork 
Signed-off-by: Viresh Kumar 
Cc: 3.12+  # 3.12+
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki

cpufreq: Clean up after a failing light-weight initialization

2013-12-29T14:30:36+00:00

If cpufreq_policy_restore() returns NULL during system resume,
__cpufreq_add_dev() should just fall back to the full initialization
instead of returning an error, because that may actually make things
work.  Moreover, it should not leave stale fallback data behind after
it has failed to restore a previously existing policy.

This change is based on Viresh Kumar's work.

Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Reported-by: Bjørn Mork 
Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar 
Cc: 3.12+  # 3.12+

cpufreq: Use CONFIG_CPU_FREQ_DEFAULT_* to set initial policy for setpolicy drivers

2013-12-21T23:51:52+00:00

When configuring a default governor (via CONFIG_CPU_FREQ_DEFAULT_*) with the
intel_pstate driver, the desired default policy is not properly set. For
example, setting 'CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE' ends up with the
'powersave' policy being set.

Fix by configuring the correct default policy, if either 'powersave' or
'performance' are requested. Otherwise, fallback to what the driver originally
set via its 'init' routine.

Signed-off-by: Jason Baron 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: remove sysfs files for CPUs which failed to come back after resume

2013-12-21T23:47:46+00:00

There are cases where cpufreq_add_dev() may fail for some CPUs
during system resume. With the current code we will still have
sysfs cpufreq files for those CPUs and struct cpufreq_policy
would be already freed for them. Hence any operation on those
sysfs files would result in kernel warnings.

Example of problems resulting from resume errors (from Bjørn Mork):

WARNING: CPU: 0 PID: 6055 at fs/sysfs/file.c:343 sysfs_open_file+0x77/0x212()
missing sysfs attribute operations for kobject: (null)
Modules linked in: [stripped as irrelevant]
CPU: 0 PID: 6055 Comm: grep Tainted: G      D      3.13.0-rc2 #153
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
 0000000000000009 ffff8802327ebb78 ffffffff81380b0e 0000000000000006
 ffff8802327ebbc8 ffff8802327ebbb8 ffffffff81038635 0000000000000000
 ffffffff811823c7 ffff88021a19e688 ffff88021a19e688 ffff8802302f9310
Call Trace:
 [] dump_stack+0x55/0x76
 [] warn_slowpath_common+0x7c/0x96
 [] ? sysfs_open_file+0x77/0x212
 [] warn_slowpath_fmt+0x41/0x43
 [] ? sysfs_get_active+0x6b/0x82
 [] ? sysfs_open_file+0x32/0x212
 [] sysfs_open_file+0x77/0x212
 [] ? sysfs_schedule_callback+0x1ac/0x1ac
 [] do_dentry_open+0x17c/0x257
 [] finish_open+0x41/0x4f
 [] do_last+0x80c/0x9ba
 [] ? inode_permission+0x40/0x42
 [] path_openat+0x233/0x4a1
 [] do_filp_open+0x35/0x85
 [] ? __alloc_fd+0x172/0x184
 [] do_sys_open+0x6b/0xfa
 [] SyS_openat+0xf/0x11
 [] system_call_fastpath+0x16/0x1b

To fix this, remove those sysfs files or put the associated kobject
in case of such errors. Also, to make it simple, remove the cpufreq
sysfs links from all the CPUs (except for the policy->cpu) during
suspend, as that operation won't result in a loss of sysfs file
permissions and we can create those links during resume just fine.

Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Reported-and-tested-by: Bjørn Mork 
Signed-off-by: Viresh Kumar 
Cc: 3.12+  # 3.12+
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki

Revert "cpufreq: fix garbage kobjects on errors during suspend/resume"

2013-12-08T00:32:41+00:00

Commit 2167e2399dc5 (cpufreq: fix garbage kobjects on errors during
suspend/resume) breaks suspend/resume on Martin Ziegler's system
(hard lockup during resume), so revert it.

Fixes: 2167e2399dc5 (cpufreq: fix garbage kobjects on errors during suspend/resume)
References: https://bugzilla.kernel.org/show_bug.cgi?id=66751
Reported-by: Martin Ziegler 
Cc: 3.12+  # 3.12+
Signed-off-by: Rafael J. Wysocki

Revert "cpufreq: suspend governors on system suspend/hibernate"

2013-12-08T00:04:17+00:00

Commit 5a87182aa21d (cpufreq: suspend governors on system
suspend/hibernate) causes hibernation problems to happen on
Bjørn Mork's and Paul Bolle's systems, so revert it.

Fixes: 5a87182aa21d (cpufreq: suspend governors on system suspend/hibernate)
Reported-by: Bjørn Mork 
Reported-by: Paul Bolle 
Signed-off-by: Rafael J. Wysocki

cpufreq: fix garbage kobjects on errors during suspend/resume

2013-12-03T14:25:52+00:00

This is effectively a revert of commit 5302c3fb2e62 ("cpufreq: Perform
light-weight init/teardown during suspend/resume"), which enabled
suspend/resume optimizations leaving the sysfs files in place.

Errors during suspend/resume are not handled properly, leaving
dead sysfs attributes in case of failures.  There are are number of
functions with special code for the "frozen" case, and all these
need to also have special error handling.

The problem is easy to demonstrate by making cpufreq_driver->init()
or cpufreq_driver->get() fail during resume.

The code is too complex for a simple fix, with split code paths
in multiple blocks within a number of functions.  It is therefore
best to revert the patch enabling this code until the error handling
is in place.

Examples of problems resulting from resume errors:

WARNING: CPU: 0 PID: 6055 at fs/sysfs/file.c:343 sysfs_open_file+0x77/0x212()
missing sysfs attribute operations for kobject: (null)
Modules linked in: [stripped as irrelevant]
CPU: 0 PID: 6055 Comm: grep Tainted: G      D      3.13.0-rc2 #153
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
 0000000000000009 ffff8802327ebb78 ffffffff81380b0e 0000000000000006
 ffff8802327ebbc8 ffff8802327ebbb8 ffffffff81038635 0000000000000000
 ffffffff811823c7 ffff88021a19e688 ffff88021a19e688 ffff8802302f9310
Call Trace:
 [] dump_stack+0x55/0x76
 [] warn_slowpath_common+0x7c/0x96
 [] ? sysfs_open_file+0x77/0x212
 [] warn_slowpath_fmt+0x41/0x43
 [] ? sysfs_get_active+0x6b/0x82
 [] ? sysfs_open_file+0x32/0x212
 [] sysfs_open_file+0x77/0x212
 [] ? sysfs_schedule_callback+0x1ac/0x1ac
 [] do_dentry_open+0x17c/0x257
 [] finish_open+0x41/0x4f
 [] do_last+0x80c/0x9ba
 [] ? inode_permission+0x40/0x42
 [] path_openat+0x233/0x4a1
 [] do_filp_open+0x35/0x85
 [] ? __alloc_fd+0x172/0x184
 [] do_sys_open+0x6b/0xfa
 [] SyS_openat+0xf/0x11
 [] system_call_fastpath+0x16/0x1b

The failure to restore cpufreq devices on cancelled hibernation is
not a new bug. It is caused by the ACPI _PPC call failing unless the
hibernate is completed. This makes the acpi_cpufreq driver fail its
init.

Previously, the cpufreq device could be restored by offlining the
cpu temporarily.  And as a complete hibernation cycle would do this,
it would be automatically restored most of the time.  But after
commit 5302c3fb2e62 the leftover sysfs attributes will block any
device add action.  Therefore offlining and onlining CPU 1 will no
longer restore the cpufreq object, and a complete suspend/resume
cycle will replace it with garbage.

Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Cc: 3.12+  # 3.12+
Signed-off-by: Bjørn Mork 
Signed-off-by: Rafael J. Wysocki

cpufreq: suspend governors on system suspend/hibernate

2013-11-28T13:47:31+00:00

This patch adds cpufreq suspend/resume calls to dpm_{suspend|resume}_noirq()
for handling suspend/resume of cpufreq governors.

Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found anr issue where
tunables configuration for clusters/sockets with non-boot CPUs was
getting lost after suspend/resume, as we were notifying governors
with CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that
policy and so deallocating memory for tunables. This is fixed by
this patch as we don't allow any operation on governors after
device suspend and before device resume now.

Reported-and-tested-by: Lan Tianyu 
Reported-by: Jinhyuk Choi 
Signed-off-by: Viresh Kumar 
[rjw: Changelog, minor cleanups]
Signed-off-by: Rafael J. Wysocki

cpufreq: move freq change notifications to cpufreq core

2013-10-30T23:11:08+00:00

Most of the drivers do following in their ->target_index() routines:

	struct cpufreq_freqs freqs;
	freqs.old = old freq...
	freqs.new = new freq...

	cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);

	/* Change rate here */

	cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);

This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.

There are few special cases though, like exynos5440, which doesn't do everything
on the call to ->target_index() routine and call some kind of bottom halves for
doing this work, work/tasklet/etc..

They may continue doing notification from their own code as flag:
CPUFREQ_ASYNC_NOTIFICATION is already set for them.

All drivers are also modified in this patch to avoid breaking 'git bisect', as
double notification would happen otherwise.

Acked-by: Hans-Christian Egtvedt 
Acked-by: Jesper Nilsson 
Acked-by: Linus Walleij 
Acked-by: Russell King 
Acked-by: Stephen Warren 
Tested-by: Andrew Lunn 
Tested-by: Nicolas Pitre 
Reviewed-by: Lan Tianyu 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: create per policy rwsem instead of per CPU cpu_policy_rwsem

2013-10-25T21:54:12+00:00

We have per-CPU cpu_policy_rwsem for cpufreq core, but we never use
all of them. We always use rwsem of policy->cpu and so we can
actually make this rwsem per policy instead.

This patch does this change. With this change other tricky situations
are also avoided now, like which lock to take while we are changing
policy->cpu, etc.

Suggested-by: Srivatsa S. Bhat 
Signed-off-by: Viresh Kumar 
Reviewed-by: Srivatsa S. Bhat 
Tested-by: Andrew Lunn 
Signed-off-by: Rafael J. Wysocki