[PATCH v2 0/2] Add device tree based lookup of boost mode frequency

[PATCH v2 0/2] Add device tree based lookup of boost mode frequency

[Thomas Abraham]

Changes since v1:
- Boost mode frequencies are specfied as a set of frequencies instead of
  specifying them as OPPs. Thanks to Nishanth, Lukasz and Rob for the
  feedback.

Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode for CPUfreq drivers. To use the new boost
mode, CPUfreq drivers have to specify the boost mode frequency and
voltage within the CPUfreq driver, which is the case for Exynos4x12
CPUfreq driver.

But for CPUfreq drivers which obtain the OPPs from cpus node, this
patch series adds support to specify boost mode frequencies in the
cpu device tree node. This requirement came up when Lukasz pointed
out the regression caused by the Exynos CPUfreq driver consolidation
patches.

Thomas Abraham (2):
  PM / OPP: Allow boost frequency to be looked up from device tree
  Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

 .../devicetree/bindings/cpufreq/cpufreq-boost.txt  |   11 +++++++
 drivers/base/power/opp.c                           |   34 +++++++++++++++++++-
 2 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt

[PATCH v2 0/2] Add device tree based lookup of boost mode frequency

[Thomas Abraham]

Changes since v1:
- Boost mode frequencies are specfied as a set of frequencies instead of
  specifying them as OPPs. Thanks to Nishanth, Lukasz and Rob for the
  feedback.

Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode for CPUfreq drivers. To use the new boost
mode, CPUfreq drivers have to specify the boost mode frequency and
voltage within the CPUfreq driver, which is the case for Exynos4x12
CPUfreq driver.

But for CPUfreq drivers which obtain the OPPs from cpus node, this
patch series adds support to specify boost mode frequencies in the
cpu device tree node. This requirement came up when Lukasz pointed
out the regression caused by the Exynos CPUfreq driver consolidation
patches.

Thomas Abraham (2):
  PM / OPP: Allow boost frequency to be looked up from device tree
  Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

 .../devicetree/bindings/cpufreq/cpufreq-boost.txt  |   11 +++++++
 drivers/base/power/opp.c                           |   34 +++++++++++++++++++-
 2 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt

[PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Thomas Abraham]

From: Thomas Abraham <thomas.ab@samsung.com>

Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and marking them as usable in boost mode.

Cc: Nishanth Menon <nm@ti.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
 drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index fa41874..b636826 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
 	struct device_opp *dev_opp;
 	struct dev_pm_opp *opp;
 	struct cpufreq_frequency_table *freq_table;
-	int i = 0;
+	int i = 0, j, len, ret;
+	u32 *boost_freqs = NULL;
 
 	/* Pretend as if I am an updater */
 	mutex_lock(&dev_opp_list_lock);
@@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
 		return -ENOMEM;
 	}
 
+	if (of_find_property(dev->of_node, "boost-frequency", &len)) {
+		if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
+			dev_err(dev, "%s: invalid boost frequency\n", __func__);
+			ret = -EINVAL;
+			goto err_boost;
+		}
+
+		boost_freqs = kzalloc(len, GFP_KERNEL);
+		if (!boost_freqs) {
+			dev_warn(dev, "%s: no memory for boost freq table\n",
+					__func__);
+			ret = -ENOMEM;
+			goto err_boost;
+		}
+		of_property_read_u32_array(dev->of_node, "boost-frequency",
+			boost_freqs, len / sizeof(u32));
+	}
+
 	list_for_each_entry(opp, &dev_opp->opp_list, node) {
 		if (opp->available) {
 			freq_table[i].driver_data = i;
 			freq_table[i].frequency = opp->rate / 1000;
+			for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
+				if (boost_freqs[j] == freq_table[i].frequency) {
+					freq_table[i].driver_data =
+							CPUFREQ_BOOST_FREQ;
+					break;
+				}
+			}
 			i++;
 		}
 	}
@@ -663,8 +689,14 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
 	freq_table[i].frequency = CPUFREQ_TABLE_END;
 
 	*table = &freq_table[0];
+	kfree(boost_freqs);
 
 	return 0;
+
+err_boost:
+	kfree(freq_table);
+	mutex_unlock(&dev_opp_list_lock);
+	return ret;
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_init_cpufreq_table);
 
-- 
1.7.10.4

[PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Thomas Abraham]

From: Thomas Abraham <thomas.ab@samsung.com>

Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and marking them as usable in boost mode.

Cc: Nishanth Menon <nm@ti.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
 drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index fa41874..b636826 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
 	struct device_opp *dev_opp;
 	struct dev_pm_opp *opp;
 	struct cpufreq_frequency_table *freq_table;
-	int i = 0;
+	int i = 0, j, len, ret;
+	u32 *boost_freqs = NULL;
 
 	/* Pretend as if I am an updater */
 	mutex_lock(&dev_opp_list_lock);
@@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
 		return -ENOMEM;
 	}
 
+	if (of_find_property(dev->of_node, "boost-frequency", &len)) {
+		if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
+			dev_err(dev, "%s: invalid boost frequency\n", __func__);
+			ret = -EINVAL;
+			goto err_boost;
+		}
+
+		boost_freqs = kzalloc(len, GFP_KERNEL);
+		if (!boost_freqs) {
+			dev_warn(dev, "%s: no memory for boost freq table\n",
+					__func__);
+			ret = -ENOMEM;
+			goto err_boost;
+		}
+		of_property_read_u32_array(dev->of_node, "boost-frequency",
+			boost_freqs, len / sizeof(u32));
+	}
+
 	list_for_each_entry(opp, &dev_opp->opp_list, node) {
 		if (opp->available) {
 			freq_table[i].driver_data = i;
 			freq_table[i].frequency = opp->rate / 1000;
+			for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
+				if (boost_freqs[j] == freq_table[i].frequency) {
+					freq_table[i].driver_data =
+							CPUFREQ_BOOST_FREQ;
+					break;
+				}
+			}
 			i++;
 		}
 	}
@@ -663,8 +689,14 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
 	freq_table[i].frequency = CPUFREQ_TABLE_END;
 
 	*table = &freq_table[0];
+	kfree(boost_freqs);
 
 	return 0;
+
+err_boost:
+	kfree(freq_table);
+	mutex_unlock(&dev_opp_list_lock);
+	return ret;
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_init_cpufreq_table);
 
-- 
1.7.10.4

Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Nishanth Menon]

On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
> support for CPU boost mode. This patch adds support for finding available
> boost frequencies from device tree and marking them as usable in boost mode.
>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>  1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index fa41874..b636826 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>         struct device_opp *dev_opp;
>         struct dev_pm_opp *opp;
>         struct cpufreq_frequency_table *freq_table;
> -       int i = 0;
> +       int i = 0, j, len, ret;
> +       u32 *boost_freqs = NULL;
>
>         /* Pretend as if I am an updater */
>         mutex_lock(&dev_opp_list_lock);
> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>                 return -ENOMEM;
>         }
>
> +       if (of_find_property(dev->of_node, "boost-frequency", &len)) {
> +               if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
> +                       dev_err(dev, "%s: invalid boost frequency\n", __func__);
> +                       ret = -EINVAL;
> +                       goto err_boost;
> +               }
> +
> +               boost_freqs = kzalloc(len, GFP_KERNEL);
> +               if (!boost_freqs) {
> +                       dev_warn(dev, "%s: no memory for boost freq table\n",
> +                                       __func__);
> +                       ret = -ENOMEM;
> +                       goto err_boost;
> +               }
> +               of_property_read_u32_array(dev->of_node, "boost-frequency",
> +                       boost_freqs, len / sizeof(u32));
> +       }
> +
>         list_for_each_entry(opp, &dev_opp->opp_list, node) {
>                 if (opp->available) {
>                         freq_table[i].driver_data = i;
>                         freq_table[i].frequency = opp->rate / 1000;
> +                       for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
> +                               if (boost_freqs[j] == freq_table[i].frequency) {
> +                                       freq_table[i].driver_data =
> +                                                       CPUFREQ_BOOST_FREQ;
> +                                       break;
> +                               }
> +                       }

What if any one of the boost_freqs are not contained in the enabled frequencies?

>                         i++;
>                 }
>         }
> @@ -663,8 +689,14 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>         freq_table[i].frequency = CPUFREQ_TABLE_END;
>
>         *table = &freq_table[0];
> +       kfree(boost_freqs);
>
>         return 0;
> +
> +err_boost:
> +       kfree(freq_table);
> +       mutex_unlock(&dev_opp_list_lock);
> +       return ret;
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_opp_init_cpufreq_table);
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Nishanth Menon]

On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
> support for CPU boost mode. This patch adds support for finding available
> boost frequencies from device tree and marking them as usable in boost mode.
>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>  1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index fa41874..b636826 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>         struct device_opp *dev_opp;
>         struct dev_pm_opp *opp;
>         struct cpufreq_frequency_table *freq_table;
> -       int i = 0;
> +       int i = 0, j, len, ret;
> +       u32 *boost_freqs = NULL;
>
>         /* Pretend as if I am an updater */
>         mutex_lock(&dev_opp_list_lock);
> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>                 return -ENOMEM;
>         }
>
> +       if (of_find_property(dev->of_node, "boost-frequency", &len)) {
> +               if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
> +                       dev_err(dev, "%s: invalid boost frequency\n", __func__);
> +                       ret = -EINVAL;
> +                       goto err_boost;
> +               }
> +
> +               boost_freqs = kzalloc(len, GFP_KERNEL);
> +               if (!boost_freqs) {
> +                       dev_warn(dev, "%s: no memory for boost freq table\n",
> +                                       __func__);
> +                       ret = -ENOMEM;
> +                       goto err_boost;
> +               }
> +               of_property_read_u32_array(dev->of_node, "boost-frequency",
> +                       boost_freqs, len / sizeof(u32));
> +       }
> +
>         list_for_each_entry(opp, &dev_opp->opp_list, node) {
>                 if (opp->available) {
>                         freq_table[i].driver_data = i;
>                         freq_table[i].frequency = opp->rate / 1000;
> +                       for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
> +                               if (boost_freqs[j] == freq_table[i].frequency) {
> +                                       freq_table[i].driver_data =
> +                                                       CPUFREQ_BOOST_FREQ;
> +                                       break;
> +                               }
> +                       }

What if any one of the boost_freqs are not contained in the enabled frequencies?

>                         i++;
>                 }
>         }
> @@ -663,8 +689,14 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>         freq_table[i].frequency = CPUFREQ_TABLE_END;
>
>         *table = &freq_table[0];
> +       kfree(boost_freqs);
>
>         return 0;
> +
> +err_boost:
> +       kfree(freq_table);
> +       mutex_unlock(&dev_opp_list_lock);
> +       return ret;
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_opp_init_cpufreq_table);
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Thomas Abraham]

