cpufreq: dt-platdev: mark RK3399 as having separate policies per cluster
PATCH 1/1 cpufreq: dt-platdev: mark RK3399 as having separate policies per cluster
RK3399 has one cluster with 4 small cores, and another one with 2 big cores, with cores in different clusters having different OPPs and thus different policies. Let's enable this via "have_governor_per_policy" platform data.
---
Not tested, but we had a patch unconditionally enabling CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag in tree we used to ship devices based on RK3399 platform.
drivers/cpufreq/cpufreq-dt-platdev.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/cpufreq/cpufreq-dt-platdev.c +4 -1
@@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst = { { .compatible = "rockchip,rk3328", }, { .compatible = "rockchip,rk3366", }, { .compatible = "rockchip,rk3368", }, - { .compatible = "rockchip,rk3399", }, + { .compatible = "rockchip,rk3399", + .data = &(struct cpufreq_dt_platform_data) + { .have_governor_per_policy = true, }, + }, { .compatible = "st-ericsson,u8500", }, { .compatible = "st-ericsson,u8540", },
Signature · 5 lines
2.19.0.605.g01d371f741-goog -- Dmitry
Viresh Kumar
maintainerQuoted 4 lines · Dmitry Torokhov
RK3399 has one cluster with 4 small cores, and another one with 2 big cores, with cores in different clusters having different OPPs and thus different policies. Let's enable this via "
have_governor_per_policy" platform data.
The policies are always different in such cases, with or without this flag. What this flag rather enables is for us to have separate set of tunables for the governor for individual policies.
For example, without this flag there will be a single governor directory:
/sys/devices/system/cpu/cpufreq/schedutil/
and the value of tunables in that directory will be used for all cpufreq policies.
With this flag you wouldn't have the governor directory there, but rather in:
/sys/devices/system/cpu/cpufreq/policy*/schedutil/
i.e. tunables per policy and that's why the name of the flag is:have_governor_per_policy.
Quoted 6 lines
Signed-off-by Dmitry Torokhov <[email protected]>---
Not tested, but we had a patch unconditionally enabling
CPUFREQ_HAVE_GOVERNOR_PER_POLICYflag in tree we used to ship devices based on RK3399 platform.
Sure, that sounds good. Just that you need to update the commit log a bit.
Quoted 8 lines
drivers/cpufreq/cpufreq-dt-platdev.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)drivers/cpufreq/cpufreq-dt-platdev.c +0
-0
drivers/cpufreq/cpufreq-dt-platdev.c static const struct of_device_id whitelist[] __initconst = { · line 82
Quoted 6 lines
drivers/cpufreq/cpufreq-dt-platdev.c +2
-1@@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst = { { .compatible = "rockchip,rk3328", }, { .compatible = "rockchip,rk3366", }, { .compatible = "rockchip,rk3368", }, - { .compatible = "rockchip,rk3399", }, + { .compatible = "rockchip,rk3399", + .data = &(struct cpufreq_dt_platform_data)
data is void *. No need to provide typecast information. This shouldn't throw any build warnings I believe.
Quoted 1 line
drivers/cpufreq/cpufreq-dt-platdev.c +1
-0+ { .have_governor_per_policy = true, },
Signature · 1 line
viresh
Quoted 25 lines · Viresh Kumar
Quoted 4 lines · Dmitry Torokhov
RK3399 has one cluster with 4 small cores, and another one with 2 big cores, with cores in different clusters having different OPPs and thus different policies. Let's enable this via "
have_governor_per_policy" platform data.The policies are always different in such cases, with or without this flag. What this flag rather enables is for us to have separate set of tunables for the governor for individual policies.
For example, without this flag there will be a single governor directory:
/sys/devices/system/cpu/cpufreq/schedutil/and the value of tunables in that directory will be used for all cpufreq policies.
With this flag you wouldn't have the governor directory there, but rather in:
/sys/devices/system/cpu/cpufreq/policy*/schedutil/i.e. tunables per policy and that's why the name of the flag is:
have_governor_per_policy.
Quoted 8 lines
Quoted 6 lines
Signed-off-by Dmitry Torokhov <[email protected]>---
Not tested, but we had a patch unconditionally enabling
CPUFREQ_HAVE_GOVERNOR_PER_POLICYflag in tree we used to ship devices based on RK3399 platform.Sure, that sounds good. Just that you need to update the commit log a bit.
OK, I'll do that.
Quoted 4 lines
Quoted 4 lines
drivers/cpufreq/cpufreq-dt-platdev.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Quoted 14 lines
drivers/cpufreq/cpufreq-dt-platdev.c static const struct of_device_id whitelist[] __initconst = { · line 82
Quoted 11 lines
drivers/cpufreq/cpufreq-dt-platdev.c +2
-1@@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst = { { .compatible = "rockchip,rk3328", }, { .compatible = "rockchip,rk3366", }, { .compatible = "rockchip,rk3368", }, - { .compatible = "rockchip,rk3399", }, + { .compatible = "rockchip,rk3399", + .data = &(struct cpufreq_dt_platform_data)data is void *. No need to provide typecast information. This shouldn't throw any build warnings I believe.
We however need to tell the compiler the type of structure we are creating. The following won't compile:
.data = &{ .have_governor_per_policy = true, }Thanks.
Signature · 1 line
Dmitry