ANDROID: cpufreq-dt: Set sane defaults for schedutil rate limits
schedfreq used transition_latency as the default value for
rate-limiting upward frequency transitions. schedutil instead uses a
separate transition_delay_us field - if this is not set, it
uses transition_latency * 1000, which is not sensible.
The reason for the two separate values (transition_delay and
transition_latency) is that they represent different quantities:
"latency" reports how long it takes to execute a frequency
transition. "delay" is a tunable whose ideal value is one that best
balances the power cost of making a frequency transition with the
benefit of more often selecting the correct frequency. "latency" is
probably a lower bound on "delay".
AFAIK we don't currently have a way to directly express the desired
transition_delay_us field in the device tree, so for now let's just
set it to the same as transition_latency, so we get similar
default behaviour for schedutil as we got for schedfreq.
This doesn't make any difference if userspace is setting the cpufreq
tunables itself, it is just making the defaults saner.
Change-Id: Iec92d710c79d9c10d0bef1b617942185448fc214
Signed-off-by: Brendan Jackman <brendan.jackman@arm.com>
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 4d3ec92..e4cbfe5 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -280,6 +280,13 @@
policy->cpuinfo.transition_latency = transition_latency;
+ /*
+ * Android: set default parameters for parity between schedutil and
+ * schedfreq
+ */
+ policy->up_transition_delay_us = transition_latency / NSEC_PER_USEC;
+ policy->down_transition_delay_us = 50000; /* 50ms */
+
return 0;
out_free_cpufreq_table: