[PATCH V5] thermal: Add cooling device's statistics in sysfs

[Viresh Kumar]

This extends the sysfs interface for thermal cooling devices and exposes
some pretty useful statistics. These statistics have proven to be quite
useful specially while doing benchmarks related to the task scheduler,
where we want to make sure that nothing has disrupted the test,
specially the cooling device which may have put constraints on the CPUs.
The information exposed here tells us to what extent the CPUs were
constrained by the thermal framework.

The write-only "reset" file is used to reset the statistics.

The read-only "time_in_state_ms" file shows the time (in msec) spent by the
device in the respective cooling states, and it prints one line per
cooling state.

The read-only "total_trans" file shows single positive integer value
showing the total number of cooling state transitions the device has
gone through since the time the cooling device is registered or the time
when statistics were reset last.

The read-only "trans_table" file shows a two dimensional matrix, where
an entry <i,j> (row i, column j) represents the number of transitions
from State_i to State_j.

This is how the directory structure looks like for a single cooling
device:

$ ls -R /sys/class/thermal/cooling_device0/
/sys/class/thermal/cooling_device0/:
cur_state  max_state  power  stats  subsystem  type  uevent

/sys/class/thermal/cooling_device0/power:
autosuspend_delay_ms  runtime_active_time  runtime_suspended_time
control   runtime_status

/sys/class/thermal/cooling_device0/stats:
reset  time_in_state_ms  total_trans  trans_table

This is tested on ARM 64-bit Hisilicon hikey620 board running Ubuntu and
ARM 64-bit Hisilicon hikey960 board running Android.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
V4->V5:
- time_in_state's unit is msec now instead of clock_t.
- Remove double setting of ->stats pointer.

V3->V4:
- Added CONFIG_THERMAL_STATISTICS
- Added transition table file in sysfs
- Updated documentation for new sysfs files
- The unit of time in time_in_state is clock_t now
- Separate routines for cooling device stat setup/destroy

V2->V3:
- Total number of states is max_level + 1. The earlier version didn't
  take that into account and so the stats for the highest state were
  missing.

V1->V2:
- Move to sysfs from debugfs

 Documentation/thermal/sysfs-api.txt |  31 +
 drivers/thermal/Kconfig |   7 ++
 drivers/thermal/thermal_core.c  |   3 +-
 drivers/thermal/thermal_core.h  |  10 ++
 drivers/thermal/thermal_helpers.c   |   5 +-
 drivers/thermal/thermal_sysfs.c | 225 
 include/linux/thermal.h |   1 +
 7 files changed, 280 insertions(+), 2 deletions(-)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index bb9a0a53e76b..911399730c1c 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -255,6 +255,7 @@ temperature) and throttle appropriate devices.
 2. sysfs attributes structure
 
 RO read only value
+WO write only value
 RW read/write value
 
 Thermal sysfs attributes will be represented under /sys/class/thermal.
@@ -286,6 +287,11 @@ if hwmon is compiled in or built as a module.
 |---type:  Type of the cooling device(processor/fan/...)
 |---max_state: Maximum cooling state of the cooling device
 |---cur_state: Current cooling state of the cooling device
+|---stats: Directory containing cooling device's statistics
+|---stats/reset:   Writing any value resets the statistics
+|---stats/time_in_state_ms:Time (msec) spent in various cooling 
states
+|---stats/total_trans: Total number of times cooling state is changed
+|---stats/trans_table: Cooing state transition table
 
 
 Then next two dynamic attributes are created/removed in pairs. They represent
@@ -490,6 +496,31 @@ cur_state
- cur_state == max_state means the maximum cooling.
RW, Required
 
+stats/reset
+   Writing any value resets the cooling device's statistics.
+   WO, Required
+
+stats/time_in_state_ms:
+   The amount of time spent by the cooling device in various cooling
+   states. The output will have " " pair in each line, which
+   will mean this cooling device spent  msec of time at .
+   Output will have one line for each of the supported states.  usertime
+   units here is 10mS (similar to other time exported in /proc).
+   RO, Required
+
+stats/total_trans:
+   A single positive value showing the total number of times the state of a
+   cooling device is changed.
+   RO, Required
+
+stats/trans_table:
+   This gives fine grained information about all the cooling state
+   transitions. The cat output here is a two dimensional matrix, where an
+   entry <i,j> (row i, column j) represents the number of 

Re: [PATCH] Documentation/thermal: Check links and convert to https

[Viresh Kumar]

On 28-03-18, 22:59, Sanjeev Gupta wrote:
> All links working.

And why is it important to convert them to https ?

> Signed-off-by: Sanjeev Gupta 
> ---
>  Documentation/thermal/cpu-cooling-api.txt | 2 +-
>  Documentation/thermal/nouveau_thermal | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/thermal/cpu-cooling-api.txt 
> b/Documentation/thermal/cpu-cooling-api.txt
> index 7df567eaea1a..32917d178c51 100644
> --- a/Documentation/thermal/cpu-cooling-api.txt
> +++ b/Documentation/thermal/cpu-cooling-api.txt
> @@ -5,7 +5,7 @@ Written by Amit Daniel Kachhap 
>  
>  Updated: 6 Jan 2015
>  
> -Copyright (c)  2012 Samsung Electronics Co., Ltd(http://www.samsung.com)
> +Copyright (c)  2012 Samsung Electronics Co., Ltd (https://www.samsung.com)
>  
>  0. Introduction
>  
> diff --git a/Documentation/thermal/nouveau_thermal 
> b/Documentation/thermal/nouveau_thermal
> index 6e17a11efcb0..502b0b95c2e2 100644
> --- a/Documentation/thermal/nouveau_thermal
> +++ b/Documentation/thermal/nouveau_thermal
> @@ -79,4 +79,4 @@ Thermal management on Nouveau is new and may not work on 
> all cards. If you have
>  inquiries, please ping mupuf on IRC (#nouveau, freenode).
>  
>  Bug reports should be filled on Freedesktop's bug tracker. Please follow
> -http://nouveau.freedesktop.org/wiki/Bugs
> +https://nouveau.freedesktop.org/wiki/Bugs
> -- 
> 2.15.1

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

[Viresh Kumar]

On 14-03-18, 13:44, Viresh Kumar wrote:
> I got those warnings as well, and I quietly ignored them :)
> 
> I ignored the renaming part for the sake of consistency. The other existing
> routines for similar purpose are named as:
> 
> thermal_cooling_device_type_show
> thermal_cooling_device_max_state_show
> thermal_cooling_device_cur_state_show
> thermal_cooling_device_cur_state_store
> 
> for me it made more sense to follow that naming convention. And I didn't use 
> the
> _RO and _WO variants for the same reason.
> 
> Now here is what I propose now:
> 
> - You apply this patch as-is and ignore the warning.
> 
> - I will send few patches on top of that to do:
>   - renaming of all such routines to shorter versions.
>   - Use the _RO or _WO variants of the macro everywhere.
> 
> What do you say ?

@Zhang: Can you please share the way you want this to get merged ? And if the
above is fine with you ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

[Viresh Kumar]

On 14-03-18, 16:01, Zhang Rui wrote:
> WARNING: please write a paragraph that describes the config symbol
> fully
> #147: FILE: drivers/thermal/Kconfig:18:
> +config THERMAL_STATISTICS
> 
> WARNING: Consider renaming function(s)
> 'thermal_cooling_device_total_trans_show' to 'total_trans_show'
> #391: FILE: drivers/thermal/thermal_sysfs.c:901:
> +}
> 
> WARNING: Consider renaming function(s)
> 'thermal_cooling_device_time_in_state_show' to 'time_in_state_show'
> #395: FILE: drivers/thermal/thermal_sysfs.c:905:
> +static DEVICE_ATTR(time_in_state, 0444,
> 
> WARNING: Consider renaming function(s)
> 'thermal_cooling_device_reset_store' to 'reset_store'
> #397: FILE: drivers/thermal/thermal_sysfs.c:907:
> +static DEVICE_ATTR(reset, 0200, NULL,
> thermal_cooling_device_reset_store);
> 
> WARNING: Consider renaming function(s)
> 'thermal_cooling_device_trans_table_show' to 'trans_table_show'
> #398: FILE: drivers/thermal/thermal_sysfs.c:908:
> +static DEVICE_ATTR(trans_table, 0444,
> 
> total: 0 errors, 5 warnings, 366 lines checked
> 
> 
> I'm okay with the first one because the description does not have to be
> larger than 3 lines.

Right.

> the last 4 warnings makes sense to me. I think we should rename the
> function and use DEVICE_ATTR_RO() and DEVICE_ATTR_WO() instead.
> 
> what do you think?

I got those warnings as well, and I quietly ignored them :)

I ignored the renaming part for the sake of consistency. The other existing
routines for similar purpose are named as:

thermal_cooling_device_type_show
thermal_cooling_device_max_state_show
thermal_cooling_device_cur_state_show
thermal_cooling_device_cur_state_store

for me it made more sense to follow that naming convention. And I didn't use the
_RO and _WO variants for the same reason.

Now here is what I propose now:

- You apply this patch as-is and ignore the warning.

- I will send few patches on top of that to do:
  - renaming of all such routines to shorter versions.
  - Use the _RO or _WO variants of the macro everywhere.

What do you say ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

[Viresh Kumar]

On 13-03-18, 15:02, Zhang Rui wrote:
> Hi, Viresh,
> 
> I will queue it for 4.17, with just one minor fix below.
> 
> On 二, 2018-01-16 at 15:22 +0530, Viresh Kumar wrote:

> > +   cdev->stats = stats;
> > +   stats->last_time = ktime_get();
> > +   stats->max_states = states;
> > +   cdev->stats = stats;
> > +
> 
> cdev->stats is set twice here, I will remove the first one.

Thanks for catching that :)

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

[Viresh Kumar]

On 16-01-18, 15:22, Viresh Kumar wrote:
> This extends the sysfs interface for thermal cooling devices and exposes
> some pretty useful statistics. These statistics have proven to be quite
> useful specially while doing benchmarks related to the task scheduler,
> where we want to make sure that nothing has disrupted the test,
> specially the cooling device which may have put constraints on the CPUs.
> The information exposed here tells us to what extent the CPUs were
> constrained by the thermal framework.

@Eduardo/Zhang: Are you going to merge this for 4.17 ?

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V4] thermal: Add cooling device's statistics in sysfs

[Viresh Kumar]

This extends the sysfs interface for thermal cooling devices and exposes
some pretty useful statistics. These statistics have proven to be quite
useful specially while doing benchmarks related to the task scheduler,
where we want to make sure that nothing has disrupted the test,
specially the cooling device which may have put constraints on the CPUs.
The information exposed here tells us to what extent the CPUs were
constrained by the thermal framework.

The write-only "reset" file is used to reset the statistics.

The read-only "time_in_state" file shows the clock_t time spent by the
device in the respective cooling states, and it prints one line per
cooling state.

The read-only "total_trans" file shows single positive integer value
showing the total number of cooling state transitions the device has
gone through since the time the cooling device is registered or the time
when statistics were reset last.

The read-only "trans_table" file shows a two dimensional matrix, where
an entry <i,j> (row i, column j) represents the number of transitions
from State_i to State_j.

This is how the directory structure looks like for a single cooling
device:

$ ls -R /sys/class/thermal/cooling_device0/
/sys/class/thermal/cooling_device0/:
cur_state  max_state  power  stats  subsystem  type  uevent

/sys/class/thermal/cooling_device0/power:
autosuspend_delay_ms  runtime_active_time  runtime_suspended_time
control   runtime_status

/sys/class/thermal/cooling_device0/stats:
reset  time_in_state  total_trans  trans_table

This is tested on ARM 64-bit Hisilicon hikey620 board running Ubuntu and
ARM 64-bit Hisilicon hikey960 board running Android.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
V3->V4:
- Added CONFIG_THERMAL_STATISTICS
- Added transition table file in sysfs
- Updated documentation for new sysfs files
- The unit of time in time_in_state is clock_t now
- Separate routines for cooling device stat setup/destroy

V2->V3:
- Total number of states is max_level + 1. The earlier version didn't
  take that into account and so the stats for the highest state were
  missing.

V1->V2:
- Move to sysfs from debugfs

 Documentation/thermal/sysfs-api.txt |  32 +
 drivers/thermal/Kconfig |   7 ++
 drivers/thermal/thermal_core.c  |   3 +-
 drivers/thermal/thermal_core.h  |  10 ++
 drivers/thermal/thermal_helpers.c   |   5 +-
 drivers/thermal/thermal_sysfs.c | 227 
 include/linux/thermal.h |   1 +
 7 files changed, 283 insertions(+), 2 deletions(-)

diff --git a/Documentation/thermal/sysfs-api.txt 
b/Documentation/thermal/sysfs-api.txt
index bb9a0a53e76b..5a71f8152dff 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -255,6 +255,7 @@ temperature) and throttle appropriate devices.
 2. sysfs attributes structure
 
 RO read only value
+WO write only value
 RW read/write value
 
 Thermal sysfs attributes will be represented under /sys/class/thermal.
@@ -286,6 +287,11 @@ if hwmon is compiled in or built as a module.
 |---type:  Type of the cooling device(processor/fan/...)
 |---max_state: Maximum cooling state of the cooling device
 |---cur_state: Current cooling state of the cooling device
+|---stats: Directory containing cooling device's statistics
+|---stats/reset:   Writing any value resets the statistics
+|---stats/time_in_state:   Time (clock_t) spent in various cooling states
+|---stats/total_trans: Total number of times cooling state is changed
+|---stats/trans_table: Cooing state transition table
 
 
 Then next two dynamic attributes are created/removed in pairs. They represent
@@ -490,6 +496,32 @@ cur_state
- cur_state == max_state means the maximum cooling.
RW, Required
 