On Fri, Feb 7, 2014 at 8:59 PM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> support for CPU boost mode. This patch adds support for finding available
>> boost frequencies from device tree and marking them as usable in boost mode.
>>
>> Cc: Nishanth Menon <nm@ti.com>
>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>>  1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>> index fa41874..b636826 100644
>> --- a/drivers/base/power/opp.c
>> +++ b/drivers/base/power/opp.c
>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>         struct device_opp *dev_opp;
>>         struct dev_pm_opp *opp;
>>         struct cpufreq_frequency_table *freq_table;
>> -       int i = 0;
>> +       int i = 0, j, len, ret;
>> +       u32 *boost_freqs = NULL;
>>
>>         /* Pretend as if I am an updater */
>>         mutex_lock(&dev_opp_list_lock);
>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>                 return -ENOMEM;
>>         }
>>
>> +       if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>> +               if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>> +                       dev_err(dev, "%s: invalid boost frequency\n", __func__);
>> +                       ret = -EINVAL;
>> +                       goto err_boost;
>> +               }
>> +
>> +               boost_freqs = kzalloc(len, GFP_KERNEL);
>> +               if (!boost_freqs) {
>> +                       dev_warn(dev, "%s: no memory for boost freq table\n",
>> +                                       __func__);
>> +                       ret = -ENOMEM;
>> +                       goto err_boost;
>> +               }
>> +               of_property_read_u32_array(dev->of_node, "boost-frequency",
>> +                       boost_freqs, len / sizeof(u32));
>> +       }
>> +
>>         list_for_each_entry(opp, &dev_opp->opp_list, node) {
>>                 if (opp->available) {
>>                         freq_table[i].driver_data = i;
>>                         freq_table[i].frequency = opp->rate / 1000;
>> +                       for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>> +                               if (boost_freqs[j] == freq_table[i].frequency) {
>> +                                       freq_table[i].driver_data =
>> +                                                       CPUFREQ_BOOST_FREQ;
>> +                                       break;
>> +                               }
>> +                       }
>
> What if any one of the boost_freqs are not contained in the enabled frequencies?

It is not used as a boost frequency because its corresponding voltage
is not known. If required a warning can be printed out for the same.

Thanks,
Thomas.

>
>>                         i++;
>>                 }
>>         }
>> @@ -663,8 +689,14 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>         freq_table[i].frequency = CPUFREQ_TABLE_END;
>>
>>         *table = &freq_table[0];
>> +       kfree(boost_freqs);
>>
>>         return 0;
>> +
>> +err_boost:
>> +       kfree(freq_table);
>> +       mutex_unlock(&dev_opp_list_lock);
>> +       return ret;
>>  }
>>  EXPORT_SYMBOL_GPL(dev_pm_opp_init_cpufreq_table);
>>
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Thomas Abraham]

On Fri, Feb 7, 2014 at 8:59 PM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> support for CPU boost mode. This patch adds support for finding available
>> boost frequencies from device tree and marking them as usable in boost mode.
>>
>> Cc: Nishanth Menon <nm@ti.com>
>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>>  1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>> index fa41874..b636826 100644
>> --- a/drivers/base/power/opp.c
>> +++ b/drivers/base/power/opp.c
>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>         struct device_opp *dev_opp;
>>         struct dev_pm_opp *opp;
>>         struct cpufreq_frequency_table *freq_table;
>> -       int i = 0;
>> +       int i = 0, j, len, ret;
>> +       u32 *boost_freqs = NULL;
>>
>>         /* Pretend as if I am an updater */
>>         mutex_lock(&dev_opp_list_lock);
>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>                 return -ENOMEM;
>>         }
>>
>> +       if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>> +               if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>> +                       dev_err(dev, "%s: invalid boost frequency\n", __func__);
>> +                       ret = -EINVAL;
>> +                       goto err_boost;
>> +               }
>> +
>> +               boost_freqs = kzalloc(len, GFP_KERNEL);
>> +               if (!boost_freqs) {
>> +                       dev_warn(dev, "%s: no memory for boost freq table\n",
>> +                                       __func__);
>> +                       ret = -ENOMEM;
>> +                       goto err_boost;
>> +               }
>> +               of_property_read_u32_array(dev->of_node, "boost-frequency",
>> +                       boost_freqs, len / sizeof(u32));
>> +       }
>> +
>>         list_for_each_entry(opp, &dev_opp->opp_list, node) {
>>                 if (opp->available) {
>>                         freq_table[i].driver_data = i;
>>                         freq_table[i].frequency = opp->rate / 1000;
>> +                       for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>> +                               if (boost_freqs[j] == freq_table[i].frequency) {
>> +                                       freq_table[i].driver_data =
>> +                                                       CPUFREQ_BOOST_FREQ;
>> +                                       break;
>> +                               }
>> +                       }
>
> What if any one of the boost_freqs are not contained in the enabled frequencies?

It is not used as a boost frequency because its corresponding voltage
is not known. If required a warning can be printed out for the same.

Thanks,
Thomas.

>
>>                         i++;
>>                 }
>>         }
>> @@ -663,8 +689,14 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>         freq_table[i].frequency = CPUFREQ_TABLE_END;
>>
>>         *table = &freq_table[0];
>> +       kfree(boost_freqs);
>>
>>         return 0;
>> +
>> +err_boost:
>> +       kfree(freq_table);
>> +       mutex_unlock(&dev_opp_list_lock);
>> +       return ret;
>>  }
>>  EXPORT_SYMBOL_GPL(dev_pm_opp_init_cpufreq_table);
>>
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Nishanth Menon]

On 02/07/2014 09:38 AM, Thomas Abraham wrote:
[...]
>>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>>> index fa41874..b636826 100644
>>> --- a/drivers/base/power/opp.c
>>> +++ b/drivers/base/power/opp.c
>>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>>         struct device_opp *dev_opp;
>>>         struct dev_pm_opp *opp;
>>>         struct cpufreq_frequency_table *freq_table;
>>> -       int i = 0;
>>> +       int i = 0, j, len, ret;
>>> +       u32 *boost_freqs = NULL;
>>>
>>>         /* Pretend as if I am an updater */
>>>         mutex_lock(&dev_opp_list_lock);
>>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>>                 return -ENOMEM;
>>>         }
>>>
>>> +       if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>>> +               if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>>> +                       dev_err(dev, "%s: invalid boost frequency\n", __func__);
>>> +                       ret = -EINVAL;
>>> +                       goto err_boost;
>>> +               }
>>> +
>>> +               boost_freqs = kzalloc(len, GFP_KERNEL);
>>> +               if (!boost_freqs) {
>>> +                       dev_warn(dev, "%s: no memory for boost freq table\n",
>>> +                                       __func__);
>>> +                       ret = -ENOMEM;
>>> +                       goto err_boost;
>>> +               }
>>> +               of_property_read_u32_array(dev->of_node, "boost-frequency",
>>> +                       boost_freqs, len / sizeof(u32));
>>> +       }
>>> +
>>>         list_for_each_entry(opp, &dev_opp->opp_list, node) {
>>>                 if (opp->available) {
>>>                         freq_table[i].driver_data = i;
>>>                         freq_table[i].frequency = opp->rate / 1000;
>>> +                       for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>>> +                               if (boost_freqs[j] == freq_table[i].frequency) {
>>> +                                       freq_table[i].driver_data =
>>> +                                                       CPUFREQ_BOOST_FREQ;
>>> +                                       break;
>>> +                               }
>>> +                       }
>>
>> What if any one of the boost_freqs are not contained in the enabled frequencies?
> 
> It is not used as a boost frequency because its corresponding voltage
> is not known. If required a warning can be printed out for the same.

yes - that would be good, as it helps debug if there are developer
errors in dts.


-- 
Regards,
Nishanth Menon

[PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Nishanth Menon]

On 02/07/2014 09:38 AM, Thomas Abraham wrote:
[...]
>>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>>> index fa41874..b636826 100644
>>> --- a/drivers/base/power/opp.c
>>> +++ b/drivers/base/power/opp.c
>>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>>         struct device_opp *dev_opp;
>>>         struct dev_pm_opp *opp;
>>>         struct cpufreq_frequency_table *freq_table;
>>> -       int i = 0;
>>> +       int i = 0, j, len, ret;
>>> +       u32 *boost_freqs = NULL;
>>>
>>>         /* Pretend as if I am an updater */
>>>         mutex_lock(&dev_opp_list_lock);
>>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>>                 return -ENOMEM;
>>>         }
>>>
>>> +       if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>>> +               if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>>> +                       dev_err(dev, "%s: invalid boost frequency\n", __func__);
>>> +                       ret = -EINVAL;
>>> +                       goto err_boost;
>>> +               }
>>> +
>>> +               boost_freqs = kzalloc(len, GFP_KERNEL);
>>> +               if (!boost_freqs) {
>>> +                       dev_warn(dev, "%s: no memory for boost freq table\n",
>>> +                                       __func__);
>>> +                       ret = -ENOMEM;
>>> +                       goto err_boost;
>>> +               }
>>> +               of_property_read_u32_array(dev->of_node, "boost-frequency",
>>> +                       boost_freqs, len / sizeof(u32));
>>> +       }
>>> +
>>>         list_for_each_entry(opp, &dev_opp->opp_list, node) {
>>>                 if (opp->available) {
>>>                         freq_table[i].driver_data = i;
>>>                         freq_table[i].frequency = opp->rate / 1000;
>>> +                       for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>>> +                               if (boost_freqs[j] == freq_table[i].frequency) {
>>> +                                       freq_table[i].driver_data =
>>> +                                                       CPUFREQ_BOOST_FREQ;
>>> +                                       break;
>>> +                               }
>>> +                       }
>>
>> What if any one of the boost_freqs are not contained in the enabled frequencies?
> 
> It is not used as a boost frequency because its corresponding voltage
> is not known. If required a warning can be printed out for the same.

yes - that would be good, as it helps debug if there are developer
errors in dts.


-- 
Regards,
Nishanth Menon

Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Sudeep Holla]

On 07/02/14 15:19, Thomas Abraham wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
> 
> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
> support for CPU boost mode. This patch adds support for finding available
> boost frequencies from device tree and marking them as usable in boost mode.
> 
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index fa41874..b636826 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>  	struct device_opp *dev_opp;
>  	struct dev_pm_opp *opp;
>  	struct cpufreq_frequency_table *freq_table;
> -	int i = 0;
> +	int i = 0, j, len, ret;
> +	u32 *boost_freqs = NULL;
>  
>  	/* Pretend as if I am an updater */
>  	mutex_lock(&dev_opp_list_lock);
> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>  		return -ENOMEM;
>  	}
>  
> +	if (of_find_property(dev->of_node, "boost-frequency", &len)) {
> +		if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
> +			dev_err(dev, "%s: invalid boost frequency\n", __func__);
> +			ret = -EINVAL;
> +			goto err_boost;
> +		}
> +
> +		boost_freqs = kzalloc(len, GFP_KERNEL);
> +		if (!boost_freqs) {
> +			dev_warn(dev, "%s: no memory for boost freq table\n",
> +					__func__);
> +			ret = -ENOMEM;
> +			goto err_boost;
> +		}
> +		of_property_read_u32_array(dev->of_node, "boost-frequency",
> +			boost_freqs, len / sizeof(u32));
> +	}
> +
>  	list_for_each_entry(opp, &dev_opp->opp_list, node) {
>  		if (opp->available) {
>  			freq_table[i].driver_data = i;
>  			freq_table[i].frequency = opp->rate / 1000;
> +			for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
> +				if (boost_freqs[j] == freq_table[i].frequency) {
> +					freq_table[i].driver_data =
> +							CPUFREQ_BOOST_FREQ;
> +					break;
> +				}
> +			}
>  			i++;
>  		}
>  	}
IIRC you had mentioned that the boost-opp was not limited to be a cpufreq, but
this change seems to be cpufreq only.

