Hi,
This patch series removes the use of Exynos5250 specific support
from exynos-cpufreq driver and enables the use of cpufreq-dt driver
for this platform. The exynos-cpufreq driver itself is also removed
as it is no longer used/needed after Exynos5250 support removal.
This patch series has been tested on Exynos5250 based Arndale board.
Depends on:
- next-20150330 branch of linux-next kernel tree
- "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
platform" [1]
- "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
platform" [2]
- "[PATCH] cpufreq: exynos: remove dead ->need_apll_change method" [3]
[1] http://www.kernelhub.org/?msg=721136&p=2
[2] http://marc.info/?l=linux-pm&m=142868881101873&w=2
[3] https://lkml.org/lkml/2015/3/27/574
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Bartlomiej Zolnierkiewicz (1):
cpufreq: exynos: remove Exynos5250 specific cpufreq driver support
Thomas Abraham (3):
clk: samsung: exynos5250: add cpu clock configuration data and
instantiate cpu clock
ARM: dts: Exynos5250: add CPU OPP and regulator supply property
ARM: Exynos: switch to using generic cpufreq driver for Exynos5250
arch/arm/boot/dts/exynos5250-arndale.dts | 4 +
arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 +
arch/arm/boot/dts/exynos5250-snow.dts | 4 +
arch/arm/boot/dts/exynos5250-spring.dts | 4 +
arch/arm/boot/dts/exynos5250.dtsi | 22 +++
arch/arm/mach-exynos/exynos.c | 1 +
drivers/clk/samsung/clk-exynos5250.c | 31 +++++
drivers/cpufreq/Kconfig.arm | 22 ---
drivers/cpufreq/Makefile | 3 -
drivers/cpufreq/exynos-cpufreq.c | 203 ----------------------------
drivers/cpufreq/exynos-cpufreq.h | 67 ---------
drivers/cpufreq/exynos5250-cpufreq.c | 210 -----------------------------
include/dt-bindings/clock/exynos5250.h | 1 +
13 files changed, 71 insertions(+), 505 deletions(-)
delete mode 100644 drivers/cpufreq/exynos-cpufreq.c
delete mode 100644 drivers/cpufreq/exynos-cpufreq.h
delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c
--
1.7.9.5
From: Thomas Abraham <[email protected]>
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type. Add the CPU clock
configuration data and instantiate the CPU clock type for Exynos5250.
Changes by Bartlomiej:
- split Exynos5250 support from the original patch
- moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
Cc: Tomasz Figa <[email protected]>
Cc: Mike Turquette <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Signed-off-by: Thomas Abraham <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
drivers/clk/samsung/clk-exynos5250.c | 31 +++++++++++++++++++++++++++++++
include/dt-bindings/clock/exynos5250.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5250.c b/drivers/clk/samsung/clk-exynos5250.c
index 70ec3d2..d87f34d 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -19,6 +19,7 @@
#include <linux/syscore_ops.h>
#include "clk.h"
+#include "clk-cpu.h"
#define APLL_LOCK 0x0
#define APLL_CON0 0x100
@@ -748,6 +749,32 @@ static struct samsung_pll_clock exynos5250_plls[nr_plls] __initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+#define E5250_CPU_DIV0(apll, pclk_dbg, atb, periph, acp, cpud) \
+ ((((apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) | \
+ ((periph) << 12) | ((acp) << 8) | ((cpud) << 4)))
+#define E5250_CPU_DIV1(hpm, copy) \
+ (((hpm) << 4) | (copy))
+
+static const struct exynos_cpuclk_cfg_data exynos5250_armclk_d[] __initconst = {
+ { 1700000, E5250_CPU_DIV0(5, 3, 7, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 1600000, E5250_CPU_DIV0(4, 1, 7, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 1500000, E5250_CPU_DIV0(4, 1, 7, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 1400000, E5250_CPU_DIV0(4, 1, 6, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 1300000, E5250_CPU_DIV0(3, 1, 6, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 1200000, E5250_CPU_DIV0(3, 1, 5, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 1100000, E5250_CPU_DIV0(3, 1, 5, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 1000000, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 900000, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 800000, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 700000, E5250_CPU_DIV0(1, 1, 3, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 600000, E5250_CPU_DIV0(1, 1, 3, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 500000, E5250_CPU_DIV0(1, 1, 2, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 400000, E5250_CPU_DIV0(1, 1, 2, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 300000, E5250_CPU_DIV0(1, 1, 1, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 200000, E5250_CPU_DIV0(1, 1, 1, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 0 },
+};
+
static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = "samsung,clock-xxti", .data = (void *)0, },
{ },
@@ -797,6 +824,10 @@ static void __init exynos5250_clk_init(struct device_node *np)
ARRAY_SIZE(exynos5250_div_clks));
samsung_clk_register_gate(ctx, exynos5250_gate_clks,
ARRAY_SIZE(exynos5250_gate_clks));
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5250_armclk_d, ARRAY_SIZE(exynos5250_armclk_d),
+ CLK_CPU_HAS_DIV1);
/*
* Enable arm clock down (in idle) and set arm divider
diff --git a/include/dt-bindings/clock/exynos5250.h b/include/dt-bindings/clock/exynos5250.h
index 4273891d..8183d1c 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -21,6 +21,7 @@
#define CLK_FOUT_CPLL 6
#define CLK_FOUT_EPLL 7
#define CLK_FOUT_VPLL 8
+#define CLK_ARM_CLK 9
/* gate for special clocks (sclk) */
#define CLK_SCLK_CAM_BAYER 128
--
1.7.9.5
From: Thomas Abraham <[email protected]>
For Exynos5250 platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific
cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- split Exynos5250 support from the original patch
- added CPU regulator supply property for Google Spring board
Cc: Kukjin Kim <[email protected]>
Cc: Doug Anderson <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Andreas Faerber <[email protected]>
Cc: Sachin Kamat <[email protected]>
Cc: Andreas Farber <[email protected]>
Signed-off-by: Thomas Abraham <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 4 ++++
arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++++
arch/arm/boot/dts/exynos5250-snow.dts | 4 ++++
arch/arm/boot/dts/exynos5250-spring.dts | 4 ++++
arch/arm/boot/dts/exynos5250.dtsi | 22 ++++++++++++++++++++++
5 files changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index 7e728a1..c64cec3 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -560,3 +560,7 @@
status = "okay";
samsung,exynos-sataphy-i2c-phandle = <&sata_phy_i2c>;
};
+
+&cpu0 {
+ cpu0-supply = <&buck2_reg>;
+};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index bc27cc2..d91db82 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -410,3 +410,7 @@
};
};
};
+
+&cpu0 {
+ cpu0-supply = <&buck2_reg>;
+};
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts
index 2657e84..700bbc8 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -301,6 +301,10 @@
vdd_pll-supply = <&ldo8_reg>;
};
+&cpu0 {
+ cpu0-supply = <&buck2_reg>;
+};
+
&i2c_0 {
status = "okay";
samsung,i2c-sda-delay = <100>;
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
index d03f9b8..38b54d9 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -99,6 +99,10 @@
vdd_pll-supply = <&ldo8_reg>;
};
+&cpu0 {
+ cpu0-supply = <&buck2_reg>;
+};
+
&i2c_0 {
status = "okay";
samsung,i2c-sda-delay = <100>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 257e2f1..c1f7811 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -63,6 +63,28 @@
compatible = "arm,cortex-a15";
reg = <0>;
clock-frequency = <1700000000>;
+ clocks = <&clock CLK_ARM_CLK>;
+ clock-names = "cpu";
+ clock-latency = <140000>;
+
+ operating-points = <
+ 1700000 1300000
+ 1600000 1250000
+ 1500000 1225000
+ 1400000 1200000
+ 1300000 1150000
+ 1200000 1125000
+ 1100000 1100000
+ 1000000 1075000
+ 900000 1050000
+ 800000 1025000
+ 700000 1012500
+ 600000 1000000
+ 500000 975000
+ 400000 950000
+ 300000 937500
+ 200000 925000
+ >;
cooling-min-level = <15>;
cooling-max-level = <9>;
#cooling-cells = <2>; /* min followed by max */
--
1.7.9.5
From: Thomas Abraham <[email protected]>
The new CPU clock type allows the use of generic CPUfreq driver.
Switch Exynos5250 to using generic cpufreq driver.
Changes by Bartlomiej:
- split Exynos5250 support from the original patch
Cc: Tomasz Figa <[email protected]>
Cc: Kukjin Kim <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Signed-off-by: Thomas Abraham <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
arch/arm/mach-exynos/exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 637d862..4b03a32 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -206,6 +206,7 @@ struct cpufreq_dt_platform_data cpufreq_dt_pd = {
static const struct of_device_id exynos_cpufreq_matches[] = {
{ .compatible = "samsung,exynos4210", .data = "cpufreq-dt" },
+ { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
{ /* sentinel */ }
};
--
1.7.9.5
Bartlomiej Zolnierkiewicz <[email protected]> writes:
> Hi,
>
> This patch series removes the use of Exynos5250 specific support
> from exynos-cpufreq driver and enables the use of cpufreq-dt driver
> for this platform. The exynos-cpufreq driver itself is also removed
> as it is no longer used/needed after Exynos5250 support removal.
>
> This patch series has been tested on Exynos5250 based Arndale board.
>
> Depends on:
> - next-20150330 branch of linux-next kernel tree
> - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
> platform" [1]
> - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
> platform" [2]
> - "[PATCH] cpufreq: exynos: remove dead ->need_apll_change method" [3]
Any chance you could prepare a branch with all the dependencies for easy
testing?
Also, The previous version from Thomas was v12, and this one is neither
versioned nor has any reference to what may have changed since that
version. Also, on v12, I had several comments[1] and wonder if they've
been addressed.
Kevin
[1] http://article.gmane.org/gmane.linux.power-management.general/53494/match=patch+v12+0+6+use+generic+cpufreq
Hi,
On Monday, April 20, 2015 02:07:33 PM Kevin Hilman wrote:
> Bartlomiej Zolnierkiewicz <[email protected]> writes:
>
> > Hi,
> >
> > This patch series removes the use of Exynos5250 specific support
> > from exynos-cpufreq driver and enables the use of cpufreq-dt driver
> > for this platform. The exynos-cpufreq driver itself is also removed
> > as it is no longer used/needed after Exynos5250 support removal.
> >
> > This patch series has been tested on Exynos5250 based Arndale board.
> >
> > Depends on:
> > - next-20150330 branch of linux-next kernel tree
> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
> > platform" [1]
> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
> > platform" [2]
> > - "[PATCH] cpufreq: exynos: remove dead ->need_apll_change method" [3]
>
> Any chance you could prepare a branch with all the dependencies for easy
> testing?
All cpufreq changes with needed dependencies are now availble in
https://github.com/bzolnier/linux.git
repository and the branch is
next-20150330-generic-cpufreq-exynos5420-5800-v2
> Also, The previous version from Thomas was v12, and this one is neither
> versioned nor has any reference to what may have changed since that
Please note that Thomas' patchset was split on separate parts (this is
part #3) and heavily modified so the previous versioning was dropped.
The cover letter of part #1 ("[PATCH 0/6] cpufreq: use generic cpufreq
drivers for Exynos4210 platform") contains detailed changelog on what has
been changed since Thomas' original v12 patch series. Individual Thomas'
patches which were modified by me also contain such information.
Part #2 ("[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
platform") was entirely new code when compared to Thomas' v12 patchset so
its cover letter doesn't contain such detailed changelog as part #1.
The newly posted part #4 ("[PATCH 0/8] cpufreq: add generic cpufreq driver
support for Exynos5250/5800 platforms" https://lkml.org/lkml/2015/4/21/314)
also contains the detailed changelog.
However for part #3 (this one, "[PATCH 0/4] cpufreq: use generic cpufreq
drivers for Exynos5250 platform") such summary changelog got missed for
some reason. Here it is:
- split Exynos5250 support from the original patch
- moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
- added CPU regulator supply property for Google Spring board
- removed exynos-cpufreq driver entirely as it is no longer used/needed
> version. Also, on v12, I had several comments[1] and wonder if they've
> been addressed.
All issues previously reported should have been fixed. If you still see
some problems please let me know.
[ I see now that exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts,
exynos5420-smdk5420.dts and exynos5800-peach-pi.dts should also have
been updated to contain CPU cluster regulator supply properties or else
if the default vdd_arm/vdd_kfc regulator state is set to too low value
there may be problems with stability when switching to higher than
default frequencies. I have posted v2 version of patch #2/8 of part #4
and pushed v2 combined branch on github. Sorry for the inconvenience. ]
> Kevin
>
> [1] http://article.gmane.org/gmane.linux.power-management.general/53494/match=patch+v12+0+6+use+generic+cpufreq
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Bartlomiej Zolnierkiewicz <[email protected]> writes:
> On Monday, April 20, 2015 02:07:33 PM Kevin Hilman wrote:
>> Bartlomiej Zolnierkiewicz <[email protected]> writes:
>>
>> > Hi,
>> >
>> > This patch series removes the use of Exynos5250 specific support
>> > from exynos-cpufreq driver and enables the use of cpufreq-dt driver
>> > for this platform. The exynos-cpufreq driver itself is also removed
>> > as it is no longer used/needed after Exynos5250 support removal.
>> >
>> > This patch series has been tested on Exynos5250 based Arndale board.
>> >
>> > Depends on:
>> > - next-20150330 branch of linux-next kernel tree
>> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
>> > platform" [1]
>> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
>> > platform" [2]
>> > - "[PATCH] cpufreq: exynos: remove dead ->need_apll_change method" [3]
>>
>> Any chance you could prepare a branch with all the dependencies for easy
>> testing?
>
> All cpufreq changes with needed dependencies are now availble in
>
> https://github.com/bzolnier/linux.git
>
> repository and the branch is
>
> next-20150330-generic-cpufreq-exynos5420-5800-v2
Great, thanks.
>> Also, The previous version from Thomas was v12, and this one is neither
>> versioned nor has any reference to what may have changed since that
>
> Please note that Thomas' patchset was split on separate parts (this is
> part #3) and heavily modified so the previous versioning was dropped.
>
> The cover letter of part #1 ("[PATCH 0/6] cpufreq: use generic cpufreq
> drivers for Exynos4210 platform") contains detailed changelog on what has
> been changed since Thomas' original v12 patch series. Individual Thomas'
> patches which were modified by me also contain such information.
>
> Part #2 ("[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
> platform") was entirely new code when compared to Thomas' v12 patchset so
> its cover letter doesn't contain such detailed changelog as part #1.
>
> The newly posted part #4 ("[PATCH 0/8] cpufreq: add generic cpufreq driver
> support for Exynos5250/5800 platforms" https://lkml.org/lkml/2015/4/21/314)
> also contains the detailed changelog.
>
> However for part #3 (this one, "[PATCH 0/4] cpufreq: use generic cpufreq
> drivers for Exynos5250 platform") such summary changelog got missed for
> some reason. Here it is:
> - split Exynos5250 support from the original patch
> - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
> - added CPU regulator supply property for Google Spring board
> - removed exynos-cpufreq driver entirely as it is no longer used/needed
Great, thanks for clarifying.
>> version. Also, on v12, I had several comments[1] and wonder if they've
>> been addressed.
>
> All issues previously reported should have been fixed. If you still see
> some problems please let me know.
>
> [ I see now that exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts,
> exynos5420-smdk5420.dts and exynos5800-peach-pi.dts should also have
> been updated to contain CPU cluster regulator supply properties or else
> if the default vdd_arm/vdd_kfc regulator state is set to too low value
> there may be problems with stability when switching to higher than
> default frequencies. I have posted v2 version of patch #2/8 of part #4
> and pushed v2 combined branch on github. Sorry for the inconvenience. ]
I've now tested your v2 branch with the bL switcher disabled, CPUidle
enabled and CPUfreq enabled.
With the default governor set to performance, it fails to boot. The last
kernel messages on the console are:
[...]
[ 3.426021] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
[ 3.431189] cpu cpu4: bL_cpufreq_init: CPU 4 initialized
However, with the default governor set to userspace it boots fine until
my userspace (ubuntu) tries to enable the ondemand governor, and then it
hangs.
For it to boot, I have to disable the ondemand governor, and set the
default governor to userspace.
As I reported earlier on Thomas' series, I suspect this is related to
the fact that the higher OPPs aren't really functional without voltage
scaling also supported.
I'm also seeing the wait_until_divider_stable errors when switching
between the available A7 OPPs. I'd reported this one earlier as well,
along with the script to reproduce it.
Kevin
On Tuesday, April 21, 2015 04:45:56 PM Kevin Hilman wrote:
> Bartlomiej Zolnierkiewicz <[email protected]> writes:
>
> > On Monday, April 20, 2015 02:07:33 PM Kevin Hilman wrote:
> >> Bartlomiej Zolnierkiewicz <[email protected]> writes:
> >>
> >> > Hi,
> >> >
> >> > This patch series removes the use of Exynos5250 specific support
> >> > from exynos-cpufreq driver and enables the use of cpufreq-dt driver
> >> > for this platform. The exynos-cpufreq driver itself is also removed
> >> > as it is no longer used/needed after Exynos5250 support removal.
> >> >
> >> > This patch series has been tested on Exynos5250 based Arndale board.
> >> >
> >> > Depends on:
> >> > - next-20150330 branch of linux-next kernel tree
> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
> >> > platform" [1]
> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
> >> > platform" [2]
> >> > - "[PATCH] cpufreq: exynos: remove dead ->need_apll_change method" [3]
> >>
> >> Any chance you could prepare a branch with all the dependencies for easy
> >> testing?
> >
> > All cpufreq changes with needed dependencies are now availble in
> >
> > https://github.com/bzolnier/linux.git
> >
> > repository and the branch is
> >
> > next-20150330-generic-cpufreq-exynos5420-5800-v2
>
> Great, thanks.
>
> >> Also, The previous version from Thomas was v12, and this one is neither
> >> versioned nor has any reference to what may have changed since that
> >
> > Please note that Thomas' patchset was split on separate parts (this is
> > part #3) and heavily modified so the previous versioning was dropped.
> >
> > The cover letter of part #1 ("[PATCH 0/6] cpufreq: use generic cpufreq
> > drivers for Exynos4210 platform") contains detailed changelog on what has
> > been changed since Thomas' original v12 patch series. Individual Thomas'
> > patches which were modified by me also contain such information.
> >
> > Part #2 ("[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
> > platform") was entirely new code when compared to Thomas' v12 patchset so
> > its cover letter doesn't contain such detailed changelog as part #1.
> >
> > The newly posted part #4 ("[PATCH 0/8] cpufreq: add generic cpufreq driver
> > support for Exynos5250/5800 platforms" https://lkml.org/lkml/2015/4/21/314)
> > also contains the detailed changelog.
> >
> > However for part #3 (this one, "[PATCH 0/4] cpufreq: use generic cpufreq
> > drivers for Exynos5250 platform") such summary changelog got missed for
> > some reason. Here it is:
> > - split Exynos5250 support from the original patch
> > - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
> > - added CPU regulator supply property for Google Spring board
> > - removed exynos-cpufreq driver entirely as it is no longer used/needed
>
> Great, thanks for clarifying.
>
> >> version. Also, on v12, I had several comments[1] and wonder if they've
> >> been addressed.
> >
> > All issues previously reported should have been fixed. If you still see
> > some problems please let me know.
> >
> > [ I see now that exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts,
> > exynos5420-smdk5420.dts and exynos5800-peach-pi.dts should also have
> > been updated to contain CPU cluster regulator supply properties or else
> > if the default vdd_arm/vdd_kfc regulator state is set to too low value
> > there may be problems with stability when switching to higher than
> > default frequencies. I have posted v2 version of patch #2/8 of part #4
> > and pushed v2 combined branch on github. Sorry for the inconvenience. ]
>
> I've now tested your v2 branch with the bL switcher disabled, CPUidle
> enabled and CPUfreq enabled.
>
> With the default governor set to performance, it fails to boot. The last
> kernel messages on the console are:
[ Small explanation for people not following the discussion from
the start:
This testing is relevant to part #4 of the rework: "[PATCH 0/8]
cpufreq: add generic cpufreq driver support for Exynos5250/5800
platforms" (https://lkml.org/lkml/2015/4/21/314"), not this one
which is part #3 and has no known issues. ]
> [...]
> [ 3.426021] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
> [ 3.431189] cpu cpu4: bL_cpufreq_init: CPU 4 initialized
>
> However, with the default governor set to userspace it boots fine until
> my userspace (ubuntu) tries to enable the ondemand governor, and then it
> hangs.
>
> For it to boot, I have to disable the ondemand governor, and set the
> default governor to userspace.
I've tried with ARM big.LITTLE cpuidle support enabled (I've just noticed
that it is not turned on in exynos_defconfig) and my ODROID-XU3 board
fails to boot. This happens even with cpufreq support disabled (hard
lockup happens during mmc initialization which is done just after cpufreq
initialization).
Could you please check if disabling cpuidle support helps?
> As I reported earlier on Thomas' series, I suspect this is related to
> the fact that the higher OPPs aren't really functional without voltage
> scaling also supported.
Part #4 contains voltage scaling support for arm_big_little[_dt] driver
so this should not be a problem any longer.
You may try next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
branch from my github (with cpufreq debugging printks enabled) to check
whether the voltage scaling is indeed done on your board.
> I'm also seeing the wait_until_divider_stable errors when switching
> between the available A7 OPPs. I'd reported this one earlier as well,
> along with the script to reproduce it.
I've tried your script and it works fine for me (I only needed to change
cpu4 to cpu0 as on ODROID-XU3 CPUs 0,5,6,7 are A7 and 1,2,3,4 are A15).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Bartlomiej Zolnierkiewicz <[email protected]> writes:
[...]
>> However, with the default governor set to userspace it boots fine until
>> my userspace (ubuntu) tries to enable the ondemand governor, and then it
>> hangs.
>>
>> For it to boot, I have to disable the ondemand governor, and set the
>> default governor to userspace.
>
> I've tried with ARM big.LITTLE cpuidle support enabled (I've just noticed
> that it is not turned on in exynos_defconfig) and my ODROID-XU3 board
> fails to boot. This happens even with cpufreq support disabled (hard
> lockup happens during mmc initialization which is done just after cpufreq
> initialization).
Right, the XU3 has broken secure firmware such that MCPM cannot properly
control CCI, so CPUidle will hang when trying to hit low power states,
so you have to disable CCI by adding something like this to the end of
your XU3 .dts file:
&cci {
status = "disabled";
};
> Could you please check if disabling cpuidle support helps?
For now, I've disabled CPUidle so we have a similar setup, but it
doesn't change anything on exynos5800-peach-pi
>> As I reported earlier on Thomas' series, I suspect this is related to
>> the fact that the higher OPPs aren't really functional without voltage
>> scaling also supported.
>
> Part #4 contains voltage scaling support for arm_big_little[_dt] driver
> so this should not be a problem any longer.
>
> You may try next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
> branch from my github (with cpufreq debugging printks enabled) to check
> whether the voltage scaling is indeed done on your board.
>
>> I'm also seeing the wait_until_divider_stable errors when switching
>> between the available A7 OPPs. I'd reported this one earlier as well,
>> along with the script to reproduce it.
>
> I've tried your script and it works fine for me (I only needed to change
> cpu4 to cpu0 as on ODROID-XU3 CPUs 0,5,6,7 are A7 and 1,2,3,4 are A15).
Then it seems something isn't quite right for exynos5800-peach-pi.
Below is the script[1] I'm using on exynos which also checks the voltage
by quering the regulator fwk (and optionally checking the INA2xx sensors
on odroid-xu3 if that support is enabled)
On your debug branch, it just gives -1 for all the voltages, so the
regulator voltage never changes:
# ./dvfs
CPU regulator: cpu0, vdd_arm, /sys/class/regulator/regulator.18
[ 45.691483] arm_big_little: bL_cpufreq_set_rate: cpu: 0, old cluster: 0, new cluster: 0, freq: 200000
[ 45.699581] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 0, 400 MHz, -1 mV --> 200 MHz, -1 mV
current freq: 200000
current voltage: 1262500
[ 46.969821] arm_big_little: bL_cpufreq_set_rate: cpu: 0, old cluster: 0, new cluster: 0, freq: 300000
[ 46.978272] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 0, 200 MHz, -1 mV --> 300 MHz, -1 mV
current freq: 300000
current voltage: 1262500
I added a bit more debug to the cpufreq driver[1] and found that the
regulator_get_optional is failing:
[ 3.407295] cpu cpu0: Unable to get regulator cpu-cluster.0
[ 3.458282] cpu cpu4: Unable to get regulator cpu-cluster.1
Kevin
[1]
#!/bin/sh
if [ ! -d /sys/devices/system/cpu/cpu0/cpufreq ]; then
echo "CPUfreq not enabled in kernel."
exit 1
fi
# NOTE: odroid-xu3: CPU0 = A7.0, CPU1 = A15.0
cpu=cpu0
reg_name=vdd_arm
hwmon=hwmon0
#cpu=cpu4
#reg_name=vdd_kfc
#hwmon=hwmon3
cpu_reg=$(dirname `find /sys/class/regulator/regulator.*/ -name name -exec grep -l $reg_name {} \;`)
echo CPU regulator: $cpu, $reg_name, $cpu_reg
# Cycle through frequencies (and check voltage)
cd /sys/devices/system/cpu/$cpu/cpufreq
echo userspace > scaling_governor
for freq in `cat scaling_available_frequencies`; do
echo ${freq} > scaling_setspeed
sleep 0.2
echo -n "current freq: "
cat scaling_cur_freq
echo -n "current voltage: "
cat ${cpu_reg}/microvolts
# odroid-xu3 INA231 monitors
if [ ! -z $hwmon ]; then
if [ -e /sys/class/hwmon/$hwmon/in1_input ]; then
echo -n "current voltage (ina2xx)":
cat /sys/class/hwmon/$hwmon/in1_input
fi
fi
sleep 1
done
[2]
diff --git a/drivers/cpufreq/arm_big_little.c
b/drivers/cpufreq/arm_big_little.c
index 024f185b2154..4108f909cc9c 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -16,6 +16,7 @@
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
+#define DEBUG
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -446,6 +447,8 @@ static int _get_cluster_clk_and_freq_table(struct
device *cpu_dev)
ret = regulator_set_voltage_time(reg[cluster], min_uV,
max_uV);
if (ret > 0)
transition_latencies[cluster] = ret * 1000;
+ } else {
+ dev_warn(cpu_dev, "Unable to get regulator %s", name);
}
ret = dev_pm_opp_init_cpufreq_table(cpu_dev,
&freq_table[cluster]);
Hi Bartlomiej/Kevin,
I have being testing github branch on OdroidXU3 board,
Would you consider testing by applying patch.
https://lkml.org/lkml/2015/1/30/423
On my board it stuck after booting. Below is the console log.
* CPUFreq Utilities: Setting ondemand CPUFreq governor...
[ OK ] * CPU7...
[ 14.245169] wait_until_divider_stable: timeout in divider stablization
* Starting CPU Frequency daemon cpufreqd [ OK ]
[ 14.385179] wait_until_divider_stable: timeout in divider stablization
[ 14.400162] wait_until_divider_stable: timeout in divider stablization
[ 14.470180] wait_until_divider_stable: timeout in divider stablization
[ 14.525157] wait_until_divider_stable: timeout in divider stablization
[ 14.665200] wait_until_divider_stable: timeout in divider stablization
* Starting NTP server ntpd [ OK ]
saned disabled; edit /etc/default/saned
root@odroidxu3:~# [ 14.945183] wait_until_divider_stable: timeout in
divider stablization
[ 14.960159] wait_until_divider_stable: timeout in divider stablization
[ 15.085154] wait_until_divider_stable: timeout in divider stablization
[ 15.105170] wait_until_divider_stable: timeout in divider stablization
[ 15.125180] wait_until_divider_stable: timeout in divider stablization
[ 15.365147] wait_until_divider_stable: timeout in divider stablization
[ 15.505163] wait_until_divider_stable: timeout in divider stablization
[ 15.520167] wait_until_divider_stable: timeout in divider stablization
[ 15.930146] wait_until_divider_stable: timeout in divider stablization
[ 17.765953] BUG: scheduling while atomic: kswitcher_7/1456/0x00000002
root@odroidxu3:~#
root@odroidxu3:~# [ 23.625134] wait_until_divider_stable: timeout in
divider stablization
[ 23.640137] wait_until_divider_stable: timeout in divider stablization
root@odroidxu3:~#
root@odroidxu3:~#
root@odroidxu3:~#
root@odroidxu3:~#
root@odroidxu3:~#
root@odroidxu3:~#
root@odroidxu3:~#
root@odroidxu3:~#
root@odroidxu3:~#
root@odroidxu3:~# [ 26.215135] wait_until_divider_stable: timeout in
divider stablization
[ 26.230135] wait_until_divider_stable: timeout in divider stablization
[ 26.237850] BUG: scheduling while atomic: kswitcher_7/1456/0x00000002
[ 26.243196] Preemption disabled at:[< (null)>] (null)
root@odroidxu3:~#
root@odroidxu3:~# [ 26.282330] BUG: scheduling while atomic:
kswitcher_7/1456/0x00000002
[ 26.287501] Preemption disabled at:[< (null)>] (null)
[ 26.293244] BUG: scheduling while atomic: kswitcher_7/1456/0x00000002
[ 26.299170] Preemption disabled at:[< (null)>] (null)
root@odroidxu3:~# [ 27.660264] Unable to handle kernel paging
request at virtual address ac22254f
[ 27.660633] Unable to handle kernel paging request at virtual
address 76688788
-Anand Moon
On 22 April 2015 at 23:07, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
>
> On Tuesday, April 21, 2015 04:45:56 PM Kevin Hilman wrote:
>> Bartlomiej Zolnierkiewicz <[email protected]> writes:
>>
>> > On Monday, April 20, 2015 02:07:33 PM Kevin Hilman wrote:
>> >> Bartlomiej Zolnierkiewicz <[email protected]> writes:
>> >>
>> >> > Hi,
>> >> >
>> >> > This patch series removes the use of Exynos5250 specific support
>> >> > from exynos-cpufreq driver and enables the use of cpufreq-dt driver
>> >> > for this platform. The exynos-cpufreq driver itself is also removed
>> >> > as it is no longer used/needed after Exynos5250 support removal.
>> >> >
>> >> > This patch series has been tested on Exynos5250 based Arndale board.
>> >> >
>> >> > Depends on:
>> >> > - next-20150330 branch of linux-next kernel tree
>> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
>> >> > platform" [1]
>> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
>> >> > platform" [2]
>> >> > - "[PATCH] cpufreq: exynos: remove dead ->need_apll_change method" [3]
>> >>
>> >> Any chance you could prepare a branch with all the dependencies for easy
>> >> testing?
>> >
>> > All cpufreq changes with needed dependencies are now availble in
>> >
>> > https://github.com/bzolnier/linux.git
>> >
>> > repository and the branch is
>> >
>> > next-20150330-generic-cpufreq-exynos5420-5800-v2
>>
>> Great, thanks.
>>
>> >> Also, The previous version from Thomas was v12, and this one is neither
>> >> versioned nor has any reference to what may have changed since that
>> >
>> > Please note that Thomas' patchset was split on separate parts (this is
>> > part #3) and heavily modified so the previous versioning was dropped.
>> >
>> > The cover letter of part #1 ("[PATCH 0/6] cpufreq: use generic cpufreq
>> > drivers for Exynos4210 platform") contains detailed changelog on what has
>> > been changed since Thomas' original v12 patch series. Individual Thomas'
>> > patches which were modified by me also contain such information.
>> >
>> > Part #2 ("[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
>> > platform") was entirely new code when compared to Thomas' v12 patchset so
>> > its cover letter doesn't contain such detailed changelog as part #1.
>> >
>> > The newly posted part #4 ("[PATCH 0/8] cpufreq: add generic cpufreq driver
>> > support for Exynos5250/5800 platforms" https://lkml.org/lkml/2015/4/21/314)
>> > also contains the detailed changelog.
>> >
>> > However for part #3 (this one, "[PATCH 0/4] cpufreq: use generic cpufreq
>> > drivers for Exynos5250 platform") such summary changelog got missed for
>> > some reason. Here it is:
>> > - split Exynos5250 support from the original patch
>> > - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
>> > - added CPU regulator supply property for Google Spring board
>> > - removed exynos-cpufreq driver entirely as it is no longer used/needed
>>
>> Great, thanks for clarifying.
>>
>> >> version. Also, on v12, I had several comments[1] and wonder if they've
>> >> been addressed.
>> >
>> > All issues previously reported should have been fixed. If you still see
>> > some problems please let me know.
>> >
>> > [ I see now that exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts,
>> > exynos5420-smdk5420.dts and exynos5800-peach-pi.dts should also have
>> > been updated to contain CPU cluster regulator supply properties or else
>> > if the default vdd_arm/vdd_kfc regulator state is set to too low value
>> > there may be problems with stability when switching to higher than
>> > default frequencies. I have posted v2 version of patch #2/8 of part #4
>> > and pushed v2 combined branch on github. Sorry for the inconvenience. ]
>>
>> I've now tested your v2 branch with the bL switcher disabled, CPUidle
>> enabled and CPUfreq enabled.
>>
>> With the default governor set to performance, it fails to boot. The last
>> kernel messages on the console are:
>
> [ Small explanation for people not following the discussion from
> the start:
>
> This testing is relevant to part #4 of the rework: "[PATCH 0/8]
> cpufreq: add generic cpufreq driver support for Exynos5250/5800
> platforms" (https://lkml.org/lkml/2015/4/21/314"), not this one
> which is part #3 and has no known issues. ]
>
>> [...]
>> [ 3.426021] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
>> [ 3.431189] cpu cpu4: bL_cpufreq_init: CPU 4 initialized
>>
>> However, with the default governor set to userspace it boots fine until
>> my userspace (ubuntu) tries to enable the ondemand governor, and then it
>> hangs.
>>
>> For it to boot, I have to disable the ondemand governor, and set the
>> default governor to userspace.
>
> I've tried with ARM big.LITTLE cpuidle support enabled (I've just noticed
> that it is not turned on in exynos_defconfig) and my ODROID-XU3 board
> fails to boot. This happens even with cpufreq support disabled (hard
> lockup happens during mmc initialization which is done just after cpufreq
> initialization).
>
> Could you please check if disabling cpuidle support helps?
>
>> As I reported earlier on Thomas' series, I suspect this is related to
>> the fact that the higher OPPs aren't really functional without voltage
>> scaling also supported.
>
> Part #4 contains voltage scaling support for arm_big_little[_dt] driver
> so this should not be a problem any longer.
>
> You may try next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
> branch from my github (with cpufreq debugging printks enabled) to check
> whether the voltage scaling is indeed done on your board.
>
>> I'm also seeing the wait_until_divider_stable errors when switching
>> between the available A7 OPPs. I'd reported this one earlier as well,
>> along with the script to reproduce it.
>
> I've tried your script and it works fine for me (I only needed to change
> cpu4 to cpu0 as on ODROID-XU3 CPUs 0,5,6,7 are A7 and 1,2,3,4 are A15).
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
On Friday, April 24, 2015 12:02:11 AM Anand Moon wrote:
> Hi Bartlomiej/Kevin,
>
> I have being testing github branch on OdroidXU3 board,
>
> Would you consider testing by applying patch.
>
> https://lkml.org/lkml/2015/1/30/423
>
> On my board it stuck after booting. Below is the console log.
The kernel with the above patch works just fine for me
(with both DEBUG_PREEMPT and DEBUG_ATOMIC_SLEEP enabled).
Could you please share your kernel config?
Also, is the user-space image that you're using available somewhere?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> * CPUFreq Utilities: Setting ondemand CPUFreq governor...
> [ OK ] * CPU7...
> [ 14.245169] wait_until_divider_stable: timeout in divider stablization
> * Starting CPU Frequency daemon cpufreqd [ OK ]
> [ 14.385179] wait_until_divider_stable: timeout in divider stablization
> [ 14.400162] wait_until_divider_stable: timeout in divider stablization
> [ 14.470180] wait_until_divider_stable: timeout in divider stablization
> [ 14.525157] wait_until_divider_stable: timeout in divider stablization
> [ 14.665200] wait_until_divider_stable: timeout in divider stablization
> * Starting NTP server ntpd [ OK ]
> saned disabled; edit /etc/default/saned
> root@odroidxu3:~# [ 14.945183] wait_until_divider_stable: timeout in
> divider stablization
> [ 14.960159] wait_until_divider_stable: timeout in divider stablization
> [ 15.085154] wait_until_divider_stable: timeout in divider stablization
> [ 15.105170] wait_until_divider_stable: timeout in divider stablization
> [ 15.125180] wait_until_divider_stable: timeout in divider stablization
> [ 15.365147] wait_until_divider_stable: timeout in divider stablization
> [ 15.505163] wait_until_divider_stable: timeout in divider stablization
> [ 15.520167] wait_until_divider_stable: timeout in divider stablization
> [ 15.930146] wait_until_divider_stable: timeout in divider stablization
> [ 17.765953] BUG: scheduling while atomic: kswitcher_7/1456/0x00000002
>
> root@odroidxu3:~#
> root@odroidxu3:~# [ 23.625134] wait_until_divider_stable: timeout in
> divider stablization
> [ 23.640137] wait_until_divider_stable: timeout in divider stablization
>
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~#
> root@odroidxu3:~# [ 26.215135] wait_until_divider_stable: timeout in
> divider stablization
> [ 26.230135] wait_until_divider_stable: timeout in divider stablization
> [ 26.237850] BUG: scheduling while atomic: kswitcher_7/1456/0x00000002
> [ 26.243196] Preemption disabled at:[< (null)>] (null)
>
> root@odroidxu3:~#
> root@odroidxu3:~# [ 26.282330] BUG: scheduling while atomic:
> kswitcher_7/1456/0x00000002
> [ 26.287501] Preemption disabled at:[< (null)>] (null)
> [ 26.293244] BUG: scheduling while atomic: kswitcher_7/1456/0x00000002
> [ 26.299170] Preemption disabled at:[< (null)>] (null)
>
> root@odroidxu3:~# [ 27.660264] Unable to handle kernel paging
> request at virtual address ac22254f
> [ 27.660633] Unable to handle kernel paging request at virtual
> address 76688788
>
> -Anand Moon
>
>
> On 22 April 2015 at 23:07, Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> >
> > On Tuesday, April 21, 2015 04:45:56 PM Kevin Hilman wrote:
> >> Bartlomiej Zolnierkiewicz <[email protected]> writes:
> >>
> >> > On Monday, April 20, 2015 02:07:33 PM Kevin Hilman wrote:
> >> >> Bartlomiej Zolnierkiewicz <[email protected]> writes:
> >> >>
> >> >> > Hi,
> >> >> >
> >> >> > This patch series removes the use of Exynos5250 specific support
> >> >> > from exynos-cpufreq driver and enables the use of cpufreq-dt driver
> >> >> > for this platform. The exynos-cpufreq driver itself is also removed
> >> >> > as it is no longer used/needed after Exynos5250 support removal.
> >> >> >
> >> >> > This patch series has been tested on Exynos5250 based Arndale board.
> >> >> >
> >> >> > Depends on:
> >> >> > - next-20150330 branch of linux-next kernel tree
> >> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
> >> >> > platform" [1]
> >> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
> >> >> > platform" [2]
> >> >> > - "[PATCH] cpufreq: exynos: remove dead ->need_apll_change method" [3]
> >> >>
> >> >> Any chance you could prepare a branch with all the dependencies for easy
> >> >> testing?
> >> >
> >> > All cpufreq changes with needed dependencies are now availble in
> >> >
> >> > https://github.com/bzolnier/linux.git
> >> >
> >> > repository and the branch is
> >> >
> >> > next-20150330-generic-cpufreq-exynos5420-5800-v2
> >>
> >> Great, thanks.
> >>
> >> >> Also, The previous version from Thomas was v12, and this one is neither
> >> >> versioned nor has any reference to what may have changed since that
> >> >
> >> > Please note that Thomas' patchset was split on separate parts (this is
> >> > part #3) and heavily modified so the previous versioning was dropped.
> >> >
> >> > The cover letter of part #1 ("[PATCH 0/6] cpufreq: use generic cpufreq
> >> > drivers for Exynos4210 platform") contains detailed changelog on what has
> >> > been changed since Thomas' original v12 patch series. Individual Thomas'
> >> > patches which were modified by me also contain such information.
> >> >
> >> > Part #2 ("[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
> >> > platform") was entirely new code when compared to Thomas' v12 patchset so
> >> > its cover letter doesn't contain such detailed changelog as part #1.
> >> >
> >> > The newly posted part #4 ("[PATCH 0/8] cpufreq: add generic cpufreq driver
> >> > support for Exynos5250/5800 platforms" https://lkml.org/lkml/2015/4/21/314)
> >> > also contains the detailed changelog.
> >> >
> >> > However for part #3 (this one, "[PATCH 0/4] cpufreq: use generic cpufreq
> >> > drivers for Exynos5250 platform") such summary changelog got missed for
> >> > some reason. Here it is:
> >> > - split Exynos5250 support from the original patch
> >> > - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
> >> > - added CPU regulator supply property for Google Spring board
> >> > - removed exynos-cpufreq driver entirely as it is no longer used/needed
> >>
> >> Great, thanks for clarifying.
> >>
> >> >> version. Also, on v12, I had several comments[1] and wonder if they've
> >> >> been addressed.
> >> >
> >> > All issues previously reported should have been fixed. If you still see
> >> > some problems please let me know.
> >> >
> >> > [ I see now that exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts,
> >> > exynos5420-smdk5420.dts and exynos5800-peach-pi.dts should also have
> >> > been updated to contain CPU cluster regulator supply properties or else
> >> > if the default vdd_arm/vdd_kfc regulator state is set to too low value
> >> > there may be problems with stability when switching to higher than
> >> > default frequencies. I have posted v2 version of patch #2/8 of part #4
> >> > and pushed v2 combined branch on github. Sorry for the inconvenience. ]
> >>
> >> I've now tested your v2 branch with the bL switcher disabled, CPUidle
> >> enabled and CPUfreq enabled.
> >>
> >> With the default governor set to performance, it fails to boot. The last
> >> kernel messages on the console are:
> >
> > [ Small explanation for people not following the discussion from
> > the start:
> >
> > This testing is relevant to part #4 of the rework: "[PATCH 0/8]
> > cpufreq: add generic cpufreq driver support for Exynos5250/5800
> > platforms" (https://lkml.org/lkml/2015/4/21/314"), not this one
> > which is part #3 and has no known issues. ]
> >
> >> [...]
> >> [ 3.426021] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
> >> [ 3.431189] cpu cpu4: bL_cpufreq_init: CPU 4 initialized
> >>
> >> However, with the default governor set to userspace it boots fine until
> >> my userspace (ubuntu) tries to enable the ondemand governor, and then it
> >> hangs.
> >>
> >> For it to boot, I have to disable the ondemand governor, and set the
> >> default governor to userspace.
> >
> > I've tried with ARM big.LITTLE cpuidle support enabled (I've just noticed
> > that it is not turned on in exynos_defconfig) and my ODROID-XU3 board
> > fails to boot. This happens even with cpufreq support disabled (hard
> > lockup happens during mmc initialization which is done just after cpufreq
> > initialization).
> >
> > Could you please check if disabling cpuidle support helps?
> >
> >> As I reported earlier on Thomas' series, I suspect this is related to
> >> the fact that the higher OPPs aren't really functional without voltage
> >> scaling also supported.
> >
> > Part #4 contains voltage scaling support for arm_big_little[_dt] driver
> > so this should not be a problem any longer.
> >
> > You may try next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
> > branch from my github (with cpufreq debugging printks enabled) to check
> > whether the voltage scaling is indeed done on your board.
> >
> >> I'm also seeing the wait_until_divider_stable errors when switching
> >> between the available A7 OPPs. I'd reported this one earlier as well,
> >> along with the script to reproduce it.
> >
> > I've tried your script and it works fine for me (I only needed to change
> > cpu4 to cpu0 as on ODROID-XU3 CPUs 0,5,6,7 are A7 and 1,2,3,4 are A15).
> >
> > Best regards,
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R&D Institute Poland
> > Samsung Electronics
Hello Bartlomiej,
On 04/22/2015 07:37 PM, Bartlomiej Zolnierkiewicz wrote:
>
> On Tuesday, April 21, 2015 04:45:56 PM Kevin Hilman wrote:
>> Bartlomiej Zolnierkiewicz <[email protected]> writes:
>>
>> > On Monday, April 20, 2015 02:07:33 PM Kevin Hilman wrote:
>> >> Bartlomiej Zolnierkiewicz <[email protected]> writes:
>> >>
>> >> > Hi,
>> >> >
>> >> > This patch series removes the use of Exynos5250 specific support
>> >> > from exynos-cpufreq driver and enables the use of cpufreq-dt driver
>> >> > for this platform. The exynos-cpufreq driver itself is also removed
>> >> > as it is no longer used/needed after Exynos5250 support removal.
>> >> >
>> >> > This patch series has been tested on Exynos5250 based Arndale board.
>> >> >
>> >> > Depends on:
>> >> > - next-20150330 branch of linux-next kernel tree
>> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
>> >> > platform" [1]
>> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
>> >> > platform" [2]
>> >> > - "[PATCH] cpufreq: exynos: remove dead ->need_apll_change method" [3]
>> >>
>> >> Any chance you could prepare a branch with all the dependencies for easy
>> >> testing?
>> >
>> > All cpufreq changes with needed dependencies are now availble in
>> >
>> > https://github.com/bzolnier/linux.git
>> >
>> > repository and the branch is
>> >
>> > next-20150330-generic-cpufreq-exynos5420-5800-v2
>>
>> Great, thanks.
>>
>> >> Also, The previous version from Thomas was v12, and this one is neither
>> >> versioned nor has any reference to what may have changed since that
>> >
>> > Please note that Thomas' patchset was split on separate parts (this is
>> > part #3) and heavily modified so the previous versioning was dropped.
>> >
>> > The cover letter of part #1 ("[PATCH 0/6] cpufreq: use generic cpufreq
>> > drivers for Exynos4210 platform") contains detailed changelog on what has
>> > been changed since Thomas' original v12 patch series. Individual Thomas'
>> > patches which were modified by me also contain such information.
>> >
>> > Part #2 ("[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
>> > platform") was entirely new code when compared to Thomas' v12 patchset so
>> > its cover letter doesn't contain such detailed changelog as part #1.
>> >
>> > The newly posted part #4 ("[PATCH 0/8] cpufreq: add generic cpufreq driver
>> > support for Exynos5250/5800 platforms" https://lkml.org/lkml/2015/4/21/314)
>> > also contains the detailed changelog.
>> >
>> > However for part #3 (this one, "[PATCH 0/4] cpufreq: use generic cpufreq
>> > drivers for Exynos5250 platform") such summary changelog got missed for
>> > some reason. Here it is:
>> > - split Exynos5250 support from the original patch
>> > - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
>> > - added CPU regulator supply property for Google Spring board
>> > - removed exynos-cpufreq driver entirely as it is no longer used/needed
>>
>> Great, thanks for clarifying.
>>
>> >> version. Also, on v12, I had several comments[1] and wonder if they've
>> >> been addressed.
>> >
>> > All issues previously reported should have been fixed. If you still see
>> > some problems please let me know.
>> >
>> > [ I see now that exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts,
>> > exynos5420-smdk5420.dts and exynos5800-peach-pi.dts should also have
>> > been updated to contain CPU cluster regulator supply properties or else
>> > if the default vdd_arm/vdd_kfc regulator state is set to too low value
>> > there may be problems with stability when switching to higher than
>> > default frequencies. I have posted v2 version of patch #2/8 of part #4
>> > and pushed v2 combined branch on github. Sorry for the inconvenience. ]
>>
>> I've now tested your v2 branch with the bL switcher disabled, CPUidle
>> enabled and CPUfreq enabled.
>>
>> With the default governor set to performance, it fails to boot. The last
>> kernel messages on the console are:
>
> [ Small explanation for people not following the discussion from
> the start:
>
> This testing is relevant to part #4 of the rework: "[PATCH 0/8]
> cpufreq: add generic cpufreq driver support for Exynos5250/5800
> platforms" (https://lkml.org/lkml/2015/4/21/314"), not this one
> which is part #3 and has no known issues. ]
>
I know that Exynos5420/5422/5800 is related to part #4 and not #3 but I
wanted to answer in this thread since here is where Kevin reported the
issue. I tried your next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
branch with exynos_defconfig plus CONFIG_BL_SWITCHER disabled and:
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
CONFIG_ARM_DT_BL_CPUFREQ=y
By default CONFIG_CPU_FREQ_GOV_PERFORMANCE=y but with that option it fails
to boot as well on my Exynos5420 Peach Pit so seems to be exactly what Kevin
reported on the Exynos5800 Peach Pi Chromebook.
>> [...]
>> [ 3.426021] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
>> [ 3.431189] cpu cpu4: bL_cpufreq_init: CPU 4 initialized
>>
>> However, with the default governor set to userspace it boots fine until
>> my userspace (ubuntu) tries to enable the ondemand governor, and then it
>> hangs.
>>
>> For it to boot, I have to disable the ondemand governor, and set the
>> default governor to userspace.
Disabling CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE and the performance
governor and enabling the userpace governor and setting it as default
makes the kernel to boot again which is the same behaviour Kevin had.
Also I can see that the CPUS have a cpufreq and the scaling driver
is the arm b.L one:
# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
arm-big-little
arm-big-little
arm-big-little
arm-big-little
arm-big-little
arm-big-little
arm-big-little
arm-big-little
>
> I've tried with ARM big.LITTLE cpuidle support enabled (I've just noticed
> that it is not turned on in exynos_defconfig) and my ODROID-XU3 board
> fails to boot. This happens even with cpufreq support disabled (hard
> lockup happens during mmc initialization which is done just after cpufreq
> initialization).
>
> Could you please check if disabling cpuidle support helps?
I don't have CPUIdle enabled since as you said is not turned on in exynos
defconfig by default so I think that is just a red herring.
>
>> As I reported earlier on Thomas' series, I suspect this is related to
>> the fact that the higher OPPs aren't really functional without voltage
>> scaling also supported.
>
> Part #4 contains voltage scaling support for arm_big_little[_dt] driver
> so this should not be a problem any longer.
>
> You may try next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
> branch from my github (with cpufreq debugging printks enabled) to check
> whether the voltage scaling is indeed done on your board.
>
The last boot log shown on the serial console with your debug branch is:
[ 3.078885] cpu cpu0: _get_cluster_clk_and_freq_table: clk: ee516a80 & freq table: ee511540, cluster: 0
[ 3.088128] cpu cpu0: bL_cpufreq_init: CPU 0 physical_cluster 0
[ 3.094024] cpu cpu0: bL_cpufreq_init: CPU 1 physical_cluster 0
[ 3.099912] cpu cpu0: bL_cpufreq_init: CPU 2 physical_cluster 0
[ 3.105871] cpu cpu0: bL_cpufreq_init: CPU 3 physical_cluster 0
[ 3.111710] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
[ 3.117291] cpu cpu4: _get_cluster_clk_and_freq_table: clk: ee516d80 & freq table: ee50c180, cluster: 1
[ 3.126379] cpu cpu4: bL_cpufreq_init: CPU 4 physical_cluster 1
[ 3.132276] cpu cpu4: bL_cpufreq_init: CPU 5 physical_cluster 1
[ 3.138169] cpu cpu4: bL_cpufreq_init: CPU 6 physical_cluster 1
[ 3.144069] cpu cpu4: bL_cpufreq_init: CPU 7 physical_cluster 1
[ 3.149967] cpu cpu4: bL_cpufreq_init: CPU 4 initialized
[ 3.155453] arm_big_little: bL_cpufreq_set_rate: cpu: 4, old cluster: 1, new cluster: 1, freq: 1300000
[ 3.164551] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 4, cluster: 1, 600 MHz, -1 mV --> 1300 MHz, -1 mV
[ 3.174646] arm_big_little: bL_cpufreq_register: Registered platform driver: dt-bl
[ 3.182305] Unable to handle kernel paging request at virtual address 60000186
so it seems to be a bug in the code and not about OPPs not functional due
voltage scaling not working as Kevin guessed.
However, as Kevin mentioned is strange that the regulator voltages are -1
as you can see in the above boot log.
Also when setting a scaling_setspeed to one of the scaling available
frequencies for a given CPU, I see in the log that the frequency is
scaled for all the cluster and correctly reported in scaling_cur_freq
but the scaled voltage is always reported as -1 again:
[ 899.002840] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 0, 1800 MHz, -1 mV --> 1100 MHz, -1 mV
[ 946.153852] arm_big_little: bL_cpufreq_set_rate: cpu: 0, old cluster: 0, new cluster: 0, freq: 1200000
[ 946.161785] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 0, 1100 MHz, -1 mV --> 1200 MHz, -1 mV
[ 975.328748] arm_big_little: bL_cpufreq_set_rate: cpu: 4, old cluster: 1, new cluster: 1, freq: 1200000
[ 975.336663] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 4, cluster: 1, 600 MHz, -1 mV --> 1200 MHz, -1 mV
>> I'm also seeing the wait_until_divider_stable errors when switching
>> between the available A7 OPPs. I'd reported this one earlier as well,
>> along with the script to reproduce it.
>
> I've tried your script and it works fine for me (I only needed to change
> cpu4 to cpu0 as on ODROID-XU3 CPUs 0,5,6,7 are A7 and 1,2,3,4 are A15).
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Best regards,
Javier
On 15 May 2015 at 23:18, Javier Martinez Canillas
<[email protected]> wrote:
> Hello Bartlomiej,
>
> On 04/22/2015 07:37 PM, Bartlomiej Zolnierkiewicz wrote:
>>
>> On Tuesday, April 21, 2015 04:45:56 PM Kevin Hilman wrote:
>>> Bartlomiej Zolnierkiewicz <[email protected]> writes:
>>>
>>> > On Monday, April 20, 2015 02:07:33 PM Kevin Hilman wrote:
>>> >> Bartlomiej Zolnierkiewicz <[email protected]> writes:
>>> >>
>>> >> > Hi,
>>> >> >
>>> >> > This patch series removes the use of Exynos5250 specific support
>>> >> > from exynos-cpufreq driver and enables the use of cpufreq-dt driver
>>> >> > for this platform. The exynos-cpufreq driver itself is also removed
>>> >> > as it is no longer used/needed after Exynos5250 support removal.
>>> >> >
>>> >> > This patch series has been tested on Exynos5250 based Arndale board.
>>> >> >
>>> >> > Depends on:
>>> >> > - next-20150330 branch of linux-next kernel tree
>>> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210
>>> >> > platform" [1]
>>> >> > - "[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
>>> >> > platform" [2]
>>> >> > - "[PATCH] cpufreq: exynos: remove dead ->need_apll_change method" [3]
>>> >>
>>> >> Any chance you could prepare a branch with all the dependencies for easy
>>> >> testing?
>>> >
>>> > All cpufreq changes with needed dependencies are now availble in
>>> >
>>> > https://github.com/bzolnier/linux.git
>>> >
>>> > repository and the branch is
>>> >
>>> > next-20150330-generic-cpufreq-exynos5420-5800-v2
>>>
>>> Great, thanks.
>>>
>>> >> Also, The previous version from Thomas was v12, and this one is neither
>>> >> versioned nor has any reference to what may have changed since that
>>> >
>>> > Please note that Thomas' patchset was split on separate parts (this is
>>> > part #3) and heavily modified so the previous versioning was dropped.
>>> >
>>> > The cover letter of part #1 ("[PATCH 0/6] cpufreq: use generic cpufreq
>>> > drivers for Exynos4210 platform") contains detailed changelog on what has
>>> > been changed since Thomas' original v12 patch series. Individual Thomas'
>>> > patches which were modified by me also contain such information.
>>> >
>>> > Part #2 ("[PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12
>>> > platform") was entirely new code when compared to Thomas' v12 patchset so
>>> > its cover letter doesn't contain such detailed changelog as part #1.
>>> >
>>> > The newly posted part #4 ("[PATCH 0/8] cpufreq: add generic cpufreq driver
>>> > support for Exynos5250/5800 platforms" https://lkml.org/lkml/2015/4/21/314)
>>> > also contains the detailed changelog.
>>> >
>>> > However for part #3 (this one, "[PATCH 0/4] cpufreq: use generic cpufreq
>>> > drivers for Exynos5250 platform") such summary changelog got missed for
>>> > some reason. Here it is:
>>> > - split Exynos5250 support from the original patch
>>> > - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
>>> > - added CPU regulator supply property for Google Spring board
>>> > - removed exynos-cpufreq driver entirely as it is no longer used/needed
>>>
>>> Great, thanks for clarifying.
>>>
>>> >> version. Also, on v12, I had several comments[1] and wonder if they've
>>> >> been addressed.
>>> >
>>> > All issues previously reported should have been fixed. If you still see
>>> > some problems please let me know.
>>> >
>>> > [ I see now that exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts,
>>> > exynos5420-smdk5420.dts and exynos5800-peach-pi.dts should also have
>>> > been updated to contain CPU cluster regulator supply properties or else
>>> > if the default vdd_arm/vdd_kfc regulator state is set to too low value
>>> > there may be problems with stability when switching to higher than
>>> > default frequencies. I have posted v2 version of patch #2/8 of part #4
>>> > and pushed v2 combined branch on github. Sorry for the inconvenience. ]
>>>
>>> I've now tested your v2 branch with the bL switcher disabled, CPUidle
>>> enabled and CPUfreq enabled.
>>>
>>> With the default governor set to performance, it fails to boot. The last
>>> kernel messages on the console are:
>>
>> [ Small explanation for people not following the discussion from
>> the start:
>>
>> This testing is relevant to part #4 of the rework: "[PATCH 0/8]
>> cpufreq: add generic cpufreq driver support for Exynos5250/5800
>> platforms" (https://lkml.org/lkml/2015/4/21/314"), not this one
>> which is part #3 and has no known issues. ]
>>
>
> I know that Exynos5420/5422/5800 is related to part #4 and not #3 but I
> wanted to answer in this thread since here is where Kevin reported the
> issue. I tried your next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
> branch with exynos_defconfig plus CONFIG_BL_SWITCHER disabled and:
>
> CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
> CONFIG_ARM_DT_BL_CPUFREQ=y
>
> By default CONFIG_CPU_FREQ_GOV_PERFORMANCE=y but with that option it fails
> to boot as well on my Exynos5420 Peach Pit so seems to be exactly what Kevin
> reported on the Exynos5800 Peach Pi Chromebook.
>
>>> [...]
>>> [ 3.426021] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
>>> [ 3.431189] cpu cpu4: bL_cpufreq_init: CPU 4 initialized
>>>
>>> However, with the default governor set to userspace it boots fine until
>>> my userspace (ubuntu) tries to enable the ondemand governor, and then it
>>> hangs.
>>>
>>> For it to boot, I have to disable the ondemand governor, and set the
>>> default governor to userspace.
>
> Disabling CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE and the performance
> governor and enabling the userpace governor and setting it as default
> makes the kernel to boot again which is the same behaviour Kevin had.
>
> Also I can see that the CPUS have a cpufreq and the scaling driver
> is the arm b.L one:
>
> # cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
> arm-big-little
> arm-big-little
> arm-big-little
> arm-big-little
> arm-big-little
> arm-big-little
> arm-big-little
> arm-big-little
>
>>
>> I've tried with ARM big.LITTLE cpuidle support enabled (I've just noticed
>> that it is not turned on in exynos_defconfig) and my ODROID-XU3 board
>> fails to boot. This happens even with cpufreq support disabled (hard
>> lockup happens during mmc initialization which is done just after cpufreq
>> initialization).
>>
>> Could you please check if disabling cpuidle support helps?
>
> I don't have CPUIdle enabled since as you said is not turned on in exynos
> defconfig by default so I think that is just a red herring.
>
>>
>>> As I reported earlier on Thomas' series, I suspect this is related to
>>> the fact that the higher OPPs aren't really functional without voltage
>>> scaling also supported.
>>
>> Part #4 contains voltage scaling support for arm_big_little[_dt] driver
>> so this should not be a problem any longer.
>>
>> You may try next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
>> branch from my github (with cpufreq debugging printks enabled) to check
>> whether the voltage scaling is indeed done on your board.
>>
>
> The last boot log shown on the serial console with your debug branch is:
>
> [ 3.078885] cpu cpu0: _get_cluster_clk_and_freq_table: clk: ee516a80 & freq table: ee511540, cluster: 0
> [ 3.088128] cpu cpu0: bL_cpufreq_init: CPU 0 physical_cluster 0
> [ 3.094024] cpu cpu0: bL_cpufreq_init: CPU 1 physical_cluster 0
> [ 3.099912] cpu cpu0: bL_cpufreq_init: CPU 2 physical_cluster 0
> [ 3.105871] cpu cpu0: bL_cpufreq_init: CPU 3 physical_cluster 0
> [ 3.111710] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
> [ 3.117291] cpu cpu4: _get_cluster_clk_and_freq_table: clk: ee516d80 & freq table: ee50c180, cluster: 1
> [ 3.126379] cpu cpu4: bL_cpufreq_init: CPU 4 physical_cluster 1
> [ 3.132276] cpu cpu4: bL_cpufreq_init: CPU 5 physical_cluster 1
> [ 3.138169] cpu cpu4: bL_cpufreq_init: CPU 6 physical_cluster 1
> [ 3.144069] cpu cpu4: bL_cpufreq_init: CPU 7 physical_cluster 1
> [ 3.149967] cpu cpu4: bL_cpufreq_init: CPU 4 initialized
> [ 3.155453] arm_big_little: bL_cpufreq_set_rate: cpu: 4, old cluster: 1, new cluster: 1, freq: 1300000
> [ 3.164551] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 4, cluster: 1, 600 MHz, -1 mV --> 1300 MHz, -1 mV
> [ 3.174646] arm_big_little: bL_cpufreq_register: Registered platform driver: dt-bl
> [ 3.182305] Unable to handle kernel paging request at virtual address 60000186
>
> so it seems to be a bug in the code and not about OPPs not functional due
> voltage scaling not working as Kevin guessed.
>
> However, as Kevin mentioned is strange that the regulator voltages are -1
> as you can see in the above boot log.
>
> Also when setting a scaling_setspeed to one of the scaling available
> frequencies for a given CPU, I see in the log that the frequency is
> scaled for all the cluster and correctly reported in scaling_cur_freq
> but the scaled voltage is always reported as -1 again:
>
> [ 899.002840] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 0, 1800 MHz, -1 mV --> 1100 MHz, -1 mV
> [ 946.153852] arm_big_little: bL_cpufreq_set_rate: cpu: 0, old cluster: 0, new cluster: 0, freq: 1200000
> [ 946.161785] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 0, 1100 MHz, -1 mV --> 1200 MHz, -1 mV
> [ 975.328748] arm_big_little: bL_cpufreq_set_rate: cpu: 4, old cluster: 1, new cluster: 1, freq: 1200000
> [ 975.336663] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 4, cluster: 1, 600 MHz, -1 mV --> 1200 MHz, -1 mV
>
>>> I'm also seeing the wait_until_divider_stable errors when switching
>>> between the available A7 OPPs. I'd reported this one earlier as well,
>>> along with the script to reproduce it.
>>
>> I've tried your script and it works fine for me (I only needed to change
>> cpu4 to cpu0 as on ODROID-XU3 CPUs 0,5,6,7 are A7 and 1,2,3,4 are A15).
>>
>> Best regards,
>> --
>> Bartlomiej Zolnierkiewicz
>> Samsung R&D Institute Poland
>> Samsung Electronics
>>
>
> Best regards,
> Javier
Hi Javier/Bartlomiej,
Below patch helps debug this problem.
http://article.gmane.org/gmane.linux.power-management.general/58549/match=cpufreq+arm_big_little+check+if+frequency+set+correctly
-Anand Moon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html