+stats/reset
+   Writing any value resets the cooling device's statistics.
+   WO, Required
+
+stats/time_in_state:
+   The amount of time spent by the cooling device in various cooling
+   states. The output will have " " pair in each line, which
+   will mean this cooling device spent  usertime units (clock_t) of
+   time at . Output will have one line for each of the supported
+   states.  usertime units here is 10mS (similar to other time exported in
+   /proc).
+   RO, Required
+
+stats/total_trans:
+   A single positive value showing the total number of times the state of a
+   cooling device is changed.
+   RO, Required
+
+stats/trans_table:
+   This gives fine grained information about all the cooling state
+   transitions. The cat output here is a two dimensional matrix, where an
+   entry <i,j> (row i, column j) represents the number of transitions from
+   State_i to State_j. If the transition table is bigger than PAGE_SIZE,
+   

[PATCH] cpu_cooling: Remove static-power related documentation

[Viresh Kumar]

commit 84fe2cab4859 ("cpu_cooling: Drop static-power related stuff")
removed support for static-power in kernel, but it missed reflecting the
same in documentation. Remove the static power related documentation
bits as well.

Reported-by: Javi Merino <javi.mer...@kernel.org>
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/thermal/cpu-cooling-api.txt | 82 +--
 1 file changed, 2 insertions(+), 80 deletions(-)

diff --git a/Documentation/thermal/cpu-cooling-api.txt 
b/Documentation/thermal/cpu-cooling-api.txt
index 7a1c89db0419..7df567eaea1a 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -44,16 +44,14 @@ the user. The registration APIs returns the cooling device 
pointer.
 2. Power models
 
 The power API registration functions provide a simple power model for
-CPUs.  The current power is calculated as dynamic + (optionally)
-static power.  This power model requires that the operating-points of
+CPUs.  The current power is calculated as dynamic power (static power isn't
+supported currently).  This power model requires that the operating-points of
 the CPUs are registered using the kernel's opp library and the
 `cpufreq_frequency_table` is assigned to the `struct device` of the
 cpu.  If you are using CONFIG_CPUFREQ_DT then the
 `cpufreq_frequency_table` should already be assigned to the cpu
 device.
 
-2.1 Dynamic power
-
 The dynamic power consumption of a processor depends on many factors.
 For a given processor implementation the primary factors are:
 
@@ -92,79 +90,3 @@ mW/MHz/uVolt^2.  Typical values for mobile CPUs might lie in 
range
 from 100 to 500.  For reference, the approximate values for the SoC in
 ARM's Juno Development Platform are 530 for the Cortex-A57 cluster and
 140 for the Cortex-A53 cluster.
-
-
-2.2 Static power
-
-Static leakage power consumption depends on a number of factors.  For a
-given circuit implementation the primary factors are:
-
-- Time the circuit spends in each 'power state'
-- Temperature
-- Operating voltage
-- Process grade
-
-The time the circuit spends in each 'power state' for a given
-evaluation period at first order means OFF or ON.  However,
-'retention' states can also be supported that reduce power during
-inactive periods without loss of context.
-
-Note: The visibility of state entries to the OS can vary, according to
-platform specifics, and this can then impact the accuracy of a model
-based on OS state information alone.  It might be possible in some
-cases to extract more accurate information from system resources.
-
-The temperature, operating voltage and process 'grade' (slow to fast)
-of the circuit are all significant factors in static leakage power
-consumption.  All of these have complex relationships to static power.
-
-Circuit implementation specific factors include the chosen silicon
-process as well as the type, number and size of transistors in both
-the logic gates and any RAM elements included.
-
-The static power consumption modelling must take into account the
-power managed regions that are implemented.  Taking the example of an
-ARM processor cluster, the modelling would take into account whether
-each CPU can be powered OFF separately or if only a single power
-region is implemented for the complete cluster.
-
-In one view, there are others, a static power consumption model can
-then start from a set of reference values for each power managed
-region (e.g. CPU, Cluster/L2) in each state (e.g. ON, OFF) at an
-arbitrary process grade, voltage and temperature point.  These values
-are then scaled for all of the following: the time in each state, the
-process grade, the current temperature and the operating voltage.
-However, since both implementation specific and complex relationships
-dominate the estimate, the appropriate interface to the model from the
-cpu cooling device is to provide a function callback that calculates
-the static power in this platform.  When registering the cpu cooling
-device pass a function pointer that follows the `get_static_t`
-prototype:
-
-int plat_get_static(cpumask_t *cpumask, int interval,
-unsigned long voltage, u32 );
-
-`cpumask` is the cpumask of the cpus involved in the calculation.
-`voltage` is the voltage at which they are operating.  The function
-should calculate the average static power for the last `interval`
-milliseconds.  It returns 0 on success, -E* on error.  If it
-succeeds, it should store the static power in `power`.  Reading the
-temperature of the cpus described by `cpumask` is left for
-plat_get_static() to do as the platform knows best which thermal
-sensor is closest to the cpu.
-
-If `plat_static_func` is NULL, static power is considered to be
-negligible for this platform and only dynamic power is considered.
-
-The platform specific callback can then use any combination of tables
-and/or equations to permute the est

[PATCH 1/4] cpu_cooling: Make of_cpufreq_power_cooling_register() parse DT

[Viresh Kumar]

All the callers of of_cpufreq_power_cooling_register() have almost
identical code and it makes more sense to move that code into the helper
as its all about reading DT properties.

This got rid of lot of redundant code.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/thermal/cpu-cooling-api.txt |  7 ++---
 drivers/cpufreq/arm_big_little.c  | 23 +--
 drivers/cpufreq/cpufreq-dt.c  | 27 +
 drivers/cpufreq/mediatek-cpufreq.c| 22 +-
 drivers/cpufreq/qoriq-cpufreq.c   | 14 +
 drivers/thermal/cpu_cooling.c | 49 +++
 include/linux/cpu_cooling.h   | 15 ++
 7 files changed, 41 insertions(+), 116 deletions(-)

diff --git a/Documentation/thermal/cpu-cooling-api.txt 
b/Documentation/thermal/cpu-cooling-api.txt
index 71653584cd03..4f6f5e9bb4d6 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -51,8 +51,7 @@ Dynamic power).  "plat_static_func" is a function to 
calculate the
 static power consumed by these cpus (See 2.2 Static power).
 
 1.1.4 struct thermal_cooling_device *of_cpufreq_power_cooling_register(
-struct device_node *np, const struct cpumask *clip_cpus, u32 capacitance,
-get_static_t plat_static_func)
+   struct cpufreq_policy *policy)
 
 Similar to cpufreq_power_cooling_register, this function register a
 cpufreq cooling device with power extensions using the device tree
@@ -76,8 +75,8 @@ cpu.  If you are using CONFIG_CPUFREQ_DT then the
 device.
 
 The `plat_static_func` parameter of `cpufreq_power_cooling_register()`