Regards,
Sudeep

[PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Sudeep Holla]

On 07/02/14 15:19, Thomas Abraham wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
> 
> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
> support for CPU boost mode. This patch adds support for finding available
> boost frequencies from device tree and marking them as usable in boost mode.
> 
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index fa41874..b636826 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>  	struct device_opp *dev_opp;
>  	struct dev_pm_opp *opp;
>  	struct cpufreq_frequency_table *freq_table;
> -	int i = 0;
> +	int i = 0, j, len, ret;
> +	u32 *boost_freqs = NULL;
>  
>  	/* Pretend as if I am an updater */
>  	mutex_lock(&dev_opp_list_lock);
> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>  		return -ENOMEM;
>  	}
>  
> +	if (of_find_property(dev->of_node, "boost-frequency", &len)) {
> +		if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
> +			dev_err(dev, "%s: invalid boost frequency\n", __func__);
> +			ret = -EINVAL;
> +			goto err_boost;
> +		}
> +
> +		boost_freqs = kzalloc(len, GFP_KERNEL);
> +		if (!boost_freqs) {
> +			dev_warn(dev, "%s: no memory for boost freq table\n",
> +					__func__);
> +			ret = -ENOMEM;
> +			goto err_boost;
> +		}
> +		of_property_read_u32_array(dev->of_node, "boost-frequency",
> +			boost_freqs, len / sizeof(u32));
> +	}
> +
>  	list_for_each_entry(opp, &dev_opp->opp_list, node) {
>  		if (opp->available) {
>  			freq_table[i].driver_data = i;
>  			freq_table[i].frequency = opp->rate / 1000;
> +			for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
> +				if (boost_freqs[j] == freq_table[i].frequency) {
> +					freq_table[i].driver_data =
> +							CPUFREQ_BOOST_FREQ;
> +					break;
> +				}
> +			}
>  			i++;
>  		}
>  	}
IIRC you had mentioned that the boost-opp was not limited to be a cpufreq, but
this change seems to be cpufreq only.

Regards,
Sudeep

Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Thomas Abraham]

On Fri, Feb 7, 2014 at 9:31 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 15:19, Thomas Abraham wrote:
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> support for CPU boost mode. This patch adds support for finding available
>> boost frequencies from device tree and marking them as usable in boost mode.
>>
>> Cc: Nishanth Menon <nm@ti.com>
>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>>  1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>> index fa41874..b636826 100644
>> --- a/drivers/base/power/opp.c
>> +++ b/drivers/base/power/opp.c
>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>       struct device_opp *dev_opp;
>>       struct dev_pm_opp *opp;
>>       struct cpufreq_frequency_table *freq_table;
>> -     int i = 0;
>> +     int i = 0, j, len, ret;
>> +     u32 *boost_freqs = NULL;
>>
>>       /* Pretend as if I am an updater */
>>       mutex_lock(&dev_opp_list_lock);
>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>               return -ENOMEM;
>>       }
>>
>> +     if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>> +             if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>> +                     dev_err(dev, "%s: invalid boost frequency\n", __func__);
>> +                     ret = -EINVAL;
>> +                     goto err_boost;
>> +             }
>> +
>> +             boost_freqs = kzalloc(len, GFP_KERNEL);
>> +             if (!boost_freqs) {
>> +                     dev_warn(dev, "%s: no memory for boost freq table\n",
>> +                                     __func__);
>> +                     ret = -ENOMEM;
>> +                     goto err_boost;
>> +             }
>> +             of_property_read_u32_array(dev->of_node, "boost-frequency",
>> +                     boost_freqs, len / sizeof(u32));
>> +     }
>> +
>>       list_for_each_entry(opp, &dev_opp->opp_list, node) {
>>               if (opp->available) {
>>                       freq_table[i].driver_data = i;
>>                       freq_table[i].frequency = opp->rate / 1000;
>> +                     for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>> +                             if (boost_freqs[j] == freq_table[i].frequency) {
>> +                                     freq_table[i].driver_data =
>> +                                                     CPUFREQ_BOOST_FREQ;
>> +                                     break;
>> +                             }
>> +                     }
>>                       i++;
>>               }
>>       }
> IIRC you had mentioned that the boost-opp was not limited to be a cpufreq, but
> this change seems to be cpufreq only.

Yes, but as you have initiated the discussion on extending the OPP
binding, this has been limited to cpufreq only. If the new OPP library
has support for listing boost frequency, this can be migrated to the
new OPP libaray.

Thanks,
Thomas.

>
> Regards,
> Sudeep
>

[PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Thomas Abraham]

On Fri, Feb 7, 2014 at 9:31 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 15:19, Thomas Abraham wrote:
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> support for CPU boost mode. This patch adds support for finding available
>> boost frequencies from device tree and marking them as usable in boost mode.
>>
>> Cc: Nishanth Menon <nm@ti.com>
>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>>  1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>> index fa41874..b636826 100644
>> --- a/drivers/base/power/opp.c
>> +++ b/drivers/base/power/opp.c
>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>       struct device_opp *dev_opp;
>>       struct dev_pm_opp *opp;
>>       struct cpufreq_frequency_table *freq_table;
>> -     int i = 0;
>> +     int i = 0, j, len, ret;
>> +     u32 *boost_freqs = NULL;
>>
>>       /* Pretend as if I am an updater */
>>       mutex_lock(&dev_opp_list_lock);
>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>               return -ENOMEM;
>>       }
>>
>> +     if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>> +             if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>> +                     dev_err(dev, "%s: invalid boost frequency\n", __func__);
>> +                     ret = -EINVAL;
>> +                     goto err_boost;
>> +             }
>> +
>> +             boost_freqs = kzalloc(len, GFP_KERNEL);
>> +             if (!boost_freqs) {
>> +                     dev_warn(dev, "%s: no memory for boost freq table\n",
>> +                                     __func__);
>> +                     ret = -ENOMEM;
>> +                     goto err_boost;
>> +             }
>> +             of_property_read_u32_array(dev->of_node, "boost-frequency",
>> +                     boost_freqs, len / sizeof(u32));
>> +     }
>> +
>>       list_for_each_entry(opp, &dev_opp->opp_list, node) {
>>               if (opp->available) {
>>                       freq_table[i].driver_data = i;
>>                       freq_table[i].frequency = opp->rate / 1000;
>> +                     for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>> +                             if (boost_freqs[j] == freq_table[i].frequency) {
>> +                                     freq_table[i].driver_data =
>> +                                                     CPUFREQ_BOOST_FREQ;
>> +                                     break;
>> +                             }
>> +                     }
>>                       i++;
>>               }
>>       }
> IIRC you had mentioned that the boost-opp was not limited to be a cpufreq, but
> this change seems to be cpufreq only.

Yes, but as you have initiated the discussion on extending the OPP
binding, this has been limited to cpufreq only. If the new OPP library
has support for listing boost frequency, this can be migrated to the
new OPP libaray.

Thanks,
Thomas.

>
> Regards,
> Sudeep
>

Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Lukasz Majewski]

Hi Thomas, Sudeep

> On Fri, Feb 7, 2014 at 9:31 PM, Sudeep Holla <Sudeep.Holla@arm.com>
> wrote:
> > On 07/02/14 15:19, Thomas Abraham wrote:
> >> From: Thomas Abraham <thomas.ab@samsung.com>
> >>
> >> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core")
> >> adds support for CPU boost mode. This patch adds support for
> >> finding available boost frequencies from device tree and marking
> >> them as usable in boost mode.
> >>
> >> Cc: Nishanth Menon <nm@ti.com>
> >> Cc: Lukasz Majewski <l.majewski@samsung.com>
> >> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> >> ---
> >>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
> >>  1 file changed, 33 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> >> index fa41874..b636826 100644
> >> --- a/drivers/base/power/opp.c
> >> +++ b/drivers/base/power/opp.c
> >> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct
> >> device *dev, struct device_opp *dev_opp;
> >>       struct dev_pm_opp *opp;
> >>       struct cpufreq_frequency_table *freq_table;
> >> -     int i = 0;
> >> +     int i = 0, j, len, ret;
> >> +     u32 *boost_freqs = NULL;
> >>
> >>       /* Pretend as if I am an updater */
> >>       mutex_lock(&dev_opp_list_lock);
> >> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct
> >> device *dev, return -ENOMEM;
> >>       }
> >>
> >> +     if (of_find_property(dev->of_node, "boost-frequency", &len))
> >> {
> >> +             if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
> >> +                     dev_err(dev, "%s: invalid boost
> >> frequency\n", __func__);
> >> +                     ret = -EINVAL;
> >> +                     goto err_boost;
> >> +             }
> >> +
> >> +             boost_freqs = kzalloc(len, GFP_KERNEL);
> >> +             if (!boost_freqs) {
> >> +                     dev_warn(dev, "%s: no memory for boost freq
> >> table\n",
> >> +                                     __func__);
> >> +                     ret = -ENOMEM;
> >> +                     goto err_boost;
> >> +             }
> >> +             of_property_read_u32_array(dev->of_node,
> >> "boost-frequency",
> >> +                     boost_freqs, len / sizeof(u32));
> >> +     }
> >> +
> >>       list_for_each_entry(opp, &dev_opp->opp_list, node) {
> >>               if (opp->available) {
> >>                       freq_table[i].driver_data = i;
> >>                       freq_table[i].frequency = opp->rate / 1000;
> >> +                     for (j = 0; j < len / sizeof(u32) &&
> >> boost_freqs; j++) {
> >> +                             if (boost_freqs[j] ==
> >> freq_table[i].frequency) {
> >> +                                     freq_table[i].driver_data =
> >> +
> >> CPUFREQ_BOOST_FREQ;
> >> +                                     break;
> >> +                             }
> >> +                     }
> >>                       i++;
> >>               }
> >>       }
> > IIRC you had mentioned that the boost-opp was not limited to be a
> > cpufreq, but this change seems to be cpufreq only.
> 
> Yes, but as you have initiated the discussion on extending the OPP
> binding, this has been limited to cpufreq only. If the new OPP library
> has support for listing boost frequency, this can be migrated to the
> new OPP libaray.

I agree here with Thomas. Since we are fixing regression here, we shall
use the existing OPP API. When agreement for the future OPPs format is
in place, we will port the boost OPPs to it.

> 
> Thanks,
> Thomas.
> 
> >
> > Regards,
> > Sudeep
> >
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Lukasz Majewski]

Hi Thomas, Sudeep

