kernel/linux.git/include/linux/cpufreq.h, branch v3.12.17

Revert "cpufreq: make sure frequency transitions are serialized"

2013-09-10T00:54:50+00:00

Commit 7c30ed5 (cpufreq: make sure frequency transitions are serialized) attempted to serialize frequency transitions by adding checks to the CPUFREQ_PRECHANGE and CPUFREQ_POSTCHANGE notifications. However, it assumed that the notifications will always originate from the driver's .target() callback, but they also can be triggered by cpufreq_out_of_sync() and that leads to warnings like this on some systems: WARNING: CPU: 0 PID: 14543 at drivers/cpufreq/cpufreq.c:317 __cpufreq_notify_transition+0x238/0x260() In middle of another frequency transition accompanied by a call trace similar to this one: [] dump_stack+0x46/0x58 [] warn_slowpath_common+0x8c/0xc0 [] ? acpi_cpufreq_target+0x320/0x320 [] warn_slowpath_fmt+0x46/0x50 [] __cpufreq_notify_transition+0x238/0x260 [] cpufreq_notify_transition+0x3e/0x70 [] cpufreq_out_of_sync+0x6d/0xb0 [] cpufreq_update_policy+0x10c/0x160 [] ? cpufreq_update_policy+0x160/0x160 [] cpufreq_set_cur_state+0x8c/0xb5 [] processor_set_cur_state+0xa3/0xcf [] thermal_cdev_update+0x9c/0xb0 [] step_wise_throttle+0x5a/0x90 [] handle_thermal_trip+0x4f/0x140 [] thermal_zone_device_update+0x57/0xa0 [] acpi_thermal_check+0x2e/0x30 [] acpi_thermal_notify+0x40/0xdc [] acpi_device_notify+0x19/0x1b [] acpi_ev_notify_dispatch+0x41/0x5c [] acpi_os_execute_deferred+0x25/0x32 [] process_one_work+0x170/0x4a0 [] worker_thread+0x121/0x390 [] ? manage_workers.isra.20+0x170/0x170 [] kthread+0xc0/0xd0 [] ? flush_kthread_worker+0xb0/0xb0 [] ret_from_fork+0x7c/0xb0 [] ? flush_kthread_worker+0xb0/0xb0 For this reason, revert commit 7c30ed5 along with the fix 266c13d (cpufreq: Fix serialization of frequency transitions) on top of it and we will revisit the serialization problem later. Reported-by: Alessandro Bono Signed-off-by: Rafael J. Wysocki

cpufreq: Remove temporary fix for race between CPU hotplug and sysfs-writes

2013-09-10T00:49:47+00:00

Commit "cpufreq: serialize calls to __cpufreq_governor()" had been a temporary and partial solution to the race condition between writing to a cpufreq sysfs file and taking a CPU offline. Now that we have a proper and complete solution to that problem, remove the temporary fix. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki

cpufreq: serialize calls to __cpufreq_governor()

2013-09-10T00:49:46+00:00

We can't take a big lock around __cpufreq_governor() as this causes recursive locking for some cases. But calls to this routine must be serialized for every policy. Otherwise we can see some unpredictable events. For example, consider following scenario: __cpufreq_remove_dev() __cpufreq_governor(policy, CPUFREQ_GOV_STOP); policy->governor->governor(policy, CPUFREQ_GOV_STOP); cpufreq_governor_dbs() case CPUFREQ_GOV_STOP: mutex_destroy(&cpu_cdbs->timer_mutex) cpu_cdbs->cur_policy = NULL; store() __cpufreq_set_policy() __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS); policy->governor->governor(policy, CPUFREQ_GOV_LIMITS); case CPUFREQ_GOV_LIMITS: mutex_lock(&cpu_cdbs->timer_mutex); <-- Warning (destroyed mutex) if (policy->max < cpu_cdbs->cur_policy->cur) <- cur_policy == NULL And so store() will eventually result in a crash if cur_policy is NULL at this point. Introduce an additional variable which would guarantee serialization here. Reported-by: Stephen Boyd Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Drop the owner field from struct cpufreq_driver

2013-08-10T01:24:47+00:00

We don't need to set .owner = THIS_MODULE any more in cpufreq drivers as this field isn't used any more by the cpufreq core. This patch removes it and updates all dependent drivers accordingly. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Store cpufreq policies in a list

2013-08-10T01:24:06+00:00

Policies available in the cpufreq framework are now linked together. They are accessible via cpufreq_policy_list defined in the cpufreq core. [rjw: Fix from Yinghai Lu folded in] Signed-off-by: Lukasz Majewski Signed-off-by: Myungjoo Ham Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Give consistent names to cpufreq_policy objects

2013-08-07T21:34:10+00:00

They are called policy, cur_policy, new_policy, data, etc. Just call them policy wherever possible. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Re-arrange declarations in cpufreq.h

2013-08-07T21:34:10+00:00

They are pretty much mixed up. Although generic headers are present, definitions/declarations are present outside of them too ... This patch just moves stuff up and down to make it look better and consistent. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Clean up header files included in the core

2013-08-07T21:34:09+00:00

This patch addresses the following issues in the header files in the cpufreq core: - Include headers in ascending order, so that we don't add same many times by mistake. - must be included after , so that they override whatever they need to. - Remove unnecessary includes. - Don't include files already included by cpufreq.h or cpufreq_governor.h. [rjw: Changelog] Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Remove unused function __cpufreq_driver_getavg()

2013-07-25T23:06:44+00:00

The target frequency calculation method in the ondemand governor has changed and it is now independent of the measured average frequency. Consequently, the __cpufreq_driver_getavg() function and getavg member of struct cpufreq_driver are not used any more, so drop them. [rjw: Changelog] Signed-off-by: Stratos Karafotis Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: Fix serialization of frequency transitions

2013-07-04T11:12:44+00:00

Commit 7c30ed ("cpufreq: make sure frequency transitions are serialized") interacts poorly with systems that have a single core freqency for all cores. On such systems we have a single policy for all cores with several CPUs. When we do a frequency transition the governor calls the pre and post change notifiers which causes cpufreq_notify_transition() per CPU. Since the policy is the same for all of them all CPUs after the first and the warnings added are generated by checking a per-policy flag the warnings will be triggered for all cores after the first. Fix this by allowing notifier to be called for n times. Where n is the number of cpus in policy->cpus. Reported-and-tested-by: Mark Brown Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki