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>

1 files changed, 7 insertions, 0 deletions

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 90d64081ddb3..7bd7a8a5a1f6 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -359,6 +359,13 @@ static int cpufreq_init(struct cpufreq_policy *policy)
 
 	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 */
+
 	of_node_put(np);
 
 	return 0;