> On Fri, Feb 7, 2014 at 9:31 PM, Sudeep Holla <Sudeep.Holla@arm.com>
> wrote:
> > On 07/02/14 15:19, Thomas Abraham wrote:
> >> From: Thomas Abraham <thomas.ab@samsung.com>
> >>
> >> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core")
> >> adds support for CPU boost mode. This patch adds support for
> >> finding available boost frequencies from device tree and marking
> >> them as usable in boost mode.
> >>
> >> Cc: Nishanth Menon <nm@ti.com>
> >> Cc: Lukasz Majewski <l.majewski@samsung.com>
> >> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> >> ---
> >>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
> >>  1 file changed, 33 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> >> index fa41874..b636826 100644
> >> --- a/drivers/base/power/opp.c
> >> +++ b/drivers/base/power/opp.c
> >> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct
> >> device *dev, struct device_opp *dev_opp;
> >>       struct dev_pm_opp *opp;
> >>       struct cpufreq_frequency_table *freq_table;
> >> -     int i = 0;
> >> +     int i = 0, j, len, ret;
> >> +     u32 *boost_freqs = NULL;
> >>
> >>       /* Pretend as if I am an updater */
> >>       mutex_lock(&dev_opp_list_lock);
> >> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct
> >> device *dev, return -ENOMEM;
> >>       }
> >>
> >> +     if (of_find_property(dev->of_node, "boost-frequency", &len))
> >> {
> >> +             if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
> >> +                     dev_err(dev, "%s: invalid boost
> >> frequency\n", __func__);
> >> +                     ret = -EINVAL;
> >> +                     goto err_boost;
> >> +             }
> >> +
> >> +             boost_freqs = kzalloc(len, GFP_KERNEL);
> >> +             if (!boost_freqs) {
> >> +                     dev_warn(dev, "%s: no memory for boost freq
> >> table\n",
> >> +                                     __func__);
> >> +                     ret = -ENOMEM;
> >> +                     goto err_boost;
> >> +             }
> >> +             of_property_read_u32_array(dev->of_node,
> >> "boost-frequency",
> >> +                     boost_freqs, len / sizeof(u32));
> >> +     }
> >> +
> >>       list_for_each_entry(opp, &dev_opp->opp_list, node) {
> >>               if (opp->available) {
> >>                       freq_table[i].driver_data = i;
> >>                       freq_table[i].frequency = opp->rate / 1000;
> >> +                     for (j = 0; j < len / sizeof(u32) &&
> >> boost_freqs; j++) {
> >> +                             if (boost_freqs[j] ==
> >> freq_table[i].frequency) {
> >> +                                     freq_table[i].driver_data =
> >> +
> >> CPUFREQ_BOOST_FREQ;
> >> +                                     break;
> >> +                             }
> >> +                     }
> >>                       i++;
> >>               }
> >>       }
> > IIRC you had mentioned that the boost-opp was not limited to be a
> > cpufreq, but this change seems to be cpufreq only.
> 
> Yes, but as you have initiated the discussion on extending the OPP
> binding, this has been limited to cpufreq only. If the new OPP library
> has support for listing boost frequency, this can be migrated to the
> new OPP libaray.

I agree here with Thomas. Since we are fixing regression here, we shall
use the existing OPP API. When agreement for the future OPPs format is
in place, we will port the boost OPPs to it.

> 
> Thanks,
> Thomas.
> 
> >
> > Regards,
> > Sudeep
> >
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Sudeep Holla]

On 08/02/14 05:10, Thomas Abraham wrote:
> On Fri, Feb 7, 2014 at 9:31 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 15:19, Thomas Abraham wrote:
>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>
>>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>>> support for CPU boost mode. This patch adds support for finding available
>>> boost frequencies from device tree and marking them as usable in boost mode.
>>>
>>> Cc: Nishanth Menon <nm@ti.com>
>>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>> ---
>>>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>>>  1 file changed, 33 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>>> index fa41874..b636826 100644
>>> --- a/drivers/base/power/opp.c
>>> +++ b/drivers/base/power/opp.c
>>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>>       struct device_opp *dev_opp;
>>>       struct dev_pm_opp *opp;
>>>       struct cpufreq_frequency_table *freq_table;
>>> -     int i = 0;
>>> +     int i = 0, j, len, ret;
>>> +     u32 *boost_freqs = NULL;
>>>
>>>       /* Pretend as if I am an updater */
>>>       mutex_lock(&dev_opp_list_lock);
>>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>>               return -ENOMEM;
>>>       }
>>>
>>> +     if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>>> +             if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>>> +                     dev_err(dev, "%s: invalid boost frequency\n", __func__);
>>> +                     ret = -EINVAL;
>>> +                     goto err_boost;
>>> +             }
>>> +
>>> +             boost_freqs = kzalloc(len, GFP_KERNEL);
>>> +             if (!boost_freqs) {
>>> +                     dev_warn(dev, "%s: no memory for boost freq table\n",
>>> +                                     __func__);
>>> +                     ret = -ENOMEM;
>>> +                     goto err_boost;
>>> +             }
>>> +             of_property_read_u32_array(dev->of_node, "boost-frequency",
>>> +                     boost_freqs, len / sizeof(u32));
>>> +     }
>>> +
>>>       list_for_each_entry(opp, &dev_opp->opp_list, node) {
>>>               if (opp->available) {
>>>                       freq_table[i].driver_data = i;
>>>                       freq_table[i].frequency = opp->rate / 1000;
>>> +                     for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>>> +                             if (boost_freqs[j] == freq_table[i].frequency) {
>>> +                                     freq_table[i].driver_data =
>>> +                                                     CPUFREQ_BOOST_FREQ;
>>> +                                     break;
>>> +                             }
>>> +                     }
>>>                       i++;
>>>               }
>>>       }
>> IIRC you had mentioned that the boost-opp was not limited to be a cpufreq, but
>> this change seems to be cpufreq only.
> 
> Yes, but as you have initiated the discussion on extending the OPP
> binding, this has been limited to cpufreq only. If the new OPP library
> has support for listing boost frequency, this can be migrated to the
> new OPP libaray.
> 

Fair enough, just wanted to check as I couldn't get the info following the
thread. I might have missed it.

Regards,
Sudeep

[PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree

[Sudeep Holla]

On 08/02/14 05:10, Thomas Abraham wrote:
> On Fri, Feb 7, 2014 at 9:31 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 15:19, Thomas Abraham wrote:
>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>
>>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>>> support for CPU boost mode. This patch adds support for finding available
>>> boost frequencies from device tree and marking them as usable in boost mode.
>>>
>>> Cc: Nishanth Menon <nm@ti.com>
>>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>> ---
>>>  drivers/base/power/opp.c |   34 +++++++++++++++++++++++++++++++++-
>>>  1 file changed, 33 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>>> index fa41874..b636826 100644
>>> --- a/drivers/base/power/opp.c
>>> +++ b/drivers/base/power/opp.c
>>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>>       struct device_opp *dev_opp;
>>>       struct dev_pm_opp *opp;
>>>       struct cpufreq_frequency_table *freq_table;
>>> -     int i = 0;
>>> +     int i = 0, j, len, ret;
>>> +     u32 *boost_freqs = NULL;
>>>
>>>       /* Pretend as if I am an updater */
>>>       mutex_lock(&dev_opp_list_lock);
>>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>>               return -ENOMEM;
>>>       }
>>>
>>> +     if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>>> +             if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>>> +                     dev_err(dev, "%s: invalid boost frequency\n", __func__);
>>> +                     ret = -EINVAL;
>>> +                     goto err_boost;
>>> +             }
>>> +
>>> +             boost_freqs = kzalloc(len, GFP_KERNEL);
>>> +             if (!boost_freqs) {
>>> +                     dev_warn(dev, "%s: no memory for boost freq table\n",
>>> +                                     __func__);
>>> +                     ret = -ENOMEM;
>>> +                     goto err_boost;
>>> +             }
>>> +             of_property_read_u32_array(dev->of_node, "boost-frequency",
>>> +                     boost_freqs, len / sizeof(u32));
>>> +     }
>>> +
>>>       list_for_each_entry(opp, &dev_opp->opp_list, node) {
>>>               if (opp->available) {
>>>                       freq_table[i].driver_data = i;
>>>                       freq_table[i].frequency = opp->rate / 1000;
>>> +                     for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>>> +                             if (boost_freqs[j] == freq_table[i].frequency) {
>>> +                                     freq_table[i].driver_data =
>>> +                                                     CPUFREQ_BOOST_FREQ;
>>> +                                     break;
>>> +                             }
>>> +                     }
>>>                       i++;
>>>               }
>>>       }
>> IIRC you had mentioned that the boost-opp was not limited to be a cpufreq, but
>> this change seems to be cpufreq only.
> 
> Yes, but as you have initiated the discussion on extending the OPP
> binding, this has been limited to cpufreq only. If the new OPP library
> has support for listing boost frequency, this can be migrated to the
> new OPP libaray.
> 

Fair enough, just wanted to check as I couldn't get the info following the
thread. I might have missed it.

Regards,
Sudeep

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Thomas Abraham]

From: Thomas Abraham <thomas.ab@samsung.com>

Add a new optional boost-frequency binding for specifying the frequencies
usable in boost mode.

Cc: Nishanth Menon <nm@ti.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
new file mode 100644
index 0000000..d925e38
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
@@ -0,0 +1,11 @@
+* Device tree binding for CPU boost frequency (aka over-clocking)
+
+Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
+overclocking) in which the CPU can operate in frequencies beyond the normal
+operating conditions.
+
+Optional Properties:
+- boost-frequency: list of frequencies in KHz to be used only in boost mode.
+  This list should be a subset of frequencies listed in "operating-points"
+  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
+  details about "operating-points" property.
-- 
1.7.10.4

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Thomas Abraham]

From: Thomas Abraham <thomas.ab@samsung.com>

Add a new optional boost-frequency binding for specifying the frequencies
usable in boost mode.

Cc: Nishanth Menon <nm@ti.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
new file mode 100644
index 0000000..d925e38
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
@@ -0,0 +1,11 @@
+* Device tree binding for CPU boost frequency (aka over-clocking)
+
+Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
+overclocking) in which the CPU can operate in frequencies beyond the normal
+operating conditions.
+
+Optional Properties:
+- boost-frequency: list of frequencies in KHz to be used only in boost mode.
+  This list should be a subset of frequencies listed in "operating-points"
+  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
+  details about "operating-points" property.
-- 
1.7.10.4

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Nishanth Menon]

On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> Add a new optional boost-frequency binding for specifying the frequencies
> usable in boost mode.
>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>  1 file changed, 11 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
> new file mode 100644
> index 0000000..d925e38
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
> @@ -0,0 +1,11 @@
> +* Device tree binding for CPU boost frequency (aka over-clocking)
> +
> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
> +overclocking) in which the CPU can operate in frequencies beyond the normal
> +operating conditions.
> +
> +Optional Properties:
> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.

boost-frequencies?

> +  This list should be a subset of frequencies listed in "operating-points"
> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
> +  details about "operating-points" property.
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Nishanth Menon]

On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> Add a new optional boost-frequency binding for specifying the frequencies
> usable in boost mode.
>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>  1 file changed, 11 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
> new file mode 100644
> index 0000000..d925e38
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
> @@ -0,0 +1,11 @@
> +* Device tree binding for CPU boost frequency (aka over-clocking)
> +
> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
> +overclocking) in which the CPU can operate in frequencies beyond the normal
> +operating conditions.
> +
> +Optional Properties:
> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.

boost-frequencies?

> +  This list should be a subset of frequencies listed in "operating-points"
> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
> +  details about "operating-points" property.
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Thomas Abraham]