-and `of_cpufreq_power_cooling_register()` is optional.  If you don't
-provide it, only dynamic power will be considered.
+is optional.  If you don't provide it, only dynamic power will be
+considered.
 
 2.1 Dynamic power
 
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 65ec5f01aa8d..3d5ed4ef3927 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -526,34 +526,13 @@ static int bL_cpufreq_exit(struct cpufreq_policy *policy)
 
 static void bL_cpufreq_ready(struct cpufreq_policy *policy)
 {
-   struct device *cpu_dev = get_cpu_device(policy->cpu);
int cur_cluster = cpu_to_cluster(policy->cpu);
-   struct device_node *np;
 
/* Do not register a cpu_cooling device if we are in IKS mode */
if (cur_cluster >= MAX_CLUSTERS)
return;
 
-   np = of_node_get(cpu_dev->of_node);
-   if (WARN_ON(!np))
-   return;
-
-   if (of_find_property(np, "#cooling-cells", NULL)) {
-   u32 power_coefficient = 0;
-
-   of_property_read_u32(np, "dynamic-power-coefficient",
-_coefficient);
-
-   cdev[cur_cluster] = of_cpufreq_power_cooling_register(np,
-   policy, power_coefficient, NULL);
-   if (IS_ERR(cdev[cur_cluster])) {
-   dev_err(cpu_dev,
-   "running cpufreq without cooling device: %ld\n",
-   PTR_ERR(cdev[cur_cluster]));
-   cdev[cur_cluster] = NULL;
-   }
-   }
-   of_node_put(np);
+   cdev[cur_cluster] = of_cpufreq_power_cooling_register(policy);
 }
 
 static struct cpufreq_driver bL_cpufreq_driver = {
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 545946ad0752..1e7bec7694ab 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -319,33 +319,8 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
 static void cpufreq_ready(struct cpufreq_policy *policy)
 {
struct private_data *priv = policy->driver_data;
-   struct device_node *np = of_node_get(priv->cpu_dev->of_node);
 
-   if (WARN_ON(!np))
-   return;
-
-   /*
-* For now, just loading the cooling device;
-* thermal DT code takes care of matching them.
-*/
-   if (of_find_property(np, "#cooling-cells", NULL)) {
-   u32 power_coefficient = 0;
-
-   of_property_read_u32(np, "dynamic-power-coefficient",
-_coefficient);
-
-   priv->cdev = of_cpufreq_power_cooling_register(np,
-   policy, power_coefficient, NULL);
-   if (IS_ERR(priv->cdev)) {
-   dev_err(priv->cpu_dev,
-   "running cpufreq without cooling device: %ld\n",
-   PTR_ERR(priv->cdev));
-
-   priv->cdev = NULL;
-   }
-   }
-
-   of_node_put(np);
+   priv->cdev = of_cpufreq_power_cooling_register(policy);

[PATCH 2/4] cpu_cooling: Remove unused cpufreq_power_cooling_register()

[Viresh Kumar]

It isn't used by anyone, drop it.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/thermal/cpu-cooling-api.txt | 24 +++-
 drivers/thermal/cpu_cooling.c | 30 --
 include/linux/cpu_cooling.h   | 10 --
 3 files changed, 3 insertions(+), 61 deletions(-)

diff --git a/Documentation/thermal/cpu-cooling-api.txt 
b/Documentation/thermal/cpu-cooling-api.txt
index 4f6f5e9bb4d6..ea61e8bf7e2b 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -36,28 +36,14 @@ the user. The registration APIs returns the cooling device 
pointer.
 np: pointer to the cooling device device tree node
 clip_cpus: cpumask of cpus where the frequency constraints will happen.
 
-1.1.3 struct thermal_cooling_device *cpufreq_power_cooling_register(
-const struct cpumask *clip_cpus, u32 capacitance,
-get_static_t plat_static_func)
-
-Similar to cpufreq_cooling_register, this function registers a cpufreq
-cooling device.  Using this function, the cooling device will
-implement the power extensions by using a simple cpu power model.  The
-cpus must have registered their OPPs using the OPP library.
-
-The additional parameters are needed for the power model (See 2. Power
-models).  "capacitance" is the dynamic power coefficient (See 2.1
-Dynamic power).  "plat_static_func" is a function to calculate the
-static power consumed by these cpus (See 2.2 Static power).
-
-1.1.4 struct thermal_cooling_device *of_cpufreq_power_cooling_register(
+1.1.3 struct thermal_cooling_device *of_cpufreq_power_cooling_register(
struct cpufreq_policy *policy)
 
-Similar to cpufreq_power_cooling_register, this function register a
+Similar to cpufreq_cooling_register, this function register a
 cpufreq cooling device with power extensions using the device tree
 information supplied by the np parameter.
 
-1.1.5 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+1.1.4 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 
 This interface function unregisters the "thermal-cpufreq-%x" cooling 
device.
 
@@ -74,10 +60,6 @@ cpu.  If you are using CONFIG_CPUFREQ_DT then the
 `cpufreq_frequency_table` should already be assigned to the cpu
 device.
 
-The `plat_static_func` parameter of `cpufreq_power_cooling_register()`
-is optional.  If you don't provide it, only dynamic power will be
-considered.
-
 2.1 Dynamic power
 
 The dynamic power consumption of a processor depends on many factors.
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 5740b49fee68..94ffb4463e22 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -841,36 +841,6 @@ of_cpufreq_cooling_register(struct device_node *np,
 }
 EXPORT_SYMBOL_GPL(of_cpufreq_cooling_register);
 
-/**
- * cpufreq_power_cooling_register() - create cpufreq cooling device with power 
extensions
- * @policy:cpufreq policy
- * @capacitance:   dynamic power coefficient for these cpus
- * @plat_static_func:  function to calculate the static power consumed by these
- * cpus (optional)
- *
- * This interface function registers the cpufreq cooling device with
- * the name "thermal-cpufreq-%x".  This api can support multiple
- * instances of cpufreq cooling devices.  Using this function, the
- * cooling device will implement the power extensions by using a
- * simple cpu power model.  The cpus must have registered their OPPs
- * using the OPP library.
- *
- * An optional @plat_static_func may be provided to calculate the
- * static power consumed by these cpus.  If the platform's static
- * power consumption is unknown or negligible, make it NULL.
- *
- * Return: a valid struct thermal_cooling_device pointer on success,
- * on failure, it returns a corresponding ERR_PTR().
- */
-struct thermal_cooling_device *
-cpufreq_power_cooling_register(struct cpufreq_policy *policy, u32 capacitance,
-  get_static_t plat_static_func)
-{
-   return __cpufreq_cooling_register(NULL, policy, capacitance,
-   plat_static_func);
-}
-EXPORT_SYMBOL(cpufreq_power_cooling_register);
-
 /**
  * of_cpufreq_power_cooling_register() - create cpufreq cooling device with 
power extensions
  * @policy: CPUFreq policy.
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index f09d4feb34f4..c35778960a9c 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -41,10 +41,6 @@ typedef int (*get_static_t)(cpumask_t *cpumask, int interval,
 struct thermal_cooling_device *
 cpufreq_cooling_register(struct cpufreq_policy *policy);
 
-struct thermal_cooling_device *
-cpufreq_power_cooling_register(struct cpufreq_policy *policy,
-  

[PATCH 3/4] cpu_cooling: Keep only one of_cpufreq*cooling_register() helper

[Viresh Kumar]

of_cpufreq_cooling_register() isn't used by anyone and so can be
removed, but then we would be left with two routines:
cpufreq_cooling_register() and of_cpufreq_power_cooling_register() that
would look odd because of strange names.

Remove current implementation of of_cpufreq_cooling_register() and
rename of_cpufreq_power_cooling_register() as
of_cpufreq_cooling_register(). This simplifies lots of stuff.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/thermal/cpu-cooling-api.txt | 14 ++--
 drivers/cpufreq/arm_big_little.c  |  2 +-
 drivers/cpufreq/cpufreq-dt.c  |  2 +-
 drivers/cpufreq/mediatek-cpufreq.c|  2 +-
 drivers/cpufreq/qoriq-cpufreq.c   |  2 +-
 drivers/thermal/cpu_cooling.c | 28 ++--
 include/linux/cpu_cooling.h   | 53 ---
 7 files changed, 23 insertions(+), 80 deletions(-)

diff --git a/Documentation/thermal/cpu-cooling-api.txt 
b/Documentation/thermal/cpu-cooling-api.txt
index ea61e8bf7e2b..7a1c89db0419 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -26,24 +26,16 @@ the user. The registration APIs returns the cooling device 
pointer.
clip_cpus: cpumask of cpus where the frequency constraints will happen.
 
 1.1.2 struct thermal_cooling_device *of_cpufreq_cooling_register(
-   struct device_node *np, const struct cpumask *clip_cpus)
+   struct cpufreq_policy *policy)
 
 This interface function registers the cpufreq cooling device with
 the name "thermal-cpufreq-%x" linking it with a device tree node, in
 order to bind it via the thermal DT code. This api can support multiple
 instances of cpufreq cooling devices.
 
-np: pointer to the cooling device device tree node
-clip_cpus: cpumask of cpus where the frequency constraints will happen.
-
-1.1.3 struct thermal_cooling_device *of_cpufreq_power_cooling_register(
-   struct cpufreq_policy *policy)
-
-Similar to cpufreq_cooling_register, this function register a
-cpufreq cooling device with power extensions using the device tree
-information supplied by the np parameter.
+policy: CPUFreq policy.
 
-1.1.4 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+1.1.3 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
 
 This interface function unregisters the "thermal-cpufreq-%x" cooling 
device.
 
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 3d5ed4ef3927..c56b57dcfda5 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -532,7 +532,7 @@ static void bL_cpufreq_ready(struct cpufreq_policy *policy)
if (cur_cluster >= MAX_CLUSTERS)
return;
 
-   cdev[cur_cluster] = of_cpufreq_power_cooling_register(policy);
+   cdev[cur_cluster] = of_cpufreq_cooling_register(policy);
 }
 
 static struct cpufreq_driver bL_cpufreq_driver = {
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 1e7bec7694ab..de3d104c25d7 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -320,7 +320,7 @@ static void cpufreq_ready(struct cpufreq_policy *policy)
 {
struct private_data *priv = policy->driver_data;
 
-   priv->cdev = of_cpufreq_power_cooling_register(policy);
+   priv->cdev = of_cpufreq_cooling_register(policy);
 }
 
 static struct cpufreq_driver dt_cpufreq_driver = {
diff --git a/drivers/cpufreq/mediatek-cpufreq.c 
b/drivers/cpufreq/mediatek-cpufreq.c
index dd0bc783cb8b..1aa79486a033 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -311,7 +311,7 @@ static void mtk_cpufreq_ready(struct cpufreq_policy *policy)
 {
struct mtk_cpu_dvfs_info *info = policy->driver_data;
 
-   info->cdev = of_cpufreq_power_cooling_register(policy);
+   info->cdev = of_cpufreq_cooling_register(policy);
 }
 
 static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 3a665c18e14e..0562761a3dec 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -276,7 +276,7 @@ static void qoriq_cpufreq_ready(struct cpufreq_policy 
*policy)
 {
struct cpu_data *cpud = policy->driver_data;
 
-   cpud->cdev = of_cpufreq_power_cooling_register(policy);
+   cpud->cdev = of_cpufreq_cooling_register(policy);
 }
 
 static struct cpufreq_driver qoriq_cpufreq_driver = {
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 94ffb4463e22..55d6b9fb909d 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -819,7 +819,6 @@ EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
 
 /**
  * of_cpufreq_cooling_register - fun

Re: [PATCH] cpufreq: docs: Drop intel_pstate.txt from index.txt

[Viresh Kumar]

On Thu, Sep 28, 2017 at 5:26 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>
> Commit 33fc30b47098 (cpufreq: intel_pstate: Document the current
> behavior and user interface) dropped the intel-pstate.txt file
> from Documentation/cpu-freq/, but it did not update the index.txt
> file in there accordingly, so do that now.
>
> Fixes: 33fc30b47098 (cpufreq: intel_pstate: Document the current behavior and 
> user interface)
> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> ---
>  Documentation/cpu-freq/index.txt |2 --
>  1 file changed, 2 deletions(-)
>
> Index: linux-pm/Documentation/cpu-freq/index.txt
> ===
> --- linux-pm.orig/Documentation/cpu-freq/index.txt
> +++ linux-pm/Documentation/cpu-freq/index.txt
> @@ -32,8 +32,6 @@ cpufreq-stats.txt -   General description
>
>  index.txt  -   File index, Mailing list and Links (this document)
>
> -intel-pstate.txt - Intel pstate cpufreq driver specific file.
> -
>  pcc-cpufreq.txt -  PCC cpufreq driver specific file.

Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 2/8] drivers: boot_constraint: Add boot_constraints_disable kernel parameter

[Viresh Kumar]

On 29-08-17, 08:37, Greg Kroah-Hartman wrote:
> On Tue, Aug 01, 2017 at 02:53:43PM +0530, Viresh Kumar wrote:
> > +   boot_constraints_disable
> > +   Do not set any boot constraints for devices.
> 
> Shouldn't that be the default?  As really, that is what the situation is
> today, why force everyone to always enable the disable value?  And
> enabling a value to disable something is usually a sign of bad naming...

I will explain once again how it is getting used and then will do whatever you
suggest.

- Platforms that don't need boot constraints should not enable the CONFIG in the
  first place. Though we use the same kernel image on multiple hardware types
  many times.
- If a platform doesn't have a platform-specific driver that adds constraints at
  boot, then the boot constraint core wouldn't get into picture at all and it is
  as good as being disabled.
- And the above boot-argument (boot_constraints_disable) is used ONLY in the
  case where the platform driver is adding boot constraints at runtime.

So, the boot-constraints are disabled by default for everyone even if the
configuration is enabled. And that's why I named it the way it is right now.

Do you still feel that it needs to be renamed? 

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 2/8] drivers: boot_constraint: Add boot_constraints_disable kernel parameter

[Viresh Kumar]

Users must be given an option to discard any constraints set by
bootloaders. For example, consider that a constraint is set for the LCD
controller's supply and the LCD driver isn't loaded by the kernel. If
the user doesn't need to use the LCD device, then he shouldn't be forced
to honour the constraint.

We can also think about finer control of such constraints with help of
some sysfs files, but a kernel parameter is fine to begin with.

Tested-by: Rajendra Nayak <rna...@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 drivers/base/boot_constraints/core.c| 17 +
 2 files changed, 20 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index d9c171ce4190..0706d1b6004d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -426,6 +426,9 @@
embedded devices based on command line input.
See Documentation/block/cmdline-partition.txt
 
+   boot_constraints_disable
+   Do not set any boot constraints for devices.
+
boot_delay= Milliseconds to delay each printk during boot.
Values larger than 10 seconds (1) are changed to
no delay (0).
diff --git a/drivers/base/boot_constraints/core.c 
b/drivers/base/boot_constraints/core.c
index 366a05d6d9ba..e0c33b2b216f 100644
--- a/drivers/base/boot_constraints/core.c
+++ b/drivers/base/boot_constraints/core.c
@@ -24,6 +24,17 @@
 static LIST_HEAD(constraint_devices);
 static DEFINE_MUTEX(constraint_devices_mutex);
 
+static bool boot_constraints_disabled;
+
+static int __init constraints_disable(char *str)
+{
+   boot_constraints_disabled = true;
+   pr_debug("disabled\n");
+
+   return 0;
+}
+early_param("boot_constraints_disable", constraints_disable);
+
 /* Boot constraints core */
 
 static struct constraint_dev *constraint_device_find(struct device *dev)
@@ -126,6 +137,9 @@ int dev_boot_constraint_add(struct device *dev,
struct constraint *constraint;
int ret;
 
+   if (boot_constraints_disabled)
+   return -ENODEV;
+
mutex_lock(_devices_mutex);
 
/* Find or add the cdev type first */
@@ -184,6 +198,9 @@ void dev_boot_constraints_remove(struct device *dev)
struct constraint_dev *cdev;
struct constraint *constraint, *temp;
 
+   if (boot_constraints_disabled)
+   return;
+
mutex_lock(_devices_mutex);
 
cdev = constraint_device_find(dev);
-- 
2.13.0.71.gd7076ec9c9cb

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 0/8] drivers: Boot Constraints core

[Viresh Kumar]

Hi Greg,

Here is V3 of the boot constraints core based on the feedbacks I have
received during V2. This tested on real hardware (Qcom dragonboard 410c)
with a display controller configured from bootloader to display a flash
screen. Obviously it doesn't work seamlessly without this series and
works just fine with it. Rajendra Nayak helped getting this tested on
Qcom hardware.

Problem statement:

Some devices are powered ON by the bootloader before the bootloader
handovers control to Linux. It maybe important for those devices to keep
working until the time a Linux device driver probes the device and
reconfigure its resources.

A typical example of that can be the LCD controller, which is used by
the bootloaders to show image(s) while the platform is booting into
Linux.  The LCD controller can be using some resources, like clk,
regulators, etc, that are shared between several devices. These shared
resources should be configured to satisfy need of all the users.  If
another device's (X) driver gets probed before the LCD controller driver
in this case, then it may end up reconfiguring these resources to ranges
satisfying the current users (only device X) and that can make the LCD
screen unstable.

Of course we can have more complex cases where the same resource is
getting used by two devices while the kernel boots and the order in
which devices get probed wouldn't matter as the other device will surely
break then.

There are also cases where the resources may not be shared, but the
kernel will disable them forcefully as no users may have appeared until
a certain point in kernel boot. This makes sure that the resources stay
enabled. A wide variety of constraints can be satisfied using the new
framework.

Proposed solution:

This patchset introduces the concept of boot-constraints, which are set
by platform specific drivers (for now at least) at early init (like
subsys_initcall) and the kernel will satisfy them until the time driver
for such a device is probed (successfully or unsuccessfully). Once the
driver is probed, the driver core removes the constraints set for the
device. This series implements clk, regulator and PM domain constraints
for now.

The last patch isn't up for merge yet, and is used to test the boot
constraint framework on Qcom 410c along with some of the display
controller patches from Rob's series [1] to make sure the controller's
registers are configured properly.

Rebased over: drivers/driver-core-next (some debugfs dependencies)
Pushed here: git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git 
device/boot-constraints

V2->V3:
- Removed DT support as we aren't sure about how to define the bindings
  yet.
- Added CLK and PM domain constraint types.
- A new directory is added for boot constraints, which will also contain
  platform specific drivers in future.
- Deferred devices are still supported, just that it wouldn't be called
  from generic code anymore but platform specific code.
- Tested on Qcom 410c dragonboard with display flash screen (Rajendra).
- Usual renaming/commit-log-updates/etc changes done.

V1->V2:
- Add support for setting constraints for devices created from DT.
- Allow handling deferred devices earlier then late_init.
- Remove 'default y' line from kconfig.
- Drop '=" after boot_constraints_disable kernel param.
- Dropped the dummy testing patch now.

--
viresh

[1] https://marc.info/?l=dri-devel=149979722606563=2

Rajendra Nayak (1):
  drivers: boot_constraint: Add Qualcomm display controller constraints

Viresh Kumar (7):
  drivers: Add boot constraints core
  drivers: boot_constraint: Add boot_constraints_disable kernel
parameter
  drivers: boot_constraint: Add support for supply constraints
  drivers: boot_constraint: Add support for clk constraints
  drivers: boot_constraint: Add support for PM constraints
  drivers: boot_constraint: Add debugfs support
  drivers: boot_constraint: Manage deferrable constraints

 Documentation/admin-guide/kernel-parameters.txt |   3 +
 drivers/base/Kconfig|  10 +
 drivers/base/Makefile   |   1 +
 drivers/base/base.h |   1 +
 drivers/base/boot_constraints/Makefile  |   3 +
 drivers/base/boot_constraints/clk.c |  74 ++
 drivers/base/boot_constraints/core.c| 300 
 drivers/base/boot_constraints/core.h|  50 
 drivers/base/boot_constraints/deferrable_dev.c  | 192 +++
 drivers/base/boot_constraints/pm.c  |  32 +++
 drivers/base/boot_constraints/qcom-display.c| 107 +
 drivers/base/boot_constraints/supply.c  | 108 +
 drivers/base/dd.c   |  32 ++-
 include/linux/boot_constraint.h |  68 ++
 14 files changed, 974 insertions(+), 7 deletions(-)
 create mode 100644 drivers/base/boot_constraints/Makefile
 create mode 100644 drivers/base/boot_constraints/clk.c
 create 

Re: [PATCH] cpufreq: docs: Add missing cpuinfo_cur_freq description

[Viresh Kumar]

On 27-07-17, 02:05, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> 
> Add a description of the cpuinfo_cur_freq policy attribute in sysfs
> to the cpufreq documentation under Documentation/admin-guide/pm/ as
> it is missing after commit 2a0e49279850 (cpufreq: User/admin
> documentation update and consolidation) that overlooked it.
> 
> Fixes: 2a0e49279850 (cpufreq: User/admin documentation update and 
> consolidation)
> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> ---
>  Documentation/admin-guide/pm/cpufreq.rst |8 
>  1 file changed, 8 insertions(+)
> 
> Index: linux-pm/Documentation/admin-guide/pm/cpufreq.rst
> ===
> --- linux-pm.orig/Documentation/admin-guide/pm/cpufreq.rst
> +++ linux-pm/Documentation/admin-guide/pm/cpufreq.rst
> @@ -237,6 +237,14 @@ are the following:
>   This attribute is not present if the scaling driver in use does not
>   support it.
>  
> +``cpuinfo_cur_freq``
> + Current frequency of the CPUs belonging to this policy as obtained from
> + the hardware (in KHz).
> +
> + This is expected to be the frequency the hardware actually runs at.
> + If that frequency cannot be determined, this attribute should not
> + be present.
> +
>  ``cpuinfo_max_freq``
>   Maximum possible operating frequency the CPUs belonging to this policy
>   can run at (in kHz).

Acked-by: Viresh Kumar <viresh.ku...@linaro.org>

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 1/9] cpufreq: governor: Drop min_sampling_rate

[Viresh Kumar]

The cpufreq core and governors aren't supposed to set a limit on how
fast we want to try changing the frequency. This is currently done for
the legacy governors with help of min_sampling_rate.

At worst, we may end up setting the sampling rate to a value lower than
the rate at which frequency can be changed and then one of the CPUs in
the policy will be only changing frequency for ever.

But that is something for the user to decide and there is no need to
have special handling for such cases in the core. Leave it for the user
to figure out.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/admin-guide/pm/cpufreq.rst |  8 
 drivers/cpufreq/cpufreq_conservative.c   |  6 --
 drivers/cpufreq/cpufreq_governor.c   | 10 ++
 drivers/cpufreq/cpufreq_governor.h   |  1 -
 drivers/cpufreq/cpufreq_ondemand.c   | 12 
 include/linux/cpufreq.h  |  2 --
 6 files changed, 2 insertions(+), 37 deletions(-)

diff --git a/Documentation/admin-guide/pm/cpufreq.rst 
b/Documentation/admin-guide/pm/cpufreq.rst
index 463cf7e73db8..2eb3bf62393e 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -471,14 +471,6 @@ it is allowed to use (the ``scaling_max_freq`` policy 
limit).
 
# echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > 
ondemand/sampling_rate
 
-
-``min_sampling_rate``
-   The minimum value of ``sampling_rate``.
-
-   Equal to 1 (10 ms) if :c:macro:`CONFIG_NO_HZ_COMMON` and
-   :c:data:`tick_nohz_active` are both set or to 20 times the value of
-   :c:data:`jiffies` in microseconds otherwise.
-
 ``up_threshold``
If the estimated CPU load is above this value (in percent), the governor
will set the frequency to the maximum value allowed for the policy.
diff --git a/drivers/cpufreq/cpufreq_conservative.c 
b/drivers/cpufreq/cpufreq_conservative.c
index 88220ff3e1c2..f20f20a77d4d 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -246,7 +246,6 @@ gov_show_one_common(sampling_rate);
 gov_show_one_common(sampling_down_factor);
 gov_show_one_common(up_threshold);
 gov_show_one_common(ignore_nice_load);
-gov_show_one_common(min_sampling_rate);
 gov_show_one(cs, down_threshold);
 gov_show_one(cs, freq_step);
 
@@ -254,12 +253,10 @@ gov_attr_rw(sampling_rate);
 gov_attr_rw(sampling_down_factor);
 gov_attr_rw(up_threshold);
 gov_attr_rw(ignore_nice_load);
-gov_attr_ro(min_sampling_rate);
 gov_attr_rw(down_threshold);
 gov_attr_rw(freq_step);
 
 static struct attribute *cs_attributes[] = {
-   _sampling_rate.attr,
_rate.attr,
_down_factor.attr,
_threshold.attr,
@@ -297,10 +294,7 @@ static int cs_init(struct dbs_data *dbs_data)
dbs_data->up_threshold = DEF_FREQUENCY_UP_THRESHOLD;
dbs_data->sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR;
dbs_data->ignore_nice_load = 0;
-
dbs_data->tuners = tuners;
-   dbs_data->min_sampling_rate = MIN_SAMPLING_RATE_RATIO *
-   jiffies_to_usecs(10);
 
return 0;
 }
diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index 47e24b5384b3..858081f9c3d7 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -47,14 +47,11 @@ ssize_t store_sampling_rate(struct gov_attr_set *attr_set, 
const char *buf,
 {
struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct policy_dbs_info *policy_dbs;
-   unsigned int rate;
int ret;
-   ret = sscanf(buf, "%u", );
+   ret = sscanf(buf, "%u", _data->sampling_rate);
if (ret != 1)
return -EINVAL;
 
-   dbs_data->sampling_rate = max(rate, dbs_data->min_sampling_rate);
-
/*
 * We are operating under dbs_data->mutex and so the list and its
 * entries can't be freed concurrently.
@@ -437,10 +434,7 @@ int cpufreq_dbs_governor_init(struct cpufreq_policy 
*policy)
latency = 1;
 
/* Bring kernel and HW constraints together */
-   dbs_data->min_sampling_rate = max(dbs_data->min_sampling_rate,
- MIN_LATENCY_MULTIPLIER * latency);
-   dbs_data->sampling_rate = max(dbs_data->min_sampling_rate,
- LATENCY_MULTIPLIER * latency);
+   dbs_data->sampling_rate = LATENCY_MULTIPLIER * latency;
 
if (!have_governor_per_policy())
gov->gdbs_data = dbs_data;
diff --git a/drivers/cpufreq/cpufreq_governor.h 
b/drivers/cpufreq/cpufreq_governor.h
index 0236ec2cd654..95f207eb820e 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -41,7 +41,6 @@ enum {OD_NORMAL_SAMPLE, OD_SUB_SAMPLE};
 struct dbs_data {
struct gov_attr_set attr_set;
void *tuners;
-   unsigned int min_

[PATCH V3 0/9] cpufreq: transition-latency cleanups

[Viresh Kumar]

Hi Rafael,

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 dropped as well. And some code consolidation is also done across
governors.

Based of: v4.13-rc1
Tested on: ARM64 Hikey board.

I have pushed it here as well (which gets tested by kbuild test bot):

git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git 
cpufreq/transition-latency

V2->V3:
- Rearranged patches to keep related stuff together
- Introduce CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING flag (Rafael)
- Minor optimization in cpufreq_policy_transition_delay_us() and moved
  it to cpufreq.c (Rafael)
- Allow dynamic switching for drivers which don't know their transition
  latency.

V1->V2:
- While we still get rid of the limitation of 10ms for using
  ondemand/conservative, but we preserve the earlier behavior where the
  transition latency set to CPUFREQ_ETERNAL would not allow use of
  ondemand/conservative governors. Thanks to Dominik for his feedback on
  that.

--
viresh

Viresh Kumar (9):
  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: Don't set transition_latency for setpolicy drivers
  cpufreq: arm_big_little: Make ->get_transition_latency() mandatory
  cpufreq: Replace "max_transition_latency" with "dynamic_switching"
  cpufreq: schedutil: Set dynamic_switching to true
  cpufreq: Add CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING cpufreq driver flag
  cpufreq: Allow dynamic switching with CPUFREQ_ETERNAL latency

 Documentation/admin-guide/pm/cpufreq.rst |  8 
 drivers/cpufreq/arm_big_little.c | 10 --
 drivers/cpufreq/cpufreq-nforce2.c|  2 +-
 drivers/cpufreq/cpufreq.c| 34 
 drivers/cpufreq/cpufreq_conservative.c   |  6 --
 drivers/cpufreq/cpufreq_governor.c   | 17 ++--
 drivers/cpufreq/cpufreq_governor.h   |  3 +--
 drivers/cpufreq/cpufreq_ondemand.c   | 12 ---
 drivers/cpufreq/elanfreq.c   |  4 +---
 drivers/cpufreq/gx-suspmod.c |  2 +-
 drivers/cpufreq/intel_pstate.c   |  1 -
 drivers/cpufreq/longrun.c|  1 -
 drivers/cpufreq/pmac32-cpufreq.c |  7 +--
 drivers/cpufreq/sa1100-cpufreq.c |  5 +++--
 drivers/cpufreq/sa1110-cpufreq.c |  5 +++--
 drivers/cpufreq/sh-cpufreq.c |  3 +--
 drivers/cpufreq/speedstep-smi.c  |  2 +-
 drivers/cpufreq/unicore2-cpufreq.c   |  3 +--
 include/linux/cpufreq.h  | 18 -
 kernel/sched/cpufreq_schedutil.c | 12 ++-
 20 files changed, 65 insertions(+), 90 deletions(-)

-- 
2.13.0.71.gd7076ec9c9cb

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC V2 0/6] cpufreq: transition-latency cleanups

[Viresh Kumar]

Hi Rafael,

Here is the V2 and sending it as RFC this time.

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 dropped as well.

Some code consolidation also done across governors.

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

V1->V2:
- While we still get rid of the limitation of 10ms for using
  ondemand/conservative, but we preserve the earlier behavior where the
  transition latency set to CPUFREQ_ETERNAL would not allow use of
  ondemand/conservative governors. Thanks to Dominik for his feedback on
  that.

--
viresh

Viresh Kumar (6):
  cpufreq: Replace "max_transition_latency" with "dynamic_switching"
  cpufreq: schedutil: Set dynamic_switching to true
  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|  8 +++
 drivers/cpufreq/cpufreq_conservative.c   |  6 --
 drivers/cpufreq/cpufreq_governor.c   | 17 ++-
 drivers/cpufreq/cpufreq_governor.h   |  3 +--
 drivers/cpufreq/cpufreq_ondemand.c   | 12 ---
 include/linux/cpufreq.h  | 36 
 kernel/sched/cpufreq_schedutil.c | 12 ++-
 9 files changed, 40 insertions(+), 72 deletions(-)

-- 
2.13.0.71.gd7076ec9c9cb

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC V2 3/6] cpufreq: governor: Drop min_sampling_rate

[Viresh Kumar]

The cpufreq core and governors aren't supposed to set a limit on how
fast we want to try changing the frequency. This is currently done for
the legacy governors with help of min_sampling_rate.

At worst, we may end up setting the sampling rate to a value lower than
the rate at which frequency can be changed and then one of the CPUs in
the policy will be only changing frequency for ever.

But that is something for the user to decide and there is no need to
have special handling for such cases in the core. Leave it for the user
to figure out.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/admin-guide/pm/cpufreq.rst |  8 
 drivers/cpufreq/cpufreq_conservative.c   |  6 --
 drivers/cpufreq/cpufreq_governor.c   | 10 ++
 drivers/cpufreq/cpufreq_governor.h   |  1 -
 drivers/cpufreq/cpufreq_ondemand.c   | 12 
 include/linux/cpufreq.h  |  2 --
 6 files changed, 2 insertions(+), 37 deletions(-)

diff --git a/Documentation/admin-guide/pm/cpufreq.rst 
b/Documentation/admin-guide/pm/cpufreq.rst
index 463cf7e73db8..2eb3bf62393e 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -471,14 +471,6 @@ it is allowed to use (the ``scaling_max_freq`` policy 
limit).
 
# echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > 
ondemand/sampling_rate
 
-
-``min_sampling_rate``
-   The minimum value of ``sampling_rate``.
-
-   Equal to 1 (10 ms) if :c:macro:`CONFIG_NO_HZ_COMMON` and
-   :c:data:`tick_nohz_active` are both set or to 20 times the value of
-   :c:data:`jiffies` in microseconds otherwise.
-
 ``up_threshold``
If the estimated CPU load is above this value (in percent), the governor
will set the frequency to the maximum value allowed for the policy.
diff --git a/drivers/cpufreq/cpufreq_conservative.c 
b/drivers/cpufreq/cpufreq_conservative.c
index 88220ff3e1c2..f20f20a77d4d 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -246,7 +246,6 @@ gov_show_one_common(sampling_rate);
 gov_show_one_common(sampling_down_factor);
 gov_show_one_common(up_threshold);
 gov_show_one_common(ignore_nice_load);
-gov_show_one_common(min_sampling_rate);
 gov_show_one(cs, down_threshold);
 gov_show_one(cs, freq_step);
 
@@ -254,12 +253,10 @@ gov_attr_rw(sampling_rate);
 gov_attr_rw(sampling_down_factor);
 gov_attr_rw(up_threshold);
 gov_attr_rw(ignore_nice_load);
-gov_attr_ro(min_sampling_rate);
 gov_attr_rw(down_threshold);
 gov_attr_rw(freq_step);
 
 static struct attribute *cs_attributes[] = {
-   _sampling_rate.attr,
_rate.attr,
_down_factor.attr,
_threshold.attr,
@@ -297,10 +294,7 @@ static int cs_init(struct dbs_data *dbs_data)
dbs_data->up_threshold = DEF_FREQUENCY_UP_THRESHOLD;
dbs_data->sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR;
dbs_data->ignore_nice_load = 0;
-
dbs_data->tuners = tuners;
-   dbs_data->min_sampling_rate = MIN_SAMPLING_RATE_RATIO *
-   jiffies_to_usecs(10);
 
return 0;
 }
diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index 47e24b5384b3..858081f9c3d7 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -47,14 +47,11 @@ ssize_t store_sampling_rate(struct gov_attr_set *attr_set, 
const char *buf,
 {
struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct policy_dbs_info *policy_dbs;
-   unsigned int rate;
int ret;
-   ret = sscanf(buf, "%u", );
+   ret = sscanf(buf, "%u", _data->sampling_rate);
if (ret != 1)
return -EINVAL;
 
-   dbs_data->sampling_rate = max(rate, dbs_data->min_sampling_rate);
-
/*
 * We are operating under dbs_data->mutex and so the list and its
 * entries can't be freed concurrently.
@@ -437,10 +434,7 @@ int cpufreq_dbs_governor_init(struct cpufreq_policy 
*policy)
latency = 1;
 
/* Bring kernel and HW constraints together */
-   dbs_data->min_sampling_rate = max(dbs_data->min_sampling_rate,
- MIN_LATENCY_MULTIPLIER * latency);
-   dbs_data->sampling_rate = max(dbs_data->min_sampling_rate,
- LATENCY_MULTIPLIER * latency);
+   dbs_data->sampling_rate = LATENCY_MULTIPLIER * latency;
 
if (!have_governor_per_policy())
gov->gdbs_data = dbs_data;
diff --git a/drivers/cpufreq/cpufreq_governor.h 
b/drivers/cpufreq/cpufreq_governor.h
index 7b7839c45fba..8463f5def0f5 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -41,7 +41,6 @@ enum {OD_NORMAL_SAMPLE, OD_SUB_SAMPLE};
 struct dbs_data {
struct gov_attr_set attr_set;
void *tuners;
-   unsigned int min_

[RFC v2 3/6] drivers: boot_constraint: Add boot_constraints_disable kernel parameter

[Viresh Kumar]

Users must be given an option to discard any constraints set by
bootloaders. For example, consider that a constraint is set for the LCD
controller's supply and the LCD driver isn't loaded by the kernel. If
the user doesn't need to use the LCD device, then he shouldn't be forced
to honour the constraint.

We can also think about finer control of such constraints with help of
some sysfs files, but a kernel parameter is fine to begin with.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 drivers/base/boot_constraint.c  | 17 +
 2 files changed, 20 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 7737ab5d04b2..59ad24822d10 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -426,6 +426,9 @@
embedded devices based on command line input.
See Documentation/block/cmdline-partition.txt
 
+   boot_constraints_disable
+   Do not set any boot constraints for devices.
+
boot_delay= Milliseconds to delay each printk during boot.
Values larger than 10 seconds (1) are changed to
no delay (0).
diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
index 4e4332751c5f..d372ddfe1264 100644
--- a/drivers/base/boot_constraint.c
+++ b/drivers/base/boot_constraint.c
@@ -47,6 +47,17 @@ static DEFINE_MUTEX(constraint_devices_mutex);
 static int constraint_supply_add(struct constraint *constraint, void *data);
 static void constraint_supply_remove(struct constraint *constraint);
 
+static bool boot_constraints_disabled;
+
+static int __init constraints_disable(char *str)
+{
+   boot_constraints_disabled = true;
+   pr_debug("disabled\n");
+
+   return 0;
+}
+early_param("boot_constraints_disable", constraints_disable);
+
 
 /* Boot constraints core */
 
@@ -154,6 +165,9 @@ int boot_constraint_add(struct device *dev, enum 
boot_constraint_type type,
struct constraint *constraint;
int ret;
 
+   if (boot_constraints_disabled)
+   return -ENODEV;
+
mutex_lock(_devices_mutex);
 
/* Find or add the cdev type first */
@@ -211,6 +225,9 @@ void boot_constraints_remove(struct device *dev)
struct constraint_dev *cdev;
struct constraint *constraint, *temp;
 
+   if (boot_constraints_disabled)
+   return;
+
mutex_lock(_devices_mutex);
 
cdev = constraint_device_find(dev);
-- 
2.13.0.71.gd7076ec9c9cb

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

[Viresh Kumar]

On 30-06-17, 06:53, Dominik Brodowski wrote:
> On Fri, Jun 30, 2017 at 09:04:25AM +0530, Viresh Kumar wrote:
> > On 29-06-17, 20:01, Dominik Brodowski wrote:
> > > On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote:
> > > > The cpufreq core and governors aren't supposed to set a limit on how
> > > > fast we want to try changing the frequency. This is currently done for
> > > > the legacy governors with help of min_sampling_rate.
> > > > 
> > > > At worst, we may end up setting the sampling rate to a value lower than
> > > > the rate at which frequency can be changed and then one of the CPUs in
> > > > the policy will be only changing frequency for ever.
> > > 
> > > Is it safe to issue requests to change the CPU frequency so frequently,
> > 
> > Well, I assumed so. I am not sure the hardware would break though.
> > Overheating ?
> > 
> > > even
> > > on historic hardware such as speedstep-{ich,smi,centrino}? In the past,

speedstep-smi is the only one which sets transition_latency to
CPUFREQ_ETERNAL and the others are putting some meaningful values. So
yes, they should be doing DVFS dynamically.

> > > these checks more or less disallowed the running of dynamic frequency
> > > scaling at least on speedstep-smi[*],
> > 
> > We must by doing dynamic freq scaling even without this patch. I don't
> > see why you say the above then.
> > 
> > All we do here is that we get rid of the limit on how soon we can
> > change the freq again.
> 
> Well, as I understand it, first generation "speedstep" was designed more or
> less to switch frequencies only when AC power was lost or restored.
> 
> The Linux implementation merely said: "no on-the-fly changes", but switch
> frequencies whenever a user explicitly requested such a change (presumably
> only every once in an unspecified while).
> 
> This same reasoning may be present in other drivers using CPUFREQ_ETERNAL.

Thanks for the explanation here and I am convinced that this series
has at least done one thing wrong. And that is removal of
max_transition_latency from governors and allowing ondemand to run on
such platforms (which may end up breaking them).

So I will actually modify that patch and set max_transition_latency to
CPUFREQ_ETERNAL for ondemand/conservative instead of 10ms. Also we
should do the same for schedutil as well, so that will also use the
max_transition_latency field.

But I hope, this patch will still be fine. Right ?

> I am not *sure* either, I am just worried of the consequences of doing
> things out-of-spec...

Thanks for your inputs Dominik.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

[Viresh Kumar]

On 29-06-17, 20:01, Dominik Brodowski wrote:
> On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote:
> > The cpufreq core and governors aren't supposed to set a limit on how
> > fast we want to try changing the frequency. This is currently done for
> > the legacy governors with help of min_sampling_rate.
> > 
> > At worst, we may end up setting the sampling rate to a value lower than
> > the rate at which frequency can be changed and then one of the CPUs in
> > the policy will be only changing frequency for ever.
> 
> Is it safe to issue requests to change the CPU frequency so frequently,

Well, I assumed so. I am not sure the hardware would break though.
Overheating ?

> even
> on historic hardware such as speedstep-{ich,smi,centrino}? In the past,
> these checks more or less disallowed the running of dynamic frequency
> scaling at least on speedstep-smi[*],

We must by doing dynamic freq scaling even without this patch. I don't
see why you say the above then.

All we do here is that we get rid of the limit on how soon we can
change the freq again.

> but maybe on a few other platforms as
> well. That's why I am curious on whether this may break systems potentially
> on a hardware level if the hardware was not designed to do dynamic frequency
> scaling (and not just frequency switches on battery/AC).

Honestly I am not sure if any hardware can break or not, just because
of this commit.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

[Viresh Kumar]

The cpufreq core and governors aren't supposed to set a limit on how
fast we want to try changing the frequency. This is currently done for
the legacy governors with help of min_sampling_rate.

At worst, we may end up setting the sampling rate to a value lower than
the rate at which frequency can be changed and then one of the CPUs in
the policy will be only changing frequency for ever.

But that is something for the user to decide and there is no need to
have special handling for such cases in the core. Leave it for the user
to figure out.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/admin-guide/pm/cpufreq.rst |  8 
 drivers/cpufreq/cpufreq_conservative.c   |  6 --
 drivers/cpufreq/cpufreq_governor.c   | 10 ++
 drivers/cpufreq/cpufreq_governor.h   |  1 -
 drivers/cpufreq/cpufreq_ondemand.c   | 12 
 include/linux/cpufreq.h  |  2 --
 6 files changed, 2 insertions(+), 37 deletions(-)

diff --git a/Documentation/admin-guide/pm/cpufreq.rst 
b/Documentation/admin-guide/pm/cpufreq.rst
index 09aa2e949787..6adbe1ed58b9 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -471,14 +471,6 @@ it is allowed to use (the ``scaling_max_freq`` policy 
limit).
 
# echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > 
ondemand/sampling_rate
 
-
-``min_sampling_rate``
-   The minimum value of ``sampling_rate``.
-
-   Equal to 1 (10 ms) if :c:macro:`CONFIG_NO_HZ_COMMON` and
-   :c:data:`tick_nohz_active` are both set or to 20 times the value of
-   :c:data:`jiffies` in microseconds otherwise.
-
 ``up_threshold``
If the estimated CPU load is above this value (in percent), the governor
will set the frequency to the maximum value allowed for the policy.
diff --git a/drivers/cpufreq/cpufreq_conservative.c 
b/drivers/cpufreq/cpufreq_conservative.c
index 88220ff3e1c2..f20f20a77d4d 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -246,7 +246,6 @@ gov_show_one_common(sampling_rate);
 gov_show_one_common(sampling_down_factor);
 gov_show_one_common(up_threshold);
 gov_show_one_common(ignore_nice_load);
-gov_show_one_common(min_sampling_rate);
 gov_show_one(cs, down_threshold);
 gov_show_one(cs, freq_step);
 
@@ -254,12 +253,10 @@ gov_attr_rw(sampling_rate);
 gov_attr_rw(sampling_down_factor);
 gov_attr_rw(up_threshold);
 gov_attr_rw(ignore_nice_load);
-gov_attr_ro(min_sampling_rate);
 gov_attr_rw(down_threshold);
 gov_attr_rw(freq_step);
 
 static struct attribute *cs_attributes[] = {
-   _sampling_rate.attr,
_rate.attr,
_down_factor.attr,
_threshold.attr,
@@ -297,10 +294,7 @@ static int cs_init(struct dbs_data *dbs_data)
dbs_data->up_threshold = DEF_FREQUENCY_UP_THRESHOLD;
dbs_data->sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR;
dbs_data->ignore_nice_load = 0;
-
dbs_data->tuners = tuners;
-   dbs_data->min_sampling_rate = MIN_SAMPLING_RATE_RATIO *
-   jiffies_to_usecs(10);
 
return 0;
 }
diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index 47e24b5384b3..858081f9c3d7 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -47,14 +47,11 @@ ssize_t store_sampling_rate(struct gov_attr_set *attr_set, 
const char *buf,
 {
struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct policy_dbs_info *policy_dbs;
-   unsigned int rate;
int ret;
-   ret = sscanf(buf, "%u", );
+   ret = sscanf(buf, "%u", _data->sampling_rate);
if (ret != 1)
return -EINVAL;
 
-   dbs_data->sampling_rate = max(rate, dbs_data->min_sampling_rate);
-
/*
 * We are operating under dbs_data->mutex and so the list and its
 * entries can't be freed concurrently.
@@ -437,10 +434,7 @@ int cpufreq_dbs_governor_init(struct cpufreq_policy 
*policy)
latency = 1;
 
/* Bring kernel and HW constraints together */
-   dbs_data->min_sampling_rate = max(dbs_data->min_sampling_rate,
- MIN_LATENCY_MULTIPLIER * latency);
-   dbs_data->sampling_rate = max(dbs_data->min_sampling_rate,
- LATENCY_MULTIPLIER * latency);
+   dbs_data->sampling_rate = LATENCY_MULTIPLIER * latency;
 
if (!have_governor_per_policy())
gov->gdbs_data = dbs_data;
diff --git a/drivers/cpufreq/cpufreq_governor.h 
b/drivers/cpufreq/cpufreq_governor.h
index 7cbb07512e4c..06d9f90ede93 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -41,7 +41,6 @@ enum {OD_NORMAL_SAMPLE, OD_SUB_SAMPLE};
 struct dbs_data {
struct gov_attr_set attr_set;
void *tuners;
-   unsigned int min_

[RFC 3/5] drivers: boot_constraint: Add boot_constraints_disable kernel parameter

[Viresh Kumar]

Users must be given an option to discard any constraints set by
bootloaders. For example, consider that a constraint is set for the LCD
controller's supply and the LCD driver isn't loaded by the kernel. If
the user doesn't need to use the LCD device, then he shouldn't be forced
to honour the constraint.

We can also think about finer control of such constraints with help of
some sysfs files, but a kernel parameter is fine to begin with.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  2 ++
 drivers/base/boot_constraint.c  | 17 +
 2 files changed, 19 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 7737ab5d04b2..35e8a298bfc1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -426,6 +426,8 @@
embedded devices based on command line input.
See Documentation/block/cmdline-partition.txt
 
+   boot_constraints_disable = Do not set any boot constraints for devices.
+
boot_delay= Milliseconds to delay each printk during boot.
Values larger than 10 seconds (1) are changed to
no delay (0).
diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
index 495344e6405b..ab766d60191a 100644
--- a/drivers/base/boot_constraint.c
+++ b/drivers/base/boot_constraint.c
@@ -45,6 +45,17 @@ static DEFINE_MUTEX(constraint_devices_mutex);
 static int constraint_supply_add(struct constraint *constraint, void *data);
 static void constraint_supply_remove(struct constraint *constraint);
 
+static bool constraints_disabled;
+
+static int __init constraints_disable(char *str)
+{
+   constraints_disabled = true;
+   pr_debug("disabled\n");
+
+   return 0;
+}
+early_param("boot_constraints_disable", constraints_disable);
+
 
 /* Boot constraints core */
 
@@ -152,6 +163,9 @@ int boot_constraint_add(struct device *dev, enum 
boot_constraint_type type,
struct constraint *constraint;
int ret;
 
+   if (constraints_disabled)
+   return -ENODEV;
+
mutex_lock(_devices_mutex);
 
/* Find or add the cdev type first */
@@ -202,6 +216,9 @@ void boot_constraints_remove(struct device *dev)
struct constraint_dev *cdev;
struct constraint *constraint, *temp;
 
+   if (constraints_disabled)
+   return;
+
mutex_lock(_devices_mutex);
 
cdev = constraint_device_find(dev);
-- 
2.13.0.71.gd7076ec9c9cb

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] cpufreq: User/admin documentation update and consolidation

[Viresh Kumar]

On 20-02-17, 14:58, Rafael J. Wysocki wrote:
> Yes, it is called for new and inactive policies.
> 
> For new policies it has to populate policy->cpus (because otherwise the core
> doesn't know what CPUs should be there), which quite arguably doesn't have
> to (or even doesn't need to) be done for inactive policies (because they 
> already
> have policy->real_cpus and policy->related_cpus populated).
 
> I would even argue that ->init() should not update policy->cpus for inactive
> (but not new) policies.

I agree, but I am not aware of any platforms that we have today which
does any similar checks in ->init(). And I wouldn't encourage drivers
to have such special handling at all. Why make it complex?

The way you have written it earlier suggests that the drivers should
check if the policy is active or not (by looking at related_cpus mask)
and set the cpus mask only for new policies. I was just worried that
new driver authors will actually try to write special code in init()
for that and if we really want that to be the case.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] cpufreq: User/admin documentation update and consolidation

[Viresh Kumar]

On 18-02-17, 02:36, Rafael J. Wysocki wrote:
> +CPU Initialization
> +==
> +


> +Next, the scaling driver's ``->init()`` callback is invoked with the policy
> +pointer of the new CPU passed to it as the argument.  If the policy object
> +pointed to by it is new

The callbacks don't need to do anything special for a new policy.
Infact, ->init() is only called for new policies or policies which
don't have any active CPUs as of now.

> , that callback is expected to initialize the performance
> +scaling hardware interface for the given CPU (or, more precisely, for the 
> set of
> +CPUs sharing the hardware interface it belongs to, represented by its policy
> +object) and to set parameters of the policy, like the minimum and maximum
> +frequencies supported by the hardware, the table of available frequencies (if
> +the set of supported P-states is not a continuous range), and the mask of 
> CPUs
> +that belong to the same policy.

Maybe we should explicitly mention that both online and offline CPUs
should be set in the mask ?

> That mask is then used by the core to populate
> +the policy pointers for all of the CPUs in it.
> +
> +The next major initialization step for a new policy object is to attach a
> +scaling governor to it (to begin with, that is the default scaling governor
> +determined by the kernel configuration, but it may be changed later
> +via ``sysfs``).  First, a pointer to the new policy object is passed to the
> +governor's ``->init()`` callback which is expected to initialize all of the
> +data structures necessary to handle the given policy and, possibly, to add
> +a governor ``sysfs`` interface to it.  Next, the governor is started by
> +invoking its ``->start()`` callback.

The rest of it looked good. Nice work Rafael :)

Acked-by: Viresh Kumar <viresh.ku...@linaro.org>

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] cpufreq: Documentation: Minor reformatting

[Viresh Kumar]

This patch doesn't change the content of the documentation, but rather
reformat it to make it more readable.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/cpu-freq/governors.txt | 205 +++
 1 file changed, 112 insertions(+), 93 deletions(-)

diff --git a/Documentation/cpu-freq/governors.txt 
b/Documentation/cpu-freq/governors.txt
index c15aa75f5227..63eef4cca1b7 100644
--- a/Documentation/cpu-freq/governors.txt
+++ b/Documentation/cpu-freq/governors.txt
@@ -111,82 +111,96 @@ directory.
 
 The CPUfreq governor "ondemand" sets the CPU depending on the
 current usage. To do this the CPU must have the capability to
-switch the frequency very quickly.  There are a number of sysfs file
-accessible parameters:
-
-sampling_rate: measured in uS (10^-6 seconds), this is how often you
-want the kernel to look at the CPU usage and to make decisions on
-what to do about the frequency.  Typically this is set to values of
-around '1' or more. It's default value is (cmp. with users-guide.txt):
-transition_latency * 1000
-Be aware that transition latency is in ns and sampling_rate is in us, so you
-get the same sysfs value by default.
-Sampling rate should always get adjusted considering the transition latency
-To set the sampling rate 750 times as high as the transition latency
-in the bash (as said, 1000 is default), do:
-echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \
->ondemand/sampling_rate
-
-sampling_rate_min:
-The sampling rate is limited by the HW transition latency:
-transition_latency * 100
-Or by kernel restrictions:
-If CONFIG_NO_HZ_COMMON is set, the limit is 10ms fixed.
-If CONFIG_NO_HZ_COMMON is not set or nohz=off boot parameter is used, the
-limits depend on the CONFIG_HZ option:
-HZ=1000: min=2us  (20ms)
-HZ=250:  min=8us  (80ms)
-HZ=100:  min=20us (200ms)
-The highest value of kernel and HW latency restrictions is shown and
-used as the minimum sampling rate.
-
-up_threshold: defines what the average CPU usage between the samplings
-of 'sampling_rate' needs to be for the kernel to make a decision on
-whether it should increase the frequency.  For example when it is set
-to its default value of '95' it means that between the checking
-intervals the CPU needs to be on average more than 95% in use to then
-decide that the CPU frequency needs to be increased.  
-
-ignore_nice_load: this parameter takes a value of '0' or '1'. When
-set to '0' (its default), all processes are counted towards the
-'cpu utilisation' value.  When set to '1', the processes that are
-run with a 'nice' value will not count (and thus be ignored) in the
-overall usage calculation.  This is useful if you are running a CPU
-intensive calculation on your laptop that you do not care how long it
-takes to complete as you can 'nice' it and prevent it from taking part
-in the deciding process of whether to increase your CPU frequency.
-
-sampling_down_factor: this parameter controls the rate at which the
-kernel makes a decision on when to decrease the frequency while running
-at top speed. When set to 1 (the default) decisions to reevaluate load
-are made at the same interval regardless of current clock speed. But
-when set to greater than 1 (e.g. 100) it acts as a multiplier for the
-scheduling interval for reevaluating load when the CPU is at its top
-speed due to high load. This improves performance by reducing the overhead
-of load evaluation and helping the CPU stay at its top speed when truly
-busy, rather than shifting back and forth in speed. This tunable has no
-effect on behavior at lower speeds/lower CPU loads.
-
-powersave_bias: this parameter takes a value between 0 to 1000. It
-defines the percentage (times 10) value of the target frequency that
-will be shaved off of the target. For example, when set to 100 -- 10%,
-when ondemand governor would have targeted 1000 MHz, it will target
-1000 MHz - (10% of 1000 MHz) = 900 MHz instead. This is set to 0
-(disabled) by default.
-When AMD frequency sensitivity powersave bias driver --
-drivers/cpufreq/amd_freq_sensitivity.c is loaded, this parameter
-defines the workload frequency sensitivity threshold in which a lower
-frequency is chosen instead of ondemand governor's original target.
-The frequency sensitivity is a hardware reported (on AMD Family 16h
-Processors and above) value between 0 to 100% that tells software how
-the performance of the workload running on a CPU will change when
-frequency changes. A workload with sensitivity of 0% (memory/IO-bound)
-will not perform any better on higher core frequency, whereas a
-workload with sensitivity of 100% (CPU-bound) will perform better
-higher the frequency. When the driver is loaded, this is set to 400
-by default -- for CPUs running workloads with sensitivity value below
-40%, a lower frequency is chosen. Unloading the driver or writing 0
-will disable this feature.
+switch the frequency very quickly.
+
+Sysfs files:

Re: [PATCH] Documentation: cpufreq: Update supported powernv processors

[Viresh Kumar]

On 16-12-16, 16:47, Shilpasri G Bhat wrote:
> Signed-off-by: Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com>
> ---
>  Documentation/cpu-freq/user-guide.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/cpu-freq/user-guide.txt 
> b/Documentation/cpu-freq/user-guide.txt
> index 109e97b..5e10d5f 100644
> --- a/Documentation/cpu-freq/user-guide.txt
> +++ b/Documentation/cpu-freq/user-guide.txt
> @@ -87,7 +87,9 @@ UltraSPARC-III
>  ---
>  
>  Several "PowerBook" and "iBook2" notebooks are supported.
> -
> +The following POWER processors are supported in powernv mode:
> +POWER8
> +POWER9
>  
>  1.5 SuperH
>  --

Acked-by: Viresh Kumar <viresh.ku...@linaro.org>

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2 1/8] sched/tune: add detailed documentation

[Viresh Kumar]

On 27-10-16, 18:41, Patrick Bellasi wrote:
> +This last requirement is especially important if we consider that schedutil 
> can
> +potentially replace all currently available CPUFreq policies. Since schedutil
> +is event based, as opposed to the sampling driven governors, it is already 
> more
> +responsive at selecting the optimal OPP to run tasks allocated to a CPU.

I am not sure if I follow this paragraph. All the governors follow the same
basic rules now. They are all event driven (events from scheduler), but they
function only after a certain sampling period is finished. Isn't this the case ?

> +SchedTune exposes a simple user-space interface with a single 
> power-performance
> +tunable:
> +
> +  /proc/sys/kernel/sched_cfs_boost
> +
> +This permits expressing a boost value as an integer in the range [0..100].
> +
> +A value of 0 (default) for a CFS task means that schedutil will attempt
> +to match compute capacity of the CPU where the task is scheduled to
> +match its current utilization with a few spare cycles left. A value of
> +100 means that schedutil will select the highest available OPP.
> +
> +The range between 0 and 100 can be set to satisfy other scenarios suitably.
> +For example to satisfy interactive response or depending on other system 
> events
> +(battery level, thermal status, etc).

Earlier section said that schedutil+schedtune can replace all earlier governors.
How will schedutil behave like powersave governor with schedtune? I was
expecting the possible values of sched_cfs_boost to be in the range -100 to 100,
where -100 will make it powersave, +100 will make it performance and 0 will not
make any changes.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 2/2] cpufreq: Add android's 'interactive' governor

[Viresh Kumar]

Interactive governor has lived in Android sources for a very long time
and this commit is based on the code present in following branch:

https://android.googlesource.com/kernel/common android-4.4

The Interactive governor is designed for latency-sensitive workloads,
such as interactive user interfaces like the mobile phones and tablets.
The interactive governor aims to be significantly more responsive to
ramp CPU quickly up when CPU-intensive activity begins.

Existing governors sample CPU load at a particular rate, typically every
X ms and then update the frequency from a work-handler.  This can lead
to under-powering UI threads for the period of time during which the
user begins interacting with a previously-idle system until the next
sample period happens.

The 'interactive' governor uses a different approach.

A real-time thread is used for scaling up, giving the remaining tasks
the CPU performance benefit, unlike existing governors which are more
likely to schedule ramp-up work to occur after your performance starved
tasks have completed.

The Android version of interactive governor also checks whether to scale
the CPU frequency up soon after coming out of idle.  When the CPU comes
out of idle, the governor check if the CPU sampling is overdue or not.
If yes, it immediately starts the sampling.  Otherwise, the utilization
hooks from the scheduler handle the sampling later.  If the CPU is very
busy from exiting idle to when the evaluation happens, then it assumes
that the CPU is under-powered and ramps it to MAX speed.

If the CPU was not sufficiently busy to immediately ramp to MAX speed,
then the governor evaluates the CPU load since the last speed
adjustment, choosing the highest value between that longer-term load or
the short-term load since idle exit to determine the CPU speed to ramp
to.

Idle notifiers will be be handled later and are not included for now.

The core of this code is written and maintained (in Android
repositories) by Mike Chan and Todd Poyner over a long period of time.

Vireshk has made changes to to the governor to align it with the current
practices followed with mainline governors, like using utilization hooks
from the scheduler and handling kobject (for governor's sysfs directory)
in a race free manner. And of course this included general cleanup of
the governor as well.

Signed-off-by: Mike Chan <m...@android.com>
Signed-off-by: Todd Poynor <toddpoy...@google.com>
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/cpu-freq/governors.txt   |   86 ++
 drivers/cpufreq/Kconfig|   30 +
 drivers/cpufreq/Makefile   |1 +
 drivers/cpufreq/cpufreq_interactive.c  | 1363 
 include/trace/events/cpufreq_interactive.h |  112 +++
 5 files changed, 1592 insertions(+)
 create mode 100644 drivers/cpufreq/cpufreq_interactive.c
 create mode 100644 include/trace/events/cpufreq_interactive.h

diff --git a/Documentation/cpu-freq/governors.txt 
b/Documentation/cpu-freq/governors.txt
index c15aa75f5227..0cf9a6bff6a5 100644
--- a/Documentation/cpu-freq/governors.txt
+++ b/Documentation/cpu-freq/governors.txt
@@ -28,6 +28,7 @@
 2.3  Userspace
 2.4  Ondemand
 2.5  Conservative
+2.6  Interactive
 
 3.   The Governor Interface in the CPUfreq Core
 
@@ -218,6 +219,91 @@ a decision on when to decrease the frequency while running 
in any
 speed. Load for frequency increase is still evaluated every
 sampling rate.
 
+2.6 Interactive
+---
+
+The CPUfreq governor "interactive" is designed for latency-sensitive,
+interactive workloads. This governor sets the CPU speed depending on
+usage, similar to "ondemand" and "conservative" governors, but with a
+different set of configurable behaviors.
+
+The tunable values for this governor are:
+
+above_hispeed_delay: When speed is at or above hispeed_freq, wait for
+this long before raising speed in response to continued high load.
+The format is a single delay value, optionally followed by pairs of
+CPU speeds and the delay to use at or above those speeds.  Colons can
+be used between the speeds and associated delays for readability.  For
+example:
+
+   8 130:20 150:4
+
+uses delay 8 uS until CPU speed 1.3 GHz, at which speed delay
+20 uS is used until speed 1.5 GHz, at which speed (and above)
+delay 4 uS is used.  If speeds are specified these must appear in
+ascending order.  Default is 2 uS.
+
+boost: If non-zero, immediately boost speed of all CPUs to at least
+hispeed_freq until zero is written to this attribute.  If zero, allow
+CPU speeds to drop below hispeed_freq according to load as usual.
+Default is zero.
+
+boostpulse: On each write, immediately boost speed of all CPUs to
+hispeed_freq for at least the period of time specified by
+boostpulse_duration, after which speeds are allowed to drop below
+hispeed_freq according to load as usual. Its a write-only file

Re: [PATCH] cpufreq-stats: Minor documentation fix

[Viresh Kumar]

On 09-09-16, 13:03, Jean Delvare wrote:
> On Fri, 9 Sep 2016 00:38:59 +0200, Rafael J. Wysocki wrote:
> > On 9/8/2016 1:20 PM, Viresh Kumar wrote:
> > > On 08-09-16, 12:39, Jean Delvare wrote:
> > >> The cpufreq-stats code can no longer be built as a module, so it now
> > >> appears with square brackets in menuconfig.
> > >>
> > >> Signed-off-by: Jean Delvare <jdelv...@suse.de>
> > >> Fixes: 1aefc75b2449 ("cpufreq: stats: Make the stats code non-modular")
> > >> Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > >> Cc: Viresh Kumar <viresh.ku...@linaro.org>
> > >> ---
> > >>   Documentation/cpu-freq/cpufreq-stats.txt |2 +-
> > >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> --- linux-4.8-rc5.orig/Documentation/cpu-freq/cpufreq-stats.txt  
> > >> 2016-09-04 23:31:46.0 +0200
> > >> +++ linux-4.8-rc5/Documentation/cpu-freq/cpufreq-stats.txt   
> > >> 2016-09-08 11:34:34.805606601 +0200
> > >> @@ -103,7 +103,7 @@ Config Main Menu
> > >>  Power management options (ACPI, APM)  --->
> > >>  CPU Frequency scaling  --->
> > >>  [*] CPU Frequency scaling
> > >> -<*>   CPU frequency translation statistics
> > >> +[*]   CPU frequency translation statistics
> > >>  [*] CPU frequency translation statistics 
> > >> details
> > > Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
> > >
> > Applied, but please CC PM material to linux-pm too.  That makes it much 
> > easier to handle.
> 
> OK. MAINTAINERS didn't tell me so, I'll send an update in a minute.

You sure about it?

CPU FREQUENCY DRIVERS
M:  "Rafael J. Wysocki" <r...@rjwysocki.net>
M:  Viresh Kumar <viresh.ku...@linaro.org>
L:  linux...@vger.kernel.org
S:  Maintained
T:  git
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
T:  git git://git.linaro.org/people/vireshk/linux.git (For ARM
Updates)
F:  drivers/cpufreq/
F:  include/linux/cpufreq.h

Also, its already applied. Don't resend it.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 7/8] cpufreq: Return index from cpufreq_frequency_table_target()

[Viresh Kumar]

This routine can't fail unless the frequency table is invalid and
doesn't contain any valid entries.

Make it return the index and WARN() in case it is used for an invalid
table.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/cpu-freq/cpu-drivers.txt |  7 +++
 drivers/cpufreq/amd_freq_sensitivity.c |  4 ++--
 drivers/cpufreq/cpufreq.c  |  9 ++---
 drivers/cpufreq/cpufreq_ondemand.c | 14 ++
 drivers/cpufreq/freq_table.c   | 24 +---
 drivers/cpufreq/powernv-cpufreq.c  |  4 ++--
 drivers/cpufreq/s3c24xx-cpufreq.c  | 26 ++
 drivers/cpufreq/s5pv210-cpufreq.c  |  7 ++-
 include/linux/cpufreq.h|  3 +--
 9 files changed, 37 insertions(+), 61 deletions(-)

diff --git a/Documentation/cpu-freq/cpu-drivers.txt 
b/Documentation/cpu-freq/cpu-drivers.txt
index 74e812f0719c..772b94fde264 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -245,12 +245,11 @@ policy->max, and all other criteria are met. This is 
helpful for the
 
 int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
unsigned int target_freq,
-   unsigned int relation,
-   unsigned int *index);
+   unsigned int relation);
 
 is the corresponding frequency table helper for the ->target
-stage. Just pass the values to this function, and the unsigned int
-index returns the number of the frequency table entry which contains
+stage. Just pass the values to this function, and this function
+returns the number of the frequency table entry which contains
 the frequency the CPU shall be set to.
 
 The following macros can be used as iterators over cpufreq_frequency_table:
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
b/drivers/cpufreq/amd_freq_sensitivity.c
index 3bea1bb791a9..6d5dc04c3a37 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -91,8 +91,8 @@ static unsigned int amd_powersave_bias_target(struct 
cpufreq_policy *policy,
else {
unsigned int index;
 
-   cpufreq_frequency_table_target(policy,
-   policy->cur - 1, CPUFREQ_RELATION_H, );
+   index = cpufreq_frequency_table_target(policy,
+   policy->cur - 1, CPUFREQ_RELATION_H);
freq_next = policy->freq_table[index].frequency;
}
 
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 30f05dd5c872..9ae58a18ccb9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1914,7 +1914,7 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int relation)
 {
unsigned int old_target_freq = target_freq;
-   int index, retval;
+   int index;
 
if (cpufreq_disabled())
return -ENODEV;
@@ -1943,12 +1943,7 @@ int __cpufreq_driver_target(struct cpufreq_policy 
*policy,
if (!cpufreq_driver->target_index)
return -EINVAL;
 
-   retval = cpufreq_frequency_table_target(policy, target_freq, relation,
-   );
-   if (unlikely(retval)) {
-   pr_err("%s: Unable to find matching freq\n", __func__);
-   return retval;
-   }
+   index = cpufreq_frequency_table_target(policy, target_freq, relation);
 
return __target_index(policy, index);
 }
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 2ee476f5a2bd..0c93cd9dee99 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -65,7 +65,7 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
 {
unsigned int freq_req, freq_reduc, freq_avg;
unsigned int freq_hi, freq_lo;
-   unsigned int index = 0;
+   unsigned int index;
unsigned int delay_hi_us;
struct policy_dbs_info *policy_dbs = policy->governor_data;
struct od_policy_dbs_info *dbs_info = to_dbs_info(policy_dbs);
@@ -79,19 +79,17 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
return freq_next;
}
 
-   cpufreq_frequency_table_target(policy, freq_next, relation, );
+   index = cpufreq_frequency_table_target(policy, freq_next, relation);
freq_req = freq_table[index].frequency;
freq_reduc = freq_req * od_tuners->powersave_bias / 1000;
freq_avg = freq_req - freq_reduc;
 
/* Find freq bounds for freq_avg in freq_table */
-   index = 0;
-   cpufreq_frequency_table_target(policy, freq_avg, CPUFREQ_RELATION_H,
-  

[PATCH V3 5/8] cpufreq: Drop freq-table param to cpufreq_frequency_table_target()

[Viresh Kumar]

The policy already has this pointer set, use it instead.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/cpu-freq/cpu-drivers.txt |  1 -
 drivers/cpufreq/amd_freq_sensitivity.c |  3 +--
 drivers/cpufreq/cpufreq.c  |  4 ++--
 drivers/cpufreq/cpufreq_ondemand.c | 11 +--
 drivers/cpufreq/freq_table.c   |  2 +-
 drivers/cpufreq/powernv-cpufreq.c  |  3 +--
 drivers/cpufreq/s3c24xx-cpufreq.c  | 11 +--
 drivers/cpufreq/s5pv210-cpufreq.c  |  3 +--
 include/linux/cpufreq.h|  1 -
 9 files changed, 16 insertions(+), 23 deletions(-)

diff --git a/Documentation/cpu-freq/cpu-drivers.txt 
b/Documentation/cpu-freq/cpu-drivers.txt
index decbb8cb5573..74e812f0719c 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -244,7 +244,6 @@ policy->max, and all other criteria are met. This is 
helpful for the
 ->verify call.
 
 int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
-   struct cpufreq_frequency_table *table,
unsigned int target_freq,
unsigned int relation,
unsigned int *index);
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
b/drivers/cpufreq/amd_freq_sensitivity.c
index bc86816693a8..3bea1bb791a9 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -92,8 +92,7 @@ static unsigned int amd_powersave_bias_target(struct 
cpufreq_policy *policy,
unsigned int index;
 
cpufreq_frequency_table_target(policy,
-   policy->freq_table, policy->cur - 1,
-   CPUFREQ_RELATION_H, );
+   policy->cur - 1, CPUFREQ_RELATION_H, );
freq_next = policy->freq_table[index].frequency;
}
 
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 1833eda1f9d4..e68611a67bd9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1947,8 +1947,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
return -EINVAL;
}
 
-   retval = cpufreq_frequency_table_target(policy, freq_table, target_freq,
-   relation, );
+   retval = cpufreq_frequency_table_target(policy, target_freq, relation,
+   );
if (unlikely(retval)) {
pr_err("%s: Unable to find matching freq\n", __func__);
return retval;
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 528353f204fd..2ee476f5a2bd 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -79,20 +79,19 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
return freq_next;
}
 
-   cpufreq_frequency_table_target(policy, freq_table, freq_next, relation,
-  );
+   cpufreq_frequency_table_target(policy, freq_next, relation, );
freq_req = freq_table[index].frequency;
freq_reduc = freq_req * od_tuners->powersave_bias / 1000;
freq_avg = freq_req - freq_reduc;
 
/* Find freq bounds for freq_avg in freq_table */
index = 0;
-   cpufreq_frequency_table_target(policy, freq_table, freq_avg,
-  CPUFREQ_RELATION_H, );
+   cpufreq_frequency_table_target(policy, freq_avg, CPUFREQ_RELATION_H,
+  );
freq_lo = freq_table[index].frequency;
index = 0;
-   cpufreq_frequency_table_target(policy, freq_table, freq_avg,
-  CPUFREQ_RELATION_L, );
+   cpufreq_frequency_table_target(policy, freq_avg, CPUFREQ_RELATION_L,
+  );
freq_hi = freq_table[index].frequency;
 
/* Find out how long we have to be in hi and lo freqs */
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index f52b5473b1f4..f145b64649ef 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -114,7 +114,6 @@ int cpufreq_generic_frequency_table_verify(struct 
cpufreq_policy *policy)
 EXPORT_SYMBOL_GPL(cpufreq_generic_frequency_table_verify);
 
 int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
-  struct cpufreq_frequency_table *table,
   unsigned int target_freq,
   unsigned int relation,
   unsigned int *index)
@@ -128,6 +127,7 @@ int cpufreq_frequency_table_target(struct cpufreq_policy 
*policy,
.frequency = 0,
};
  

[PATCH V2 4/6] cpufreq: Drop freq-table param to cpufreq_frequency_table_target()

[Viresh Kumar]

The policy already has this pointer set, use it instead.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/cpu-freq/cpu-drivers.txt |  1 -
 drivers/cpufreq/amd_freq_sensitivity.c |  3 +--
 drivers/cpufreq/cpufreq.c  |  4 ++--
 drivers/cpufreq/cpufreq_ondemand.c | 11 +--
 drivers/cpufreq/freq_table.c   |  2 +-
 drivers/cpufreq/powernv-cpufreq.c  |  3 +--
 drivers/cpufreq/s3c24xx-cpufreq.c  | 11 +--
 drivers/cpufreq/s5pv210-cpufreq.c  |  3 +--
 include/linux/cpufreq.h|  1 -
 9 files changed, 16 insertions(+), 23 deletions(-)

diff --git a/Documentation/cpu-freq/cpu-drivers.txt 
b/Documentation/cpu-freq/cpu-drivers.txt
index decbb8cb5573..74e812f0719c 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -244,7 +244,6 @@ policy->max, and all other criteria are met. This is 
helpful for the
 ->verify call.
 
 int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
-   struct cpufreq_frequency_table *table,
unsigned int target_freq,
unsigned int relation,
unsigned int *index);
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
b/drivers/cpufreq/amd_freq_sensitivity.c
index bc86816693a8..3bea1bb791a9 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -92,8 +92,7 @@ static unsigned int amd_powersave_bias_target(struct 
cpufreq_policy *policy,
unsigned int index;
 
cpufreq_frequency_table_target(policy,
-   policy->freq_table, policy->cur - 1,
-   CPUFREQ_RELATION_H, );
+   policy->cur - 1, CPUFREQ_RELATION_H, );
freq_next = policy->freq_table[index].frequency;
}
 
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 1833eda1f9d4..e68611a67bd9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1947,8 +1947,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
return -EINVAL;
}
 
