There are two descriptions of the TEO (Timer Events Oriented) cpuidle
governor in the kernel source tree, one in the C file containing its
code and one in cpuidle.rst which is part of admin-guide.
Instead of trying to keep them both in sync and in order to reduce
text duplication, include the governor description from the C file
directly into cpuidle.rst.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
As soon as a gpio is registered, it should be usable by a consumer. So,
do all the initialization before registering the gpios. Without this
change, a consumer can request a GPIO IRQ and have the gpio to IRQ
mapping fail.
Change-Id: If3e264ab764c633f00fcc280db0e1f9a10af5efb
Signed-off-by: Saravana Kannan <saravanak@google.com>
(cherry picked from commit 32188bddc9d8ba8d5907882ed5bd1dc3a83662a9)
Add a stub for cal_register_pd_lookup_cmu_id() when debugfs is disabled to
fix CONFIG_DEBUG_FS=n compilation.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
There's no reason to pin workers onto CPU2. Instead, allow the workers to
run where the workqueue sees fit, most likely on the CPU which enqueues the
worker, which is better than always dumping the workers onto CPU2.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Calling the architected timer adds nontrivial overhead as observed in perf
top, especially since the DVFS functions are hot paths.
Remove all of the sched_clock() calls since they're unneeded by ACPM.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Nahuel Gómez <nahuelgomez329@gmail.com>
This driver isn't even compatible with our kernel version, though it is present in the ems folder.
Signed-off-by: Nahuel Gómez <nahuelgomez329@gmail.com>
This was applied to fix a suspected reboot issue, but it turns out this was not the source of it.
This reverts commit ed828ec374bbd9f3a538a0c92421e9e0074b078f.
Queuing wake-ups is not measurably beneficial in any way. Disable it.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
[Flopster101: Apply to new way of setting features.]
Signed-off-by: Nahuel Gómez <nahuelgomez329@gmail.com>
(cherry picked from commit 8ddf75b4fb1d7b54a795c1dc70bf480a5f049603)
(cherry picked from commit dbf96ce6987d4361b4135124b81cb40b269366c5)
(cherry picked from commit 3291d145fade85cef2830b9d28fe1c90e154ba9c)
Given that a CPU's clock is gated at even the shallowest idle state,
waiting until a CPU idles at least once before reducing its frequency is
putting the cart before the horse. For long-running workloads with low
compute needs, requiring an idle call since the last frequency update to
lower the CPU's frequency results in significantly increased energy usage.
Given that there is already a mechanism in place to ratelimit frequency
changes, this heuristic is wholly unnecessary.
Allow single-CPU performance domains to drop their frequency without
requiring an idle call in between to improve energy. Right off the bat,
this reduces CPU power consumption by 7.5% playing a cat gif in Firefox on
a Pixel 8 (270 mW -> 250 mW). And there is no visible loss of performance.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
* This is a modified version of schedutil, introducing two new tunables: "efficient_freq" and "up_delay".
* Only raise cpufreq to the non-efficient one (higher than effcient frequencies) if the governor keeps requiring non-efficient frequencies for more than up_delay time.
* Override the new frequencies with the efficient one if the consecutive request time doesn't reach up_delay.
* The two tunables support multiple args, e.g. you can set "1248000 1401600" for "efficient_freq" and set "50 60" for "up_delay", which means it would wait 50ms before raising the frequency to 1248mhz and wait for 60ms before raising the frequency to 1401mhz.
[Flopster101: move the kconfig entry to the proper section.]