On Fri, Feb 7, 2014 at 8:57 PM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Add a new optional boost-frequency binding for specifying the frequencies
>> usable in boost mode.
>>
>> Cc: Nishanth Menon <nm@ti.com>
>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> new file mode 100644
>> index 0000000..d925e38
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> @@ -0,0 +1,11 @@
>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>> +
>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
>> +overclocking) in which the CPU can operate in frequencies beyond the normal
>> +operating conditions.
>> +
>> +Optional Properties:
>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
>
> boost-frequencies?

Okay, I will change it.

Thanks,
Thomas.

>
>> +  This list should be a subset of frequencies listed in "operating-points"
>> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>> +  details about "operating-points" property.
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Thomas Abraham]

On Fri, Feb 7, 2014 at 8:57 PM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 9:19 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Add a new optional boost-frequency binding for specifying the frequencies
>> usable in boost mode.
>>
>> Cc: Nishanth Menon <nm@ti.com>
>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> new file mode 100644
>> index 0000000..d925e38
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> @@ -0,0 +1,11 @@
>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>> +
>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
>> +overclocking) in which the CPU can operate in frequencies beyond the normal
>> +operating conditions.
>> +
>> +Optional Properties:
>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
>
> boost-frequencies?

Okay, I will change it.

Thanks,
Thomas.

>
>> +  This list should be a subset of frequencies listed in "operating-points"
>> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>> +  details about "operating-points" property.
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 07/02/14 15:19, Thomas Abraham wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
> 
> Add a new optional boost-frequency binding for specifying the frequencies
> usable in boost mode.
> 
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>  1 file changed, 11 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
> new file mode 100644
> index 0000000..d925e38
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
> @@ -0,0 +1,11 @@
> +* Device tree binding for CPU boost frequency (aka over-clocking)
> +
> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
> +overclocking) in which the CPU can operate in frequencies beyond the normal
> +operating conditions.
> +
> +Optional Properties:
> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
> +  This list should be a subset of frequencies listed in "operating-points"
> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
> +  details about "operating-points" property.
> 

Won't single entry for boost frequency suffice which would be the starting
frequency in the boost range. IWO will there be OPP list with frequencies:
A > B > C > D, but only B and C are boost frequency. That seems little odd,
unless it's some configuration chosen purely on software basis rather than
hardware. For me B marks the beginning of over-clocking.

Regards,
Sudeep

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 07/02/14 15:19, Thomas Abraham wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
> 
> Add a new optional boost-frequency binding for specifying the frequencies
> usable in boost mode.
> 
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>  1 file changed, 11 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
> new file mode 100644
> index 0000000..d925e38
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
> @@ -0,0 +1,11 @@
> +* Device tree binding for CPU boost frequency (aka over-clocking)
> +
> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
> +overclocking) in which the CPU can operate in frequencies beyond the normal
> +operating conditions.
> +
> +Optional Properties:
> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
> +  This list should be a subset of frequencies listed in "operating-points"
> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
> +  details about "operating-points" property.
> 

Won't single entry for boost frequency suffice which would be the starting
frequency in the boost range. IWO will there be OPP list with frequencies:
A > B > C > D, but only B and C are boost frequency. That seems little odd,
unless it's some configuration chosen purely on software basis rather than
hardware. For me B marks the beginning of over-clocking.

Regards,
Sudeep

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 07/02/14 16:15, Sudeep Holla wrote:
> On 07/02/14 15:19, Thomas Abraham wrote:
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Add a new optional boost-frequency binding for specifying the frequencies
>> usable in boost mode.
>>
>> Cc: Nishanth Menon <nm@ti.com>
>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> new file mode 100644
>> index 0000000..d925e38
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> @@ -0,0 +1,11 @@
>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>> +
>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
>> +overclocking) in which the CPU can operate in frequencies beyond the normal
>> +operating conditions.
>> +
>> +Optional Properties:
>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
>> +  This list should be a subset of frequencies listed in "operating-points"
>> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>> +  details about "operating-points" property.
>>
> 
> Won't single entry for boost frequency suffice which would be the starting
> frequency in the boost range. IOW will there be OPP list with frequencies:
> A > B > C > D, but only B and C are boost frequency. That seems little odd,
> unless it's some configuration chosen purely on software basis rather than
> hardware. For me B marks the beginning of over-clocking.
> 
Ah, I meant A < B < C < D in the above example.

Regards,
Sudeep

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 07/02/14 16:15, Sudeep Holla wrote:
> On 07/02/14 15:19, Thomas Abraham wrote:
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Add a new optional boost-frequency binding for specifying the frequencies
>> usable in boost mode.
>>
>> Cc: Nishanth Menon <nm@ti.com>
>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> new file mode 100644
>> index 0000000..d925e38
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>> @@ -0,0 +1,11 @@
>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>> +
>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
>> +overclocking) in which the CPU can operate in frequencies beyond the normal
>> +operating conditions.
>> +
>> +Optional Properties:
>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
>> +  This list should be a subset of frequencies listed in "operating-points"
>> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>> +  details about "operating-points" property.
>>
> 
> Won't single entry for boost frequency suffice which would be the starting
> frequency in the boost range. IOW will there be OPP list with frequencies:
> A > B > C > D, but only B and C are boost frequency. That seems little odd,
> unless it's some configuration chosen purely on software basis rather than
> hardware. For me B marks the beginning of over-clocking.
> 
Ah, I meant A < B < C < D in the above example.

Regards,
Sudeep

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Nishanth Menon]

On Fri, Feb 7, 2014 at 10:28 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 16:15, Sudeep Holla wrote:
>> On 07/02/14 15:19, Thomas Abraham wrote:
>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>
>>> Add a new optional boost-frequency binding for specifying the frequencies
>>> usable in boost mode.
>>>
>>> Cc: Nishanth Menon <nm@ti.com>
>>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>> Cc: Kumar Gala <galak@codeaurora.org>
>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>> ---
>>>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>>>  1 file changed, 11 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>> new file mode 100644
>>> index 0000000..d925e38
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>> @@ -0,0 +1,11 @@
>>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>>> +
>>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
>>> +overclocking) in which the CPU can operate in frequencies beyond the normal
>>> +operating conditions.
>>> +
>>> +Optional Properties:
>>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
>>> +  This list should be a subset of frequencies listed in "operating-points"
>>> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>>> +  details about "operating-points" property.
>>>
>>
>> Won't single entry for boost frequency suffice which would be the starting
>> frequency in the boost range. IOW will there be OPP list with frequencies:
>> A > B > C > D, but only B and C are boost frequency. That seems little odd,
>> unless it's some configuration chosen purely on software basis rather than
>> hardware. For me B marks the beginning of over-clocking.
>>
> Ah, I meant A < B < C < D in the above example.
Should'nt we let the SoC dts define that - traditionally, yes, but
consider the following:
A, B, C uses clk_parent X which describes B, C as overclocked.
and say D uses clk_parent Y which is not "over clocked", then you have
the scenario that on the first look seems counter-intutive.

Regards,
Nishanth Menon

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Nishanth Menon]

On Fri, Feb 7, 2014 at 10:28 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 16:15, Sudeep Holla wrote:
>> On 07/02/14 15:19, Thomas Abraham wrote:
>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>
>>> Add a new optional boost-frequency binding for specifying the frequencies
>>> usable in boost mode.
>>>
>>> Cc: Nishanth Menon <nm@ti.com>
>>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>> Cc: Kumar Gala <galak@codeaurora.org>
>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>> ---
>>>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>>>  1 file changed, 11 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>> new file mode 100644
>>> index 0000000..d925e38
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>> @@ -0,0 +1,11 @@
>>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>>> +
>>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
>>> +overclocking) in which the CPU can operate in frequencies beyond the normal
>>> +operating conditions.
>>> +
>>> +Optional Properties:
>>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
>>> +  This list should be a subset of frequencies listed in "operating-points"
>>> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>>> +  details about "operating-points" property.
>>>
>>
>> Won't single entry for boost frequency suffice which would be the starting
>> frequency in the boost range. IOW will there be OPP list with frequencies:
>> A > B > C > D, but only B and C are boost frequency. That seems little odd,
>> unless it's some configuration chosen purely on software basis rather than
>> hardware. For me B marks the beginning of over-clocking.
>>
> Ah, I meant A < B < C < D in the above example.
Should'nt we let the SoC dts define that - traditionally, yes, but
consider the following:
A, B, C uses clk_parent X which describes B, C as overclocked.
and say D uses clk_parent Y which is not "over clocked", then you have
the scenario that on the first look seems counter-intutive.

Regards,
Nishanth Menon

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 07/02/14 16:43, Nishanth Menon wrote:
> On Fri, Feb 7, 2014 at 10:28 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 16:15, Sudeep Holla wrote:
>>> On 07/02/14 15:19, Thomas Abraham wrote:
>>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>>
>>>> Add a new optional boost-frequency binding for specifying the frequencies
>>>> usable in boost mode.
>>>>
>>>> Cc: Nishanth Menon <nm@ti.com>
>>>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>>>>  1 file changed, 11 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>> new file mode 100644
>>>> index 0000000..d925e38
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>> @@ -0,0 +1,11 @@
>>>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>>>> +
>>>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
>>>> +overclocking) in which the CPU can operate in frequencies beyond the normal
>>>> +operating conditions.
>>>> +
>>>> +Optional Properties:
>>>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
>>>> +  This list should be a subset of frequencies listed in "operating-points"
>>>> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>>>> +  details about "operating-points" property.
>>>>
>>>
>>> Won't single entry for boost frequency suffice which would be the starting
>>> frequency in the boost range. IOW will there be OPP list with frequencies:
>>> A > B > C > D, but only B and C are boost frequency. That seems little odd,
>>> unless it's some configuration chosen purely on software basis rather than
>>> hardware. For me B marks the beginning of over-clocking.
>>>
>> Ah, I meant A < B < C < D in the above example.
>
> Should'nt we let the SoC dts define that - traditionally, yes, but
> consider the following:
> A, B, C uses clk_parent X which describes B, C as overclocked.
> and say D uses clk_parent Y which is not "over clocked", then you have
> the scenario that on the first look seems counter-intutive.
> 

Yes I thought of exactly similar clock setup, but was not convinced that it
should be part of OPP. In that case it looks like we are trying to represent
clock internals through some OPP bindings.

Yes I think its counter-intuitive as it's visible to the userspace(list of
frequencies and the boost parameters are exposed through sysfs)

