[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <cover.1497002895.git.viresh.kumar@linaro.org>
Date: Fri, 9 Jun 2017 15:45:53 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Rafael Wysocki <rjw@...ysocki.net>
Cc: Viresh Kumar <viresh.kumar@...aro.org>,
linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
Juri Lelli <Juri.Lelli@....com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>, patrick.bellasi@....com,
john.ettedgui@...il.com,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Joel Fernandes <joelaf@...gle.com>,
Morten Rasmussen <morten.rasmussen@....com>
Subject: [PATCH 0/3] cpufreq: schedutil: Fix 4.12 regressions
Hi Rafael,
I have identified some regressions with the schedutil governor which
happen due to one of your patches that got merged in 4.12-rc1.
This series fixes all the drivers which provide a ->target_index()
callback but doesn't fix the drivers which provide ->target() callback.
Such platforms need to implement the ->resolve_freq() callback in order
to get this fixed and I only had hardware for testing intel_pstate,
which I fixed in this series.
I am wondering if there is another way to fix this issue (than what I
tried) or if we should revert the offending commit (39b64aa1c007) and
look for other solutions.
Anyway, this series has the necessary patches to fix it.
Viresh Kumar (3):
cpufreq: schedutil: Restore cached_raw_freq behavior
cpufreq: schedutil: Fix selection algorithm while reducing frequency
cpufreq: intel_pstate: Provide resolve_freq() to fix regression
drivers/cpufreq/intel_pstate.c | 14 +++++++++++++
kernel/sched/cpufreq_schedutil.c | 45 +++++++++++++++++++++++++++++++++-------
2 files changed, 52 insertions(+), 7 deletions(-)
--
2.13.0.70.g6367777092d9
Powered by blists - more mailing lists