-   retval = cpufreq_frequency_table_target(policy, freq_table, target_freq,
-   relation, );
+   retval = cpufreq_frequency_table_target(policy, target_freq, relation,
+   );
if (unlikely(retval)) {
pr_err("%s: Unable to find matching freq\n", __func__);
return retval;
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 528353f204fd..2ee476f5a2bd 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -79,20 +79,19 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
return freq_next;
}
 
-   cpufreq_frequency_table_target(policy, freq_table, freq_next, relation,
-  );
+   cpufreq_frequency_table_target(policy, freq_next, relation, );
freq_req = freq_table[index].frequency;
freq_reduc = freq_req * od_tuners->powersave_bias / 1000;
freq_avg = freq_req - freq_reduc;
 
/* Find freq bounds for freq_avg in freq_table */
index = 0;
-   cpufreq_frequency_table_target(policy, freq_table, freq_avg,
-  CPUFREQ_RELATION_H, );
+   cpufreq_frequency_table_target(policy, freq_avg, CPUFREQ_RELATION_H,
+  );
freq_lo = freq_table[index].frequency;
index = 0;
-   cpufreq_frequency_table_target(policy, freq_table, freq_avg,
-  CPUFREQ_RELATION_L, );
+   cpufreq_frequency_table_target(policy, freq_avg, CPUFREQ_RELATION_L,
+  );
freq_hi = freq_table[index].frequency;
 