Regards,
Sudeep

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 07/02/14 16:43, Nishanth Menon wrote:
> On Fri, Feb 7, 2014 at 10:28 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 16:15, Sudeep Holla wrote:
>>> On 07/02/14 15:19, Thomas Abraham wrote:
>>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>>
>>>> Add a new optional boost-frequency binding for specifying the frequencies
>>>> usable in boost mode.
>>>>
>>>> Cc: Nishanth Menon <nm@ti.com>
>>>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt |   11 +++++++++++
>>>>  1 file changed, 11 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>> new file mode 100644
>>>> index 0000000..d925e38
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
>>>> @@ -0,0 +1,11 @@
>>>> +* Device tree binding for CPU boost frequency (aka over-clocking)
>>>> +
>>>> +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
>>>> +overclocking) in which the CPU can operate in frequencies beyond the normal
>>>> +operating conditions.
>>>> +
>>>> +Optional Properties:
>>>> +- boost-frequency: list of frequencies in KHz to be used only in boost mode.
>>>> +  This list should be a subset of frequencies listed in "operating-points"
>>>> +  property. Refer to Documentation/devicetree/bindings/power/opp.txt for
>>>> +  details about "operating-points" property.
>>>>
>>>
>>> Won't single entry for boost frequency suffice which would be the starting
>>> frequency in the boost range. IOW will there be OPP list with frequencies:
>>> A > B > C > D, but only B and C are boost frequency. That seems little odd,
>>> unless it's some configuration chosen purely on software basis rather than
>>> hardware. For me B marks the beginning of over-clocking.
>>>
>> Ah, I meant A < B < C < D in the above example.
>
> Should'nt we let the SoC dts define that - traditionally, yes, but
> consider the following:
> A, B, C uses clk_parent X which describes B, C as overclocked.
> and say D uses clk_parent Y which is not "over clocked", then you have
> the scenario that on the first look seems counter-intutive.
> 

Yes I thought of exactly similar clock setup, but was not convinced that it
should be part of OPP. In that case it looks like we are trying to represent
clock internals through some OPP bindings.

Yes I think its counter-intuitive as it's visible to the userspace(list of
frequencies and the boost parameters are exposed through sysfs)

Regards,
Sudeep

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Nishanth Menon]

On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> Yes I thought of exactly similar clock setup, but was not convinced that it
> should be part of OPP. In that case it looks like we are trying to represent
> clock internals through some OPP bindings.

And this series (rightly) does not make it an OPP behavior. instead
all it does is to list the boost-frequencies and mark those in cpufreq
table. the description is left to the dts and implementation to the
clock drivers involved.


> Yes I think its counter-intuitive as it's visible to the userspace(list of
> frequencies and the boost parameters are exposed through sysfs)

That will be a different problem -> as currently every single
frequency in the cpufreq list has ability to be marked as boost
frequency - if userspace does not maintain that, then, IMHO, fix the
userspace :D

Regards,
Nishanth Menon

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Nishanth Menon]

On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> Yes I thought of exactly similar clock setup, but was not convinced that it
> should be part of OPP. In that case it looks like we are trying to represent
> clock internals through some OPP bindings.

And this series (rightly) does not make it an OPP behavior. instead
all it does is to list the boost-frequencies and mark those in cpufreq
table. the description is left to the dts and implementation to the
clock drivers involved.


> Yes I think its counter-intuitive as it's visible to the userspace(list of
> frequencies and the boost parameters are exposed through sysfs)

That will be a different problem -> as currently every single
frequency in the cpufreq list has ability to be marked as boost
frequency - if userspace does not maintain that, then, IMHO, fix the
userspace :D

Regards,
Nishanth Menon

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Nishanth Menon]

On Fri, Feb 7, 2014 at 11:37 AM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> Yes I thought of exactly similar clock setup, but was not convinced that it
>> should be part of OPP. In that case it looks like we are trying to represent
>> clock internals through some OPP bindings.
>
> And this series (rightly) does not make it an OPP behavior. instead
> all it does is to list the boost-frequencies and mark those in cpufreq
> table. the description is left to the dts and implementation to the
> clock drivers involved.


One more thing, before I forget -> currently
dev_pm_opp_[init|free]_cpufreq_table is in drivers/base/power/opp.c ->
this probably should go away to drivers/cpufreq to keep opp.c
independent of frameworks using it. i dont see any code that is
introduced in the mentioned functions as being OPP behavior specific,
instead, I consider them as cpufreq+opp behaviors, which this change
fits into.

Regards,
Nishanth Menon

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Nishanth Menon]

On Fri, Feb 7, 2014 at 11:37 AM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> Yes I thought of exactly similar clock setup, but was not convinced that it
>> should be part of OPP. In that case it looks like we are trying to represent
>> clock internals through some OPP bindings.
>
> And this series (rightly) does not make it an OPP behavior. instead
> all it does is to list the boost-frequencies and mark those in cpufreq
> table. the description is left to the dts and implementation to the
> clock drivers involved.


One more thing, before I forget -> currently
dev_pm_opp_[init|free]_cpufreq_table is in drivers/base/power/opp.c ->
this probably should go away to drivers/cpufreq to keep opp.c
independent of frameworks using it. i dont see any code that is
introduced in the mentioned functions as being OPP behavior specific,
instead, I consider them as cpufreq+opp behaviors, which this change
fits into.

Regards,
Nishanth Menon

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 07/02/14 17:37, Nishanth Menon wrote:
> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:

[...]

>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>> frequencies and the boost parameters are exposed through sysfs)
> 
> That will be a different problem -> as currently every single
> frequency in the cpufreq list has ability to be marked as boost
> frequency - if userspace does not maintain that, then, IMHO, fix the
> userspace :D
> 

/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
the list of frequencies based on the state of the boost feature at anytime.

Intuitively the list without boost shouldn't have any frequency above the range
when it's enabled :), that's what I was referring to. So I am not talking about
any issue with user-space maintenance.

Regards,
Sudeep

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 07/02/14 17:37, Nishanth Menon wrote:
> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:

[...]

>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>> frequencies and the boost parameters are exposed through sysfs)
> 
> That will be a different problem -> as currently every single
> frequency in the cpufreq list has ability to be marked as boost
> frequency - if userspace does not maintain that, then, IMHO, fix the
> userspace :D
> 

/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
the list of frequencies based on the state of the boost feature at anytime.

Intuitively the list without boost shouldn't have any frequency above the range
when it's enabled :), that's what I was referring to. So I am not talking about
any issue with user-space maintenance.

Regards,
Sudeep

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Nishanth Menon]

On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 17:37, Nishanth Menon wrote:
>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> [...]
>
>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>> frequencies and the boost parameters are exposed through sysfs)
>>
>> That will be a different problem -> as currently every single
>> frequency in the cpufreq list has ability to be marked as boost
>> frequency - if userspace does not maintain that, then, IMHO, fix the
>> userspace :D
>>
>
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
> the list of frequencies based on the state of the boost feature at anytime.
>
> Intuitively the list without boost shouldn't have any frequency above the range
> when it's enabled :), that's what I was referring to. So I am not talking about
> any issue with user-space maintenance.
Fair enough - but i still think it has nothing to do with dt binding
itself -> and i think the discussion we've had should be good for the
binding provided in this patch.. I hope.. if documentation needs a bit
of better explanation to prevent a repeat of the same discussion at a
later point of time, now might be a good time to add it in.

Regards,
Nishanth Menon

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Nishanth Menon]

On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 17:37, Nishanth Menon wrote:
>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> [...]
>
>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>> frequencies and the boost parameters are exposed through sysfs)
>>
>> That will be a different problem -> as currently every single
>> frequency in the cpufreq list has ability to be marked as boost
>> frequency - if userspace does not maintain that, then, IMHO, fix the
>> userspace :D
>>
>
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
> the list of frequencies based on the state of the boost feature at anytime.
>
> Intuitively the list without boost shouldn't have any frequency above the range
> when it's enabled :), that's what I was referring to. So I am not talking about
> any issue with user-space maintenance.
Fair enough - but i still think it has nothing to do with dt binding
itself -> and i think the discussion we've had should be good for the
binding provided in this patch.. I hope.. if documentation needs a bit
of better explanation to prevent a repeat of the same discussion at a
later point of time, now might be a good time to add it in.

Regards,
Nishanth Menon

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Thomas Abraham]

On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 17:37, Nishanth Menon wrote:
>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> [...]
>>
>>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>>> frequencies and the boost parameters are exposed through sysfs)
>>>
>>> That will be a different problem -> as currently every single
>>> frequency in the cpufreq list has ability to be marked as boost
>>> frequency - if userspace does not maintain that, then, IMHO, fix the
>>> userspace :D
>>>
>>
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
>> the list of frequencies based on the state of the boost feature at anytime.
>>
>> Intuitively the list without boost shouldn't have any frequency above the range
>> when it's enabled :), that's what I was referring to. So I am not talking about
>> any issue with user-space maintenance.
> Fair enough - but i still think it has nothing to do with dt binding
> itself -> and i think the discussion we've had should be good for the
> binding provided in this patch.. I hope.. if documentation needs a bit
> of better explanation to prevent a repeat of the same discussion at a
> later point of time, now might be a good time to add it in.

The term boost and over-clocking have been described in the bindings
document as being the same. Since the term over-clocking refers to
running a CPU beyond normal operating frequencies, I tend to agree
with Sudeep that it is not intuitive if a normal operating frequency
is greater than a boost mode frequency.

Otherwise, when userspace does "echo 1 >
/sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I
think the original intent of boost mode patches was to allow CPU to
operate at frequencies greater than the normal operating frequencies.

Lukasz, how would you want this to be handled?

Thanks,
Thomas.

>
> Regards,
> Nishanth Menon

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Thomas Abraham]

On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 17:37, Nishanth Menon wrote:
>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> [...]
>>
>>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>>> frequencies and the boost parameters are exposed through sysfs)
>>>
>>> That will be a different problem -> as currently every single
>>> frequency in the cpufreq list has ability to be marked as boost
>>> frequency - if userspace does not maintain that, then, IMHO, fix the
>>> userspace :D
>>>
>>
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
>> the list of frequencies based on the state of the boost feature at anytime.
>>
>> Intuitively the list without boost shouldn't have any frequency above the range
>> when it's enabled :), that's what I was referring to. So I am not talking about
>> any issue with user-space maintenance.
> Fair enough - but i still think it has nothing to do with dt binding
> itself -> and i think the discussion we've had should be good for the
> binding provided in this patch.. I hope.. if documentation needs a bit
> of better explanation to prevent a repeat of the same discussion at a
> later point of time, now might be a good time to add it in.

The term boost and over-clocking have been described in the bindings
document as being the same. Since the term over-clocking refers to
running a CPU beyond normal operating frequencies, I tend to agree
with Sudeep that it is not intuitive if a normal operating frequency
is greater than a boost mode frequency.

Otherwise, when userspace does "echo 1 >
/sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I
think the original intent of boost mode patches was to allow CPU to
operate at frequencies greater than the normal operating frequencies.

Lukasz, how would you want this to be handled?

Thanks,
Thomas.

>
> Regards,
> Nishanth Menon

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Lukasz Majewski]

Hi Thomas, Sudeep,

