Hi,
This patchset adds support to build a single-coefficient dynamic power
model for a CPU. The model is used by the CPU cooling device to
provide an estimate of power consumption and also translate allocated
power to performance cap.
Patch 1 extends the CPU nodes binding to provide an optional dynamic
power coefficient which can be used to create a dynamic power model
for the CPUs. This model is used to constrain device power consumption
(using power_allocator governor) when the system is thermally
constrained.
Patches 2-3 extends the cpufreq-dt and arm_big_little driver to
register cpu cooling devices with the dynamic coefficient when
provided.
The patches were previously posted as part of [0][1]. Since the last
posting Mediatek platform 8173 is also building on these bindings to
build the power model.
Feedback on the bindings would be particularly appreciated.
Thanks,
Punit
[0] http://thread.gmane.org/gmane.linux.kernel/2002152
[1] http://thread.gmane.org/gmane.linux.kernel/2011466
Punit Agrawal (3):
devicetree: bindings: Add optional dynamic-power-coefficient property
cpufreq-dt: Supply power coefficient when registering cooling devices
cpufreq: arm_big_little: Add support to register a cpufreq cooling
device
Documentation/devicetree/bindings/arm/cpus.txt | 17 +++++++++
drivers/cpufreq/arm_big_little.c | 52 +++++++++++++++++++++++++-
drivers/cpufreq/cpufreq-dt.c | 9 ++++-
3 files changed, 74 insertions(+), 4 deletions(-)
--
2.5.3
The dynamic power consumption of a device is proportional to the
square of voltage (V) and the clock frequency (f). It can be expressed as
Pdyn = dynamic-power-coefficient * V^2 * f.
The coefficient represents the running time dynamic power consumption in
units of mw/MHz/uVolt^2 and can be used in the above formula to
calculate the dynamic power in mW.
Signed-off-by: Punit Agrawal <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Mark Rutland <[email protected]>
---
Documentation/devicetree/bindings/arm/cpus.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 91e6e5c..c33362d 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -240,6 +240,23 @@ nodes to be present and contain the properties described below.
Definition: Specifies the syscon node controlling the cpu core
power domains.
+ - dynamic-power-coefficient
+ Usage: optional
+ Value type: <prop-encoded-array>
+ Definition: A u32 value that represents the running time dynamic
+ power coefficient in units of mW/MHz/uVolt^2. The
+ coefficient can either be calculated from power
+ measurements or derived by analysis.
+
+ The dynamic power consumption of the CPU is
+ proportional to the square of the Voltage (V) and
+ the clock frequency (f). The coefficient is used to
+ calculate the dynamic power as below -
+
+ Pdyn = dynamic-power-coefficient * V^2 * f
+
+ where voltage is in uV, frequency is in MHz.
+
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
--
2.5.3
Support registering cooling devices with dynamic power coefficient
where provided by the device tree. This allows OF registered cooling
devices driver to be used with the power_allocator thermal governor.
Signed-off-by: Punit Agrawal <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Cc: Eduardo Valentin <[email protected]>
---
drivers/cpufreq/cpufreq-dt.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 7c0d70e..4434e45 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -407,8 +407,13 @@ static void cpufreq_ready(struct cpufreq_policy *policy)
* thermal DT code takes care of matching them.
*/
if (of_find_property(np, "#cooling-cells", NULL)) {
- priv->cdev = of_cpufreq_cooling_register(np,
- policy->related_cpus);
+ u32 power_coefficient = 0;
+
+ of_property_read_u32(np, "dynamic-power-coefficient",
+ &power_coefficient);
+
+ priv->cdev = of_cpufreq_power_cooling_register(np,
+ policy->related_cpus, power_coefficient, NULL);
if (IS_ERR(priv->cdev)) {
dev_err(priv->cpu_dev,
"running cpufreq without cooling device: %ld\n",
--
2.5.3
Register passive cooling devices when initialising cpufreq on
big.LITTLE systems. If the device tree provides a dynamic power
coefficient for the CPUs then the bound cooling device will support
the extensions that allow it to be used with all the existing thermal
governors including the power allocator governor.
A cooling device will be created per individual frequency domain and
can be bound to thermal zones via the thermal DT bindings.
Signed-off-by: Punit Agrawal <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Cc: Sudeep Holla <[email protected]>
Cc: Eduardo Valentin <[email protected]>
---
drivers/cpufreq/arm_big_little.c | 52 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index f1e42f8..72a2777 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -23,6 +23,7 @@
#include <linux/cpu.h>
#include <linux/cpufreq.h>
#include <linux/cpumask.h>
+#include <linux/cpu_cooling.h>
#include <linux/export.h>
#include <linux/module.h>
#include <linux/mutex.h>
@@ -55,6 +56,10 @@ static bool bL_switching_enabled;
#define ACTUAL_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq << 1 : freq)
#define VIRT_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq >> 1 : freq)
+struct private_data {
+ struct thermal_cooling_device *cdev;
+};
+
static struct cpufreq_arm_bL_ops *arm_bL_ops;
static struct clk *clk[MAX_CLUSTERS];
static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
@@ -440,6 +445,7 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
{
u32 cur_cluster = cpu_to_cluster(policy->cpu);
struct device *cpu_dev;
+ struct private_data *priv;
int ret;
cpu_dev = get_cpu_device(policy->cpu);
@@ -457,9 +463,15 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
if (ret) {
dev_err(cpu_dev, "CPU %d, cluster: %d invalid freq table\n",
policy->cpu, cur_cluster);
- put_cluster_clk_and_freq_table(cpu_dev);
- return ret;
+ goto out_free_cpufreq_table;
+ }
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ ret = -ENOMEM;
+ goto out_free_cpufreq_table;
}
+ policy->driver_data = priv;
if (cur_cluster < MAX_CLUSTERS) {
int cpu;
@@ -484,12 +496,19 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
dev_info(cpu_dev, "%s: CPU %d initialized\n", __func__, policy->cpu);
return 0;
+
+out_free_cpufreq_table:
+ put_cluster_clk_and_freq_table(cpu_dev);
+
+ return ret;
}
static int bL_cpufreq_exit(struct cpufreq_policy *policy)
{
struct device *cpu_dev;
+ struct private_data *priv = policy->driver_data;
+ cpufreq_cooling_unregister(priv->cdev);
cpu_dev = get_cpu_device(policy->cpu);
if (!cpu_dev) {
pr_err("%s: failed to get cpu%d device\n", __func__,
@@ -498,11 +517,39 @@ static int bL_cpufreq_exit(struct cpufreq_policy *policy)
}
put_cluster_clk_and_freq_table(cpu_dev);
+ kfree(priv);
dev_dbg(cpu_dev, "%s: Exited, cpu: %d\n", __func__, policy->cpu);
return 0;
}
+static void bL_cpufreq_ready(struct cpufreq_policy *policy)
+{
+ struct device *cpu_dev = get_cpu_device(policy->cpu);
+ struct device_node *np = of_node_get(cpu_dev->of_node);
+ struct private_data *priv = policy->driver_data;
+
+ 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",
+ &power_coefficient);
+
+ priv->cdev = of_cpufreq_power_cooling_register(np,
+ policy->related_cpus, power_coefficient, NULL);
+ if (IS_ERR(priv->cdev)) {
+ dev_err(cpu_dev,
+ "running cpufreq without cooling device: %ld\n",
+ PTR_ERR(priv->cdev));
+ priv->cdev = NULL;
+ }
+ }
+ of_node_put(np);
+}
+
static struct cpufreq_driver bL_cpufreq_driver = {
.name = "arm-big-little",
.flags = CPUFREQ_STICKY |
@@ -513,6 +560,7 @@ static struct cpufreq_driver bL_cpufreq_driver = {
.get = bL_cpufreq_get_rate,
.init = bL_cpufreq_init,
.exit = bL_cpufreq_exit,
+ .ready = bL_cpufreq_ready,
.attr = cpufreq_generic_attr,
};
--
2.5.3
On Mon, Nov 09, 2015 at 05:29:21PM +0000, Punit Agrawal wrote:
> The dynamic power consumption of a device is proportional to the
> square of voltage (V) and the clock frequency (f). It can be expressed as
>
> Pdyn = dynamic-power-coefficient * V^2 * f.
>
> The coefficient represents the running time dynamic power consumption in
> units of mw/MHz/uVolt^2 and can be used in the above formula to
> calculate the dynamic power in mW.
I have no issue with the binding, but I wonder if a single value is
really sufficient to model this. Don't you also need a static component?
Rob
>
> Signed-off-by: Punit Agrawal <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: Mark Rutland <[email protected]>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index 91e6e5c..c33362d 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -240,6 +240,23 @@ nodes to be present and contain the properties described below.
> Definition: Specifies the syscon node controlling the cpu core
> power domains.
>
> + - dynamic-power-coefficient
> + Usage: optional
> + Value type: <prop-encoded-array>
> + Definition: A u32 value that represents the running time dynamic
> + power coefficient in units of mW/MHz/uVolt^2. The
> + coefficient can either be calculated from power
> + measurements or derived by analysis.
> +
> + The dynamic power consumption of the CPU is
> + proportional to the square of the Voltage (V) and
> + the clock frequency (f). The coefficient is used to
> + calculate the dynamic power as below -
> +
> + Pdyn = dynamic-power-coefficient * V^2 * f
> +
> + where voltage is in uV, frequency is in MHz.
> +
> Example 1 (dual-cluster big.LITTLE system 32-bit):
>
> cpus {
> --
> 2.5.3
>
Rob Herring <[email protected]> writes:
> On Mon, Nov 09, 2015 at 05:29:21PM +0000, Punit Agrawal wrote:
>> The dynamic power consumption of a device is proportional to the
>> square of voltage (V) and the clock frequency (f). It can be expressed as
>>
>> Pdyn = dynamic-power-coefficient * V^2 * f.
>>
>> The coefficient represents the running time dynamic power consumption in
>> units of mw/MHz/uVolt^2 and can be used in the above formula to
>> calculate the dynamic power in mW.
>
> I have no issue with the binding, but I wonder if a single value is
> really sufficient to model this. Don't you also need a static
> component?
In general, power consumption does consist of the static and dynamic
power. Here we are only modelling the dynamic component.
For CPUs, we found that a single-coefficient model using frequency and
voltages gives a reasonable estimation of dynamic power consumption. For
thermal management, because of using closed loop control providing the
dynamic consumption is good enough as long as static power for your
platform is not significant.
On the other hand, there isn't a generally applicable model for static
power - it has complex relationships with temperature, voltages, etc
which make it hard to express as a simple formula. For platforms where
static power is significant, providing it via platform code is the only
option for now.
This patchset enables platforms where dynamic power works well to setup
their power model for thermal management via device tree.
>
> Rob
>
>>
>> Signed-off-by: Punit Agrawal <[email protected]>
>> Cc: Rob Herring <[email protected]>
>> Cc: Mark Rutland <[email protected]>
>> ---
>> Documentation/devicetree/bindings/arm/cpus.txt | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
>> index 91e6e5c..c33362d 100644
>> --- a/Documentation/devicetree/bindings/arm/cpus.txt
>> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
>> @@ -240,6 +240,23 @@ nodes to be present and contain the properties described below.
>> Definition: Specifies the syscon node controlling the cpu core
>> power domains.
>>
>> + - dynamic-power-coefficient
>> + Usage: optional
>> + Value type: <prop-encoded-array>
>> + Definition: A u32 value that represents the running time dynamic
>> + power coefficient in units of mW/MHz/uVolt^2. The
>> + coefficient can either be calculated from power
>> + measurements or derived by analysis.
>> +
>> + The dynamic power consumption of the CPU is
>> + proportional to the square of the Voltage (V) and
>> + the clock frequency (f). The coefficient is used to
>> + calculate the dynamic power as below -
>> +
>> + Pdyn = dynamic-power-coefficient * V^2 * f
>> +
>> + where voltage is in uV, frequency is in MHz.
>> +
>> Example 1 (dual-cluster big.LITTLE system 32-bit):
>>
>> cpus {
>> --
>> 2.5.3
>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 09, 2015 at 05:29:22PM +0000, Punit Agrawal wrote:
> Support registering cooling devices with dynamic power coefficient
> where provided by the device tree. This allows OF registered cooling
> devices driver to be used with the power_allocator thermal governor.
>
> Signed-off-by: Punit Agrawal <[email protected]>
> Acked-by: Viresh Kumar <[email protected]>
> Cc: Eduardo Valentin <[email protected]>
> ---
> drivers/cpufreq/cpufreq-dt.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
FWIW,
Reviewed-by: Javi Merino <[email protected]>
On Mon, Nov 09, 2015 at 05:29:23PM +0000, Punit Agrawal wrote:
> Register passive cooling devices when initialising cpufreq on
> big.LITTLE systems. If the device tree provides a dynamic power
> coefficient for the CPUs then the bound cooling device will support
> the extensions that allow it to be used with all the existing thermal
> governors including the power allocator governor.
>
> A cooling device will be created per individual frequency domain and
> can be bound to thermal zones via the thermal DT bindings.
>
> Signed-off-by: Punit Agrawal <[email protected]>
> Acked-by: Viresh Kumar <[email protected]>
> Cc: Sudeep Holla <[email protected]>
> Cc: Eduardo Valentin <[email protected]>
> ---
> drivers/cpufreq/arm_big_little.c | 52 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
> index f1e42f8..72a2777 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufreq/arm_big_little.c
> @@ -23,6 +23,7 @@
> #include <linux/cpu.h>
> #include <linux/cpufreq.h>
> #include <linux/cpumask.h>
> +#include <linux/cpu_cooling.h>
> #include <linux/export.h>
> #include <linux/module.h>
> #include <linux/mutex.h>
> @@ -55,6 +56,10 @@ static bool bL_switching_enabled;
> #define ACTUAL_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq << 1 : freq)
> #define VIRT_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq >> 1 : freq)
>
> +struct private_data {
> + struct thermal_cooling_device *cdev;
> +};
> +
My first impression was that this is redundant and you could store the
pointer to cdev in driver_data itself. But seeing that it's mirroring
the structure in cpufreq-dt and it's simpler to do it this way I guess
it's ok to create this struct with only one pointer. You can add my
Reviewed-by: Javi Merino <[email protected]>
> static struct cpufreq_arm_bL_ops *arm_bL_ops;
> static struct clk *clk[MAX_CLUSTERS];
> static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
> @@ -440,6 +445,7 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
> {
> u32 cur_cluster = cpu_to_cluster(policy->cpu);
> struct device *cpu_dev;
> + struct private_data *priv;
> int ret;
>
> cpu_dev = get_cpu_device(policy->cpu);
> @@ -457,9 +463,15 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
> if (ret) {
> dev_err(cpu_dev, "CPU %d, cluster: %d invalid freq table\n",
> policy->cpu, cur_cluster);
> - put_cluster_clk_and_freq_table(cpu_dev);
> - return ret;
> + goto out_free_cpufreq_table;
> + }
> +
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (!priv) {
> + ret = -ENOMEM;
> + goto out_free_cpufreq_table;
> }
> + policy->driver_data = priv;
>
> if (cur_cluster < MAX_CLUSTERS) {
> int cpu;
> @@ -484,12 +496,19 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
>
> dev_info(cpu_dev, "%s: CPU %d initialized\n", __func__, policy->cpu);
> return 0;
> +
> +out_free_cpufreq_table:
> + put_cluster_clk_and_freq_table(cpu_dev);
> +
> + return ret;
> }
>
> static int bL_cpufreq_exit(struct cpufreq_policy *policy)
> {
> struct device *cpu_dev;
> + struct private_data *priv = policy->driver_data;
>
> + cpufreq_cooling_unregister(priv->cdev);
> cpu_dev = get_cpu_device(policy->cpu);
> if (!cpu_dev) {
> pr_err("%s: failed to get cpu%d device\n", __func__,
> @@ -498,11 +517,39 @@ static int bL_cpufreq_exit(struct cpufreq_policy *policy)
> }
>
> put_cluster_clk_and_freq_table(cpu_dev);
> + kfree(priv);
> dev_dbg(cpu_dev, "%s: Exited, cpu: %d\n", __func__, policy->cpu);
>
> return 0;
> }
>
> +static void bL_cpufreq_ready(struct cpufreq_policy *policy)
> +{
> + struct device *cpu_dev = get_cpu_device(policy->cpu);
> + struct device_node *np = of_node_get(cpu_dev->of_node);
> + struct private_data *priv = policy->driver_data;
> +
> + 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",
> + &power_coefficient);
> +
> + priv->cdev = of_cpufreq_power_cooling_register(np,
> + policy->related_cpus, power_coefficient, NULL);
> + if (IS_ERR(priv->cdev)) {
> + dev_err(cpu_dev,
> + "running cpufreq without cooling device: %ld\n",
> + PTR_ERR(priv->cdev));
> + priv->cdev = NULL;
> + }
> + }
> + of_node_put(np);
> +}
> +
> static struct cpufreq_driver bL_cpufreq_driver = {
> .name = "arm-big-little",
> .flags = CPUFREQ_STICKY |
> @@ -513,6 +560,7 @@ static struct cpufreq_driver bL_cpufreq_driver = {
> .get = bL_cpufreq_get_rate,
> .init = bL_cpufreq_init,
> .exit = bL_cpufreq_exit,
> + .ready = bL_cpufreq_ready,
> .attr = cpufreq_generic_attr,
> };
>
> --
> 2.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On 09-11-15, 17:29, Punit Agrawal wrote:
> Register passive cooling devices when initialising cpufreq on
> big.LITTLE systems. If the device tree provides a dynamic power
> coefficient for the CPUs then the bound cooling device will support
> the extensions that allow it to be used with all the existing thermal
> governors including the power allocator governor.
>
> A cooling device will be created per individual frequency domain and
> can be bound to thermal zones via the thermal DT bindings.
>
> Signed-off-by: Punit Agrawal <[email protected]>
> Acked-by: Viresh Kumar <[email protected]>
> Cc: Sudeep Holla <[email protected]>
> Cc: Eduardo Valentin <[email protected]>
> ---
> drivers/cpufreq/arm_big_little.c | 52 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
> index f1e42f8..72a2777 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufreq/arm_big_little.c
> @@ -23,6 +23,7 @@
> #include <linux/cpu.h>
> #include <linux/cpufreq.h>
> #include <linux/cpumask.h>
> +#include <linux/cpu_cooling.h>
> #include <linux/export.h>
> #include <linux/module.h>
> #include <linux/mutex.h>
> @@ -55,6 +56,10 @@ static bool bL_switching_enabled;
> #define ACTUAL_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq << 1 : freq)
> #define VIRT_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq >> 1 : freq)
>
> +struct private_data {
> + struct thermal_cooling_device *cdev;
> +};
I think we need to be consistent within the driver, and so this must
be stored in a similar way to what we do for other structures. We have
static arrays for them, please do it that way only OR first change all
of them to be part of a bigger private_data structure.
--
viresh
Viresh Kumar <[email protected]> writes:
> On 09-11-15, 17:29, Punit Agrawal wrote:
>> Register passive cooling devices when initialising cpufreq on
>> big.LITTLE systems. If the device tree provides a dynamic power
>> coefficient for the CPUs then the bound cooling device will support
>> the extensions that allow it to be used with all the existing thermal
>> governors including the power allocator governor.
>>
>> A cooling device will be created per individual frequency domain and
>> can be bound to thermal zones via the thermal DT bindings.
>>
>> Signed-off-by: Punit Agrawal <[email protected]>
>> Acked-by: Viresh Kumar <[email protected]>
>> Cc: Sudeep Holla <[email protected]>
>> Cc: Eduardo Valentin <[email protected]>
>> ---
>> drivers/cpufreq/arm_big_little.c | 52 ++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 50 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
>> index f1e42f8..72a2777 100644
>> --- a/drivers/cpufreq/arm_big_little.c
>> +++ b/drivers/cpufreq/arm_big_little.c
>> @@ -23,6 +23,7 @@
>> #include <linux/cpu.h>
>> #include <linux/cpufreq.h>
>> #include <linux/cpumask.h>
>> +#include <linux/cpu_cooling.h>
>> #include <linux/export.h>
>> #include <linux/module.h>
>> #include <linux/mutex.h>
>> @@ -55,6 +56,10 @@ static bool bL_switching_enabled;
>> #define ACTUAL_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq << 1 : freq)
>> #define VIRT_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq >> 1 : freq)
>>
>> +struct private_data {
>> + struct thermal_cooling_device *cdev;
>> +};
>
> I think we need to be consistent within the driver, and so this must
> be stored in a similar way to what we do for other structures. We have
> static arrays for them, please do it that way only OR first change all
> of them to be part of a bigger private_data structure.
Sure, I'll switch to using static arrays. There seem to be a lot of
assumptions that might be easily broken in moving all the data into a
single structure. I'll leave that as a later change.