summaryrefslogtreecommitdiff
path: root/firmware/target
diff options
context:
space:
mode:
authorAidan MacDonald <amachronic@protonmail.com>2021-04-17 11:34:05 +0100
committerAidan MacDonald <amachronic@protonmail.com>2021-04-17 20:24:36 +0000
commit92140752d784d7180df294e41e0d4f90c34c86c9 (patch)
tree588b00303e0720f993d1a75d48351c1f22771f7c /firmware/target
parentfceffb7d4aa429a60cd4cf760dd9852bb594b4be (diff)
downloadrockbox-92140752d784d7180df294e41e0d4f90c34c86c9.tar.gz
rockbox-92140752d784d7180df294e41e0d4f90c34c86c9.zip
FiiO M3K: disable CPU frequency switching
After conducting some simplistic tests, I found that the power usage did not appear to be affected by the CPU frequency. I tested by playing back a 44.1 KHz FLAC file on single track repeat, and measured current with the AXP173's battery discharge current ADC. The button and LCD backlights were set to always on. Headphones were unplugged and the volume was muted to eliminate any influence from the headphone amp. On average the current usage was between 78-81 mA at 1008 MHz, 252 MHz, and 112 MHz. If anything, 1008 MHz drew _less_ current than the lower frequencies, by about 1-3 mA. A possible explanation for this, assuming it's not just a bias of the test, is that the CPU idle state saves so much power that it's better to maximize the real time that the CPU spends idling. More systematic testing is needed to confirm this. Change-Id: I527473e8c4c12bc1e94f8d4e849fecc108022abe
Diffstat (limited to 'firmware/target')
-rw-r--r--firmware/target/mips/ingenic_x1000/kernel-x1000.c20
1 files changed, 0 insertions, 20 deletions
diff --git a/firmware/target/mips/ingenic_x1000/kernel-x1000.c b/firmware/target/mips/ingenic_x1000/kernel-x1000.c
index eb7c3d6124..8d272bdaa9 100644
--- a/firmware/target/mips/ingenic_x1000/kernel-x1000.c
+++ b/firmware/target/mips/ingenic_x1000/kernel-x1000.c
@@ -23,26 +23,6 @@
23#include "system.h" 23#include "system.h"
24#include "x1000/ost.h" 24#include "x1000/ost.h"
25 25
26/* TODO: implement a CPU frequency switching policy based on CPU utilization
27 *
28 * The basic assumption is that the workload consumes a fixed number of CPU
29 * cycles per second on average (= utilization), so we can set the frequency
30 * based on that value. Audio playback should fit this usage pattern well, so
31 * it's a good fit for Rockbox.
32 *
33 * It's easier to understand in terms of fluid flow -- we need to keep
34 * a reservoir of water topped up, CPU frequency is the inflow rate, and
35 * CPU utilization is the outflow rate. The goal is to avoid running dry
36 * and minimize the inflow rate.
37 *
38 * The only tricky part here is handing usage spikes -- CPU frequency has to
39 * increase faster than utilization or there's a risk of audio dropouts.
40 *
41 * Rockbox CPU boost could be used as a hint to scale up frequency faster.
42 * If that's not necessary to get good results, HAVE_ADJUSTABLE_CPU_FREQ can
43 * be disabled entirely.
44 */
45
46#define CPU_IDLE_SAMPLES 100 26#define CPU_IDLE_SAMPLES 100
47 27
48void tick_start(unsigned interval_in_ms) 28void tick_start(unsigned interval_in_ms)