> On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote:
> > On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla
> > <Sudeep.Holla@arm.com> wrote:
> >> On 07/02/14 17:37, Nishanth Menon wrote:
> >>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
> >>> <Sudeep.Holla@arm.com> wrote:
> >>
> >> [...]
> >>
> >>>> Yes I think its counter-intuitive as it's visible to the
> >>>> userspace(list of frequencies and the boost parameters are
> >>>> exposed through sysfs)
> >>>
> >>> That will be a different problem -> as currently every single
> >>> frequency in the cpufreq list has ability to be marked as boost
> >>> frequency - if userspace does not maintain that, then, IMHO, fix
> >>> the userspace :D
> >>>
> >>
> >> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> >> gives the list of frequencies based on the state of the boost
> >> feature at anytime.
> >>
> >> Intuitively the list without boost shouldn't have any frequency
> >> above the range when it's enabled :), that's what I was referring
> >> to. So I am not talking about any issue with user-space
> >> maintenance.
> > Fair enough - but i still think it has nothing to do with dt binding
> > itself -> and i think the discussion we've had should be good for
> > the binding provided in this patch.. I hope.. if documentation
> > needs a bit of better explanation to prevent a repeat of the same
> > discussion at a later point of time, now might be a good time to
> > add it in.
> 
> The term boost and over-clocking have been described in the bindings
> document as being the same. Since the term over-clocking refers to
> running a CPU beyond normal operating frequencies, I tend to agree
> with Sudeep that it is not intuitive if a normal operating frequency
> is greater than a boost mode frequency.
> 
> Otherwise, when userspace does "echo 1 >
> /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I
> think the original intent of boost mode patches was to allow CPU to
> operate at frequencies greater than the normal operating frequencies.
> 
> Lukasz, how would you want this to be handled?

Please consider an example:

normal-freqs: 1400000, 1200000, 1000000, 800000, 600000, 400000, 200000
[1]
boost-freqs: 1700000, 1600000, 1500000. [2]

All those freqs shall be represented as OPPs freq and voltage tuple.

Best would be to specify all the boost-freqs as:
boost-freqs = <1700000 1600000 1500000> to be prepared for future
quirks or problems (or special cases which might show up latter).
If anybody can foresee any potential threads - like platform on which
boost freqs are 1700000 and 1500000, but not 1600000, then please share
this information.

However, I think that it would be also acceptable to specify only:
boost-freq = <1500000> and mark all freqs greater or equal to it as
CPUFREQ_BOOST_FREQ.

If there aren't any potential problems, then I think the second option
would be a good solution (we would have only one BOOST attribute stored
at CPUs DTS node).

> 
> Thanks,
> Thomas.
> 
> >
> > Regards,
> > Nishanth Menon
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Lukasz Majewski]

Hi Thomas, Sudeep,

> On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote:
> > On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla
> > <Sudeep.Holla@arm.com> wrote:
> >> On 07/02/14 17:37, Nishanth Menon wrote:
> >>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
> >>> <Sudeep.Holla@arm.com> wrote:
> >>
> >> [...]
> >>
> >>>> Yes I think its counter-intuitive as it's visible to the
> >>>> userspace(list of frequencies and the boost parameters are
> >>>> exposed through sysfs)
> >>>
> >>> That will be a different problem -> as currently every single
> >>> frequency in the cpufreq list has ability to be marked as boost
> >>> frequency - if userspace does not maintain that, then, IMHO, fix
> >>> the userspace :D
> >>>
> >>
> >> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> >> gives the list of frequencies based on the state of the boost
> >> feature at anytime.
> >>
> >> Intuitively the list without boost shouldn't have any frequency
> >> above the range when it's enabled :), that's what I was referring
> >> to. So I am not talking about any issue with user-space
> >> maintenance.
> > Fair enough - but i still think it has nothing to do with dt binding
> > itself -> and i think the discussion we've had should be good for
> > the binding provided in this patch.. I hope.. if documentation
> > needs a bit of better explanation to prevent a repeat of the same
> > discussion at a later point of time, now might be a good time to
> > add it in.
> 
> The term boost and over-clocking have been described in the bindings
> document as being the same. Since the term over-clocking refers to
> running a CPU beyond normal operating frequencies, I tend to agree
> with Sudeep that it is not intuitive if a normal operating frequency
> is greater than a boost mode frequency.
> 
> Otherwise, when userspace does "echo 1 >
> /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I
> think the original intent of boost mode patches was to allow CPU to
> operate at frequencies greater than the normal operating frequencies.
> 
> Lukasz, how would you want this to be handled?

Please consider an example:

normal-freqs: 1400000, 1200000, 1000000, 800000, 600000, 400000, 200000
[1]
boost-freqs: 1700000, 1600000, 1500000. [2]

All those freqs shall be represented as OPPs freq and voltage tuple.

Best would be to specify all the boost-freqs as:
boost-freqs = <1700000 1600000 1500000> to be prepared for future
quirks or problems (or special cases which might show up latter).
If anybody can foresee any potential threads - like platform on which
boost freqs are 1700000 and 1500000, but not 1600000, then please share
this information.

However, I think that it would be also acceptable to specify only:
boost-freq = <1500000> and mark all freqs greater or equal to it as
CPUFREQ_BOOST_FREQ.

If there aren't any potential problems, then I think the second option
would be a good solution (we would have only one BOOST attribute stored
at CPUs DTS node).

> 
> Thanks,
> Thomas.
> 
> >
> > Regards,
> > Nishanth Menon
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 10/02/14 07:53, Lukasz Majewski wrote:
> Hi Thomas, Sudeep,
> 
>> On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote:
>>> On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla
>>> <Sudeep.Holla@arm.com> wrote:
>>>> On 07/02/14 17:37, Nishanth Menon wrote:
>>>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
>>>>> <Sudeep.Holla@arm.com> wrote:
>>>>
>>>> [...]
>>>>
>>>>>> Yes I think its counter-intuitive as it's visible to the
>>>>>> userspace(list of frequencies and the boost parameters are
>>>>>> exposed through sysfs)
>>>>>
>>>>> That will be a different problem -> as currently every single
>>>>> frequency in the cpufreq list has ability to be marked as boost
>>>>> frequency - if userspace does not maintain that, then, IMHO, fix
>>>>> the userspace :D
>>>>>
>>>>
>>>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>>>> gives the list of frequencies based on the state of the boost
>>>> feature at anytime.
>>>>
>>>> Intuitively the list without boost shouldn't have any frequency
>>>> above the range when it's enabled :), that's what I was referring
>>>> to. So I am not talking about any issue with user-space
>>>> maintenance.
>>> Fair enough - but i still think it has nothing to do with dt binding
>>> itself -> and i think the discussion we've had should be good for
>>> the binding provided in this patch.. I hope.. if documentation
>>> needs a bit of better explanation to prevent a repeat of the same
>>> discussion at a later point of time, now might be a good time to
>>> add it in.
>>
Nishanth, though I am not convinced that it should be list, since you have a
valid point that this should not prevent in having this feature, I am fine with
the list.

>> The term boost and over-clocking have been described in the bindings
>> document as being the same. Since the term over-clocking refers to
>> running a CPU beyond normal operating frequencies, I tend to agree
>> with Sudeep that it is not intuitive if a normal operating frequency
>> is greater than a boost mode frequency.
>>
>> Otherwise, when userspace does "echo 1 >
>> /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I
>> think the original intent of boost mode patches was to allow CPU to
>> operate at frequencies greater than the normal operating frequencies.
>>
>> Lukasz, how would you want this to be handled?
> 
> Please consider an example:
> 
> normal-freqs: 1400000, 1200000, 1000000, 800000, 600000, 400000, 200000
> [1]
> boost-freqs: 1700000, 1600000, 1500000. [2]
> 
> All those freqs shall be represented as OPPs freq and voltage tuple.
> 
> Best would be to specify all the boost-freqs as:
> boost-freqs = <1700000 1600000 1500000> to be prepared for future
> quirks or problems (or special cases which might show up latter).
> If anybody can foresee any potential threads - like platform on which
> boost freqs are 1700000 and 1500000, but not 1600000, then please share
> this information.
> 
If that's the case then why should it be included in the list of OPPs.
I know Nishanth had a valid point in other thread previously(like including
SoC.dtsi having OPPs in platform files), but that's different problem.

> However, I think that it would be also acceptable to specify only:
> boost-freq = <1500000> and mark all freqs greater or equal to it as
> CPUFREQ_BOOST_FREQ.
> 
> If there aren't any potential problems, then I think the second option
> would be a good solution (we would have only one BOOST attribute stored
> at CPUs DTS node).
> 

Yes I prefer this to keep it simple and as per the definition of overclocking
or turbo boost in hardware terms if possible.

Just another thought, not sure how much this is true for real platforms, sharing
it anyway. IIUC these boost frequencies have certain constraints like thermal
and can't be sustained all the processors for long time.

So does it make sense to specify normal max frequency instead of boost-frequency
which by definition would be: "The maximum frequency that all processors are can
sustain simultaneously without any thermal constraints".
Ignore this if this is not the definition of boost on real platforms.


Regards,
Sudeep

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 10/02/14 07:53, Lukasz Majewski wrote:
> Hi Thomas, Sudeep,
> 
>> On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote:
>>> On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla
>>> <Sudeep.Holla@arm.com> wrote:
>>>> On 07/02/14 17:37, Nishanth Menon wrote:
>>>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
>>>>> <Sudeep.Holla@arm.com> wrote:
>>>>
>>>> [...]
>>>>
>>>>>> Yes I think its counter-intuitive as it's visible to the
>>>>>> userspace(list of frequencies and the boost parameters are
>>>>>> exposed through sysfs)
>>>>>
>>>>> That will be a different problem -> as currently every single
>>>>> frequency in the cpufreq list has ability to be marked as boost
>>>>> frequency - if userspace does not maintain that, then, IMHO, fix
>>>>> the userspace :D
>>>>>
>>>>
>>>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>>>> gives the list of frequencies based on the state of the boost
>>>> feature at anytime.
>>>>
>>>> Intuitively the list without boost shouldn't have any frequency
>>>> above the range when it's enabled :), that's what I was referring
>>>> to. So I am not talking about any issue with user-space
>>>> maintenance.
>>> Fair enough - but i still think it has nothing to do with dt binding
>>> itself -> and i think the discussion we've had should be good for
>>> the binding provided in this patch.. I hope.. if documentation
>>> needs a bit of better explanation to prevent a repeat of the same
>>> discussion at a later point of time, now might be a good time to
>>> add it in.
>>
Nishanth, though I am not convinced that it should be list, since you have a
valid point that this should not prevent in having this feature, I am fine with
the list.

>> The term boost and over-clocking have been described in the bindings
>> document as being the same. Since the term over-clocking refers to
>> running a CPU beyond normal operating frequencies, I tend to agree
>> with Sudeep that it is not intuitive if a normal operating frequency
>> is greater than a boost mode frequency.
>>
>> Otherwise, when userspace does "echo 1 >
>> /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I
>> think the original intent of boost mode patches was to allow CPU to
>> operate at frequencies greater than the normal operating frequencies.
>>
>> Lukasz, how would you want this to be handled?
> 
> Please consider an example:
> 
> normal-freqs: 1400000, 1200000, 1000000, 800000, 600000, 400000, 200000
> [1]
> boost-freqs: 1700000, 1600000, 1500000. [2]
> 
> All those freqs shall be represented as OPPs freq and voltage tuple.
> 
> Best would be to specify all the boost-freqs as:
> boost-freqs = <1700000 1600000 1500000> to be prepared for future
> quirks or problems (or special cases which might show up latter).
> If anybody can foresee any potential threads - like platform on which
> boost freqs are 1700000 and 1500000, but not 1600000, then please share
> this information.
> 
If that's the case then why should it be included in the list of OPPs.
I know Nishanth had a valid point in other thread previously(like including
SoC.dtsi having OPPs in platform files), but that's different problem.

