mbox series

[0/6] cpufreq: transition-latency cleanups

Message ID cover.1498733506.git.viresh.kumar@linaro.org
Headers show
Series cpufreq: transition-latency cleanups | expand

Message

Viresh Kumar June 29, 2017, 10:59 a.m. UTC 
Hi,

This series tries to cleanup the code around transition-latency and its
users. Some of the old legacy code, which may not make much sense now,
is being dropped as.

Some code consolidation also happens across governors.

Based of: pm/linux-next
Tested on: ARM64 Hikey board.

--
viresh

Viresh Kumar (6):
  cpufreq: Don't check for max_transition_latency
  cpufreq: Remove (now) unused code related to max_transition_latency
  cpufreq: governor: Drop min_sampling_rate
  cpufreq: Use transition_delay_us for legacy governors as well
  cpufreq: Cap the default transition delay value to 10 ms
  cpufreq: arm_big_little: Make ->get_transition_latency() mandatory

 Documentation/admin-guide/pm/cpufreq.rst |  8 --------
 drivers/cpufreq/arm_big_little.c         | 10 ++++-----
 drivers/cpufreq/cpufreq.c                | 19 -----------------
 drivers/cpufreq/cpufreq_conservative.c   |  6 ------
 drivers/cpufreq/cpufreq_governor.c       | 17 ++--------------
 drivers/cpufreq/cpufreq_governor.h       |  2 --
 drivers/cpufreq/cpufreq_ondemand.c       | 12 -----------
 drivers/cpufreq/cpufreq_performance.c    |  6 ------
 include/linux/cpufreq.h                  | 35 +++++++++++++++++++++++---------
 kernel/sched/cpufreq_schedutil.c         | 11 +---------
 10 files changed, 32 insertions(+), 94 deletions(-)

-- 
2.13.0.71.gd7076ec9c9cb

Comments

Rafael J. Wysocki June 29, 2017, 8:36 p.m. UTC | #1 
Hi,

On Thu, Jun 29, 2017 at 12:59 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Hi,

>

> This series tries to cleanup the code around transition-latency and its

> users. Some of the old legacy code, which may not make much sense now,

> is being dropped as.

>

> Some code consolidation also happens across governors.


Please mark RFC patches as RFC.

This is not going to be considered for 4.13, so the timing is not the
best one I could think about.

Thanks,
Rafael