summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq
diff options
context:
space:
mode:
Diffstat (limited to 'drivers/cpufreq')
-rw-r--r--drivers/cpufreq/cpufreq_governor.c16
1 files changed, 4 insertions, 12 deletions
diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 99d25af6485b..fd4cdc2db238 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -38,10 +38,6 @@ EXPORT_SYMBOL_GPL(dbs_data_mutex);
* reducing the sampling rate, we need to make the new value effective
* immediately.
*
- * On the other hand, if new rate is larger than the old, then we may evaluate
- * the load too soon, and it might we worth updating sample_delay_ns then as
- * well.
- *
* This must be called with dbs_data->mutex held, otherwise traversing
* policy_dbs_list isn't safe.
*/
@@ -69,18 +65,14 @@ ssize_t store_sampling_rate(struct dbs_data *dbs_data, const char *buf,
* really doesn't matter. If the read returns a value that's
* too big, the sample will be skipped, but the next invocation
* of dbs_update_util_handler() (when the update has been
- * completed) will take a sample. If the returned value is too
- * small, the sample will be taken immediately, but that isn't a
- * problem, as we want the new rate to take effect immediately
- * anyway.
+ * completed) will take a sample.
*
* If this runs in parallel with dbs_work_handler(), we may end
* up overwriting the sample_delay_ns value that it has just
- * written, but the difference should not be too big and it will
- * be corrected next time a sample is taken, so it shouldn't be
- * significant.
+ * written, but it will be corrected next time a sample is
+ * taken, so it shouldn't be significant.
*/
- gov_update_sample_delay(policy_dbs, dbs_data->sampling_rate);
+ gov_update_sample_delay(policy_dbs, 0);
mutex_unlock(&policy_dbs->timer_mutex);
}