#include #include "timer.h" void set_itimer_interval_value(struct itimerval *itimer, unsigned long sec, unsigned long usec) { itimer->it_interval.tv_sec = sec; itimer->it_interval.tv_usec = usec; itimer->it_value.tv_sec = sec; itimer->it_value.tv_usec = usec; } //git.distanz.ch/cgit.cgi/linux/net-next.git/atom/?h=nds-private-remove' type='application/atom+xml'/>
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-10-12 21:47:03 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-10-13 14:42:06 +0200
commitabb6627910a1e783c8e034b35b7c80e5e7f98f41 (patch)
treec346d3f1add775bacbec9e0dc51f8f3e88ecfec7
parent899bb6642f2a2f2cd3f77abd6c5a14550e3b37e6 (diff)
cpufreq: conservative: Fix next frequency selection
Commit d352cf47d93e (cpufreq: conservative: Do not use transition notifications) overlooked the case when the "frequency step" used by the conservative governor is small relative to the distances between the available frequencies and broke the algorithm by using policy->cur instead of the previously requested frequency when computing the next one. As a result, the governor may not be able to go outside of a narrow range between two consecutive available frequencies. Fix the problem by making the governor save the previously requested frequency and select the next one relative that value (unless it is out of range, in which case policy->cur will be used instead). Fixes: d352cf47d93e (cpufreq: conservative: Do not use transition notifications) Link: https://bugzilla.kernel.org/show_bug.cgi?id=177171 Reported-and-tested-by: Aleksey Rybalkin <aleksey@rybalkin.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.8+ <stable@vger.kernel.org> # 4.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat