summaryrefslogtreecommitdiff
path: root/include/linux/workqueue.h
diff options
context:
space:
mode:
authorBrendan Jackman <brendan.jackman@arm.com>2017-08-17 14:38:21 +0100
committerJoel Fernandes <joelaf@google.com>2017-09-06 20:40:44 +0000
commit1bab88a22447c96f832aca1115370cfdd75fb168 (patch)
tree26b2482ed8d6e3b56533c6e28368ada0a69008f7 /include/linux/workqueue.h
parent3482bbea6b3e9ed685ce42a77927dfeaec0be122 (diff)
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>
Diffstat (limited to 'include/linux/workqueue.h')
0 files changed, 0 insertions, 0 deletions