/* Find out how long we have to be in hi and lo freqs */
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index f52b5473b1f4..f145b64649ef 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -114,7 +114,6 @@ int cpufreq_generic_frequency_table_verify(struct 
cpufreq_policy *policy)
 EXPORT_SYMBOL_GPL(cpufreq_generic_frequency_table_verify);
 
 int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
-  struct cpufreq_frequency_table *table,
   unsigned int target_freq,
   unsigned int relation,
   unsigned int *index)
@@ -128,6 +127,7 @@ int cpufreq_frequency_table_target(struct cpufreq_policy 
*policy,
.frequency = 0,
};
  

[PATCH V2 6/6] cpufreq: Return index from cpufreq_frequency_table_target()

[Viresh Kumar]

This routine can't fail unless the frequency table is invalid and
doesn't contain any valid entries.

Make it return the index and WARN() in case it is used for an invalid
table.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/cpu-freq/cpu-drivers.txt |  7 +++
 drivers/cpufreq/amd_freq_sensitivity.c |  4 ++--
 drivers/cpufreq/cpufreq.c  |  9 ++---
 drivers/cpufreq/cpufreq_ondemand.c | 14 ++
 drivers/cpufreq/freq_table.c   | 24 +---
 drivers/cpufreq/powernv-cpufreq.c  |  4 ++--
 drivers/cpufreq/s3c24xx-cpufreq.c  | 26 ++
 drivers/cpufreq/s5pv210-cpufreq.c  |  7 ++-
 include/linux/cpufreq.h|  3 +--
 9 files changed, 37 insertions(+), 61 deletions(-)