> However, I think that it would be also acceptable to specify only:
> boost-freq = <1500000> and mark all freqs greater or equal to it as
> CPUFREQ_BOOST_FREQ.
> 
> If there aren't any potential problems, then I think the second option
> would be a good solution (we would have only one BOOST attribute stored
> at CPUs DTS node).
> 

Yes I prefer this to keep it simple and as per the definition of overclocking
or turbo boost in hardware terms if possible.

Just another thought, not sure how much this is true for real platforms, sharing
it anyway. IIUC these boost frequencies have certain constraints like thermal
and can't be sustained all the processors for long time.

So does it make sense to specify normal max frequency instead of boost-frequency
which by definition would be: "The maximum frequency that all processors are can
sustain simultaneously without any thermal constraints".
Ignore this if this is not the definition of boost on real platforms.


Regards,
Sudeep

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Thomas Abraham]

On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 17:37, Nishanth Menon wrote:
>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> [...]
>
>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>> frequencies and the boost parameters are exposed through sysfs)
>>
>> That will be a different problem -> as currently every single
>> frequency in the cpufreq list has ability to be marked as boost
>> frequency - if userspace does not maintain that, then, IMHO, fix the
>> userspace :D
>>
>
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
> the list of frequencies based on the state of the boost feature at anytime.

The list of frequencies in
/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
does not change based in the state of the boost feature (enabled or
disabled). But the scaling_max_frequency and scaling_min_frequency are
updated based on the set of available + boost frequencies available.

>
> Intuitively the list without boost shouldn't have any frequency above the range
> when it's enabled :), that's what I was referring to. So I am not talking about
> any issue with user-space maintenance.
>
> Regards,
> Sudeep
>

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Thomas Abraham]

On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 17:37, Nishanth Menon wrote:
>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> [...]
>
>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>> frequencies and the boost parameters are exposed through sysfs)
>>
>> That will be a different problem -> as currently every single
>> frequency in the cpufreq list has ability to be marked as boost
>> frequency - if userspace does not maintain that, then, IMHO, fix the
>> userspace :D
>>
>
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
> the list of frequencies based on the state of the boost feature at anytime.

The list of frequencies in
/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
does not change based in the state of the boost feature (enabled or
disabled). But the scaling_max_frequency and scaling_min_frequency are
updated based on the set of available + boost frequencies available.

>
> Intuitively the list without boost shouldn't have any frequency above the range
> when it's enabled :), that's what I was referring to. So I am not talking about
> any issue with user-space maintenance.
>
> Regards,
> Sudeep
>

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Lukasz Majewski]

Hi Thomas, Sudeep,

> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com>
> wrote:
> > On 07/02/14 17:37, Nishanth Menon wrote:
> >> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
> >> <Sudeep.Holla@arm.com> wrote:
> >
> > [...]
> >
> >>> Yes I think its counter-intuitive as it's visible to the
> >>> userspace(list of frequencies and the boost parameters are
> >>> exposed through sysfs)
> >>
> >> That will be a different problem -> as currently every single
> >> frequency in the cpufreq list has ability to be marked as boost
> >> frequency - if userspace does not maintain that, then, IMHO, fix
> >> the userspace :D
> >>
> >
> > /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> > gives the list of frequencies based on the state of the boost
> > feature at anytime.
> 
> The list of frequencies in
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> does not change based in the state of the boost feature (enabled or
> disabled). But the scaling_max_frequency and scaling_min_frequency are
> updated based on the set of available + boost frequencies available.

With boost intended behavior is as follow:

/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies [1]

shows the non boost frequencies no matter if boost is enabled or not.
Those are the "normal" frequencies.

When boost is supported (by enabling the CONFIG_CPU_FREQ_BOOST_SW)
extra sysfs attribute shows up:

/sys/devices/system/cpu/cpu0/cpufreq/scaling_boost_frequencies [2]
in which are listed only the boost frequencies.

If the dts doesn't provide any values or as it is now no
CPUFREQ_BOOST_FREQ flag is specified (at exynos4x12-cpufreq.c), then
this list is empty.


When boost is disabled the max freq (cpuinfo_max_freq) is in the range
listed at [1].

When boost is enabled this value is the sum of freqs represented at [1]
and [2].

By adding an extra attribute [2] we:
1. Indicate that boost is supported
2. List provided BOOST frequencies
3. Separate boost and non boost freqs


> 
> >
> > Intuitively the list without boost shouldn't have any frequency
> > above the range when it's enabled :), that's what I was referring
> > to. So I am not talking about any issue with user-space maintenance.
> >
> > Regards,
> > Sudeep
> >



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Lukasz Majewski]

Hi Thomas, Sudeep,

> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com>
> wrote:
> > On 07/02/14 17:37, Nishanth Menon wrote:
> >> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
> >> <Sudeep.Holla@arm.com> wrote:
> >
> > [...]
> >
> >>> Yes I think its counter-intuitive as it's visible to the
> >>> userspace(list of frequencies and the boost parameters are
> >>> exposed through sysfs)
> >>
> >> That will be a different problem -> as currently every single
> >> frequency in the cpufreq list has ability to be marked as boost
> >> frequency - if userspace does not maintain that, then, IMHO, fix
> >> the userspace :D
> >>
> >
> > /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> > gives the list of frequencies based on the state of the boost
> > feature at anytime.
> 
> The list of frequencies in
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> does not change based in the state of the boost feature (enabled or
> disabled). But the scaling_max_frequency and scaling_min_frequency are
> updated based on the set of available + boost frequencies available.

With boost intended behavior is as follow:

/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies [1]

shows the non boost frequencies no matter if boost is enabled or not.
Those are the "normal" frequencies.

When boost is supported (by enabling the CONFIG_CPU_FREQ_BOOST_SW)
extra sysfs attribute shows up:

/sys/devices/system/cpu/cpu0/cpufreq/scaling_boost_frequencies [2]
in which are listed only the boost frequencies.

If the dts doesn't provide any values or as it is now no
CPUFREQ_BOOST_FREQ flag is specified (at exynos4x12-cpufreq.c), then
this list is empty.


When boost is disabled the max freq (cpuinfo_max_freq) is in the range
listed at [1].

When boost is enabled this value is the sum of freqs represented at [1]
and [2].

By adding an extra attribute [2] we:
1. Indicate that boost is supported
2. List provided BOOST frequencies
3. Separate boost and non boost freqs


> 
> >
> > Intuitively the list without boost shouldn't have any frequency
> > above the range when it's enabled :), that's what I was referring
> > to. So I am not talking about any issue with user-space maintenance.
> >
> > Regards,
> > Sudeep
> >



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 10/02/14 07:38, Lukasz Majewski wrote:
> Hi Thomas, Sudeep,
> 
>> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com>
>> wrote:
>>> On 07/02/14 17:37, Nishanth Menon wrote:
>>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
>>>> <Sudeep.Holla@arm.com> wrote:
>>>
>>> [...]
>>>
>>>>> Yes I think its counter-intuitive as it's visible to the
>>>>> userspace(list of frequencies and the boost parameters are
>>>>> exposed through sysfs)
>>>>
>>>> That will be a different problem -> as currently every single
>>>> frequency in the cpufreq list has ability to be marked as boost
>>>> frequency - if userspace does not maintain that, then, IMHO, fix
>>>> the userspace :D
>>>>
>>>
>>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>>> gives the list of frequencies based on the state of the boost
>>> feature at anytime.
>>
>> The list of frequencies in
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>> does not change based in the state of the boost feature (enabled or
>> disabled). But the scaling_max_frequency and scaling_min_frequency are
>> updated based on the set of available + boost frequencies available.
> 
> With boost intended behavior is as follow:
> 
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies [1]
> 
> shows the non boost frequencies no matter if boost is enabled or not.
> Those are the "normal" frequencies.
> 
> When boost is supported (by enabling the CONFIG_CPU_FREQ_BOOST_SW)
> extra sysfs attribute shows up:
> 
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_boost_frequencies [2]
> in which are listed only the boost frequencies.
> 

Correct, sorry I misunderstood this to dynamic change in
scaling_available_frequencies based on state of boot.

Regards,
Sudeep

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 10/02/14 07:38, Lukasz Majewski wrote:
> Hi Thomas, Sudeep,
> 
>> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com>
>> wrote:
>>> On 07/02/14 17:37, Nishanth Menon wrote:
>>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
>>>> <Sudeep.Holla@arm.com> wrote:
>>>
>>> [...]
>>>
>>>>> Yes I think its counter-intuitive as it's visible to the
>>>>> userspace(list of frequencies and the boost parameters are
>>>>> exposed through sysfs)
>>>>
>>>> That will be a different problem -> as currently every single
>>>> frequency in the cpufreq list has ability to be marked as boost
>>>> frequency - if userspace does not maintain that, then, IMHO, fix
>>>> the userspace :D
>>>>
>>>
>>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>>> gives the list of frequencies based on the state of the boost
>>> feature at anytime.
>>
>> The list of frequencies in
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>> does not change based in the state of the boost feature (enabled or
>> disabled). But the scaling_max_frequency and scaling_min_frequency are
>> updated based on the set of available + boost frequencies available.
> 
> With boost intended behavior is as follow:
> 
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies [1]
> 
> shows the non boost frequencies no matter if boost is enabled or not.
> Those are the "normal" frequencies.
> 
> When boost is supported (by enabling the CONFIG_CPU_FREQ_BOOST_SW)
> extra sysfs attribute shows up:
> 
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_boost_frequencies [2]
> in which are listed only the boost frequencies.
> 

Correct, sorry I misunderstood this to dynamic change in
scaling_available_frequencies based on state of boot.

Regards,
Sudeep

Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 08/02/14 06:47, Thomas Abraham wrote:
> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 17:37, Nishanth Menon wrote:
>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> [...]
>>
>>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>>> frequencies and the boost parameters are exposed through sysfs)
>>>
>>> That will be a different problem -> as currently every single
>>> frequency in the cpufreq list has ability to be marked as boost
>>> frequency - if userspace does not maintain that, then, IMHO, fix the
>>> userspace :D
>>>
>>
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
>> the list of frequencies based on the state of the boost feature at anytime.
> 
> The list of frequencies in
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> does not change based in the state of the boost feature (enabled or
> disabled). But the scaling_max_frequency and scaling_min_frequency are
> updated based on the set of available + boost frequencies available.
> 

Ah ok, sorry just glanced the code and misunderstood it. It make sense to update
only max_frequency.

Regards,
Sudeep

[PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency

[Sudeep Holla]

On 08/02/14 06:47, Thomas Abraham wrote:
> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 17:37, Nishanth Menon wrote:
>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> [...]
>>
>>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>>> frequencies and the boost parameters are exposed through sysfs)
>>>
>>> That will be a different problem -> as currently every single
>>> frequency in the cpufreq list has ability to be marked as boost
>>> frequency - if userspace does not maintain that, then, IMHO, fix the
>>> userspace :D
>>>
>>
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
>> the list of frequencies based on the state of the boost feature at anytime.
> 
> The list of frequencies in
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> does not change based in the state of the boost feature (enabled or
> disabled). But the scaling_max_frequency and scaling_min_frequency are
> updated based on the set of available + boost frequencies available.
> 

Ah ok, sorry just glanced the code and misunderstood it. It make sense to update
only max_frequency.

Regards,
Sudeep