Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1282441 > unrolled thread
| Started by | Ben Gamari <ben@smart-cactus.org> |
|---|---|
| First post | 2015-12-02 22:40 +0100 |
| Last post | 2015-12-03 12:30 +0100 |
| Articles | 15 — 5 participants |
Back to article view | Back to linux.kernel
[PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 Ben Gamari <ben@smart-cactus.org> - 2015-12-02 22:40 +0100
[PATCH 11/12] cpufreq: arm-big-little: clarify frequency units Ben Gamari <ben@smart-cactus.org> - 2015-12-02 22:40 +0100
Re: [PATCH 11/12] cpufreq: arm-big-little: clarify frequency units "Jon Medhurst (Tixy)" <tixy@linaro.org> - 2015-12-03 15:30 +0100
Re: [PATCH 11/12] cpufreq: arm-big-little: clarify frequency units Ben Gamari <ben@smart-cactus.org> - 2015-12-03 15:40 +0100
[PATCH 07/12] ARM: dts: Exynos5422: fix OPP tables Ben Gamari <ben@smart-cactus.org> - 2015-12-02 22:40 +0100
[PATCH 01/12] cpufreq: arm_big_little: add cluster regulator support Ben Gamari <ben@smart-cactus.org> - 2015-12-02 22:40 +0100
Re: [PATCH 01/12] cpufreq: arm_big_little: add cluster regulator support Anand Moon <linux.amoon@gmail.com> - 2015-12-03 05:50 +0100
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 Viresh Kumar <viresh.kumar@linaro.org> - 2015-12-03 07:10 +0100
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 Ben Gamari <ben@smart-cactus.org> - 2015-12-03 11:30 +0100
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 Viresh Kumar <viresh.kumar@linaro.org> - 2015-12-03 11:40 +0100
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 Viresh Kumar <viresh.kumar@linaro.org> - 2015-12-03 12:30 +0100
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 Ben Gamari <ben@smart-cactus.org> - 2015-12-03 12:30 +0100
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 Ben Gamari <ben@smart-cactus.org> - 2015-12-07 22:20 +0100
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 Sudeep Holla <sudeep.holla@arm.com> - 2015-12-03 12:10 +0100
Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 Viresh Kumar <viresh.kumar@linaro.org> - 2015-12-03 12:30 +0100
| From | Ben Gamari <ben@smart-cactus.org> |
|---|---|
| Date | 2015-12-02 22:40 +0100 |
| Subject | [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 |
| Message-ID | <qBn8m-4el-9@gated-at.bofh.it> |
This patch series adds cpufreq support for the Exynos 5800, 5420, and 5422 SOCs. In particular, it adds support for operating-points-v2 bindings to the arm-big-little cpufreq driver and updates the above-mentioned SOCs' devicetrees to take advantage of this support. There are also a couple of patches improving the clarify of the arm-big-little implementation. It is built on a set posted by Bartlomiej Zolnierkiewicz in April 2015. The most signficant change from the original series is porting to the operating-points-v2 devicetree bindings. The series has been tested by me on and Odroid XU4 and by Javier Martinez Canillas on a Peach Pit. Cheers, - Ben -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Ben Gamari <ben@smart-cactus.org> |
|---|---|
| Date | 2015-12-02 22:40 +0100 |
| Subject | [PATCH 11/12] cpufreq: arm-big-little: clarify frequency units |
| Message-ID | <qBni3-4hS-27@gated-at.bofh.it> |
| In reply to | #1282441 |
The frequency units are very confusing in this area as OPPs use Hz
whereas cpufreq uses kHz. Be explicit about this in variable naming.
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Ben Gamari <ben@smart-cactus.org>
---
drivers/cpufreq/arm_big_little.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 855599b..2d5761c 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -130,14 +130,14 @@ static unsigned int bL_cpufreq_get_rate(unsigned int cpu)
}
static int
-bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
+bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate_kHz)
{
unsigned long volt = 0, volt_old = 0;
long freq_Hz;
u32 old_rate;
int ret;
- freq_Hz = new_rate * 1000;
+ freq_Hz = new_rate_kHz * 1000;
old_rate = clk_get_rate(clk[cluster]) / 1000;
if (!IS_ERR(reg[cluster])) {
@@ -163,10 +163,10 @@ bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
pr_debug("%s: cpu %d, cluster: %d, %u MHz, %ld mV --> %u MHz, %ld mV\n",
__func__, cpu, cluster,
old_rate / 1000, (volt_old > 0) ? volt_old / 1000 : -1,
- new_rate / 1000, volt ? volt / 1000 : -1);
+ new_rate_kHz / 1000, volt ? volt / 1000 : -1);
/* scaling up? scale voltage before frequency */
- if (!IS_ERR(reg[cluster]) && new_rate > old_rate) {
+ if (!IS_ERR(reg[cluster]) && new_rate_kHz > old_rate) {
ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
if (ret) {
pr_err("%s: cpu: %d, cluster: %d, failed to scale voltage up: %d\n",
@@ -175,7 +175,7 @@ bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
}
}
- ret = clk_set_rate(clk[cluster], new_rate * 1000);
+ ret = clk_set_rate(clk[cluster], new_rate_kHz * 1000);
if (WARN_ON(ret)) {
pr_err("%s: clk_set_rate failed: %d, cluster: %d\n",
__func__, cluster, ret);
@@ -185,7 +185,7 @@ bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
}
/* scaling down? scale voltage after frequency */
- if (!IS_ERR(reg[cluster]) && new_rate < old_rate) {
+ if (!IS_ERR(reg[cluster]) && new_rate_kHz < old_rate) {
ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
if (ret) {
pr_err("%s: cpu: %d, cluster: %d, failed to scale voltage down: %d\n",
@@ -199,7 +199,7 @@ bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
}
static unsigned int
-bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
+bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate_kHz)
{
u32 new_rate, prev_rate;
int ret;
@@ -209,13 +209,13 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
if (bLs) {
prev_rate = per_cpu(cpu_last_req_freq, cpu);
- per_cpu(cpu_last_req_freq, cpu) = rate;
+ per_cpu(cpu_last_req_freq, cpu) = rate_kHz;
per_cpu(physical_cluster, cpu) = new_cluster;
new_rate = find_cluster_maxfreq(new_cluster);
new_rate = ACTUAL_FREQ(new_cluster, new_rate);
} else {
- new_rate = rate;
+ new_rate = rate_kHz;
}
pr_debug("%s: cpu: %d, old cluster: %d, new cluster: %d, freq: %d\n",
@@ -236,7 +236,7 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
} else if (ret && bLs) {
per_cpu(cpu_last_req_freq, cpu) = prev_rate;
per_cpu(physical_cluster, cpu) = old_cluster;
- }
+ }
mutex_unlock(&cluster_lock[new_cluster]);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Jon Medhurst (Tixy)" <tixy@linaro.org> |
|---|---|
| Date | 2015-12-03 15:30 +0100 |
| Subject | Re: [PATCH 11/12] cpufreq: arm-big-little: clarify frequency units |
| Message-ID | <qBD3s-6ip-23@gated-at.bofh.it> |
| In reply to | #1282443 |
On Wed, 2015-12-02 at 22:19 +0100, Ben Gamari wrote:
> The frequency units are very confusing in this area as OPPs use Hz
> whereas cpufreq uses kHz. Be explicit about this in variable naming.
>
> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> Signed-off-by: Ben Gamari <ben@smart-cactus.org>
> ---
> drivers/cpufreq/arm_big_little.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
> index 855599b..2d5761c 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufreq/arm_big_little.c
> @@ -130,14 +130,14 @@ static unsigned int bL_cpufreq_get_rate(unsigned int cpu)
> }
>
> static int
> -bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
> +bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate_kHz)
> {
> unsigned long volt = 0, volt_old = 0;
> long freq_Hz;
> u32 old_rate;
IMO variable renaming doesn't seem necessary, if cpufreq uses kHz then
in a cpufreq driver adding 'kHz' to variable seems redundant, especially
if Hz values like freq_Hz above are named especially to signal their
different units. However, if renaming is going to happen it should at
least be consistent within the same function i.e. also rename the old
old_rate variable above.
> int ret;
>
> - freq_Hz = new_rate * 1000;
> + freq_Hz = new_rate_kHz * 1000;
> old_rate = clk_get_rate(clk[cluster]) / 1000;
>
> if (!IS_ERR(reg[cluster])) {
> @@ -163,10 +163,10 @@ bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
> pr_debug("%s: cpu %d, cluster: %d, %u MHz, %ld mV --> %u MHz, %ld mV\n",
> __func__, cpu, cluster,
> old_rate / 1000, (volt_old > 0) ? volt_old / 1000 : -1,
> - new_rate / 1000, volt ? volt / 1000 : -1);
> + new_rate_kHz / 1000, volt ? volt / 1000 : -1);
>
> /* scaling up? scale voltage before frequency */
> - if (!IS_ERR(reg[cluster]) && new_rate > old_rate) {
> + if (!IS_ERR(reg[cluster]) && new_rate_kHz > old_rate) {
> ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
> if (ret) {
> pr_err("%s: cpu: %d, cluster: %d, failed to scale voltage up: %d\n",
> @@ -175,7 +175,7 @@ bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
> }
> }
>
> - ret = clk_set_rate(clk[cluster], new_rate * 1000);
> + ret = clk_set_rate(clk[cluster], new_rate_kHz * 1000);
> if (WARN_ON(ret)) {
> pr_err("%s: clk_set_rate failed: %d, cluster: %d\n",
> __func__, cluster, ret);
> @@ -185,7 +185,7 @@ bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
> }
>
> /* scaling down? scale voltage after frequency */
> - if (!IS_ERR(reg[cluster]) && new_rate < old_rate) {
> + if (!IS_ERR(reg[cluster]) && new_rate_kHz < old_rate) {
> ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
> if (ret) {
> pr_err("%s: cpu: %d, cluster: %d, failed to scale voltage down: %d\n",
> @@ -199,7 +199,7 @@ bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
> }
>
> static unsigned int
> -bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
> +bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate_kHz)
> {
> u32 new_rate, prev_rate;
Ditto. Rename these too to add '_kHz' ?
> int ret;
> @@ -209,13 +209,13 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
>
> if (bLs) {
> prev_rate = per_cpu(cpu_last_req_freq, cpu);
> - per_cpu(cpu_last_req_freq, cpu) = rate;
> + per_cpu(cpu_last_req_freq, cpu) = rate_kHz;
> per_cpu(physical_cluster, cpu) = new_cluster;
>
> new_rate = find_cluster_maxfreq(new_cluster);
> new_rate = ACTUAL_FREQ(new_cluster, new_rate);
> } else {
> - new_rate = rate;
> + new_rate = rate_kHz;
> }
>
> pr_debug("%s: cpu: %d, old cluster: %d, new cluster: %d, freq: %d\n",
> @@ -236,7 +236,7 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
> } else if (ret && bLs) {
> per_cpu(cpu_last_req_freq, cpu) = prev_rate;
> per_cpu(physical_cluster, cpu) = old_cluster;
> - }
> + }
There's a spurious whitespace change here. I know the space you deleted
shouldn't have been there, but doing tidyups like that generally isn't
done in patches that don't otherwise affect the code in question.
>
> mutex_unlock(&cluster_lock[new_cluster]);
>
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ben Gamari <ben@smart-cactus.org> |
|---|---|
| Date | 2015-12-03 15:40 +0100 |
| Subject | Re: [PATCH 11/12] cpufreq: arm-big-little: clarify frequency units |
| Message-ID | <qBDd7-6lI-5@gated-at.bofh.it> |
| In reply to | #1283079 |
[Multipart message — attachments visible in raw view] — view raw
"Jon Medhurst (Tixy)" <tixy@linaro.org> writes:
> On Wed, 2015-12-02 at 22:19 +0100, Ben Gamari wrote:
>> The frequency units are very confusing in this area as OPPs use Hz
>> whereas cpufreq uses kHz. Be explicit about this in variable naming.
>>
>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>> Signed-off-by: Ben Gamari <ben@smart-cactus.org>
>> ---
>> drivers/cpufreq/arm_big_little.c | 20 ++++++++++----------
>> 1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
>> index 855599b..2d5761c 100644
>> --- a/drivers/cpufreq/arm_big_little.c
>> +++ b/drivers/cpufreq/arm_big_little.c
>> @@ -130,14 +130,14 @@ static unsigned int bL_cpufreq_get_rate(unsigned int cpu)
>> }
>>
>> static int
>> -bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
>> +bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate_kHz)
>> {
>> unsigned long volt = 0, volt_old = 0;
>> long freq_Hz;
>> u32 old_rate;
>
> IMO variable renaming doesn't seem necessary, if cpufreq uses kHz then
> in a cpufreq driver adding 'kHz' to variable seems redundant, especially
> if Hz values like freq_Hz above are named especially to signal their
> different units.
>
Correct; it isn't strictly necessary but it would have saved me half an
hour of poking around trying work out the intent of this code.
> However, if renaming is going to happen it should at
> least be consistent within the same function i.e. also rename the old
> old_rate variable above.
>
That's a reasonable objection. I'd be happy to do that.
snip
>> static unsigned int
>> -bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
>> +bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate_kHz)
>> {
>> u32 new_rate, prev_rate;
>
> Ditto. Rename these too to add '_kHz' ?
>
Sure.
>> int ret;
>> @@ -209,13 +209,13 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
>>
>> if (bLs) {
>> prev_rate = per_cpu(cpu_last_req_freq, cpu);
>> - per_cpu(cpu_last_req_freq, cpu) = rate;
>> + per_cpu(cpu_last_req_freq, cpu) = rate_kHz;
>> per_cpu(physical_cluster, cpu) = new_cluster;
>>
>> new_rate = find_cluster_maxfreq(new_cluster);
>> new_rate = ACTUAL_FREQ(new_cluster, new_rate);
>> } else {
>> - new_rate = rate;
>> + new_rate = rate_kHz;
>> }
>>
>> pr_debug("%s: cpu: %d, old cluster: %d, new cluster: %d, freq: %d\n",
>> @@ -236,7 +236,7 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
>> } else if (ret && bLs) {
>> per_cpu(cpu_last_req_freq, cpu) = prev_rate;
>> per_cpu(physical_cluster, cpu) = old_cluster;
>> - }
>> + }
>
> There's a spurious whitespace change here. I know the space you deleted
> shouldn't have been there, but doing tidyups like that generally isn't
> done in patches that don't otherwise affect the code in question.
>
Alright, I can drop that change.
Cheers,
- Ben
[toc] | [prev] | [next] | [standalone]
| From | Ben Gamari <ben@smart-cactus.org> |
|---|---|
| Date | 2015-12-02 22:40 +0100 |
| Subject | [PATCH 07/12] ARM: dts: Exynos5422: fix OPP tables |
| Message-ID | <qBni3-4hS-33@gated-at.bofh.it> |
| In reply to | #1282441 |
The Exynos 5422 is identical to the 5800 except for the fact that it
boots from the A7 cores. Consequently, the core numbering is different:
cores 0-3 are A7s whereas 4-7 are A15s.
We can reuse the device tree of the 5800 for the 5422 but we must take
care to override the OPP tables and CPU clocks. These are otherwise
inherited from the exynos5800 devicetree, which has the CPU clusters
reversed compared to the 5422. This results in the A15 cores only
reaching 1.4GHz, the maximum rate of the KFC clock.
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Ben Gamari <ben@smart-cactus.org>
---
arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index b7f60c8..9a5131d 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -20,8 +20,10 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
+ operating-points-v2 = <&cpu1_opp_table>;
};
&cpu1 {
@@ -30,6 +32,7 @@
reg = <0x101>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
+ operating-points-v2 = <&cpu1_opp_table>;
};
&cpu2 {
@@ -38,6 +41,7 @@
reg = <0x102>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
+ operating-points-v2 = <&cpu1_opp_table>;
};
&cpu3 {
@@ -46,14 +50,17 @@
reg = <0x103>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
+ operating-points-v2 = <&cpu1_opp_table>;
};
&cpu4 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
+ operating-points-v2 = <&cpu0_opp_table>;
};
&cpu5 {
@@ -62,6 +69,7 @@
reg = <0x1>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
+ operating-points-v2 = <&cpu0_opp_table>;
};
&cpu6 {
@@ -70,6 +78,7 @@
reg = <0x2>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
+ operating-points-v2 = <&cpu0_opp_table>;
};
&cpu7 {
@@ -78,4 +87,5 @@
reg = <0x3>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
+ operating-points-v2 = <&cpu0_opp_table>;
};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ben Gamari <ben@smart-cactus.org> |
|---|---|
| Date | 2015-12-02 22:40 +0100 |
| Subject | [PATCH 01/12] cpufreq: arm_big_little: add cluster regulator support |
| Message-ID | <qBni3-4hS-43@gated-at.bofh.it> |
| In reply to | #1282441 |
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Add cluster regulator support as a preparation to adding
generic arm_big_little_dt cpufreq_dt driver support for
ODROID-XU3 board. This allows arm_big_little[_dt] driver
to set not only the frequency but also the voltage (which
is obtained from operating point's voltage value) for CPU
clusters.
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Ben Gamari <ben@smart-cactus.org>
---
.../bindings/cpufreq/arm_big_little_dt.txt | 4 +
drivers/cpufreq/arm_big_little.c | 155 ++++++++++++++++++---
2 files changed, 142 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
index 0715695..8ca4a12 100644
--- a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
+++ b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
@@ -18,6 +18,10 @@ Required properties:
Optional properties:
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
+- cpu-cluster.0-supply: Provides the regulator node supplying voltage to CPU
+ cluster 0.
+- cpu-cluster.1-supply: Provides the regulator node supplying voltage to CPU
+ cluster 1.
Examples:
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index c5d256c..855599b 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -31,6 +31,7 @@
#include <linux/slab.h>
#include <linux/topology.h>
#include <linux/types.h>
+#include <linux/regulator/consumer.h>
#include "arm_big_little.h"
@@ -57,6 +58,9 @@ static bool bL_switching_enabled;
static struct cpufreq_arm_bL_ops *arm_bL_ops;
static struct clk *clk[MAX_CLUSTERS];
+static struct regulator *reg[MAX_CLUSTERS];
+static struct device *cpu_devs[MAX_CLUSTERS];
+static int transition_latencies[MAX_CLUSTERS];
static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
static atomic_t cluster_usage[MAX_CLUSTERS + 1];
@@ -125,6 +129,75 @@ static unsigned int bL_cpufreq_get_rate(unsigned int cpu)
}
}
+static int
+bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
+{
+ unsigned long volt = 0, volt_old = 0;
+ long freq_Hz;
+ u32 old_rate;
+ int ret;
+
+ freq_Hz = new_rate * 1000;
+ old_rate = clk_get_rate(clk[cluster]) / 1000;
+
+ if (!IS_ERR(reg[cluster])) {
+ struct dev_pm_opp *opp;
+ unsigned long opp_freq;
+
+ rcu_read_lock();
+ opp = dev_pm_opp_find_freq_ceil(cpu_devs[cluster], &freq_Hz);
+ if (IS_ERR(opp)) {
+ rcu_read_unlock();
+ pr_err("%s: cpu %d, cluster: %d, failed to find OPP for %ld\n",
+ __func__, cpu, cluster, freq_Hz);
+ return PTR_ERR(opp);
+ }
+ volt = dev_pm_opp_get_voltage(opp);
+ opp_freq = dev_pm_opp_get_freq(opp);
+ rcu_read_unlock();
+ volt_old = regulator_get_voltage(reg[cluster]);
+ pr_debug("%s: cpu %d, cluster: %d, Found OPP: %ld kHz, %ld uV\n",
+ __func__, cpu, cluster, opp_freq / 1000, volt);
+ }
+
+ pr_debug("%s: cpu %d, cluster: %d, %u MHz, %ld mV --> %u MHz, %ld mV\n",
+ __func__, cpu, cluster,
+ old_rate / 1000, (volt_old > 0) ? volt_old / 1000 : -1,
+ new_rate / 1000, volt ? volt / 1000 : -1);
+
+ /* scaling up? scale voltage before frequency */
+ if (!IS_ERR(reg[cluster]) && new_rate > old_rate) {
+ ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
+ if (ret) {
+ pr_err("%s: cpu: %d, cluster: %d, failed to scale voltage up: %d\n",
+ __func__, cpu, cluster, ret);
+ return ret;
+ }
+ }
+
+ ret = clk_set_rate(clk[cluster], new_rate * 1000);
+ if (WARN_ON(ret)) {
+ pr_err("%s: clk_set_rate failed: %d, cluster: %d\n",
+ __func__, cluster, ret);
+ if (!IS_ERR(reg[cluster]) && volt_old > 0)
+ regulator_set_voltage_tol(reg[cluster], volt_old, 0);
+ return ret;
+ }
+
+ /* scaling down? scale voltage after frequency */
+ if (!IS_ERR(reg[cluster]) && new_rate < old_rate) {
+ ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
+ if (ret) {
+ pr_err("%s: cpu: %d, cluster: %d, failed to scale voltage down: %d\n",
+ __func__, cpu, cluster, ret);
+ clk_set_rate(clk[cluster], old_rate * 1000);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
static unsigned int
bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
{
@@ -148,7 +221,7 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
pr_debug("%s: cpu: %d, old cluster: %d, new cluster: %d, freq: %d\n",
__func__, cpu, old_cluster, new_cluster, new_rate);
- ret = clk_set_rate(clk[new_cluster], new_rate * 1000);
+ ret = bL_cpufreq_set_rate_cluster(cpu, new_cluster, new_rate);
if (!ret) {
/*
* FIXME: clk_set_rate hasn't returned an error here however it
@@ -160,22 +233,15 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
*/
if (clk_get_rate(clk[new_cluster]) != new_rate * 1000)
ret = -EIO;
- }
-
- if (WARN_ON(ret)) {
- pr_err("clk_set_rate failed: %d, new cluster: %d\n", ret,
- new_cluster);
- if (bLs) {
- per_cpu(cpu_last_req_freq, cpu) = prev_rate;
- per_cpu(physical_cluster, cpu) = old_cluster;
- }
+ } else if (ret && bLs) {
+ per_cpu(cpu_last_req_freq, cpu) = prev_rate;
+ per_cpu(physical_cluster, cpu) = old_cluster;
+ }
- mutex_unlock(&cluster_lock[new_cluster]);
+ mutex_unlock(&cluster_lock[new_cluster]);
+ if(ret)
return ret;
- }
-
- mutex_unlock(&cluster_lock[new_cluster]);
/* Recalc freq for old cluster when switching clusters */
if (old_cluster != new_cluster) {
@@ -195,9 +261,10 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
pr_debug("%s: Updating rate of old cluster: %d, to freq: %d\n",
__func__, old_cluster, new_rate);
- if (clk_set_rate(clk[old_cluster], new_rate * 1000))
- pr_err("%s: clk_set_rate failed: %d, old cluster: %d\n",
- __func__, ret, old_cluster);
+ if (bL_cpufreq_set_rate_cluster(cpu, old_cluster, new_rate)) {
+ pr_err("%s: bL_cpufreq_set_rate_cluster failed\n",
+ __func__);
+ }
}
mutex_unlock(&cluster_lock[old_cluster]);
}
@@ -304,6 +371,8 @@ static void _put_cluster_clk_and_freq_table(struct device *cpu_dev)
return;
clk_put(clk[cluster]);
+ if (!IS_ERR(reg[cluster]))
+ regulator_put(reg[cluster]);
dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table[cluster]);
if (arm_bL_ops->free_opp_table)
arm_bL_ops->free_opp_table(cpu_dev);
@@ -337,7 +406,9 @@ static void put_cluster_clk_and_freq_table(struct device *cpu_dev)
static int _get_cluster_clk_and_freq_table(struct device *cpu_dev)
{
+ unsigned long min_uV = ~0, max_uV = 0;
u32 cluster = raw_cpu_to_cluster(cpu_dev->id);
+ char name[14] = "cpu-cluster.";
int ret;
if (freq_table[cluster])
@@ -350,6 +421,51 @@ static int _get_cluster_clk_and_freq_table(struct device *cpu_dev)
goto out;
}
+ name[12] = cluster + '0';
+ reg[cluster] = regulator_get_optional(cpu_dev, name);
+ if (!IS_ERR(reg[cluster])) {
+ unsigned long opp_freq = 0;
+
+ dev_dbg(cpu_dev, "%s: reg: %p, cluster: %d\n",
+ __func__, reg[cluster], cluster);
+ cpu_devs[cluster] = cpu_dev;
+
+ /*
+ * Disable any OPPs where the connected regulator isn't able to
+ * provide the specified voltage and record minimum and maximum
+ * voltage levels.
+ */
+ while (1) {
+ struct dev_pm_opp *opp;
+ unsigned long opp_uV;
+
+ rcu_read_lock();
+ opp = dev_pm_opp_find_freq_ceil(cpu_dev, &opp_freq);
+ if (IS_ERR(opp)) {
+ rcu_read_unlock();
+ break;
+ }
+ opp_uV = dev_pm_opp_get_voltage(opp);
+ rcu_read_unlock();
+
+ if (regulator_is_supported_voltage(reg[cluster], opp_uV,
+ opp_uV)) {
+ if (opp_uV < min_uV)
+ min_uV = opp_uV;
+ if (opp_uV > max_uV)
+ max_uV = opp_uV;
+ } else {
+ dev_pm_opp_disable(cpu_dev, opp_freq);
+ }
+
+ opp_freq++;
+ }
+
+ ret = regulator_set_voltage_time(reg[cluster], min_uV, max_uV);
+ if (ret > 0)
+ transition_latencies[cluster] = ret * 1000;
+ }
+
ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table[cluster]);
if (ret) {
dev_err(cpu_dev, "%s: failed to init cpufreq table, cpu: %d, err: %d\n",
@@ -483,6 +599,11 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
else
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+ if (cur_cluster < MAX_CLUSTERS &&
+ policy->cpuinfo.transition_latency != CPUFREQ_ETERNAL)
+ policy->cpuinfo.transition_latency
+ += transition_latencies[cur_cluster];
+
if (is_bL_switching_enabled())
per_cpu(cpu_last_req_freq, policy->cpu) = clk_get_cpu_rate(policy->cpu);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Anand Moon <linux.amoon@gmail.com> |
|---|---|
| Date | 2015-12-03 05:50 +0100 |
| Subject | Re: [PATCH 01/12] cpufreq: arm_big_little: add cluster regulator support |
| Message-ID | <qBu0a-at-1@gated-at.bofh.it> |
| In reply to | #1282447 |
Hi Ben Gamari,
On 3 December 2015 at 02:49, Ben Gamari <ben@smart-cactus.org> wrote:
> From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>
> Add cluster regulator support as a preparation to adding
> generic arm_big_little_dt cpufreq_dt driver support for
> ODROID-XU3 board. This allows arm_big_little[_dt] driver
> to set not only the frequency but also the voltage (which
> is obtained from operating point's voltage value) for CPU
> clusters.
>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> Cc: Andreas Faerber <afaerber@suse.de>
> Cc: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Thomas Abraham <thomas.ab@samsung.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Signed-off-by: Ben Gamari <ben@smart-cactus.org>
> ---
> .../bindings/cpufreq/arm_big_little_dt.txt | 4 +
> drivers/cpufreq/arm_big_little.c | 155 ++++++++++++++++++---
> 2 files changed, 142 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
> index 0715695..8ca4a12 100644
> --- a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
> @@ -18,6 +18,10 @@ Required properties:
> Optional properties:
> - clock-latency: Specify the possible maximum transition latency for clock,
> in unit of nanoseconds.
> +- cpu-cluster.0-supply: Provides the regulator node supplying voltage to CPU
> + cluster 0.
> +- cpu-cluster.1-supply: Provides the regulator node supplying voltage to CPU
> + cluster 1.
>
> Examples:
>
> diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
> index c5d256c..855599b 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufreq/arm_big_little.c
> @@ -31,6 +31,7 @@
> #include <linux/slab.h>
> #include <linux/topology.h>
> #include <linux/types.h>
> +#include <linux/regulator/consumer.h>
>
> #include "arm_big_little.h"
>
> @@ -57,6 +58,9 @@ static bool bL_switching_enabled;
>
> static struct cpufreq_arm_bL_ops *arm_bL_ops;
> static struct clk *clk[MAX_CLUSTERS];
> +static struct regulator *reg[MAX_CLUSTERS];
> +static struct device *cpu_devs[MAX_CLUSTERS];
> +static int transition_latencies[MAX_CLUSTERS];
> static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
> static atomic_t cluster_usage[MAX_CLUSTERS + 1];
>
> @@ -125,6 +129,75 @@ static unsigned int bL_cpufreq_get_rate(unsigned int cpu)
> }
> }
>
> +static int
> +bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
> +{
> + unsigned long volt = 0, volt_old = 0;
> + long freq_Hz;
> + u32 old_rate;
> + int ret;
> +
> + freq_Hz = new_rate * 1000;
> + old_rate = clk_get_rate(clk[cluster]) / 1000;
> +
> + if (!IS_ERR(reg[cluster])) {
> + struct dev_pm_opp *opp;
> + unsigned long opp_freq;
> +
> + rcu_read_lock();
> + opp = dev_pm_opp_find_freq_ceil(cpu_devs[cluster], &freq_Hz);
> + if (IS_ERR(opp)) {
> + rcu_read_unlock();
> + pr_err("%s: cpu %d, cluster: %d, failed to find OPP for %ld\n",
> + __func__, cpu, cluster, freq_Hz);
> + return PTR_ERR(opp);
> + }
> + volt = dev_pm_opp_get_voltage(opp);
> + opp_freq = dev_pm_opp_get_freq(opp);
> + rcu_read_unlock();
> + volt_old = regulator_get_voltage(reg[cluster]);
> + pr_debug("%s: cpu %d, cluster: %d, Found OPP: %ld kHz, %ld uV\n",
> + __func__, cpu, cluster, opp_freq / 1000, volt);
> + }
> +
> + pr_debug("%s: cpu %d, cluster: %d, %u MHz, %ld mV --> %u MHz, %ld mV\n",
> + __func__, cpu, cluster,
> + old_rate / 1000, (volt_old > 0) ? volt_old / 1000 : -1,
> + new_rate / 1000, volt ? volt / 1000 : -1);
> +
> + /* scaling up? scale voltage before frequency */
> + if (!IS_ERR(reg[cluster]) && new_rate > old_rate) {
> + ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
> + if (ret) {
> + pr_err("%s: cpu: %d, cluster: %d, failed to scale voltage up: %d\n",
> + __func__, cpu, cluster, ret);
> + return ret;
> + }
> + }
> +
> + ret = clk_set_rate(clk[cluster], new_rate * 1000);
> + if (WARN_ON(ret)) {
> + pr_err("%s: clk_set_rate failed: %d, cluster: %d\n",
> + __func__, cluster, ret);
> + if (!IS_ERR(reg[cluster]) && volt_old > 0)
> + regulator_set_voltage_tol(reg[cluster], volt_old, 0);
> + return ret;
> + }
> +
> + /* scaling down? scale voltage after frequency */
> + if (!IS_ERR(reg[cluster]) && new_rate < old_rate) {
> + ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
> + if (ret) {
> + pr_err("%s: cpu: %d, cluster: %d, failed to scale voltage down: %d\n",
> + __func__, cpu, cluster, ret);
> + clk_set_rate(clk[cluster], old_rate * 1000);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> static unsigned int
> bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
> {
> @@ -148,7 +221,7 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
> pr_debug("%s: cpu: %d, old cluster: %d, new cluster: %d, freq: %d\n",
> __func__, cpu, old_cluster, new_cluster, new_rate);
>
> - ret = clk_set_rate(clk[new_cluster], new_rate * 1000);
> + ret = bL_cpufreq_set_rate_cluster(cpu, new_cluster, new_rate);
> if (!ret) {
> /*
> * FIXME: clk_set_rate hasn't returned an error here however it
> @@ -160,22 +233,15 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
> */
> if (clk_get_rate(clk[new_cluster]) != new_rate * 1000)
> ret = -EIO;
> - }
> -
> - if (WARN_ON(ret)) {
> - pr_err("clk_set_rate failed: %d, new cluster: %d\n", ret,
> - new_cluster);
> - if (bLs) {
> - per_cpu(cpu_last_req_freq, cpu) = prev_rate;
> - per_cpu(physical_cluster, cpu) = old_cluster;
> - }
> + } else if (ret && bLs) {
> + per_cpu(cpu_last_req_freq, cpu) = prev_rate;
> + per_cpu(physical_cluster, cpu) = old_cluster;
> + }
>
> - mutex_unlock(&cluster_lock[new_cluster]);
> + mutex_unlock(&cluster_lock[new_cluster]);
>
> + if(ret)
> return ret;
> - }
> -
> - mutex_unlock(&cluster_lock[new_cluster]);
>
> /* Recalc freq for old cluster when switching clusters */
> if (old_cluster != new_cluster) {
> @@ -195,9 +261,10 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
> pr_debug("%s: Updating rate of old cluster: %d, to freq: %d\n",
> __func__, old_cluster, new_rate);
>
> - if (clk_set_rate(clk[old_cluster], new_rate * 1000))
> - pr_err("%s: clk_set_rate failed: %d, old cluster: %d\n",
> - __func__, ret, old_cluster);
> + if (bL_cpufreq_set_rate_cluster(cpu, old_cluster, new_rate)) {
> + pr_err("%s: bL_cpufreq_set_rate_cluster failed\n",
> + __func__);
> + }
> }
> mutex_unlock(&cluster_lock[old_cluster]);
> }
> @@ -304,6 +371,8 @@ static void _put_cluster_clk_and_freq_table(struct device *cpu_dev)
> return;
>
> clk_put(clk[cluster]);
> + if (!IS_ERR(reg[cluster]))
> + regulator_put(reg[cluster]);
> dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table[cluster]);
> if (arm_bL_ops->free_opp_table)
> arm_bL_ops->free_opp_table(cpu_dev);
> @@ -337,7 +406,9 @@ static void put_cluster_clk_and_freq_table(struct device *cpu_dev)
>
> static int _get_cluster_clk_and_freq_table(struct device *cpu_dev)
> {
> + unsigned long min_uV = ~0, max_uV = 0;
> u32 cluster = raw_cpu_to_cluster(cpu_dev->id);
> + char name[14] = "cpu-cluster.";
> int ret;
>
> if (freq_table[cluster])
> @@ -350,6 +421,51 @@ static int _get_cluster_clk_and_freq_table(struct device *cpu_dev)
> goto out;
> }
>
> + name[12] = cluster + '0';
> + reg[cluster] = regulator_get_optional(cpu_dev, name);
> + if (!IS_ERR(reg[cluster])) {
> + unsigned long opp_freq = 0;
> +
> + dev_dbg(cpu_dev, "%s: reg: %p, cluster: %d\n",
> + __func__, reg[cluster], cluster);
> + cpu_devs[cluster] = cpu_dev;
> +
> + /*
> + * Disable any OPPs where the connected regulator isn't able to
> + * provide the specified voltage and record minimum and maximum
> + * voltage levels.
> + */
> + while (1) {
> + struct dev_pm_opp *opp;
> + unsigned long opp_uV;
> +
> + rcu_read_lock();
> + opp = dev_pm_opp_find_freq_ceil(cpu_dev, &opp_freq);
> + if (IS_ERR(opp)) {
> + rcu_read_unlock();
> + break;
> + }
> + opp_uV = dev_pm_opp_get_voltage(opp);
> + rcu_read_unlock();
> +
> + if (regulator_is_supported_voltage(reg[cluster], opp_uV,
> + opp_uV)) {
> + if (opp_uV < min_uV)
> + min_uV = opp_uV;
> + if (opp_uV > max_uV)
> + max_uV = opp_uV;
> + } else {
> + dev_pm_opp_disable(cpu_dev, opp_freq);
> + }
> +
> + opp_freq++;
> + }
> +
> + ret = regulator_set_voltage_time(reg[cluster], min_uV, max_uV);
> + if (ret > 0)
> + transition_latencies[cluster] = ret * 1000;
> + }
> +
> ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table[cluster]);
> if (ret) {
> dev_err(cpu_dev, "%s: failed to init cpufreq table, cpu: %d, err: %d\n",
> @@ -483,6 +599,11 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
> else
> policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
>
> + if (cur_cluster < MAX_CLUSTERS &&
> + policy->cpuinfo.transition_latency != CPUFREQ_ETERNAL)
> + policy->cpuinfo.transition_latency
> + += transition_latencies[cur_cluster];
> +
> if (is_bL_switching_enabled())
> per_cpu(cpu_last_req_freq, policy->cpu) = clk_get_cpu_rate(policy->cpu);
>
> --
> 2.6.2
>
I am getting following warning when I am trying to use git am
root@odroidxu4:/usr/src/odroidxu3-4.y-final# git am -s cpuf1.patch
Applying: cpufreq: arm_big_little: add cluster regulator support
/usr/src/odroidxu3-4.y-final/.git/rebase-apply/patch:144: trailing whitespace.
}
warning: 1 line adds whitespace errors.
-----------------------------------------------------------
Also I have disabled and enabled following config options.
-CONFIG_BL_SWITCHER=y
-CONFIG_BL_SWITCHER_DUMMY_IF=y
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
CONFIG_ARM_DT_BL_CPUFREQ=y
But I could not see the cpu frequency working on my Odroid XU4. Am I
missing some thing.
Every 2.0s: cpupower -c 4 frequency-info
Thu Dec
3 04:02:36 2015
analyzing CPU 4:
driver: arm-big-little
CPUs which run at the same hardware frequency: 4 5 6 7
CPUs which need to have their frequency coordinated by software: 4 5 6 7
maximum transition latency: 0.00 ms.
hardware limits: 200 MHz - 1.80 GHz
available frequency steps: 200 MHz, 300 MHz, 400 MHz, 500 MHz, 600
MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz, 1.30
GHz, 1.40 GHz, 1.50 GH
z, 1.60 GHz, 1.70 GHz, 1.80 GHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 200 MHz and 1.80 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1.80 GHz (asserted by call to hardware).
cpufreq stats: 200 MHz:0.00%, 300 MHz:0.00%, 400 MHz:0.00%, 500
MHz:0.00%, 600 MHz:0.00%, 700 MHz:0.00%, 800 MHz:0.00%, 900 MHz:0.00%,
1000 MHz:0.00%, 1.10
GHz:0.00%, 1.20 GHz:0.00%, 1.30 GHz:0.00%, 1.40 GHz:0.00%, 1.50
GHz:0.00%, 1.60 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:100.00% (1)
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Viresh Kumar <viresh.kumar@linaro.org> |
|---|---|
| Date | 2015-12-03 07:10 +0100 |
| Subject | Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 |
| Message-ID | <qBvfA-19g-9@gated-at.bofh.it> |
| In reply to | #1282441 |
Hi Ben, On 02-12-15, 22:19, Ben Gamari wrote: > > This patch series adds cpufreq support for the Exynos 5800, 5420, and 5422 > SOCs. In particular, it adds support for operating-points-v2 bindings to the > arm-big-little cpufreq driver and updates the above-mentioned SOCs' devicetrees > to take advantage of this support. There are also a couple of patches improving > the clarify of the arm-big-little implementation. It is built on a set posted > by Bartlomiej Zolnierkiewicz in April 2015. > > The most signficant change from the original series is porting to the > operating-points-v2 devicetree bindings. The series has been tested by me on > and Odroid XU4 and by Javier Martinez Canillas on a Peach Pit. Thanks for working with opp-v2 bindings, really appreciate it. But, before I start reviewing this series, I have few comments. - We weren't able to use cpufreq-dt driver for big LITTLE platforms earlier, as it never had multi cluster support and we wanted clock-sharing information via DT. - That is all fixed now. - I want Samsung's big LITTLE platforms to use cpufreq-dt and drop arm_big_little driver completely. - The only case for which it (arm_big_little) driver might be useful is the IKS solution. Which I don't believe you are going to use in future :) My plan for the arm-big-little driver: - Migrate all platforms to use cpufreq-dt instead for non-IKS solution - Make arm-big-little driver arm-big-little-iks only driver. @Sudeep: What would it take you to use cpufreq-dt for ARM's platforms ? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ben Gamari <ben@smart-cactus.org> |
|---|---|
| Date | 2015-12-03 11:30 +0100 |
| Message-ID | <qBzjb-3FV-5@gated-at.bofh.it> |
| In reply to | #1282725 |
[Multipart message — attachments visible in raw view] — view raw
Viresh Kumar <viresh.kumar@linaro.org> writes: > Hi Ben, Hi Viresh, > On 02-12-15, 22:19, Ben Gamari wrote: >> >> This patch series adds cpufreq support for the Exynos 5800, 5420, and 5422 >> SOCs. In particular, it adds support for operating-points-v2 bindings to the >> arm-big-little cpufreq driver and updates the above-mentioned SOCs' devicetrees >> to take advantage of this support. There are also a couple of patches improving >> the clarify of the arm-big-little implementation. It is built on a set posted >> by Bartlomiej Zolnierkiewicz in April 2015. >> >> The most signficant change from the original series is porting to the >> operating-points-v2 devicetree bindings. The series has been tested by me on >> and Odroid XU4 and by Javier Martinez Canillas on a Peach Pit. > > Thanks for working with opp-v2 bindings, really appreciate it. My pleasure. > But, before I start reviewing this series, I have few comments. > - We weren't able to use cpufreq-dt driver for big LITTLE platforms > earlier, as it never had multi cluster support and we wanted > clock-sharing information via DT. Fair enough. > - That is all fixed now. I did not see any mention of this in the cpufreq-dt driver binding documentation, otherwise I would have tried going this route. Do you have any references? I'd be happy to examine what would be necessary to go this route although, being an independent contributor, it may take time. > - I want Samsung's big LITTLE platforms to use cpufreq-dt and drop > arm_big_little driver completely. That sounds like a great direction going forward. However, I would still kindly request that you consider this series. The existence of future plans of course does not change the fact that users have real hardware today; hardware that they have spent money on and would like to use. Cpufreq support has already been deferred once for similar reasons of interface churn which essentially forestalled working functionality from entering the kernel by eight months; I'd really like to avoid having this happen again. > - The only case for which it (arm_big_little) driver might be useful > is the IKS solution. Which I don't believe you are going to use in > future :) Indeed. > My plan for the arm-big-little driver: > - Migrate all platforms to use cpufreq-dt instead for non-IKS > solution > - Make arm-big-little driver arm-big-little-iks only driver. Sounds reasonable to me. However, I'd just like to reiterate that this line of work can be pursued independently from the upstreaming of this series. Thanks for your time, - Ben
[toc] | [prev] | [next] | [standalone]
| From | Viresh Kumar <viresh.kumar@linaro.org> |
|---|---|
| Date | 2015-12-03 11:40 +0100 |
| Subject | Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 |
| Message-ID | <qBzsS-3Jm-5@gated-at.bofh.it> |
| In reply to | #1282903 |
On 03-12-15, 11:26, Ben Gamari wrote: > Viresh Kumar <viresh.kumar@linaro.org> writes: > > But, before I start reviewing this series, I have few comments. > > - We weren't able to use cpufreq-dt driver for big LITTLE platforms > > earlier, as it never had multi cluster support and we wanted > > clock-sharing information via DT. > > Fair enough. > > > - That is all fixed now. > > I did not see any mention of this in the cpufreq-dt driver binding > documentation, otherwise I would have tried going this route. > > Do you have any references? I'd be happy to examine what would be > necessary to go this route although, being an independent contributor, > it may take time. You wouldn't find in cpufreq-dt documentation as its not specific to that. I have seen you DT patches now, and you have created the OPP tables mostly correctly. Just create the cpufreq-platform device for cpufreq-dt instead of arm-big-little one. And it should just work. > > - I want Samsung's big LITTLE platforms to use cpufreq-dt and drop > > arm_big_little driver completely. > > That sounds like a great direction going forward. However, I would still > kindly request that you consider this series. > > The existence of future plans of course does not change the fact that > users have real hardware today; hardware that they have spent money on > and would like to use. Cpufreq support has already been deferred once > for similar reasons of interface churn which essentially forestalled > working functionality from entering the kernel by eight months; I'd > really like to avoid having this happen again. I am not talking about any future plans here that need some work to be done. Its all working today, you just need to use a different driver. > Sounds reasonable to me. However, I'd just like to reiterate that this > line of work can be pursued independently from the upstreaming of this > series. I think this is the right time to upstream the right solution. Just try it once, if you face lots of difficulties or issues, then we can ofcourse see.. NOTE: Check how OPP nodes are required to be created now in linux-next. They should be named like opp@<freq-hz>. Something I noticed in your DTs. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Viresh Kumar <viresh.kumar@linaro.org> |
|---|---|
| Date | 2015-12-03 12:30 +0100 |
| Subject | Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 |
| Message-ID | <qBAfg-4hh-11@gated-at.bofh.it> |
| In reply to | #1282908 |
On 03-12-15, 12:21, Ben Gamari wrote: > Do you mean something along these lines? [1] Yeah. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Ben Gamari <ben@smart-cactus.org> |
|---|---|
| Date | 2015-12-03 12:30 +0100 |
| Message-ID | <qBAfg-4hh-13@gated-at.bofh.it> |
| In reply to | #1282908 |
[Multipart message — attachments visible in raw view] — view raw
Viresh Kumar <viresh.kumar@linaro.org> writes: > On 03-12-15, 11:26, Ben Gamari wrote: >> Viresh Kumar <viresh.kumar@linaro.org> writes: >> > But, before I start reviewing this series, I have few comments. >> > - We weren't able to use cpufreq-dt driver for big LITTLE platforms >> > earlier, as it never had multi cluster support and we wanted >> > clock-sharing information via DT. >> >> Fair enough. >> >> > - That is all fixed now. >> >> I did not see any mention of this in the cpufreq-dt driver binding >> documentation, otherwise I would have tried going this route. >> >> Do you have any references? I'd be happy to examine what would be >> necessary to go this route although, being an independent contributor, >> it may take time. > > You wouldn't find in cpufreq-dt documentation as its not specific to > that. I have seen you DT patches now, and you have created the OPP > tables mostly correctly. Just create the cpufreq-platform device for > cpufreq-dt instead of arm-big-little one. And it should just work. > Do you mean something along these lines? [1] >> Sounds reasonable to me. However, I'd just like to reiterate that this >> line of work can be pursued independently from the upstreaming of this >> series. > > I think this is the right time to upstream the right solution. Just > try it once, if you face lots of difficulties or issues, then we can > ofcourse see.. > Sure. I didn't realize things were so close to being functional. Thanks for the hint. I'll give it a shot next time my XU4 is free. > NOTE: Check how OPP nodes are required to be created now in > linux-next. They should be named like opp@<freq-hz>. Something I > noticed in your DTs. > I've fixed this in the branch. Thanks again. Cheers, - Ben [1] https://github.com/bgamari/linux/commit/285778aaff464d4dcf152f3e9e0df3d8c6909576
[toc] | [prev] | [next] | [standalone]
| From | Ben Gamari <ben@smart-cactus.org> |
|---|---|
| Date | 2015-12-07 22:20 +0100 |
| Message-ID | <qDbmp-1sP-3@gated-at.bofh.it> |
| In reply to | #1282908 |
[Multipart message — attachments visible in raw view] — view raw
Viresh Kumar <viresh.kumar@linaro.org> writes: > On 03-12-15, 11:26, Ben Gamari wrote: >> Sounds reasonable to me. However, I'd just like to reiterate that this >> line of work can be pursued independently from the upstreaming of this >> series. > > I think this is the right time to upstream the right solution. Just > try it once, if you face lots of difficulties or issues, then we can > ofcourse see.. > It looks like Bartlomiej has picked up this set. Regardless, while tracking down various devicetree issues I noticed that the cpu-supply and cpu%d-supply bindings appear to be completely undocumented. It seem as though this ought to be fixed. Cheers, - Ben
[toc] | [prev] | [next] | [standalone]
| From | Sudeep Holla <sudeep.holla@arm.com> |
|---|---|
| Date | 2015-12-03 12:10 +0100 |
| Subject | Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 |
| Message-ID | <qBzVT-4ak-17@gated-at.bofh.it> |
| In reply to | #1282725 |
On 03/12/15 06:05, Viresh Kumar wrote: [...] > > @Sudeep: What would it take you to use cpufreq-dt for ARM's platforms > ? > The main difference is that we get the OPPs from the firmware rather than DT. We may just need to abstract that part and we should be able to use it. I will have a look at it and get back to you will more details. It has been a while since I looked at cpufreq-dt. -- Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Viresh Kumar <viresh.kumar@linaro.org> |
|---|---|
| Date | 2015-12-03 12:30 +0100 |
| Subject | Re: [PATCH v5 0/12] cpufreq: Add support for Exynos 5800, 5420, and 5422 |
| Message-ID | <qBAfg-4hh-15@gated-at.bofh.it> |
| In reply to | #1282945 |
On 03-12-15, 11:05, Sudeep Holla wrote: > The main difference is that we get the OPPs from the firmware rather > than DT. We may just need to abstract that part and we should be able to > use it. I will have a look at it and get back to you will more details. > It has been a while since I looked at cpufreq-dt. I forgot that :( .. but we can then create OPPs at runtime based on what's available from firmware. And we also have an API now to set which CPUs share OPPs... so that might be used as well.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web