diff --git a/Documentation/cpu-freq/cpu-drivers.txt 
b/Documentation/cpu-freq/cpu-drivers.txt
index 74e812f0719c..772b94fde264 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -245,12 +245,11 @@ policy->max, and all other criteria are met. This is 
helpful for the
 
 int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
unsigned int target_freq,
-   unsigned int relation,
-   unsigned int *index);
+   unsigned int relation);
 
 is the corresponding frequency table helper for the ->target
-stage. Just pass the values to this function, and the unsigned int
-index returns the number of the frequency table entry which contains
+stage. Just pass the values to this function, and this function
+returns the number of the frequency table entry which contains
 the frequency the CPU shall be set to.
 
 The following macros can be used as iterators over cpufreq_frequency_table:
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
b/drivers/cpufreq/amd_freq_sensitivity.c
index 3bea1bb791a9..6d5dc04c3a37 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -91,8 +91,8 @@ static unsigned int amd_powersave_bias_target(struct 
cpufreq_policy *policy,
else {
unsigned int index;
 
-   cpufreq_frequency_table_target(policy,
-   policy->cur - 1, CPUFREQ_RELATION_H, );
+   index = cpufreq_frequency_table_target(policy,
+   policy->cur - 1, CPUFREQ_RELATION_H);
freq_next = policy->freq_table[index].frequency;
}
 
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 30f05dd5c872..9ae58a18ccb9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1914,7 +1914,7 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int relation)
 {
unsigned int old_target_freq = target_freq;
-   int index, retval;
+   int index;
 
if (cpufreq_disabled())
return -ENODEV;
@@ -1943,12 +1943,7 @@ int __cpufreq_driver_target(struct cpufreq_policy 
*policy,
if (!cpufreq_driver->target_index)
return -EINVAL;
 
-   retval = cpufreq_frequency_table_target(policy, target_freq, relation,
-   );
-   if (unlikely(retval)) {
-   pr_err("%s: Unable to find matching freq\n", __func__);
-   return retval;
-   }
+   index = cpufreq_frequency_table_target(policy, target_freq, relation);
 
return __target_index(policy, index);
 }
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 2ee476f5a2bd..0c93cd9dee99 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -65,7 +65,7 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
 {
unsigned int freq_req, freq_reduc, freq_avg;
unsigned int freq_hi, freq_lo;
-   unsigned int index = 0;
+   unsigned int index;
unsigned int delay_hi_us;
struct policy_dbs_info *policy_dbs = policy->governor_data;
struct od_policy_dbs_info *dbs_info = to_dbs_info(policy_dbs);
@@ -79,19 +79,17 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
return freq_next;
}
 
-   cpufreq_frequency_table_target(policy, freq_next, relation, );
+   index = cpufreq_frequency_table_target(policy, freq_next, relation);
freq_req = freq_table[index].frequency;
freq_reduc = freq_req * od_tuners->powersave_bias / 1000;
freq_avg = freq_req - freq_reduc;
 
/* Find freq bounds for freq_avg in freq_table */
-   index = 0;
-   cpufreq_frequency_table_target(policy, freq_avg, CPUFREQ_RELATION_H,
-  

[PATCH 8/8] cpufreq: Return index from cpufreq_frequency_table_target()

[Viresh Kumar]

This routine can't fail unless the frequency table is invalid and
doesn't contain any valid entries.

Make it return the index and WARN() in case it is used for an invalid
table.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/cpu-freq/cpu-drivers.txt |  7 +++
 drivers/cpufreq/amd_freq_sensitivity.c |  4 ++--
 drivers/cpufreq/cpufreq.c  |  9 ++---
 drivers/cpufreq/cpufreq_ondemand.c | 14 ++
 drivers/cpufreq/freq_table.c   | 24 +---
 drivers/cpufreq/powernv-cpufreq.c  |  4 ++--
 drivers/cpufreq/s3c24xx-cpufreq.c  | 26 ++
 drivers/cpufreq/s5pv210-cpufreq.c  |  7 ++-
 include/linux/cpufreq.h|  3 +--
 9 files changed, 37 insertions(+), 61 deletions(-)

diff --git a/Documentation/cpu-freq/cpu-drivers.txt 
b/Documentation/cpu-freq/cpu-drivers.txt
index 74e812f0719c..772b94fde264 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -245,12 +245,11 @@ policy->max, and all other criteria are met. This is 
helpful for the
 
 int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
unsigned int target_freq,
-   unsigned int relation,
-   unsigned int *index);
+   unsigned int relation);
 
 is the corresponding frequency table helper for the ->target
-stage. Just pass the values to this function, and the unsigned int
-index returns the number of the frequency table entry which contains
+stage. Just pass the values to this function, and this function
+returns the number of the frequency table entry which contains
 the frequency the CPU shall be set to.
 
 The following macros can be used as iterators over cpufreq_frequency_table:
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
b/drivers/cpufreq/amd_freq_sensitivity.c
index 3bea1bb791a9..6d5dc04c3a37 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -91,8 +91,8 @@ static unsigned int amd_powersave_bias_target(struct 
cpufreq_policy *policy,
else {
unsigned int index;
 
-   cpufreq_frequency_table_target(policy,
-   policy->cur - 1, CPUFREQ_RELATION_H, );
+   index = cpufreq_frequency_table_target(policy,
+   policy->cur - 1, CPUFREQ_RELATION_H);
freq_next = policy->freq_table[index].frequency;
}
 
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 1685e930770f..07c933c6c29a 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1914,7 +1914,7 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int relation)
 {
unsigned int old_target_freq = target_freq;
-   int index, retval;
+   int index;
 
if (cpufreq_disabled())
return -ENODEV;
@@ -1943,12 +1943,7 @@ int __cpufreq_driver_target(struct cpufreq_policy 
*policy,
if (!cpufreq_driver->target_index)
return -EINVAL;
 
-   retval = cpufreq_frequency_table_target(policy, target_freq, relation,
-   );
-   if (unlikely(retval)) {
-   pr_err("%s: Unable to find matching freq\n", __func__);
-   return retval;
-   }
+   index = cpufreq_frequency_table_target(policy, target_freq, relation);
 
return __target_index(policy, index);
 }
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 2ee476f5a2bd..0c93cd9dee99 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -65,7 +65,7 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
 {
unsigned int freq_req, freq_reduc, freq_avg;
unsigned int freq_hi, freq_lo;
-   unsigned int index = 0;
+   unsigned int index;
unsigned int delay_hi_us;
struct policy_dbs_info *policy_dbs = policy->governor_data;
struct od_policy_dbs_info *dbs_info = to_dbs_info(policy_dbs);
@@ -79,19 +79,17 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
return freq_next;
}
 
-   cpufreq_frequency_table_target(policy, freq_next, relation, );
+   index = cpufreq_frequency_table_target(policy, freq_next, relation);
freq_req = freq_table[index].frequency;
freq_reduc = freq_req * od_tuners->powersave_bias / 1000;
freq_avg = freq_req - freq_reduc;
 
/* Find freq bounds for freq_avg in freq_table */
-   index = 0;
-   cpufreq_frequency_table_target(policy, freq_avg, CPUFREQ_RELATION_H,
-  

[PATCH 6/8] cpufreq: Drop freq-table param to cpufreq_frequency_table_target()

[Viresh Kumar]

The policy already has this pointer set, use it instead.

Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
 Documentation/cpu-freq/cpu-drivers.txt |  1 -
 drivers/cpufreq/amd_freq_sensitivity.c |  3 +--
 drivers/cpufreq/cpufreq.c  |  4 ++--
 drivers/cpufreq/cpufreq_ondemand.c | 11 +--
 drivers/cpufreq/freq_table.c   |  2 +-
 drivers/cpufreq/powernv-cpufreq.c  |  3 +--
 drivers/cpufreq/s3c24xx-cpufreq.c  | 11 +--
 drivers/cpufreq/s5pv210-cpufreq.c  |  3 +--
 include/linux/cpufreq.h|  1 -
 9 files changed, 16 insertions(+), 23 deletions(-)

diff --git a/Documentation/cpu-freq/cpu-drivers.txt 
b/Documentation/cpu-freq/cpu-drivers.txt
index decbb8cb5573..74e812f0719c 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -244,7 +244,6 @@ policy->max, and all other criteria are met. This is 
helpful for the
 ->verify call.
 
 int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
-   struct cpufreq_frequency_table *table,
unsigned int target_freq,
unsigned int relation,
unsigned int *index);
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
b/drivers/cpufreq/amd_freq_sensitivity.c
index bc86816693a8..3bea1bb791a9 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -92,8 +92,7 @@ static unsigned int amd_powersave_bias_target(struct 
cpufreq_policy *policy,
unsigned int index;
 
cpufreq_frequency_table_target(policy,
-   policy->freq_table, policy->cur - 1,
-   CPUFREQ_RELATION_H, );
+   policy->cur - 1, CPUFREQ_RELATION_H, );
freq_next = policy->freq_table[index].frequency;
}
 
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index cc252eecc45a..a28144697128 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1947,8 +1947,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
return -EINVAL;
}
 
-   retval = cpufreq_frequency_table_target(policy, freq_table, target_freq,
-   relation, );
+   retval = cpufreq_frequency_table_target(policy, target_freq, relation,
+   );
if (unlikely(retval)) {
pr_err("%s: Unable to find matching freq\n", __func__);
return retval;
diff --git a/drivers/cpufreq/cpufreq_ondemand.c 
b/drivers/cpufreq/cpufreq_ondemand.c
index 528353f204fd..2ee476f5a2bd 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -79,20 +79,19 @@ static unsigned int generic_powersave_bias_target(struct 
cpufreq_policy *policy,
return freq_next;
}
 
-   cpufreq_frequency_table_target(policy, freq_table, freq_next, relation,
-  );
+   cpufreq_frequency_table_target(policy, freq_next, relation, );
freq_req = freq_table[index].frequency;
freq_reduc = freq_req * od_tuners->powersave_bias / 1000;
freq_avg = freq_req - freq_reduc;
 
/* Find freq bounds for freq_avg in freq_table */
index = 0;
-   cpufreq_frequency_table_target(policy, freq_table, freq_avg,
-  CPUFREQ_RELATION_H, );
+   cpufreq_frequency_table_target(policy, freq_avg, CPUFREQ_RELATION_H,
+  );
freq_lo = freq_table[index].frequency;
index = 0;
-   cpufreq_frequency_table_target(policy, freq_table, freq_avg,
-  CPUFREQ_RELATION_L, );
+   cpufreq_frequency_table_target(policy, freq_avg, CPUFREQ_RELATION_L,
+  );
freq_hi = freq_table[index].frequency;
 
/* Find out how long we have to be in hi and lo freqs */
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index f52b5473b1f4..f145b64649ef 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -114,7 +114,6 @@ int cpufreq_generic_frequency_table_verify(struct 
cpufreq_policy *policy)
 EXPORT_SYMBOL_GPL(cpufreq_generic_frequency_table_verify);
 
 int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
-  struct cpufreq_frequency_table *table,
   unsigned int target_freq,
   unsigned int relation,
   unsigned int *index)
@@ -128,6 +127,7 @@ int cpufreq_frequency_table_target(struct cpufreq_policy 
*policy,
.frequency = 0,
};